Suricata

简介

Suricata 是由 OISF 和 Suricata 社区开发的网络 IDS、IPS 和 NSM 引擎。

资源

• 主页
• Bug 跟踪器
• 用户指南
• 开发者指南
• 安装指南
• 用户支持论坛

贡献

我们非常乐意接受补丁和其他贡献。请参阅我们的贡献流程了解如何开始。

Suricata 是一款复杂的软件，处理的大多是不可信的输入。错误处理这些输入将产生严重后果：

• 在 IPS 模式下，崩溃可能导致网络离线
• 在被动模式下，IDS 被攻破可能导致关键和机密数据丢失
• 漏检可能导致网络被入侵而未被发现

换句话说，我们认为风险相当高，尤其是在许多常见情况下，攻击者可以直接访问 IDS/IPS。

因此，我们开发了一套相当全面的 QA 流程。其结果是，为 Suricata 做贡献可能是一个较为漫长的过程。

从高层来看，步骤如下：

1. 基于 GitHub-CI 的检查。当提交拉取请求时会自动运行。
2. 由团队和社区的开发者进行审查
3. 来自私有 QA 环境的 QA 运行。由于测试流量的性质，这些环境是私有的。

Suricata QA 步骤概述

OISF 团队成员可以向我们的私有 QA 环境提交构建。它将运行一系列构建测试和回归测试套件，以确认没有现有功能被破坏。

最终的 QA 运行最少需要几个小时，通常会在夜间运行。目前它运行：

• 在不同操作系统、编译器、优化级别和 configure 功能上进行广泛的构建测试
• 使用 cppcheck、scan-build 进行静态代码分析
• 使用 valgrind、AddressSanitizer、LeakSanitizer 进行运行时代码分析
• 针对过去 bug 的回归测试
• 日志输出验证
• unix socket 测试
• 使用 ASAN 和 LSAN 的基于 pcap 的模糊测试
• 基于流量重放的 IDS 和 IPS 测试

除这些测试外，根据代码更改的类型，还可以手动运行进一步测试：

• 流量重放测试（多千兆）
• 大型 pcap 集合处理（多太字节）
• 模糊测试（可能需要数天甚至数周）
• 基于 pcap 的性能测试
• 实时性能测试
• 根据对拟议更改的评估进行的各种其他手动测试

重要的是要认识到，上述几乎所有测试都用作验收测试。如果有任何测试失败，你需要在自己的代码中解决这个问题。

QA 的一个步骤目前是在合并后运行的。我们将构建提交给 Coverity Scan 程序。由于这项（免费）服务的限制，我们每天最多只能提交一次。当然，合并后社区可能会发现问题。对于这两种情况，我们都请求你帮助解决可能出现的问题。

常见问题

问：你会接受我的 PR 吗？

答：这取决于很多因素，包括代码质量。对于新功能，还取决于团队和/或社区是否认为该功能有用、它对其他代码和功能的影响程度、性能回退的风险等。

问：我的 PR 什么时候会被合并？

答：视情况而定，如果它是一个主要功能或被视为高风险更改，它可能会进入下一个主要版本。

问：为什么我的 PR 被关闭了？

答：如 Suricata GitHub 工作流 所述，我们希望每次更改都提交一个新的 PR。

通常，团队（或社区）会对拉取请求给出反馈，之后应当用改进后的 PR 替换它。所以请查看评论。如果你不同意这些评论，我们仍然可以在已关闭的 PR 中讨论它们。

如果 PR 在没有评论的情况下被关闭，很可能是由于 QA 失败。如果 GitHub-CI 检查失败，应立即修复 PR。没有必要对此进行讨论，除非你认为 QA 失败是错误的。

问：编译器/代码分析器/工具出错了，现在怎么办？

答：为了辅助 QA 的自动化，我们不接受警告或错误留存。在某些情况下，这意味着如果工具支持，我们会添加抑制（例如 valgrind、DrMemory）。某些警告可以被禁用。在一些特殊情况下，唯一的“解决方案”是重构代码以绕过静态代码检查器的误报限制。尽管这令人沮丧，但我们更愿意这样做，而不是在输出中留下警告。警告往往会被忽略，然后增加掩盖其他警告的风险。

问：我认为你们的 QA 测试是错误的

答：如果你真的这么认为，我们可以讨论如何改进它。但不要太快得出这个结论，更多时候是代码本身有问题。

问：你们是否要求签署贡献者许可协议？

答：是的，我们这样做是为了将 Suricata 的所有权集中在一方手中：Open Information Security Foundation。请参阅 http://suricata.io/about/open-source/ 和 http://suricata.io/about/contribution-agreement/