当前位置:   article > 正文

TCP洪水攻击Ru侵和结果分析解决方案_cmd 发送洪水

cmd 发送洪水

目录

一、TCP洪水攻击介绍

1.TCP洪水攻击介绍

 1.1 半连接队列(SYN队列)

1.2 全连接队列

2.ss命令浅析

二、Linux服务器TCP洪水攻击入侵Demo(上)

2.1 TCP洪水攻击环境准备 

三、Linux服务器TCP洪水攻击入侵Demo(下)

3.1  入侵攻防分析实战

3.2  继续抓包分析

四、TCP洪水攻击结果分析和解决方案Demo

4.1 洪水攻击结果现象

4.2 缓解TCP洪水攻击方案

4.3 现象和思路总结


本博文简单介绍TCP洪水攻击流程,同时使用 hping3 进行攻击服务,重点介绍怎么区分洪水攻击以及解决方案。

一、TCP洪水攻击介绍

1.TCP洪水攻击介绍

洪水攻击是一种网络攻击,它使用伪造的TCP连接请求来淹没服务器的资源,从而使服务器无法响应正常的用户请求
这种攻击通过不断地发送同步(SYN)连接请求到服务器,而服务器会尝试建立连接,当服务器回复 SYN+ACK 报文后,攻击者不会发送确认(ACK)
那SYN队列里的连接则不会出队,逐步就会占满服务端的 SYN半连接队列
服务器会一直等待,耗尽服务器的资源,最终就是服务器不能为正常用户提供服务

(想了解特别详细的可以看看TCP三次握手的流程)

攻击的背景来源:TCP 进入三次握手前,服务端会从内部创建了两个队列
半连接队列(SYN 队列)
全连接队列(ACCEPT 队列)

 1.1 半连接队列(SYN队列)

存放的是三次握手未完成的连接,客户端发送 SYN 到服务端,服务端收到回复 ACK 和 SYN
状态由 LISTEN 变为 SYN_RCVD,此时这个连接就被放进 SYN 半连接队列
半连接队列的个数一般是有限的,在SYN攻击时服务器会打开大量的半连接,分配TCB耗尽服务器的资源,使得正常的连接请求无法得到响应

查看系统最大半队列大小

 sysctl -a|grep max_syn

 或者 cat /proc/sys/net/ipv4/tcp_max_syn_backlog

查看系统当前半队列大小

ss -s   结果的 synrecv 0  或者 netstat -natp | grep SYN_RECV | wc -l

 查看 SYN队列是否有溢出

间隔执行下面命令,如果有持续大量递增则是溢出 netstat -s|grep  LISTEN

1.2 全连接队列

存放的是完成三次握手的连接,客户端回复 ACK, 并且服务端接收后,三次握手就完成了
连接会等待的应用取走,在被取走之前,它被放进 ACCEPT全连接队列

查看系统最大全连接队列大小

cat /proc/sys/net/core/somaxconn

长度由 net.core.somaxconn 和 应用程序使用 listen 函数时传入的参数,二者取最小值
默认为 128,表示最多有 129 的 ESTABLISHED 的连接等待accept

查看系统当前全连接队列大小

ss -lnt   如果是指定端口 可以用 ss -lnt |grep 80

# -l 显示正在Listener的socket
# -n 不解析服务名称
# -t 只显示tcp

state 在LISTEN 状态下
  Send-Q表示listen端口上的全连接队列最大为128
  Recv-Q为全连接队列当前使用了多少

2.ss命令浅析

Socket Statistics 是Linux中的一条网络工具命令,用于显示当前系统的各种网络连接状态,包括TCP、UDP以及Unix套接字等。相比netstat可以显示更多更详细的有关 TCP 和连接状态的信息。

本博文主要用来查看洪水攻击时,连接队列的情况。  

二、Linux服务器TCP洪水攻击入侵Demo(上)

2.1 TCP洪水攻击环境准备 

机器准备:

机器A 部署Nginx 作为常规服务

阿里云服务需要关闭 syn_cookie ,即net.ipv4.tcp_syncookies = 0

vim /etc/sysctl.conf

修改完之后,需要执行 sysctl -p 配置才能生效。

docker部署nginx   docker run --name nginx-wnn -p 80:80 -d nginx:1.23.3

机器B安装hping3 ,模拟 SYN 攻击

准备hping3工具:hping3是一款开源的网络扫描和测试工具,可用于模拟tcp洪水攻击

hping3 命令安装

# 依赖库
yum -y install libpcap
yum -y install libpcap-devel
yum -y install tcl-devel

#安装
yum -y install hping3

使用hping3模拟tcp洪水攻击:通过hping3指令,向攻击目标发送大量tcp数据包,从而模拟tcp洪水攻击。

hping3 -S -p 80 --flood 112.74.xxx.xx
#-S是发送SYN数据包,-p是目标端口,112.74.xxx.xx是目标机器ip

现象:

攻击前 访问A机器的nginx成功
攻击时  机器A服务访问超时失败(使用谷歌浏览器开启隐身模式,或者 curl -v 地址)
查看内存占用率不高、CPU平均负载和使用率等比较低,CPU耗在 si 软中断 消耗时间比例升高

 攻击后,转圈 无法访问

 攻击之前地址是可以正常访问的,攻击之后 无法访问nginx

三、Linux服务器TCP洪水攻击入侵Demo(下)

3.1  入侵攻防分析实战

  top查看cpu情况

查看内存占用率不高、CPU平均负载和使用率等比较低,CPU耗在 si 软中断 消耗时间比例升高

CPU主要用在软中断上,从进程列表上看到CPU 使用率最高的也是软中断进程 ksoftirqd

ksoftirqd是运行在Linux的进程,专门处理系统的软中断的,格式是 “ksoftirqd/CPU 编号
在多核服务器上每核都有一个ksoftirqd进程,经常看到ksoftirqd/0表示这是CPU0的软中断处理程序 

所以软中断过多比较大可能导致问题,通过文件系统 /proc/softirqs 看是哪类下软中断导致
/proc/softirqs 提供了软中断的运行情况
/proc/interrupts 提供了硬中断的运行情况

命令  watch -d cat /proc/softirqs

说明:
  HI 高优先级软中断
  TIMER 表示定时器软中断,用于定时触发某些操作
  NET_TX 表示网络发送软中断,用于处理网络发送的数据包
  NET_RX 表示网络接收软中断,用于处理网络接收的数据包
  BLOCK 表示块设备软中断,用于处理磁盘读写请求。
  TASKLET:任务中断,用于处理任务的中断任务。
  SCHED 表示内核调度软中断
  HRTIMER:高精度定时器中断,用于处理高精度定时任务。
  RCU:Read-Copy Update中断,用于处理读写锁的内核操作。

现象:
几个指标都在变化中,但是NET_RX 是变化最多的
推断是网络接收软中断,用于处理网络接收的数据包 导致出现问题

分析网络流量 sar :

sar -n DEV 1 -h

#-n DEV 表示显示网络收发的报告,间隔 1 秒输出一组数据 -h人类可读方式

分析网卡数据包

eth0:接收的网络帧(包) PPS较大为179063, 而每秒收到的数据包大小BPS为9.2M(转为字节)
计算为:9.2 * 1024 * 1024 /179063 = 54字节,平均每个网络帧只有54字节,很小的网络帧是小包问题

3.2  继续抓包分析


 tcpdump -i eth0 -n tcp port 80

对输出结果进行分析: 

第一列:时分秒毫秒 

第二列:网络协议 IP

第三列:发送方的ip地址

第四列:箭头 > 表示数据流向

第五列:接收方的ip地址

第六列:冒号

第七列:数据包内容,包括Flags 标识符,seq 号,ack 号,win 窗口,数据长度 length

更多标识符:使用 tcpdump 抓包后,会遇到的 TCP 报文 Flags,有以下几种:

[S] : SYN(开始连接)
[P] : PSH(推送数据)
[F] : FIN (结束连接)
[R] : RST(重置连接)
[.] : 没有 Flag (意思是除上面四种类型外的其他情况,有可能是 ACK 也有可能是 URG)
 

分析:

大部分数据都是从 112.xxx.xxx.8.43231 > 171.xx.xxx.9.http: Flags [S] ,数据包是SYN
确认是 SYN FLOOD 洪水攻击

四、TCP洪水攻击结果分析和解决方案Demo

4.1 洪水攻击结果现象

攻击中查看SYN半连接队列大小: 持续递增

 netstat -natp | grep SYN_RECV | wc -l

攻击中查看SYN半连接队列是否有溢出

间隔执行下面命令,如果有持续大量递增则是溢出

netstat -s|grep  LISTEN

4.2 缓解TCP洪水攻击方案

一、开启tcp_cookie
vim /etc/sysctl.conf

net.ipv4.tcp_syncookies = 1

修改完之后,需要执行 sysctl -p 配置才能生效。

 二、增大半连接队列和全连接队列
    半连接队列的最大长度不一定由 tcp_max_syn_backlog 值决定的
    测试发现服务端最多只有 256 个半连接队列而不是 1024,Linux 内核版本实现不一样,和somaxconn全连接队列也有关系
    增加半连接队列大小不能只增大 tcp_max_syn_backlog 的值,还要一同增大 somaxconn  即增大全连接队列


#增大 tcp_max_syn_backlog(半连接队列)
echo 2048 > /proc/sys/net/ipv4/tcp_max syn backlog

#增大 somaxconn(全连接队列)
echo 2048 > /proc/sys/net/core/somaxconn

三、减少 SYN+ACK 重传次数(减小tcp_synack_retries的值)

# 减少SYN+ACK 的重传次数为1,加快处于SYN_REVC 状态的 TCP 连接断开
echo 1 > /proc/sys/net/ipv4/tcp_synack_retries

4.3 现象和思路总结

当发现服务器或业务卡顿的时候,通过top命令来查看服务器负载和cpu使用率,然后排查cpu占用较高的进程

如果发现cpu使用率并不高,但是si软中断很高,且ksoftirqd进程cpu占用率高,则说明服务器持续发生软中断

通过cat /proc/softirqs 来分析是哪类型的软中断次数最多,watch命令来查看变化最快的值

多数情况下网络发生中断的情况会比较多,通过sar命令来查看收发包速率和收发包数据量

验证是否是网络收发包过多导致,计算每个包的大小,判断服务器是否收到了flood攻击


通过tcpdump来抓包,分析数据包来源ip和抓包数据中的Flags来分析数据包类型

如果是Flood洪水攻击,可以通过调整tcp链接参数策略和防火墙封禁异常ip

如果是大规模DDOS攻击,则花钱找运营商购买流量包封堵

DDOS攻击实操以及SSH免登录原理介绍:

你知道小伙伴们的阿里云服务为什么会被ru侵,是怎么ru侵的吗?_为什么redis部署到阿里云会被攻击_这是王姑娘的微博的博客-CSDN博客

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/笔触狂放9/article/detail/542988
推荐阅读
  

闽ICP备14008679号