安全网关运维中的一声感叹

■ 四川 赖文书

编者按： 安全网关的正常运行关系到单位的网络安全状况，在近期单位网络运维中，安全网关却出现了一系列莫名故障，很多情况是与相关厂家有关的，连续几次故障事件中，笔者单位的日常巡检还帮助厂商发现他们不应该出现的问题。

为保障信息系统稳定对外提供服务，防御来自互联网的各种安全威胁，公司在IDC机房的互联网出口部署了2台太一星辰的MSG多业务融合安全网关，构建了主备高可用集群。该设备适用于传统大中型网络边界、云数据中心、SDN及其他新业务环境的新一代应用网络虚拟化平台产品。实现了软硬件解耦合、弹性资源管理业务功能软件定义等特性。

融合安全网关主要由以下五个部分组成：高性能交换矩阵T-xSwitch，虚机管理T-vBOS系统，标准虚拟化网元层T-xVNF，业务编排T-vOSS、T-vAPI。我们所使用的T-Force 12000-MSG拥有240GPS吞吐量，包含ADC（应用交付控制）、NGFW（下一代防火墙）、WAG(Web应用网关)、入侵防御、防病毒、流控等网元，这些网元就是以KVM（Kernel Virtual Machine内核虚拟机，Linux的一种虚拟化技术）运行的虚机。其运行机制是通过Service-Chain服务链让流量按照预定策略，依次通过多个虚拟化网元所经过的轨迹，每个虚拟化网元在数据流量通过时，进行相应的安全检测，防御，流量优化，整形以及其他更高层协议的处理。我们的安全网关一直运行正常，近几个月运维管理中遇到如下故障。

一、入侵防护特征库更新失败，添加更新服务器的访问规则

我们的融合网关的入侵防护特征库更新，在系统里配置为在每晚凌晨1点自动进行。平日的观察中发现厂家会在一周左右的时间，根据互联网安全预警进行特征库的更新。连续几周观察更新情况，更新日期都没变动，通过手动在管理页面操作“立即升级”，显示“升级信息已下发成功”，但是特征库始终定格在1个月前。只能及时联系厂商咨询其入侵防护特征库是否在正常更新，厂商给出了特征库更新情况查询网址https://www.venustech.com.cn/article/type/1/141.html，在页面上确认“USG产品入侵防御特征库-适用T系列”都正常发布了更新。可为什么我们的设备更新却停止了呢？

只得请厂商工程师远程对设备进行检查，登录后台的NGFW网元ping互联网的DNS地址114.114.114.114确认正常，也能正常解析域名。再以命令“debug u p d a t e”，“t e r m i n a l monitor”，开启后台对特征库升级的调试模式，在管理页面操作“立即升级”，后台返回与升级服务器的网络异常，最后ping特征库升级服务器测试不通。自动升级问题就定位到网络连通性上，工程师尝试停用了我们做的对恶意访问地址组限制的规则，再测试其连通性仍然失败。

经过多处配置的检查均没有可调试的地方，只能在NGFW管理页面新建了一条访问规则，允许any访问特征库更新服务器202.85.219.10的任何服务。再测试其连通性居然通了，手动点击管理页面上的“立即升级”，特征库终于赶上更新的步伐如图1所示。

经过上述操作确实解决了此次问题，但是为什么一直都正常的入侵防护特征库自动更，忽然NGFW网元就无法与升级服务器网络不通了？难道真是我们在添加安全防护策略时被意外阻止了？

经过对IP地址对象的检查，和防护策略的逐条确认，未能找到故障根源。感觉此问题甚为蹊跷，真不知道是否厂商在设备后台系统的某些变化引发故障？

图1 设备入侵防护特征库更新

图2 厂家发布的特征库升级包

二、入侵防护特征库再次更新失败，厂商的更新服务器故障

自从上次厂商帮忙处理融合网关的入侵防护特征库更新，升级到2019年1月18日后，很快就进入春节假期。正常上班后在日常巡检中也都留意设备的更新情况，怎么这特征库又停止不前了？去官网确认更新情况步调一致，这次就不怀疑我们设备问题了。看来这入侵防护特征更新是厂商的安全人员还在研究中，春节过后大家都还没进入正工作状态，完全可以理解。可是等到元宵节（2月19日）都过了，发现病毒防护特征库、应用分类特征库、URL分类特征库都已经更新到2月21日，同时发现官网也已经发布了2月22日的更新如图2所示，而我们设备入侵防护特征库更新好像还在放假中没有反应。

只得再次通过400电话联系厂家，深入诊断问题的原因。厂商工程师远程检查了一番，没有找到可以入手的地方，过了一小段时间回复说他们的入侵防护特征库在公网映射可能有些问题。于是便去别的用户设备上进行验证，发现其他设备也是同样的情况，入侵防护特征库自动更新最新只能到1月18号，别的都可以更新到2月份，此次故障原因确实是他们的服务器有问题。工程师同时发给我们发了一份离线更新包，以便及时有效防护来自互联网的安全威胁。

最终厂商确认了他们升级服务器中的入侵防护特征库少了一段数据，原本应该是01月18日至02月22日这个时间段的特征库，厂商研发人员却配置了02月15日至02月22日的库，和用户端融合网关的入侵防护特征库顺序不一致，导致无法正常自动更新。通过厂商服务器的调整最终解决了问题。

三、威胁统计数据异常，还是入侵防护特征库的问题

在每日融合网关安全巡检过程中，我们已经形成了一条安全威胁基线。当有一天看到NGFW安全近24小时威胁统计页面中出现零星几个攻击事件，就让我们意识到设备有问题。立即检查流量图是正常的，且峰值和低谷都和以往基本一致，就此确认网络和信息系统所发布的应用都正常。设备有问题还是联系厂商检查原因，当电话联系到对方工程师时，却不以为然地说威胁统计数据少，那就表示来自互联网的攻击不多嘛，不能说明设备有问题。

图3 特征库事件数为0

由于我们每天在巡检设备时详细记录了安全威胁类别和具体数量，所以我们当即反驳厂商的观点，融合网关是我们在管理，其运行情况我们当然最清楚；而设备内部的异常只有厂商才了解，所以要求厂商远程协助排查原因。工程师通过teamviewer再次连到我们的工作电脑，由于是上两次处理问题的同一个人，对于设备情况也较熟悉。他很快检查了入侵防护更新情况，当时我们还不明白，他为什么要这样做，赶忙和他沟通说要处理的问题是NGFW管理页面的威胁统计数据异常。

这次倒是很快检查到了原因，还是入侵防护特征库引起的。细看特征库更新日期3月15日，符合正常的更新周期，只是后面的特征库的条目却是0，如图3所示，也就是说此时的入侵防护特征库是空的，也不能防御来自互联网的安全威胁，所以管理页面的统计数据生成自然就和平日不一样了。

既然确认了入侵防护特征库的问题，只能将特征库回退到上一个正常版本，最后工程师发来了更新文件20190301-20190308.tis，在管理页面的“手动升级“项将更新文件上传到设备完成特征库版本回退。等了几分钟，设备的威胁日志产生了，威胁统计数据也正常显示出来。

四、 融合网关ADC网元主备自动切换，检查原因暂无定论

上周的日常运维巡检中发现作为master设备流量异常小，和以往的情况有点不一样，由于是在8点半看到的流量图，此时业务访问量也非常少。于是检查了各信息系统均能从互联网正常访问，就没有太留意。下午14点半再次检查时流量依然很小，但是NGFW显示的并发连接数又是往常一样峰值在6000个左右，新建连接数为每秒120个，这流量都跑哪去啦？

于是登录到slave设备，才发现两台设备发生了自动的主备切换。融合网关运行一年多来都没有发生过这样的现象，只在去年年中的应急恢复演练为了验证另一台设备是否运行正常，进行过一次手动主备切换。急忙查看ADC的系统日志，筛选出HA（High Avalibility高可用）日志如图4所示，在2019年3月18日15点19分33秒时检测到“内网链路“DOWN，于是发生了主备切换，在2秒后该链路又UP了。当时我们怀疑可能是设备与核心交换机的链路不稳定，再次从核心交换机检查又没有任何端口DONW和UP的信息，问题的具体的原因只能留待以后观察。

没想到3月22日融合网关的ADC的流量又自动切回来了，这样的不稳定虽然不会影响信息系统正常访问，在切换时正在访问的用户体验可能受影响。向厂商工程师求助指点迷津，远程对融合网关的管理页面和后台检查一番，发现NGFW网元的运行时间为1天19小时，同时也在后台发现了NGFW网元有自动重启的日志，和ADC的主备切换时间比较吻合。

于是工程师认定为主备切换的原因为NGFW网元引起，并说其它用户的设备也存在类似情况，需要研发出新版本来解决此问题。我们就相信了厂商的权威结论，没有再问更进一步的原因，等待其发布新版本解决。

图4 健康检查ping的配置

NGFW新版本还没任何消息，本周3月25日又发生上面所述的流量切换，这次我们特意查看了NGFW运行时间为5天22小时，也就是说，这次NGFW网元没有自动重启，还是赶紧联系厂商报告最新情况。

又是一阵远程检查，结果如我们猜想的一样，他们也没有再提上次所说的NGFW网元的原因，转而解释为是ADC网元高可用性中故障检测，所配置的网关监测检测到“内网链路”DOWN就发生了主备切换，该解释如系统中的HA日志描述一样。我们想确认所配置“内网链路“具体指的什么，发现在链路负载模块中的链路池定义了“内网链路”，链路成员是连接核心交换机虚接口的IP地址，并且配置了ping健康检查。确认“模板和对象 健康检查 健康检查列表”中ping的配置，其超时时间为1秒，如图5所示，厂商工程师提出可能此值太小而流量太大所致。

但我们的融合网关一直没有修改过此项配置，且近一年都未出现主备自动切换问题。加之融合网关与后面的核心交换机是10Gbps的链路，平时来自互联网的流量峰值也就100Mbps，此项配置引发故障的可能性较小。

我们希望厂商找到自动切换的根本原因，才能最终解决问题。但厂商工程师还是强调此处是个疑点，于是将ping超时的时间改为3秒，作为排查测试。此后稳定了一周又开始自动切换，频率大概在每周出现一次。

图5 ADC系统日志中HA报警

就这样厂商对设备故障放弃治疗了，我们也只能很无语面对融合网关不明原因的“自动化”，幸好该故障没有明显影响。

总结

部署在网络边界的安全设备稳定运行至关重要，一方面我们通过每日巡检和记录了解设备的运行状态和威胁防御情况，日积月累在心中自然形成了正常的运行基线，一眼就能看出设备是否正常，访问流量是否异常，以便及时处置相关问题。另一方面厂商的技术支撑非常重要，首先是WAF和IPS事件特征库的及时更新，才能有效防御各种威胁；其次是当出现问题时能及时解决，以保障设备的稳定运行。