记一次解决阿里云服务器偶尔连接不上的问题（由tcp_tw_recycle参数引发的）

Posted 2023-04-07

参考技术A 阿里云服务器偶尔连接不上的问题出现在我做了一些TCP优化之后，出现了公司内网偶尔会出现连接不上服务器的问题，但是切换其他的网络就可以正常连接。

1，登陆服务器查看资源使用top，vmstat等命令查看了一番发现服务器各项指标都没有异常。于是将问题转向了网络层。
2，本地使用ping服务器外网ip正常返回，无丢包，延迟也正常。
3，登录服务器查看tcp相关数据。

发现在卡顿时有大量tcp syn包被丢弃，数值一直在增长。

在查阅资料并结合实际情况后，发现该服务器同时启用了 tcp_timestamps和tcp_tw_recycle参数。
后想起，之前同事为改善time_wait连接数过多问题曾改过该内核参数。
解决办法是，关闭tcp_tw_recycle：

再观察，发现服务已正常，偶尔连接不上的现象消失。

我们先来man一下这两个参数(man tcp)：

cp_timestamp 是 RFC1323 定义的优化选项，主要用于 TCP 连接中 RTT(Round Trip Time) 的计算，开启 tcp_timestamp 有利于系统计算更加准确的 RTT，也就有利于 TCP 性能的提升。（默认开启）
关于tcp_timestamps详情请见： https://tools.ietf.org/pdf/rfc7323.pdf

开启tcp_tw_recycle会启用tcp time_wait的快速回收，这个参数不建议在NAT环境中启用，它会引起相关问题。

tcp_tw_recycle是依赖tcp_timestamps参数的，在一般网络环境中，可能不会有问题，但是在NAT环境中，问题就来了。比如我遇到的这个情况，办公室的外网地址只有一个，所有人访问后台都会通过路由器做SNAT将内网地址映射为公网IP，由于服务端和客户端都启用了tcp_timestamps，因此TCP头部中增加时间戳信息，而在服务器看来，同一客户端的时间戳必然是线性增长的，但是，由于我的客户端网络环境是NAT，因此每台主机的时间戳都是有差异的，在启用tcp_tw_recycle后，一旦有客户端断开连接，服务器可能就会丢弃那些时间戳较小的客户端的SYN包，这也就导致了网站访问极不稳定。

主机A SIP:P1 (时间戳T0) ---> Server 主机A断开后
主机B SIP:P1 (时间戳T2) T2 < T0 ---> Server 丢弃

经过此次故障，告诫我们在处理线上问题时，不能盲目修改参数，一定要经过测试，确认无误后，再应用于生产环境。同时，也要加深对相关内核参数的认识和理解。
本文解决灵感来自于 https://blog.51cto.com/hld1992/2285410
https://blog.csdn.net/chengm8/article/details/51668992

记一次阿里云服务器因Redis被挖矿病毒crypto和pnscan攻击的case，附带解决方案

一、事情缘由

• 云服务器到手之后，为了可以让自己本地可以连接到阿里云服务器上就做了如下操作：
  • 开放了ssh（port:22）端口：为了远程连接使用。
  • 开放了剩余的其他所有端口：录制教学视频时启动了相关容器，容器的一些固定端口6379等映射到了宿主机的随机端口上，为了能从公网访问到容器的内容，就开放了这些端口（这是隐患）。

二、原因排查

• 在云服务器中搭建了含有Redis/Nginx等服务的容器（但是Redis服务并没有设置密码），如下图所示
• 好家伙，就在我搭建完这些容器之后，后面云服务器就开始给我报警了。首先是CPU暴涨（这也算是挖矿的基本特征），如下图所示

• 接着就是安全警告

• 打开一看，没错，redis被攻进来了（教学视频介绍Docker 3大网络的时候，把容器的6379端口直接映射到宿主机上了）

• 分析原因：恶意攻击访问本地服务，上传了相关恶意脚本。
• 报警报了一两天，一开始我也没在意，后来我忍不住了，我能让你在我面前玩？？？那就开整，干死你。

三、找出挖矿机器目的地（新加坡）

• CPU暴涨，那肯定是后台有恶意程序在跑了，先top命令查看一下，果然，两个常见的挖矿病毒，crypto和pnscan

top

• 这些恶意程序一般都存在/usr/share目录下，查看若然都在里面，执行下面的命令把这些相关程序都删除了

# 查看
ls -l /usr/share | gre cry
# 删除
sudo rm -rf /usr/share/*crypto*
# 确认下是否删除完成
ls -l /usr/share | gre cry
# 查看
ls -l /usr/share | gre scan
# 删除
sudo rm -rf /usr/share/*scan*

• 再来查看一下网络情况，程序肯定是把本机的一些数据往外面传了，结果发现这个家伙把我本地好多的命令全部都改了，气死我了，例如下面netstate命令把我的可执行权限给删了。

# 查看网络相关信息
netstat -aptn
sudo netstat -aptn

# 查看netstat命令在哪里
which netstat
whereis netstat

# 查看一下netstat程序的相关信息
ls -l /bin/netstat

• 如上图所示，netstat没有x权限（可执行权限），那就用chmod给它加下x权限，结果发现netstat不能赋值可执行权限，如下所示：

sudo chmod +x /bin/netstat
lsattr /bin/netstat

• 从上图的lsattr命令可以看到，/bin/netstat有一个i权限，表示这个文件不可以被修改，也就是说不能被赋予可执行权限。这里介绍2个命令：
  • lsattr：查看文件的相关属性。
  • chattr：与lsattr对应，用来设置文件相关属性。
• 解决方法就是使用chattr命令来更改，把其i属性去除，结果如下所示，chattr命令不能执行，原因也是chattr没有可执行权限

# 将netstat命令的i属性去除
sudo chattr -i /bin/netstat
# 查看chattr
ls -l /usr/bin/chattr

• 接着就用chmod给chattr去赋值可执行权限，结果发现chattr也有i属性，不能被赋值权限，唉。

# 赋值可执行权限
sudo chmod +x /usr/bin/chattr
# 查看chattr属性
lsattr /usr/bin/chattr

• 哦吼，这下怎么办？chattr既不能赋值权限，也不能更改自己的属性。后来想到一种办法：
  • 我的另一台机器上有chattr命令，那就把另一台机器上的chattr命令拷贝到这台被攻击的机器上。
  • 因为另一台机器上的chattr命令是好的，所以拿过来可以直接使用。
• 输入下面的命令，把另一台机器上的chattr命令拷贝到本地，保存名为~/chattr_tmp，然后用chattr_tmp去除有问题的chattr命令的i属性（可能有点绕），如下所示：

# 将0.0.0.0机器上的/usr/bin/chattr拷贝到本地，保存为~/chattr_tmp
sudo scp ubuntu:0.0.0.0:/usr/bin/chattr ~/chattr_tmp

# 查看一下，确认是可以执行的
ls -l ~/chattr_tmp

# 使用~/chattr_tmp去除/usr/bin/chattr的i属性
sudo /home/dongyusheng/chattr_tmp -i /usr/bin/chattr

• 上面执行完成之后就可以给chattr赋予可执行权限了，如下所示：

# 查看chattr的i属性被去除
lsattr /usr/bin/chattr
# 赋予可执行权限
sudo chmod +x /usr/bin/chattr
# 查看权限，已经可执行了
ls -l /usr/bin/chattr

• 下面使用chattr去除netstate的i属性，去除之后赋予其可执行权限，如下所示：

sudo chattr -i /bin/netstat
sudo chmod +x /bin/netstat
ls -l /bin/netstat

• 接着查看网络信息，可以看到，crypto正在往一个IP为172.104.165.191的机器上传输数据呢，IP一查是新加坡的机器。

sudo netstat -aptnl

四、删除恶意进程

• 下面删除这些恶意进程，结果kill的时候发现kill命令也没有可执行权限，最后只好用跟上面一样的方法给kill命令赋予可执行权限

whereis kill
sudo ls -l /bin/kill
sudo chmod +x /bin/kill
lasttr /bin/kill
sudo chattr -i /bin/kill
lsattr /bin/kill
sudo chmod +x /bin/kill
sudo ls -l /bin/kill

• kill命令可以使用之后，杀掉这2个进程

sudo kill -9 657 604

• 杀掉之后查看再次查看进程，可以看到CPU恢复正常，程序没了

top

五、删除容器镜像

• 接着检查本地的容器情况（容器已经被我停止运行了，这是后面截的图片），这家伙给我构建了一个容器，里面曾跑过脚本。

# 停止运行容器
sudo docker stop 5e3defeb058c

# 查看本地所有容器, 不论是否正在运行
sudo docker ps -a

• 再查看镜像，这家伙给我构建了一个镜像

# 查看本地所有镜像
sudo docker images

• 我就尝试着删除这个容器，结果失败了，因为有内容被链接挂载。

# 删除容器, 删除之前需要先停止运行该容器
sudo docker rm 5e3defeb058c

• 来到容器的目录下，找到这个容器相关的内容

cd /var/lib/docker/containers
sudo find . | grep 5e3defeb058c

• 找到之后全部删除，一点不留情。

sudo rm -rf 5e3defeb058cd75b39740cd1584945f9a822a022b2a7c3bf025ee027017edb0f
sudo rm -find . | grep 5e3defeb058c

• 然后再次删除容器还是不可以。

• 没办法，只能重启docker进程。下面重启docker进程，发现service程序没有可执行权限，果断给其赋值可执行权限，然后再重新启动，结果还是错误，显示systemctl程序不能执行。

sudo service docker restart
whereis service
sudo chattr -i /usr/sbin/service
sudo chmod +x /usr/sbin/service
sudosudo service docker restart

• 那就果断给systemctl程序再赋予可执行权限，指挥重启docker服务，成功。

whereis systemctl
ls -l /bin/systemctl
sudo chattr -i /bin/systemctl
sudo chmod +x /bin/systemctl
sudosudo service docker restart

• 再次查看容器，哈哈哈哈哈哈，容器没了。

# 查看所有容器
sudo docker ps -a

• 容器没了就可以删除镜像了，如下所示，镜像也删除成功。

# 查看镜像
sudo docker iamges
# 删除镜像
sudo docker rmi b4a24c6be971
# 确认是否删除成功
sudo docker iamges

六、结束语

• 搞了我半天这个东西，在这里给大家总一下整个流程：
  • 第1步：云服务器告警，受到攻击。
  • 第2步：进入服务器排查，发现有恶意程序。
  • 第3步：删除恶意程序，虽然在删除的时候发现很多命令被篡改，不过在我的小聪明下解决了这些命令问题。
  • 第4步：查看容器也被攻击，删除容器和相关镜像。
• 这里也给大家一些在使用云服务器时的相关建议：
  • 一些重要的端口不要随便开放。
  • 如果迫不得已端口需要开放，请配置好相关密码，密码尽量不要太简单，要不然容易被暴力破解。
  • 如果云服务器不使用了，也没有功能要用，尽量关机。
• 这里我云服务器关闭了相关重要的端口，先暂时开发ssh：