《CSNA網(wǎng)絡(luò)分析認(rèn)證專家實(shí)戰(zhàn)案例》課件-第22章

第22章垃圾郵件行為分析22.1故障描述22.2分析過程22.3SMTP數(shù)據(jù)流解碼分析22.4案例總結(jié)

22.1.1故障背景

科來回溯分析系統(tǒng)3.1版增加了很多新功能，豐富的實(shí)時(shí)警報(bào)功能就是其中之一，這與3.0版相比可以說是一次質(zhì)的飛躍。新版的警報(bào)功能可以基于字節(jié)數(shù)、數(shù)據(jù)包數(shù)量、平均包長、TCP特征統(tǒng)計(jì)等流量統(tǒng)計(jì)信息設(shè)置警報(bào)，還可以設(shè)置郵件敏感字、可疑域名檢測以及報(bào)文特征值的警報(bào)。利用這些靈活的警報(bào)功能可以讓網(wǎng)管人員及時(shí)發(fā)現(xiàn)各種故障和安全隱患。22.1故障描述本章就是一個(gè)利用科來回溯分析系統(tǒng)3.1版流量警報(bào)功能發(fā)現(xiàn)內(nèi)網(wǎng)主機(jī)發(fā)送垃圾郵件的實(shí)例。22.1.2故障環(huán)境

本文的網(wǎng)絡(luò)環(huán)境是一家中國教育網(wǎng)用戶的網(wǎng)絡(luò)，內(nèi)網(wǎng)使用公有IP地址，在其互聯(lián)網(wǎng)出口部署科來回溯分析服務(wù)器，7

×

24小時(shí)捕獲互聯(lián)網(wǎng)出入站流量。由于內(nèi)網(wǎng)使用公有IP地址沒有做NAT(NetworkAddressTranslation，網(wǎng)絡(luò)地址轉(zhuǎn)換)，因此內(nèi)網(wǎng)主機(jī)會直接面對來自互聯(lián)網(wǎng)的各種威脅，端口掃描就是其中較常見的行為之一。為了及時(shí)監(jiān)測端口掃描的行為，我們在分析服務(wù)器上設(shè)置了旨在發(fā)現(xiàn)特定端口的主機(jī)掃描行為的警報(bào)，如圖22-1所示。

圖22-1科來回溯分析系統(tǒng)3.1版可以靈活地利用與或邏輯關(guān)系設(shè)置復(fù)雜的警報(bào)觸發(fā)條件。對于監(jiān)測網(wǎng)絡(luò)中任意應(yīng)用，如果某應(yīng)用1秒鐘內(nèi)數(shù)據(jù)包數(shù)量超過100個(gè)，并且平均包長小于72B，便觸發(fā)警報(bào)。

通常來自互聯(lián)網(wǎng)的主機(jī)掃描會針對特定的服務(wù)端口(如MSSQL1433端口)，短時(shí)間內(nèi)向一個(gè)網(wǎng)段內(nèi)每個(gè)IP發(fā)送連接請求，如果發(fā)現(xiàn)某主機(jī)有TCP同步確認(rèn)回應(yīng)，則與該主機(jī)建立TCP連接，而后進(jìn)一步嘗試漏洞攻擊或弱口令嘗試。由于TCP同步包和同步確認(rèn)包都沒有上層數(shù)據(jù)，因此這種主機(jī)掃描行為的數(shù)據(jù)包都很小，一般不會超過72B。設(shè)置這個(gè)警報(bào)的初衷雖然是發(fā)現(xiàn)主機(jī)掃描行為，但是在實(shí)際使用時(shí)意外地發(fā)現(xiàn)某臺內(nèi)網(wǎng)主機(jī)在發(fā)送垃圾郵件時(shí)觸發(fā)了這個(gè)警報(bào)。

22.2.1主機(jī)掃描警報(bào)的基本效果

在設(shè)置案例中的主機(jī)掃描警報(bào)之前，我們要發(fā)現(xiàn)主機(jī)掃描行為通常是在“TCP分析”趨勢圖中找TCP同步包的異常峰值，但是如果是在流量較大的網(wǎng)絡(luò)中，短短1～3秒的主機(jī)掃描行為所觸發(fā)的TCP同步包增加往往會被忽略。例如案例中的網(wǎng)絡(luò)工作時(shí)段，TCP同步包量在每秒400～600個(gè)之間，偶爾每秒增加100個(gè)并不是非常明顯，因而很多主機(jī)掃描行為沒有被及時(shí)發(fā)現(xiàn)。22.2分析過程在設(shè)置了案例中的警報(bào)之后，我們可以在控制臺的趨勢圖中直觀地看到每一次主機(jī)掃描的警報(bào)，同時(shí)在“警報(bào)日志”視圖看到主機(jī)掃描所針對的應(yīng)用服務(wù)，甚至不用切換到“TCP分析”趨勢圖，如圖22-2所示。

圖22-2從圖22-2中可以看到，選中時(shí)段內(nèi)有兩次針對MSSQL應(yīng)用的疑似主機(jī)掃描行為。3.1系統(tǒng)還增加了針對選中對象的分析功能(如選中某應(yīng)用或某IP地址)，在這里我們選中其中某警報(bào)日志條目，點(diǎn)擊鼠標(biāo)右鍵，選擇“分析”菜單項(xiàng)，就可以針對選中時(shí)段的MSSQL應(yīng)用進(jìn)行單獨(dú)分析，這樣可以快速判斷警報(bào)是否誤報(bào)，如圖22-3所示。

圖22-3從圖22-3中可以看出，警報(bào)發(fā)生的時(shí)段，某外網(wǎng)IP在短時(shí)間內(nèi)嘗試與內(nèi)網(wǎng)所有主機(jī)的TCP1433端口建立連接，由于內(nèi)網(wǎng)主機(jī)都沒有安裝SQLServer，所以每個(gè)連接請求都沒有得到應(yīng)答，每個(gè)會話都只有1個(gè)數(shù)據(jù)包。可以斷定這個(gè)外網(wǎng)IP在做全網(wǎng)段的MSSQL服務(wù)主機(jī)掃描。

在案例的網(wǎng)絡(luò)中，我們利用這個(gè)自定義的主機(jī)掃描警報(bào)發(fā)現(xiàn)了大量的類似主機(jī)掃描行為。這些行為的共同特點(diǎn)是發(fā)生時(shí)間很短(整個(gè)掃描過程一般在3秒內(nèi)完成)，一次掃描會觸發(fā)1～3次警報(bào)。掃描針對的應(yīng)用主要集中在MSSQL、MySQL、Oracle等數(shù)據(jù)庫端口以及CIFS、NetBios等共享端口，通常這些端口會容易受到漏洞攻擊或弱口令攻擊。這些行為在使用3.1版本之前需要非常仔細(xì)的觀察和分析才能發(fā)現(xiàn)，現(xiàn)在我們可以及時(shí)地發(fā)現(xiàn)，并在邊緣設(shè)備上針對這些掃描的端口或IP地址進(jìn)行過濾，避免更大的安全問題發(fā)生。22.2.2意外的SMTP主機(jī)掃描警報(bào)

在配置了自定義主機(jī)掃描警報(bào)之后，偶然發(fā)現(xiàn)某個(gè)時(shí)段有大量的針對SMTP應(yīng)用的主機(jī)掃描報(bào)警，報(bào)警的頻繁程度明顯超過了其他的主機(jī)掃描行為。

這次意外事件在1分多鐘的時(shí)間里觸發(fā)了56次主機(jī)掃描警報(bào)，這明顯與其他時(shí)段發(fā)生的主機(jī)掃描行為有區(qū)別。通常主機(jī)掃描者不會針對一個(gè)應(yīng)用端口持續(xù)很長時(shí)間的反復(fù)掃描。一般情況下，針對SMTP端口的SYNFlood攻擊才有可能持續(xù)觸發(fā)我們定制的主機(jī)掃描警報(bào)，然而這種SYNFlood攻擊往往會在“TCP分析”趨勢圖上看到明顯的TCP同步包數(shù)量增加，而從圖22-4的“TCP分析”趨勢圖上卻看不到這一現(xiàn)象。為了進(jìn)一步分析判斷這一事件的原因，我們使用3.1系統(tǒng)的應(yīng)用統(tǒng)計(jì)分析功能，對這一時(shí)段的SMTP會話進(jìn)行了統(tǒng)計(jì)分析。

圖22-422.2.3SMTP會話統(tǒng)計(jì)分析

從圖22-5所示的流量趨勢圖上明顯看到，SMTP流量在警報(bào)發(fā)生的時(shí)段內(nèi)有明顯增加，最大流量超過150kbps。在“TCP會話”視圖中我們看到，一個(gè)內(nèi)網(wǎng)IP在短時(shí)間內(nèi)與若干個(gè)外網(wǎng)IP的TCP25端口建立了很多TCP會話，這些會話并不像主機(jī)掃描行為那樣只有很少量的數(shù)據(jù)包，而是每個(gè)會話有幾個(gè)到幾十個(gè)不等(截圖中碰巧都是11個(gè)數(shù)據(jù)包)。

圖22-5至此，基本排除了這些警報(bào)是主機(jī)掃描行為的可能性，但可以判斷這些TCP會話不是正常的郵件發(fā)送，因?yàn)檎５泥]件發(fā)送不會產(chǎn)生如此多的會話，而且正常郵件發(fā)送的平均數(shù)據(jù)包長度不會小于72B。

要了解這些異常會話的真正作用，就需要對這些會話進(jìn)行數(shù)據(jù)包級解碼分析。于是我們將這一時(shí)段的SMTP應(yīng)用的數(shù)據(jù)包下載到控制臺，利用控制臺自帶的科來網(wǎng)絡(luò)分析模塊進(jìn)行解碼分析。

下載SMTP數(shù)據(jù)包后，定位到“TCP會話”視圖，并且選中某個(gè)會話，查看其“數(shù)據(jù)流”信息，能夠完整展現(xiàn)一個(gè)TCP會話的應(yīng)用層數(shù)據(jù)交互信息。

從數(shù)據(jù)流信息中我們看到，1這個(gè)外網(wǎng)IP有可能是21CN的郵件服務(wù)器，觸發(fā)警報(bào)的內(nèi)網(wǎng)IP在嘗試向21的某個(gè)不存在的用戶發(fā)送郵件，21CN的郵件服務(wù)器拒絕了這次郵件發(fā)送，如圖22-6所示。22.3SMTP數(shù)據(jù)流解碼分析

圖22-6繼續(xù)查看其他與21CN的TCP會話，發(fā)現(xiàn)每個(gè)會話的發(fā)件人都是“tyco110@163.com”，收件人郵箱地址在不斷變化，每個(gè)會話的收件人都不相同，但郵件后綴都是“@12”，說明這個(gè)內(nèi)網(wǎng)IP主機(jī)的郵件發(fā)送程序并不知道收件人的真實(shí)信息，而是在不斷變換郵件前綴嘗試向21CN的用戶發(fā)送郵件，如圖22-7所示。

圖22-7由于該內(nèi)網(wǎng)IP在短時(shí)間內(nèi)向21CN的郵件服務(wù)器發(fā)起了大量SMTP會話，一段時(shí)間后21CN的郵件服務(wù)器拒絕了該IP的郵件發(fā)送請求。

在該內(nèi)網(wǎng)IP與其他外網(wǎng)IP的SMTP會話中，我們看到了與21CN的會話相似的行為，這些外網(wǎng)IP包括“263.net”、“126.com”、“世紀(jì)互聯(lián)”等多家郵件服務(wù)提供商或IDC的郵件服務(wù)器地址，還包括一些中小型ICP的郵件服務(wù)器地址。在下載的全部4000多個(gè)SMTP會話中，成功發(fā)送郵件的會話不到10個(gè)?？磥磉@個(gè)垃圾郵件發(fā)送程序的效率并不是很高，或者是內(nèi)置的用戶列表已經(jīng)過時(shí)了。在幾個(gè)成功發(fā)送的郵件會話中我們可以看到明顯的垃圾郵件內(nèi)容，如圖22-8所示。

圖22-8至此，我們可以確定，一系列的SMTP主機(jī)掃描警報(bào)是這個(gè)持續(xù)的效率不是很高的垃圾郵件發(fā)送行為引起的。

通過這個(gè)案例的分析過程，我們可以總結(jié)以下幾點(diǎn)經(jīng)驗(yàn)：

(1)科來回溯分析系統(tǒng)3.1版強(qiáng)化的警報(bào)功能可以更加靈活地用來及時(shí)發(fā)現(xiàn)多種故障隱患和安全隱患，例如可以更加方便地發(fā)現(xiàn)主機(jī)掃描行為。22.4案例總結(jié)

(2)警報(bào)功能本質(zhì)上是模式比對，這一點(diǎn)與IDS的警報(bào)相似，由于存在行為模式相似的網(wǎng)絡(luò)行為，這會使得精心設(shè)計(jì)的警報(bào)出現(xiàn)誤報(bào)(包括IDS警報(bào))。與IDS等常規(guī)安全管理產(chǎn)品相比，回溯分析系統(tǒng)的優(yōu)勢在于可以對每一次警報(bào)進(jìn)行深入的挖掘和分析，以驗(yàn)證警報(bào)的真實(shí)性，避免誤報(bào)或漏報(bào)對網(wǎng)絡(luò)管理帶來的影響。

(3)在遇到警報(bào)出現(xiàn)頻率有明顯變化的時(shí)候，對警報(bào)相關(guān)的流量進(jìn)行深入分析，