防火墙ACL配置自动化方案探讨
主要介绍了一些各品牌防火墙配置自动化生成的思路，功能包括核查现有配置，判断是否需要新增配置，以及自动生成新增配置命令。并且在新增配置中，如何有效结合调用现有配置，避免在自动化生成的过程中引起防火墙配置量的野蛮增长，产生大量冗余配置。
1，ACL配置命名规范
自动化执行一个ACL需求时，需要输入一个唯一的编号（可以跟随需求单），命名过程中会使用到，太长的话，天融信防火墙命名可能会报错，推荐字母+六位数字，例如A000001
为了不影响存量配置，建议所有自动化的匹配规则全部都在规范命名后的地址组/端口组/ACL组内开展
防火墙自动化之前，必须要明确ACL命名的规范性，否则自动化无从谈起，甚至还会影响生产
以下面需求为例：
需求单A000001： 源地址（10.10.10.1, 10.10.10.2）；目标地址（20.20.20.1, 20.20.20.2）；目标端口（TCP: 80，443）；
需求单A000002： 源地址（10.10.10.3, 10.10.10.4）；目标地址（20.20.20.1, 20.20.20.2）；目标端口（TCP: 80，443）；
需求单A000003： 源地址（10.10.10.5, 10.10.10.6）；目标地址（20.20.20.1, 20.20.20.2）；目标端口（TCP: 80，443）；
需求单A000004： 源地址（10.10.10.1, 10.10.10.2）；目标地址（20.20.20.1, 20.20.20.2）；目标端口（TCP: 80，443，8443）；
需求单A000005： 源地址（10.10.10.3, 10.10.10.4）；目标地址（20.20.20.1, 20.20.20.2）；目标端口（TCP: 80，443，8443）；
需求单A000006： 源地址（10.10.10.5, 10.10.10.6）；目标地址（20.20.20.1, 20.20.20.2）；目标端口（TCP: 80，443，8443）；
需求单A000007： 源地址（20.20.20.1, 20.20.20.2）；目标地址（10.10.10.1, 10.10.10.2）；目标端口（TCP: 80，443）；
假设源地址接口是outside，目标地址接口是inside
怎么建地址组/端口组合适呢？
1.1，端口组
cisco：如果是访问一个端口，不用创建端口组，直接eq ...。如果是开通多个端口，必须建立端口组，才能被ACL调用。
juniper/华为/天融信：可以在ACL中直接调用端口，因此建议不用建端口组了。自动化时直接在ACL中罗列开通端口即可，其中juniper/天融信需要事先为端口自定义一个名称，华为连名称都不用定义。
cisco多个端口需要定义端口组，但是处理也比较简单，不用和本次开通单号做关联，可以搜索现有的自动化端口组名称（不建议调用非规范命名的端口组），有则调用，没有则新建。
以A需求为例，如果不存在包含80，443端口的TCP端口组，则新建端口组：pg_A000001。(如果是UDP可以建pgu_A000001)
后续如果是开通TCP80，TCP443的，可以直接调用端口组pg_A000001
后续如果是开通TCP80，TCP443，TCP8443的，不允许往pg_A000001中添加8443，然后再调用pg_A000001。而应当根据需求单号，新建一个地址组。
不允许往现有规范命名的端口组内加成员！！！
1.2，地址组
需求单A000001： 源地址（10.10.10.1, 10.10.10.2）；目标地址（20.20.20.1, 20.20.20.2）；目标端口（TCP: 80，443）
假设根据开通单号A000001，命名为：
A000001_src（10.10.10.1, 10.10.10.2）
A000001_dst（20.20.20.1, 20.20.20.2）
pg_A000001（80, 443）
access-list outside extended permit tcp object-group A000001_src object-group A000001_dst object-group pg_A000001
需求单A000002：
需求单A000002： 源地址（10.10.10.3, 10.10.10.4）；目标地址（20.20.20.1）；目标端口（TCP: 80，443）
需求单A000002和需求单A000001的目标地址/目标端口完全一样
根据1.1，端口组可以直接调用现有的pg_A000001
地址组如果不考虑融合现有策略，完全新建：
A000002_src（10.10.10.1, 10.10.10.2）
A000002_dst（20.20.20.1, 20.20.20.2）
pg_A000001（80, 443）
这样，配置量增长会非常快，如果有100个需求单都是访问20.20.20.1, 20.20.20.2的80和443端口，源地址/目的地址/acl都会被重复创建100遍。但其实这100条ACL完全可以融合成1条ACL。
那如果选择融合，直接将需求单B的源地址（10.10.10.1, 10.10.10.2）加到A000001_src，这样可行吗？
可能存在如下问题：
1）如果该源地址组被其他ACL调用，则可能扩大了其他ACL的访问范围， 假如存在10.10.10.1, 10.10.10.2访问100.100.100.1的需求，其中10.10.10.1, 10.10.10.2地址组名称用的也是A000001_src
2）更糟糕的是如果被反方向deny调用，则可能影响现有系统的访问，例如存在deny 某些地址(inside) 访问 A000001_src(outside) 的ACL
因此：
地址组名称可以被反复调用和地址组名称可以添加成员是一对矛盾
可以被反复调用就不允许添加成员，可以添加成员就应该禁止被反复调用
指定如下地址组命名规范:
目的地址组名称: 所在防火墙接口_开通工单， 可以被其他"同方向"ACL调用但禁止添加成员（"同方向"，意味着只能作为目的地址被调用）
源地址组名称: to_目的地址组名称_开通工单， 禁止被其他ACL调用但可以往里面添加成员
1.3，规范后的开通单案例
根据1.1-1.2，前述需求单A000001-A000002可以做如下命名：
需求单A000001：新建源地址组 to_inside_A000001_A000001，新建目的地址组inside_A000001，新建端口组pg_A000001
需求单A000002：将10.10.10.3, 10.10.10.4添加至to_inside_A000001_A000001
需求单A000003：将10.10.10.5, 10.10.10.6添加至to_inside_A000001_A000001
需求单A000004：新建源地址组to_inside_A000001_A000004，新建端口组pg_A000004
需求单A000005：将10.10.10.3, 10.10.10.4添加至to_inside_A000001_A000004
需求单A000006：将10.10.10.5, 10.10.10.6添加至to_inside_A000001_A000004
需求单A000007：新建源地址组to_outside_A000007_A000007，目的地址组outside_A000007
注意
需求单4：由于目的地址组inside_A000001已经创建过，可以直接调用，但是端口组和源地址组需要新建
需求单7：即使20.20.20.1, 20.20.20.2和10.10.10.1, 10.10.10.2都已经被创建过，但是方向不同，都不能拿来调用，需要全部新建
实际上：就是把 "接口+目标服务器+端口" 绑定起来看作一种"服务"，后续需求单如果是访问已有的"服务"，就可以往该"服务"的"客户端(即源地址)"内添加。如果该服务不存在，就需要新建。
这样可以在 "完全不融合导致配置野蛮增长" 和 "融合太紧密导致放宽策略或者出现问题" 做个折中
1.4，存在PAT时的命名
PAT策略的地址组名称，不应该调用ACL组名称
2，ACL配置自动化的思路
主要涉及模块：
1）配置采集
2）配置解析
3）策略分析，策略分析又包含路径分析，策略核查，配置生成模块
3，配置采集
配置采集通过paramiko定制脚本，获取防火墙配置文件。
4，配置解析
对各品牌防火墙（思科、天融信、juniper、华为）不同版本的防火墙配置文件进行解析，转换为三张表格：
表格一：地址表，记录地址组名称和地址组成员的对应关系
表格二：端口表，记录端口组名称和端口组成员的对应关系
表格三：ACL策略表，记录ACL主要信息
备注:
不同品牌防火墙记录信息会有差异，例如地址表中juniper需要记录区域信息
主要采用正则表达式 + pandas每天定时对防火墙配置进行读取和解析，供后续模块调用
返回的类型是表格， 可以通过excel， json， 数据库保存。数据库有点大材小用，excel表格单元格内数据量太大无法保存(例如地址组中有conf列会记录该地址组相关配置，如果成员数量过多就无法显示)，推荐用json，后续模块调用时可以直接将json转pandas。
5，策略分析
5.1，路径生成模块（需要结合公司实际场景定制）
直接调用配置生成模块，不仅需要提供防火墙名称，防火墙端口等信息，如果涉及多个防火墙，还需要逐一罗列，对运维人员交互不友好
因此还需要结合公司实际网络环境，定制各网段间访问的关系，例如A网段访问B网段经过哪几个防火墙，以及分别是涉及防火墙的哪几个接口，思科防火墙的入向策略名等等
如果网络环境比较复杂可能全部罗列比较困难
对于HUB-SPOKEN有环形网的场景，可以通过记录每个网段到环形网经过的防火墙(以及相应接口)，这样所有通过环形网互相访问的网段就无需逐一罗列，同时再补充一张不经过环形网的特殊访问表即可
5.2，策略核查模块
策略核查模块针对输入的ACL访问需求，做如下核查:
1)检查源地址、目的地址、目的端口， 三元素完全一致的ACL，返回所有命中的ACL(包括)
2)检查目的地址、目的端口，两个元素完全一致的ACL，并且目的地址组命名符合第一章的命名规范的(添加源地址时避免影响存量不规范配置)，返回该ACL所有信息
备注：这里只是做最简单的描述，实际实现时，还涉及到协议tcp/udp，而且不同防火墙需要的acl字段也有差异，思科只需要传策略名，其他品牌防火墙还有源区域和目的区域等等。
5.3， 配置生成模块
这块比较简单，主要是结合策略核查模块的结果，以及各品牌防火墙的配置命令，做如下三步：
1)三元素完全一致的ACL，并且第一条是permit的，直接反馈现有配置，无需新增配置
2)三元素中有目的地址、目的端口，两个元素完全一致的ACL，直接将需求中的源地址往现有源地址组名称中添加
3)根据本次工单号，依据命名规范，新增配置。新增配置时需要考虑是否有现有的目的地址组，端口组(思科)可以调用
后续会逐一对各模块实现细节和相应代码进行展开分析
