TFTP蜜罐一月戰(zhàn)果：七家安全公司掃描實錄

我的TFTP蜜罐已經持續(xù)運行超過一個月，一部分時間跑在每月5美元的VPS上不間斷工作，另一部分時間斷斷續(xù)續(xù)掛在家里的戴爾R530服務器上。現(xiàn)在揭蓋的時刻到了，看看這小小的陷阱都抓住了什么。

當蜜罐運行時，兩臺服務器每天都會收到20到50個TFTP數(shù)據(jù)包，而且兩臺機器看到的基本是同樣的流量。最初看到天天有UDP 69端口的數(shù)據(jù)涌進來，而且大部分都帶著標準的TFTP格式，我真是興奮得不行。不過這股興奮很快被潑了冷水——我慢慢理清這些流量后，發(fā)現(xiàn)絕大多數(shù)都來自七家信息安全公司，它們是按部就班在做定期掃描。

這七家公司的掃描模式各具風格，我一條一條拆開看。第一家是Shadow Servers，它會連續(xù)發(fā)送5個ERROR包，大約每11秒一個，錯誤碼4帶消息“Bad Filename”，接著是錯誤碼0帶消息“Access violation”，再是錯誤碼4帶消息“4”和1個額外字節(jié)“\x05\x00\x044\x00\x00”，隨后錯誤碼5帶“Illegal TID”，還有一個錯誤碼4帶“Illegal TFTP operation”。除了這批錯誤包，它還會在另一個時間點發(fā)出對a.pdf的讀請求，傳輸模式為octet。

第二家Censys的指紋很清楚，它會請求下載/a文件，模式netascii。第三家Driftnet每次會請求一個由8個隨機字母組成的文件名，模式也是netascii，文件名規(guī)則是[a-zA-Z]重復8次，探測有時通過IPv6發(fā)起。第四家Shodan的手法比較特別，它發(fā)送一個16字節(jié)的非標準UDP載荷，十六進制表現(xiàn)為00000417271019800000000000034925，大約一半的情況下從UDP源端口18020過來，并且會在兩分鐘內從兩個或更多IP地址連續(xù)發(fā)射4到6個包。

第五家是行事頗為隱秘的Palo Alto Networks，它會先用netascii模式請求/a，隨后再用octet模式請求file。第六家Netscout請求的文件名是不太常規(guī)的ay9mfwq7xxmd4w6c7\xa0，模式octet。第七家Internet Census同時具備兩種行為：它用netascii模式請求/a文件，也會發(fā)送和Shodan表面相似的16字節(jié)非標準UDP載荷，但沒有兩個載荷完全相同，十六進制形式為000004172710198000000000xxyyzzww，其中末尾四個字節(jié)會變化。

注意到沒有，有三家公司全都會定期請求一個叫“a”的文件下載。要把這些交錯的請求完全拆解開，其實相當費神。命令行下的whois輸出格式太不規(guī)整，我不得不分別從whois抓取這三家的CIDR數(shù)據(jù)，再用grepcidr工具根據(jù)CIDR重新提取日志條目，交叉驗證是否把每家的所有日志條目都抓全了、分配對了。

這七家公司使用的IP地址絕大部分注冊在它們自己名下，多數(shù)IP在DNS里沒有A記錄，我全靠whois才找到歸屬。唯一的例外是Shodan，它有時候用自己的地址，有時候會用Digital Ocean的地址。至于掃描節(jié)奏，我只能看出“大約每天一次”這種模糊模式，再細節(jié)的規(guī)律就沒法分辨了。以持續(xù)在線的蜜罐數(shù)據(jù)看，在35天里，Palo Alto Networks的IPv4地址一共發(fā)來了35對探測，每一對內的兩次請求間隔約45秒，而不同對之間的第一次請求平均間隔24.09小時，最短間隔14小時，最長達到33.65小時。

這里順便放一張三家安全公司探測間隔的示例圖，可以看到間隔小時數(shù)的分布。就算把Palo Alto Networks和其他兩家的數(shù)據(jù)擺在一起，也很難提煉出一條精確的時間表，各家的步調只是大致維持在日頻附近。整個蜜罐運行下來，最初對陌生流量的激動感，最終凝結成一份清晰的安全掃描公司行為檔案，也算沒有白跑這一個月。