SYN Cookie在Linux核心中的實現

來源:互聯網
上載者:User


概述
在目前以IPv4為支撐的網路通訊協定上搭建的網路環境中,SYN Flood是一種非常危險而常見的DoS攻擊方式。到目前為止,能夠有效防範SYN Flood攻擊的手段並不多,而SYN Cookie就是其中最著名的一種。SYN Cookie原理由D. J. Bernstain和 Eric Schenk發明。在很多作業系統上都有各種各樣的實現。其中包括Linux。本文就分別介紹一下SYN Flood攻擊和SYN Cookie的原理,更重要的是介紹Linux核心中實現SYN Cookie的方式。最後,本文給出一種增強目前Linux中SYN Cookie功能的想法。
一、SYN Flood攻擊
SYN Flood攻擊是一種典型的拒絕服務型(Denial of Service)攻擊。所謂拒絕服務型攻擊就是通過進行攻擊,使受害主機或網路不能夠良好的提供服務,從而間接達到攻擊的目的。
SYN Flood攻擊利用的是IPv4中TCP協議的三向交握(Three-Way Handshake)過程進行的攻擊。大家知道協議規定,如果一端想向另一端發起TCP串連,它需要首先發送TCP SYN 包到對方,對方收到後發送一個TCP SYN+ACK包回來,發起方再發送TCP ACK包回去,這樣三向交握就結束了。我們把TCP串連的發起方叫作"TCP客戶機(TCP Client)",TCP串連的接收方叫作"TCP伺服器(TCP Server)"。值得注意的是在TCP伺服器收到TCP SYN request包時,在發送TCP SYN+ACK包回TCP客戶機前,TCP伺服器要先分配好一個資料區專門服務於這個即將形成的TCP串連。一般把收到SYN包而還未收到ACK包時的串連狀態成為半開串連(Half-open Connection)。
在最常見的SYN Flood攻擊中,攻擊者在短時間內發送大量的TCP SYN包給受害者,這時攻擊者是TCP客戶機,受害者是TCP伺服器。根據上面的描述,受害者會為每個TCP SYN包分配一個特定的資料區,只要這些SYN包具有不同的源地址(這一點對於攻擊者來說是很容易偽造的)。這將給TCP伺服器系統造成很大的系統負擔,最終導致系統不能正常工作。
二、SYN Cookie原理
SYN Cookie是對TCP伺服器端的三向交握協議作一些修改,專門用來防範SYN Flood攻擊的一種手段。它的原理是,在TCP伺服器收到TCP SYN包並返回TCP SYN+ACK包時,不分配一個專門的資料區,而是根據這個SYN包計算出一個cookie值。在收到TCP ACK包時,TCP伺服器在根據那個cookie值檢查這個TCP ACK包的合法性。如果合法,再分配專門的資料區進行處理未來的TCP串連。
從上面的介紹可以看出,SYN Cookie的原理比較簡單。到實際的應用中,它有多種不同的實現方式。
三、Linux核心中的SYN Cookie實現
Linux核心中對SYN Flood有很好的防護。以下的討論都是針對Linux2.4.20核心進行的。在每一個sock都有一個tcp_opt即這個sock的TCP選項。在tcp_opt其中有一個tcp_listen_opt,這裡儲存的是這個sock在LISTEN狀態下時儲存的一些選項,其中有一個open_request結構的數組,數組長度為TCP_SYNQ_HSIZE(512)。所有這些表示在一個sock,最多可以同時開啟512個半開串連(這是在不考慮其他約束條件時的最大值,實際情況中不會達到這個值)。當這個數組滿了時,新來的open_request會頂替掉一個老的open_request。這樣,即使沒有啟動SYN Cookie,也能夠在SYN Flood發生時保護系統免於癱瘓。問題是這種處理方法會在面對SYN Flood攻擊時丟掉正常的TCP串連請求。SYN Cookie的作用恰恰是保證在面對SYN Flood攻擊時,一方面能夠拒絕非法的TCP串連請求,一方面正常串連可以被建立。
Linux核心對TCP流程的處理主要在tcp_ipv4.c檔案中的函數實現。具體的,當處理TCP SYN包時,系統進入tcp_v4_conn_request函數。其中調用cookie_v4_init_sequence產生一個ISN(Initial Sequence Number)。Linux核心把它作為SYN Cookie流程中的cookie。
cookie_v4_init_sequence函數在syncookies.c檔案中定義,它又調用random.c檔案中的secure_tcp_syn_cookie函數。cookie的實質計算是在這個函數中進行的。
在random.c檔案裡給出secure_tcp_syn_cookie函數的定義之前給出兩個宏,它們的定義分別為
#define COOKIEBITS 24
#define COOKIEMASK (((__u32)1 << COOKIEBITS) - 1)
COOKIEBITS表示cookie的位元長度;COOKIEMASK是一個COOKIEBITS長的位元串,所有位元都是1。
還有兩個位元串,被定義成一個__u32的二維數組
static __u32syncookie_secret[2][16-3+HASH_BUFFER_SIZE];
其中所有的位元值在secure_tcp_syn_cookie中被隨機的賦予,用get_random_bytes函數。它們成為製作cookie的密鑰。這兩個被隨機產生的位元串是整個SYN Cookie實現方案的關鍵。另外還有一個開關syncookie_init控制對這兩個密鑰的改動。
還需要指出,在檔案syncookies.c中定義有一個__u16組成的表static __u16 const msstab[],這個表中儲存的是一些可能的MSS(Maximum Segment Size)值。
secure_tcp_syn_cookie函數的傳回值就是計算得到的ISN值,即cookie。為了描述方便,我們給出如下定義:
tmp1 := saddr + daddr + ((sport<<16)+dport) + syncookie_secret[0]
tmp2 := saddr + daddr + ((sport<<16)+dport) + syncookie_secret[1]
tmp11 := HASH_TRANSFORM(tmp1[16], tmp1)
tmp22 := HASH_TRANSFORM(tmp2[16], tmp2)
A := tmp11[0][17]
B := tmp22[1][17]
sseq := ntohl(skb->h.th->seq) 這裡的skb是攜帶TCP SYN的那個skb
count1 := jiffies/(HZ*60) 目前時間的分鐘值
data1 := msstab
從前往後最後一個小於skb中攜帶的MSS值的值的索引(值得注意的是兩個密鑰在第一次被初始化後,就不會再有改動,直到系統重新啟動。因此可以認為它是一個常值。)
有了上面的定義我們可以得到cookie等於
isn := A+sseq + (count1<<COOKIEBITS) + (B+data1)&COOKIEMASK
這個isn被賦予返回的TCP SYN+ACK包中,作為其中的ISN值。這就是cookie 的產生過程。在這個過程中,沒有在本地為這個串連請求分配任何儲存空間。
在TCP伺服器收到TCP ACK包時,相應的要進行SYN Cookie的檢查。這個檢查過程在函數tcp_v4_hnd_req中的cookie_v4_check函數開始。cookie_v4_check調用cookie_check函數,cookie_check函數調用check_tcp_syn_cookie函數。
check_tcp_syn_cookie函數在random.c中定義,是與前面介紹的
secure_tcp_syn_cookie函數對應的函數,檢查從TCP ACK中提取出的ISN值。
在check_tcp_syn_cookie中假定ISN的值如下
isn := A+sseq + (count2<<COOKIEBITS) + (B+data2)&COOKIEMASK
這裡的A、B都是根據當前這個skb中的地址資訊和syncookie_secret算出來的;sseq是根據這個skb中的seq值算出的。
有了上面這些值,TCP伺服器就可以反算出count2和data2。理論上來說,只要這個isn是原來那個isn,應該有
count2 == count1
data2 == data1
但是這種結論僅僅是一個理論情況。因為在TCP伺服器端並沒有儲存原來的count1和data1,因此不能直接進行比較。TCP伺服器採取的方法是:
1)計算出當前的分鐘值
count3 := jiffies/(HZ*60)
用count3與count2比較,如果差值超過COUNTER_TRIES(4)分鐘,則認為這 個ACK包不合法。
2)看data2是不是一個合法的msstab的索引,也就是說是不是小於NUM_MSS, 即(sizeof(msstab)/sizeof(msstab[0]) - 1)。如果小於,則認為這個ACK 合法,否則認為非法。
上面介紹的就是Linux核心Linux2.4.20中對SYN Cookie的實現方式。下面討論一下它的合理性。希望得到的結論是這種方案可以有效實現一般TCP的串連,同時可以防止SYN Flood攻擊。
從上面的介紹來說,合法的TCP串連請求一定可以通過SYN Cookie流程。 另一方面我們看SYN Cookie在系統受到各種SYN Flood攻擊時會採取的行為。 最一般的SYN Flood攻擊方式是攻擊者作為TCP客戶機發送大量TCP SYN包而不再發送其他的包。這時SYN Cookie會為每個SYN包計算出相應的ISN值,並返回SYN+ACK包,而在本地將不分配任何儲存空間,因此不會被成功攻擊。
根據SYN Cookie的原理,攻擊者有可能直接發送大量ACK包。這時SYN Cookie提取出每個包的isn值,並假定它有下面的格式
isn := A+sseq + (count<<COOKIEBITS) + (B+data)&COOKIEMASK
反算出count和data。
因為攻擊者並不知道這裡的A和B,因此經過反算出的count和data幾乎不可能都合理,因此TCP伺服器也幾乎不可能為這些ACK包分配儲存空間,這也就說明了SYN Cookie達到起到了抵擋SYN Flood攻擊的作用。
四、SYN Cookie Firewall
從上面的介紹可以看到,Linux核心中的SYN Cookie機制主要的功能是防止本機遭受SYN Flood攻擊的,但是在很多情況下,僅僅實現這樣的SYN Cookie機制是不夠的。如果我們要考慮的是一個網關模式的防火牆,它不僅要保護本機免受各種網路攻擊,還要保護它後面的所有對外有開放TCP連接埠的主機免受這些攻擊。比如一個區域網路中有個伺服器開放了FTP服務給外界,這個伺服器主機就有可能遭受到來自互連網上的SYN Flood攻擊。而這時的防火牆會將所有的攻擊SYN包轉寄給受害主機。
一種杜絕這種情況的方法是SYN Cookie Firewall。它是SYN Cookie的一種擴充形式。總的來說,它是利用原來SYN Cookie的原理在內網和外網之間實現TCP三向交握過程的代理(proxy)的機制。
為了方便描述,我們假定一個外在的TCP客戶機C希望通過防火牆F串連到區域網路中的一個TCP伺服器S。
在防火牆收到來自外網的SYN包時,它並不直接進行轉寄,而是緩衝在本地,再按照原來SYN Cookie的機制製作好一個針對這個SYN包的SYN+ACK包,注意,這個SYN+ACK包中的ack順序號為特製的cookie值c,更重要的是這個包的的源地址被偽造成了S的地址(為了描述方便,我們這裡暫時不考慮NAT等其他因素)。這樣C會接收到這個SYN+ACK包,並認為是從S反饋回來的。於是C再響應一個ACK包,並認為與S的TCP串連已經建立起來。這時防火牆F收到這個ACK包,按照前面的描述的SYN Cookie原理來檢查這個ACK中的ack順序號。如果認為合法,F將本機快取的來自C的SYN包發送給S,這時S會響應一個SYN+ACK包到C,其中也攜帶一個seq號, 我們設為c`。當然這個包不會到達C,而是由防火牆F截取,F根據這個包中的序號等資訊,造一個ACK包響應到S。這時的情況是:C認為自己已經與S建立了TCP串連;S認為自己與C建立了TCP串連。以後的TCP資料內容可以直接穿過防火牆F,在S和C之間互動。

是SYN Cookie Firewall的工作原理,它相當於在TCP Server與TCP Client之間實現了對三向交握協議的代理。第一次"三向交握"在TCP Client與防火牆之間進行,第二次"三向交握"在防火牆與TCP Server之間。在第一次"三向交握"時使用前面介紹的SYN Cookie流程。有一個問題在進行兩次"三向交握"時出現了:,進行第一次"三向交握"後,TCP Client認為後續資料包的seq值從c+1開始,而進行第二次"三向交握"後,TCP Server認為後續發來的資料包的seq值從c`+1開始, c是cookie,c`是TCP Server隨機產生的。c和c`幾乎不可能相等,也就是說在完成上面的兩個"三向交握"後,如果不進行其他動作,後續從TCP Client到TCP Server的資料包都將被認為順序號不對而被丟掉。一種補救方法就是在防火牆本地儲存一個值δ

δ = |c - c`|
利用這個差值,在每個資料包經過防火牆時,將其seq值修改一下,這樣,後續的資料流量可以完美地在TCP Server和TCP Client之間傳輸了。
總結
現在普遍使用的IPv4協議帶有很多安全上的問題,其中面對SYN Flood攻擊的軟弱就是一點。在不改變TCP三向交握流程的情況下,TCP Server幾乎不可能有效防範SYN Flood的攻擊。要保證完全防範SYN Flood,必須修改三向交握協議。SYN Cookie是一種很有效方法。它的思想比較簡單,主要是如何具體的實現,Linux系統也提供了一種實現。作者通過研讀Linux2.4.20核心中的代碼,基本瞭解了Linux核心中實現SYN Cookie的手段,將其總結成文字,與對SYN Cookie同樣感興趣的朋友分享、交流

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.