Windows进程CPU、内存等资源限制

Windows自身没有提供类似Linux cgroup的能力来限制进程或进程组的资源占用,进程CPU/IO/内存/网络等资源的控制只能由自己实现。目前已有第三方的实现,主要是限制进程CPU的占用,如文档 < 21 Best Ways to Limit the CPU Usage of a Process > 所描述的BES,Process Tamer等软件。自Windows 8及Server 2012开始Windows系统有提供以job为单位的CPU占用及内存上限设置,之前的版本则只能以进程或线程为单位进行限制。

进程CPU占用限制方案

即时轮询系统所有进程(线程)的CPU占用,当发现所设定进程有超标时强制暂停进程所有线程的执行,然后在适当的时机再恢复执行。其中所涉及技术点:

进程CPU占用查询 GetProcessTimes

BOOL GetProcessTimes(
  [in]  HANDLE     hProcess,
  [out] LPFILETIME lpCreationTime,
  [out] LPFILETIME lpExitTime,
  [out] LPFILETIME lpKernelTime,
  [out] LPFILETIME lpUserTime
);

此函数可以获取进程从创建至当前的总运行时间及总的CPU时间,(KernelTime + UserTime) < 系统CPU数 * (当前时间 - CreationTime)

线程CPU占用查询 GetThreadTimes

BOOL GetThreadTimes(
  [in]  HANDLE     hThread,
  [out] LPFILETIME lpCreationTime,
  [out] LPFILETIME lpExitTime,
  [out] LPFILETIME lpKernelTime,
  [out] LPFILETIME lpUserTime
);

QueryThreadCycleTime可以提供更精准的CPU时间数据,单位为CPU时钟周期

BOOL QueryThreadCycleTime(
  [in]  HANDLE   ThreadHandle,
  [out] PULONG64 CycleTime
);

线程暂停及恢复

Windows平台没有提供暂停整个进程的支持函数,只能以线程为单位来操作,即SuspendThread及ResumeThread:

DWORD SuspendThread(
  [in] HANDLE hThread
);
DWORD ResumeThread(
  [in] HANDLE hThread
);

CPU亲和性设置: SetProcessAffinityMask

BOOL SetProcessAffinityMask(
  [in] HANDLE    hProcess,
  [in] DWORD_PTR dwProcessAffinityMask
);

此函数可以限定进程及其所有线程所能使用的CPU,故一定程序上亦限定了进程最大的系统CPU占用率。

DWORD_PTR SetThreadAffinityMask(
  [in] HANDLE    hThread,
  [in] DWORD_PTR dwThreadAffinityMask
);

此函数可单独限制特定线程的CPU亲和性。

进程优先级设置: SetPriorityClass

优先级解决的是优先运行及退让CPU的问题,本质上并不能限定CPU占用,只是优先级高于当前任务的忙碌的时候,当前进程会主动退让CPU 线程优先级设置:SetThreadPriority

BOOL SetThreadPriority(
  [in] HANDLE hThread,
  [in] int    nPriority
);

Job Objects

Windows系统提供了Job的概念用以管理多个进程,可以限制Job对象内所有进程及期线程的CPU核心占用、CPU占用及内存分配上限等,均通过SetInformationJobObject来实现,具体的CPU限制由JOBOBJECT_CPU_RATE_CONTROL_INFORMATION管理,内存限制则由JOBOBJECT_EXTENDED_LIMIT_INFORMATION来管理。

BOOL SetInformationJobObject(
  [in] HANDLE             hJob,
  [in] JOBOBJECTINFOCLASS JobObjectInformationClass,
  [in] LPVOID             lpJobObjectInformation,
  [in] DWORD              cbJobObjectInformationLength
);

需要注意的是CPU占用设置只有Windows 8及Server 2012之后的版本有效。

CPU Sets

此部分只限定了CPU Affinity属性

实验验证

可以直接利用开源项目go-winjob验证,验证系统Windows 8 x64,go-winjob git repo: https://github.com/kolesnikovae/go-winjob

验证程序

#include &lt;stdio.h&gt;
#include &lt;stdlib.h&gt;

void main(int argc, char *argv[])
{
        unsigned long total = 0, count = 0, i = 0;

        while (1) {
                if (malloc(1024)) {
                        total += 1024;
                        count++;
                }
                if (!(++i &amp; 4095))
                        printf(&quot;alloc: %u size: %u bytes\n&quot;, count, total);
    }
}

无限制

在无限制的情况下,此进程会占满一个CPU核心,commit内存总占用达2G CPUStress unlimited

单一进程

在设定CPU上限16%及内存16M上限之后,结果如下: CPUStress single process examples/job_object.go按如下修改:

var limits = []winjob.Limit{
        winjob.WithBreakawayOK(),
        winjob.WithKillOnJobClose(),
        winjob.WithActiveProcessLimit(3),
        winjob.WithProcessTimeLimit(10 * time.Second),
        winjob.WithCPUHardCapLimit(1600),        // 16%
        winjob.WithProcessMemoryLimit(16 &lt;&lt; 20), // 16MB
        winjob.WithWriteClipboardLimit(),
}

const defaultCommand = &quot;.\\CPUStress.exe&quot;

多进程(双进程)

将winjob.WithProcessMemoryLimit 改为 winjob.WithJobMemoryLimit,后者表示此job内所有进程要占用的总内存限制:

var limits = []winjob.Limit{
        winjob.WithBreakawayOK(),
        winjob.WithKillOnJobClose(),
        winjob.WithActiveProcessLimit(3),
        winjob.WithProcessTimeLimit(10 * time.Second),
        winjob.WithCPUHardCapLimit(1600),    // 16%
        winjob.WithJobMemoryLimit(16 &lt;&lt; 20), // 16MB
        winjob.WithWriteClipboardLimit(),
}

验证结果如下: CPUStress 2-processes CPUStress 2-processes

winjob example代码:

// +build windows

package main

import (
        &quot;encoding/json&quot;
        &quot;log&quot;
        &quot;os&quot;
        &quot;os/exec&quot;
        &quot;os/signal&quot;
        &quot;time&quot;

        &quot;golang.org/x/sys/windows&quot;

        &quot;github.com/kolesnikovae/go-winjob&quot;
)

var limits = []winjob.Limit{
        winjob.WithBreakawayOK(),
        winjob.WithKillOnJobClose(),
        winjob.WithActiveProcessLimit(3),
        winjob.WithProcessTimeLimit(10 * time.Second),
        winjob.WithCPUHardCapLimit(1600),    // 16%
        winjob.WithJobMemoryLimit(16 &lt;&lt; 20), // 16MB
        winjob.WithWriteClipboardLimit(),
}

const defaultCommand = &quot;.\\CPUStress.exe&quot;
const stressCommand  = &quot;.\\CPUStressX64.exe&quot;

func main() {
        job, err := winjob.Create(&quot;&quot;, limits...)
        if err != nil {
                log.Fatalf(&quot;Create: %v&quot;, err)
        }

        cmd := exec.Command(defaultCommand)
        cmd.Stderr = os.Stderr
        cmd.SysProcAttr = &amp;windows.SysProcAttr{
                CreationFlags: windows.CREATE_SUSPENDED,
        }
        if err := cmd.Start(); err != nil {
                log.Fatalf(&quot;Start: %v&quot;, err)
        }

        stress := exec.Command(stressCommand)
        stress.Stderr = os.Stderr
        stress.SysProcAttr = &amp;windows.SysProcAttr{
                CreationFlags: windows.CREATE_SUSPENDED,
        }
        if err := stress.Start(); err != nil {
                log.Fatalf(&quot;Start: %v&quot;, err)
        }

        s := make(chan os.Signal, 1)
        signal.Notify(s, os.Interrupt)

        c := make(chan winjob.Notification)
        subscription, err := winjob.Notify(c, job)
        if err != nil {
                log.Fatalf(&quot;Notify: %v&quot;, err)
        }

        done := make(chan struct{})
        go func() {
                defer close(done)
                ticker := time.NewTicker(time.Second * 5)
                defer ticker.Stop()
                var counters winjob.Counters
                for {
                        select {
                        case &lt;-s:
                                log.Println(&quot;Closing job object&quot;)
                                if err := job.Close(); err != nil {
                                        log.Fatal(err)
                                }
                                log.Println(&quot;Closing subscription&quot;)
                                if err := subscription.Close(); err != nil {
                                        log.Fatal(err)
                                }
                                return

                        case n, ok := &lt;-c:
                                if ok {
                                        log.Printf(&quot;Notification: %#v\n&quot;, n)
                                } else if err := subscription.Err(); err != nil {
                                        log.Fatalf(&quot;Subscription: %v&quot;, err)
                                }

                        case &lt;-ticker.C:
                                if err := job.QueryCounters(&amp;counters); err != nil {
                                        log.Fatalf(&quot;QueryCounters: %v&quot;, err)
                                }
                                b, err := json.MarshalIndent(counters, &quot;&quot;, &quot;\t&quot;)
                                if err != nil {
                                        log.Fatal(err)
                                }
                                log.Printf(&quot;Counters: \n%s\n&quot;, b)
                        }
                }
        }()

        if err := job.Assign(cmd.Process); err != nil {
                log.Fatalf(&quot;Assign: %v&quot;, err)
        }
        if err := winjob.Resume(cmd); err != nil {
                log.Fatalf(&quot;Resume: %v&quot;, err)
        }

        if err := job.Assign(stress.Process); err != nil {
                log.Fatalf(&quot;Assign: %v&quot;, err)
        }
        if err := winjob.Resume(stress); err != nil {
                log.Fatalf(&quot;Resume: %v&quot;, err)
        }

        if err := cmd.Wait(); err != nil {
                log.Fatalf(&quot;Wait: %v&quot;, err)
        }
        if err := stress.Wait(); err != nil {
                log.Fatalf(&quot;Wait: %v&quot;, err)
        }

        // Wait for a signal.
        &lt;-done
}

参考链接

  1. 21 Best Ways to Limit the CPU Usage of a Process
  2. MSDN: Windows Process and Thread Functions
  3. MSDN: CPU Sets
  4. GetThreadTimes

预测未来7步法

对男人来说拥有精准如女人般的第六感听起来不像是什么好事,可如果能用来预测未来那就不一样了,试想当别人还摸着石头的时候你却已经站在桥头的优越感。

未来学家尼尔·伯勒斯归纳出了理解未来的7个原则,这7个原则有很强的操作性,可直接上手:

1 从确定性开始(使用硬趋势预测将会发生什么) 2 洞察先机(基于你所知的未来确立策略) 3 变革(利用技术驱动型变革发挥自身优势) 4 跳出你面临的问题(这并非真正的问题) 5 反其道而行(看向没有人关注的方向,做没有人做过的事) 6 重新定义和再创造(用强有力的新方式识别并利用你的独特性) 7 主导未来(否则被别人主导)

说实话我读完全书还是没能理解作者为什么这样界定这7个原则,这些原则间并没有一而贯之的逻辑,并且相互间还有些交叉重叠,不过当作检查表来用确实可以拿来即用。这几个步骤简言之就是:识别你的问题及其边界,理解问题所涉及领域的硬趋势,硬趋势就是确定性的未来,知道了硬趋势就像是穿越到了未来并站在未来的制高点上反过来寻找通往未来的路径并思考如何利用自己的优势以确保超越路上所有的障碍。

比如你领导给你出一个难题:将一头大象装到冰箱里。这个问题涉及到了多个行业及领域,如制造业、生物学等,甚至还牵扯到了物流 :) 你不得不绞尽脑汁思考应对的办法,比如造个超大冰箱,或者发明个能自由缩放物体的装置,亦或一个能将物体电子化/数字化又能根据信息即时重组实体的“传送机”,当然时光机更可以,利用时光机将大象还原成小象或者干脆还原成一个受精卵的状态。科技的想像就是没有边界,远超你所想。此时你的问题已不再是问题,毕竟时光机都有了还要啥自行车嘛 :)

另外也不妨再反过来想想你领导为什么给你出这么个难题:或者他想让他老婆的二舅的小儿子的女同学的二妹来顶替你的位置,或者是他领导的领导不爽他才故意给他出了这个难题,结果你领导想了几天也没想到办法便直接将锅抛到了你头上。既然想到了这里,那后面就是要联合你领导的领导干掉你领导还是联合你的领导一起解决掉大领导的问题了 ...

小王子的”B 612″星球

小王子的"B 612"星球倒底有多大?注意星球代号是有空格的 :)

第六章中曾说过小王子在一天中看到过43次日落,而且还是带着椅子边挪边看的。假设B 612星球一天也是24小时,并且小王子追逐日落的活动正好用了24小时且刚好走完一圈,当然如果星球够大的话是用不着走一圈的,只不过“正好一圈“的行程更符合小王子的人设。再假设观看日落时间共5分钟,即小王子坐椅子看日落的总时间为435分钟,其余的时间均需要走路赶去后面的时区。带着椅子挪步的速度肯定快不了,考虑到小王子的运动能力及喜动的性格,且算作是4公里/小时,所以B 612星球周长为4 (24 - 43 5 / 60) = 81.7KM,可得B 612星球直径为81.7 / 3.14 = 26KM,故星球总面积为: 3.14 26 * 26 = 2122 平方公里,差不多1/3个上海,或者1个海口的大小

知乎网友提供了不同的答案:https://www.zhihu.com/question/23241753

通过QEMU/KVM GDB Stub进行内核调试

内核准备

内核配置

建议从源代码重新编译内核,这样可以更方便地进行源代码级调试;当然自己从发行版官网下载相应内核的调试符号亦可以,通常情况下只用于应急分析,比如crash dump分析等。

自己编译Linux内核的话,最好打开两个选项:

CONFIG_DEBUG_INFO=y
CONFIG_GDB_SCRIPTS=y

可通过make menuconfig来设置内核配置项,分别以5.12及6.1.0为例: 5.12: Linux kernel 5.12 menuconfig 6.1.0: Linux kernel 6.1.0 menuconfig

禁止编译优化

无法针对Linux内核禁止全局优化,但可以针对特定的源代码文件做禁止编译优化的处理,可通过以下方式达成:

在需要被调试的源代码文件头部增加下面一行代码:

#pragma GCC optimize ("O0")

或者修改其对应的Makefile,以文件名core.c为例:

CFLAGS_REMOVE_core.o := -O2
CFLAGS_core.o := -O0

镜像准备

建议通过libvirt来管理本地KVM虚拟机,这样使用起来非常方便,如果条件不允许的话亦可用qemu命令行方式来运行。

添加 gdb stub

下面的示例是以命令行方式来运行调试目标:

qemu-system-x86_64 -m 4096 -nographic -net user,hostfwd=tcp::44334-:22 -net nic -hda \
    debian-10.7.qcow2 -machine type=pc,accel=kvm -cpu host -smp 4 -gdb tcp:127.0.0.1:44333

“-gdb tcp:127.0.0.1:44333” 就是gdb stub的命令行参数,即gdb可连接localhost:44333来调试目标系统。

如果使用libvirt的话则需要修改QEMU配置,可通过命令virsh edit来进行修改,需要在末尾加上中间4行:

   </devices>

   <qemu:commandline>
    <qemu:arg value='-gdb'/>
    <qemu:arg value='tcp:localhost:44333'/>
  </qemu:commandline>

</domain>

另外还需要更改虚拟机配置文件的domain type,即将第一行从

<domain type='kvm'>

改为:

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>

修改内核启动项

本步骤主要为了禁止内核地址随机化,不然内核符号无法定位并正确绑定。可通过修改grub项完成,在安装新内核过程中会自加增加nokaslr及nopti,当然在编译内核时亦可直接禁止相应功能亦可。

root@T490:~# cat /etc/default/grub | grep nokaslr
GRUB_CMDLINE_LINUX_DEFAULT=&quot;noquiet nopti nokaslr console=ttyS0&quot;

最直接的方式就是直接修改/boot/grub/grub.cfg文件,或者在系统启动时手工编译grub启动项亦可:

root@T490:~# cat /boot/grub/grub.cfg | grep nokaslr
    linux   /boot/vmlinuz-5.10.14 root=UUID=c4072cd3-9ed9-4376-b85c-95d1306e817b ro  noquiet nopti nokaslr console=ttyS0,115200

host端准备

前面我们就完成了guest端即调试目标机的配置,然后就是准备host端,可以用gdb,亦可以用vscode等gui工具,甚至可以用Windows Visual Studio配合VisualKernel工具来调试Linux系统。

源代码及调试符号vmlinux

将相应源代码及调试符号vmlinux复制到host端即可,复制时注意软链接问题,比如:

vmlinux-gdb.py -> /BUILD/linux-5.12/scripts/gdb/vmlinux-gdb.py

设置gdb的auto-load路径

建议直接修改 ~/.gdbinit文件,当然手动执行亦可,当处理多个调试机时最好通过.gdbinit来保存配置:

matt@T490 /W/K/debian-10.7> cat ~/.gdbinit 
add-auto-load-safe-path /usr/share/gdb/python/gdb/
add-auto-load-safe-path /usr/share/gdb/python/
add-auto-load-safe-path /usr/share/gdb/
add-auto-load-safe-path /BUILD/linux-5.12
set auto-load python-scripts on
source /BUILD/pwndbg/gdbinit.py

我本地的调试环境里安装的是pwndbg,已配置好了python组件

启动gdb

cd /BUILD/linux-5.12; gdb ./vmlinux

在gdb中执行以下执行开启内核调试:

    target remote :44333

然后gdb会自动加载pwndbg并中断目标机: Linux kernel 5.12 gdb

在内核gdb scripts加载成功的情况下可以执行lx系列扩展命令以获取内核信息: Linux kernel 5.12 gdb scripts

可通过apropos lx查询相应的gdb scripts扩展命令,如lx-lsmod, 变量:$lx_current():

gdb> apropos lx
function lx_clk_core_lookup -- Find struct clk_core by name
function lx_current -- Return current task.
function lx_device_find_by_bus_name -- Find struct device by bus and name (both strings)
function lx_device_find_by_class_name -- Find struct device by class and name (both strings)
function lx_module -- Find module by name and return the module variable.
function lx_per_cpu -- Return per-cpu variable.
function lx_rb_first -- Lookup and return a node from an RBTree
function lx_rb_last -- Lookup and return a node from an RBTree.
function lx_rb_next -- Lookup and return a node from an RBTree.
function lx_rb_prev -- Lookup and return a node from an RBTree.
function lx_task_by_pid -- Find Linux task by PID and return the task_struct variable.
function lx_thread_info -- Calculate Linux thread_info from task variable.
function lx_thread_info_by_pid -- Calculate Linux thread_info from task variable found by pid
lx-clk-summary -- Print clk tree summary
lx-cmdline --  Report the Linux Commandline used in the current kernel.
lx-configdump -- Output kernel config to the filename specified as the command
lx-cpus -- List CPU status arrays
lx-device-list-bus -- Print devices on a bus (or all buses if not specified)
lx-device-list-class -- Print devices in a class (or all classes if not specified)
lx-device-list-tree -- Print a device and its children recursively
lx-dmesg -- Print Linux kernel log buffer.
lx-fdtdump -- Output Flattened Device Tree header and dump FDT blob to the filename
lx-genpd-summary -- Print genpd summary
lx-iomem -- Identify the IO memory resource locations defined by the kernel
lx-ioports -- Identify the IO port resource locations defined by the kernel
lx-list-check -- Verify a list consistency
lx-lsmod -- List currently loaded modules.
lx-mounts -- Report the VFS mounts of the current process namespace.
lx-ps -- Dump Linux tasks.
lx-symbols -- (Re-)load symbols of Linux kernel and currently loaded modules.
lx-timerlist -- Print /proc/timer_list
lx-version --  Report the Linux Version of the current kernel.

Linux kernel 6.0 gdb Linux kernel 6.0 gdb Linux kernel 6.0 gdb

gdb常用命令及调试技巧

常用命令

常用gdb指令:bt, disass, step, next, break/delete, print, x/[i/g/d]等,具体可查询gdb命令手册

断点设置

使用break命令可设置断点,支持以下几种命令格式:

  • break 函数名: break dump_stack
  • break source_file:line_number: break smith_hook.c:70
  • break 逻辑地址:break 0xffffffff81003010,可以强制break跳过符号/函数名识别

针对模块的调试,可以考虑在模块中增加不常用内核函数的调用,如dump_stack;模块加载前是无法设置断点的,但内核函数的调用是可以的,这样就可以在模块调用指定内核函数时触发断点,然后再通过add-symbol-file /path_to/ko_file base_address,base_address或通过lx-lsmod查询得到,即模块在内核中的内存位置,之后就可以访问模块内的符号了,如全局变量或内部函数

X86_64位环境调试32位虚拟机

需要在attach前设置目标及当前系统架构,如 set architecture i386:x86-64。建议安装gdb-multiarch,以免系统自带gdb不支持多种架构:

pwndbg> target remote :44323
Remote debugging using :44323
warning: Selected architecture i386 is not compatible with reported target architecture i386:x86-64
warning: Architecture rejected target-supplied description
Remote 'g' packet reply is too long (expected 312 bytes, got 608 bytes): 102b91c10......0000

pwndbg> set architecture i386:x86-64
The target architecture is set to "i386:x86-64".
pwndbg> target remote :44323
Remote debugging using :44323
0x00000000c1912b23 in default_idle () at arch/x86/kernel

Linux系统安全-入侵检测与防护思路

1 系统安全简介及现状分析

主机安全涉及防御的整个纵深,内容繁多,如防火墙、WAF、RASP、IDS、IPS、安全审计、病毒杀毒、补丁管理、安运与安服等等。本文的目标主要是解决单点的系统威胁的发现与防御问题,属于系统安全的范畴,主要包含攻击发现、本地提权、rootkit防护三方面的内容。

本文目标在操作系统层面仅限于Linux系统,体系架构上以X86为主,兼顾ARM64。公司目前的主机系统主要是Intel XEON架构。既然以服务器系统为主,所以必须应对生产服务器对稳定性及性能的苛刻要求,并在此前提下达成安全上的需求。

2 核心需求

  1. 实现入侵行为的检测与防护,保障服务安全
  2. 稳定性与性能兼顾,保证服务可用性

总之,从检测能力及防护能力上着手,进一步接近并达成反入侵的需求,确实做好安全与保障。

3 攻击路径

大部分的入侵行为均可分成以下几个阶段:

  1. 扫描探测:通过扫描、社工或钓鱼等方式以了解主机信息,如网络结构、操作系统及服务类型等
  2. 漏洞触发:针对系统漏洞或配置错误发起攻击,前期攻击办能搭载较轻量的payload
  3. 主体下载:成功触发漏洞并达成了RCE (shellcode执行)或取得了shell权限,然后下载工作负载,如挖矿、勒索程序
  4. 主体执行:运行新下载的工作负载以启动真正的攻击,如挖矿、勒索、横向攻击、提权或持久化
  5. 本地提权:利用系统漏洞组合攻击,这一步有难度较高,且并非必需,主要由攻击意图决定
  6. 后门固化:即持久化,并隐藏自身或伪装、混淆

在主机这个单点上由于缺少关联数据,针对“扫描探测”只能做有限应对,如弱密码爆破场景,其它复杂场景需要汇集终端及其它主机的数据综合分析以作判定。第二步的漏洞触发也是很难检测到的,如未知0DAY漏洞本身就没有任何的先验知识,毕竟漏洞的存在是不可回避的事实。好在从第三步开始,主机端均有机会发现并做出合理判定,因为攻击意图必须以特定的攻击行为方能达成。

攻击行为相对于系统正常行为来说还是少之又少,并且多数攻击行为和正常操作并没有太大差异,这也是攻击检测的难点。攻击行为可分为两部分分别应对:可疑攻击和未知攻击,可疑攻击部分毕竟有先验知识,可以划定出较清楚的边界,此部分可以马上着手实现,这也是本文的重点。

4 可疑攻击

这部分主要依据经验总结,是针对当前HIDS的补充和增强,检测部分主要有4类检测项目,实现思路部分先做个简单阐述,等商定后再做详细详解。

4.1 攻击检测

4.1.1 CPU关键控制位

此部分主要针对CPU硬件的安全特性的检测,攻击者为了展开攻击或扩大成果不得不关闭这些安全特性:

  1. MSR寄件器EFER.NXE位:即DEP/NX位,数据区防执行,本安全特性默认开启,Linux系统允许通过grub的kernel参数开启或关闭。另外亦可通过修改MSI寄存Extended Feature Enable Register (EFER)的Bit 11调节。EFER寄存器是位于MSR的C0000080H处。
  2. CR4.SMEP位:Supervisor Mode Execution Prevention,此功能可阻止内核特权模式下运行用户层代码,可阻止ret2usr类的攻击。
  3. CR4.SMAP位:Supervisor Mode Access Prevention,配合EFLAGS的AC位可开启或关闭,可以阻止内核特权模式下直接访问用户层内存。在必须访问用户内存时,系统支持函数copy_to/from_user会临时设置EFLAGS的AC位。此特性从Linux 3.7开始支持。
  4. CR4.TSD位:Time Stamp Disable, 高精度计数器,可用于时序攻击,如Meltdown及Spectre/MDS等针对CPU漏洞的攻击所采用的就是rdtsc或rdtscp指令以精准确定CPU cache是否命中。
  5. CR4.PCE位: Performance-monitor Counter Enable,类似TSD,但精度上不如TSC。

4.1.2 内核检查项

这部分主要是针对内核对象及内核空间的检测,需要内核权限:

  1. 内核镜像: KIMAGE_VADDR, kpti/kaslr等属性
  2. 核心表项:idt/syscall table/shadow kernel
  3. 内核模块:映射区域:MODULES_VADDR - MODULES_END,3条链:module/sysfs/kobject
  4. 关键内核对象:file/dentry/inode_operations等,涉及文件系统(包含/proc、设备等重要数据结构,常被rootkit篡改以隐藏进程、网络连接、病毒文件等
  5. 内核通知链notifier_chain: 内核支持几十个,较重要的有module、keyboard等,后者可用于实现keylogger
  6. 网络驱动netfilter内部结构及操作表项
  7. binfmt: 二进制可执行行程序加载:elf程序运行、内核模块加载等

4.1.3 进程检查项

此部分检测针对用户进程,主要是进程相关的核心数据结构、以及对进程自身的R3用户空间的内存的检测:

  1. 可执行内存区域检测: a) W + X 内存映射区,针对jit程序存在误报可能 b) 不属于任何模块的映射区:如通过【REF1: ELF反射加载器】自展开加载的模块或程序
  2. VDSO及vsyscall映射区域防篡改校验:常用于ret2dir及DirtyCow攻击,可通过PFN与内容HASH进行校验
  3. 运行时安全属性检测: a) LD_PRELOAD: 动态库搜索路径,最好程序运行时进行检查 b) 第三方模块注入,如Apache插件,第三方注入在Linux系统上并不常见
  4. task_struct结构:如属主权限信息:uid/suid/euid/gid/egid/fsuid/fsgid, cap_effective/inheritable/permitted等,定时检测可以发现“任意内存写”攻击 a) 非法pid值检查:利用非法pid值可以达成进程隐藏 b) 线程Stack Pointer检查 (Stack Pivot攻击),难点是:go/rust/jit的

4.1.4 高危调用

这里我们主要关注进程、程序/动态库/模块加载、内存及文件相关的调用,与Linux LSM的监控点基本符合。以4.4.131的内核为例,系统共提供了多达198个监控点回调,较新的5.4.2内核已经支持多达216监控回调:

类别 钩子函数个数 功能
ptrace 2 ptrace操作的权限检查
能力机制 3 Capabilities相关操作的权限检查
磁盘配额 2 配盘配额管理操作的权限检查
超级块 13 mount/umount/文件系统/超级块相关操作的权限检查
dentry 2 dentry相关操作的权限检查
文件路径 11 文件名/路径相关操作的权限检查
inode 27 inode相关操作的权限检查
file 13 file相关操作的权限检查
程序加载 5 运行程序时的权限检查
进程 27 进程/进程相关操作的权限检查
IPC 21 IPC消息/共享内存/信号量等操作的权限检查
proc文件系统 2 proc文件系统相关操作的权限检查
系统设置 2 日志,时间等相关操作的权限检查
内存管理 1 内存管理相关操作的权限检查
安全属性 7 对安全相关数据结构的操作的权限检查
网络 37 网络相关操作的权限检查
XFRM 11 XFRM架构想要关操作的权限检查
密钥 4 密钥管理相关操作的权限检查
审计 4 内核审计相关操作的权限检查
Android Binder 4 Android Binder架构有关操作的权限检查
总计 198

重点关注项:

  1. prctl: 进程项调节
  2. ptrace: 调试
  3. mmap/mprotect (W+X):内存映射、可执行权限设置
  4. dlopen/dlmopen: 动态库加载
  5. LKM/module加载时针对modprobe_path的检查
  6. execve/execveat等:针对主、客体的关联判断,另外可增加主被动交互的侦测,如通过bash.readline可以判断是否是用户手动输入
  7. commit_creds/setuid/seteuid/setegid...
  8. chown/chmod +s/rename/unlink/link等:文件属主、属性相关操作

4.2 实现思路简述

需要两种检测机制:

4.2.1 定时检测:CPU及纯内核数据

此部分需要周期性的定时检测,实现方式有多种,如hrtimer/timer回调,延时工作队列(delayed workqueue)、硬件PMU或Intel PT等机制,目前来看延时工作队列的方式足以满足需求,如果后期对实时性要求更高可改用高精度时钟(hrtimer),这两种方式是都是Linux内核本身所支持的,有良好的普适性和稳定性。

在涉及内核对抗的情况下,可采用PMU或PT等硬件机制,硬件机制还能应对基于虚拟化的攻击,参考实现有【REF3: HARDWARE-ASSISTED ROOTKITS】及【REF4: GhostHook – Bypassing PatchGuard with Processor Trace Based Hooking】。

4.2.2 事件触发检测:进程相关数据

  1. 模块加载、进程创建等操作可通过通知链或kprobe监控点触发,如LD_PRELOAD及modprobe_path等项目
  2. 进程相关数据检测:要通过进程调度事件触发(trace_sched_switch),当进程时间片用完被调试出去时检测task_struct结构及相关内存映射属性等项目
  3. 高危调用

这部分数据的检测要注意事件回调的上下文环境,部分数据检测会涉及进程用户层内存的访问,属于softirq的hrtimer回调中是不能进行此操作的,需要转至workqueue或私有内核线程。

另外,纯用户层内存的检测亦可以通过R3 HOOK【REF2: TrustSec: LINUX: HOW’S MY MEMORY】或uprobe机制实现(自Linux 3.8开始支持),但必要性并不大,完全内核态的实现没有引入过多复杂性。

5 未知攻击

针对未知攻击一直没有较好的应对方式,一些比较苛刻的环境采用了可信计算的机制,即非白即黑的策略。可信计算主要解决了程序来源的问题,并不能有效应对程序的漏洞问题。业界公司应对内存安全的方案,所解决的也是类似的未知攻击及内存安全问题。

本章节所描述的应对思路便遵循了非白即黑的策略,当然此部分并不是完全的可信计算,而是一种轻量级的程序来源可信及可信执行的工程化实现。

5.1 程序可信

程序可信所解决的是来源问题,有两种可实现方式:

  1. 白名单机制:利用现有的IMA/Integrity进行来源控制
  2. 针对ELF文件增加新section,所有的程序均要做此处理,技术上需要修改elf加载器

此部分对用户行为有较大影响,程序发布及扩散环节都要做处理,特别是第二种方式。

5.2 执行可信

执行可信考虑的不是程序的来源,而是程序自身的代码逻辑,可分为两种粒度的控制:

  1. 指令控制流防护(CFI):需要编译器在编译阶段生成指令时加入分支指令操作的判断,这部分相对已经成熟,gcc及llvm均有支持,会增加程序的体量和性能损耗,但总体上可控。grSecurity的RAP方式就是类似的方式,可参见:【REF5: grSecurity RAP】
  2. 关键API调用序列防护:在API或系统调用层次上实现的执行防护,需要预先针对可执行程序进行静态或动态分析以生成规则,并在运行时进行插桩检测,同RASP异曲同工,只是所解决的问题不在一个层面上。相关的参考有【REF6: BlackBox: Lightweight Security C Monitoring for COTS Binaries】及【REF7: Virsec Trusted Execution】

5.3 脚本防护

Linux下可执行脚本种类繁多,且功能较大,没有统一的方式来应对,可常用的应对方案有以下几中:

  1. 用行为沙箱或类RASP的方式来做启发式分析
  2. 通过文件集进行执行管控: 如/tmp目录、web服务upload目录(新上传)脚本防执行,当然也有些例外情况,如安装包会自动生成脚本并执行
  3. 全量收集以进行后续人工分析及机器学习分类

6 其它功能

6.1 自保功能:防杀防卸载 6.2 ARM64等新体系结构的支持 6.3 代码优化及性能提升

7 样本数据库建设

安全不只是技术,还是人的行为管理和数据的运营,所以有必要从以下两个方面来强化数据的收集与关联:

7.1 行为数据及画像库

常登录的服务器、登录时间、经常的操作、来源ip等习惯行为数据

7.2 程序样本数据库

所有的程序(可执行程序、动态库、脚本)及安装包、来源信息的整理,现在360、腾讯等公司均已建立了较为完备的样本库,同样亦适用于URL/IP、威胁及漏洞等数据

8 参考资料

  1. REF1: ELF反射加载器
  2. REF2: TrustSec: LINUX: HOW’S MY MEMORY
  3. REF3: Hardware-Assisted Rootkits: Abusing Performance Counters on the ARM and x86 Architectures
  4. REF4: GhostHook – Bypassing PatchGuard with Processor Trace Based Hooking
  5. REF5: grSecurity RAP
  6. REF6: BlackBox: Lightweight Security C Monitoring for COTS Binaries
  7. REF7: Virsec Trusted Execution
  8. REF8: Integrity Measurement Architecture (IMA)