凌晨两点十七分，黑客运维老张的攻击手机响了。监控平台推送的事件告警只有一行字：核心数据库CPU飙到98%，持续超过五分钟。应急预案他爬起来打开电脑，黑客发现Web服务器正在向一个境外IP传输压缩包，攻击文件名是事件`user_data_20240817.tar.gz`。这不是应急预案演习。

攻击者大概率已经拿到了某个低权限账号。黑客怎么拿的攻击？可能是钓鱼邮件，可能是事件某个没打补丁的Nginx漏洞，也可能是应急预案外包开发人员把测试密钥传到了GitHub。不管入口是黑客什么，现在要做的攻击不是追查原因，而是事件先切断数据外流。

第一步，隔离。别想着先取证再断网，数据传完了你连日志都未必留得住。直接拔网线或者改安全组规则，把受影响主机从生产环境摘出去。注意，别关机——内存里的进程信息、网络连接状态，关机就全没了。用`netstat -antp`和`ps aux`把当前连接和进程列表存下来，截图也行。

第二步，改密码。所有系统账号、数据库账号、API密钥、SSH密钥，全部重置。别只改被攻击那台机器的，同一套凭据可能在别的服务器上复用。我们那次事故，攻击者就是用一个运维人员五年前在论坛上泄露的密码，撞进了跳板机。改完密码之后，立刻启用双因素认证，能挡掉后续九成以上的暴力尝试。

第三步，查后门。攻击者通常会留至少一个Web Shell或者计划任务。翻`/var/www/html`下最近修改的PHP文件，看`crontab -l`有没有奇怪的定时脚本，检查`/etc/passwd`里有没有新增的UID 0用户。有个细节：很多入侵者会把后门文件时间戳改成和系统文件一样，用`find / -mtime -1`找最近一天被改过的文件更靠谱。

第四步，恢复业务。从备份恢复之前，先确认备份本身没被污染。我们吃过亏——备份脚本把数据库导出到同一台机器的`/tmp`目录，攻击者顺手把备份也加密了。正确做法是备份文件异地存储，恢复前校验哈希值。业务恢复后别急着全量开放，先切百分之五的流量观察半小时，确认没有异常回连再逐步放开。

第五步，写报告。不是给领导看的PPT，是给技术团队看的复盘文档。写清楚：攻击时间线、入口点、影响范围、处置动作、哪些环节慢了。比如我们那次，从告警到断网花了二十二分钟，其中八分钟浪费在找安全组密码上。这种细节不写下来，下次还会踩同样的坑。

最后说一个容易被忽略的点：通知。如果用户数据确实泄露了，法务和公关要提前介入。别等媒体爆出来再回应。我们当时给受影响用户发了邮件，说明泄露了哪些字段、建议改密码、附上免费信用监控链接。虽然麻烦，但比事后被起诉强。

攻击不会只来一次。把这次事件里用到的命令、脚本、联系人清单整理成一个`runbook`，放在内网Wiki上。下次半夜再响警报，值班的人不用从头翻文档。老张后来把那个压缩包追回来了——攻击者还没来得及删，因为传输速度被我们限了流。运气好，但别指望运气。