服务器突然变慢，CPU 长时间顶满，网站时开时关。很多人第一反应是流量高了或者程序有 bug，但如果这些现象同时出现，业务量却没有变化，就要怀疑是不是被人动了手脚。个人站长和中小企业在阿里云上遇到被攻击的情况并不少见。下面说明发现异常后先查什么、怎么止损，以及之后该补哪些基础防护。
一、常见的攻击方式
攻击者一般不会专门盯着某一台机器，更多是用脚本扫描公网 IP 段，哪台开了弱口令或旧版本程序，就从哪里进去。下面几类比较常见。
- 暴力破解：针对 SSH、RDP、数据库端口反复试密码。如果日志里同一个 IP 在短时间内出现上百次失败登录，基本可以判断是这类。
- 挖矿木马：通过漏洞或弱口令植入程序，占满 CPU 和带宽去挖矿。典型表现是 CPU 长期高位，而访问量没有明显变化。
- DDoS 攻击：用大流量或大量请求把带宽和服务拖垮。判断时先看流量来源是否集中，再区分是攻击还是正常高峰。
- Web 应用漏洞：SQL 注入、文件上传漏洞、未授权访问等，目的往往是拿到 webshell，之后再做别的事。
- 勒索与数据窃取：批量加密文件或导出数据库，再用来索要赎金。一旦发现大量文件后缀被改动，应该马上断开外网。
二、两个常见场景
以下是常见情形的简化示意，细节做了调整，主要用来说明问题是怎么发生的。
场景一：弱口令让挖矿程序长期留在机器上
一台 ECS 上部署了 WordPress，SSH 用的是一个和其他账号相同的简单密码，而且没有关闭密码登录。过了几周，CPU 占用一直在 90% 以上，但站点访问量并没有涨。检查定时任务时，发现一条陌生记录，进程名伪装成系统程序，却指向一个外部下载地址。攻击者就是通过暴力破解 SSH 进入的，植入挖矿程序后还设置了开机自启。
处理时，先断网隔离，再清理定时任务和可疑进程，然后修改密码，改用密钥登录，并关闭密码登录。只要确认被植入过，最省心的还是重装系统，因为手工清理很难保证没有残留的后门。这类问题的入口通常很普通，就是弱口令加上公网开放的 22 端口。扫描器不挑目标，谁的密码弱，谁就先中招。
场景二：没有打补丁的上传插件
某个开源建站程序的文件上传插件存在公开漏洞，团队一直没有升级。攻击者上传了伪装成图片的脚本，借此拿到网站目录的控制权，改了页面，还拖走了部分用户数据。事后复盘，日志里早就出现过异常的上传请求，只是没有人去看。
这件事的责任落在应用层。阿里云提供的是底层的安全能力，业务程序的补丁、目录权限和日志，仍然要使用者自己盯着。
三、发现异常后的排查顺序
人一慌就容易直接重启、删文件，现场很快就被破坏。建议按下面的顺序来做。
- 先保存证据。导出系统日志、Web 访问日志和登录记录，放到别的位置保存。这一步做完之前，不要动手清理。
- 查看当前登录用户、开放端口、定时任务、开机启动项和正在运行的进程。进程名看着像系统程序，但路径不在标准系统目录下，就要重点怀疑。
- 到阿里云控制台的安全中心看告警记录，再结合云监控里 CPU 和网络流量的曲线，找出异常开始的时间点。有了时间点，回头查日志会快很多。
- 检查网站目录里最近被修改的文件，尤其是上传目录。图片目录里混进了 php、jsp 之类的脚本文件，要立刻记下来。
- 确认影响范围后，修改服务器账号和应用后台账号的密码与密钥。涉及数据库的，也要轮换数据库账号。
如果无法确定入侵是否彻底清除，最稳妥的做法是先备份数据，再重装系统，从干净的环境恢复业务。备份本身也可能已经被感染，所以恢复前要确认备份的时间点早于入侵发生的时间。
四、长期防护的基础措施
事后补救只能止损。提前做好下面几件事，就能挡住大多数自动化扫描。
- 关闭密码登录，改用 SSH 密钥，并在安全组里只允许可信 IP 访问 22 端口。密钥丢失时要有备用方案，否则连自己也进不去。
- 安全组最小化开放。数据库、Redis 这类服务不要直接暴露在公网上，需要远程访问时走内网或跳板机。
- 开启阿里云安全中心，重点关注漏洞修复建议和异常登录提醒。提醒出现后要有人负责处理，否则只是多一条通知。
- 固定周期检查系统和应用的补丁，尤其是建站程序和插件。不必追每一个版本，但已公开的高危漏洞要尽快处理。
- 定期备份，并做一次真正的恢复测试。很多人有备份，却从没验证过能不能用。备份最好放在独立的存储里，和服务器账号分开管理。
- 配置 CPU、流量和登录失败次数的告警，让异常在早期就能被发现。
五、小结
阿里云服务器被攻击，多数情况下问题出在账号没管好、补丁没打、日志没人看。日常把基础配置做扎实，大部分自动化扫描就进不来。真的遇到入侵，先保留证据，再逐步清除，最后加固，损失通常能控制在较小范围内。
