服务器被入侵了怎么办

凌晨两点十七分，服务我的器被手机在床头柜上疯狂震动。监控系统弹出三条告警，入侵服务器CPU占用率飙到97%，服务出口流量每秒跑着2.3GB。器被第一反应是入侵“不可能”，第二反应是服务赶紧打开电脑。SSH连上去的器被那一刻，我看到了一个名叫“xmrig”的入侵进程，正安静地吃着所有核。服务

别慌，器被先拔网线。入侵是服务的，物理断开。器被别想着优雅地执行什么命令来隔离，入侵你根本不知道对方手里有什么权限。拔掉网线或者直接在云控制台关掉外网端口，这一步能让攻击者和你断开连接，给你争取到宝贵的思考时间。

然后才是取证。别急着重装系统，那是最偷懒也最蠢的做法。先做内存快照，再做磁盘快照。如果你用的是云服务器，控制台一般都有快照功能，立刻打一个。如果没有，那就用dd命令把整块盘镜像到另一台干净的机器上。这步做完，你才有资格去分析“怎么被入侵的”。

我那次遇到的情况，后来查出来是Redis未授权访问漏洞。6379端口直接暴露在公网，没有密码，攻击者用一条cron命令就把反弹shell写进去了。整个过程不到十秒。你根本想不到自己哪行配置会要命，所以我建议你平时就养成习惯：所有非必要端口，一律防火墙白名单；所有数据库和中间件，必须设强密码；所有对外服务，能跑在Docker里就别直接裸奔在宿主机上。

分析入侵路径的时候，重点看三样东西：系统登录日志（/var/log/auth.log或/var/log/secure）、历史命令（~/.bash_history）、以及最近被修改过的文件（用find / -mtime -3 -type f）。攻击者一般会清理痕迹，但总有漏网之鱼。我那次就在/tmp目录下挖出了一个伪装成.ice-unix的脚本，里面藏着下载恶意程序的完整URL。

拿到证据链之后，别自己扛着。如果服务器里有用户数据，特别是身份证号、手机号这类敏感信息，立刻报警。这不是小题大做，是合规要求。同时通知你的云服务商，他们一般有安全团队可以配合溯源。别怕丢脸，被入侵不丢人，丢人的是瞒着不报最后导致客户数据泄露。

清理阶段有个细节容易被忽略：检查SSH公钥。攻击者很可能把自己的公钥写进了~/.ssh/authorized_keys，就算你改了密码，他照样能进来。还有计划任务（crontab -l）和启动项（/etc/rc.local），这些是持久化后门的常见藏身处。我习惯把所有可疑文件打包留档，然后才重装系统。重装完第一时间修改所有密码，包括数据库、控制台、SSH密钥对。

最后说个扎心的事实：大多数人被入侵后，第一反应是“我是不是得罪谁了”。其实不是，绝大多数攻击都是扫描器自动完成的，你的服务器只是恰好暴露在互联网上的一个普通目标。跟黑客无冤无仇，纯粹是运气差。所以别纠结“为什么是我”，赶紧把系统重新加固一遍，然后睡个好觉。第二天太阳照常升起，你的服务器也照常运行。

对了，记得把这次入侵的全过程写进技术文档里。一方面给自己留个教训，另一方面，下次如果再碰到，你能更快地定位问题。我就把那次经历整理成了一篇排查手册，后来公司其他同事遇到类似情况，照着手册操作，半小时就能恢复业务。这比什么都值。