阿里云服务器被攻击后，我这样排查和止损，亲测有效

做运维这些年，我最怕的不是深夜告警，而是打开监控后台时，发现一台业务服务器的CPU、带宽和磁盘IO同时飙升。那种感觉，很多人经历过一次就忘不了。尤其是当业务跑在云上时，表面上看资源弹性很强，但一旦遇到异常流量、恶意扫描、暴力破解甚至植入后门，损失往往来得又快又猛。前段时间，我就真实经历了一次阿里云的服务器被攻击事件，从发现异常到排查来源，再到临时止损和后续加固，整个过程让我对云服务器安全有了更深的认识。今天把我的处理思路完整分享出来，希望能给同样遇到问题的人一些可直接参考的方法。

先说结论：不要一慌就重装，先保业务、再保现场、后做清理

很多人在发现服务器异常后，第一反应就是关机、重启、重装系统。这样做有时候确实能“快速恢复”，但也可能直接抹掉关键线索，导致后续根本不知道攻击是怎么进来的，修复完过几天又被打回来。我这次处理的核心原则只有三步：先止损，防止损失扩大；再排查，尽量保留证据；最后加固，堵住真正的入口。

这次异常最早是业务侧同事反馈接口响应明显变慢，用户后台偶尔超时。我登录阿里云控制台后先看云监控，发现那台ECS实例的出网流量在短时间内暴增，CPU长期维持在90%以上，而我们的业务本身并没有大促活动，也没有定时任务高峰。这个时候我基本判断，十有八九不是普通性能瓶颈，而是阿里云的服务器被攻击或者已经被植入恶意进程。

第一步：控制损失，优先切断异常攻击路径

当你怀疑服务器正在遭受攻击时，第一目标不是“找真相”，而是“先止血”。我当时做了几件非常关键的事。

• 立即修改安全组规则，只保留办公IP、堡垒机IP和必要业务端口，临时关闭不必要的对外访问。
• 检查是否需要临时下线对外服务。如果是核心业务，优先切流量到备用节点，避免生产实例继续被打。
• 在阿里云控制台查看DDoS基础防护和安全告警，确认是否存在大流量异常访问。
• 冻结可疑账号和密钥，包括服务器登录账号、应用连接密码、AccessKey等，防止攻击者进一步横向移动。

很多人忽略了一个问题：攻击不一定只是外部打流量，也可能是账号泄露后，攻击者直接登录机器运行挖矿程序、代理程序或木马。所以除了网络层面止损，我还同步做了身份层面的收口。比如立刻更换root密码，禁用密码登录，只保留SSH密钥认证；如果业务中用了数据库弱口令，也要同步修改，否则你即便把系统清干净，数据库还可能继续被拖库。

第二步：确认是“被打”还是“被控”，排查方向完全不同

很多人看到服务器卡顿，就笼统地说阿里云的服务器被攻击了。但从处置角度看，至少要分清两类情况：一种是外部流量攻击，导致服务不可用；另一种是系统已经被入侵，机器成了攻击者的工具。这两种场景的日志特征、处理优先级和恢复方式都不一样。

我当时先用几个简单命令快速判断系统状态。比如查看高占用进程、异常端口、可疑连接和计划任务。结果很快发现，有一个陌生进程长期占用CPU，并且对外发起大量连接，进程名伪装得很像系统服务，但路径非常可疑，不在常规系统目录下。继续查启动方式，发现它被写进了定时任务和rc本地启动项里。这基本可以确认，不只是被扫描，而是已经被植入了持续驻留程序。

到这里，排查思路就清晰了：不是单纯拦IP就能解决，而是要找到它从哪里进来的。

第三步：重点查这几个入口，基本能定位大部分问题

我总结下来，云服务器被入侵，最常见的入口无非以下几类，而且很多都是“老问题反复出现”。

1. SSH暴力破解或弱口令登录。这是最常见的入口之一，尤其是22端口全网开放、密码过于简单时，几乎等于在公网上裸奔。
2. Web应用漏洞。比如上传漏洞、命令执行漏洞、反序列化漏洞、历史组件漏洞等，攻击者拿到WebShell后再提权。
3. 未更新的中间件和面板。某些老版本Nginx、Tomcat、Redis、Docker组件或运维面板，一旦暴露在公网，很容易成为突破口。
4. AccessKey泄露。如果云账号相关密钥泄露，攻击者甚至不一定要登录系统，而是直接通过API操作资源。
5. 供应链风险。安装了不明脚本、来路不明的软件包，或者图省事执行了网上复制来的命令，都可能把后门主动装进系统里。

我这次最后定位到的问题，是一套老旧后台系统中存在上传校验不严的缺陷。攻击者先通过应用入口上传恶意文件，再落地脚本下载挖矿程序和守护进程。之所以会发现得这么晚，是因为业务日志和系统日志平时没有做集中分析，异常行为被埋在海量正常请求里，不容易第一时间察觉。

第四步：日志怎么查，别只盯着一处

很多人排查时只看应用日志，实际上这远远不够。我建议按“系统、网络、应用、云平台”四个层面同时看。

• 系统日志：重点看登录记录、提权记录、计划任务变更、异常新建用户、可疑启动项。
• 网络连接：看当前有哪些对外连接，哪些端口被异常监听，是否存在非常规国外IP通信。
• Web访问日志：重点查异常上传、可疑参数、批量扫描特征、特定漏洞利用路径。
• 阿里云侧告警：查看安全中心、云防火墙、操作审计等服务记录，很多线索会比本机更完整。

我当时就是通过Web日志发现，某几个时间点有非常明显的异常POST请求，路径集中、参数奇怪、来源IP分散但行为一致，随后系统日志里就出现了新的进程拉起记录。把这两类日志时间线一对，攻击链路基本就还原出来了。

第五步：清理时不要只删文件，要连“复活机制”一起处理

不少人发现恶意文件后，直接rm删除，以为事情结束了。结果过几分钟进程又起来了，因为攻击者通常会设置多重自启动机制。我的经验是，清理一定要成套做。

• 结束恶意进程，确认父子进程关系，避免只杀掉表层进程。
• 删除恶意文件和下载脚本，包括临时目录、隐藏目录、伪装目录下的文件。
• 清除计划任务、开机启动项、systemd服务项，防止再次拉起。
• 检查新建用户、SSH authorized_keys、sudoers配置，防止攻击者留后门账户。
• 核对应用目录完整性，确认是否被篡改页面、注入后门文件。

我在处理时就遇到一个典型情况：主恶意程序删掉后，过了一会儿又出现。后来才发现攻击者在两个地方都做了持久化，一个是cron定时任务，一个是伪装成系统服务的启动项。只有把这两个“复活点”都拔掉，机器才算真正安静下来。

第六步：要不要重装系统？我的建议是看业务价值和入侵深度

如果只是短暂被扫，没有拿到权限，修复漏洞和收紧策略通常就够了。但如果已经确认服务器被深度入侵，尤其是存在提权、后门、关键文件被修改、敏感数据可能泄露等情况，我的建议是：能重建就尽量重建，不要迷信“已经清干净了”。

我这次最终采取的是“双线处理”：一边保留受感染实例做取证和复盘，一边从干净镜像新建一台服务器，用最新补丁、最小权限配置和新的部署流程重新上线业务。这样做的好处是，既不影响后续定位问题，也避免在一台“不再可信”的机器上继续承载生产流量。

第七步：复盘后我做了这些加固，效果非常明显

经历过一次阿里云的服务器被攻击，你会明白安全从来不是装个杀毒软件那么简单，而是一个持续治理的过程。事后我重点做了这些加固动作，后续确实减少了很多风险。

1. 关闭密码登录，统一改为密钥登录，SSH端口不再全网开放，只允许固定出口IP访问。
2. 启用阿里云安全中心和云防火墙，把基础告警、入侵检测和异常外联监控用起来。
3. 安全组最小化开放，业务不需要的端口一律不暴露公网。
4. 建立漏洞修复周期，系统补丁、中间件版本、应用组件定期升级。
5. 日志集中化，把系统日志、访问日志、告警日志统一汇总，方便做关联分析。
6. 关键目录做完整性校验，防止网页被篡改、程序被偷偷替换。
7. 定期备份和演练恢复，真出问题时能快速切换，而不是现场手忙脚乱。

写在最后：被攻击并不可怕，可怕的是不知道自己为什么会被打

说到底，阿里云的服务器被攻击并不是小概率事件。只要服务器暴露在公网，只要账户、应用、配置里存在薄弱环节，就迟早会遇到扫描、探测甚至真正入侵。区别只在于，有的人在告警响起的第一分钟就能准确止损，有的人却要等业务彻底崩掉才发现问题。

如果你现在也正在处理类似情况，我建议你先稳住节奏：先隔离风险，再保留现场，然后从登录入口、应用漏洞、异常进程、计划任务、云平台审计这几个方向逐步排查。不要急着“恢复正常”，而要先搞清楚攻击者是怎么进来的、有没有留下后门、数据是否受到影响。只有这样，问题才是真正解决，而不是暂时安静。

我这次的亲测经验可以总结成一句话：止损要快，排查要细，重建要果断，加固要长期。服务器安全没有一劳永逸，但只要流程正确、动作到位，大多数风险都能被控制在可承受范围内。这也是我经历这次事件后，最深的一点体会。