作者：w7ay@知道創宇404實驗室
日期：2019年10月12日
Zmap和Masscan都是號稱能夠快速掃描網際網路的掃描器，十一因為無聊，看了下它們的程式碼實現，發現它們能夠快速掃描，原理其實很簡單，就是實現兩種程式，一個傳送程式，一個抓包程式，讓傳送和接收分隔開從而實現了速度的提升。但是它們識別的準確率還是比較低的，所以就想了解下為什麼準確率這麼低以及應該如何改善。
Masscan 原始碼分析
首先是看的Masscan［1］的原始碼，在readme上有它的一些設計思想，它指引我們看中的入口函式，以及傳送函式和接收函式和，還有一些簡單的原理解讀。
理論上的6分鐘掃描全網
在後面自己寫掃描器的過程中，對Masscan的掃描速度產生懷疑，目前Masscan是號稱6分鐘掃描全網，以每秒1000萬的發包速度。
之後瞭解到，預設模式下Masscan使用傳送和接收資料包，它在Windows和Mac上只有30萬/秒的發包速度，而Linux可以達到150萬/秒，如果安裝了PF_RING DNA裝置，它會提升到1000萬/秒的發包速度（這些前提是硬體裝置以及頻寬跟得上）。
注意，這只是按照掃描
一個
埠的計算。
PF_RING DNA裝置瞭解地址：http：//www。ntop。org/products/pf_ring/
那為什麼Zmap要45分鐘掃完呢？
在Zmap的主頁［2］上說明了
用PF_RING驅動，可以在5分鐘掃描全網，而預設模式才是45分鐘，Masscan的預設模式計算一下也是45分鐘左右才掃描完，這就是宣傳的差距嗎 （-
歷史記錄
觀察了readme的歷史記錄https：//github。githistory。xyz/robertdavidgraham/Masscan/blob/master/README。md
之前構建時會提醒安裝，但是後面沒有了，從releases上看，是將靜態編譯的改為了動態載入。
C10K問題
c10k也叫做client 10k，就是一個客戶端在硬體效能足夠條件下如何處理超過1w的連線請求。Masscan把它叫做C10M問題。
Masscan的解決方法是不透過系統核心呼叫函式，而是直接呼叫相關驅動。
主要透過下面三種方式：
1。定製的網路驅動
Masscan可以直接使用PF_RING DNA的驅動程式，該驅動程式可以直接從使用者模式向網路驅動程式傳送資料包而不經過系統核心。
2。內建tcp堆疊 直接從tcp連線中讀取響應連線，只要記憶體足夠，就能輕鬆支援1000萬併發的TCP連線。但這也意味著我們要手動來實現tcp協議。 3。不使用互斥鎖 鎖的概念是使用者態的，需要經過CPU，降低了效率，Masscan使用來進行一些需要同步的操作。與之對比一下Zmap，很多地方都用到了鎖。
為什麼要使用鎖？ 一個網絡卡只用開啟一個接收執行緒和一個傳送執行緒，這兩個執行緒是不需要共享變數的。但是如果有多個網絡卡，Masscan就會開啟多個接收執行緒和多個傳送執行緒，這時候的一些操作，如列印到終端，輸出到檔案就需要鎖來防止衝突。
多執行緒輸出到檔案 Masscan的做法是每個執行緒將內容輸出到不同檔案，最後再集合起來。在中
隨機化地址掃描
在讀取地址後，如果進行順序掃描，虛擬碼如下
但是考慮到有的網段可能對掃描進行檢測從而封掉整個網段，順序掃描效率是較低的，所以需要將地址進行隨機的打亂，用演算法描述就是設計一個，Masscan是設計了一個加密演算法，虛擬碼如下
隨機種子就是的值，這種加密演算法能夠建立一種一一對應的對映關係，即在［1。。。range］的區間內透過來生成［1。。。range］內不重複的隨機數。同時如果中斷了掃描，只需要記住的值就能重新啟動，在分散式上也可以根據來進行。
如果對這個加密演算法感興趣可以看 Ciphers with Arbitrary Finite Domains［3］這篇論文。
無狀態掃描的原理
回顧一下tcp協議中三次握手的前兩次
1。客戶端在向伺服器第一次握手時，會組建一個數據包，設定syn標誌位，同時生成一個數字填充seq序號欄位。2。服務端收到資料包，檢測到了標誌位的syn標誌，知道這是客戶端發來的建立連線的請求包，服務端會回覆一個數據包，同時設定syn和ack標誌位，伺服器隨機生成一個數字填充到seq欄位。並將客戶端傳送的seq資料包+1填充到ack確認號上。
在收到syn和ack後，我們返回一個rst來結束這個連線，如下圖所示
Masscan和Zmap的掃描原理，就是利用了這一步，因為seq是我們可以自定義的，所以在傳送資料包時填充一個特定的數字，而在返回包中可以獲得相應的響應狀態，即是無狀態掃描的思路了。接下來簡單看下Masscan中發包以及接收的程式碼。
發包
在中，前面說的隨機化地址掃描
接著生成cookie併發送
看名字我們知道，生成cookie的因子有源ip，源埠，目的ip，目的埠，和entropy（隨機種子，Masscan初始時自動生成），siphash24是一種高效快速的雜湊函式，常用於網路流量身份驗證和針對雜湊dos攻擊的防禦。
組裝tcp協議，部分程式碼
發包函式
可以看到它是分三種模式發包的，，，，如果沒有裝相關驅動的話，預設就是pcap發包。如果想使用PF_RING模式，只需要加入啟動引數
接收
在接收執行緒看到一個關於cpu的程式碼
大意是鎖住這個執行緒執行的cpu，讓傳送執行緒執行在雙數cpu上，接收執行緒執行在單數cpu上。但程式碼沒怎麼看懂
接收原始資料包
主要是使用了PFRING和PCAP的api來接收。後面便是一系列的接收後的處理了。在757行
後面還會判斷是否為源ip，判斷方式不是相等，是判斷某個範圍。
接著後面的處理
Zmap原始碼分析
Zmap官方有一篇paper［4］，講述了Zmap的原理以及一些實踐。上文說到Zmap使用的發包技術和Masscan大同小異，高速模式下都是呼叫pf_ring的驅動進行，所以對這些就不再敘述了，主要說下其他與Masscan不同的地方，paper中對丟包問題以及掃描時間段有一些研究，簡單整理下
1。傳送多個探針：結果表明，傳送8個SYN包後，響應主機數量明顯趨於平穩2。哪些時間更適合掃描2。我們觀察到一個±3。1%的命中率變化依賴於日間掃描的時間。最高反應率在美國東部時間上午7時左右，最低反應率在美國東部時間下午7時45分左右。2。這些影響可能是由於整體網路擁塞和包丟失率的變化，或者由於只間斷連線到網路的終端主機的總可用性的日變化模式。在不太正式的測試中，我們沒有注意到任何明顯的變化
還有一點是Zmap只能掃描單個埠，看了一下程式碼，這個儲存埠變數的作用也只是在最後接收資料包用來判斷srcport用，不明白為什麼還沒有加上多埠的支援。
寬頻限制
相比於Masscan用作為限制引數，Zmap用的方式來限制
我覺得這點很好，因為不是每個使用者都能明白每個引數代表的原理。實現細節
發包與解包
Zmap不支援Windows，因為Zmap的發包預設用的是socket，在window下可能不支援tcp的組包（猜測）。相比之下Masscan使用的是pcap發包，在win/linux都有支援的程式。Zmap接收預設使用的是pcap。
在構造tcp包時，附帶的狀態資訊會填入到seq和srcport中
在解包時，先判斷返回dstport的資料
再判斷返回的ack中的資料
輸入用 go 寫埠掃描器
在瞭解完以上後，我就準備用go寫一款類似的掃描器了，希望能解決丟包的問題，順便學習go。
在上面分析中知道了，Masscan和Zmap都使用了pcap，pfring這些元件來原生髮包，值得高興的是go官方也有原生支援這些的包https：//github。com/google/gopacket，而且完美符合我們的要求。
介面沒問題，在實現了基礎的無狀態掃描功能後，接下來就是如何處理丟包的問題。
丟包問題
按照tcp協議的原理，我們傳送一個數據包給目標機器，埠開放時返回標記，關閉會返回標記。
但是透過掃描一臺外網的靶機，發現掃描幾個埠是沒問題的，但是掃描大批次的埠（1-65535），就可能造成丟包問題。而且不存在的埠不會返回任何資料。
控制速率
剛開始以為是速度太快了，所以先控制下每秒傳送的頻率。因為傳送和接收都是啟動了一個goroutine，目標的傳入是透過一個channel傳入的（go的知識點）。
所以控制速率的虛擬碼類似這樣
本地狀態表
即使將速度控制到了最小，也存在丟包的問題，後經過一番測試，發現是防火牆的原因。例如常用的，其中拒絕的埠不會返回資訊。將埠放行後再次掃描，就能正常返回資料包了。
此時遇到的問題是有防火牆策略的主機如何進行準確掃描，一種方法是掃描幾個埠後就延時一段時間，但這不符合快速掃描的設想，所以我的想法是維護一個本地的狀態表，狀態表中能夠動態修改每個掃描結果的狀態，將那些沒有返回包的目標進行重試。
Ps：這是針對一個主機，多埠（1-65535）的掃描策略，如果是多個IP，Masscan的策略就能發揮作用了。
設想的結構如下
初始資料時為0，當傳送資料時，將變更為1，同時記錄傳送時間，接收資料時透過返回的標記，，等查詢到本地狀態表相應的資料結構，變更為2，同時啟動一個監控程式，監控程式每隔一段時間對所有的狀態進行檢查，如果發現為1並且當前時間-傳送時間大於一定值的時候，可以判斷這個ip+埠的探測包丟失了，準備重發，將+1，重新設定傳送時間後，將資料傳入傳送的channel中。
概念驗證程式
因為只是概念驗證程式，而且是自己組包傳送，需要使用到本地和閘道器的mac地址等，這些還沒有寫自動化程式獲取，需要手動填寫。mac地址可以手動用wireshark抓包獲得。
如果你想使用該程式的話，需要修改全域性變數中的這些值
整個go語言源程式如下，單檔案。
執行結果如下
但這個程式並沒有解決上述說的防火牆阻斷問題，設想很美好，但是在實踐的過程中發現這樣一個問題。比如掃描一臺主機中的1000個埠，第一次掃描後由於有防火牆的策略只檢測到了5個埠，剩下995個埠會進行第一次重試，但是重試中依然會遇到防火牆的問題，所以本質上並沒有解決這個問題。
Top 埠
這是Masscan原始碼中一份內建的Top埠表
可以使用來選擇數量。
這是在寫完go掃描器後又在Masscan中發現的，可能想象到Masscan可能也考慮過這個問題，它的方法是維護一個top常用埠的排行來儘可能減少掃描埠的數量，這樣可以覆蓋到大多數的埠（猜測）。
總結
概念性程式實踐失敗了，所以再用go開發的意義也不大了，後面還有一個坑就是go的pcap不能跨平臺編譯，只能在Windows下編譯windows版本，mac下編譯mac版本。
但是研究了Masscan和Zmap在tcp協議下的syn掃描模式，還是有很多收穫，以及明白了它們為什麼要這麼做，同時對網路協議和一些更低層的細節有了更深的認識。
這裡個人總結了一些tips：
Masscan原始碼比Zmap讀起來更清晰，註釋也很多，基本上一看原始碼就能明白大致的結構了。 Masscan和Zmap最高速度模式都是使用的pfring這個驅動程式，理論上它兩的速度是一致的，只是它們宣傳口徑不一樣？ 網路寬頻足夠情況下，掃描單個埠準確率是最高的（透過自己編寫go掃描器的實踐得出）。 Masscan和Zmap都能利用多網絡卡，但是Zmap執行緒切換用了鎖，可能會消耗部分時間。 設定發包速率時不僅要考慮自己頻寬，還要考慮目標伺服器的承受情況（掃描多埠時）
參考連結
Masscan：
https：//github。com/robertdavidgraham/Masscan
主頁：
https：//github。com/Zmap/Zmap
Ciphers with Arbitrary Finite Domains：
https：//web。cs。ucdavis。edu/~rogaway/papers/subset。pdf
paper：
https：//Zmap。io/paper。pdf
基於無狀態的極速掃描技術：
https：//github。com/robertdavidgraham/Masscan
Github：Zmap：
https：//github。com/Zmap/Zmap
Zmap原始碼解讀之Zmap掃描快的原因：
https：//nanshihui。github。io/2017/03/29/Zmap原始碼解讀之Zmap掃描快的原因/
往 期 熱 門
覺得不錯點個“在看”哦