TCP协议数据包及攻击分析

TCP/IP协议栈中一些报文的含义和作用

URG: Urget pointer is valid (紧急指针字段值有效)

SYN: 表示建立连接

FIN: 表示关闭连接

ACK: 表示响应

PSH: 表示有 DATA数据传输

RST: 表示连接重置。

1、++SYN++:一段TCP对话开始时的数据包,收到的主机将以syn+ack回应,并进入半连接状态,将此链接存入队列,等待75s(可设置)。
//:服务器接收到连接请求(syn= j),将此信息加入未连接队列,并发送请求包给客户(syn=k,ack=j+1),此时进入SYN_RECV状态。当服务器未收到客户端的确认包时,重发请求包,一直到超时,才将此条目从未连接队列删除。
//:SYN数据包本质上是将syn位设为1的TCP包。因此,如果你的防火墙丢弃所有的发往外网接口的SYN包,那么你将不 能让外部任何主机主动建立连接。

++可能造成的攻击方式++:SYN泛洪。通过大量发送目标不可达的、伪造的IP和端口号的syn连接包,大量消耗被攻击主机带宽和流量,可造成DDOS攻击
++可能的防护方式++:将首次收到的syn包丢弃,由于tcp保证到达的特性,正常访问的用户会重传一个syn,而恶意构造的则不会重传。缺点是要维护一个已到达的syn数据包的表,以便确定是否已经首次抛弃。


2、++ACK++:TCP的报文到达确认(ACK),是对接收到的数据的最高序列号的确认,并向发送端返回一个下次接收时期望的TCP数据包的序列号(Ack Number)。例如,主机A发送的当前数据序号是400,数据长度是100,则接收端收到后会返回一个确认号是501的确认号给主机A
//:TCP协议应当保证数据报按序到达接收方。如果接收方收到的数据报文没有错误,只是未按序号,这种现象如何处理呢?TCP协议本身没有规定,而是由TCP协议的实现者自己去确定。通常有两种方法进行处理:一是对没有按序号到达的报文直接丢弃,二是将未按序号到达的数据包先放于缓冲区内,等待它前面的序号包到达后,再将它交给应用进程。后一种方法将会提高系统的效率。例如,发送方连续发送了每个报文中100个字节的TCP数据报,其序号分别是1,101,201,…,701。假如其它7个数据报都收到了,而201这个数据报没有收到,则接收端应当对1和101这两个数据报进行确认,并将数据递交给相关的应用进程,301至701这5个数据报则应当放于缓冲区,等到201这个数据报到达后,然后按序将201至701这些数据报递交给相关应用进程,并对701数据报进行确认,确保了应用进程级的TCP数据的按序到达。(++若恶意未发送201数据包,而继续发送后续数据,缓冲区是否会溢出?++)

++可能的攻击方式++:如上所述,是否存在缓冲区被数据填满的情况而导致拒绝服务或者数据溢出?


3、++FIN++:FIN(ISH)为TCP报头的码位字段,该位置为1的含义为发送方字节流结束,用于关闭连接。
当两端交换带有FIN标志的TCP报文段并且每一端都确认另一端发送的FIN包时,TCP连接将会关闭。FIN位字面上的意思是连接一方再也没有更多新的数据发送。然而,那些重传的数据会被传送,直到接收端确认所有的信息  
//:用于TCP四次握手断开连接,即互相发送ACK/FIN数据包,彼此ACK确认。
//:ACK/FIN包(ACK和FIN标记设为1)通常被认为是FIN(终结)包.然而,由于连接还没有关闭,FIN包总是打上ACK标记.没有ACK标记而仅有FIN标记的包不是合法的包,并且通常被认为是恶意的

++可能的攻击方式++:由于TCP关闭连接四次握手,其中两次服务器发送数据包;1:可以丢弃客户端发送FIN之后的服务器相应的ACK/FIN数据包。2:可以丢弃服务器主动发送的FIN数据包;即:当客户端发送FIN数据包之后,丢弃任何从服务器传来的数据包。会导致服务器为结束连接同时在超时时间内重发两份数据包


4、++RST++:表示复位,用来异常的关闭连接,在TCP的设计中它是不可或缺的。就像上面说的一样,发送RST包关闭连接时,不必等缓冲区的包都发出去(不像上面的FIN包),直接就丢弃缓存区的包发送RST包。而接收端收到RST包后,也不必发送ACK包来确认。TCP处理程序会在自己认为的异常时刻发送RST包。例如,A向B发起连接,但B之上并未监听相应的端口,这时B操作系统上的TCP处理程序会发RST包。又比如,AB正常建立连接了,正在通讯时,A向B发送了FIN包要求关连接,B发送ACK后,网断了,A通过若干原因放弃了这个连接(例如进程重启)。网通了后,B又开始发数据包,A收到后表示压力很大,不知道这野连接哪来的,就发了个RST包强制把连接关了,B收到后会出现connect reset by peer错误。

++可能的攻击方式++:A和服务器B之间建立了TCP连接,此时C伪造了一个TCP包发给B,使B异常的断开了与A之间的TCP连接,就是RST攻击了.
实际上从上面RST标志位的功能已经可以看出这种攻击如何达到效果了。那么伪造什么样的TCP包可以达成目的呢?我们至顶向下的看。1、假定C伪装成A发过去的包,这个包如果是RST包的话,毫无疑问,B将会丢弃与A的缓冲区上所有数据,强制关掉连接。2、如果发过去的包是SYN包,那么,B会表示A已经发疯了(与OS的实现有关),正常连接时又来建新连接,B主动向A发个RST包,并在自己这端强制关掉连接。这两种方式都能够达到复位攻击的效果。

似乎挺恐怖,然而关键是,如何能伪造成A发给B的包呢? 这里有两个关键因素,源端口和序列号。++一个TCP连接都是四元组,由源IP、源端口、目标IP、目标端口唯一确定一个连接++。所以,如果C要伪造A发给B的包,要在上面提到的IP头和TCP头,把源IP、源端口、目标IP、目标端口都填对。这里B作为服务器,IP和端口是公开的,A是我们要下手的目标,IP当然知道,但A的源端口就不清楚了,因为这可能是A随机生成的。当然,如果能够对常见的OS如windows和linux找出生成source port规律的话,还是可以搞定的。序列号问题是与滑动窗口对应的,伪造的TCP包里需要填序列号,如果序列号的值不在A之前向B发送时B的滑动窗口内,B是会主动丢弃的。所以我们要找到能落到当时的AB间滑动窗口的序列号。这个可以暴力解决,因为一个sequence长度是32位,取值范围0-4294967296,如果窗口大小像上图中我抓到的windows下的65535的话,只需要相除,就知道最多只需要发65537(4294967296/65535=65537)个包就能有一个序列号落到滑动窗口内。RST包是很小的,IP头+TCP头也才40字节,算算我们的带宽就知道这实在只需要几秒钟就能搞定


ICMP数据报

++1、目的不可达++: 当路由器收到一个无法传递下去的IP报文时,会发送ICMP目的不可达报文(Type为3)给IP报文的源发送方。报文中的Code就表示发送失败的原因。

Code

0 = net unreachable;

1 = host unreachable;

2 = protocol unreachable;

3 = port unreachable;

4 = fragmentation needed and DF set;

5 = source route failed.


++2、传输时间超时++

网络传输IP数据报的过程中,如果IP数据包的TTL值逐渐递减为0时,需要丢弃数据报。这时,路由器需要向源发送方发送ICMP超时报文(Type为11),Code为0,表示传输过程中超时了。

一个IP数据报可能会因为过大而被分片,然后在目的主机侧把所有的分片重组。如果主机迟迟没有等到所有的分片报文,就会向源发送方发送一个ICMP超时报文,Code为1,表示分片重组超时了。


++3、参数错误报文++:当路由器或主机处理数据报时,发现因为报文头的参数错误而不得不丢弃报文时,需要向源发送方发送参数错误报文(Type为12)。当Code为0时,报文中的Pointer表示错误的字节位置。


++4、源冷却++:路由器在处理报文时会有一个缓存队列。如果超过最大缓存队列,将无法处理,从而丢弃报文。并向源发送方发一个ICMP源冷却报文(Type为4),告诉对方:“嘿,我这里客满了,你迟点再来。”


++5、重定向++:路由器在处理报文时会有一个缓存队列。如果超过最大缓存队列,将无法处理,从而丢弃报文。并向源发送方发一个ICMP源冷却报文(Type为4),告诉对方:“嘿,我这里客满了,你迟点再来。”


++6、请求回显或回显应答++:Type(8)是请求回显报文(Echo);Type(0)是回显应答报文(Echo Reply)。

请求回显或回显应答报文属于查询报文。Ping就是用这种报文进行查询和回应


++6、时间戳报文++:时间戳报文是用来记录收发以及传输时间的报文。Originate Timestamp记录的是发送方发送报文的时刻;Receive Timestamp记录的是接收方收到报文的时刻;Transmit Timestamp表示回显这最后发送报文的时刻。


++7、信息请求或信息响应++:这种报文是用来找出一个主机所在的网络个数(一个主机可能会在多个网络中)。报文的IP消息头的目的地址会填为全0,表示this,源地址会填为源IP所在的网络IP。

image


在协议层面的攻击

1、TCP SYN FLOOD攻击
2、TCP 完整连接攻击
3、TCP 连接结束半连接攻击
4、UDP 流量攻击
5、DNS 放大攻击

posted @ 2018-10-06 21:21  柏凝  阅读(2690)  评论(0编辑  收藏  举报