淺談拒絕服務攻擊的原理與防禦（5） | NTP反射攻擊復現

*原創作者：黑戈爾，本文屬FreeBuf原創獎勵計劃，未經許可禁止轉載

0×01 故事起因

系列回顧

【點擊閱讀原文查看】

前兩天以為freebuf上的網友stream（年齡、性別不詳）私信我說他在阿里雲上的伺服器被NTP攻擊了，流量超過10G，希望我幫忙一起分析一下，復現一下攻擊。

我這當代雷鋒當然非常樂意了，於是我就和stream聯繫（勾搭）上了，今天我就詳細講一下我們一起複現NTP反射攻擊的過程。

0×02 分析攻擊數據

stream大兄弟把當時抓到的包發給了我，數據包不大只有31.4M

當我打開數據包看了下時間才知道這數據包可不小啊！只有0.011秒就抓了67598個包，粗略計算一下67598*482/0.011=2 962 021 454位元組，將近3G/s也就是24Gbps，對我來說這樣的流量已經很大了。

藉助whireshark查看了一下源IP的情況，並排列了一下每個IP的發包數量，但是whireshark居然沒有統計IP地址個數的地方，也可能是我沒找到。

於是我就另存為到一個txt文件中，查看行號計算數量，發現總共有3307個源IP（哈哈！這可都是寶貝啊！）

然後把這些IP地址都轉換個格式存起來，留著下個階段復現的時候用。

0×03 攻擊復現

原本以為知道了IP了復現起來很簡單呢，其實過程並不順利（還是自己沒經驗）。

我先選了發包最多的那個IP測試一下，看看到底能不能返回monlist數據。

果然能返回monlist包，返回了大約100個482位元組的包，我靠！這尼瑪放大倍數非常讓人興奮啊！我還是too young啊，等我再次發包的時候就沒有回應了。

孤零零的就一個包，後來我測試了好幾個IP都是這種情況，有的甚至第一個包都不回，艹！這是怎麼回事呢？於是我就去看了下NTP協議的報文格式。

看起來挺長，我其實也沒看太懂，不過我們的目的是要發出monlist請求，所以我們只要清楚monlist的格式什麼樣就行了。後來我發現這個跟whireshark上的結構不太一樣，後來我就直接去看whireshark上的注釋了。

這就清晰多了，flags：

第一個bit是表示請求（0）還是應答（1）

第二個bit是是否閏秒，網上解釋是有時由於地球潮汐等等的影響時間會差0.9秒，通過這個bit加上，這塊對咱們沒用

第三四五個bit時表示版本的，現在常用第二版，所以這裡是010

剩下三個bit是模式，0未定義、1表示主動對等體模式、2表示被動對等體模式、3表示客戶模式、4表示伺服器模式、5表示廣播模式或組播模式、6表示此報文為NTP控制報文、7預留給內部使用。這裡我們要用的monlist是用的7

auth，sequence：

這欄位的八個bit我沒找到文獻說明具體幹嘛的，但是看樣子是1bit奇偶校驗，7bit序列號。

在下面那個implementation我就不知道是幹嘛的了。。。。。慚愧慚愧。。

request code就是我們重點需要的monlist請求。

於是我對照著協議標準從新構造了一個請求報文發現跟我以前構造的一模一樣。。。。。

str_monlist="x17"+"x00"+"x03"+"x2a"+20*"x00"

這是怎麼回事？我發的數據包沒有錯啊怎麼就沒回復呢？在這種情況下，就要藉助一下已有的一些軟體幫幫忙了，在這裡我們可以使用ntpdc來幫忙。

我用的是kali，上面已經安裝好了這個工具，這個工具的作用就是能發出想要的ntp報文，我用它發一個ntp monlist請求先看看情況，用 ntpdc -c monlist *.*.*.* 命令查看

看抓包情況

我發現我構造的數據包跟ntpdc的數據包就差了一堆00，於是我加上了180個00後整個世界都豁然開朗了。。。。

然後我修改了上次發的那個攻擊腳本，把NTP的payload加了180個00，做了一下測試，攻擊了一下stream的阿里雲伺服器

看看攻擊效果

能打出2.2G的峰值，但是跟攻擊者的10G 20G差很多，可能是我帶寬的原因，當然也可能是攻擊腳本不完美，日後還需要繼續改進才行。

0×04 結語

首先感謝一下stream大兄弟的分享，讓我能認識到我的不足，同時也分享出來讓大家避免同樣的錯誤，其次就是在網路攻擊上或者其他事情上要大家要細心，一些看似沒啥用的00就能影響結果。

還有就是希望大家遇到攻擊或者有什麼新的方法多分享出來，大夥一起學習一起進步，有問題可以私信我或者加我qq 2289988238，我不一定能幫到你，但是多一個人多一份力量，我有時間的情況下一定是有問必答的。各位朋友下期再見！

*原創作者：黑戈爾，本文屬FreeBuf原創獎勵計劃，未經許可禁止轉載

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！