對這文章發表回應
發表限制: 非會員 可以發表
發表者： 冷日 發表時間： 2016/12/21 15:10:57
最近有許多學校的DNS遭到了攻擊，全都是因為沒有限制遞迴查詢，導致外面的IP也可以使用學校的DNS進行遞迴查詢，產生大量的查詢封包，攻擊者只要利用沒有限制遞迴查詢的學校DNS，去查詢一個網域，就足以產生大量的名稱解析
這次受攻擊的SERVER為Centos與舊版B2D(jacana) ，全都是未加入限制查詢的設定
若你使用miniserver或OB2D，那麼預設是有加入的(使用 acl allow_clients { …. }; view “recursive” { …. };來限制)，可以放心
Linux限制遞迴查詢：
若你的系統是Centos或舊版B2D:
B2D:請檢查你的/etc/bind/named.conf
CentOS：請檢查你的/var/named/chroot/etc/named.conf
於 options{ …. };中，加入
以上是範例，請勿照抄m(_ _)m，請將學校網段改成學校的IPv4與IPv6
清除查詢快取：
重新啟動dns
B2D:
CentOS:
windows server：關閉遞迴查詢
注意:Windows的DNS服務並沒有辦法像Linux上Bind(DNS服務)做允許遞迴查詢來源限制,
此時勾選不允許遞迴查詢限制時,學校電腦的DNS解析伺服器若指定該Windows DNS伺服
器IP,會造無法連線google ,yahoo等網站問題,主要是此時的DNS伺服器只負責解析自己管理的網域,解決方式就是更改主機的DNS伺服器IP設定,可參考使用下列DNS伺服器IP:
中心DNS伺服器: 163.26.1.1 , 163.26.1.26 , 163.26.200.1 , 163.26.200.2
Hinet DNS伺服器:168.95.1.1, 168.95.192.1
處理後的狀況
案例:後壁國中(CentOS)與柳營國小(B2D)
後壁國中
9/1
9/4(關閉遞迴查詢後)dns查詢量雖減少，但查詢的殭屍電腦仍不斷查詢
9/10（以iptables drop ANY的查詢後）
柳營國小
9/1
9/4(關閉遞迴查詢後)
9/10（以iptables drop ANY的查詢後）
以下是我的處理流程
(攻擊查詢變成fkfkfkfz.guru)
雖於於9/2日，關閉遞迴查詢，dns查詢量已經大幅減少，後續觀察，這些『殭屍電腦』還是緊咬不放，而有大量的deny紀錄，讓log檔案快速增長
log有一大堆的莫名其妙的dns ANY query 被 denied
計算一下查詢的次數
（9/7）
9925540筆的deny查詢
（9/8）
10656799筆的deny查詢
（9/9）
6005641筆的deny查詢
雖然這些查詢被deny，但是持續不斷，真如殭屍一般，對系統造成不小的壓力，所以，根據之前log的特徵值，以iptables進行封檔
iptables -t raw -A PREROUTING -p udp --dport 53 -m string --algo bm --hex-string "|0000ff0001|" -j DROP
封擋掉吧，不然 messages的log會變很大
2.8G的檔案中，光從fkfkfkfz.guru的ANY查詢就達到2.6G
使用此iptables來deny ANY的查詢，可以立刻阻斷這些殭屍電腦的攻擊，並且也就不會紀錄相關log，可以讓你的系統負擔瞬間降低
測試：
ANY 查詢
-> 會被drop
一般查詢
B2D的bind版本較舊，需使用iptables drop ANY的查詢
柳營國小dns攻擊紀錄：
另外，作一個錯誤的zone
參考網站：
http://pank.org/blog/2012/08/block-dns-query-type-any.html
http://blogger.micloud.tw/2013/05/what-is-dns.html
原文出處：關於DNS的遞迴查詢攻擊與防護
這次受攻擊的SERVER為Centos與舊版B2D(jacana) ，全都是未加入限制查詢的設定
若你使用miniserver或OB2D，那麼預設是有加入的(使用 acl allow_clients { …. }; view “recursive” { …. };來限制)，可以放心
Linux限制遞迴查詢：
若你的系統是Centos或舊版B2D:
B2D:請檢查你的/etc/bind/named.conf
CentOS：請檢查你的/var/named/chroot/etc/named.conf
於 options{ …. };中，加入
------------------------------------------------------------------------------
allow-recursion { 127.0.0.1/32; 120.116.126.0/24(學校網段); 2001:288:759d::/48; };
------------------------------------------------------------------------------以上是範例，請勿照抄m(_ _)m，請將學校網段改成學校的IPv4與IPv6
清除查詢快取：
rndc flush
重新啟動dns
B2D:
service bind9 restart
CentOS:
service named restart
windows server：關閉遞迴查詢
注意:Windows的DNS服務並沒有辦法像Linux上Bind(DNS服務)做允許遞迴查詢來源限制,
此時勾選不允許遞迴查詢限制時,學校電腦的DNS解析伺服器若指定該Windows DNS伺服
器IP,會造無法連線google ,yahoo等網站問題,主要是此時的DNS伺服器只負責解析自己管理的網域,解決方式就是更改主機的DNS伺服器IP設定,可參考使用下列DNS伺服器IP:
中心DNS伺服器: 163.26.1.1 , 163.26.1.26 , 163.26.200.1 , 163.26.200.2
Hinet DNS伺服器:168.95.1.1, 168.95.192.1
處理後的狀況
案例:後壁國中(CentOS)與柳營國小(B2D)
後壁國中
9/1
9/4(關閉遞迴查詢後)dns查詢量雖減少，但查詢的殭屍電腦仍不斷查詢
9/10（以iptables drop ANY的查詢後）
柳營國小
9/1
9/4(關閉遞迴查詢後)
9/10（以iptables drop ANY的查詢後）
以下是我的處理流程
(攻擊查詢變成fkfkfkfz.guru)
雖於於9/2日，關閉遞迴查詢，dns查詢量已經大幅減少，後續觀察，這些『殭屍電腦』還是緊咬不放，而有大量的deny紀錄，讓log檔案快速增長
log有一大堆的莫名其妙的dns ANY query 被 denied
計算一下查詢的次數
（9/7）
9925540筆的deny查詢
（9/8）
10656799筆的deny查詢
（9/9）
6005641筆的deny查詢
雖然這些查詢被deny，但是持續不斷，真如殭屍一般，對系統造成不小的壓力，所以，根據之前log的特徵值，以iptables進行封檔
iptables -t raw -A PREROUTING -p udp --dport 53 -m string --algo bm --hex-string "|0000ff0001|" -j DROP
封擋掉吧，不然 messages的log會變很大
2.8G的檔案中，光從fkfkfkfz.guru的ANY查詢就達到2.6G
使用此iptables來deny ANY的查詢，可以立刻阻斷這些殭屍電腦的攻擊，並且也就不會紀錄相關log，可以讓你的系統負擔瞬間降低
測試：
ANY 查詢
dig @120.116.96.1 fkfkfkfz.guru ANY
-> 會被drop
一般查詢
dig @120.116.96.1 fkfkfkfz.guru
; <<>> DiG 9.9.5-3-Ubuntu <<>> @120.116.96.1 fkfkfkfz.guru
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 17042
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;fkfkfkfz.guru. IN A
;; Query time: 3 msec
;; SERVER: 120.116.96.1#53(120.116.96.1)
;; WHEN: Tue Sep 09 15:57:03 CST 2014
;; MSG SIZE rcvd: 42
B2D的bind版本較舊，需使用iptables drop ANY的查詢
柳營國小dns攻擊紀錄：
Sep 09 11:25:15.234 queries: info: client 179.99.159.137#10559: query: fkfkfkfz.guru IN ANY
Sep 09 11:25:15.237 queries: info: client 179.99.159.137#49217: query: fkfkfkfz.guru IN ANY
Sep 09 11:25:15.244 queries: info: client 179.99.159.137#57063: query: fkfkfkfz.guru IN ANY
Sep 09 11:25:15.245 queries: info: client 189.79.40.16#1364: query: fkfkfkfz.guru IN ANY
Sep 09 11:25:15.245 queries: info: client 179.99.159.137#24150: query: fkfkfkfz.guru IN ANY
Sep 09 11:25:15.246 queries: info: client 179.99.159.137#4834: query: fkfkfkfz.guru IN ANY
Sep 09 11:25:15.257 queries: info: client 179.99.159.137#47927: query: fkfkfkfz.guru IN ANY
Sep 09 11:25:15.266 queries: info: client 179.99.159.137#23960: query: fkfkfkfz.guru IN ANY
Sep 09 11:25:15.274 queries: info: client 179.99.159.137#18024: query: fkfkfkfz.guru IN ANY
Sep 09 11:25:15.285 queries: info: client 189.79.40.16#63803: query: fkfkfkfz.guru IN ANY
Sep 09 11:25:15.285 queries: info: client 189.79.40.16#36168: query: fkfkfkfz.guru IN ANY
Sep 09 11:25:15.305 queries: info: client 189.79.40.16#47455: query: fkfkfkfz.guru IN ANY
Sep 09 11:25:15.306 queries: info: client 189.79.40.16#55162: query: fkfkfkfz.guru IN ANY
Sep 09 11:25:15.306 queries: info: client 189.79.40.16#36751: query: fkfkfkfz.guru IN ANY
Sep 09 11:25:15.321 queries: info: client 189.79.40.16#51238: query: fkfkfkfz.guru IN ANY
Sep 09 11:25:15.356 queries: info: client 179.99.159.137#42087: query: fkfkfkfz.guru IN ANY
Sep 09 11:25:15.356 queries: info: client 179.99.159.137#25743: query: fkfkfkfz.guru IN ANY
另外，作一個錯誤的zone
cd /etc/bind/
vi bad-domain
-------------------------------
$TTL 86400
@ IN SOA dns.lyes.tn.edu.tw. admin.dns.lyes.tn.edu.tw. (
2000082619 ; serial
86400 ; refresh
1800 ; retry
1728000 ; expirei
1200 ;native cache
)
; IN NS dns.lyes.tn.edu.tw.
;* IN A 127.0.0.1
------------------------------
vi auth_zones.conf
--------------------------------
zone "fkfkfkfz.guru" {
type master;
file "bad-domain";
allow-update { none; };
};
--------------------------------
service bind9 restart
參考網站：
http://pank.org/blog/2012/08/block-dns-query-type-any.html
http://blogger.micloud.tw/2013/05/what-is-dns.html
原文出處：關於DNS的遞迴查詢攻擊與防護