【交易技术前沿】网络自动化运维系统自主研发的探索与实践

本文选自《交易技术前沿》总第四十期文章（2020年9月）

安信证券股份有限公司 梁德汉 唐新华 武孟军

对于网络运维人员来说，日常工作中有一类属于重复性高且繁琐的内容：防火墙策略配置、定期设备配置备份、定期密码修改、配置内外网地址映射、交换机VLAN端口划分等等。特别是防火墙策略配置，随着应用系统数量增加，业务访问逻辑的复杂化，导致访问策略开通申请数量剧增。原始的手工配置方式不仅工作量大，而且差错率高，已经不能满足网络运维需求。故，网络自动化运维是IT系统运维必然的发展方向，也是大势所趋。但市场上此类成熟产品凤毛麒角，大多要深度定制开发。其中，防火墙策略开通自动化配置，是技术含量最高，也是最难实现的部分。本文重点分享了我司在网络自动化运维工作中为满足防火墙策略自动化配置需求，提出的防火墙策略自动化处理解决方案和自主研发实践经验，希望能“抛砖引玉”，为行业解决此类问题提供一个参考思路。

一、系统简介

网络系统是整个券商IT系统的重要基础设施和支撑平台，“牵一发而动全身”，其重要性不言而喻。相较于其他应用系统，网络系统中设备种类繁多，如路由器、交换机、防火墙、负载均衡器等。即使是同一种类设备，由于品牌和型号不同，配置管理方式和命令格式也不尽相同。因此，在IT运维自动化技术发展如火如荼的今天，网络系统自动化运维进程可谓举步维艰，传统的手工网络运维方式依然占据主流。

随着业务的发展，我司“两地三中心”IT系统架构的成型，网络运维工作量也成倍增加，传统运维模式差错率高、效率低等种种问题凸显出来。为改变这种被动局面，信息技术中心组织技术力量，分析网络日常运维工作中的弊端，结合目前出现的自动化运维新技术，决定自主研发、搭建一套能够解决网络日常运维工作中重复性高，需求量大，工作量大（需批量处理）的网络自动化运维系统。

1.1 功能需求和系统定位

经过分析，下列运维工作内容全部或部分适用于自动化处理：

（1）配置防火墙策略

（2）负载均衡设备配置

（3）定期设备配置备份

（4）定期修改设备密码

（5）交换机端口VLAN划分

（6）网络设备工作状态自动定期巡检

（7）应急处理（应急方案自动化）

（8）批量设备IOS升级

另外，系统定位于实现网络设备的自动化配置功能，不涉及网络设备监控功能。但是系统可以与监控系统建立通信接口，与监控系统建立联动机制，完成某些操作动作。比如，根据监控系统提供的监控数据和预先设置的阈值，触发自动化系统执行某些应急操作命令。

上述功能需求中，防火墙策略配置自动化需求尤为急迫：每天需要处理的防火墙策略开通流程多达30～50个，单个流程中列出的源、目的访问关系平均5～10条。这样，每天运维人员需要配置的防火墙策略条数接近百条，全部需要手工处理，占用了大量运维人力。同时，这也是所有功能需求中实现起来技术含量最高，最困难的部分。为此，我们决定先实现这部分功能，如果能顺利攻克这个“制高点”，后续部分的功能需求实现起来，也就水到渠成，容易多了。

1.2 系统整体架构

系统整体架构如图1所示，包括后台处理功能模块，系统界面和数据库三个主要部分。

图1 系统整体架构

其中，数据库保存各种程序数据配置信息，如设备信息，配置文件，包括各类用户输入的流程相关数据。系统界面实现用户接口，管理员配置、操作系统功能，它保存系统信息到数据库，也可以通过通信接口和功能模块通信，调用功能模块进行处理。功能模块实现一个可扩充的处理系统，由实现各种自动化处理功能的子模块组成。软件环境要求如下：

数据库：MYSQL 5.6

操作系统：CentOS 7

Web服务器：Apache2.4.41，PHP 7.0

功能模块开发语言：python>= 2.7

经过努力，目前已经完成了系统整体平台的搭建，以及防火墙策略的自动化处理：包括策略信息读取，自动生成配置脚本，自动下发配置等，实现了预期功能。使用本系统处理50条左右的策略，全部处理完成耗时在1分钟左右，极大提高了工作效率。本文后续内容，重点就防火墙策略自动化处理功能的实现进行介绍。

二、网络访问策略自动化处理解决方案

2.1 网络访问策略申请及处理流程

默认情况下，网络数据中心安全域之间主机相互访问是全部禁止的，网络访问按照“最小化”策略原则开通。在IT应用系统建设和运维工作中，如涉及到安全域之间主机的访问关系变更，就需要申请开通防火墙策略。通常，系统负责人会通过OA/ITIL系统提一个网络访问权限开通申请流程，经过审批，流转到网络运维人员处理后再流转回申请人处测试验证。具体流程如下：

申请人需要清楚应用系统各个组成部分的相互访问关系，即需要开通哪些主机访问哪些主机的哪些端口。这个访问关系随应用系统规模的不同，复杂度也不一样，但终归可以归结为1条或多条以下的访问关系，如表1所示：

表1 访问关系

在防火墙策略术语中，主机IP地址172.1.1称为源地址，172.10.5.5称为目的地址，TCP 端口8080称为服务。源地址，目的地址和服务，可以认为是一条防火墙策略中最关键的三要素。申请人的工作，是要把这些访问关系，以三要素的形式，提交给运维人员处理。

网络运维人员的处理过程如下：

1.首先根据源和目的地址，确定访问网络路径，路径上部署了哪些防火墙，最终确定需要在哪些防火墙上开通策略。完成这个工作的基础，是运维人员要十分熟悉网络的整体拓扑，以及整个网络中防火墙的分布情况。

2.假定需要在防火墙F1和F2两台防火墙上开通策略，下一步要确定F1和F2是什么品牌的防火墙？因为不同品牌防火墙，配置命令大相径庭。

3.一般的防火墙设备都提供web页面和命名行方式进行管理。登录防火墙，输入配置一条策略的必需信息，完成配置。如果是web页面，会通过表单提交信息。如果是命令行方式，则需要逐条输入完整的配置命令。

2.2 防火墙策略自动化处理

通过上面的过程分析，可以看到，申请人的工作量主要集中在访问关系的整理上；运维人员的工作重点则是在步骤1-3上，这也是最耗费人力，最费时的工作内容。策略自动化系统，就是要将运维人员的工作步骤1-3全部实现自动化。

也就是说，自动化配置系统需要根据申请人提供的策略信息，完成下面三部分工作：

其中，确定访问路径中的防火墙，首先要将网络中防火墙部署关系，也就是拓扑图用某种数据类型表示。比如将网络安全域表示为图的节点，网络链路表示为图的边。企业网网络拓扑相对稳定，不会频繁发生变化。这样，访问路径的确定实际上转化为有环路无向图的最短路径问题。

确定了访问路径，路径中有哪些防火墙，也就可以确定了。当然，如果网络规模不大，结构相对简单，也可以采用简单的手工确定方式，将网络中所有网段之间的访问关系列出来，每种访问关系经过哪些防火墙，保存到配置文件中直接使用。

在设备上下发配置策略，有两种方式可选，一是模拟手工通过命令行方式进行，即通过远程登录，将配置命令逐行提交设备。二是目前很多设备提供各种API接口，调用这些编程接口可以实现配置策略的功能。综合比较，考虑到通用行、执行效率和灵活性，选择使用第一种方式。远程登录可以使用python语言提供的telnetlib，或第三方库paramiko编写脚本实现，也可以考虑和目前流行的各种自动化运维平台结合，由第三方运维平台提交。

大部分重要和繁琐的工作，是生成策略配置脚本的过程。可以说，这个功能实现的差异，直接决定自动化配置系统的成败和智能化程度的高低。下面着重予以说明。

2.2.1 防火墙安全策略分析

图2是一条典型的防火墙安全策略。

图2 防火墙中一条实际的策略

可见，一条安全策略包括源安全域，目的安全域，源地址集合，目的地址集合，端口集合（包括TCP，UDP），动作（允许，拒绝，转发到VPN隧道）等几个重要组成元素。这条策略的控制意义是：如果有一个数据包从源安全域进入，经过防火墙处理后，要从目的安全域出去，数据包的源IP地址包含在策略的源地址集合中，目的地址包含在策略的目的地址集合中，且端口包含在端口集合中，则称为该数据包匹配了这条安全策略，防火墙根据策略中指定的动作，允许或拒绝该数据包通过。

注1：防火墙中的安全域可以简单理解一个命名的若干物理网络接口的集合。服务端口集合也叫服务，除了TCP，UDP端口，还可以包括其他协议，比如ICMP。简单起见，这里只涉及TCP，UDP端口。

其中，源地址集合，目的地址集合，端口集合是组成一个策略的三个关键元素。在防火墙策略中，描述网络地址的形式可以是网络地址+掩码，一段起止地址范围，也可以是域名。

地址也可以以地址对象的形式出现。一个命名地址对象是若干个上述地址形式的集合，可以代表一组地址。同样地，一个命名服务对象是若干TCP，UDP端口范围的集合，表示一组服务端口。在定义策略时，网络地址可以直接在策略中使用，也可以将一组地址定义为一个地址对象后在策略中引用。服务必须先定义为一个服务对象后才能在策略中引用。

注2：不同防火墙品牌在定义策略时地址和服务端口使用规定也不尽相同。另外，不同防火墙在单条策略中允许出现的地址条目数量，服务条目数量也不同。使用时请查询使用手册，这里不展开讨论。

如何在防火墙上配置一条这样的策略呢？以山石网科防火墙命令行方式为例（下同），分为以下几个步骤：

（1）定义端口对象

（2）定义地址对象（如需要）

（3）定义策略

注3 策略中地址条目比较少的话，可以直接使用地址定义，不用单独定义地址对象。如果地址过多且不连续，或地址信息中包含有域名条目，需要定义地址对象。

另外，要考虑的问题如下：

（1）防火墙上已经存在了一条这样的策略吗？或已经存在了一条包含了这条新增策略访问关系的策略吗？如是，则这条策略无需再配置了；

（2）新开策略，端口对象存在吗？如是，则可以直接在新策略中引用；否则新定义一个命名端口对象；

（3）如需定义地址对象，现有配置中存在吗？如是，则可以直接在新策略中应用；否则新定义一个命名地址对象；

（4）上述步骤（2）或（3）中，如果不存在相等的对象，是否存在2个或几个已有对象，他们的并集等于新增对象呢？如有也可以直接拿来使用；

注4：在配置新策略时，之所以尽量引用防火墙中已有配置的地址和端口对象，不新增加配置项，一是可以减少配置文件大小，二是出于提高设备运行性能考虑。因为在配置文件中的地址或端口对象，运行时最终都要加载到内存中的。

2.2.2 配置文件分析

由前面的分析可以知道，掌握防火墙现有的配置信息，是高效配置安全策略的基础。我们采用下载设备当前配置文件的方式，对整个配置文件逐行进行分析，解析出设备中现有配置的各种对象、策略等重要配置信息保存，为后续的策略生成决策提供数据分析依据。

配置文件的分析的过程其实就是文本处理，比如在配置文件中，一条完整的策略配置信息如下：

每行的的组成由关键字+配置参数组成。一般情况下，关键字都在行的开头。因此，可以根据判断关键字的结果，从配置文件中分析出一条完整的策略信息。上面的例子中，一条策略的开始由“rule id 2305”这一行开始，后续的行为该条策略的其它配置信息，直到“exit”结束。

以此类推，可以从配置文件中解析出已定义的地址对象和服务对象等关键配置信息，保存备用。

2.3 生成策略配置命令序列

有了设备当前配置信息，后面的策略配置命令生成就容易多了。这里我们仍以配置一条策略最重要的三个元素为例，说明如何产生对应命令序列。

在生成配置命令序列之前，需要做的一个重要步骤是，在当前已配置策略中进行查找比对，确定是否已经存在策略，包含或等于本次新增的策略。另外还可以查找新增策略是否和当前策略中有可以合并的策略，如有，则建议合并以减少设备中策略数量。查找当前策略和新增策略进行比较的算法略显复杂，这里就不再展开叙述了，下面讲述新增策略的脚本生成步骤。

（1）源地址和目的地址

在一条策略中，如果源地址有10个，分别是172.0.5.1--172.0.5.10，那么，在策略配置命令中，可以是这样的单个地址分列的形式：

也可以是地址范围的形式：

还可以是先定义地址对象，再在策略中引用的形式：

单条策略中定义源地址语句有数量限制，一般为8,16或32个。而一个地址对象中可定义的地址语句则可以多于256个。因此，当地址经过合并处理，比如，连续地址用一个网段表示，或用一段地址范围表示，使得在策略中可以用几个语句定义完成的，在策略中直接定义即可；否则，定义一个地址对对象，然后在策略中引用。

在定义地址对象时，应充分利用当前配置中的地址对象。如有完全相同的，则直接引用，无需再定义的地址对象；如无，则应查找是否有几个当前的地址对象合并后等于现有的地址集合，如有，直接在策略中引用这几个地址对象。更甚一步，如果可以找到有限几个地址对象的并集，接近新增地址集合，只要在策略中定义地址语句不超过数量限制，就可以在先引用这几个地址对象，然后再将未被包含的新增地址集合中的地址，使用单独的地址定义语句添加进去即可。如此劳力费神操作，目的还是遵循这样一个重要原则：新增策略配置尽量少在设备中增加新的配置元素。

目的地址的处理和源地址处理过程完全相同，只不过在对应配置语句中，将关键字"src"全部替换为"dst"即可。

（2） 服务

简单起见，服务只考虑TCP、UDP端口。和地址不同的是，在策略配置中，服务必须要先配置为一个服务对象，然后才能在策略配置中引用。且策略配置中服务的关键字只有一种，就是“service”，后跟已经定义的服务对象。

同样定义服务对象也应该采用和定义地址对象相同的算法，尽量利用当前配置中已有配置项，减少新增配置项。例如，当前配置文件中有如下服务对象配置：

假定本次新增的服务又恰好只有TCP 7700和 9016两个端口，那么在策略定义中就可以直接使用如下定义:

最后，分别将三部分命令序列组合起来，加上其它固定部分，比如源和目的安全域，按顺序组合到一起，形成一个完成个策略配置命令序列。至此，一条防火墙策略的完整配置脚本就生成了。

三、项目实施成果

安信证券网络自动化运维系统于2019年9月份立项建设，2020年1月份上线试运行。项目一期的主要目标，是实现公司“两地三中心”网络中(包括运营商IDC托管机房)近30台物理防火墙日常用运维中策略开通工作的自动化配置处理。

3.1、系统主要功能

根据申请信息中的源，目的地址判断相关主机所处的安全域，进而找出正确的访问路径，找出路径中的防火墙，最终确定需要在哪些防火墙上配置策略。

根据防火墙现有配置信息，判断新增策略是否已经存在或被包含，如是则忽略该条策略。

根据防火墙现有配置信息，判断新增策略是否可以和已存在策略合并。

根据防火墙现有配置信息，判断新增策略是否可以利用已经存在的端口，地址条目等配置信息，减少新增配置信息。

判断自否需要做地址转换，如需要，则根据地址转换规律生成地址转换命令序列。

每天生成一个配置脚本文件，永久保存。

策略下发完毕，生成配置反馈文件，记录实际配置结果，永久保存。

3.2系统架构及处理流程

系统架构如图3所示。

图3 系统架构

整个系统由策略信息录入服务器、数据库和处理机组成。逻辑功能上分为两部分，一是完成申请人通过Web页面提交策略参数信息，二是后台策略数据处理部分。

Web服务器为用户提供登录认证、策略参数录入页面。录入数据在前端进行合法性检查后，保存到数据库。事务处理机在指定时间内处理录入数据，产生配置脚本，然后下发到目标设备。

申请流程需要通过ITIL系统发起，Web服务器和ITIL系统做了接口对接，跟踪申请流程在ITIL系统中的审批状态。审批通过后的流程，相关信息被保存到待执行表中。

另外，系统提供了一些附加功能：策略查询功能，路径查询功能，内外网映射查询等。

3.3 主要功能展示

3.3.1 策略信息录入功能

策略信息输入界面如图4所示。申请人通过输入界面，将流程需要开通的策略，逐一输入。同时，为提高输入效率，还提供了已输入策略的复制编辑功能。申请人也可以在历史申请流程中选择一个进行完整复制，然后再编辑提交。

信息录入指定了单个地址，地址段，地址+掩码以及域名等形式限制，否则在添加策略时会给出错误提示。另外，在策略录入完成后提交流程时，会对每条策略进行初步检查。比如不能访问互联网的主机在策略中申请访问互联网，源和目的主机位于同一安全域内（不需要开放防火墙）等。

图4 策略信息录入界面

3.3.2 对象定义功能

对象定义功能见图5。系统管理员可以预先定义一些面对全体用户的，常用的大地址段，比如“XX办公网”“XX数据库集群”“XX负载均衡组”等。这些地址可能经常在策略中被引用，且包含的地址多而分散。定义好地址对象之后，就可以直接在策略申请输入信息时使用。用户也可以预先定义一些私有的地址对象，仅供自己使用。

除了地址对象，系统还支持端口对象定义。

图5 对象定义

3.3.3 拓扑图及查询功能

拓扑图及查询功能见图6.这里的拓扑并非传统意义上的网络拓扑图，更确切地，应该称其为防火墙部署图。图中每个节点代表一个网络安全域。连接两个节点之间的连线，如果有防火墙，则两个节点之间的主机相互访问，就需要处理防火墙策略。如果连线上没有防火墙，说明两个节点之间的安全等级相同，可以视为同一个安全域。

基于这个基本拓扑，可以实现一些查询功能。比如某台主机所处的安全域？某台主机是否可以访问互联网？某台主机访问另外一台主机，是否经过防火墙？是否存在对应的策略？等等。

图6 拓扑图及查询

3.3.4 流程处理功能

流程处理，暂时采用在指定时间段手动触发方式。点击“开始处理”后，由后台处理机启动处理程序，对数据库待执行表中的策略逐条读出，分析处理，生成对应的脚本文件，并在窗口中展示出来。图7是一个系统实际生成的脚本配置文件的一部分。

可以看到在图中框内，自动化系统搜索到一条已经存在的策略，包含了本次要新增的策略，结果将忽略该条策略的后续处理。

图7 配置脚本生成

运维人员可以检查脚本的正确性，如有错误，在窗口直接进行编辑修改后，保存提交，点击“执行”，则后台处理机启动下发进程，远程连接防火墙设备，逐条提交配置命令。图8是配置下发完成后，记录的结果文件内容中一部分。

图8 脚本下发记录文件

下发过程采用多线程处理方式，每个需要配置的防火墙启动一个线程，这样，下发策略需要时间最长的设备，即为本次下发操作耗费的时间。

四、结语

本系统从功能上模拟了人工处理防火墙策略开通流程的整个过程，实现了自动化、智能化处理策略配置。自动化比人工处理优势明显：可自动在成千上万条策略中查找是否有包含新增策略、自动查找需要当前配置中是否已存在地址和服务对象、高效发布变更至防火墙设备、大幅降低人工操作出差概率等。由于这段时间我司数据中心机房处于搬迁阶段，新、旧两个机房共存，不仅策略开通量大增，而且网络拓扑变化频繁，自动化系统很好地应对了这种复杂环境，运行平稳。

网络运维自动化系统自2020年1月份投入试运行，至今共处理申请流程近4000条。其中，每条流程包含访问权限开通申请平均2.2条，剔除已有包含策略，实际产生并下发到防火墙的具体访问策略条目接近8000条。自动化系统每天处理策略，下发配置脚本耗费时间控制在1分钟左右，差错率控制在1%以下。

后期，将不断增补其它网络设备的自动化配置功能，例如负载均衡设备的自动化配置、交换机和路由器等网络基础设备的日常运维自动化配置等，实现大部分日常运维工作内容自动化处理。