基於無狀態的極速掃描技術(適用於新手)

在這裏插入圖片描述
大家都知道TCP是可靠的面向連接的協議,一個完整的TCP會話每個過程 都有不同的狀態。正是操作系統在底層已經保存了這些狀態我們在應用層使用起來才更方便可靠。可靠的同時帶來的是資源佔用,在古老的xp時代系統 TCP/IP連接默認只有10個。即使系統沒有這種限制,應用內部要使用上萬的連接也是消耗極大資源的,一般的應用程序每個連接啓動一個線程。 apache 默認1500個連接,打垮它是很容易的。

無狀態連接是指無需關心TCP狀態,不佔用系統TCP/IP協議棧 資源,忘記syn,ack,fin,timewait ,不進行會話組包。在實現上也有可能需要把必要的信息存放在數據包本身中。如13年曾以44分鐘掃描完全部互聯網zmap,之後出現的massscan, 都使用了這種無狀態技術,掃描速度比以往任何工具都有質的提升,後者更是提出了3分鐘掃完互聯網的極速。

我們注意到zmap和masscan都有一個控制發包速率的參 數,爲什麼需要這個參數呢?不是越高越好嗎?不是的,這個參數的設置直接影響漏報。一般家用adsl的上行速度在100kb/s-300kb/s 之間,以互聯網最小包60byte計算,100kb/s =1746 pps,也就是說每秒發送數據包約2000個,超出就容易丟包漏報。通過這個公式不難得出在一個家庭adsl環境下且保證準確度,用zmap掃描全部互聯 網需要 255255255*255/2000/3600/24=24天。

zmap在實現上還有兩個必須提的技巧,一個是爲了避免掃描連續的 IP地址而觸發目標網絡的IDS,採用了一種分組掃描算法,這樣掃描的IP地址隨機分佈,不再連續,就不會因爲密集掃描而觸發IDS。第二個技巧是利用對 掃描無影響的可用字段,來標記自己的掃描流量。在TCP掃描中使用了sequence number和source port 兩個字段,而ICMP則是 identifier 和 sequence number。通過這兩個自定義的標記過濾掉其它應用的背景流量。 masscan在過濾背景流量使用的是另外一種方法,通過註冊一個不存在的IP地址,來發送掃描數據。相比這兩種過濾方法,zmap產生的大量 sequence number 會導致交換機在跟蹤會話時內存佔滿。masscan就安全的多了。
這兩工具掃描端口的交互過程一致如下,在確認端口打開後通過RST放棄建立連接。


在這裏插入圖片描述
zmap和masscan重點都是端口掃描,並沒有建立完整的TCP會話,接下來我們要實現建立完整的連接。建立連接對掃描程序沒什麼性能消耗,考慮下apache的慢連接攻擊,那麼對服務器的危害就很大了。

tscan工具架構
在這裏插入圖片描述
tscan是我們自己實現的工具,在這個工具中我們用了兩個線程,一個線程負責發起SYN包,一個線程用來處理返回包,在背景流量過濾上使用了winpcap的端口和IP過濾器,同時打開windows系統自帶的防火牆防止系統自動發出RST干擾會話。

場景一 全連接測試

這是最簡單的會話實現,只建立連接,不提交任何數據。在沒有使用虛擬 IP的情況下,受端口4字節長度限制,一個IP對一個主機的同一端口只能建立65535個連接。截圖來自2010年我的博客 http://hi.baidu.com/cnqing/item/93894bf3c329e4c4a935a266,如果要建立更多連接可以利用虛擬 IP地址(同masscan背景流量過濾方式)
--------
在這裏插入圖片描述
在這裏插入圖片描述
應答數據包主要有下面幾個關鍵信息
1.源MAC和目的MAC互換
2.源IP和目的IP互換
3.源PORT和目的PORT互換
4.響應ack=原seq+本次數據長度
這幾個動作做好,再計算校驗和就可以正確的響應一個SYN +ACK,至此TCP連接建立完成。

應答數據包構造代碼:
在這裏插入圖片描述
場景二 掃描OpenSSL heartbeat

這個場景稍微複雜,不但建立會話還需要完成兩次數據交互,第一次是發送client hello,第二次發送heatbeat驗證漏洞。

process 處理流程示意:
在這裏插入圖片描述
OpenSSL HeartBleed 漏洞掃描流程示意圖:
在這裏插入圖片描述
代碼示例:
在這裏插入圖片描述

在這裏插入圖片描述
完成之後我們做了兩個測試
1.在上行速度3Mb的情況下,對12W活躍IP掃描,耗時36秒,漏報約1%。
2.用最低配的雲主機測一個A段1600W ip地址,耗時7.5小時,2977個漏洞。
照此粗略計算,目前全球受ssl影響的主機約爲75W個地址,接近zoomeye公佈的71W。

場景三 批量掃描FTP匿名

通過分析FTP登錄過程發現FTP的狀態碼還算可靠,只需關心的幾個狀態碼。
220 服務就緒,客戶端提交用戶名
331 服務器肯定,肯定繼續提交密碼
230 登錄成功
4xx/5xx 異常

下圖是我們模擬的登錄過程,在最後登錄成功後,多發送了一個RST終止流量。

FTP掃描要比SSL慢一些主要原因是FTP服務響應沒有openssl在handshake階段響應的快。
在這裏插入圖片描述
更高級的應用WEB漏洞掃描

理解前面的過程後掃描web漏洞就很容易實現,舉個掃描phpinfo的例子建立連接之後我們提交:

GET /phpinfo.php HTTP/1.1
Host: {$AUTOIP}

在這裏插入圖片描述
通過驗證返回的數據內容判斷是否存在phpinfo。

關於帶寬
在這裏插入圖片描述
不同的場景,帶寬消耗不同,端口掃描出流量,遠大於入流量,http掃描出流量和入流量比例在1:20左右。適當的設置發包速度可以有效降低漏報。

出於僅技術討論的目的,本文涉及的工具這裏暫不提供。有興趣的同學可以通過更改masscan研究。

發佈了405 篇原創文章 · 獲贊 159 · 訪問量 15萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章