记录一次云服务器遭遇SYN泛洪攻击处理方式

1 场景再现

今天上午刚想用云服务器传输下文件,当打开finalshell连接服务器时突然发现服务器的系统指标很异常,而且在终端输入命令的时候都非常的卡,图示:
记录一次云服务器遭遇SYN泛洪攻击处理方式_第1张图片
很明显我们可以看出服务器的异常状态:

  • CPU高负载
  • 内存高利用率
  • 网络高出口带宽

2 尝试解决

2.1 尝试使用netstat命令检查网络连接状态

首先使用最基本的netstat命令查看网络的连接状态

####  命令
netstat

####  输出字段含义
Proto   #
Recv-Q  #
Send-Q  #
Local   #
Address  #
Foreign Address #
State #

记录一次云服务器遭遇SYN泛洪攻击处理方式_第2张图片

2.2 回顾TCP三次握手

记录一次云服务器遭遇SYN泛洪攻击处理方式_第3张图片
由TCP三次握手的流程和各自的状态我们可以看出,当客户端向服务器发送玩syn=1,seq=n时,客户端会处于SYN_SEND状态,并等待服务端ACK。

由上图得知我们的服务器TCP连接大量的处于SYN_SEND状态,因此可以判断是被黑客当成了肉机对其他服务器进行拒绝服务攻击,我们自己服务器攻击的类似则属于SYN泛洪攻击。

2.3 netstat命令搭配参数查看更多网络状态信息

接下来我们使用更复杂一点的netstat参数来查看详细一点的网络信息,首先是

####  命令
netstst -p

####  参数作用
-p 显示建立相关链接的程序名

### 其他参数
-a (all)显示所有选项,默认不显示LISTEN相关
-t (tcp)仅显示tcp相关选项
-u (udp)仅显示udp相关选项
-n 拒绝显示别名,能显示数字的全部转化成数字。
-l 仅列出有在 Listen (监听) 的服務状态

-p 显示建立相关链接的程序名
-r 显示路由信息,路由表
-e 显示扩展信息,例如uid等
-s 按各个协议进行统计
-c 每隔一个固定时间,执行该netstat命令。

提示:LISTEN和LISTENING的状态只有用-a或者-l才能看到

####  -p输出字段含义
Proto   #
Recv-Q  #
Send-Q  #
Local   #
Address  #
Foreign Address #
State #
PID/Program name #

我们使用netstat -p命令进行对网络连接所处程序的查询,发现无法正确的查看,因此我们可以断定攻击者的水平还算是可以的,并且我们通过这些简单的命令很难查出背后的原因了。

记录一次云服务器遭遇SYN泛洪攻击处理方式_第4张图片
发现TCP的连接数如此之多,而且状态多为正在打开并未连接的TCP报文
记录一次云服务器遭遇SYN泛洪攻击处理方式_第5张图片

2.4 发现异常TCP连接

下一步排查当前服务器的TCP已连接情况:

22端口的都是我在本机使用三方工具进行对服务器的远程连接,22端口和我本机的公网IP,因此这一部分TCP连接不需要质疑,但是唯独有几个不知名端口号和不知名IP的连接,因此我们可以断定这些连接多半为黑客攻击时的异常连接,并且隐藏了连接的进程。
记录一次云服务器遭遇SYN泛洪攻击处理方式_第6张图片
因为只有一个异常连接能够看到进程名,于是我们顺藤摸瓜找到该程序的位置
在这里插入图片描述
该程序的位置在/tmp目录下,但是这个服务器只有我一个人使用,并未下载和添加该程序,因此该程序来源不明,对于该程序的介绍(来自GitHub):

https://github.com/tmate-io/tmate

tmate 的意思是 teammates,它是 tmux 的一个分支,并且使用相同的配置信息(例如快捷键配置,配色方案等)。它是一个终端多路复用器,同时具有即时分享终端的能力。它允许在单个屏幕中创建并操控多个终端,同时这些终端还能与其他同事分享。

你可以分离会话,让作业在后台运行,然后在想要查看状态时重新连接会话。tmate 提供了一个即时配对的方案,让你可以与一个或多个队友共享一个终端。

在屏幕的底部有一个状态栏,显示了当前会话的一些诸如 ssh 命令之类的共享信息。
记录一次云服务器遭遇SYN泛洪攻击处理方式_第7张图片
因此我们大致可以断定黑客就是通过tmate来对我们的服务器进行控制,让服务器出去SYN泛红状态并启动了挖矿程序进行挖矿。

3 偶遇大神指点

由于服务器的用途有限,并且针对服务器异常情况的应对经验也有限,因此先在微信的一个技术群中进行询问,以下是处理过程。

3.1 ps命令查找恶意进程并终止

什么都没说,一位很有经验的老前辈上来就让我执行这几部操作

  • ps -ef|egrep "mass|scan"
  • 停止相关进程
  • 找到对应的文件,删除

记录一次云服务器遭遇SYN泛洪攻击处理方式_第8张图片
记录一次云服务器遭遇SYN泛洪攻击处理方式_第9张图片
虽然不知道为什么,但是还是照做了,当停止进程的时候,发现网络和内存的情况一下子就好了
记录一次云服务器遭遇SYN泛洪攻击处理方式_第10张图片

3.2 删除异常用户和文件

按照前辈说的,再将黑客创建的用户和用户目录都删除掉
记录一次云服务器遭遇SYN泛洪攻击处理方式_第11张图片
还有异常的脚本也都删除掉
在这里插入图片描述

3.3 缘由探究

在那位老前辈的指引下,服务器的网络和内存情况已经得到修复,但是CPU占用情况仍然没有缓解,而且多半是被挖矿程序占用,因此很不容易被发现。

在操作完成后,向老前辈请教本次异常出现的原因,老前辈直接就说肯定是端口开太多了,我回头一想,当初确实是为了方便做实验,开放了很多端口,因此被黑客利用,对服务器发起了攻击。

4 回顾总结

对TCP连接过程比较熟悉的同学应该都知道,TCP的SYN泛洪攻击以及DOS、DDOS攻击等都是基于TCP三次握手来进行的,因此很难完全避免,我们要做的就是在公网服务器上尽量少放开不常用的端口,以免遭受黑客攻击。还有就是加深自己的计算机网络知识,遇到问题要知道是什么原因,并且尝试着去解决。

当然因为有挖矿程序很难清理,最后还是备份数据,重装了服务器的操作系统来解决的,但是内存和网络的异常得以被修复就是很值得学习和记录的,继续加油~

你可能感兴趣的:(项目实战经验,探索云原生,网络,tcp,服务器,运维,syn泛洪攻击)