aclAuditor—基于Python的ACL安全审计脚本

作者：cah1l1yn   （默默无闻的安服仔）

本文介绍了一个用于对主流品牌的网络设备配置文件中的ACL规则进行安全审计的脚本，并对脚本的设计过程、审计规则、代码结构等进行说明。该脚本旨在批量发现ACL中存在安全隐患的规则，如过于宽松、开放危险端口、重复或冲突等情况，弥补纯人工审计需要花费大量时间和精力的弊端。

华三交换机和思科交换机配置文件的审计结果分别如下两个图所示。

访问控制列表（AccessControlLists，ACL）是应用在路由、交换和防火墙等网络设备接口的指令列表。这些指令用来告诉网络设备哪些数据包可以通过、哪些数据包需要拒绝，每条指令中都包含源地址、目的地址、端口号、协议和动作等条件。

ACL在企业内网安全中发挥着不可或缺的作用，它可以有效规避很多外部和内部的信息安全问题。例如开发人员有权限登录生产环境的某些机器，ACL可以防止他们利用这些机器跳转访问到其他不属于其权限范围的机器。又例如黑客通过网站获取到内网服务器的控制权限，ACL可以限制黑客在内网中横向移动的范围，降低危害。

上图是一个简单的企业内网拓扑示意图，内网ACL配置在位于中心位置的网络设备，可能是交换机、路由器或防火墙。ACL管控内网中不同区域之间的数据往来，且应该遵循默认拒绝原则，即跨区域传输的数据包，只有当ACL中有明确的匹配规则时才可通过，否则一律拒绝。按照该原则，每当企业需要新增设备、服务或者需要临时调试网络、测试业务时，都需要开通新的ACL规则。但在一些中小型企业中，ACL规则只开不关的情况普遍存在。当设备或服务下线、IP地址变更或者临时用途结束后，没有及时删除对应的ACL规则。日积月累，网络设备上堆积了大量的ACL规则，其中可能存在一些开放了危险端口(如3389、3306、1433等)甚至是网段全通的规则，也可能存在一些冗余或者互相冲突的规则，这些情况都存在安全隐患，并且体积太大的配置文件也不利于网络设备的健康运行。相关负责人可能有意识到这种情况，但是由于网络设备数量多，如需要人工审计所有设备上的ACL规则将耗费大量的时间精力，实施难度较大。目前业内暂时没有针对ACL安全审计的解决方案，网络上也没有相关的开源工具，因此笔者尝试通过Python脚本实现ACL的批量化安全审计，弥补纯人工审计的弊端。

在实际的企业内网中，基本上每个区域的边界都会有路由交换或防火墙等设备，这些设备上都会配置ACL规则用于管控所属区域的数据进出。因此脚本首先需要具备批量审计的功能，将所有待审计的完整网络配置文件放置在一个文件夹，脚本能一次性审计完成。再者，脚本需要基于预先设定好的审计规则发现这些配置文件的ACL列表中存在安全隐患的规则，最后，为了方便审计结果的保存和传阅，脚本需能够输出可读性较高的审计日志，并按网络配置文件名生成对应的日志文件。日志内容应包括配置文件名、ACL列表名称、规则数量、存在隐患的ACL规则和对应的隐患类型及发现该ACL存在的隐患总数等信息。另外，有些企业内网中会使用不同品牌的网络设备，他们的配置文件格式基本上可分为两大派系：一是华为系，包括华为和华三，二是思科系，包括思科和锐捷，其他品牌的设备大多也是基于这两大派系。因此，审计脚本至少必须支持华为系和思科系品牌的配置文件格式。并且笔者希望脚本可以实现不同品牌设备配置文件的一键批量审计，而不需要用户在审计时将不同品牌的配置文件放在不同的文件夹或是执行脚本时利用参数指定品牌。

前面提到所有待审的配置文件会放置在一个文件夹中，因此脚本执行的第一步就是从这个文件夹中逐个读取配置文件内容。配置文件保存了设备上的所有配置，如接口地址、设备登录凭据、路由协议、ACL、VLAN等等，以上每一个部分之间都有特定的符号进行分割，如下图所示，华为系设备是“#”，而思科系设备是“!”。

为了方便审计规则的匹配，需要将所有ACL配置提取出来，保存为一个列表，后续对这个列表进行审计。这样做的原因是因为有些配置文件内容较多且复杂，把ACL配置单独提取出来的目的是细化审计范围，避免其他无关的配置内容影响审计进行。

ACL配置提取出来后，还需要进一步进细化。因为提取出来的配置中包含了多个互相独立的ACL列表，在上图中便能看到“3999”和“4000”两个列表。最终需要审计的目标是每个ACL列表中的每一条ACL规则。因此需要将提取出来的ACL配置再分割为单独的ACL列表。

整个提取过程如下图所示。

作为一个审计脚本，最核心的就是审计规则，即判断怎么样的ACL规则存在安全隐患，再根据这些规则编写具体的匹配规则。笔者根据以往在甲方企业中兼任网络管理员的经验，整理出以下存在安全隐患的规则类型。

注：因不同品牌的ACL规则格式不同，下列有部分规则仅针对特定品牌，已作备注。

笔者将以上审计规则划分为两大类：1类包含危险规则和宽松规则，通过输入单条ACL规则便可判断其是否匹配；2类包含覆盖规则、冲突规则和冗余规则，需要对比两条ACL规则才能判断是否互相覆盖、冲突或冗余。而最后一个默认拒绝规则的匹配方式较为特殊，后文会详细讲解。

笔者已经将ACL列表从配置文件中提取出来，执行审计时需要依次用上文定义的规则去匹配每个ACL列表中的每一条规则，而默认拒绝规则是直接从单个ACL列表中匹配。匹配成功后打印结果并记录日志，日志中包含匹配的审计规则和对应的ACL规则。脚本的整体结构和执行流程如下图所示。

不同品牌网络设备的ACL配置格式相差较大。其中思科系设备的ACL配置格式比较多样。相同意义的ACL规则，华为系只存在一种格式，而思科系可以用四种不同的格式表达，如下表所示。

从上表可以看出，华为系ACL规则的特点是源地址、目的地址和端口都有明确的关键字作标识。而思科系ACL规则没有以上关键字，默认前面的地址为源，后面的地址为目的。且地址的编写方式有两种，一是host+IP，二是IP+掩码。在企业网络中，由于不同网络管理员的操作习惯，同一台设备的ACL规则可能存在不同的格式。这就给脚本匹配规则的编写带来了较大的难度。

根据上述设计思路，笔者编写了审计脚本，其中包含的6个函数及主要功能描述如下表所示。ruleXX()和ruleXX()函数即是根据4.2章节表格中所列举的审计规则利用正则表达式实现。

该函数用于提取ACL列表并识别设备品牌，如下图。

首先通过思科系设备ACL配置中的关键字符串’ip access-list’来识别设备类型是华为系还是思科系，并利用变量device_type作为标识，便于后续调用相应的审计规则。华为系和思科系设备的配置文件中不同类型的配置之间会分别以“#”号和”!”号进行分割，基于这个特点本函数利用find()函数和字符串切片方法来提取ACL配置部分，提取后再利用split()函数将其分割为单独的ACL列表。

以华为系为例，首先利用find()函数查找字符串‘acl’并将索引值赋予给变量first_index，再利用rfind()函数从文件末尾反向查找最后一个’acl’字符串并将索引值赋予变量second_index，查找到最后一个‘acl’字符串所在的索引值后find()函数则可以从该索引值的位置往后查找第第一个‘#’符号的索引值，将该索引值与变量second_index对应的索引值相加后则是整个ACL配置部分最后的一个’#’符号的索引值。最后用字符切片方法将截取索引值fisrt_index和third_index之间的内容即为上图红框所示的ACL配置，截取后同时利用split()函数以’#’符号分割并赋值予列表alist。最终执行结果如下图所示。

Main()函数将进一步处理列表alist，将其提取为单个ACL列表。执行审计时，首先在整个ACL列表中匹配是否存在默认拒绝规则，再逐条提取ACL规则，调用1类规则函数进行审计，最后按两条一组提取ACL规则，调用2类规则函数进行审计。主要代码如下图。

下面以表格形式对部分关键代码作讲解。

ruleXX()函数族包含了4个函数，分别为对应华为系ACL格式的ruleA1()和ruleA2()，对应思科系ACL格式的ruleB1()和ruleB2()。这几个函数中包含了脚本的所有审计规则（除默认拒绝规则），均使用正则表达式进行匹配。下面各列举A1类和A2类的一个匹配规则作讲解。

ruleA()函数中通过正则表达式匹配动作为允许的ACL规则中是否存在放通整个C段甚至是B段的作为源地址的情况，如有则将该ACL规则判断为源地址范围过大的宽松规则。这种匹配方式存在的不足是当网段不是正常C段或B段而是非常规的子网时就无法匹配，但由于这种子网不便于管理，因此大多数中小型企业内网很少使用这种子网。

ruleB()函数首先通过对比规则号判断两条传入的ACL规则是否为同一条，再判断动作是否一致，如一致则由后面的冗余和覆盖规则进行匹配，否则进行冲突规则的匹配。

下图中的冲突规则是对比两条ACL的源地址、目的地址和端口号，在完全一致的情况下，由于两条规则的动作不一致，即一条为允许另一条为拒绝，由此把这两条ACL规则判断为互相冲突。

下图中分割线以下的规则为冗余和覆盖规则，原理与上述规则一致。由于两条ACL的动作、源地址、目的地址和端口号均一致，因此把这两条规则判断为互相冗余。

本文介绍了笔者基于目前市场和网络上难以找到ACL安全审计解决方案和工具的情况，根据以往在甲方企业的网络管理工作经验编写了一个安全审计脚本。该脚本可以批量发现新主流品牌的网络设备配置文件中存在安全隐患的ACL规则并输出具备较高可读性的审计日志。随着网络安全形势发展，笔者认为往后会有越来越多的企业产生ACL安全审计这个需求。

目前该脚本支持华为、华三、思科、锐捷等主流品牌及其他类似于以上品牌配置文件格式的设备，但因为笔者持有的测试样本较少。无法保证该脚本没有BUG，希望有ACL安全审计这方面需求的朋友们下载试用。如有任何问题可以在Github提交Issue，帮助笔者逐步完善该脚本。

最后附上Github地址：https://github.com/cahi1l1yn/aclAuditor/