网络日志分析场景三：服务器陷落

一、往期回顾

上周，我们向大家展示了网络攻防领域中的两个网络安全调查案例。这些案例都基于真实事件改编，旨在分享处理网络安全事件的实战经验。第一篇文章（https://blog.csdn.net/lcgweb/article/details/144416011）详细叙述了一起影视作品泄露案的调查流程，而第二篇文章（https://blog.csdn.net/lcgweb/article/details/144399855）则深入探讨了电商网站首页被篡改的案例分析。两篇文章均详尽记录了事件处理的各个步骤，包括日志分析、网络追踪、系统检查等，为读者呈现了明确的操作指南。

二、思维导图

三、摘要

本文主要讲述了一个网络安全事件，其中小王（网管）在办公室发现服务器无法登录，随后发现服务器可能遭受了安全攻击。文章详细描述了小王如何逐步排查问题，发现服务器被黑客攻击的迹象，包括恶意脚本的运行、系统配置被修改、SSH登录被设置、定时任务被创建等。这些攻击行为导致服务器被冻结，并且可能涉及到分布式拒绝服务攻击（DDoS）。

故事人物：小王（网管）

四、故事背景

一大早出门就遇到堵车，到公司后，小王急匆匆走进办公室，门还没关好呢，就听见同事们在小声嘀咕，好像在讨论什么紧急的技术问题，听说是前几天刚加固的服务器，又登录不了了。没多久，运维团队就飞快地赶过去了。其中一个小伙伴急得像热锅上的蚂蚁，跑来告诉小王们：“咱们的阿里云服务器好像被冻住了，初步看可能是安全漏洞或者有人捣乱。”他接着说，所谓的“对外恶意发包”不只是服务器自己发了一堆没用的请求，搞得网络都堵车了，还可能涉及到网络攻击，就像是黑客用小王们的服务器搞了个分布式拒绝服务攻击（DDoS），搞得其他无辜的用户和服务商都跟着遭殃。

他接着说，看那日志记录，一堆来自不同地方的请求像潮水一样涌来，简直吓人！这些流量就像洪水一样，把小王们正常的业务流量全给淹没了，系统稳定性的帽子都快被冲走了。咱们的监控系统几乎招架不住这突如其来的状况，实时数据被那狂风暴雨般的流量给撕得粉碎，结果阿里云为了保护整个网络生态，不得不把小王们的服务器给冻住了。

这事儿让人心里更慌了，因为这冻住不只是服务暂时中断那么简单，后面可能还有调查、审核，甚至处罚等着呢。在这火烧眉毛的时刻，同事们一个个眉头紧锁，手机不停地响，好像随时都有新的警报要来。小王们得赶紧想个办法，尽快找出问题所在，把潜在的安全隐患给排查掉，这样才有可能让服务器重新跑起来。他的声音在这紧张的气氛中显得特别有力，“小王们得找到问题的根儿，确保以后不会再出这种事儿！”

他点了一根烟，让烟雾在肺里打转，然后开始连接SSH服务器。哎呀，屏幕上弹出一条血红的错误信息，小王心里一惊——连接被拒绝了！检查后发现，网络的22端口被封了。这不仅仅是让小王头疼的障碍，更是对服务器安全的担忧。小王赶紧联系了运维的小伙伴们，请他们帮忙调整一下端口配置。等了一会儿，端口终于开放了，小王迫不及待地重新尝试连接。

屏幕上那个闪烁的光标在等待回应，小王输入登录名的时候，心里突然有种不好的预感：竟然是“root”这个最高权限的用户！紧接着，小王输入密码，心都凉了——这密码也太弱了吧。

小王心想，黑客是怎么这么轻松就拿到这个弱密码的呢？是钓鱼邮件，也是运维的某个失误？

就像上集文章中网络安全攻击案例分析里说的，很多公司因为遭受DDoS攻击、钓鱼攻击等网络攻击而损失惨重，比如某个大型在线游戏平台因为DDoS攻击服务中断；还有银行用户因为钓鱼攻击泄露了账户信息，损失了不少钱。这些事件不仅导致了数据库被删、敏感信息泄露，还对公司的品牌形象造成了永久的伤害。这样的事情在安全圈子里层出不穷。现在，小王只能希望赶紧采取措施，查清楚服务器的情况，尽量控制住事态的恶化。

五、分析线索

服务器系统 CentOS 7.X，部署了 Nginx、Tomcat等应用，上来先把数据库全备份到本地，然后 Top 命令看了一下，有 2 个 99% 的同名进程还在运行，叫 gpg-agentd。这里GPG 提供的 gpg-agent 提供了对 SSH 协议的支持，这个功能可以大大简化密钥的管理工作。

这程序看起来挺正规的，但你再仔细瞧瞧，服务器上的进程名字后面带了个字母 d，伪装得挺像回事儿的，就像在 Windows 上那些冒充 svchost.exe 的病毒一样。

继续排查，咱们来看看进程号是23374的进程是从哪儿启动的，网络情况怎么样。这就得看图1的目录了，到这里为止，已经找到黑客留下的那个二进制文件了。

接下来还有两个问题得解决：

History 看一下，记录果然都被清掉了，没留下任何痕迹。继续命令 more messages：

大概在半夜12点的时候，小王发现服务器上装了好多软件，有几款特别吸引小王，接下来小王会详细说说。

一边找一边猜，如果小王们想干点坏事，可能会在哪些地方下手呢，是自动启动还是定时启动呢？对，计划任务：

1.crontab -e 

线索找到了。

这个计划任务的意思就是每 15 分钟去服务器上拿一个脚本，然后运行这个脚本。

脚本内容如下：

略

简单说说这个脚本是干啥的：是一个恶意脚本，它通过修改系统配置、设置SSH登录、创建定时任务和执行远程脚本来破坏系统安全。这种行为是非法的，并且对网络安全构成严重威胁。

首先它会关掉一个叫SELinux的东西，然后让Shell能随便访问东西，接着在/root/ssh/authorized_keys这个文件里头生成一个SSH的公钥。

这样一来，黑客每次登录这台服务器都不用输密码了，用起来就方便多了。

接下来，小王们会安装一个叫Bash的东西，然后继续下载第二个脚本叫bsh.php来运行。之后，小王们会下载并看看bsh.pbp里面都有啥：

代码略！ 

这个脚本搞了一系列操作，目的就是搞垮系统的安全和稳定。下面小王来简单说说脚本里几个重要步骤是啥意思：

脚本里用了一个叫sleep的命令，让系统随机等待几秒。

脚本还试图切换到/tmp或者/var/tmp目录。

接着脚本会创建一个叫.ICE-unix/的目录，给它所有权限，然后切换到这个目录里。

如果发现有个叫.watch的文件，脚本就会把它删了然后退出。

脚本还会时不时地用sleep命令让系统暂停一下。

脚本用ps和awk命令找特定的进程，比如redisscan、ebscan、redis-cli，然后把它们干掉。

脚本还会检查/usr/bin/gpg-agentd这个文件在不在，如果不在，就从远程服务器下载下来，设置成开机启动。

给/usr/bin/gpg-agentd执行权限，让它运行，如果失败了就删掉。

脚本还会检查masscan装了没，没装的话就更新系统，装上必要的依赖，然后下载安装masscan。

这个脚本的用意可能是要在目标系统上搞个后门，让攻击者能远程控制这个系统。

这段脚本的代码比较长，但主要的功能有 4 个：

• chmod u+x。
• rc.local，让本地代码开机自动执行。
• Github 上的开源扫描器代码，并安装相关的依赖软件，也就是小王上面的 Messages 里看到的记录。

小王浏览了Github上的这个开源代码，发现其性能非常出色：

Transmitting 10 Million Packets Per Second（每秒发送 1000 万个数据包），比 nmap 速度还要快，这就不难理解为什么阿里云把服务器冻结了。

小王快速浏览了Readme文件后，决定继续下载第三个脚本：

代码略

如果说前两个脚本只是在服务器上下载并运行了二进制文件，那么这个脚本才真正显示出它作为病毒的厉害之处。现在，小王们就来深入研究这个脚本。

一开始的修改系统环境没啥特别的，接下来的文件操作看起来有点熟悉，如果你用过 Redis，应该能猜到，这里是对 Redis 进行配置。

写这个配置，其实就是利用了 Redis 把缓存内容写入本地文件的漏洞，结果就是用本地的私钥去登录被写入公钥的服务器了，不需要密码就能登录，也就是小王们文章最开始提到的 /root/ssh/authorized_keys。

登录成功后，就开始定期执行预设的任务，下载并运行相关脚本。好了，配置文件准备好了，就开始用 Masscan 进行全网扫描 Redis 服务器，寻找肉鸡。

注意看这 6379 就是 Redis 服务器的默认端口，如果你的 Redis 的监听端口是公网 IP 或是 0.0.0.0，并且没有密码保护，那你就倒霉了。

仔细看看这三个脚本，你就能明白这个病毒有多厉害。它先是偷偷写入 ssh public key，这样就能登录进来了。然后它下载一个远程的二进制文件来执行，最后利用 Redis 漏洞疯狂复制自己，像病毒一样迅速传遍整个网络，增长速度像滚雪球一样。

那问题来了，这台服务器是怎么被感染的呢？小王检查了一下 redis.conf 文件，发现里面的 Bind 地址设置成了 127.0.0.1，看起来没啥问题。

所以小王觉得，应该是 Root 账号被人家用暴力破解了。为了验证小王的猜测，小王用 Lastb 命令查了一下，果然发现了很多尝试登录的记录：

略

最后一个问题来了，这个gpg-agentd程序到底是干啥的呢？小王第一反应是它可能跟挖矿有关，毕竟现在数字货币火得一塌糊涂，大家对分布式矿机的需求暴涨，这也催生了不少灰色产业。

于是小王就随手把gpg-agentd扔进Ida里，用String功能搜了搜bitcoin、eth、mine这些词，结果发现了这个：

恶意脚本细节略！

六、系统加固

1.服务器：

• ROOT账户，以防止未经授权的访问尝试。这是出于安全考虑，因为ROOT账户拥有服务器上的最高权限，任何利用该账户的攻击都可能导致严重的安全问题。
• SSH服务的默认端口22，因为端口22是众所周知的端口，容易成为攻击者尝试登录的目标。通过更改端口，可以减少自动化的扫描工具发现并尝试攻击服务器的机会。
• DenyHosts软件。这是一个专门用于防止SSH服务遭受暴力破解攻击的工具，它能够识别并阻止恶意的登录尝试。
• RSA公钥认证。这种方式通过使用一对密钥（一个公钥和一个私钥）来验证用户身份，比传统的密码认证方式更为安全，因为即使密码被破解，没有私钥也无法登录服务器。

2.Redis:

• Redis数据库，第一步是禁用公网IP监听。这包括禁止监听在0.0.0.0上的连接请求，因为这将允许任何网络上的设备尝试连接到Redis服务器，从而大大增加了遭受攻击的风险。
• Redis的访问，应使用密码进行访问控制。这意味着只有知道正确密码的用户才能连接到Redis服务器，从而提高了数据的安全性。
• Redis服务。这样做可以限制Redis进程的权限，即使Redis被攻破，攻击者也只能在有限的权限范围内进行操作，从而降低了潜在的损害。

七、后记

好了，整个黑客攻击的过程大致讲了一遍，提示大家一定要保持系统和软件的更新，及时修补漏洞。其次，对于网络流量和异常行为要保持警惕，使用防火墙和入侵检测系统来监控。最后，定期进行安全培训，提高员工的安全意识，防止钓鱼邮件等社会工程学攻击。

对于持续关注日志取证分析系列文章的读者而言，不难发现，这三篇文章广泛涵盖了网络安全、日志分析、系统管理以及法律等多个学科领域。尽管这些文章采用了故事化的技术叙述方式，但即便是技术新手也能轻松理解。为了实现这一目标，作者在文章的创作上采用了“从工作场景导入”→“到知识点讲解”→“再回到工作场景”的三段式结构。这种方法旨在尽量减少使用繁复的网络安全术语和复杂的程序代码，使更多读者能够透过现象洞察本质。尽管技术手段和语言表达方式可能发生变化，但分析事物的逻辑思维能力和判断力是始终不变的核心。这正是作者希望向读者传达的核心理念，期望读者在阅读过程中能够有所收获。

如果读者还意犹未尽的话，可以阅读《Unix/Linux网络日志分析与流量监控》这本书，书中提供二十多个网络日志分析、安全取证经的典案例。通过实战案例来学习网络安全的方方面面。该书计算机领域的经典之作，已经畅销长达十年之久，深受网络安全专业人员、企业信息化主管以及网络攻防演练红蓝战队的青睐。

机械出版社JD购书地址：https://item.jd.com/10026499621877.html  

双十二优惠活动：三折低价+免邮费