拒絕服務攻擊（DDoS）從1970年出現直到今天都依然在作祟，並給全球范圍內的各大組織帶來了不可估量的損失。
SYN Flood是互聯網上最經典的DDoS攻擊方式之一，最早出現於1999年左右，雅虎是當時最著名的受害者。
SYN Flood攻擊利用了TCP三次握手的缺陷，能夠以較小代價使目標服務器無法響應，且難以追查。
SYN flood是一種常見的DOS（denial of service拒絕服務）和DDos (distributed denial of serivce 分布式拒絕服務）攻擊方式。這是一種使用TCP協議缺陷，發送大量的偽造的TCP連接請求，使得被攻擊方cpu或內存資源耗盡，最終導致被攻擊方無法提供正常的服務。
TCP SYN Flood攻擊原理
TCP SYN Flood攻擊利用的是TCP的三次握手（SYN -> SYN/ACK -> ACK），假設連接發起方是A，連接接受方是B，
即B在某個端口（Port）上監聽A發出的連接請求，過程如下圖所示，左邊是A，右邊是B。
A首先發送SYN（Synchronization）消息給B，要求B做好接收數據的准備；B收到后反饋SYN-ACK（Synchronization-Acknowledgement） 消息給A，這個消息的目的有兩個：(1) 向A確認已做好接收數據的准備，(2) 同時要求A也做好接收數據的准備，此時B已向A確認好接收狀態，並等待A的確認，連接處於半開狀態（Half-Open），顧名思義只開了一半；A收到后再次發送ACK(Acknowledgement)消息給B，向B確認也做好了接收數據的准備，至此三次握手完成，“連接”就建立了，實際上只是雙方都按對方的要求進入了可以接收消息的狀態。以上彼此要求對方確認的“狀態”主要是雙方將要使用的消息序號(SquenceNum)，TCP為保證消息按發送順序抵達接收方的上層應用，需要用消息序號來標記消息的發送先后順序的。TCP是“雙工”(Duplex)連接，同時支持雙向通信，也就是雙方同時可向對方發送消息，其中SYN和SYN-ACK消息開啟了A→B的單向通信通道（B獲知了A的消息序號）；SYN-ACK和ACK消息開啟了B→A單向通信通道（A獲知了B的消息序號）。
以上討論的是在雙方誠實可信，網絡正常的理想狀況下建立連接。但實際情況是，網絡可能不穩定會丟包，使握手消息不能抵達對方，也可能是對方故意不按規矩來，故意延遲或不發送握手確認消息。假設B通過某TCP端口提供服務，B在收到A的SYN消息時，積極的反饋了SYN-ACK消息，使連接進入半開狀態，因為B不確定自己發給A的SYN-ACK消息或A反饋的ACK消息是否會丟在半路，所以會給每個待完成的半開連接都設一個Timer，如果超過時間還沒有收到A的ACK消息，則重新發送一次SYN-ACK消息給A，直到重試超過一定次數時才會放棄。
B為幫助A能順利連接，需要分配內核資源維護半開連接，那么當B面臨海量的大忽悠A時，如上圖所示，SYN Flood攻擊就形成了。攻擊方A可以控制肉雞向B發送大量SYN消息但不響應ACK消息，或者干脆偽造SYN消息中的Source IP，使B反饋的SYN-ACK消息石沉大海，導致B被大量注定不能完成的半開連接占據，直到資源耗盡，停止響應正常的連接請求。
防范措施：
1、降低SYN timeout時間，使得主機盡快釋放半連接的占用
2、采用SYN cookie設置，如果短時間內連續收到某個IP的重復SYN請求，則認為受到了該IP的攻擊，丟棄來自該IP的后續請求報文
3、在網關處設置過濾，拒絕將一個源IP地址不屬於其來源子網的包進行更遠的路由
————————————————
版權聲明：本文為CSDN博主「木霖森77」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/mulinsen77/java/article/details/88925672
轉載請注明：“轉自綠盟科技博客”： 原文鏈接.
歡迎大家關注我的微信公眾號，獲取你不知道的寶藏。
