服务器又被黑了,可咋办

科技   2024-11-14 12:36   浙江  


!! 大家好,我是乔克,一个爱折腾的运维工程,一个睡觉都被自己丑醒的云原生爱好者。


作者:乔克
公众号:运维开发故事
博客:jokerbai.com


✍ 道路千万条,安全第一条。操作不规范,运维两行泪。

发生

正在为公司呕心沥血之际,收到好友消息:说服务器是不是中招了?

随即叫他看看能不能找到CPU使用率高的进程,但他使用top命令,未发现异常进程。

使用htop,也一样未发现任何异常进程。

并且所有节点的CPU都处于高负荷状态。

根据我的经验,被黑无疑了。

怎么办呢?

  • 断网
  • 改密码

排查

作为资深老油条(Server Reinstall Enginner),对于这种安全问题,第一反应就是重装(没有什么是重装解决不了的,如果有,那就再装一次),因为病毒大概率是找不全,杀不干净,很容易对外留尾巴。

不过,咱还是要稍微专业一点,拿出病毒排查秘笈宝典,至少要找到一点蛛丝马迹才行,那我们就开始吧。

上面不论是通过top还是htop命令都没有发现具体占用CPU较高的进程,那么进程肯定是隐藏了

对于隐藏进程,第一个想到的就是/etc/ld.so.preload文件,该文件是作用是让程序在运行之前,优先加载某些动态的链接库,部分木马正是利用此文件的功能,修改了该文件,在里面添加恶意so文件,从而达到了隐藏挖矿进程的目的。这也是为什么服务器CPU使用率很高,但是看不到占用CPU高的进程的原因。

默认情况下,该文件应该是空的,如果里面有内容,那大概率是木马植入的,我们需要先找到文件里的so文件并将其删除掉,然后再清空该文件。

通过排查,发现/etc/ld.so.preload文件确实有内容(这里忘记截图了),就按照上面的步骤操作一遍。

讲道理,上面操作后再使用top或者htop命令就能看到CPU占用高的进程了。

除此之外,还可以使用unhide命令来查看隐藏进程。使用yum install unhide安装命令,然后使用unhide proc即可发现隐藏进程。

秉着头痛医脚的理念,发现问题,就要解决问题,虽然心里知道使用kill -9 PID大概率解决不了问题,但是忍不住想尝试一下。果不其然,杀了进程又起来另外的进程了。

很明显,这是有其他守护进程的。所以使用systemctl status PID查看一下具体的进程服务。

通过图中的箭头所指来看,就不是正常的服务。查看启动的二进制文件,发现也是才安装不久。

心中窃喜,果然皇天不负有心人。然后准备尝试一番,看看CPU会不会降下来。

  • systemctl disable <SERVER>
  • systemctl stop <SERVER>
  • mv /etc/systemd/system/audit-piped.service ~/audit-piped.service.bak
  • mv /user/bin/udeb ~/udeb.bak
  • kill -9 PID

处理之后CPU果然下来了,而且隐藏进行也没有再起来。

看起来是解决了该台服务器的问题了。

不过,事情还没完,我们需要把服务器再检查一遍,尽可能的找到一些尾巴。

  • 检查计划任务
  • 检查开机启动文件
  • 检查开机启动服务
  • 检查环境变量文件
  • 检查二进制命令文件
  • 检查内核配置文件
  • 检查密钥登录文件
  • 检查账户信息
  • 检查DNS配置文件
  • 检查临时目录文件

另外,还可以借助一些工具,比如clamav,来检查是否篡改或者植入了二进制命令。

集群中的其他服务器也按上面的流程检查了一遍,发现都是一样的服务、一样的二进制、一样的计划任务。处理过后,服务器节点的CPU都降下来了。

不过,这些服务器都是纯内网服务器,木马是怎么植入进来的呢?

通过朋友的描述,为了便于办公,有一台VPN服务器,是自建的openvpn,对外暴露了公网,且把SSH也暴露了出去,而且万万没想到的是密码非常简单:Aa@123456。这种密码跟给情人留门没什么两样。而且中招的那些服务器的密码和这台服务器是一样的,这不仅留了大门,还把其他房间的钥匙放在桌上。

登录到那台vpn服务器一看,果然中招了。

而且服务和进程都不一样。

并且bash都被修改了。

所有定时任务文件中,都有对应的定时任务。

而且,还有另外一个高权限的账户。

这台服务器,不准备修了,直接重装吧。

复盘

这其实是一件入侵成本很低的安全事件:

  • 对外暴露的SSH服务,未做白名单限制
  • 对外暴露的服务器的密码简单
  • 内网服务器的密码简单,且不同服务器使用的相同的简单密码

正常情况下,对外暴露的除了提供服务能力的端口都应该限制白名单,并且服务器本身的密码不应该简单随意。

  • 对于管理端口,应该修改默认端口,设置访问白名单,避免被扫描和爆破。
  • 除非业务端口(例如80、443),其他无关端口无特殊情况不放行。
  • 服务器和应用程序的密码尽量复杂,不同服务器和应用程序密码不应相同。
  • 每台新的服务器购买或者创建之后,应该做一些基础的安全加固(按照等保检查的要求加固)。
  • DMZ区和业务区应该做网络隔离限制,只允许访问特定的端口。
  • 做好监控,及时发现问题。
  • 有钱的情况下,上一些安全防护软件,不要裸奔。

最后,送警世名言:

道路千万条,
安全第一条。
操作不规范,
运维两行泪。



最后,求关注。如果你还想看更多优质原创文章,欢迎关注我们的公众号「运维开发故事」。

如果我的文章对你有所帮助,还请帮忙点赞、在看、转发一下,你的支持会激励我输出更高质量的文章,非常感谢!

你还可以把我的公众号设为「星标」,这样当公众号文章更新时,你会在第一时间收到推送消息,避免错过我的文章更新。




我是 乔克,《运维开发故事》公众号团队中的一员,一线运维农民工,云原生实践者,这里不仅有硬核的技术干货,还有我们对技术的思考和感悟,欢迎关注我们的公众号,期待和你一起成长!



运维开发故事
由一群志同道合的小伙伴共同维护,有运维也有开发,内容不限于Linux运维,devops工具链,k8s容器化技术,监控,日志收集,网络安全,Python或GO开发,团队成员有乔克、wanger、冬哥、素心、华仔、郑哥、夏老师
 最新文章