【免费下载链接】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 项目的架构文档为主线系统拆解这套实时 syscall 安全追踪工具的端到端设计内核空间五个 eBPF C 程序如何通过 ring buffer 与用户空间 Python 组件协作检测引擎如何完成从单事件可疑判定到跨事件时序关联的两级检测以及其数据模型、安全模型、性能权衡与扩展方式。读完本文你将掌握 BCC 版 eBPF 安全监控工具的分层架构方法论并能对照源码理解每一层组件如何被调用、如何被测试验证。总体架构用户空间与内核空间的职责划分项目的架构围绕一条清晰的分界线展开内核空间只负责看得见采集用户空间负责看得懂解析、富化、检测、展示。完整的组件与数据通路如下┌────────────────────────────────────────────────────────┐ │ User Space │ │ │ │ ┌─────────┐ │ │ │ main.py │ CLI entrypoint │ │ │ (Typer) │ parses args, wires components │ │ └────┬─────┘ │ │ │ │ │ ▼ │ │ ┌──────────┐ ┌─────────────┐ ┌────────────────┐ │ │ │loader.py │──▶│processor.py │──▶│ renderer.py │ │ │ │ │ │ │ │ │ │ │ │ Compiles │ │ Parses raw │ │ JSON / Live / │ │ │ │ loads │ │ events, │ │ Table output │ │ │ │ eBPF C │ │ enriches │ │ │ │ │ │ programs │ │ from /proc │ └────────────────┘ │ │ │ │ │ │ │ │ │ │ Sets up │ │ Filters by │ ┌────────────────┐ │ │ │ ring buf │ │ severity, │──▶│ detector.py │ │ │ │ callback │ │ PID, comm │ │ │ │ │ └──────────┘ │ │ │ Stateless │ │ │ └─────────────┘ │ rules │ │ │ │ stateful │ │ │ │ correlation │ │ │ └────────────────┘ │ ├────────────────────────────────────────────────────────┤ │ Kernel Space │ │ │ │ ┌──────────────────────────────────────────────┐ │ │ │ Ring Buffer (shared) │ │ │ │ BPF_RINGBUF_OUTPUT, 256KB │ │ │ └──────────┬──────────┬──────────┬─────────────┘ │ │ │ │ │ │ │ ┌──────────┴───┐ ┌────┴────┐ ┌──┴──────────┐ │ │ │process_tracer│ │file_ │ │network_ │ │ │ │ .c │ │tracer.c │ │tracer.c │ │ │ │ │ │ │ │ │ │ │ │ sys_enter_ │ │sys_enter│ │sys_enter_ │ │ │ │ execve │ │_openat │ │connect │ │ │ │ sys_enter_ │ │sys_enter│ │sys_enter_ │ │ │ │ clone │ │_unlinkat│ │accept4 │ │ │ │ │ │sys_enter│ │sys_enter_ │ │ │ │ │ │_rename │ │bind/listen │ │ │ └─────────────┘ └─────────┘ └─────────────┘ │ │ ┌─────────────┐ ┌─────────────┐ │ │ │privilege_ │ │system_ │ │ │ │tracer.c │ │tracer.c │ │ │ │ │ │ │ │ │ │sys_enter_ │ │sys_enter_ │ │ │ │setuid │ │ptrace │ │ │ │sys_enter_ │ │sys_enter_ │ │ │ │setgid │ │mount │ │ │ │ │ │sys_enter_ │ │ │ │ │ │init_module │ │ │ └─────────────┘ └─────────────┘ │ └────────────────────────────────────────────────────────┘从源码结构看用户空间由六个 Python 模块组成main.py、loader.py、processor.py、detector.py、renderer.py、config.py内核空间由 ebpf/ 目录下的五个 C 文件组成process_tracer.c、file_tracer.c、network_tracer.c、privilege_tracer.c、system_tracer.c每个文件对应一类 syscall。组件分解七层各司其职main.py — CLI 与装配层最薄的层main.py 通过 Typer 解析命令行参数并把 loader、processor、detector、renderer 装配在一起同时处理基于信号的优雅退出。它在整个系统中刻意保持最薄只做管道plumbing不含任何业务逻辑。从源码看核心入口trace()命令依次完成四件事启动前置校验调用check_privileges()要求 rootos.geteuid() ! 0时输出Error: eBPF tracing requires root privileges. Run with: sudo uv run ebpf-tracer并退出、check_kernel_version()要求内核 5.8否则报错退出装配组件实例化DetectionEngine与create_renderer(format)若指定了-o/--output则追加创建FileRenderer定义 ring buffer 回调on_event()这是用户空间处理每个事件的唯一入口串联了parse_raw_event → enrich_event → detector.evaluate → should_include → renderer.render整条流水线进入主循环loader.load()加载 eBPF 程序loader.poll()进入轮询循环并由try/finally保证即便出现异常TableRenderer.finalize()、FileRenderer.close()与清理也会执行。CLI 的全部参数定义在这一层包括-f/--formatlive/json/table、-s/--severityLOW/MEDIUM/HIGH/CRITICAL、-p/--pid、-c/--comm、-t/--typeprocess/file/network/privilege/system/all、--no-enrich、-o/--output、--detections。loader.py — eBPF 程序生命周期管理loader.py 负责 eBPF 程序的全生命周期从TRACER_FILES映射表读取ebpf/目录下的.c文件process: process_tracer.c等通过 BCC 的BPF(textc_text)即时编译bpf[events].open_ring_buffer(self._callback)将用户空间回调挂到 ring buffer 上_resolve_tracers()根据--type决定加载单个还是全部 tracerpoll()安装 SIGINT/SIGTERM 处理器在while self._running循环中对每个 BPF 对象执行ring_buffer_poll(timeout100)cleanup()遍历所有bpf.cleanup()分离 tracepoint、释放内核资源。启动时它会先做两项校验check_privileges()检查 euid 是否为 0check_kernel_version()通过os.uname().release解析内核版本并与MIN_KERNEL_MAJOR/MINOR5.8比对因为 ring buffer API 依赖内核 5.8。processor.py — 事件解析与富化processor.py 定义了两类数据模型并完成从裸字节到富化事件的转换RawEvent一个ctypes.Structure字段布局与 C 结构体一一对应TracerEventPython dataclass承载解析后的结构化事件。parse_raw_event()用ctypes.cast(data, ctypes.POINTER(RawEvent)).contents把 ring buffer 的裸指针直接解释为结构体再逐字段转换comm/filename按 NUL 截断解码raw.split(b\x00, 1)[0].decode(...)addr_v4由网络序 32 位整数还原为点分十进制内核单调时钟通过_boot_time_ns()从/proc/stat的btime行读取换算为墙上时钟。enrich_event()再从/proc/ppid/comm读取父进程名写入event.extra[parent_comm]。过滤逻辑should_include()在流水线末端执行依次检查--detections只保留有检测标记的事件、最低严重级别通过SEVERITY_ORDER数值比较、PID 精确匹配、comm 精确匹配、事件类别EVENT_TYPE_CATEGORIES与-t指定的 tracer 类型。detector.py — 两级检测引擎detector.py 承载全部安全检测逻辑采用无状态规则 有状态关联的两级结构无状态规则_check_stateless()针对单事件判断。例如setuid且target_uid 0且当前uid ! 0命中 D001 提权openat读取/etc/shadow且非 root 命中 D002ptrace_request属于 PTRACE_ATTACH(16)/PTRACE_SEIZE(16902)/PTRACE_SETREGS(13) 命中 D004init_module命中 D005mount命中 D010 等有状态规则_check_stateful()跨事件时序关联核心是 D006 反向 shell 检测——若同一 PID 历史中出现connect事件后又出现execve且进程名为 shellsh/bash/dash/zsh 等或在connect时发现该 PID 已有 shell 执行记录则命中Reverse Shell检测时还会回看父进程ppid_hist的历史覆盖攻击者先建立连接、再 fork 出 shell的场景。evaluate()是统一入口先写_mono_time单调时钟标记执行无状态检查未命中再执行有状态检查随后把事件追加进 per-PID 的deque并做窗口裁剪。命中规则时通过_apply_detection()把severity、detection、detection_id、mitre_id盖到事件上。这一层的正确性由 tests/test_detector.py 的 474 行测试保障——例如 D001 的用例验证了非 root 进程setuid(0)命中 CRITICALroot 自身setuid(0)忽略setuid到非 0 UID 忽略三种边界。renderer.py — 四种输出模式renderer.py 通过create_renderer()工厂按-f参数返回对应实现渲染器行为适用场景LiveRenderer用 Rich 输出彩色流式日志severity 按SEVERITY_COLORS配色LOWcyan、MEDIUMyellow、HIGHred、CRITICALbold red命中的检测以 bold magenta 追加在行尾默认的交互式实时监控JsonRenderer每事件向 stdout 写一行 JSONjson.dumps(d) \n并 flush管道给 jq 或日志采集系统TableRenderer缓冲事件攒满 20 条后用 Rich 表格批量渲染finalize()在退出时冲刷剩余缓冲周期性摘要观察FileRenderer以追加模式把 JSON 逐行写入文件独立于主输出模式并行工作边看边落盘留档_event_to_dict()负责统一的 JSON 序列化基础字段恒定输出timestamp/event_type/category/pid/ppid/uid/username/comm/severity其余字段按事件类型条件输出——网络事件补dest_ip/dest_portsetuid/setgid 补目标 UID/GIDptrace 补ptrace_request/target_pid命中检测补detection/detection_id/mitre_id富化结果补parent_comm。config.py — 全部魔法数字的唯一归宿config.py 是全项目的单一事实来源所有魔法数字、文件路径、检测规则元数据、严重级别、事件类型映射全部集中于此代码其余部分不做任何硬编码。改一条检测规则的 severity 或新增敏感文件路径只需编辑这一个文件。其中值得关注的设计有EventType是IntEnum14 种事件类型EXECVE1 … INIT_MODULE14的数值必须与各.c文件中#define EVENT_*保持严格一致EVENT_TYPE_CATEGORIES把事件映射到五个分类供-t过滤使用路径常量按攻击意图分组SENSITIVE_READ_PATHS/etc/shadow 等、CREDENTIAL_PATHS.ssh/id_rsa、.aws/credentials 等、CREDENTIAL_ACCESS_ALLOWLISTsshd、ssh-agent、gpg 等合法访问者、PERSISTENCE_CRON_PATHS、PERSISTENCE_SYSTEMD_PATHS、LOG_PATHSDETECTION_RULES以 dict 形式登记 D001–D010 共 10 条规则每条含 rule_id/name/severity/mitre_id/description。ebpf/*.c — 内核空间五份精简程序ebpf/下五个 C 文件按 syscall 分类各司其职每个文件定义若干TRACEPOINT_PROBE钩住对应的syscalls:sys_enter_*事件。以 process_tracer.c 为例BPF_RINGBUF_OUTPUT(events, 1 18)声明 ring buffer118 256KB 容量与RING_BUFFER_BYTES对应fill_base()辅助函数用bpf_get_current_pid_tgid()、bpf_get_current_uid_gid()、bpf_get_current_comm()填充公共字段用bpf_probe_read_kernel()从task-real_parent-tgid读 ppid并把所有不相关字段清零sys_enter_execve探针额外用bpf_probe_read_user_str()从用户态安全读取args-filename首个参数network_tracer.c 额外实现parse_sockaddr()用bpf_probe_read_user()把用户态sockaddr拷入内核栈仅当sin_family AF_INET时提取addr_v4网络序与port经__builtin_bswap16转为主机序。C 代码刻意保持最小采集到的共享结构体推入 ring buffer所有检测逻辑留在 Python。数据流从 syscall 到告警的八步旅程以攻击者通过已建立的连接启动 bash触发反向 shell 告警为例架构文档给出的完整链路如下1. Process calls execve(/bin/bash) │ 2. Kernel hits tracepoint syscalls:sys_enter_execve │ 3. eBPF program (process_tracer.c) fires: - Reserves space in ring buffer - Fills struct: pid, ppid, uid, comm, filename, timestamp - Submits to ring buffer │ 4. Python callback (on_event in main.py) fires: - parse_raw_event() casts raw bytes to RawEvent ctypes struct - Converts to TracerEvent dataclass - Decodes comm/filename from null-terminated bytes - Converts kernel timestamp to wall clock datetime - Resolves UID to username via pwd module │ 5. enrich_event() adds parent process name from /proc │ 6. detector.evaluate() checks: - Stateless: Is the event itself suspicious? No. - Stateful: Is this a shell? Yes (bash). Was there a recent connect from this PID? Check history deque. If yes - Detection(Reverse Shell, CRITICAL) │ 7. should_include() applies users filters: - Severity minimum? PID matches? Comm matches? │ 8. renderer.render() outputs: [14:30:01] CRITICAL execve pid1234 commbash /bin/bash [Reverse Shell]对照源码可以逐环节印证第 3 步对应 process_tracer.c 的ringbuf_reserve → fill_base → ringbuf_submit三段式第 4 步对应 processor.py 的parse_raw_event()及 UID 缓存解析第 6 步对应 detector.py 中_check_stateful()的 execve 分支——它会先确认event.comm in SHELL_BINARIES再扫描当前 PID 与父 PID 两个 deque 中是否存在connect事件。设计模式三组关键决策模式一内核极简用户空间复杂eBPF C 程序只做最小必要工作读 syscall 参数、填充结构体、推入 ring buffer。所有有意思的逻辑检测、关联、富化、格式化都在 Python 侧完成。原因在于 eBPF 程序运行在内核中的严格约束之下512 字节栈上限禁止动态内存分配字符串操作仅限bpf_probe_read_*系列verifier 会拒绝任何复杂逻辑。把逻辑搬到用户空间的额外收益改检测规则无需重编译 eBPF 程序检测逻辑可以在无 root 权限的情况下做单元测试这正是tests/用make_event工厂直接构造TracerEvent就能跑的原因。模式二单一事件结构体五个 eBPF 程序共享同一个struct event布局即使并非每个字段对每个事件类型都有意义——进程事件用不到addr_v4网络事件用不到filename。结构体约 300 字节多数事件会带着大段零值字段看似浪费却换来三大优势Python 侧只需维护一份RawEventctypes 定义而非五份只需一个 ring buffer 回调而非五个代码更简单、bug 更少。从 processor.py 可以看到RawEvent的 16 个字段与 C 侧struct event严格镜像备选方案按类型区分联合体的多个结构体能省内存但在当前规模下复杂度不值得。模式三基于 deque 的时序关联检测引擎为每个 PID 维护一个带 maxlen 的collections.dequemaxlenMAX_EVENTS_PER_PID64每次求值时按CORRELATION_WINDOW_SEC10秒窗口从队首裁剪过期事件_prune_history()并每SWEEP_INTERVAL1000个事件做一次全量_sweep_stale()清扫空转 PID。这带来 O(1) 追加与 O(n) 扫描n 上界 64的复杂度。在典型服务器上约 1000 个活跃 PID 对应 1000 个 deque相关性状态的总内存占用不过几 MB。权衡表三组核心技术选型维度本项目选择备选方案取舍说明事件通道ring bufferperf bufferring buffer 需内核 5.8但提供事件顺序保证和 reserve/submit 零拷贝 API开销更低perf buffer 兼容 4.4 内核却有 per-CPU 分配浪费且无顺序保证eBPF 工具链BCClibbpf (CO-RE)BCC 需宿主机 LLVM、每工具约 80MB 内存libbpf 可产出约 9MB 的独立静态二进制。作为教学工具BCC 的 Python API 和迭代式开发体验胜出生产环境才值得切换到 libbpf挂载点tracepointkprobetracepoint 是稳定 ABI跨内核版本不破坏kprobe 钩任意内核函数内部 API 变化即可能失效。本项目只使用 tracepoint数据模型两个层次的完整字段RawEventC 结构体 / ctypes 镜像字段类型字节用途timestamp_nsu648内核单调时钟pidu324进程 IDppidu324父进程 IDuidu324用户 IDgidu324组 IDevent_typeu324枚举EXECVE1 … INIT_MODULE14flagsu324返回值或标志位openat 的 O_WRONLY/O_RDWR/O_TRUNC 等commchar[16]16进程名TASK_COMM_LENfilenamechar[256]256文件路径或设备名addr_v4u324IPv4 地址网络序portu162端口主机序protocolu162地址族AF_INET2target_uidu324setuid 目标 UIDtarget_gidu324setgid 目标 GIDptrace_requestu324ptrace 操作类型target_pidu324ptrace 目标 PID合计324注架构文档表格将 flags 计入ret_val源码中 RawEvent 实际命名为flags用于承载 openat 的访问标志是 D007/D008/D009 判定写操作的关键。TracerEventPython 富化层在 RawEvent 基础上扩展timestamp由内核纳秒换算为带时区的datetimeusername由 UID 经pwd.getpwuid()解析带 dict 缓存severity/detection/detection_id/mitre_id来自检测引擎盖章extradict 承载parent_comm等富化信息与内部关联用的_mono_time。安全架构权限、防护与清理权限模型加载 eBPF 程序需要 rootCAP_SYS_ADMIN。check_privileges()在启动时用os.geteuid()校验非 root 直接输出明确报错并退出绝不在降权状态下带病运行。eBPF 安全性内核 verifier 是最后防线保证 eBPF 程序不可能越出自身栈或 BPF map 访问内存、不可能执行无界循环、不可能调用任意内核函数、不可能导致内核崩溃。项目自身的安全逻辑建立在采集端只看不改的原则上。清理机制SIGINT/SIGTERM 信号处理器把_running置 False 退出轮询TracerLoader.cleanup()对每个 BPF 对象调用bpf.cleanup()分离 tracepoint、释放内核资源main.py 的try/finally保证即使出现异常清理也必然执行。输入验证数据源为内核 ring buffer可信与 /proc可信无用户直接输入CLI 参数由 Typer 通过类型注解自动校验枚举字面量类型OutputFormat/Severity/TracerType把非法取值挡在启动前。配置中心一张表掌握全部可调参数所有配置以模块级常量集中在 config.py配置项默认值作用RING_BUFFER_BYTES256KB共享 ring buffer 容量CORRELATION_WINDOW_SEC10有状态检测的滑动窗口秒MAX_EVENTS_PER_PID64每个 PID 相关性 deque 的最大事件数MIN_KERNEL_MAJOR / MINOR5.8最低内核版本ring buffer 依赖SENSITIVE_READ_PATHS/etc/shadow、/etc/gshadow、/etc/sudoers、/etc/master.passwd触发 D002 的敏感文件CREDENTIAL_PATHS.ssh/id_rsa、.aws/credentials、.gnupg/ 等触发 D003 的凭据文件CREDENTIAL_ACCESS_ALLOWLISTsshd、ssh-agent、gpg、gpg2 等D003 的白名单合法访问者PERSISTENCE_CRON_PATHS/etc/cron、/var/spool/cron、/etc/crontab触发 D007 的持久化路径PERSISTENCE_SYSTEMD_PATHS/etc/systemd/system/ 等触发 D008 的持久化路径LOG_PATHS/var/log/ 及 syslog/auth.log/kern.log触发 D009 的日志路径SHELL_BINARIESsh、bash、dash、zsh、csh、tcsh、fish、ksh参与 D006 反向 shell 判定的shell集合PTRACE_ATTACH / SEIZE / SETREGS16 / 16902 / 13触发 D004 的 ptrace 操作码SWEEP_INTERVAL1000全量清扫过期 PID 关联状态的周期事件数性能考量四个优化点ring buffer 尺寸256KB 对典型负载足够极端 syscall 速率10 万/秒下ringbuf_reserve返回 NULL 会丢事件高吞吐环境应调大RING_BUFFER_BYTES事件富化开销每个事件都读/proc/pid/comm会引入延迟--no-enrich参数专为高流量场景关闭该步骤用户名缓存UID→用户名解析使用 dict 缓存避免反复pwd.getpwuid()系统调用检测引擎复杂度无状态规则每事件 O(1)有状态规则扫描 deque有界 64 条最坏 O(64) 次比较。设计决策四个为什么为什么用 Python 而非 Go/RustBCC 拥有成熟、文档完备的 Python 绑定Go 绑定cilium/ebpf走的是 libbpf 而非 BCC 路径Rust 侧是 libbpf-rs。对以教学 eBPF 概念为目标的初学者项目Python 让读者聚焦 eBPF 与安全概念本身而非语言复杂度。为什么一个 ring buffer 而非每 tracer 一个每个 BPF 程序确实各有自己的BPF_RINGBUF_OUTPUT但它们共享同一结构体布局与同一个 Python 回调把回调逻辑保持为单一解析路径若每个 tracer 配独立回调与独立结构体就需要维护五套解析代码。为什么标准 tracepoint 而非 raw_tracepointraw_tracepoint 提供bpf_raw_tp_args结构体、抽象更少、速度略快但需手动转换参数标准 tracepoint 提供args-具名字段访问对学习项目可读性高得多。为什么用 Typer与仓库其他项目保持一致Typer 以极少量代码提供自动帮助生成、类型校验与 shell 补全。可扩展性三个标准扩展流程新增一个 syscall在 config.py 的EventType枚举中新增事件类型加入EVENT_TYPE_CATEGORIES在合适的.c文件或新建文件中编写TRACEPOINT_PROBE如需新检测规则在DETECTION_RULES登记并在 detector.py 中实现。新增一条检测规则在DETECTION_RULES中添加DetectionRule条目在detector.py的_check_stateless()或_check_stateful()中实现判定在 tests/test_detector.py 添加对应测试。新增一种输出格式在 renderer.py 中创建带render(event)方法的渲染器类在config.py的OutputFormat字面量类型中加入格式名在create_renderer()工厂中处理该格式。已知局限与演进方向架构文档明确列出了五条当前边界IPv6网络 tracer 只解析 IPv4sockaddr_inIPv6 需处理sockaddr_in6与 128 位地址字段容器感知无容器 ID 或 namespace 检测需读/proc/pid/cgroup或使用 BPF namespace helper参数捕获execve 仅捕获首个参数filename完整 argv 需读取指针数组受 verifier 约束实现复杂fd 跟踪不维护 fd→文件映射无法把connect()的 fd 与后续dup2()关联无持久化事件不落库历史分析需把 JSON 输出管道到文件或日志聚合系统。与生产级工具的能力定位特性本项目FalcoTetragonTraceeeBPF 后端BCC (Python)libs (C)libbpf (Go)libbpf (Go)Syscall 覆盖14503040检测规则10100基于策略70拦截能力仅检测仅检测检测阻断仅检测容器感知否是是是内存占用~80MB~50MB~30MB~60MB生产就绪否教学是是是正如架构文档的定位总结这是一个学习资源它传授的正是支撑 Falco 与 Tetragon 的同一套 eBPF 基础原理但把规模压缩到每一行代码都可读、可理解的层次。对于希望进入 eBPF 安全监控领域的开发者这份架构可以作为通往生产级方案的起点——ring buffer tracepoint 用户空间两级检测引擎这套骨架在更大的系统中同样成立。更进一步的实现细节与代码走读可继续阅读 03-IMPLEMENTATION.md相关前置概念见 01-CONCEPTS.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点击查看免费下载相关推荐深入解析 slang 仓库中的 spvdbSPIR-V 着色器源码级调试器与解释器深入解析 slang 仓库中的 spvdbSPIR V 着色器源码级调试器与解释器 导读 spvdbSPIR V Shader Debugger是 sl/Linux 内核揭秘open 系统调用实现深度解析——从用户空间到内核态的完整路径Linux 内核揭秘open 系统调用实现深度解析——从用户空间到内核态的完整路径 本篇技术指南源自《Linux 内核揭秘linux insides zh如何快速生成微信支付宝QQ三合一收款码终极免费解决方案如何快速生成微信支付宝QQ三合一收款码终极免费解决方案 在移动支付普及的今天商户和个人经常面临一个难题需要向客户展示多个不同平台的收款码。这不仅影响用户体开发工具运维观测系统底层上一篇Flutter Engine混合开发终极指南与原生应用无缝集成的10个技巧下一篇人工智能领域重大突破全新模型架构引领行业变革创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考