第一篇,怎么增加SYN数据包的大小(syn flood攻击实验)

新人学习,如有错误请见谅和指正。如果大家参考,请多找资料和实验进行比对研究。谢谢

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的回执并继续进行重试),如下图。当停止攻击后,保持的状态迅速被删掉。(增加包大小成功)
图示:
第一篇,怎么增加SYN数据包的大小(syn flood攻击实验)_第1张图片
















































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发生组包错误时,该包会被重传,保证可靠传输。

你可能感兴趣的:(DDoS攻防学习)