记录服务器被入侵的一次经历

半日闲 2020年09月11日 20次浏览

前几天买了个远程电脑作为测试机,准备测试下kubernetes之类,今天通过ssh过去后,发现使用kubectl get no的时候,有时候正常,但是有时候,就说do you specity the right host or port,很奇怪,报错如下

image-20200911164556554

一,查询cpu情况

因为当有时kubectl get no命令正常的时候,看到kube-system底下的pod都重启了好几百次,使用logs查询后,发现很多sync timeout的问题,就想到是不是cpu被某些进程占用满了,导致api server运行太慢了,因为docker ps的时候,所有的pod都是存在的

使用top命令查看cpu使用情况

image-20200911164639521

查看到damon程序占用了很多cpu,初步确认是中毒

二,查看中毒进程

使用ps aux | grep daemon查看为空

image-20200911164929574

使用lsof命令,根据pid进行查询(因为忘记截图,所以使用其他命令代替下过程)

image-20200911165112512

如上,可查看到命令执行相关的目录,以及运行命令,因此找到位于/tmp/底下的daemon命令

将其保留,后续反编译可以查看入侵来源

mkdir /debug/ && mv /tmp/daemon /debug/test_daemon && chmod -R 600 /debug/*

三,查看cron任务

使用crontab -l查看是否有定时任务

image-20200911165439597

使用crontab -e将其删除

四,查看是否有其他后台任务

使用string命令可以查看到病毒中的一些字符

image-20200911165545195

可以看到其中有个proc/self/exe链接到了本机的ls命令,因此,很有可能我在debug的过程中执行的ls命令就会导致再次中毒,因此后续考虑重装系统

同时使用string命令可以查看到该命令中的一些作者的信息,如下

image-20200911165733266

五,溯源过程(由于日志均被删除,所以无法看到)

查看secure日志

查看message日志

查看last登录情况

查看系统邮件

image-20200911170202150

六,备注

本次入侵事件,主要是由于我为了连接方便,因此将该虚拟机的ssh端口映射到了云服务器的高端口,然后密码就比较简单,时间123456,因此会被爆破

​ 警示:

	1. `sshd`这种服务应该只是用密钥登录,其余密码登陆一律拒绝
	2. `sshd`服务应设置与高端口
	3. 采用脚本分析`secure`日志,凡登录失败,超过3次的`ip`,一律拉入黑名单

病毒已经备份,下篇文章分享,如何反查询