锋云服务器配置向导设置锋云服务器ktv

转载

编程小天才 2023-12-18 16:11:32

文章标签 锋云服务器配置向导设置服务器网络 java 后端 文章分类 云服务云计算

记录下云服务器kinsing,kdevtmpfsi,kthreaddk等病毒的处理与个人心得

至于怎么发现kdevtmpfsi和kthreaddk此处就不赘述了(不知道的也找不到这里来)，此文说下怎么排查处理及后续防护。(懒得截图,主要讲思路)

一. kdevtmpfsi

获取病毒相关信息及守护进程（图就不截了，按照思路走。此处假设kdevtmpfsi的进程id为15365,kinsing的进程id为15240）

由于我的服务器，不同中间件和应用，都是分配的不同用户启动的，很容易就知道病毒从哪来的，所以直接把对应中间件/应用也停了，搜索下旗下目录有没有病毒的sh文件，干掉即可。(root启动的话，建议抹了重装系统，鬼知道在哪留了后门或者残留)

二. kthreaddk

吐槽一下，这个病毒，如果是root启动的，那么恭喜你，你干不掉它了，你按照网上的文章去删，别人行你不行 ~（别杠,大佬请绕路)，因为这玩意一拿到root权限，定时任务是一秒一个不带重样的，执行文件都处于deleted状态，拿着刀却砍不到人，气不气。

行了，说下怎么查吧
那么后续漏洞排查来了，直接说结果吧，打了这么多字也累了。

三. 个人心得

一. 暴露在公网，并且没有公司没买网络安全，公司没有网络安全工程师的情况下，做下以下操作

至于怎么发现kdevtmpfsi和kthreaddk此处就不赘述了(不知道的也找不到这里来)，此文说下怎么排查处理及后续防护。(懒得截图,主要讲思路)

一. kdevtmpfsi

获取病毒相关信息及守护进程（图就不截了，按照思路走。此处假设kdevtmpfsi的进程id为15365,kinsing的进程id为15240）

1. 通过top命令获取到cpu占用最高的进程id（有些厉害的病毒会修改系统文件，top看不到，使用top -H 命令或者htop插件）
2. 通过进程id获取启动信息
 systemctl status 15365 
 在输出信息中可以找到此进程是由那个用户启动的，并且关联了那些进程,也是此处能发现kdevtmpfsi的守护进程kinsing3. 通过名称搜索关联文件
 find / -name kdevtmpfsi
 find / -name kinsing
 发现他们都在/tmp目录里(当然通过第2步就能看到该病毒的执行程序在哪，这里是为了看看有没有备份)4. 这种病毒一般都会有定时任务存在
 cd /var/spool/cron
 在此目录下，ll 一下可以看到定时任务列表，cat 看一下，有没有wget 或者curl，一般加了 -o -q，所以下载下来的sh文件很难找到（此处着重说下，暴露在公网的服务器，中间件及应用服务最好不要用root账号启动,非必要端口不要开放）5. 清理病毒文件和进程
 kill -9 15365 //干掉kdevtmpfsi进程
 kill -9 15240 //干掉kinsing守护进程
 rm -f /tmp/kdevtmpfsi //删掉病毒执行程序
 rm -f /tmp/kinsing //删掉病毒守护程序kinsing
 cd /var/spool/cron //进入定时任务目录,准备删除病毒的定时任务(此处假设病毒使用mytest用户启动的，这里应该会有mytest文件)
 rm -f mytest //删除病毒定时任务(别瞎抄,mytest是之前步骤查出来的病毒定时任务文件，也有可能是其他名称，或者直接就是在root文件里。在root文件的话就vi root，然后删掉不正常的定时任务命令，wq保存)

由于我的服务器，不同中间件和应用，都是分配的不同用户启动的，很容易就知道病毒从哪来的，所以直接把对应中间件/应用也停了，搜索下旗下目录有没有病毒的sh文件，干掉即可。(root启动的话，建议抹了重装系统，鬼知道在哪留了后门或者残留)

二. kthreaddk

吐槽一下，这个病毒，如果是root启动的，那么恭喜你，你干不掉它了，你按照网上的文章去删，别人行你不行 ~（别杠,大佬请绕路)，因为这玩意一拿到root权限，定时任务是一秒一个不带重样的，执行文件都处于deleted状态，拿着刀却砍不到人，气不气。

行了，说下怎么查吧

同样是top,查进程id和启动用户
同样是systemctl status 进程id ，拿到守护线程id和名字(这玩意的守护线程可能是一串无意义字符串，别忽略哈）
ps：因为我是用java用户启动的应用，这病毒的启动用户也是java,是不是一下子思路就变清晰了~
和kdevtmpfsi病毒一样，这玩意也有定时任务在/var/spool/cron目录下，因为启动用户叫java,所以这个目录下有个java文件，里面定时去下载病毒初始化脚本。但是有区别的是，这个病毒的执行文件是deleted了，也就是他运行起来后自宫了，所以这个先不管。
干掉kthreaddk进程和他的守护进程，删除病毒的定时任务。
已存在服务器的病毒被杀了，虽然漏洞还在！~
还是老生常谈，病毒的启动用户是java,而我只用了java用户启动了两个项目，一个我司的系统后台，一个xxl-job,那么显而易见了，这两玩意肯定有一个有问题。
当然，不能怀疑自己，那就先认为xxl-job有问题，于是去查xxl-job的日志，发现少了一个时间段的调度日志，那么问题来了，这段时间没跑？不可能，最快了一个定时我设的1分钟一次。
然后再去我的后台服务查看指定的xxl-job的lobpath里的日志，就发现了病毒的出生点了，该目录下有一串sh文件，具体的不贴了，问就是懒，这些文件干的就是下载病毒初始化脚本和执行程序,并且扔到tmp目录执行。
哪还有啥话好说的，直接删掉。

那么后续漏洞排查来了，直接说结果吧，打了这么多字也累了。

xxl-job-admin项目的配置文件中，accesstoken记得给个复杂点的字符串，端口也改掉自定义的，别像我之前一样裸奔
同样的受调度的项目里，也需要将accesstoken配置上，端口别用9999了，改个自己定义的。还有，没事别把simpleJob里的http例子开着，如有必要，也要进行ip校验。