我负责管理香港裸金属服务器，遇到一次无预警的系统异常。日志无迹象、负载却飙高，最终发现是一个被劫持的二进制频繁触发异常系统调用，导致内核资源消耗暴涨。传统的 auditd 与 strace 监控方案性能开销太大，不适合线上实时运行。为了解决这个问题，我最终选择了 eBPF 实现系统调用级别的实时监控，并结合 ring buffer 高效捕获异常行为，既不影响性能，又能快速定位问题。
本文将还原我在香港服务器上的实战部署过程，核心目标是：在不中断线上业务的前提下，实时监控异常系统调用行为，并将关键事件写入日志系统或触发告警。
一、环境准备与内核要求
我选择的目标平台为香港自营节点，运行内核版本为 5.15.0，支持 eBPF（包含 BTF 格式），满足如下前提条件：
Linux Kernel ≥ 5.4（建议 5.10+ 以支持 ring buffer + BPF CO-RE）
安装 bcc 和 libbpf-tools
启用必要的内核配置项，如：
CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
CONFIG_DEBUG_INFO_BTF=y
CONFIG_KPROBE_EVENTS=y
实测部署服务器为 Ubuntu 20.04 + Kernel 5.15，自带 BTF 支持，无需自编译。
二、核心思路与技术路径
目标是“实时捕获异常系统调用行为”，但如何定义“异常”？
我的策略是：
- 白名单行为建模：统计各进程通常调用的 syscall 类型，建立 baseline。
- 实时监听 syscall：通过 tracepoint/sys_enter 捕获所有系统调用入口。
- 行为偏移检测：若某个进程调用了非常见 syscall，如 ptrace, reboot, bpf, kexec_load, mmap 等敏感行为，即判为可疑。
- 事件低开销导出：通过 ring buffer 将事件导出到用户态，避免 perf event 带来的抖动。
三、构建 eBPF 实现框架
我选用 libbpf + CO-RE 技术栈实现，具体包括内核 eBPF 程序 + 用户态 reader。
1. 编写 BPF 程序（C）
以下是核心片段，监听所有 syscall 入口：
SEC("tracepoint/syscalls/sys_enter")
int trace_syscall_enter(struct trace_event_raw_sys_enter *ctx) {
u32 pid = bpf_get_current_pid_tgid() >> 32;
u32 syscall_nr = ctx->id;
if (is_suspicious_syscall(syscall_nr)) {
struct syscall_event evt = {};
evt.pid = pid;
evt.syscall_nr = syscall_nr;
bpf_get_current_comm(&evt.comm, sizeof(evt.comm));
bpf_ringbuf_output(&events, &evt, sizeof(evt), 0);
}
return 0;
}
其中 is_suspicious_syscall() 是自定义黑名单判断逻辑，例如：
static __always_inline bool is_suspicious_syscall(u32 id) {
return id == __NR_ptrace || id == __NR_bpf || id == __NR_kexec_load || id == __NR_reboot;
}
2. 定义结构与 ringbuf 输出通道
struct syscall_event {
u32 pid;
u32 syscall_nr;
char comm[16];
};
struct {
__uint(type, BPF_MAP_TYPE_RINGBUF);
__uint(max_entries, 1 << 24);
} events SEC(".maps");
四、用户态捕获与输出（C / Python）
用户态 reader 用于读取 ring buffer 并打印日志或写入 ELK：
void handle_event(void *ctx, void *data, size_t len) {
struct syscall_event *evt = data;
printf("[!] PID=%d (%s) called suspicious syscall: %d\n",
evt->pid, evt->comm, evt->syscall_nr);
}
或者使用 Python 搭配 libbpf 封装模块读取 ringbuf 并转发至 Redis、Elasticsearch、syslog 等。
五、性能评估与优化建议
在香港 bare-metal 物理机（48核 Intel Xeon，512G 内存）上实测如下：
| 测试项 | 性能指标 |
|---|---|
| QPS（系统调用吞吐） | > 1M/s syscall 监控 |
| 平均延迟 | < 3μs / syscall hook |
| CPU 开销 | 单核浮动 1.2%~3.6% |
| 内存使用（ringbuf） | 可控在 16~32MB 范围内 |
相比传统 auditd 或 ptrace 方式，eBPF 几乎是量级上的提升。
六、告警与白名单策略
我补充了基于 PID + COMMAND 名称的白名单逻辑：
if (bpf_map_lookup_elem(&trusted_proc_map, &pid)) return 0;
并设定如下敏感 syscall 阈值触发告警：
- 单进程 10 秒内调用 bpf() ≥ 3 次
- 任意进程触发 ptrace()，立即推送至告警通道（如 Prometheus alertmanager + webhook）
七、总结与后续方向
基于 eBPF 的系统调用监控方案，已在香港多个节点部署上线，用于早期检测被劫持进程、恶意行为、以及预警新型后门特征。相比传统方法，这种方式不仅几乎无性能影响，而且可以灵活扩展到文件操作、网络连接、内核对象访问等维度。
下一步，我计划将此监控系统与容器运行时结合，实现对 Kubernetes pod 的系统调用行为可视化与异常剖析。
相关工具推荐：
- bcc：快速调试原型开发
- libbpf-bootstrap：用于构建 CO-RE 程序
- bpftool：调试 eBPF map/program 状态
- tracee：可参考的开源 runtime 安全项目（来自 Aqua）
如果你也在维护高安全需求的香港服务器，这类 eBPF 方案值得第一时间投入部署。
