服务器被攻击后日志分析思路2026，定位入侵痕迹与攻击链

上周四刚帮隔壁公司的兼职运维救了个急——他们的电商后台突然被挂了恶意跳转链接，业务直接掉了30%多流量。那天早上运维的是个刚入行两年的小姑娘，当时慌得连SSH都差点登错机器，后来还是我跟着我一步步查日志才顺藤摸瓜找到是Redis未授权访问丢的壳。说实话，新手遇到攻击第一反应不是重装系统（当然如果是严重勒索那种别乱动数据，要先留证据！很多新手嫌备份系统留痕，直接就把恶意进程杀了重装，最后老板要溯源要问责要做安全复盘，连个像样的攻击路径都拿不出来，那才是真的头大。

首先开头我得先给姑娘上次复盘一下她当时的问题——她一开始是先看的网站后台，后台改了配置重启了Nginx，结果跳转还在，以为没杀干净，然后才慌慌张张来找我。那时候已经过了两个多小时，要不是我让她先拍了几个关键日志的快照，后来查起来还得花更多时间。别不信，真的有70%的新手会犯这种“先处理症状不管证据”的错误。

证据留存这里要说一下，首先用scp先把几个核心日志目录远程传到一台干净的备份机上，这个是第一步的前置——备份的时候要用tar打包，而且要加上exclude避免把恶意脚本带过去，打包的时候要加-cvfz，压缩率高点，传输快，命令大概是这样：tar -czvf attack_logs_$(date +%Y%m%d_%H%M).tar.gz /var/log/ /root/.bash_history /var/spool/cron /tmp exclude=/tmp/.so exclude=/tmp/.sh exclude=/tmp/.py exclude=/tmp/.bin，时间戳一定要加，方便后面复盘的时候好追溯。如果有条件的公司， 提前给审计工具auditd配置好关键目录的监控，audit.log能记录很多ssh暴力破解、文件篡改的操作，姑娘那台就是没开auditd，后来溯源到中间跳壳那段就靠对比备份日志才找出来点影子。

接下来顺攻击后排查的核心日志位置，先说大家最熟的系统认证日志，/var/log/auth.log或者/var/log/secure对吧？CentOS 7/8/9用的是secure，Ubuntu用的是auth.log。查这个日志主要看啥？看大量的Failed password，这个姑娘那边查出来凌晨3点多有个来自越南IP连续爆了root和那个兼职小姑娘配置的弱密码“admin123！哦不对，是admin@123admin？反正就是个很常见的组合，爆了大概5000多次，最后3点42分登进去了。这里给你们提个醒，新手别偷懒，系统默认root是禁止远程登录的，小姑娘嫌麻烦开了，这是第一个大漏洞！而且密码别用生日公司域名的变体，至少要8位以上大小写加符号加数字的随机组合，不行就用ssh-keygen生成密钥对，禁用密码登录，这个才是安全点的做法。

查完认证日志，接下来看Web服务的日志，比如Nginx的access.log和error.log，Apache的access_log和error_log。看access.log要找凌晨3点42分之后有没有奇怪的POST请求到后台管理页面，姑娘那边的access.log里找到3点45分有个POST到/wp-admin/plugins.php的请求，IP和爆SSH的那个IP一样，传了个zip文件，解压后是个隐藏的webshell.php。还有，这个webshell文件名是带混淆的，文件名是_abc123.php？哦不对，是用MD5加密的一部分，文件名是a1b2c3d4e5f6g7h8i9j0.php，看起来像是系统生成的临时文件？不仔细看根本注意不到。这里的避坑提醒第二个，别把Nginx的日志权限开得太大，别让用户能直接访问到/tmp目录，这个漏洞导致了后续能上传zip解压之后执行webshell，姑娘那边的Nginx配置里的root有问题，把整个/data/wwwroot目录里加了个/tmp的软链接，老板不让删说是方便开发调试，结果成了攻击的垫脚石。

顺藤摸瓜到这里，姑娘已经能找到挂恶意跳转的源头了，那个混淆的webshell里有个header函数，把所有来自百度搜索来的移动端用户跳转到了一个博彩网站。不过再往深挖的话，要看看有没有后续有没有下载或者执行了什么命令，那就要查/root/.bash_history，还有/var/spool/cron/root和/var/spool/cron/下的其他用户的定时任务，看看有没有定时从外部IP下载恶意脚本的命令。姑娘那边查bash_history发现凌晨3点50分有个wget命令从GitHub的一个公开仓库下载了个sh脚本，那个脚本是用来清理日志的，把刚才的wget命令和登录痕迹都清了，还好我之前让她拍了日志快照，不然这步就断了。那个脚本还改了几个核心系统命令，比如ps、netstat、top这些，加了个隐藏进程的脚本，还好我用了strace去查文件句柄才看到有个隐藏的Python进程在后台挖矿！姑娘一开始用ps根本看不到，用ss -tulpn也看不到挖矿的端口。

哦对了，ss命令现在应该普及一下，ps和netstat现在很多新版本的Linux系统里netstat被替换成ss了，而且ss的速度比netstat快很多，新手可以多用ss。刚才用ss -tulpn看不到的话，可以试试lsof -i 1-65535或者ps auxf | grep -v "grep" | grep -i "python|perl|bash"，如果还是看不到，那就得检查一下ld.so.preload文件，或者检查一下/proc目录下有没有陌生的PID，姑娘那边就是ld.so.preload被改了，加了个.so文件，把这些系统命令都hook了。

说实话，ld.so.preload这个文件是个大杀器，很多rootkit都会用到，新手一定要注意，没事别乱改这个文件的权限，默认是644就好，而且最好用chattr +i把它锁定，chattr +i /etc/ld.so.preload，这样连root都改不了，除非先chattr -i。

你们在运维工作中有没有遇到过类似的坑？欢迎在评论区分享你的排查经验。