IP 來源地址主機(jī)名
64.152. 4. 80
128.121.223.161
131.103.248.119
164.109. 18.251
171. 64. 14.238
205.205.134. 1
206.222.179.216
208. 47.125. 33
216. 34. 13.245
216.111.239.132
216.115.102. 75
216.115.102. 76
216.115.102. 77
216.115.102. 78
216.115.102. 79
216.115.102. 80
216.115.102. 82
www.wwfsuperstars.com
veriowebsites.com
www.cc.rapidsite.net
whalenstoddard.com
www4.Stanford.EDU
shell1.novalinktech.net
forsale.txic.net
gary7.nsa.gov
channelserver.namezero.com
www.jeah.net
w3.snv.yahoo.com
w4.snv.yahoo.com
w5.snv.yahoo.com
w6.snv.yahoo.com
w7.snv.yahoo.com
w8.snv.yahoo.com
w10.snv.yahoo.com
這蜂擁而來的SYN/ACK 數(shù)據(jù)包和一些非路由的網(wǎng)絡(luò)服務(wù)器告訴了我們，任何用于普通目的TCP 連接許可的網(wǎng)絡(luò)服務(wù)器都可以用做數(shù)據(jù)包反射服務(wù)器。當(dāng)我看到我們光阻攔從BGP 端口傳來的數(shù)據(jù)是遠(yuǎn)遠(yuǎn)不夠的，我開發(fā)了一套更全面的解決方案來對(duì)付這種攻擊。這套方案我們會(huì)在下面討論。
在裝置好對(duì)付反射攻擊的filter 后，我們立即就可以重新返回網(wǎng)上了。經(jīng)過我不可以監(jiān)控在裝置filter 后的攻擊狀況，但看到下面的這些信息還是讓我冒了一陣?yán)浜埂?
直到攻擊停止，Verio 的路由丟棄了將近十億(1,072,519,399)的惡意SYN/ACK 數(shù)據(jù)包。
我是在認(rèn)識(shí)我到?jīng)]有抓到第二波非BGP 的數(shù)據(jù)包后才聯(lián)系Verio，從而得知這個(gè)數(shù)據(jù)的。我想要重新裝備我們的防御系統(tǒng)，好讓我們繼續(xù)遭受攻擊，這樣才能抓到那些我先前沒有收集到的資料，但當(dāng)我這樣做的時(shí)候，攻擊已經(jīng)停止了。
反射攻擊的防御及預(yù)防
通過Internet 進(jìn)行交流的電腦一般都可以被分為兩類：客戶端及服務(wù)端。這兩個(gè)角色可以隨著環(huán)境轉(zhuǎn)換（例如一個(gè)網(wǎng)頁(yè)服務(wù)器可能會(huì)是一個(gè)郵件服務(wù)器的客戶端），不過大部分的TCP 連接都意味著一個(gè)客戶端和服務(wù)端的關(guān)系?？蛻舳艘话銜?huì)從一個(gè)高數(shù)位的端口發(fā)起連接到服務(wù)端上處于監(jiān)聽狀態(tài)的底數(shù)位端口上。
因?yàn)槿魏畏瓷涞腟YN/ACK 數(shù)據(jù)包必須要彈到一個(gè)TCP 服務(wù)器上，并且因?yàn)閹缀跛械姆?wù)端口都在1 到1023 這個(gè)范圍之內(nèi)，阻攔所有在服務(wù)端口范圍之內(nèi)入站的數(shù)據(jù)包會(huì)防止大部分的攻擊造成的阻塞。不過這樣做有產(chǎn)生一些問題…..
保護(hù)服務(wù)器
首先，這次對(duì)grc.com 的攻擊包含了從端口4001 和6668 來的SYN/ACK 數(shù)據(jù)包。所以，如果從這些端口發(fā)出的數(shù)據(jù)太多的話，這些特殊的高數(shù)位服務(wù)端口也需要被阻攔。在阻攔高數(shù)位端口的入站數(shù)據(jù)包存在一個(gè)問題，那就是一些合法的客戶端的端口所發(fā)生的數(shù)據(jù)可能也會(huì)被我們?cè)O(shè)置的filter 給攔截掉。
第二個(gè)問題是如果我們只是簡(jiǎn)單的攔截所有從1024 以下端口發(fā)送的數(shù)據(jù)的話，那么像當(dāng)一個(gè)在blanket filter 后的服務(wù)器作為客戶端的話，它將無法和其它服務(wù)器進(jìn)行交流。就像我們剛才舉的例子一樣，當(dāng)一個(gè)網(wǎng)頁(yè)服務(wù)器作為一個(gè)SMTP 服務(wù)器的客戶端時(shí)，這個(gè)情況就會(huì)變的非常復(fù)雜。因?yàn)檫h(yuǎn)程SMTP 服務(wù)器的數(shù)據(jù)包會(huì)試圖從SMTP 服務(wù)器的25 號(hào)端口返回，這時(shí)它就會(huì)被我們?cè)O(shè)置的反反射攻擊的filter 給攔截掉。為了解決這個(gè)問題，我們需要在配置文件里設(shè)置例外端口，這樣才可以讓合法數(shù)據(jù)包正常通過。
保護(hù)客戶端
這里有一些壞消息?？蛻舳酥鳈C(jī)，例如那些典型的終端用戶，將無法被保護(hù)。因?yàn)槎鄶?shù)的客戶端在大部分時(shí)間里都是連接到遠(yuǎn)程的服務(wù)器端上的，這些服務(wù)器端很可能會(huì)被利用來攻擊這些無辜的客戶端。
譯者注：
國(guó)內(nèi)的網(wǎng)管可能都冒了一身的冷汗，以前的分布式拒絕服務(wù)式攻擊可以算是可見不可及。畢竟那是需要幾百臺(tái)受控的肉雞才能實(shí)現(xiàn)的，可現(xiàn)在這個(gè)技術(shù)可以利用任何不存在安全漏洞的主機(jī)來進(jìn)行攻擊，后果可以想象。原作者上面所說的利用filter 來攔截?cái)?shù)據(jù)包只是暫時(shí)之策，服務(wù)器不用來提供服務(wù)還有屁用？所以真正的解決辦法還是要從基礎(chǔ)的配置做起，這種攻擊不是使用半連接來掛掉主機(jī)，所以對(duì)付以前那種傳統(tǒng)的SYNFlood 的方法可能無法在這里行通。到目前為止，通過利用防火墻來阻擋那些序列號(hào)不對(duì)的數(shù)據(jù)包恐怕是最好的方法了。
希望網(wǎng)絡(luò)安全界的人士能盡快研究出更好的解決方法。
另外也請(qǐng)那些能自己悟出Exploit 的高手不要將攻擊方法亂傳，以國(guó)內(nèi)現(xiàn)在的安全水準(zhǔn)，無法經(jīng)受起這種攻擊，慎思。
