【免费下载链接】Cybersecurity-ProjectsBuilding 70 Projects ranging from beginner to advanced so anyone can — learn from, build upon, use as a reference, or even copy directly. Gamified Cybersecurity learning 项目地址https://gitcode.com/gh_mirrors/cy/Cybersecurity-Projects点击查看免费下载本指南是 Linux eBPF Security Tracer 学习系列的概念基石系统讲解 eBPF 如何在内核中实现沙箱化的安全可观测性、系统调用为何是不可绕过的检测面以及检测工程中无状态规则 有状态关联的设计思想。读完本文你将掌握 eBPF 编译加载链路、本项目 14 类被追踪系统调用与 10 条 MITRE ATTCK 映射规则的理论依据并能独立理解常见检测陷阱与真实攻击案例的 syscall 视角。eBPF可编程内核可观测性它是什么eBPFextended Berkeley Packet Filter是一种允许你在 Linux 内核中运行小程序的技术无需编写内核模块、也无需修改内核源码。你可以把它理解成一种安全、受沙箱约束的内核脚本语言。当你加载一个 eBPF 程序时内核的**验证器verifier**会对其做安全性检查——不允许无限循环、不允许越界内存访问、不允许崩溃内核——随后通过JIT 编译器将其编译为原生机器码。这意味着 eBPF 程序能以接近原生的速度运行同时具备很强的安全保证。为什么它对安全很重要在 eBPF 出现之前获得内核级可见性只有两个选项内核模块kernel modules权限完全但一个 bug 就会让系统崩溃。在内核中加载不可信代码本质上充满风险。系统调用追踪strace/ptrace安全但缓慢基于 ptrace 的追踪会给被追踪进程带来 10–100 倍的性能开销。eBPF 让你以用户空间的安全性获得内核级可见性典型性能开销低于 1%且验证器能保证你的程序不会弄崩内核。这正是 2020 年以来几乎所有主流云安全工具Falco、Tetragon、Tracee、Datadog 的运行时安全模块都以 eBPF 为底层根基的原因。它是如何工作的本项目的编译加载链路印证了经典 eBPF 数据流你的 Python 脚本 │ ▼ BCC 编译器 (Clang/LLVM) │ ▼ eBPF 字节码 │ ▼ 内核验证器 ──▶ 拒绝不安全的程序 │ ▼ JIT 编译器 │ ▼ 原生机器码 (挂载到 tracepoint) │ ▼ 每次匹配的系统调用触发 │ ▼ Ring Buffer ──▶ 你的 Python 回调在源码层面这条链路由 loader.py 完整实现TracerLoader.load()读取 src/ebpf/ 目录下的 C 程序文本调用 BCC 的BPF(textc_text)在运行时完成 Clang 编译、验证器检查与 JIT 加载随后用bpf[events].open_ring_buffer(self._callback)建立内核到用户空间的通信通道并在poll()循环中通过bpf.ring_buffer_poll(timeout100)持续拉取事件。BCC vs libbpf两种主流的 eBPF 开发框架编写 eBPF 程序主要有两种框架BCCBPF Compiler Collection在运行时用 Clang/LLVM 编译你的 eBPF C 代码。优点是开发迭代快把 C 代码写成 Python 字符串或项目中的独立.c文件加载即可运行。缺点是每台宿主机都需要安装 LLVM 与内核头文件且每个程序大约占用 80MB 内存。libbpf CO-RECompile Once, Run Everywhere在构建期只编译一次 eBPF 程序借助 BTFBPF Type Format元数据让同一份二进制跨内核版本运行。Tetragon 等生产级工具采用这种方案因为它更轻量约 9MB且生产主机上无需编译工具链。本项目选择 BCC因为它的定位是学习工具而非生产代理Python API 让代码易读运行时编译免去构建步骤便于反复试验。仓库中的 5 个 C 源文件process_tracer.c、file_tracer.c、network_tracer.c、privilege_tracer.c、system_tracer.c正是由TRACER_FILES字典按类别映射、由 loader 逐个读取编译的。系统调用内核的前门什么是系统调用用户空间程序与内核的每一次交互都要经过系统调用。当cat读取文件时它调用openat()获取文件描述符、read()读取内容、write()输出到 stdout当curl连接服务器时它调用socket()、connect()和read()。这个过程无法绕开。即使恶意软件完全驻留内存、即使它用汇编编写它要做任何有用的事仍必须发起系统调用。这让系统调用追踪成为一种极难规避的强大检测机制——本项目的 00-OVERVIEW.md 将其概括为在事件发生时、于内核层面观察系统调用。安全相关的系统调用Linux 拥有 300 多个系统调用并非全部对安全有意义。本项目实际追踪的 14 种事件、5 个类别与概念文档描述的安全维度一一对应安全维度追踪的系统调用eBPF 源文件tracepoint事件常量进程执行execve、cloneprocess_tracer.csys_enter_execve/sys_enter_clone1、2文件访问openat、unlinkat、renameat2file_tracer.csys_enter_openat/sys_enter_unlinkat/sys_enter_renameat23、4、5网络活动connect、accept4、bind、listennetwork_tracer.csys_enter_connect/sys_enter_accept4/sys_enter_bind/sys_enter_listen6、7、8、9权限变化setuid、setgidprivilege_tracer.csys_enter_setuid/sys_enter_setgid10、11系统操作ptrace、mount、init_modulesystem_tracer.csys_enter_ptrace/sys_enter_mount/sys_enter_init_module12、13、14这些事件常量的数值定义与类别归属在 config.py 的EventType枚举和EVENT_TYPE_CATEGORIES映射中集中维护保证了 C 侧与 Python 侧的事件协议一致。逐一说明它们为何重要进程执行——execve每次运行新程序都会触发。这是安全监控最重要的系统调用几乎每一起攻击都涉及执行某个东西——shell、payload或某个被滥用的合法工具。文件访问——openat揭示进程正在读写哪些文件。攻击者读取/etc/shadow或向/etc/cron.d/写入传递的是清晰的恶意信号。网络活动——connect暴露外连目标。一个 Web 服务器突然连接东欧某 IP 的 4444 端口就是危险信号bind与listen则显示进程为入站连接bind shell开放端口。权限变化——setuid、setgid显示权限跃迁。进程调用setuid(0)企图变成 root正是提权攻击的典型画面。系统操作——ptrace、mount、init_moduleptrace用于调试但也被用于进程注入MITRE ATTCK T1055.008mount可能暗示容器逃逸企图init_module加载内核模块是 rootkit 安装自身的方式。以execve的追踪实现为例process_tracer.c 中TRACEPOINT_PROBE(syscalls, sys_enter_execve)先events.ringbuf_reserve保留事件槽位经fill_base()填充时间戳、PID/TGID、UID/GID、PPID 与进程名等公共字段再用bpf_probe_read_user_str()安全读取用户空间的args-filename最后ringbuf_submit提交。这段代码同时是概念文档所述tracepoint 接口 ring buffer 通信的直接证据。系统调用追踪面用户空间进程 │ │ execve(/bin/bash, ...) │ openat(/etc/shadow, O_RDONLY) │ connect(sockfd, {ip10.0.0.1, port4444}) │ setuid(0) │ ▼ ┌─────────────────────────┐ │ 系统调用入口 │◀── eBPF tracepoint 挂载于此 │ (内核边界) │ └─────────────────────────┘ │ ▼ 内核实现检测工程从系统调用到安全告警单个系统调用孤立来看很少可疑openat在繁忙系统上每秒触发成千上万次。检测工程的艺术在于识别哪些模式——是参数异常的单个事件还是事件序列——意味着恶意活动。这正是本项目 detector.py 中DetectionEngine的职责每一类规则要么独立评估单个事件要么关联同一进程在时间窗口内的事件序列。无状态检测某些事件单独出现就足以可疑以 UID 1000 运行的进程调用setuid(0)几乎必然是提权尝试Python 脚本读取/etc/shadow值得调查init_module()加载内核模块总是值得注意ptrace(PTRACE_ATTACH, target_pid)是一种代码注入原语这些是无状态检测因为每个事件被独立评估。具体到本项目无状态规则在DetectionEngine._check_stateless()中逐条实现并由 config.py 的DETECTION_RULES提供规则元数据严重级与 MITRE 编号。10 条规则完整清单如下ID规则名称严重度MITRE ATTCK触发条件D001权限提升Privilege EscalationCRITICALT1548非 root 进程调用setuid(0)D002敏感文件读取Sensitive File ReadMEDIUMT1003.008非 root 进程读取/etc/shadow等凭据文件且非写操作D003SSH 密钥访问SSH Key AccessMEDIUMT1552.004非白名单进程访问 SSH 密钥材料D004进程注入Process InjectionMEDIUMT1055.008ptraceATTACH/SEIZE/SETREGSD005内核模块加载Kernel Module LoadHIGHT1547.006调用init_moduleD006反向 ShellReverse ShellCRITICALT1059.004connect与 shellexecve事件序列D007Cron 持久化Persistence via CronMEDIUMT1053.003向 cron 目录写入D008Systemd 持久化Persistence via SystemdMEDIUMT1543.002向 systemd unit 目录写入D009日志篡改Log TamperingMEDIUMT1070.002日志文件删除或截断D010可疑挂载Suspicious MountHIGHT1611调用mount规则背后有精细的上下文判断逻辑仅举几例D002敏感文件读取SENSITIVE_READ_PATHS包含/etc/shadow、/etc/gshadow、/etc/sudoers等同时要求event.uid ! 0且不是写标志_is_write_flags从而避免把 PAM 的正常登录校验误报为攻击。D003SSH 密钥访问CREDENTIAL_PATHS覆盖/.ssh/id_rsa、/.ssh/authorized_keys、/.aws/credentials等但CREDENTIAL_ACCESS_ALLOWLISTsshd、ssh、ssh-agent、gpg-agent等内的合法进程被豁免。D004进程注入只对PTRACE_ATTACH16、PTRACE_SEIZE16902、PTRACE_SETREGS13三个请求类型告警因为普通调试并不总是使用这些原语。D009日志篡改openat带O_TRUNC512标志打开/var/log/下文件或unlinkat删除日志路径均触发。有状态检测事件关联另一些威胁只有在关联多个事件时才变得可见。经典的反向 shell 模式攻陷服务器的攻击者需要把交互式 shell 连回自己的机器惯用手法是1. socket(AF_INET, SOCK_STREAM) # 创建 TCP socket 2. connect(sockfd, attacker_ip) # 连接到攻击者 3. dup2(sockfd, 0) # 重定向 stdin 到 socket 4. dup2(sockfd, 1) # 重定向 stdout 到 socket 5. dup2(sockfd, 2) # 重定向 stderr 到 socket 6. execve(/bin/bash) # 生成 shell这中间没有任何单个系统调用是可疑的程序创建 socket、连接服务器、启动 shell 都是常态。但同一 PID 在数秒内先connect后执行 shellexecve就是强烈的反向 shell 信号。本项目将这条规则实现为有状态检测DetectionEngine按 PID 维护最近事件的滑动窗口_get_history()为每个 PID 创建deque(maxlenMAX_EVENTS_PER_PID)上限 64 条事件_prune_history()与_sweep_stale()负责丢弃超过关联窗口CORRELATION_WINDOW_SEC 10秒的过期事件。核心逻辑在_check_stateful()中双向匹配当 shell 二进制SHELL_BINARIES中的sh、bash、zsh等执行execve时检查同一 PID 的历史里是否有connect若没有再检查父 PIDevent.ppid的历史——覆盖先连接后派生 shell的常见形态当connect发生时反向检查该 PID 历史里是否已有 shellexecve。任一方向命中即触发 D006CRITICAL。整个评估流程由evaluate()统一驱动记录单调时间戳 → 先试无状态规则 → 再试有状态规则 → 将事件写入历史并剪枝 → 每SWEEP_INTERVAL1000 次事件做一次全局过期清扫。真实世界示例2021 Log4ShellCVE-2021-44228初始漏洞利用触发一次 JNDI 查询下载并执行 payload。从 syscall 视角看Java 进程出人意料地调用connect()连向外部 LDAP 服务器下载 class 文件随后execve()生成 shell。基于 eBPF 的工具在 WAF 还在更新签名时就已实时发现它。2020 SolarWinds 供应链攻击被攻陷的 Orion 软件对外部avsvmcloud.com发起异常外连。syscall 追踪会显示 Orion 进程调用connect()到不在其正常通信模式内的 DNS/HTTP 端点。Kubernetes 容器逃逸CVE-2022-0185该漏洞利用内核文件系统上下文处理中的堆溢出攻击序列涉及在容器内以构造的参数调用mount()系统调用——这正是 Tetragon 等 eBPF 工具专门设计要捕获的行为也正是本项目的 D010 规则追踪sys_enter_mount的原因。MITRE ATTCK 映射MITRE ATTCK 框架为描述攻击者行为提供了通用语言。本项目把每条检测规则映射到具体的 ATTCK 技术与战术完整 10 条规则即上节表格。这里摘录概念文档中规则与技术、战术的对应关系检测技术战术权限提升T1548 - Abuse Elevation Control权限提升敏感文件读取T1003.008 - /etc/passwd 与 /etc/shadow凭据访问SSH 密钥访问T1552.004 - 私钥凭据访问进程注入T1055.008 - Ptrace 系统调用防御规避内核模块加载T1547.006 - 内核模块持久化反向 ShellT1059.004 - Unix Shell执行Cron 持久化T1053.003 - Cron持久化日志篡改T1070.002 - 清除 Linux 日志防御规避这套映射在 config.py 的DetectionRule中作为结构化元数据落地每条规则携带rule_id、name、severity、mitre_id与description当_apply_detection()命中规则时这些字段被盖上对应的事件从而让告警输出天然带上 ATTCK 上下文。常见陷阱陷阱一假设系统调用名称是稳定的系统调用命名随架构与内核版本变化。在 x86_64 上open()已被openat()取代为主流的文件打开系统调用。因此应始终使用 tracepoint 接口如syscalls:sys_enter_openat而不是对原始 syscall 函数使用 kprobe——因为 tracepoint 是稳定 ABIkprobe 则挂载在内核内部实现函数上随版本波动。本项目全部采用TRACEPOINT_PROBE宏可见于 src/ebpf/ 下每个 C 文件正是对这一原则的贯彻。陷阱二忽略事件量级在繁忙服务器上execve和openat每秒触发数百次。若检测引擎对每个事件做昂贵处理必然落后。为此本项目使用ring buffer 而非 perf bufferC 侧BPF_RINGBUF_OUTPUT(events, 1 18)即 256KBPython 侧bpf[events].open_ring_buffer(...)并刻意保持检测逻辑简单每个事件只做有限次字符串前缀/包含匹配状态关联仅维护每 PID 的小型 deque。这样内核侧零拷贝投递、用户侧批量轮询才能跟上真实系统的事件速率。陷阱三过度告警如果每次openat(/etc/passwd)都触发告警运维人员一天内就会禁用这个工具。好的检测工程意味着理解什么是正常root 读取/etc/shadow是符合预期的PAM 每次登录都会这么做而一个 Python 脚本读取它才异常——上下文决定一切。这正是 D002 规则限定非 root 进程、D003 规则维护合法进程白名单的原因也是严重度分级LOW/MEDIUM/HIGH/CRITICAL与-s最小严重度过滤存在的意义。概念如何连接将本项目的全部组件串成一条完整的流水线即是概念文档的收束图eBPF 程序 ─────────────────────┐ (内核中的 C 代码) │ │ │ │ 捕获 syscall 参数 │ 编译 加载 │ │ ▼ │ Ring Buffer ◀───────────────────┘ │ via BCC Python │ 事件流向用户空间 ▼ 检测引擎 │ │ 对照规则评估 │ 关联事件序列 ▼ MITRE ATTCK 映射 │ │ 分类严重度 ▼ 告警输出这条链路与源码一一对应BCC 运行时编译 src/ebpf/ 的 C 程序loader.py→ ring buffer 投递 →parse_raw_event()用 ctypes 按 C 结构体布局解析processor.py可选从/proc/{ppid}/comm富化父进程名 →DetectionEngine.evaluate()运行规则detector.py→should_include()按严重度、PID、进程名、类别、仅告警等条件过滤 → 由 renderer 输出 live/JSON/table 格式。行业标准本项目的设计与多个行业框架对齐MITRE ATTCK for Linux描述 Linux 系统上攻击者行为的框架本项目每条规则均映射到其中的技术与战术NIST SP 800-137信息安全持续监控ISCM指南eBPF 类工具直接支持其持续监控目标CIS Controls v8 第 8 项审计日志管理eBPF 追踪提供的正是原始审计数据。测试你的理解为什么恶意软件无法通过从用户空间直接访问内核内存来规避基于 syscall 的检测参考思路用户空间进程无法直接读写内核内存——x86 架构通过特权级隔离禁止普通进程执行特权指令或访问内核地址空间所有能产生实际效果的操作打开文件、建立连接、派生进程最终都必须跨过内核边界、经由系统调用完成。即使恶意软件完全驻留内存它仍要发 syscall 才能做任何事。看到 PID 4521 的序列socket(AF_INET, SOCK_STREAM)、connect(10.0.0.5:443)、execve(/usr/bin/curl)。这是反向 shell 吗为什么参考思路对本工具而言不是。D006 规则要求execve的执行体是 shell 二进制SHELL_BINARIES中的sh/bash/zsh等而curl是网络客户端、不在 shell 名单内。更一般地说curl 连 443 端口属于其正常用途缺少把标准 I/O 重定向到 socket 再起交互 shell的提权语义但若在真实环境中一个普通进程异常地调用这些 syscall仍值得结合上下文排查。一条规则对每次openat(/etc/passwd)触发告警。在每小时 100 个用户登录的服务器上每小时预计多少误报如何减少参考思路登录流程PAM会为每个登录用户读取/etc/passwd若规则不区分调用者身份每小时至少约 100 次误报实际可能更多因getpwuid等辅助查询也会触发。减少误报的办法正是本项目 D002 的做法限定调用者 UID非 root、排除合法服务白名单、并结合调用上下文如是否同时出现写入标志或可疑文件名后缀提高置信度。kprobe 与 tracepoint 挂载 eBPF 程序的差别是什么生产环境哪个更可靠参考思路kprobe 挂载在内核内部函数如do_sys_openat2上能观测到更细粒度的内部细节但内部函数名与签名随内核版本频繁变动一旦目标函数被重构程序即失效tracepoint 挂载在内核为外部消费者显式暴露的稳定事件点如syscalls:sys_enter_openat上是稳定 ABI。生产环境通常优先选用 tracepoint这也是本项目全部使用TRACEPOINT_PROBE的原因只有需要观测 tracepoint 未覆盖的深层路径时才退而求其次用 kprobe并配合内核版本管理。延伸阅读必读官方 eBPF 学习资源ebpf.ioBCC 参考指南覆盖全部 BCC APIMITRE ATTCK 的 Linux 完整技术矩阵。进阶Liz Rice 的《Learning eBPF》全面讲解 eBPF 编程Brendan Gregg 的《BPF Performance Tools》是 eBPF 系统分析的经典参考Falco 规则仓库展示了生产工具如何定义检测规则。仓库内继续深入安装与快速上手见 00-OVERVIEW.md含./install.sh、sudo uv run ebpf-tracer等完整命令与预期输出系统设计与数据流见 02-ARCHITECTURE.md逐模块代码走读见 03-IMPLEMENTATION.md扩展练习见 04-CHALLENGES.md。项目总览与完整检测规则表见 README.md。赞分享【免费下载链接】Cybersecurity-ProjectsBuilding 70 Projects ranging from beginner to advanced so anyone can — learn from, build upon, use as a reference, or even copy directly. Gamified Cybersecurity learning 项目地址https://gitcode.com/gh_mirrors/cy/Cybersecurity-Projects点击查看免费下载相关推荐Linux eBPF Security Tracer 实战指南基于 BCC 的实时系统调用安全监控与 MITRE ATTCK 检测引擎Linux eBPF Security Tracer 实战指南基于 BCC 的实时系统调用安全监控与 MITRE ATTCK 检测引擎 本指南围绕 CybeLinux eBPF Security Tracer 架构深度解析从内核 tracepoint 到用户空间检测引擎的完整设计Linux eBPF Security Tracer 架构深度解析从内核 tracepoint 到用户空间检测引擎的完整设计 本指南以 linux ebpfKernelSU 元模块 meta-overlayfs 指南四步装好模块改 system 才真正生效KernelSU 元模块 meta overlayfs 指南四步装好模块改 system 才真正生效 装了 KernelSU又刷了一批动 /system操作系统驱动开发上一篇Adobe-GenP终极指南5分钟快速激活Adobe全系列软件下一篇Adobe-GenP 3.05步解锁Adobe全系列软件的专业指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考