Suricata

はじめに

Suricata は、OISF と Suricata コミュニティによって開発されたネットワーク IDS、IPS、NSM エンジンです。

リソース

• ホームページ
• バグトラッカー
• ユーザーガイド
• 開発者ガイド
• インストールガイド
• ユーザーサポートフォーラム

貢献について

パッチやその他の貢献を歓迎しています。開始方法については、貢献プロセス をご覧ください。

Suricata は、ほとんどが信頼されていない入力（untrusted input）を扱う複雑なソフトウェアです。この入力を誤って処理すると、深刻な結果を招く可能性があります：

• IPS モードでは、クラッシュによってネットワークがオフラインになる可能性があります
• パッシブモードでは、IDS の侵害により、重要かつ機密性の高いデータが失われる可能性があります
• 検出の見逃しは、ネットワークの侵害が検出されないままになる可能性があります

言い換えれば、多くの一般的なケースでは IDS/IPS が攻撃者から直接到達可能であるため、リスクはかなり高いと考えています。

このため、当プロジェクトでは非常に大規模な QA プロセスを開発してきました。その結果、Suricata への貢献はやや時間のかかるプロセスになることがあります。

大まかに言うと、手順は次のとおりです：

1. GitHub-CI ベースのチェック。プルリクエストが作成されると自動的に実行されます。
2. チームとコミュニティの開発者によるレビュー
3. プライベートな QA 環境での QA 実行。テストトラフィックの性質上、これらは非公開です。

Suricata の QA 手順の概要

OISF チームメンバーは、ビルドを非公開の QA 環境に提出できます。QA 環境では、既存機能が壊れていないことを確認するために、一連のビルドテストとリグレッション（回帰）テストスイートが実行されます。

最終的な QA 実行は最短で数時間かかり、通常は一晩かけて実行されます。現在、以下のテストが実行されます：

• さまざまな OS、コンパイラ、最適化レベル、configure 機能での広範なビルドテスト
• cppcheck、scan-build を使用した静的コード解析
• valgrind、AddressSanitizer、LeakSanitizer を使用したランタイムコード解析
• 過去のバグに対するリグレッションテスト
• ログ出力の検証
• Unix ソケットテスト
• ASAN と LSAN を使用した pcap ベースのファズテスト
• トラフィックリプレイに基づく IDS および IPS テスト

これらのテストに加えて、コード変更の種類に応じて、以下の追加テストを手動で実行できます：

• トラフィックリプレイテスト（マルチギガビット）
• 大規模な pcap コレクションの処理（マルチテラバイト）
• ファズテスト（数日から数週間かかる場合があります）
• pcap ベースのパフォーマンステスト
• ライブパフォーマンステスト
• 提案された変更の評価に基づくその他のさまざまな手動テスト

上記のテストのほぼすべてが受け入れテストとして使用されていることを理解することが重要です。何かが失敗した場合、それを自分のコードで対応するのはあなたの責任です。

現在、QA の1つのステップがマージ後に実行されます。ビルドを Coverity Scan プログラムに提出しています。この（無料の）サービスの制限により、提出は最大1日1回です。もちろん、マージ後にコミュニティが問題を発見することもあります。いずれの場合も、問題が発生した際には対処にご協力いただくようお願いします。

FAQ

Q: 私の PR は受け入れてもらえますか？

A: コードの品質を含むいくつかの要因によります。新機能の場合、チームやコミュニティがその機能が有用だと思うかどうか、他のコードや機能への影響の大きさ、パフォーマンス低下のリスクなどにも依存します。

Q: 私の PR はいつマージされますか？

A: 状況によります。大きな機能やリスクの高い変更と見なされる場合は、おそらく次のメジャーバージョンに含まれます。

Q: 私の PR がクローズされたのはなぜですか？

A: Suricata GitHub ワークフロー に記載されているとおり、変更ごとに新しいプルリクエストを提出していただくことを想定しています。

通常、チーム（またはコミュニティ）はプルリクエストに対してフィードバックを行い、その後、改善された PR に置き換えられることが期待されます。コメントを確認してください。コメントに同意できない場合は、クローズされた PR 内で議論することも可能です。

コメントなしで PR がクローズされた場合、それはおそらく QA の失敗が原因です。GitHub-CI チェックが失敗した場合は、すぐに PR を修正してください。QA の失敗が誤りであると思わない限り、議論の必要はありません。

Q: コンパイラ／コード解析ツールの方が間違っていると思います。どうすればいいですか？

A: QA の自動化を支援するため、警告やエラーを残したままにすることは受け入れていません。場合によっては、ツールが対応していれば抑制（サプレッション）を追加することもあります（例: valgrind、DrMemory）。無効にできる警告もあります。例外的なケースでは、静的コードチェッカーの限界による誤検知を回避するためにコードをリファクタリングすることが唯一の「解決策」となる場合もあります。もどかしいですが、出力に警告を残すよりはこちらを選びます。警告は無視される傾向があり、他の警告を隠すリスクが高まります。

Q: QA テストの方が間違っていると思います

A: 本当にそう思うのであれば、改善方法について議論できます。ただし、結論を急ぎすぎないでください。多くの場合、間違っているのはコードの方です。

Q: コントリビューターライセンス契約（CLA）への署名は必要ですか？

A: はい、必要です。これは Suricata の所有権を単一の組織である Open Information Security Foundation に保持するためです。http://suricata.io/about/open-source/ と http://suricata.io/about/contribution-agreement/ をご覧ください。