2016年6月30日-7月1日，万众瞩目的GITC全球互联网技术大会将走进上海，在上海宝华万豪隆重举行。 GITC2016上海站将始终以汇聚行业精英、促进技术交流、加深商务合作、推动行业发展为大会宗旨，持续聚焦互联网领域的最新技术成果和未来发展趋势，就云、运维、大数据等技术热门话题进行主题、专题演讲，分享互联网的核心、尖端技术。 此次大会还特别增设了“互联网+”论坛、VR体验特展，技术&产品秀等一系列特色专场，给参会者带来更多直观的互动体验，打造更专业、有趣的技术交流分享及商务合作的平台。

随着互联网技术的不断发展，在线网站的规模越来越大，防火墙作为网站的安全屏障，被大量的使用。防火墙数量的增加以及防火墙中安全策略条目的增加，安全工程师的运维工作量成倍的增长，应用交付往往要求防火墙策略能快速设置。用传统的人工方式运维大量的防火墙策略已经变得非常困难。 本次分享将会介绍携程网络安全运维如何通过自动化方式，在防火墙数量达到几十台，策略条目庞大、多品牌的情况下，对防火墙策略进行集中式统一化的管理，提升用户查询、申请策略体验，优化申批流程，系统自动化配置防火墙策略，提升安全工程师效率的同时降低人工出错概率。

我给大家带来的议题是“防火墙自动化运维”。首先做下自我介绍，我是田国华，来自携程网络安全部。2010年加入携程，最近6年多一直从事网络安全架构规划以及安全系统运维相关的工作。之前在绿盟、安氏2家国内乙方安全公司工作多年，下面在座的也有我原来的老同事。接下来40分钟，我给大家介绍一下，我们在携程做防火墙自动化运维上的一些尝试。和大家分享一下过程中遇到困难、解决思路。



简单介绍一下东家，携程旅行网创立于1999年，总部设在上海，员工3万余人。Ctrip于2003年在美国纳斯达克成功上市。携程向超过2.5亿注册会员提供包括酒店、机票、旅游度假、商旅管理及攻略社区在内的全方位旅行服务。今日的携程在在线旅行服务市场居领先地位，已成为全球市值前三的在线旅行服务公司。

议题通过以下三个方面进行介绍，第一个方面，防火墙运维之痛，主要介绍一下我们做防火墙自动化运维的一个背景。接下来会通过系统的架构、核心模块，以及流程对接三块内容来介绍一下我们的防火墙运维管理系统。那防火墙自动化运维之后，我们下一步打算做什么，我们看一下未来的一个展望。

防火墙运维之痛，这种叫法有点落俗套，可事实上运维的确是痛的，我们经常在很多场合以及在PPT的开篇，会看到这样的说法，比如IT运维之痛，机房管理之痛，网络管理之痛，所以痛在运维这个行业是一个正常的存在，我们都知道，运维通常要经历人工阶段到自动化阶段，再到智能阶段这三个过程。那么是不是有更高级的一些方式，目前尚不清楚。但是大家可以关注一下今天或明天的议题，看是不是有公司已经取得了这方面的突破。当人工阶段处理的事务遇到严重挑战，就会痛苦，不痛苦就没有改变。所以痛也不见得是坏事。



我们在建设基础的安全架构的时候，通常有两种选择，一种是单一品牌的防火墙，或者选择多品牌的防火墙的架构。我想在现场做一个小的调查，企业或单位里，只使用一种品牌防火墙的请举下手。人不算太多。看来不少企业都在多品牌的阵营，防火墙品牌太多了，这里只是列举一部分作下示意。更多的国内外品牌，都没有列出来。企业网内或单位里使用3种以上防火墙的请举一下手，挺多人了。携程比这个还要多，由于一些历史的原因，我们在现网使用的就有5个品牌。



从这个调查的结果可以得到一个结论，企业网使用多品牌防火墙是一种普遍情况。比如银行业有防火墙异构的合规要求，一些金融企业也会参照这个标准。不同品牌的防火墙提供不同的功能特性。比如在OA出口，你想看到并拦截应用层的安全威胁，也可能需要实现基于用户身份的访问控制。就会选择NGFW，数据中心可能会选大吞吐量的墙来满足数据转发的需求。不同时期、商务因素等这样一些原因，导致我们使用了不同品牌的防火墙来满足安全隔离的要求。

防火墙运维的第二个痛点来自于数量的增加，随着互联网技术的不断发展，在线网站的规模越来越大，防火墙作为网络的安全屏障在广泛使用，其数量也在相应的增加。这张拓扑图展示的一些较大规模互联网公司或企业典型的防火墙部署示意图，体现了边界防护、重要业务系统隔离保护、办公与生产隔离的一些保护需求。



据我了解使用几台到几十台的企业有很多，也有一些大型集团公司或跨国公司使用数百台防火墙。面对这么多防火墙，要把它管理好，难度是很大的。有些厂商就说了，你可以使用我们的防火墙集中管理系统帮助降低运维复杂度，当告诉他我们有好几个品牌的墙，对不起，他的系统管不了。只能管自家的墙。有商用产品可以实现不同品牌防火墙策略集中管理，但是按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分钟以上。



人工处理的方式缺点也很明显，人工操作时间加上变更窗口时间限制，用户的等待时间有数小时之久，用户满意度差。人工操作还有一个不好的地方，会发生工为差错，曾经发生过一次，我们知道用命令行编写配置工艺，最快的方法就是copy rule .然后做下修改，而这位工程师一时大意，没有修改策略ID， 复制过来什么样，改好还什么样。直接下发设备。由于 策略ID相同，就把正在使用的策略覆盖掉了。造成业务影响。

自动化生成策略工艺并下发设备的实现。第一个过程首先是判断拓扑中涉及的防火墙，对它的策略操作是不添加、新建还是修改。然后会有2种情况，如果策略生成动作为新建策略，则按需生成新建策略的工艺，生成的方法是按防火墙的API格式或是CLI命令行格式生成。



第二种情况，如果判断策略生成动作是修改策略，那么在生成策略工艺时，就需要处理对原策略的修改，可能需要调整策略顺序等操作。完成策略工艺生成过程，这里会对工艺做人工审核，后面后进到。到达变更窗口时间，自动把配置下发到防火墙设备。完成策略变更。

之前的内容解决了技术层面的问题，接下来看看流程方面的优化。对于用户来说，我们提供统一的申请portal，用户申请策略需求，后台自动判断，如果有策略，返回消息，用户自行测试通过就结束了。如果后台判断没有策略支持，生成策略清单，可能是1条或多条策略需求，如果是常规申请，会直接提交成功，如果提供的策略需要特别审批，比如申请测试环境访问生产，一定是特例申批。



我们有一个审批管理模块解决这个问题，程序判断如果提出的策略属于特殊申请的，会自动给审批人发邮件说明申请理由，审批人点开链接点通过或拒绝进行审批，通过后完成申请提交。在安全工程师这条线上，申请提交后会进入自动化的防火墙管理系统开始自动生成工艺，安全工程师人工审核工艺，必须要安全工程师人工审核。上生产前二次检查，就是为了避免由于系统设计可能存在的疏漏，生成与预期不一致的变更工艺，带来对生产业务的影响，我们要防止这种错误的产生。增加人工把关环节。



审核通过后等待变更窗口，到达变更窗口时间，自动执行变更。也是自动下发策略的过程。完成一次策略申请到人工审核再到自动下发设备的整个过程。通过自动化策略配置的实现，策略维护花费的时间大大减少，现在做一个变更，平均花费3分钟左右，比原来30多分钟有10倍的提升。

对接工单系统，自动化对接工单或变更系统，虽然自动化与流程之间有很多的冲突，因为自动化追求的是速度，效率，而流程希望你慢下来。要求把事情做正确。



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



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



具体是这样一个过程，策略申请，策略配置请求单生成进程会创建请求单，并返回单号，第一个步骤是等待审批，这个角色通过是安全工程师的leader, 授权该申请。到变更窗口时间，程序修改状态为“处理中”，此时工单进行会创建一个变更单，前面的是请求单，二者有区别，不要混淆。



生成好变更单后是等执行状态，会自动发消息给NOC，说某某同事因什么需求，需要在某某设备上执行策略变更。NOC接受工单后，状态修改为已接受、并且获取请求单对应的变更单。当程序将变更单状态修改为执行中时，程序同步自动化登录到相应的防火墙设备执行策略下发操作。然后程序将请求单和变更单状态分先后置为已完成。整个流程部分就完成了。

前面说的都是我们一些实现原理，接下来我们看一下防火墙运维管理系统的实际界面，到底长什么样子，这里是一些实用的功能，比如策略申请，策略查询，然后这些是VPN管理的一些模块，这些是安全工程师最常用的功能，比如说一些墙元素的查询，全局申请是提供查看总共有多少个申请策略，他们申请的原因是什么，过去的审批都有完整的记录，审批关系的维护，历史变更，到底做了多少个变更，通过自动化完成的，全局参数配置。



这些模块呢，会通过SSO的权限区分，不同的人看到不同的界面，这个是一个策略申请的界面，这里面我们会告诉用户一个预期时间，你在不同的时间段申请的一个策略请求，在什么时间段可以完成掉，用户有预期他就不会来催单。接下来是申请的理由，你需要什么时间来完成，然后这个策略是一个临时策略还是长期的，接下来就是策略的一些基本的元组，最后提交就可以了。这就是我们自动化的一些实践。

接下来我们介绍一下，未来我们考虑自动化之后做什么？我们接下来会考虑实现以应用为基础的防火墙策略的模型，那我们以简单的三个应用组来举例，比如说web服务组，APP服务组和DB服务组，它们各自都开放了一些端口，由授权的系统来访问，那么他们的这个访问关系，我们可以把它抽象出来，我们把它定义为应用策略配置文件，把它定义好之后，当服务器上线或者下线的时候，它会传递过来参数，只需要看它传递过来的是一个什么样的应用标签。



如果它传递过来的参数是说我要上线50台web应用服务器，调用防火墙自动化系统接口，登录到相应的防火墙上，把这50台机器的策略配置就可以了。如果是下线也是同样的做法，我们只看这个应用标签，不再基于IP去看。

这样做的一些好处，首先，安全策略，原来的颗粒度是以IP为颗粒度的，接下来我的颗粒度变成了应用，然后配置会更加的高效智能，速度会更快，人工介入更少。然后这样一个方式呢，策略更加易于维护和管理，统一的模型，与你使用何种品牌的防火墙无关，我们会采用通用的API适配的方式对接任何品牌的防火墙。

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