網管談：內網病毒緝拿記
身為中小企業的網絡管理員主要工作就是負責企業內部網絡及各個服務器的安全，因此必然離不開各式各樣的網絡及單機病毒。當然對于單機病毒來說一個強有力的殺毒軟件加上最終的重裝系統是百分之百可以解決的。
然而一旦病毒和內網聯系起來的話，網絡管理員將面臨棘手的查殺難題。最近筆者所在單位就爆發了一次局部的網絡病毒，排查與解決問題的過程是曲折而復雜的。
一、網絡環境簡介：
筆者負責區級教育網絡的維護工作，全部教育城域網均使用由我們提供的服務，包括辦公網郵件系統服務以及信息網站互動平臺等。所有服務器都在10.82.0.*/255.255.254.0這個網段，結合入侵檢測系統和防毒進行進行防護，而其他各個教育機構都通過電信的光纖連接到核心層的網絡設備上，每個教育機構獨立一個諸如10.82.*.*的內部網段。
二、故障起因——服務器部分服務失效：
最近有一個部門的員工打電話告訴我們說這幾天一直無法正常訪問辦公網郵件系統服務器10.82.0.3以及信息網站互動平臺10.82.0.1，而訪問其他諸如搜狐，新浪等外部網站都沒有問題。開始筆者以為是該員工的計算機自身存在問題，讓其恢復了系統后問題也得到了解決。然而隨著時間的推進筆者又接收到來自該分支機構的多個不同科室的電話，反映的情況都是一樣的即無法正常訪問辦公網郵件系統服務器10.82.0.3以及信息網站互動平臺10.82.0.1。與此同時筆者用自己的機器訪問這兩臺服務器上的應用服務時沒有任何問題，也沒有接到其他分支機構的故障電話，而且本人咨詢了具體情況后發現并不是該分支機構下的所有機器都無法訪問這兩個服務器上的應用，出現問題的只是其中的十幾臺，其他幾十臺沒有任何問題。
三、排查故障——篩選目標：(如圖1)
圖1
為了更好的了解和解決網絡問題，筆者親自到該分支機構去檢測。檢測發現當訪問10.82.0.3郵件辦公系統時可以出現正常的訪問登錄界面，不過在輸入用戶名和密碼時要嘛“登錄”按鈕不能用，要嘛干脆登錄進入后直接出現一行名為“office.nsf/pgnavigator?openpage>http/1.1 200 ok content-length:4742 content-type:text/html”報錯的提示，而且和往常登錄界面不同的是在辦公主頁下方出現了一行“input”的小字。之后筆者更換了瀏覽器為火狐以及騰訊的TT瀏覽器故障依舊，看來并不是本機IE瀏覽器插件的問題。而且筆者還得到了一個新的消息，那就是前幾天更更恢復完系統解決問題的那個員工計算機又出現了同樣的癥狀，無法順利訪問這兩臺服務器。
通過檢測的種種現象來看，首先服務器自身的問題可以排除，畢竟其他分支機構以及筆者都可以順利訪問，而且該機構下的某些機器也可以順利登錄信息平臺和郵件系統。另外當把系統恢復到以前或者重新安裝后問題也可以解決，這說明故障確實出現在本機。排除了服務器，網絡設備后筆者將關注的目標放到了本機上。 #p#
四、高級檢測——確定目標：
平時這個分支機構的計算機都是由筆者和幾個同伴一起負責維護，按照常理來說安全防范級別應該比較高，系統自動更新補丁都隨時安裝，殺毒軟件也使用的是卡巴斯基，那么為什么還會在本機出現故障呢?筆者再次檢測發現出問題的幾臺計算機的卡巴斯基并沒有升級到最新病毒庫，于是手工升級，并在安全模式下全面查殺本地硬盤各個分區，確保無毒后再次訪問辦公系統，結果令人遺憾的是故障依舊。不過每當訪問這兩個服務器應用服務時卡巴斯基都給出了發現危機的提示——malcious http object :access denied。這說明在訪問服務器時頁面要求自動跳轉到http://ck1.in/n.js這個地址，而該地址被卡巴斯基過濾禁止訪問了。筆者測試了所有出問題的機器都在訪問服務器時卡巴斯基給出警報提示。(如圖2)
圖2
由于之前已經確定了服務器自身沒有問題，所以排除了服務器上存在木馬或被篡改添加惡意腳本的可能，因此我們確定了目標，主要問題是病毒帶來的，該病毒被卡巴斯基命名為trojan program trojan-downloader.js.agent.lg，是一種木馬病毒。筆者在故障機上直接訪問http://ck1.in/n.js這個地址出現了該地址被殺毒軟件屏蔽的提示，看來該地址是萬惡之源。(如圖3)
圖3 #p#
五、解決問題——Sniffer出山找源頭
雖然確定了本次網絡故障是由病毒引起，但是筆者一直有一個疑惑，那就是各個機器的安全級別都很高，平時都是由我們專業人員負責維護，自動打各種漏洞補丁的，那么為什么還會有這么多的計算機感染了該木馬病毒呢?另外我們也針對這些故障機器進行了查殺病毒操作，卡巴斯基并沒有找到對應的染毒文件。種種跡象都表明病毒未必都在這些故障機器的系統中。
這時有一個念頭出現在筆者的腦海中，記得以前曾經應對和解決過ARP欺騙病毒，只要網絡中有一臺機器感染了ARP病毒，那么幾乎這個網段的所有機器都無法上網或者訪問網絡時斷時續。那么這次的木馬trojan program trojan-downloader.js.agent.lg病毒的感染與攻擊機理是否相同呢?為了證實此想法筆者拿出了看家工具——sniffer來掃描整個網段，看看是否有機器在發送或接收可疑數據包。
(1)掃描網絡：
安裝Sniffer針對出問題的網段進行掃描，筆者發現MAC地址為000BDBC2F6C5的機器頻繁發送廣播數據包，數量比較大。(如圖4)
圖4
將MAC地址切換到IP信息后筆者發現這臺可疑機器的IP地址為10.82.4.89，另外從掃描的圖表中我們看到了10.82.4.89這臺計算機不光頻繁發送廣播包，還發送了基于239.255.255.250地址的組播包，這在我們平時各種服務和應用中更是少見，這點增加了他的可疑性。(如圖5)
圖5
為了確定筆者的想法本人通過sniffer只針對該一臺機器進行掃描，并且在掃描的同時通過網絡來訪問之前出現問題的兩臺服務器應用，結果發現只要筆者在瀏覽器中輸入地址訪問辦公郵件系統或信息平臺，回車后10.82.4.89這臺機器就馬上發送數據到239.255.255.250地址，進行組播數據傳輸。看來這臺機器是罪魁禍首的可能性已經超過百分之八十。(如圖6)
圖6 #p#
小提示：
通過主機掃描筆者發現該機器名為dellesp，地址是10.82.4.89，MAC信息是000BDBC2F6C5。可惜該分支機構DELL機器有幾十臺，由于平時沒有按照科室的序號對計算機命令，所以無法從dellesp信息來定位故障來源。這點需要引起重視，應該在以后的維護中將各個員工機按照一定的順序命令和歸納。
(2)過濾可疑機：
由于無法通過計算機名來定位與排查，所以筆者只能夠在交換機和路由器上對地址是10.82.4.89，MAC信息是000BDBC2F6C5機器進行封殺了，如果禁止該機器訪問網絡后故障解決就可以斷定他是木馬的來源了。
筆者登錄到交換設備的管理界面，通過sh mac address命令來查看連接到該交換設備上的所有網絡設備對應的MAC地址。(如圖7)
圖7
接下來交換機界面會顯示出所有設備的MAC地址以及存在類型還有該MAC設備連接交換機的端口，在這些信息中筆者看到了MAC地址為000bdbc2f6c5這臺機器對應的交換機端口為GI0/2。于是筆者進入到該接口通過shutdown命令關閉來阻止該機器對網絡的訪問。(如圖8)
圖8
(3)恢復正常：
當我們順利將000bdbc2f6c5這臺機器過濾后網絡馬上恢復了正常，所有原本出現問題的計算機訪問辦公系統和信息平臺服務都沒有問題，訪問時卡巴斯基殺毒軟件也沒有再有任何警報產生。之后筆者也接到了000bdbc2f6c5這臺機器的主人打來電話說上不了網了，原來是辦公室的一臺筆記本電腦，將其殺毒后才用no shut命令解除了端口過濾。
小提示：
當然如果要封鎖的端口連接有多臺員工計算機的話，我們就不能夠通過簡單的shut端口命令來過濾問題機了，畢竟其他機器也會出現無法上網的問題。這時我們可以使用基于MAC地址的ACL訪問控制列表來解決，由于篇幅的關系這里就不詳細介紹了，感興趣的讀者可以自行搜索研究。
六、總結：
之前筆者一直認為木馬病毒和蠕蟲病毒不同并不會引起全網多臺機器無法訪問網絡，然而經過本次故障的排查和解決讓筆者不得不信服現在病毒的強大，對木馬類病毒更加刮目相看，原來他們不光可以盜取帳號等個人隱私，還可以對網絡其他機器造成惡劣影響。希望這種情況能夠引起各位網管讀者的重視，讓我們可以更好更快的解決企業內部網絡故障，徹底戰勝病毒。
【編輯推薦】
