1、为什么要引入防火墙对象(组)的概念？

在目前的云计算中，虚拟化防火墙已经成为了主流，其不但可以节省资源，还可以按序创建。SaaF（Soft As A Firewall）已经成为未来的防火墙形态，但是针对繁杂的 ACL，传统的五元组就显得有些笨拙了，此时更加灵活的对象组应运而生，专门用来解决这些繁杂的问题。

1.1、对象(组)的优势

1. 减少配置访问策略的条目

   如果需要添加或删除某一个对象的策略时，只需要在对象组中操作就可以了

   使我们的访问策略更有可读性

   对象组使得策略用途简单明了

   可以在对象中定义 NAT

2、对象(组)和规则的关系

以上，对象组分为服务对象组和 IP 对象组，服务对象组中包含服务对象，IP 对象组中包含 IP 对象。其中服务对象为协议和端口的组合，IP 对象为单个 IP、CIDR 和连续的 IP 段。规则中包含 3 个对象，分别为源 IP 对象，目的 IP 对象和服务对象，这样一来对象组和传统的五元组就实现了功能对齐，而且可以实现更加详细的规则策略。

使用对象组的防火墙层次：对象-->对象组-->规则-->策略-->防火墙

3、对象(组)数据表设计

3.1、详细设计

3.1.1、对象的详细定义

对象组分为 IPv4 地址对象组、IPv6 地址对象组、服务对象组。这些对象组可以被对象策略、ACL 引用，作为报文匹配的条件。

IPv4 地址对象组内可以配置 IPv4 地址对象，地址对象与 IPv4 地址或用户绑定，用于匹配报文中的 IPv4 地址或报文所属的用户。

IPv6 地址对象组内可以配置 IPv6 地址对象，地址对象与 IPv6 地址或用户绑定，用于匹配报文中的 IPv6 地址或报文所属的用户。

服务对象组内可以配置服务对象，服务对象与协议类型以及协议的特性绑定（协议特性如 TCP 或 UDP 的源端口/目的端口、ICMP 协议的消息类型/消息码等），用于匹配报文中的可承载的上层协议，其中端口与协议端口号绑定，用于匹配报文中的协议端口号。

3.2、对象表结构

MariaDB [neutron]> desc firewall_object;+-------------------+---------------+------+-----+---------+-------+| Field             | Type          | Null | Key | Default | Extra |+-------------------+---------------+------+-----+---------+-------+| id                | varchar(36)   | NO   | PRI | NULL    |       || name              | varchar(255)  | YES  |     | NULL    |       || project_id        | varchar(255)  | YES  | MUL | NULL    |       || description       | varchar(1024) | YES  |     | NULL    |       || object_group_type | varchar(36)   | YES  |     | NULL    |       || protocol          | varchar(40)   | YES  |     | NULL    |       || ip_version        | int(11)       | YES  |     | NULL    |       || source_port       | varchar(255)  | YES  |     | NULL    |       || destination_port  | varchar(255)  | YES  |     | NULL    |       || ip_address        | varchar(255)  | YES  |     | NULL    |       || object_group_id   | varchar(36)   | YES  |     | NULL    |       |+-------------------+---------------+------+-----+---------+-------+11 rows in set (0.00 sec)

以上，防火墙相关表都属于 neutron 库，根据 object_group_type 类型来确定对象的类型，比如服务对象组中的对象只有 protocol、source_port、destination_port 这几个关键属性，IP 对象组的对象有 ip_version、ip_address 两个关键属性，project_id、name、id、description 属于公共属性。

3.3、对象组表结构

MariaDB [neutron]> desc firewall_object_group;+-------------------+---------------+------+-----+---------+-------+| Field             | Type          | Null | Key | Default | Extra |+-------------------+---------------+------+-----+---------+-------+| id                | varchar(36)   | NO   | PRI | NULL    |       || name              | varchar(255)  | YES  |     | NULL    |       || description       | varchar(1024) | YES  |     | NULL    |       || project_id        | varchar(255)  | YES  | MUL | NULL    |       || ip_version        | int(11)       | YES  |     | NULL    |       || object_group_type | varchar(36)   | YES  |     | NULL    |       || rule_id           | varchar(36)   | YES  |     | NULL    |       |+-------------------+---------------+------+-----+---------+-------+7 rows in set (0.00 sec)

以上，对象组是对象的集合，其中 object_group_type 表明了对象组的类型，rule_id 表明了此对象组关联的规则，当对象组关联了规则时无法被删除，ip_version 表明了 IP 对象组的 ip 版本，建议使用 IPv4，IPv6 这种样式。

3.4、接口定义

3.4.1、创建对象组

method：POST

uri：/v2.0/firewall/object_group

Code：202、404

body：

{	"object_groups": {  	"name": "x",    "description": "xx",    "project_id": "xxx",    "ip_version": "IPv4",    "object_group_type": "IPv4",    "rule_id": "dsds"  }}

字段解释：

name：对象组名称（必填）

description：对象组描述（选填）

project_id：对象组所属项目 ID（必填）

ip_version：IP 独享的 IP 版本（当对象组类型为 IP 是必填）

object_group_type：对象组的类型（枚举：IPv4、IPv6、Service）

rule_id：对象组关联规则的 ID（选填，可以在创建对象的时候关联规则，也可后续关联）

响应示例：

{	"object_groups": {  	"id": "dsdsdsdfrrgdg-gfdgdfgdgfd"  	"name": "x",    "description": "xx",    "project_id": "xxx",    "ip_version": "IPv4",    "object_group_type": "IPv4",    "rule_id": "dsds",    "created_at": "2021-4-2 22:20:37"  }}

以上，初始定义的对象组表结构中没有定义创建时间 created_at，在响应体中我想到了这个，所以添加了，你可以选在在设计表结构的时间增加他。这样我们就可以得到这个资源的创建时间，在以后的审计中会很有用。

3.4.2、修改对象组

method：PUT

uri：/v2.0/firewall/object_group

Code：200、409

body：

{	"object_groups": {  	"name": "x",    "description": "xx"  }}

鉴于对象组的特殊性，涉及到数据切换，所以暂时设计只支持名称 name 和描述 description 的修改。

字段解释：

name：对象组名称（必填）

description：对象组描述（选填）

响应示例：

{	"object_groups": {  	"id": "dsdsdsdfrrgdg-gfdgdfgdgfd"  	"name": "x",    "description": "xx",    "project_id": "xxx",    "ip_version": "IPv4",    "object_group_type": "IPv4",    "rule_id": "dsds",    "created_at": "2021-4-2 22:20:37",    "update_at": "2021-4-2 22:25:57"  }}

以上，我在修改对象组的接口中又想到了更新时间这个字段，可以记录我们最近一次修改对象组的时间，你可以在表结构中增加这个字段。

3.4.3、查询对象组

method：GET

uri：/v2.0/firewall/object_group

Code：200、404

响应示例：同创建

3.4.4、删除对象组

method：DELETE

uri：/v2.0/firewall/object_group/{object_group_id}

Code: 201、409

响应示例：

{	"res": 0}

3.4.5、CRUD 对象

关于对象的 CRUD 和对象组类似，只是在对象组的基础上，增加了所属对象组 ID，IP，协议，源目的端口这几个属性，而且你依然可以为其增加创建时间和修改时间两个时间属性。

4、原型

4.1、对象组的原型

4.2、对象的原型

4.3、补充解释

关于以上原型，只是大概的介绍，还有很多的不足，比如分页和查询，以及单条记录的快捷操作。请大家见谅，其中在规则的创建中我们可以选择数据来源为五元组或者对象组，如果为对象组，则我们需要为规则指定源地址对象组，目的地址对象组和服务对象组。

5、对象组和防火墙的联动

我们创建规则可以关联对象组，同时将规则关联到策略，之后策略关联防火墙的时候，Neutron 会将策略通过防火墙的插件下发到虚墙，实际使用的源地址，目的地址，协议和端口会使用对象定义的数据。而且当我们需要修改源地址等对象的时候，只需要修改对象的数据，Neutron 依然可以通过防火墙的插件将变更更新到虚墙。这样可以实现更加灵活的策略变更。

6、使用场景

• 复杂的访问策略场景

• 高频的权限更改

• 追加的 IP

• 端口的频繁变更

7、附

7.1、防火墙的规则是什么？

防火墙的规则描述了允许或拒绝五元组或者对象组的组合。比如：允许源地址为全零的段使用 ICMP 协议去访问目的地址为 192.168.1.1 的 IP，端口范围为 0-255。其中的源（目的）地址可以为五元组中的 IP 段，也可以是 IP 对象组。协议和端口可以是五元组组中的协议和端口范围，也可以是对象组中的服务对象。

7.2、防火墙的策略是什么？

防火墙的策略实际上市规则的集合，用来描述一组复杂的规则，从而实现类似 iptables 的多条 ACL。比如可以允许服务器的 80 端口通过 TCP 对外提供服务，也可以允许指定 IP 对服务器使用 ICMP 协议进行访问。