通过从proc文件系统入手，来检测可能的ptrace进程注入

探究

根据man proc的结果，在 /proc/[pid]/status的字段描述有这么一段

* TracerPid: PID of process tracing this process (0 if not being traced).

说明可以从进程的status文件这个字段得到该进程的跟踪进程。

看一下对进程使用ptrace是否会设置这个字段。

由于gdb是基于ptrace实现的，可以使用gdb来检查一下效果。

可以下载gdb代码搜索ptrace验证

选用oseec-remoted进程做例子

[[email protected] code]# ps aux|grep remoted
ossecr      2238  0.1  0.3 1254156 14188 ?       Sl   Aug09   2:27 /var/ossec/bin/ossec-remoted

它的pid是2238。可以看到它的TracerPid的值是0

[[email protected] code]# grep "TracerPid" /proc/2238/status
TracerPid: 0

在另外一个窗口使用gdb附加到2238进程

[[email protected] buckxu]# gdb -p 2238 -q
Attaching to process 2238
[New LWP 2265]

这时，它的TracerPid的值变了

[[email protected] code]# grep "TracerPid" /proc/2238/status
TracerPid: 18669

看一下18669这个进程是哪个

[[email protected] code]# cat /proc/18669/cmdline 
gdb-p2238-q

可见，TracerPid字段确实可以知道哪个进程对另外一个进程使用ptrace。

那么，接下来的检测的思路就非常简单了。

检测思路

对/proc下的进程进行扫描：

1. 读取进程的status文件TracerPid字段
2. 如果字段为0，则跳过，否则就看/proc/<TracerPid>/cmdline，获取程序信息
3. 把程序信息上报

分析端获取到上报数据后，就对照白名单，如果使用ptrace的程序不在白名单，那么就有可能是可疑程序，需要进一步分析了。

扫描的程序需要静态编译，使用-static，因为这样扫描出那些使用/etc/ld.so.preload来隐藏自身的进程。

缺点

一般ptrace注入过程时间非常短，而遍历/proc的时间会比较长，往往会错过那些快速注入的恶意进程。而把扫描频次调高，又会引起对系统性能的占用。