■ 四川 賴(lài)文書(shū)

編者按： 安全網(wǎng)關(guān)的正常運(yùn)行關(guān)系到單位的網(wǎng)絡(luò)安全狀況，在近期單位網(wǎng)絡(luò)運(yùn)維中，安全網(wǎng)關(guān)卻出現(xiàn)了一系列莫名故障，很多情況是與相關(guān)廠家有關(guān)的，連續(xù)幾次故障事件中，筆者單位的日常巡檢還幫助廠商發(fā)現(xiàn)他們不應(yīng)該出現(xiàn)的問(wèn)題。

為保障信息系統(tǒng)穩(wěn)定對(duì)外提供服務(wù)，防御來(lái)自互聯(lián)網(wǎng)的各種安全威脅，公司在IDC機(jī)房的互聯(lián)網(wǎng)出口部署了2臺(tái)太一星辰的MSG多業(yè)務(wù)融合安全網(wǎng)關(guān)，構(gòu)建了主備高可用集群。該設(shè)備適用于傳統(tǒng)大中型網(wǎng)絡(luò)邊界、云數(shù)據(jù)中心、SDN及其他新業(yè)務(wù)環(huán)境的新一代應(yīng)用網(wǎng)絡(luò)虛擬化平臺(tái)產(chǎn)品。實(shí)現(xiàn)了軟硬件解耦合、彈性資源管理業(yè)務(wù)功能軟件定義等特性。

融合安全網(wǎng)關(guān)主要由以下五個(gè)部分組成：高性能交換矩陣T-xSwitch，虛機(jī)管理T-vBOS系統(tǒng)，標(biāo)準(zhǔn)虛擬化網(wǎng)元層T-xVNF，業(yè)務(wù)編排T-vOSS、T-vAPI。我們所使用的T-Force 12000-MSG擁有240GPS吞吐量，包含ADC（應(yīng)用交付控制）、NGFW（下一代防火墻）、WAG(Web應(yīng)用網(wǎng)關(guān))、入侵防御、防病毒、流控等網(wǎng)元，這些網(wǎng)元就是以KVM（Kernel Virtual Machine內(nèi)核虛擬機(jī)，Linux的一種虛擬化技術(shù)）運(yùn)行的虛機(jī)。其運(yùn)行機(jī)制是通過(guò)Service-Chain服務(wù)鏈讓流量按照預(yù)定策略，依次通過(guò)多個(gè)虛擬化網(wǎng)元所經(jīng)過(guò)的軌跡，每個(gè)虛擬化網(wǎng)元在數(shù)據(jù)流量通過(guò)時(shí)，進(jìn)行相應(yīng)的安全檢測(cè)，防御，流量?jī)?yōu)化，整形以及其他更高層協(xié)議的處理。我們的安全網(wǎng)關(guān)一直運(yùn)行正常，近幾個(gè)月運(yùn)維管理中遇到如下故障。

一、入侵防護(hù)特征庫(kù)更新失敗，添加更新服務(wù)器的訪問(wèn)規(guī)則

我們的融合網(wǎng)關(guān)的入侵防護(hù)特征庫(kù)更新，在系統(tǒng)里配置為在每晚凌晨1點(diǎn)自動(dòng)進(jìn)行。平日的觀察中發(fā)現(xiàn)廠家會(huì)在一周左右的時(shí)間，根據(jù)互聯(lián)網(wǎng)安全預(yù)警進(jìn)行特征庫(kù)的更新。連續(xù)幾周觀察更新情況，更新日期都沒(méi)變動(dòng)，通過(guò)手動(dòng)在管理頁(yè)面操作“立即升級(jí)”，顯示“升級(jí)信息已下發(fā)成功”，但是特征庫(kù)始終定格在1個(gè)月前。只能及時(shí)聯(lián)系廠商咨詢(xún)其入侵防護(hù)特征庫(kù)是否在正常更新，廠商給出了特征庫(kù)更新情況查詢(xún)網(wǎng)址https://www.venustech.com.cn/article/type/1/141.html，在頁(yè)面上確認(rèn)“USG產(chǎn)品入侵防御特征庫(kù)-適用T系列”都正常發(fā)布了更新?？蔀槭裁次覀兊脑O(shè)備更新卻停止了呢？

只得請(qǐng)廠商工程師遠(yuǎn)程對(duì)設(shè)備進(jìn)行檢查，登錄后臺(tái)的NGFW網(wǎng)元ping互聯(lián)網(wǎng)的DNS地址114.114.114.114確認(rèn)正常，也能正常解析域名。再以命令“debug u p d a t e”，“t e r m i n a l monitor”，開(kāi)啟后臺(tái)對(duì)特征庫(kù)升級(jí)的調(diào)試模式，在管理頁(yè)面操作“立即升級(jí)”，后臺(tái)返回與升級(jí)服務(wù)器的網(wǎng)絡(luò)異常，最后ping特征庫(kù)升級(jí)服務(wù)器測(cè)試不通。自動(dòng)升級(jí)問(wèn)題就定位到網(wǎng)絡(luò)連通性上，工程師嘗試停用了我們做的對(duì)惡意訪問(wèn)地址組限制的規(guī)則，再測(cè)試其連通性仍然失敗。

經(jīng)過(guò)多處配置的檢查均沒(méi)有可調(diào)試的地方，只能在NGFW管理頁(yè)面新建了一條訪問(wèn)規(guī)則，允許any訪問(wèn)特征庫(kù)更新服務(wù)器202.85.219.10的任何服務(wù)。再測(cè)試其連通性居然通了，手動(dòng)點(diǎn)擊管理頁(yè)面上的“立即升級(jí)”，特征庫(kù)終于趕上更新的步伐如圖1所示。

經(jīng)過(guò)上述操作確實(shí)解決了此次問(wèn)題，但是為什么一直都正常的入侵防護(hù)特征庫(kù)自動(dòng)更，忽然NGFW網(wǎng)元就無(wú)法與升級(jí)服務(wù)器網(wǎng)絡(luò)不通了？難道真是我們?cè)谔砑影踩雷o(hù)策略時(shí)被意外阻止了？

經(jīng)過(guò)對(duì)IP地址對(duì)象的檢查，和防護(hù)策略的逐條確認(rèn)，未能找到故障根源。感覺(jué)此問(wèn)題甚為蹊蹺，真不知道是否廠商在設(shè)備后臺(tái)系統(tǒng)的某些變化引發(fā)故障？

圖1 設(shè)備入侵防護(hù)特征庫(kù)更新

圖2 廠家發(fā)布的特征庫(kù)升級(jí)包

二、入侵防護(hù)特征庫(kù)再次更新失敗，廠商的更新服務(wù)器故障

自從上次廠商幫忙處理融合網(wǎng)關(guān)的入侵防護(hù)特征庫(kù)更新，升級(jí)到2019年1月18日后，很快就進(jìn)入春節(jié)假期。正常上班后在日常巡檢中也都留意設(shè)備的更新情況，怎么這特征庫(kù)又停止不前了？去官網(wǎng)確認(rèn)更新情況步調(diào)一致，這次就不懷疑我們?cè)O(shè)備問(wèn)題了?？磥?lái)這入侵防護(hù)特征更新是廠商的安全人員還在研究中，春節(jié)過(guò)后大家都還沒(méi)進(jìn)入正工作狀態(tài)，完全可以理解?？墒堑鹊皆?jié)（2月19日）都過(guò)了，發(fā)現(xiàn)病毒防護(hù)特征庫(kù)、應(yīng)用分類(lèi)特征庫(kù)、URL分類(lèi)特征庫(kù)都已經(jīng)更新到2月21日，同時(shí)發(fā)現(xiàn)官網(wǎng)也已經(jīng)發(fā)布了2月22日的更新如圖2所示，而我們?cè)O(shè)備入侵防護(hù)特征庫(kù)更新好像還在放假中沒(méi)有反應(yīng)。

只得再次通過(guò)400電話聯(lián)系廠家，深入診斷問(wèn)題的原因。廠商工程師遠(yuǎn)程檢查了一番，沒(méi)有找到可以入手的地方，過(guò)了一小段時(shí)間回復(fù)說(shuō)他們的入侵防護(hù)特征庫(kù)在公網(wǎng)映射可能有些問(wèn)題。于是便去別的用戶設(shè)備上進(jìn)行驗(yàn)證，發(fā)現(xiàn)其他設(shè)備也是同樣的情況，入侵防護(hù)特征庫(kù)自動(dòng)更新最新只能到1月18號(hào)，別的都可以更新到2月份，此次故障原因確實(shí)是他們的服務(wù)器有問(wèn)題。工程師同時(shí)發(fā)給我們發(fā)了一份離線更新包，以便及時(shí)有效防護(hù)來(lái)自互聯(lián)網(wǎng)的安全威脅。

最終廠商確認(rèn)了他們升級(jí)服務(wù)器中的入侵防護(hù)特征庫(kù)少了一段數(shù)據(jù)，原本應(yīng)該是01月18日至02月22日這個(gè)時(shí)間段的特征庫(kù)，廠商研發(fā)人員卻配置了02月15日至02月22日的庫(kù)，和用戶端融合網(wǎng)關(guān)的入侵防護(hù)特征庫(kù)順序不一致，導(dǎo)致無(wú)法正常自動(dòng)更新。通過(guò)廠商服務(wù)器的調(diào)整最終解決了問(wèn)題。

三、威脅統(tǒng)計(jì)數(shù)據(jù)異常，還是入侵防護(hù)特征庫(kù)的問(wèn)題

在每日融合網(wǎng)關(guān)安全巡檢過(guò)程中，我們已經(jīng)形成了一條安全威脅基線。當(dāng)有一天看到NGFW安全近24小時(shí)威脅統(tǒng)計(jì)頁(yè)面中出現(xiàn)零星幾個(gè)攻擊事件，就讓我們意識(shí)到設(shè)備有問(wèn)題。立即檢查流量圖是正常的，且峰值和低谷都和以往基本一致，就此確認(rèn)網(wǎng)絡(luò)和信息系統(tǒng)所發(fā)布的應(yīng)用都正常。設(shè)備有問(wèn)題還是聯(lián)系廠商檢查原因，當(dāng)電話聯(lián)系到對(duì)方工程師時(shí)，卻不以為然地說(shuō)威脅統(tǒng)計(jì)數(shù)據(jù)少，那就表示來(lái)自互聯(lián)網(wǎng)的攻擊不多嘛，不能說(shuō)明設(shè)備有問(wèn)題。

圖3 特征庫(kù)事件數(shù)為0

由于我們每天在巡檢設(shè)備時(shí)詳細(xì)記錄了安全威脅類(lèi)別和具體數(shù)量，所以我們當(dāng)即反駁廠商的觀點(diǎn)，融合網(wǎng)關(guān)是我們?cè)诠芾?，其運(yùn)行情況我們當(dāng)然最清楚；而設(shè)備內(nèi)部的異常只有廠商才了解，所以要求廠商遠(yuǎn)程協(xié)助排查原因。工程師通過(guò)teamviewer再次連到我們的工作電腦，由于是上兩次處理問(wèn)題的同一個(gè)人，對(duì)于設(shè)備情況也較熟悉。他很快檢查了入侵防護(hù)更新情況，當(dāng)時(shí)我們還不明白，他為什么要這樣做，趕忙和他溝通說(shuō)要處理的問(wèn)題是NGFW管理頁(yè)面的威脅統(tǒng)計(jì)數(shù)據(jù)異常。

這次倒是很快檢查到了原因，還是入侵防護(hù)特征庫(kù)引起的。細(xì)看特征庫(kù)更新日期3月15日，符合正常的更新周期，只是后面的特征庫(kù)的條目卻是0，如圖3所示，也就是說(shuō)此時(shí)的入侵防護(hù)特征庫(kù)是空的，也不能防御來(lái)自互聯(lián)網(wǎng)的安全威脅，所以管理頁(yè)面的統(tǒng)計(jì)數(shù)據(jù)生成自然就和平日不一樣了。

既然確認(rèn)了入侵防護(hù)特征庫(kù)的問(wèn)題，只能將特征庫(kù)回退到上一個(gè)正常版本，最后工程師發(fā)來(lái)了更新文件20190301-20190308.tis，在管理頁(yè)面的“手動(dòng)升級(jí)“項(xiàng)將更新文件上傳到設(shè)備完成特征庫(kù)版本回退。等了幾分鐘，設(shè)備的威脅日志產(chǎn)生了，威脅統(tǒng)計(jì)數(shù)據(jù)也正常顯示出來(lái)。

四、 融合網(wǎng)關(guān)ADC網(wǎng)元主備自動(dòng)切換，檢查原因暫無(wú)定論

上周的日常運(yùn)維巡檢中發(fā)現(xiàn)作為master設(shè)備流量異常小，和以往的情況有點(diǎn)不一樣，由于是在8點(diǎn)半看到的流量圖，此時(shí)業(yè)務(wù)訪問(wèn)量也非常少。于是檢查了各信息系統(tǒng)均能從互聯(lián)網(wǎng)正常訪問(wèn)，就沒(méi)有太留意。下午14點(diǎn)半再次檢查時(shí)流量依然很小，但是NGFW顯示的并發(fā)連接數(shù)又是往常一樣峰值在6000個(gè)左右，新建連接數(shù)為每秒120個(gè)，這流量都跑哪去啦？

于是登錄到slave設(shè)備，才發(fā)現(xiàn)兩臺(tái)設(shè)備發(fā)生了自動(dòng)的主備切換。融合網(wǎng)關(guān)運(yùn)行一年多來(lái)都沒(méi)有發(fā)生過(guò)這樣的現(xiàn)象，只在去年年中的應(yīng)急恢復(fù)演練為了驗(yàn)證另一臺(tái)設(shè)備是否運(yùn)行正常，進(jìn)行過(guò)一次手動(dòng)主備切換。急忙查看ADC的系統(tǒng)日志，篩選出HA（High Avalibility高可用）日志如圖4所示，在2019年3月18日15點(diǎn)19分33秒時(shí)檢測(cè)到“內(nèi)網(wǎng)鏈路“DOWN，于是發(fā)生了主備切換，在2秒后該鏈路又UP了。當(dāng)時(shí)我們懷疑可能是設(shè)備與核心交換機(jī)的鏈路不穩(wěn)定，再次從核心交換機(jī)檢查又沒(méi)有任何端口DONW和UP的信息，問(wèn)題的具體的原因只能留待以后觀察。

沒(méi)想到3月22日融合網(wǎng)關(guān)的ADC的流量又自動(dòng)切回來(lái)了，這樣的不穩(wěn)定雖然不會(huì)影響信息系統(tǒng)正常訪問(wèn)，在切換時(shí)正在訪問(wèn)的用戶體驗(yàn)可能受影響。向廠商工程師求助指點(diǎn)迷津，遠(yuǎn)程對(duì)融合網(wǎng)關(guān)的管理頁(yè)面和后臺(tái)檢查一番，發(fā)現(xiàn)NGFW網(wǎng)元的運(yùn)行時(shí)間為1天19小時(shí)，同時(shí)也在后臺(tái)發(fā)現(xiàn)了NGFW網(wǎng)元有自動(dòng)重啟的日志，和ADC的主備切換時(shí)間比較吻合。

于是工程師認(rèn)定為主備切換的原因?yàn)镹GFW網(wǎng)元引起，并說(shuō)其它用戶的設(shè)備也存在類(lèi)似情況，需要研發(fā)出新版本來(lái)解決此問(wèn)題。我們就相信了廠商的權(quán)威結(jié)論，沒(méi)有再問(wèn)更進(jìn)一步的原因，等待其發(fā)布新版本解決。

圖4 健康檢查ping的配置

NGFW新版本還沒(méi)任何消息，本周3月25日又發(fā)生上面所述的流量切換，這次我們特意查看了NGFW運(yùn)行時(shí)間為5天22小時(shí)，也就是說(shuō)，這次NGFW網(wǎng)元沒(méi)有自動(dòng)重啟，還是趕緊聯(lián)系廠商報(bào)告最新情況。

又是一陣遠(yuǎn)程檢查，結(jié)果如我們猜想的一樣，他們也沒(méi)有再提上次所說(shuō)的NGFW網(wǎng)元的原因，轉(zhuǎn)而解釋為是ADC網(wǎng)元高可用性中故障檢測(cè)，所配置的網(wǎng)關(guān)監(jiān)測(cè)檢測(cè)到“內(nèi)網(wǎng)鏈路”DOWN就發(fā)生了主備切換，該解釋如系統(tǒng)中的HA日志描述一樣。我們想確認(rèn)所配置“內(nèi)網(wǎng)鏈路“具體指的什么，發(fā)現(xiàn)在鏈路負(fù)載模塊中的鏈路池定義了“內(nèi)網(wǎng)鏈路”，鏈路成員是連接核心交換機(jī)虛接口的IP地址，并且配置了ping健康檢查。確認(rèn)“模板和對(duì)象 健康檢查 健康檢查列表”中ping的配置，其超時(shí)時(shí)間為1秒，如圖5所示，廠商工程師提出可能此值太小而流量太大所致。

但我們的融合網(wǎng)關(guān)一直沒(méi)有修改過(guò)此項(xiàng)配置，且近一年都未出現(xiàn)主備自動(dòng)切換問(wèn)題。加之融合網(wǎng)關(guān)與后面的核心交換機(jī)是10Gbps的鏈路，平時(shí)來(lái)自互聯(lián)網(wǎng)的流量峰值也就100Mbps，此項(xiàng)配置引發(fā)故障的可能性較小。

我們希望廠商找到自動(dòng)切換的根本原因，才能最終解決問(wèn)題。但廠商工程師還是強(qiáng)調(diào)此處是個(gè)疑點(diǎn)，于是將ping超時(shí)的時(shí)間改為3秒，作為排查測(cè)試。此后穩(wěn)定了一周又開(kāi)始自動(dòng)切換，頻率大概在每周出現(xiàn)一次。

圖5 ADC系統(tǒng)日志中HA報(bào)警

就這樣廠商對(duì)設(shè)備故障放棄治療了，我們也只能很無(wú)語(yǔ)面對(duì)融合網(wǎng)關(guān)不明原因的“自動(dòng)化”，幸好該故障沒(méi)有明顯影響。

總結(jié)

部署在網(wǎng)絡(luò)邊界的安全設(shè)備穩(wěn)定運(yùn)行至關(guān)重要，一方面我們通過(guò)每日巡檢和記錄了解設(shè)備的運(yùn)行狀態(tài)和威脅防御情況，日積月累在心中自然形成了正常的運(yùn)行基線，一眼就能看出設(shè)備是否正常，訪問(wèn)流量是否異常，以便及時(shí)處置相關(guān)問(wèn)題。另一方面廠商的技術(shù)支撐非常重要，首先是WAF和IPS事件特征庫(kù)的及時(shí)更新，才能有效防御各種威脅；其次是當(dāng)出現(xiàn)問(wèn)題時(shí)能及時(shí)解決，以保障設(shè)備的穩(wěn)定運(yùn)行。