DDOS/CC攻击
TCP 相关知识
传输控制协议(TCP,Transmission Control Protocol)是一种面向连接的、可靠的、基于字节流的传输层通信协议。
TCP首部格式如下:
-
长度共20字节
-
第1~2字节:源端口号
-
第3~4字节:目的端口号
源端口号+ip首部中的源ip地址 + 目的端口号+ip首部中的目的ip地址,唯一的确定了一个tcp连接。对应编码级别的socket。
-
第5~8字节:32位序列号
tcp提供全双工服务,两端都有各自的序号。编号:解决网络包乱序的问题
序号如何生成:不能是固定写死的,否则断网重连时序号重复使用会乱套。tcp基于时钟生成一个序号,每4微秒加一,到2^32-1时又从0开始
-
第9~12字节:32位确认号
上次成功收到数据字节序号加1,ack为1才有效。确认号:解决丢包的问题
-
第13位字节:首部长度。因为任选字段长度可变。
-
后6位:保留
-
随后6位:标识位。控制各种状态
- URG:为1时,表示紧急指针有效
- ACK:确认标识,连接建立成功后,总为1。为1时确认号有效
- PSH:接收方应尽快把这个报文交给应用层
- RST:复位标识,重建连接
- SYN:建立新连接时,该位为0
- FIN:关闭连接标识
-
第15-16字节:窗口大小。接收端期望接收的字节数。解决流量控制的问题
-
第17-18字节:校验和。由发送端计算和存储,由接收端校验。解决数据正确性问题
-
第19-20字节:紧急指针
TCP连接的特点:
- 提供面向连接、可靠的 字节流服务
- 为上层应用层提供服务,不关心具体传输的内容是什么,也不知道是二进制流,还是ascii字符
TCP如何保证可靠性?
- 分块传送:数据被分割成最合适的数据块(UDP的数据报长度不变)
- 等待确认:通过定时器等待接收端发送确认请求,收不到确认则重发
- 确认回复:收到确认后发送确认回复(不是立即发送,通常推迟几分之一秒)
- 数据校验:保持首部和数据的校验和,检测数据传输过程有无变化
- 乱序排序:接收端能重排序数据,以正确的顺序交给应用端
- 重复丢弃:接收端能丢弃重复的数据包
- 流量缓冲:两端有固定大小的缓冲区(滑动窗口),防止速度不匹配丢数据
TCP三次握手
见图:
为什么是三次握手?
tcp连接是全双工的,数据在两个方向上能同时传递。
所以要确保双方,同时能发数据和收数据
- 第一次握手:证明了发送方能发数据
- 第二次握手:ack确保了接收方能收数据,syn确保了接收方能发数据
- 第三次握手:确保了发送方能收数据
- 实际上是四个维度的信息交换,不过中间两步合并为一次握手了。
- 四次握手浪费,两次握手不能保证“双方同时具备收发功能
TCP 四次挥手
见图:
为什么是四次挥手?
因为tcp连接是全双工的,数据在两个方向上能同时传递。同时tcp支持半关闭(发送一方结束发送还能接收数据的功能),因此每个方向都要单独关闭,且收到关闭通知需要发送确认回复。
为什么有个2MSL?
MSL是最大报文生存时间。为了保证客户端发送的最后一个ACK报文段能够到达服务器。即最后一个确认报文可能丢失,服务器会超时重传,然后服务器发送FIN请求关闭连接,客户端发送ACK确认。一个来回是两个报文生命周期。如果没有等待时间,发送完确认报文段就立即释放连接的话,服务器就无法重传,因此也就收不到确认,就无法按步骤进入CLOSED状态。并且可以防止已经失效的连接请求报文出现在连接中。经过2MSL,在这个连续持续的时间内,产生的所有报文段就可以都从网络消失
UDP 相关知识
用户数据报协议 (UDP,User Data Protocol) 只在 IP 的数据报服务之上增加了很少一点的功能,这就是复用和分用的功能以及查错检测的功能。
UDP协议特点:
- 面向无连接的
- 不可靠交付。尽最大努力交付,不保证交付成功
- 面向报文的。
- 没有拥塞控制。网络出现的拥塞不会使源主机的发送速率降低
- 支持一对一、一对多、多对一和多对多的交互通信
- 首部开销小,只有8个字节,比 TCP 的20个字节的首部要短
UDP首部格式如下:
DDOS攻击
DDOS(Distributed Deny of Service):分布式拒绝服务攻击,即处于不同位置的多个攻击者同时向一个或数个目标发动攻击,或者一个攻击者控制了位于不同位置的多台机器并利用这些机器对受害者同时实施攻击。
SYN Flood 攻击
SYN Flood
攻击是当前网络上最为常见的DDos攻击,也是最为经典的拒绝服务攻击。很多操作系统,甚至防火墙、路由器都无法有效地防御这种攻击,而且由于它可以方便地伪造源地址,追查起来非常困难。
-
攻击方式
利用TCP协议实现上的一个缺陷,通过向网络服务所在端口发送大量的伪造源地址的半连接请求,造成目标服务器中的半连接队列被占满,耗费CPU和内存资源,使服务器超负荷,从而阻止其他合法用户进行访问。
如图:
-
攻击特征
-
CPU占用高
-
网络连接状态出现大量的SYN_RECEIVED状态,可通过命令查看
1
netstat -na
-
-
防御方式
- 源认证。由于TCP是面向连接的,是可靠传输,可通过识别源是否为正常用户进行防御。
TCP 全连接攻击
这种攻击是为了绕过常规防火墙的检查而设计的,一般情况下,常规防火墙大多具备syn cookies
或者syn proxy
能力,能够有效应对伪造的IP攻击,但对于正常的TCP连接是放过的。但殊不知很多网络服务程序能接受的TCP连接数是有限的,一旦有大量的TCP连接,即便是正常的,也会导致网站访问非常缓慢甚至无法访问。
-
攻击方式
通过许多僵尸主机不断地与受害服务器建立大量的TCP连接,直到服务器的内存等资源被耗尽而被拖跨,从而造成拒绝服务。
-
防御方式
【暂无】
TCP 混乱数据包攻击
TCP混乱数据包攻击与Syn Flood
攻击类似,发送伪造源IP的TCP数据包,只不过TCP头的TCP Flags
部分是混乱的,可能是syn,ack,syn+ack,syn+rst
等等,会造成一些防护设备处理错误锁死,消耗服务器CPU内存的同时还会堵塞带宽,在迷惑对手的时候施展最后的致命一击。
UDP Flood 攻击
UDP Flood
是日渐猖獗的流量型DOS攻击。由于UDP协议是一种无连接的服务,在UDP FLOOD攻击中,攻击者可发送大量伪造源IP地址的小UDP包,由于UDP协议是无连接性的,所以只要开了一个UDP的端口提供相关服务的话,那么就可针对相关的服务进行攻击。
-
攻击方式
利用大量UDP小包冲击DNS服务器或Radius认证服务器、流媒体视频服务器。100k PPS的UDP Flood经常将线路上的骨干设备(例如,防火墙)打瘫,造成整个网段的瘫痪。
-
攻击特征
- 报文源IP和源端口变化频繁,但报文负载一般保持不变或具有规律的变化
-
防御方式
- 限流,属于暴力型,可以很快将UDP流量限制在一个合理的范围内,但是不分青红皂白,超过就丢,可能会丢弃一些正常报文
- 指纹学习,属于理智型,不会随意丢弃报文,但是发生攻击后需要有个指纹学习的过程。目前,指纹学习功能是针对UDP Flood攻击的主流防御手段,在华为防火墙产品中广泛应用。
- 关联TCP。UDP是无连接的协议,因此无法通过源认证的方法防御UDP Flood攻击。如果UDP业务流量需要通过TCP业务流量认证或控制(即,需要经过TCP确认是否允许UDP),当UDP业务受到攻击时,对关联的TCP业务强制启动防御,用此TCP防御产生的白名单决定同一源的UDP报文是丢弃还是转发。
DNS Flood 攻击
DNS Query Flood
攻击实质上是UDP Flood的一种,但是由于DNS服务器的不可替代的关键作用,一旦服务器瘫痪,影响一般都很大。
-
攻击方式
向被攻击的服务器发送大量的域名解析请求,通常请求解析的域名是随机生成或者是网络世界上根本不存在的域名,被攻击的DNS服务器在接收到域名解析请求的时候首先会在服务器上查找是否有对应的缓存,如果查找不到并且该域名无法直接由服务器解析的时候,DNS服务器会向其上层DNS服务器递归查询域名信息,但是DNS连接是有上限的,当量足够大的时候,会导致拒绝服务。
-
防御方式
【暂无】
CC 攻击
CC
攻击(Challenge Collapsar)是DDOS攻击的一种,是不断对网站发送连接请求致使其形成拒绝服务的攻击。相比其它的DDOS攻击,CC攻击是应用层的,主要针对网站(服务器资源)。
-
攻击方式
CC主要是用来攻击页面的,CC就是模拟多个用户(多少线程就是多少用户)不停地进行访问那些需要大量数据操作(就是需要大量CPU时间)的页面,造成服务器资源的浪费,CPU长时间处于100%,永远都有处理不完的连接直至就网络拥塞,正常的访问被中止。
-
攻击特征
-
网站出现
service unavaliable
提示 -
CPU占用高
-
网络连接出现大量
ESTABLISHED
状态,单个IP高达几十条甚至上百条 -
外部无法打开网站,软重启后,短期内恢复正常,几分钟后又无法访问
-
-
防御方式
- 限制每个IP的请求频率
- 域名欺骗解析,发现针对域名的CC攻击,我们可以把被攻击的域名解析到127.0.0.1这个地址上。
- 更改web端口,一般情况下Web服务器通过80端口对外提供服务,因此攻击者实施攻击就以默认的80端口进行攻击,所以,我们可以修改Web端口达到防CC攻击的目的
- 屏蔽IP
- 尽量将网站做成静态页面
- 禁止通过代理访问网站
如果您喜欢此博客或发现它对您有用,则欢迎对此发表评论。 也欢迎您共享此博客,以便更多人可以参与。 如果博客中使用的图像侵犯了您的版权,请与作者联系以将其删除。 谢谢 !