安全網關運維中的一聲感嘆

■ 四川 賴文書

編者按： 安全網關的正常運行關系到單位的網絡安全狀況，在近期單位網絡運維中，安全網關卻出現了一系列莫名故障，很多情況是與相關廠家有關的，連續幾次故障事件中，筆者單位的日常巡檢還幫助廠商發現他們不應該出現的問題。

為保障信息系統穩定對外提供服務，防御來自互聯網的各種安全威脅，公司在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系列”都正常發布了更新?？蔀槭裁次覀兊脑O備更新卻停止了呢？

只得請廠商工程師遠程對設備進行檢查，登錄后臺的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日后，很快就進入春節假期。正常上班后在日常巡檢中也都留意設備的更新情況，怎么這特征庫又停止不前了？去官網確認更新情況步調一致，這次就不懷疑我們設備問題了。看來這入侵防護特征更新是廠商的安全人員還在研究中，春節過后大家都還沒進入正工作狀態，完全可以理解?？墒堑鹊皆潱?月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事件特征庫的及時更新，才能有效防御各種威脅；其次是當出現問題時能及時解決，以保障設備的穩定運行。