防火墙智能分析工具（juniper srx）

随便说说

防火墙作为网络安全的第一道防线，在网络中的地位是毋庸置疑的。防火墙自上线以来，其策略数量随着业务量增长日益增加，很多时候运维人员需要对现网的策略做些优化和梳理工作，了解墙的线上配置都开了哪些策略，这些策略都放行了什么IP的什么端口；又或者领导让出一下关于A地址的所有策略都开了哪些端口的表格等等。虽然有些任务通过命令检查一下就能看到结果，大家都知道现在的墙策略大部分都是调用的对象名称，而并不能直观的显示其具体的内容。针对防火墙策略不多的情况，偶尔人工梳理一次也未尝不可，但如果把这些工作都变成常态的话，估计再有耐心的人都会给逼疯，暂且不说梳理一次需要的工时。
设备老旧了、新政策出台、国产化推进等等各种因素，会将批量的国外安全设备替换为国内品牌。防火墙的迁移替换工作可不比防火墙，交换机路由器只要架构性配置搞定就可以了，可以说没有太大工作量；而防火墙确不一样，防火墙的配置迁移说白了就是策略的迁移，策略的多少决定了工作量大小，如果是nat环境，工作量再加倍。防火墙跨平台配置转换一般厂家都提供相应的配置迁移工具，实现配置转换，我接触过的国内和国外防火墙配置迁移工具可以说没有一个完美支持nat的，或者只支持特定的nat配置语法，或者只是半转换（转换不彻底），再有就是其他各种不常见的语法无法支持到位。即使转了也要再加上大量的人工对其进行后期修订才能使用。
作为一名长期工作在运维人一线的我，不堪把时间都花费在这些方面，于是就产生了写脚本，自动化的各种想法…

SRX配置文件分析及数据结构选则

我工作中接触的juniper和hillstone防火墙比较多，本次先拿juniper 的srx配置来做初步的梳理和实现。Juniper srx墙给予junos系统，其配置文件的set格式结构比较清晰，语法都是固定格式，这里就不贴配置了，接触过的自然明白。

策略对象主要包含内容：策略id，from安全域，to安全域，源地址、目标地址、服务端口、动作、日志开关、时间表，状态。
策略的源地址、目标地址可以调用地址簿对象和地址组对象，服务端口可调用预定义服务端口和自定义服务端口，动作常用的也就permit和deny，日志开关也就是session-init和session-close，时间调用schedule，状态默认是enable，除非明确disable。

地址簿对象：地址簿可定义单个地址，一个子网、或者使用通配符掩码也就这3中格式。
地址组对象：地址组对象是一个容器，其成员可以是地址簿对象或者地址组对象，如果地址组里放地址组，我暂且叫他地址组嵌套。
服务簿对象：一种是自定义，一种是预定义的；服务簿有协议类型、源端口范围、目标端口范围、超时时长和应用关联这几项内容。一个服务簿里可以通过多个term实现多个不同协议及端口定义。
服务组对象：服务组是一个容器，其成员可以使自定义服务簿对象，预定义服务簿对象，亦可以是服务组对象，类似地址组。
时间表对象：也就两种，一种是例行性时间定义，一种是绝对时间的定义方式。
nat规则：srx防火墙支持三种类型nat配置，静态、动态源和动态目的；静态nat比较简单就是一对一或者n对n的地址映射，动态源和动态目地nat的语法类似策略，有匹配条件和动作，即满足什么源地址、目标地址、协议及端口的nat成pool的地址。
如何将这些策略、nat及相关对象配置进行数据结构化？采用什么样的数据结构便于存储这些元素信息，又便于做查找、调用及展现？数据结构不要太过于复杂。综合以上考虑，最终选择采用字典为主、列表为辅及两者的嵌套结构。

思路及实现过程

开发环境选择python，因为简单易上手。
通过配置文件分析，我需要构建地址簿字典，地址组字典、服务簿字典、服务组字典、预定义服务字典、策略字典、nat字典，时间表字典。
防火墙配置初始化函数实现配置文件的读取，通过正则匹配将各对象的语法及数据转变为字典结构的数据模型。策略配置和nat规则转成表的过程无非就是将策略里的对象名展现为其真实内容而已。
安全策略和nat规则梳理成表功能实现起来难度不大，只是配置识别，然后展现，再通过固定格式输出就可以了。但防火墙配置迁移转换功能模块实现起来就稍微复杂。首先必须熟通两个平台的语法，其次要清楚数据流处理机制，再有就是做等价语法转换。
说起来简单，做起来难呀。比如juniper的netscreen墙的策略和nat就非常灵活，可以使用静态mip，可以基于策略实现源和目的nat或者port-map，基于接口的nat模式，及以上几种nat的混合使用。配置转换并不是直译，并不是你看到什么配置，将其转换成另一平台语法即可，看到的并不一定是真实的。比如一条策略源地址转换调用了dip 地址池的地址，那么策略源地址一定会转换为dip的地址吗，答案不一定是，如果你直接这么转了，那可就有风险了，因为mip的优先级是最高的，源地址在出接口上有mip配置的话，其会转换为mip定义的对应地址。再有trust接口如果是nat模式，其具体会对哪些方向的流量默认做源地址转换为接口ip，这个具体就不细说了。再比如juniper的srx墙，策略和nat是分离的，策略里源地址和目标地址都是真实IP地址，而不是nat前的地址，这个与山石墙的策略和nat规则就不一样了，如果是直译，那就直接死掉了。顺便补充一句，山石墙不支持bnat和snat、dnat混用，切记！

1、通过类class Srx类实现配置文件初始化，并构建数据模型；
2、循环策略字典，将每条策略的源地址、目标地址、服务端口展现为对象的真实内容；
3、nat规则本身就是真实地址，无需展现；
4、将展现后的策略字典和nat字典内容输出到csv文件。
5、梳理某IP策略的功能首先要编写ip地址匹配函数，我调用了IPy模块，并写了自己的函数，可以实现单个IP，IP范围、不连续IP作为输入条件进行匹配查找，将满足条件的策略输出到csv文件；

配置迁移转换以juniper srx 转hillstone 为例，nat规则配置迁移转换可直译，保证语法等价即可，需要注意的地方就是静态nat需要转换为山石的snat和dnat，前面说过了山石nat不支持静态和动态混用。策略配置转换需将每条策略的目标地址通过特殊匹配算法找到其相关的nat条目，取出nat规则里的nat地址并予以替换。这项工作就相当于把策略表里的所有的策略条目，在nat表里跑一遍，用匹配的nat条目的nat地址对策略目标地址进行替换。如果是人工作这项工作的话，500条策略，试算下需要多少工时？

##安全策略输出表格格式：

##NAT策略表格格式：

功能展示

目前工具已实现主体功能，其中由于华为的版本语法差异太大，目前只实现了v3版本；还有很多想法，比如垃圾对象配置梳理并自动生产删除脚本功能模块；策略合规检查模块；策略自动生成配置模块；多套防火墙自动定位及策略匹配查找模块；基于访问关系需求表自动生成配置模块；防火墙基线合规检查模块等等。废话少说：“翠花，上菜，，，，”

策略和nat梳理表格输出

policy_table.xls:

nat_table.xls：

配置文件转换

附图为juniper srx转山石防火墙配置示例：

山石墙配置文件由于内容太多，只是将文件段落做下展示：