你的服务器被黑了，第一反应是什么？

“网站打不开”“后台多了个不认识的用户”“数据库里突然多出一堆奇怪记录”——这种消息弹出来的时候，手心一凉，心跳加速，脑子先空白三秒。

别急着重装系统，也别马上删日志。你现在最该做的，是像警察封锁案发现场一样，先把服务器“按住”，再一点点翻线索。

第一步：立刻隔离，保护现场

先断网，别关机。

物理拔线、云控制台禁用网卡、安全组封掉所有入向流量——怎么快怎么来。目的是让攻击者进不来、也跑不掉。

但千万别直接 reboot 或 poweroff。内存里可能正跑着Webshell、正连着C2服务器、或者刚解密完的恶意载荷还没写到磁盘。这些全会随着断电消失。

稳妥做法是：

  • 如果环境支持，先用 dd if=/dev/mem of=/tmp/mem.dump（或 volatility 工具）抓个内存快照；
  • 再执行 systemctl suspend 或 echo mem > /sys/power/state 把系统挂起；
  • 最后断网。

一个真实案例：某本地生活平台发现订单后台被篡改。运维小哥看到告警就顺手重启了应用服务器，结果攻击者刚上传还没执行的PHP木马、正在内存中轮询C2的心跳包、甚至SSH会话里的临时命令历史，全没了。后来光是还原攻击入口，团队熬了两个通宵翻日志。

服务器日志，你的“黑匣子”

日志不是等出事才看的摆设。它就是你没开摄像头时，服务器自己记的流水账。

重点盯这三类：

  1. 访问日志：Nginx/Apache 的 access.log。不用从头读，直接 grep -E "(php\?|\.php\?|/wp-admin|/admin\.php|union.*select|<script)" access.log | tail -50，找那些明显不像正常请求的URL。
  2. 登录日志：Linux 的 /var/log/auth.log（Ubuntu/Debian）或 /var/log/secure（CentOS/RHEL）。grep "Failed password" auth.log | awk '{print $11}' | sort | uniq -c | sort -nr | head -10，一眼揪出扫密码最凶的IP。
  3. 命令历史：cat ~/.bash_history、cat /root/.bash_history，再查下 last -a 看最近谁登过、从哪登的。攻击者留下的痕迹，往往就藏在最后几条命令里。

时间范围很关键——锁定你发现异常的前后2小时内，别在三年日志里大海捞针。

哪些文件被动了手脚？

攻击者不会只来逛一圈。他们一定会留后门、改页面、加定时任务。

快速排查这几处：

  • Web目录下的“影子文件”：进到 /var/www/html 或你的站点根目录，find . -name "*.php" -size +10k -ls | head -20，挑几个体积大、名字怪（比如 a.php、123.php、img_20240401.jpg.php）的打开看看，十有八九是Webshell。
  • 定时任务里的“幽灵指令”：crontab -l 查当前用户，cat /etc/crontab 和 ls /etc/cron.d/ 看系统级任务。留意那些指向陌生路径、调用 curl 或 wget 下载脚本的行。
  • 偷偷加的用户和提权工具：cut -d: -f1 /etc/passwd | sort 对比下有没有眼生的用户名；再跑 find / -type f -perm -4000 2>/dev/null | grep -E "(nmap|python|perl|bash)"，SUID权限+解释器组合，大概率是攻击者埋的提权后门。
  • 两天内新增/修改的文件：find /var/www -type f -mtime -2 -ls | head -30，优先检查图片目录、上传目录、模板目录。

一个具体场景：某企业官网首页突然跳转赌博站。溯源时，在 /uploads/2024/04/ 下发现一个叫 logo.png.php 的文件，内容是一段base64加密的eval代码。顺着这个文件的 stat logo.png.php 查创建时间，再回查同一秒的 access.log，定位到一个未过滤的图片上传接口——漏洞根源当场坐实。

网络流量里藏着什么线索？

哪怕没装Zeek或Suricata，Linux自带的工具也能挖出关键信息。

如果服务器还在线（隔离前），立刻执行：
netstat -tulnp | grep -E ":(31337|6666|4444|5555)" —— 这些是常见后门端口；
ss -tunap | grep ESTAB | grep -v "127.0.0.1" —— 看有没有连向境外IP或非常规域名的稳定连接；
tcpdump -i any port 53 -w dns.pcap -c 1000（如果还能抓包）—— DNS请求常被用来做C2通信，尤其是一堆随机子域名解析。

更简单的办法：
去云厂商控制台翻“流日志”或“VPC流日志”。阿里云、腾讯云、华为云都有，不用额外部署，打开就能看——哪些IP在疯狂连你、连的什么端口、有没有大量短连接又断开，一目了然。

如何拼凑出攻击者的画像？

现在你手里有：
✔️ 一个可疑IP（来自auth.log）
✔️ 一个Webshell文件（在/uploads里）
✔️ 一条C2连接记录（netstat里看到的）

下一步不是百度IP归属地，而是串时间线：

  1. 这个IP第一次出现在 auth.log 是什么时候？
  2. 它成功登录后，~/.bash_history 里第一条命令是什么？
  3. 那条命令下载的脚本，最后修改时间是否和Webshell创建时间吻合？
  4. Webshell被访问的时间点，是否和 access.log 里某个异常POST请求一致？

把这几个时间戳对齐，你就知道：他怎么进来的（弱口令爆破）、进来干了啥（上传木马）、后续想干嘛（连C2发指令）。至于IP是谁——大概率是黑产租的云主机，追到底意义不大；但它的行为模式（比如总在凌晨3点活动、固定用某个User-Agent），能帮你设规则拦住下一轮。

事后总结：如何避免下次手忙脚乱？

复盘不是走形式。问自己四个问题，每个都要有答案：

  • 漏洞在哪？是SSH密码太简单？还是用了带CVE的老版本ThinkPHP？
  • 我们花了多久才发现？是靠用户投诉？还是监控根本没告警？
  • 日志有没有被自动清理？/var/log/nginx/access.log 昨天的内容还在不在？
  • 团队里谁该第一时间拉群？谁负责断网？谁负责备份日志？流程写在纸上，还是只存在老员工脑子里？

根据答案，马上动手：
✅ 把SSH密码全换成密钥登录（ssh-copy-id 三分钟搞定）；
✅ 给所有Web服务加个基础WAF（Nginx里加几行if规则，或用云厂商免费版）；
✅ 把关键日志同步一份到另一台干净服务器（rsync -avz /var/log/nginx/ user@backup:/backup/nginx/）；
✅ 每月用 lynis audit system 扫一次基线配置，生成报告存档。

今天下班前就能做的一件事

打开终端，连上你最重要的那台生产服务器，执行这三步：

  1. ls -lh /var/log/ | grep "access\|auth\|secure" —— 看日志文件是不是还在，大小是否合理；
  2. cat /etc/logrotate.d/nginx 2>/dev/null | grep -A5 "rotate" —— 确认Nginx日志保留周期至少是30天；
  3. 如果发现 missingok 或 nocreate 后面没配归档路径，立刻编辑：sudo nano /etc/logrotate.d/nginx，把 rotate 30 和 compress 加进去，保存退出。

做完这三步，你至少保住了下次被黑时最关键的证据——日志。它不会让你百毒不侵，但能让你在慌乱中，稳稳抓住第一根救命稻草。