当AI编写你的防火墙时，请检查数学计算
这是新常态。人们正在用他们并不主要使用的语言交付真实项目，速度之快在两年前是不可能的。问题不在于AI辅助代码能否写好。问题在于你是否能区分出真正优秀的代码和看起来优秀的代码。我去探究了一番。
Blackwall是什么？
Blackwall是一个eBPF/XDP防火墙，带有LLM驱动的蜜罐，使用Rust编写。名字来源于《赛博朋克2077》中的AI隔离屏障。它通过aya（纯Rust eBPF，无C，无libbpf）在内核级别运行数据包过滤，通过一个状态机跟踪每个IP的行为特征，该状态机从New升级到Normal再到Probing最后到EstablishedC2，进行JA4 TLS指纹识别和深度数据包检测，并包含一个通过Ollama使用本地LLM来模拟受损Ubuntu服务器的tarpit（慢速陷阱）。其理念是：当行为引擎将某个IP标记为恶意时，流量会被重定向到蜜罐，蜜罐假装成真实机器，同时记录攻击者的一切行为。
一个维护者。两次提交。四天内获得119颗星。MIT许可证。
项目快照
| 项目 | Blackwall |
|---|---|
| 星标数 | 撰写时约119颗 |
| 维护者 | 单人（xzcrpw），一次提交推送所有内容 |
| 代码健康度 | 8544行，123个测试，生产环境中零unwrap()，胶水代码中存在真实bug |
| 贡献者体验 | 无CONTRIBUTING.md，无CI，无从判断的PR历史 | | 是否值得使用 | 尚不值得，但值得阅读 |
底层架构
一个Cargo工作区中包含六个crate。common存放内核与用户空间之间共享的#[repr(C)]类型，带有显式填充字段。blackwall-ebpf包含XDP程序。blackwall是用户空间守护进程。tarpit是蜜罐。blackwall-controller协调分布式节点。xtask处理eBPF交叉编译。
eBPF代码是最强的部分。每次指针解引用在访问前都有边界检查，这不仅是良好实践，更是硬性要求：否则BPF验证器会拒绝你的程序，而通过aya在Rust中正确实现这一点比听起来要难。熵估计使用256位位图而不是直方图，这是针对eBPF 512字节栈限制的巧妙改编。TLS ClientHello解析器处理会话ID、密码套件、压缩方法、扩展、SNI提取、ALPN和GREASE过滤。如果你想看如何用Rust编写正确的eBPF代码，这是一个可靠的参考。
行为引擎也很清晰。从New到EstablishedC2的七个阶段，怀疑度单调递增，并有一条明确的降级路径到Trusted。状态机使用确定性阈值进行快速路径决策，可选的LLM分类作为慢速路径。常量命名良好且一致：SUSPICION_INCREMENT为0.15，SUSPICION_MAX为1.0，SUSPICION_DECAY为0.02。提升到Trusted需要分数在300秒和100多个数据包内保持在0.1以下。
tarpit是创意所在。它运行四个协议处理程序：SSH（由假装成bash shell的LLM支持）、HTTP（假WordPress）、MySQL（线协议响应）和DNS（金丝雀记录）。SSH蜜罐的系统提示足够详细，具有说服力。它指定了主机名、内核版本、文件系统布局、已安装服务，并包含示例命令/输出对，以便LLM知道用原始终端输出回应，而不是“当然，这是ls的输出”。
现在说说bug。该项目在Ollama请求中设置了"think": false，但某些模型仍然会输出<think>块。剥离代码恰好处理一个块：
if let Some(start) = content.find("<think>") {
if let Some(end) = content.find("</think>") {
let after = &content[end + 8..];
after.trim_start().to_string()
如果模型输出两个<think>块，第二个块会直接传给攻击者，泄露LLM关于如何回应的推理过程。一个带有安全漏洞的安全工具。
贡献内容
怀疑分数尺度不匹配是最容易修复的bug。行为引擎在0.0到1.0的尺度上运行。增量为0.15，最大值为1.0，每次评估衰减0.02，提升到Trusted需要分数低于0.1。但process_events中的DPI事件处理程序加了15.0，上限为100.0。完全不同的尺度。任何触发单个DPI检测的IP都会获得15.0+的怀疑分数，使得提升到Trusted几乎不可能。以每次滴答衰减0.02的速度，大约需要750次滴答才能回到0.1以下。
修复很小：从behavior模块导出SUSPICION_INCREMENT和SUSPICION_MAX，并在DPI处理程序中使用它们，匹配transition逻辑中apply_escalation已经使用的模式。三个文件，11处插入，5处删除。所有19个行为测试都通过了。
尽管代码库规模较大，但进入其中很容易。工作区结构保持分离，命名一致，行为引擎足够自包含，无需阅读eBPF代码就能理解状态机。找到bug的方法是用grep搜索suspicion_score，并注意到一个调用点与其他调用点完全不同。
PR #3当天就得到了回复。维护者在一次重大的架构重写中独立发现了同一个bug，并关闭了PR以避免与新核心的合并冲突。“兄弟，尺度不匹配的问题抓得好。”几小时后他发布了v2.0.0，彻底修改了行为引擎并迁移到原生eBPF DNAT。其他人的详细bug报告也得到了类似的回应：所有发现都将在重写中解决。两个问题现在都已关闭。
最终 verdict
Blackwall作为一个代码库和案例研究都很有趣。eBPF工作确实有能力。行为引擎设计良好。蜜罐概念很有创意。但它是在一次提交中发布的，没有CI，没有开发历史，并且连接组件的代码中存在bug。最强的部分（内核程序、类型契约、状态机）看起来是精心构建的。最弱的部分（DPI集成、think标签剥离、死代码）看起来是拼凑起来的，没有经过端到端测试。
这不是对使用AI编写代码的批评。这是对在没有集成测试的情况下交付的批评，无论代码是谁或什么编写的。eBPF验证器强制你在内核程序中正确。但没有任何东西强制你在胶水代码中正确。
如果你从事eBPF工作，XDP程序和aya模式值得研究。如果你对蜜罐设计感兴趣，tarpit的多协议方法和LLM集成是真正新颖的。维护者在同一周发布了v2.0.0重写，这表明集成bug正在被解决。如果你想在生产环境中运行它，请先认真阅读新版本。架构已经发生了重大变化，它还没有时间积累你希望从位于攻击者和你的网络之间的东西中获得的那种真实世界测试。
去看看
GitHub上的Blackwall。即使跳过其余部分，也要阅读eBPF代码。
如果你想贡献，v2.0.0重写是一个全新的起点。我们的怀疑分数修复和bug报告都已关闭，并在重写中得到解决。新的代码库仍然没有CI，<think>标签剥离可能仍然需要改进。35 MB的PNG资源仍然存在。
这是Review Bomb系列的第14篇，我在这个系列中寻找GitHub上不太引人注目的项目，阅读代码，贡献一些内容，并写下来。FINISHED
