新人學習，如有錯誤請見諒和指正。如果大家參考，請多找資料和實驗進行比對研究。謝謝

iphdr->tot_len 總長度字段(16位)是指整個IP數據報的長度,以字節為單位。利用首部長度字段和總長度字段,就可以知道 IP數據報中數據內容的起始位置和長度。由于該字段長16比特,所以IP數據報最長可達65535字節 總長度字段是IP首部中必要的內容,因為一些數據鏈路(如以太網)需要填充一些數據以達到最小長度。盡管以太網的最小幀長為46字節,但是IP數據可能會更短。如果沒有總長度字段,那么IP層就不知道46字節中有多少是IP數據報的內容。

tcphdr->doff
TCP頭長度，指明了在TCP頭部包含多少個32位的字。此信息是必須的，因為options域的長度是可變的，所以整個TCP頭部的長度也是變化的。從技術上講，這個域實際上指明了數據部分在段內部的其起始地址(以32位字作為單位進行計量)，因為這個數值正好是按字為單位的TCP頭部的長度，所以，二者的效果是等同的

由這兩個參數來規定tcp內數據包的大小？但是以太網的填充字段（Padding）怎么辦。?

TCP數據包的大小是很大的，但是如果超過MTU就需要分片發送數據包。所以在syn攻擊里應盡可能采用單包發送，提高效率。【詳見附1】

test1:
操作：修改ip.tot_len字段（加20）并且給發送的總包加上相應字段內存
結果：失敗了，收到數據包大小為74（54+20），尾部的填充6Byte不見了，并且協議解析為NBSS
【通過搜索相關知識，了解到eth.padding的6Byte是以太網的填充字段，為了讓數據包對齊32bits進行傳輸】
【通過相關查詢，了解到NBSS是139端口（我攻擊的端口）提供的共享打印機服務，那是不是我換個端口就好了？】

test2:
操作：./awl -i 192.168.45.1 -p 1399 -I 192.168.45.129 -t 20【自己改的syn攻擊程序，-i是對方ip，-I是自己ip，-p是對方端口，其他未設定參數（mac、port）默認采用隨機】
結果：成功了，收到數據包大小為74，Data字段為0填充。看來這個真的是跟端口有關系呢。。

test3:
操作：./awl -i 192.168.45.1 -p 8080 -I 192.168.45.129 -m 00:50:56:c0:00:08 -n 1【打開了主機的apache，端口8080開啟，指定對象的mac和隨機的源ip位】
結果：成功造成攻擊，服務器收到syn后進行arp請求查找源ip的mac地址，保持SYN_RECEIVE狀態(回復syn+ack后由于對方主機的響應端口并沒有開啟的程序，收到ICMP的回執并繼續進行重試)，如下圖。當停止攻擊后，保持的狀態迅速被刪掉。（增加包大小成功）
圖示：

















































test4:
操作：同3，把數據包降為無data的包，并且隨機4個ip進行攻擊
結果：apache死掉了。。所以我也不知道速度，需要重啟一下- -不過參見以前的記錄，六個進程同時開啟情況下有64Kpackages/s，在單包60Byte情況下占用帶寬30Mbits/s




【附1:MTU大小】
以太網EthernetII最大的數據幀是1518Bytes，刨去以太網幀的幀頭14Bytes和幀尾CRC校驗部分4Bytes，那么剩下承載上層協議的Data域最大就只有1500Bytes，這個值我們就把它稱之為MTU。

UDP?包的大小就應該是?1500 - IP頭(20) - UDP頭(8) = 1472(BYTES)
TCP?包的大小就應該是?1500 - IP頭(20) - TCP頭(20) = 1460 (BYTES)

當發送包大小大于MTU時，就會再ip層做分包處理。如果使用UDP協議，當IP層組包發生錯誤，那么包就會被丟棄。接收方無法重組數據報，將導致丟棄整個IP數據報。UDP不保證可靠傳輸；但是TCP發生組包錯誤時，該包會被重傳，保證可靠傳輸。

總結

以上是生活随笔為你收集整理的第一篇，怎么增加SYN数据包的大小（syn flood攻击实验）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。