鳥哥的 Linux 私房菜

這是鳥哥網站的工作日誌~

最近更新日期:2014/02/19

工作日誌連結

2014/02/22 鳥站遭受 DNS 之 DDoS 攻擊事件簿:

終於在 2014 年的 2 月份初期將鳥站移機到新的機器上面,這個新機器使用 4 核 8 緒的 CPU,配合 32GB 的記憶體,以及保障硬碟資料的硬體磁碟陣列, 配合少少的 5 顆 2TB 硬碟,對於我們鳥站這個小站來說,這樣的硬體設備是 OK 的了。同時參考 2013 年工作日誌裡面談到的, 使用虛擬機還是有不少的好處的。因此,在這個機器設備上面,鳥哥使用了虛擬機, 4 緒 CPU 加上 8G 記憶體的硬體規模來搭建鳥站所需要的環境。 初期運作狀況讓人相當滿意!除了某些 big5 轉 utf8 以及小程式的運作有點出錯之外,其餘的運作倒是還 OK 的!反應速度也夠快。

不過出事了!因為過去都沒有仔細研究一下 DNS named.conf 內的 recursive query 的項目,而新 named.conf 內預設的 recursive 是 yes 的環境, 鳥哥竟然就這樣沿用了!但是,這個 recursive yes 的參數,會讓所有的 client 都可以透過這部 DNS 來查詢資料,這稱之為 Open DNS 的設定!就跟 mail server 的 open relay 一樣,會導致很嚴重的後果!

上星期六 (2014/02/15) 鳥哥連進系統操作 http 的相關作業時,發現新站的連線速度好慢,甚至慢到會無法反應!這太奇怪了!用 ssh 連進去瞧一瞧, 要死了! CPU loading 衝高到 60~70% ,平時幾乎都在 10% 以下的~然後用 top 看一下,整個 CPU 效能被 named 佔用了!怎麼回事呢? 查詢 log 都沒有紀錄重大的事件啊!那怎辦?好~透過 tcpdump 去抓 port 53 看看吧~果然,一堆人在用 port 53 !隨便抓個 1 分鐘的 tcpdump 結果資料來分析,log 檔案幾乎大到幾百 MB 了!單純的抓 port 53 而已ㄟ!怎麼可能會這麼大?

好吧!在來看看 MRTG 的流量解析結果好了,結果,一看整個人昏倒!竟然流出的流量平均到達 30~40MBytes/s ,這麼高個頻寬使用量,是要嚇死誰? 趕緊關掉 DNS 然後繼續檢查,這才發現 recursive yes 會產生的嚴重問題~之後關掉了 recursive yes 改成 allow-recursive 的設定,只開放某些信任的網域作為 recursive 的方式而已。重新啟動 DNS。 不過,要命的是!依舊非常忙碌!雖然 CPU loading 降低到 20% 左右了 (還是比平時高),但是 log 檔案竟然一直長大,12 小時長大了 25GB 左右~ 如果不是隔天有繼續關注,恐怕整個 /var 會被衝爆!

為什麼會這樣呢?由於鳥哥已經關閉了 named 的 recursive 功能,因此當有其他人還想要來做 recursive 的查詢時,系統會顯示 deny 的作用。 但由於鳥哥的主機已經被鎖定了,因此在這 12 小時期間,系統還是一直被攻擊的!所以,deny 就一直產生,系統的 log 就一直長大! 結果除了 /var/log/messages 產生很多的垃圾訊息,另外,/var/named/data/* 也產生很多的垃圾訊息!要死了!這樣系統不死掉才怪! 好佳在鳥哥以前就遇到過 /var/ 爆表的問題,因此分割上面還有特別將 /var/ 切出來,可以避免出問題啦!所以系統沒死掉,不過, 也跟差點死掉差不多了!如何解決啊這問題?

因為一直被攻擊,鳥哥又用 tcpdump 去分析一下,果然是攻擊 udp 而已。好,那我將 port 53 的 udp 關閉總可以吧?那您會問, DNS 服務會不會死掉呢?好佳在,並不會。因為 DNS 的 udp 連不上的話,就會轉以 tcp 連線,因此關閉 udp 並不會讓系統死掉! 太好了,那就直接關閉吧!果然 cpu loading 與 log 都正常了。但是,分析 mrtg 還是發現 input 的流量非常大!不過,至少已經是在比較正常的流量值, 這樣應該就不會被鳥哥的 ISP 罵了吧!哈哈哈!

又過了一天, input 的流量終於也恢復正常了!好一個佳在~終於可以正常的提供服務。這時鳥哥也將 port 53 udp 再次的讓他放行, 這樣也才讓鳥站的整體服務通通正常~唉~好不容易啊!以此為鑑,大家要注意 DNS 這服務的正確性喔! ^_^



   http://linux.vbird.org is designed by VBird during 2001-2017.