淺談DDOS攻擊的應對策略
筆者在新加坡從事計算機網路工作7年,2013年考取CCIE(R&S), 目前在沙特工作,供職於「世界第一土豪大學「阿卜杜拉國王科技大學(KAUST),擔任Senior Network Engineer。本文兩年前發表於自己的技術博客,這兩天更新了下內容。
前幾天一朋友在新加坡開的網吧因為競爭被同行找人DDOS攻擊,整個外網全部癱瘓,斷線了數個小時。好在路由器是思科的,亡羊補牢猶未為晚,在換了公網IP並幫忙做了些加固後,問題暫時得以解決。不免想起這幾年「掙外快」時已經數次幫人做DDOS的防範加固,覺得有必要隨筆來一篇針對大多只有1G以內帶寬,沒有預算購買中高端安全設備和請安全顧問值守的網吧、小公司在技術上應如何防範DDOS攻擊的心得。
1. DDOS攻擊(分散式拒絕服務攻擊)早已產業化,現在中國的DDOS黑市,出錢請黑客打1G的流量到一個網吧或網站,市場價只要不到50元RMB。
2. DDOS攻擊已經算不上什麼高大上的技術了,只要具備基本的TCP/IP和LINUX伺服器知識,會使用Trinoo, TFN2K, Stacheldraht等等這些知名的DDOS攻擊軟體, 要獨立完成一次DDOS攻擊並不是難事。
3. 針對預算有限,規模較小的網吧和公司,遭受一次DDOS攻擊的打擊是毀滅性的,雖然DDOS攻擊在理論上是不可能完全避免的,但是依然有許多防範措施可以採用,個人的經驗大致如下:
A. 使用思科的路由器,理由大概兩點
1) 毫不誇張的說,新加坡的網路從業人員95%以上是學思科技術出生的,購買和部署思科的設備,有利於將來請人幫忙排錯或者維護時,技術人員能以最短的時間完成他的工作。
2) 思科的設備和其他牌子的設備相比,貴是貴,但是一台思科2811路由器也就不到1500新幣的價格,做生意的你別說這個你都負擔不起。
B. DDOS攻擊大概分為三種主要攻擊方式,針對每種攻擊方式的對策大概講解如下(各種攻擊和防範的原理就略過不說了)。
所有攻擊的拓撲均如下:
內網PC-----內網交換機------(GI0/0) 思科2811路由器(Gi0/1)------運營商設備--------INTERNET
1) 基於ICMP(也就是PING包)的SMURF攻擊:
a. 你要不想被黑客利用成「肉雞」,成為攻擊他人的幫凶,關閉broadcast redirect
2811(conf)# int gi0/0
2811(config-if)# no ip directed-broadcast
b. 你要不想成為被攻擊的受害者,寫一個ACL來過濾所有的ICMP ECHO包,
2811(config)#ip access-list extended 101
2811(config-ext-nacl)#deny icmp any any echo
2811(config-ext-nacl)#permit ip any any
2811(conf)# int gi0/1
2811(config-if)# ip access-group 101 in
* 如果你覺得這種「一刀切」的方式過濾掉所有的PING包,會給將來網路的維護、排錯帶來一些麻煩,那也可以考慮允許ICMP ECHO-REPLY包的通過,但是用CAR來對其進行限速。
2811(config)#ip access-list extended 102
2811(config-ext-nacl)#permit icmp any any echo-reply
2811(conf)# int gi0/1
2811(config-if)# rate-limit output access-group 102 3000000 512000 786000 conform-action transmit exceed-action drop
注意這裡CAR的方向是output
c. Unicast Reverse Path Forwarding (uRPF)
uRPF也是抵禦SMURF攻擊的一個利器,不過這個東西是在運營商那邊部署的,一個網吧就算有N條專線也用不上uRPF,不管是strict模式還是loose模式。網上很多所謂的「專家」不負責任地說話只說一半,只說建議在路由器上開啟uRPF,可以抵禦偽造了源IP的SMURF攻擊,也不講清楚是在運營商那邊開啟,還是在客戶這邊的路由器開啟,這些只會紙上談兵的人不知道禍害了多少人。你要是不信邪的話,照著下面的配置在你外網埠Gi0/1上開啟uRPF,不管是strict模式還是loose模式,包你分分鐘斷網,至於為什麼就不說了,因為這個原理對網吧業主還有小公司老闆們來說深奧了,就不浪費篇幅解釋了。
Loose模式
2811(config)#int gi0/1
2811(config-if)#ip verify unicast source reachable-via any
Strict模式
2811(config)#int gi0/1
2811(config-if)#ip verify unicast source reachable-via rx
怎樣,敢不敢試下?先聲明我不承擔後果。
2) 基於TCP的SYN Flood攻擊:
絕大多數網吧沒有對外網開放訪問的WEB伺服器,對SYN Flood攻擊不必太過擔心。但是很多小公司會用到它來做自己公司的網站,WEB伺服器很脆弱,因為他用的是TCP 80這個最常被攻擊的埠,黑客也最喜歡利用TCP三次握手的漏洞來發動基於TCP的SYN Flood攻擊,可行的防範方法如下:
a. 用CAR對SYN包限速
假設外網帶寬為50M
2811(config)#ip access-list extended 103
2811(config-ext-nacl)# permit tcp any host eq www
2811(config)#ip access-list extended 104
2811(config-ext-nacl)# permit tcp any host eq www established
2811(config)# interface gi0/1
2811(config-if)# rate-limit output access-group 104 50000000 100000 100000 conform-action transmit exceed-action drop
2811(config-if)# rate-limit output access-group 103 1000000 100000 100000 conform-action transmit exceed-action drop
這裡提兩點:
1. 對已經完成了TCP三次握手(established, 也就是104這個ACL)的流量,我們可以放心大膽的分配全部的帶寬(50M)給它,因為三次握手都完成了,肯定不是SYN Flood攻擊了。
2.
對沒有完成TCP三次握手的流量(103這個ACL), 這裡只給了1M的帶寬,也就是說假設你現在正遭到SYN Flood攻擊,那麼最多你也只會損失1M的帶寬,但是這也是把雙刃劍,因為它同樣會對合法的SYN包限速,通常建議遭受攻擊時才開啟這個ACL,並且這裡把流量限制為SYN Flood攻擊流量的30%到50%。b. TCP Intercept (TCP 攔截)
假設WEB伺服器的IP為1.1.1.1
2811(config)#ip access-list extended 105
2811(config-ext-nacl)# permit tcp any host 1.1.1.1
2811(config)#ip tcp intercept list 105
2811(config)#ip tcp intercept max-incomplete high 1100
2811(config)#ip tcp intercept max-incomplete low 900
2811(config)#ip tcp intercept one-minute high 1100
2811(config)#ip tcp intercept one-minute low 900
2811(config)#scheduler interval 500
*註:這裡用的是默認的intercept模式,個人感覺它比watch模式更牛逼,但缺點是路由器的CPU負擔加重,所以用了scheduler interval 500來優化一下。
c. 如果WEB伺服器是基於LINUX的,還可以將LINUX十分強大的IPTABLE防火牆用起來抵禦針對TCP 80埠的SYN FLOOD攻擊,舉例如下:
iptables -I INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 10 -j DROP
簡單講下:
第一條的意思是監視所有從eth0介面進來,目標埠為TCP 80的流量。
第二條的意思是在60秒內,如果對方試圖用同一個IP連接你的80埠超過10次,那麼將對方的連接斷掉。
3) UDP Flood攻擊
相較於基於ICMP的SMURF攻擊和基於TCP的SYN Flood攻擊, UDP Flood更難以防範,因為這貨是大名鼎鼎的無鏈接狀態協議(connectionless protocol),它根本不需要用任何程序建立連接就能傳輸數據,也就意味著不管你玩的是路由器還是防火牆,都無法像SYN FLOOD攻擊那樣做源探測,攻擊者可以隨意偽造大量虛假IP來進行攻擊,意味著你寫了ACL來過濾IP也是白寫。
那麼怎麼判斷中了UDP Flood攻擊?很簡單,不需要你去用什麼Wireshark來抓包研究分析,只需要在思科路由器上開啟CEF,然後show ip cache flow就行了,當然如果你說可以通過show process來查看CPU用量來判斷是否中招,也說得通,但是引起CPU用量高的原因太多太多,你不可能判斷這就是DDOS攻擊,更不能說它就是UDP Flood攻擊。
下面是我曾經實戰時經歷過的一次UDP Flood攻擊
2811#show ip cache flow
IP packet size distribution (90784136 total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .941 .001 .001 .004 .000 .000 .000 .000 .000 .003 .000 .000 .000 .000
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.000 .001 .046 .000 .002 .000 .000 .000 .000 .000 .000
IP Flow Switching Cache, 4456704 bytes
1885 active, 63651 inactive, 59960004 added
129803821 ager polls, 0 flow alloc failures
Active flows timeout in 30 minutes
Inactive flows timeout in 15 seconds
IP Sub Flow Cache, 402056 bytes
0 active, 16384 inactive, 0 added, 0 added to flow
0 alloc failures, 0 force free
1 chunk, 1 chunk added
last clearing of statistics never
Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)
-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
TCP-Telnet 11393421 2.8 1 48 3.1 0.0 1.4
TCP-FTP 236 0.0 12 66 0.0 1.8 4.8
TCP-FTPD 21 0.0 13726 1294 0.0 18.4 4.1
TCP-WWW 22282 0.0 21 1020 0.1 4.1 7.3
TCP-X 719 0.0 1 40 0.0 0.0 1.3
TCP-BGP 1 0.0 1 40 0.0 0.0 15.0
TCP-Frag 70399 0.0 1 688 0.0 0.0 22.7
TCP-other 47861004 11.8 1 211 18.9 0.0 1.3
UDP-DNS 582 0.0 4 73 0.0 3.4 15.4
UDP-NTP 287252 0.0 1 76 0.0 0.0 15.5
UDP-other 332110347 0.0 2 230 0.1 0.6 15.9
ICMP 11674 0.0 3 61 0.0 19.8 15.5
IPv6INIP 15 0.0 1 1132 0.0 0.0 15.4
GRE 4 0.0 1 48 0.0 0.0 15.3
Total: 399579570 14.8 1 196 22.5 0.0 1.5
從IP packet size distribution的內容可以看到, 現在2811路由器收到的94.1%的數據包都是介於33-64 Byte的(這是典型的UDP FLOOD攻擊的包的大小),正常情況下 ,你路由器收到的33-64 Byte的數據包不會超過1%,再看下面的數據包類型,UDP-other 332110347進一步證明了這就是不折不扣的UDP Flood攻擊!
對UDP Flood攻擊的防禦沒有太多可靠的方案,對網吧和小公司來說,只能在路由器上做一些加固以及對UDP流量限速,雖然可以緩解帶寬的壓力,但是也容易對合法流量造成誤判,如果有硬體防火牆的話,可以開啟指紋學習來對付UDP
Flood,不過不在我們的討論範圍內。防禦方案
假設內網網段為192.168.1.0 /24
a. 在外網入口方向過濾RFC 1918地址(老生常談的話題了,就不廢話了)
2811(config)#ip access-list extended 106
2811(config-ext-nacl)# deny ip 10.0.0.0 0.255.255.255 any
2811(config-ext-nacl)# deny ip 172.16.0.0 0.15.255.255 any
2811(config-ext-nacl)# deny ip 192.168.0.0 0.0.255.255 any
2811(config-ext-nacl)# permit ip any any
2811(config)# interface gi0/1
2811(config-if)# ip access-group 106 in
b. 在內網入口方向只允許自己的內網網段的流量通過
2811(config)#ip access-list extended 107
2811(config-ext-nacl)# permit ip 192.168.1.0 0.0.0.255 any
2811(config-ext-nacl)# deny ip any any
2811(config)# interface gi0/0
2811(config-if)# ip access-group 107 in
c. 關閉UDP診斷功能
2811(config)#no service udp-small-server
d. 對UDP包限速 ,注意,為了安全起見,我們不僅要對路由器的數據層面(Data Plane) ,也要用CoPP對控制層面(Control Plane)限速,所以這裡不能簡單用CAR來寫了,要用稍微高端點的流量整治(Policing)了。
2811(config)#ip access-list extended 108
2811(config-ext-nacl)# permit udp any any
2811(config)#class-map match-all UDP
2811(config-cmap)#match access-group name 108
2811(config)#policy-map UDP
2811(config-pmap)#class UDP
2811(config-pmap-c)# police 40000000 conform-action transmit exceed-action drop
exit
2811(config)# interface gi0/1
2811(config-if)#service-policy input UDP
2811(config)#control-plane
2811(config-cp)#service-policy input UDP
4) 用IOS Firewall來防範DDOS攻擊
考過CCIE R&S的應該都知道思科IOS設備有一個很強大的功能叫做IOS Firewall,即使是低端的思科路由器(800,1800,2800)也支持該功能,這可以為中小型網吧省下不少添置硬體防火牆的銀子,只不過IOS Firewall屬於比較高端的技術,99.9%的網吧網管壓根就沒聽說過這個東西,更不用說如何配置它。
IOS Firewall的配置模式分為兩種,一種是傳統的CBAC(Context-Based Access Control),另外一種是較新的,也是後來思科力推的Zone-Based模式 (CCIE R&S實驗考試考過的)。 鑒於CBAC將來遲早會有被淘汰的一天(思科從ASR 1000起,所有基於IOS-XE的設備已經不再支持CBAC),我們下面的配置全部基於Zone-Based模式。
從技術上來講,IOS Firewall主要有三種方式來抵禦DDOS攻擊
a. Aggressive aging of firewall sessions
b. Event Rate Monitoring
c. Half-Opened Connections Limit
今天我們先講第一個Aggressive aging of firewall sessions
Aggressive aging of firewall sessions顧名思義是一種強制老化(aging out)機制,需要定義三個參數:
1. 防火牆Session表的Session數量上限閾值
2. 防火牆Session表的Session數量下限閾值
3. Aging-out timing
具體工作原理如下:
當防火牆的Session表的session數量超過定義的Session數量上限閾值時,防火牆隨即進入aggressive aging period。
當防火牆的Session表的session數量低於定義的Session數量下限閾值時,aggressive aging period結束。
在aggressive aging period期間,防火牆當前所有的session會在你定義的Aging-out timing到期後全部被強制老化掉(也就是斷掉)。
舉個例子,如果你定義的aging-out timing是30秒, session 1始建於第10秒,session 2始建於第20秒,session 3始建於第30秒。那麼在防火牆進入aggressive aging period後,session 1會在第40秒時被防火牆強制斷掉, session 2會在第50秒被防火牆強制斷掉,同理session 3會在第60秒被防火牆強制斷掉,以此類推。
如果黑客試圖建立新session的速度超過了防火牆斷掉現有session的速度的話,防火牆會拒絕所有建立新session的請求。
配置:
Aggressive aging of firewall sessions有三種配置模式:per-box,deafult-VRF, per-VRF,這裡我們只講最常用也是最簡單的per-box配置。
第1步: 創建兩個Zone,分別取名Private和Public,將內網埠gi0/0劃分在Private Zone,外網埠gi0/1劃分在Public Zone
2811(config)#class-map type inspect match-any ddos-class
2811(config-cmap)#match protocol tcp
2811(config-cmap-c)#exit
2811(config)#parameter-map type inspect global
2811(config-profile)#redundancy
2811(config-profile)#exit
2811(config)#policy-map type inspect ddos-fw
2811(config-pmap)#class type inspect ddos-class
2811(config-pmap-c)#inspect
2811(config-pmap-c)#exit
2811(config-pmap)#class class-default
2811(config-pmap-c)#drop
2811(config-pmap-c)#exit
2811(config-pmap)#exit
2811(config)#zone security private
2811(config-sec-zone)#exit
2811(config)#zone security public
2811(config-sec-zone)#exit
2811(config)#zone-pairsecurity private2public source private destination public
2811(config-sec-zone-pair)#service-policy type inspect ddos-fw
2811(config-sec-zone-pair)#exit
2811(config)#interface gigabitethernet 0/0
2811(config-if)#zone-member security private
2811(config-if)#interface gigabitethernet 0/1
2811(config-subif)#zone-member security public
第2步: 配置Aggressive aging of firewall sessions,上限閾值1700,下限閾值1300,aging-out timing為10秒
2811(config)#parameter-map type inspect global
2811(config-profile)#per-box max-incomplete 2000 aggressive-aging 1500 low 1200
2811(config-profile)#per-box aggressive-aging high 1700 low 1300
2811(config-profile)#exit
2811(config)#parameter-map type inspect pmap1
2811(config-profile)#tcp synwait-time 30 ageout-time 10
未完待續
推薦閱讀:
※3條防騙妙計,值30萬,今天免費!
※技術分享:巴基斯坦的某APT活動事件分析
※花無涯帶你走進黑客世界18 加密演算法
※斯諾登主演的美國大片,你看過幾部?
※重磅發布!阿里聚安全 2016 年報-應用安全不容樂觀