随着互联网技术的不断发展，在线网站的规模越来越大，防火墙作为网站的安全屏障，被大量的使用。防火墙数量的增加以及防火墙中安全策略条目的增加，安全工程师的运维工作量成倍的增长，应用交付往往要求防火墙策略能快速设置。用传统的人工方式运维大量的防火墙策略已经变得非常困难。

本文会介绍携程网络安全运维如何通过自动化方式，在防火墙数量达到几十台，策略条目庞大、多品牌的情况下，对防火墙策略进行集中式统一化的管理，提升用户查询、申请策略体验，优化申批流程，系统自动化配置防火墙策略，提升安全工程师效率的同时降低人工出错概率。

防火墙运维之痛

防火墙运维之痛，这种叫法有点落俗套，可事实上运维的确是痛的，我们经常在很多场合以会看到这样的说法，比如IT运维之痛，机房管理之痛，网络管理之痛，所以痛在运维这个行业是一个正常的存在，我们都知道，运维通常要经历人工阶段到自动化阶段，再到智能阶段这三个过程。当人工阶段处理的事务遇到严重挑战，就会痛苦，不痛苦就没有改变。所以痛也不见得是坏事。

我们在建设基础的安全架构的时候，通常有两种选择，一种是单一品牌的防火墙，或者选择多品牌的防火墙的架构。携程由于一些历史的原因，我们在现网使用的就有5个品牌。据相关调查数据显示，企业网使用多品牌防火墙是一种普遍情况。比如银行业有防火墙异构的合规要求，一些金融企业也会参照这个标准。不同品牌的防火墙提供不同的功能特性。比如在OA出口，你想看到并拦截应用层的安全威胁。就会选择NGFW(Next generation firewall即下一代防火墙)，数据中心可能会选大吞吐量的墙来满足数据转发的需求。不同时期、商务因素等这样一些原因，导致我们使用了不同品牌的防火墙来满足安全隔离的要求。

这张拓扑图展示的一些较大规模互联网公司或企业典型的防火墙部署示意图，体现了边界防护、重要业务系统隔离保护、办公与生产隔离的一些保护需求。据我了解使用几台到几十台防火墙服务器的企业有很多，也有一些大型集团公司或跨国公司的防火墙集群规模达到数百台。面对这么大规模的防火墙，要把它管理好是个难度是很大的问题。有些厂商称，用户企业可以使用他们的防火墙集中管理系统帮助降低运维复杂度；但是当告诉他我们有好几个品牌的墙时，对不起，这种情况他的系统管不了，他的方案只能管理自家的墙。。诚然，有商用产品可以实现不同品牌防火墙策略集中管理，但是产品会按license 算钱，不仅价格昂贵，而且方案不灵活，不能实现个性化的需求。在这种多品牌，多数量的情况下，防火墙系统的运维难度和挑战将变得非常的大。

现在看看运维层面实际遇到的问题，用户经常会提出这样的问题，我访问某个资源不通，是不是被墙拦截了？访问lab 环境有没有墙呀？测试访问生产是违规的，需要特别审批，找谁去审批呢？而防火墙安全工程师呢要一遍遍解答用户的疑问，不断与用户沟通。同时要人工审核策略需求，编写防火墙配置工艺，在变更窗口登录到防火墙设备下发配置，不断重复这个过程。我们都知道，现有安全工程师很难招，而且都很贵，招来做大量重复性工作，对安全工程师本身的成长是不利的。还有一个显著的缺点就是人工处理的速度慢。互联网企业业务需求变化快就要求防火墙策略能够随需而变快速部署。在这种情况下，低效的工作已经不能满足实际的业务要求，因此我们提出自己的运维目标：透明、规范、自动化、高效。

防火墙运维管理系统

为了实现透明、规范、自动化、高效的防火墙运维目标，我们设计了这样一个架构，最底层是每台防火墙设备，通过API接口与系统连接，配置备份系统，每小时对全网防火墙自动进行一次配置备份，当然可以针对不同实时性要求级别来调整备份间隔。比如AD会新增入职员工域帐号，也会按需新建一些邮件组，这些信息多久同步到防火墙上呢，看需求。路由解析和和配置解析两个模块处理配置文件，并将元数据（5元组+路由表）存入统一模型数据库。

最核心的基础工作就完成了，在此之上设计一些功能模块，路径查询解决拓扑计算问题，策略查询允许用户自助查询两点间防火墙策略，策略合并和生成模块是自动生成策略配置工艺。策略自动下发实现工艺下发设备，再上一层是API，这些功能模块都是通过API方式调用的，最外层是统一web portal 入口，提供给用户查询或申请防火墙策略，跟踪进度等。还有一些小工具我们也集成进入管理系统，比如设备密码修改、VPN管理。最右上角，可以通过系统API与其他系统共享数据。

这张图展示的是，我们自主开发的防火墙运维管理系统的组成，简单来说它有三个模块，拓扑计算、策略查询和策略生成三个模块，工单对接指的是一套流程，其他的模块其实指的是一些有用的工具。

那我简要的说一下这些模块实现的功能，拓扑计算做什么事情？通过路由计算的方法形成一个拓扑，这个拓扑指的是，访问的两点之间跨越了哪些墙，然后在策略查询上它完成两件事情，第一件事情就说提供给用户可以自主的去查询策略。第二件事情，用户在申请策略的时候，我们后台会帮他自动做一个查询动作，看是不是已经有策略了，如果有策略会返回一个消息告诉说：有策略了，你不需要申请，直接去测试就可以了，这样可以节省大家的时间。策略生成这个模块，它是针对不同品牌的墙去编写防火墙的配置工艺，比如说我们都知道思科、PaloAlto、Fortigate这些品牌的墙，每个策略工艺都不一样，我们需要去解决这些问题。

工单对接的重点在于流程的解决，这里包含三个问题：第一个是我们与现有的企业网内的变更管理系统，或者是工单系统对接；第二要解决的问题是，我们设计一个用户从提出申请到自动化完成一个策略配置，再告诉用户需求完成一个完整的一条龙服务；第三个就是一些特殊权限的审批，如果遇到特殊权限，原来都是发邮件审批，非常低效，现在我们通过一个特殊审批的模块解决这个问题，我们设计了规则，比如说要访问数据库的防火墙权限，要找谁审批。如果要测试环境访问生产环境的违规访问，要做特例审批，我们都定好规则。当用户的输入条件匹配了这些规则会自动发邮件给审批人，通过URL链接进行审批，然后就会往下面的流程去走。

还有一些其他功能模块，如改密码模块，VPN隧道管理模块，防火墙元素查询模块等。我们要维护数百条的VPN隧道，如果人工的方式一条一条去添加效率非常的低，防火墙运维系统开放接口，允许我们通过导入Excel表格的方式，一次可以添加一批隧道效率大幅提升。

三个核心模块的实现原理

接下来详细介绍一下三个核心模块的实现原理：自动化拓扑计算、自动化策略查询、自动化策略工艺生成下发。

拓扑计算要解决的问题是知道两点之间的访问经过哪几台墙。通常的做法是这样的，安全工程师根据经验模糊判断两点之间的访问经过哪几台防火墙，再加人工查询、验证，有时拿不准需要看防火墙Log，看是不是有deny日志。存在的问题就是在防火墙数量较多的情况下，安全工程师往往难以判断两个IP是否经过墙或经过哪几台墙，费时费力，效率低下，判断可能产生差错。

因此，我推荐自动化拓扑计算方法来解决，确定源访问到目标经过哪几台防火墙的问题。拓扑计算有三个环节：路由匹配、接口比较、生成拓扑。首先在防火墙进行路由匹配 （最长路由匹配，掩码中的1最多）也叫精确匹配，如果匹配到则转到下个过程接口比较，否则继续查询其他防火墙。接口比较（图中b环节），这个过程是判断出路由经过防火墙的接口或zone。如果判断源、目的接口或zone 相同，就需要把该防火墙从拓扑中删除。实际上就是不经过这台墙。匹配到将相应的防火墙添加到拓扑中。如果所有防火墙都被遍历，则进入到c过程可以输入防火墙拓扑。否则转到a 进行下次循环。

策略查询普遍做法仍是基于经验判断，经验丰富的工程师可以快速定位到墙和策略，不熟悉的操作人员可能要逐台查询多台防火墙才能找到对应的策略，安全策略在不断的增，当策略数目多到几千条时，查询工作将变得困难，在跨多IDC，跨多墙的环境下，比较难搞不清楚用户提出的策略申请到底有没有策略支持。带来的缺点就是工作效率低下，可能漏查。

自动化策略查询的实现，查询的输入条件包括源、目标、目标端口，协议4个元素，通过拓扑计算已经知道目标落在哪台墙上，因此查找目的的动作直接在目标墙上进行，范围缩小，查询速度很快。在程序处理上是按这个逻辑处理的。首先匹配目标，找到目标接着匹配目标协议和端口，也找到了，再匹配源，如果源也找到了。则记录查询结果，注意此时还没有结束，还需要继续在剩余的策略中查询，所有策略都匹配完，统一输出结果。通过这样几个步骤，根据用户的查询条件，就能秒级返回结果，是有策略放行还是该访问被防火墙拦截，一目了然。

防火墙配置工艺编写的传统做法，根据不同品牌，有些墙只能图形界面配置，有些墙可以图形可以命令行，安全工程师会针对不同品牌墙，根据自己熟悉的方式编写配置工艺，在变更窗口登录防火墙完成配置，从变更申请到工艺编写再到登录设备配置，整个过程平均耗时在30分钟以上。人工处理的方式缺点也很明显，人工操作时间加上变更窗口时间限制，用户的等待时间有数小时之久，用户满意度差。人工操作还有一个不好的地方，会发生人为差错的可能性。

自动化生成策略工艺并下发设备的实现。第一个过程首先是判断拓扑中涉及的防火墙，对它的策略操作是不添加、新建还是修改。然后会有2种情况，如果策略生成动作为新建策略，则按需生成新建策略的工艺，生成的方法是按防火墙的API格式或是CLI命令行格式生成。第二种情况，如果判断策略生成动作是修改策略，那么在生成策略工艺时，就需要处理对原策略的修改，可能需要调整策略顺序等操作。完成策略工艺生成过程，这里会对工艺做人工审核，后面后进到。到达变更窗口时间，自动把配置下发到防火墙设备。完成策略变更。

一套流程的优化

之前的内容解决了技术层面的问题，接下来看看流程方面的优化。

首先用户使用统一提供的申请portal，然后后台根据用户申请策略需求进行自动判断，。如果有策略，返回消息，用户自行测试通过就结束了；如果后台判断没有策略支持，生成策略清单，可能是一条或多条策略需求；如果是常规申请，会直接提交成功；如果提供的策略需要特别审批，比如申请测试环境访问生产，一定是特例申批。

我们有一个审批管理模块解决这个问题，程序判断如果提出的策略属于特殊申请的，会自动给审批人发邮件说明申请理由，审批人点开链接点通过或拒绝进行审批，通过后完成申请提交。在安全工程师这条线上，申请提交后会进入自动化的防火墙管理系统开始自动生成工艺，安全工程师人工审核工艺，必须要安全工程师人工审核。

上生产前二次检查，就是为了避免由于系统设计可能存在的疏漏，生成与预期不一致的变更工艺，带来对生产业务的影响，我们要防止这种错误的产生。增加人工把关环节。审核通过后等待变更窗口，到达变更窗口时间，自动执行变更。也是自动下发策略的过程。完成一次策略申请到人工审核再到自动下发设备的整个过程。通过自动化策略配置的实现，策略维护花费的时间大大减少，现在做一个变更，平均花费3分钟左右，比原来30多分钟有10倍的提升。

对接工单系统，自动化对接工单或变更系统。自动化与流程两者存在鲜明的冲突：自动化追求的是速度、效率，而流程希望你慢下来。不过最本质的要求是把事情做正确。

前几天参加另一个安全的会议，刚好是携程528事件过去一周年不久，遇到一些与会嘉宾旧事重提，就问我到底是什么原因导致网站瘫痪12小时。对于这次事件，网上的猜测各种版本，数据删除说、员工报复说、网站被黑说。

在这里说明一下，真正的原因就是由于员工错误操作，误删除了生产服务器上的执行代码导致。虽然流程不能完全规避掉像528这样的事故，但是它会帮助我们降低发生事故的概率。因此在携程的最佳实践就是自动化系统与变更工单系统对接。打通，使二者结合作用。在流程框架的规定下进行自动化。

具体是这样一个过程：策略申请，策略配置请求单生成进程会创建请求单，并返回单号。第一个步骤是等待审批，这个角色通过是安全工程师的leader, 授权该申请。到变更窗口时间，程序修改状态为“处理中”，此时工单进行会创建一个变更单，前面的是请求单，二者有区别，不要混淆。生成好变更单后是等执行状态，会自动发消息给NOC，说某某同事因什么需求，需要在某某设备上执行策略变更。NOC接受工单后，状态修改为已接受、并且获取请求单对应的变更单。当程序将变更单状态修改为执行中时，程序同步自动化登录到相应的防火墙设备执行策略下发操作。然后程序将请求单和变更单状态分先后置为已完成。整个流程部分就完成了。

总结

简单总结一下分享的内容：三个核心模块，拓扑计算，策略查询和策略工艺生成；一套流程，解决用户一条龙的服务，以及与我们的变更管理和配置管理系统的工单对接，一些工具用来提升我们的效率。上述这些共同构成了我们的防火墙自动化运维系统，通过这套系统的自动化方式，帮助我们轻松运维几十台防火墙服务器，在不断提高工作效益的同时，也降低了人工出现差错的一些概率。