crowdsec

CrowdSec

CrowdSec はログと HTTP リクエストから悪意のある動作を検出し、LAPI を通じてアラートと判断を公開します。エンジンだけではトラフィックをブロックしません。保護できていると主張する前に、少なくとも 1 つの修復コンポーネント（バウンサー）をインストールして動作を確認してください。

安全確認

変更を加える前に、対象ホスト／コンテナー、対象範囲、バックアップまたはロールバック手段、メンテナンス時間帯を確認してください。まず読み取り専用の調査とシミュレーションを行ってください。理由と元に戻す手順を記録せずに、判断、コレクション、データを手動で削除してはいけません。バウンサーキーは作成時に保存してください。一度しか表示されません。シナリオの調整中は simulation: true を使用し、強制適用せずに検出結果を確認してから、実際にブロックする前に許可リストを検証してください。

デプロイ方法を選択する

Debian/Ubuntu では、CrowdSec リポジトリを追加し、crowdsec をインストールしてから、crowdsec-firewall-bouncer-iptables または -nftables などの修復パッケージをインストールします。Docker Compose の場合は、LAPI（127.0.0.1:8080）、メトリクス（127.0.0.1:6060）、AppSec（127.0.0.1:7422）を必要なネットワークにのみ公開し、/etc/crowdsec、/var/lib/crowdsec/data、ログを読み取り専用でマウントし、レビュー済みのイメージバージョンを固定してください。v1.7.0+ では必須となるデータディレクトリを永続化してください。完全な Compose の例とリモートエージェントに関する注意事項は、Docker デプロイガイドを参照してください。

インストール後、systemctl status crowdsec（またはコンテナーのヘルス状態）を確認し、続いて cscli version、cscli collections list、取得メトリクス、バウンサーの接続状態を確認してください。明確なネットワーク設計と認証設計なしに、LAPI や AppSec をパブリックに公開してはいけません。

検出からブロックまでのワークフロー

1. 実際のログ形式に合ったコレクションを選択します。たとえば、crowdsecurity/linux、sshd、nginx、traefik、base-http-scenarios などです。
2. /etc/crowdsec/acquis.yaml または acquis.d/ で取得設定を行います。すべてのソースには、正しいパーサーが実行されるよう labels.type が必要です。信頼性の低い NFS/SMB またはバインドマウントでは poll_without_inotify: true を、バッファーされたログでは use_time_machine: true を使用してください。
3. cscli metrics -o json でパーサー／シナリオのヒット数と未解析行を確認します。
4. プロファイルを使用してアラートを判断に割り当てます。profiles.yaml.local を保持し、YAML のシーケンスはマージではなく置き換えられることに注意してください。
5. cscli bouncers add NAME でバウンサーを追加し、一度だけ表示されるキーを安全に保存してから、cscli bouncers list と無害なテスト用判断で確認します。
6. リバースプロキシ／ファイアウォールが実際に判断を適用していることを確認してください。アラートや LAPI の判断だけでは、リクエストがブロックされた証拠にはなりません。

設定ディレクティブ、データベースの選択肢、セキュリティ強化については、config-reference、database-config、production-hardeningを参照してください。

cscli の基本

自動化には cscli -o json を使用し、コマンド出力、バージョン、ホスト、時刻を証拠として記録してください。読み取り専用のトリアージでは、一般に次のコマンドを使用します。

cscli version
cscli hub list
cscli collections list
cscli alerts list --contain "scenario:ssh-bf"
cscli decisions list -o json
cscli metrics -o json
cscli explain --file /path/to/sample.log

cscli hub update はローカルの Hub インデックスを更新し、ローカル状態を変更する場合があります。これは任意の操作であり、読み取り専用のトリアージ手順には含まれません。実行前に、上記の安全確認が必要です。Hub 項目は collections|parsers|scenarios install/list/upgrade/inspect で管理します。これらのインストール、アップグレード、削除操作にも安全確認が必要です。アラートと判断は alerts list/inspect および decisions add/list/delete で管理します。変更コマンドの実行前にも、上記の安全確認が必要です。 バウンサーとマシンは bouncers add/list/delete および machines add/list/delete で管理します。console status、console enroll、lapi register は、接続先と認証情報を確認してから使用してください。フラグ、出力モード、使用頻度の低いコマンドについては、cscli の完全なリファレンスを参照してください。

取得とAppSec WAF

最小限のファイル取得エントリーは次のとおりです。

filenames: [/var/log/nginx/*.log]
labels: {type: nginx}

AppSec では、関連する仮想パッチ／CRS コレクションをインストールし、7422 でリッスンする appsec 取得ソースを追加します。このソースには、appsec_config: crowdsecurity/appsec-default と labels.type: appsec を設定します。プロキシからのリクエストを AppSec にルーティングし、障害時の動作を慎重に決定してください。フェイルオープンは可用性を維持しますが、保護を回避する可能性があります。フェイルクローズはより強力に保護しますが、障害を引き起こす可能性があります。ブロッキングを有効にする前に、問題のないフィクスチャでテストし、AppSec のメトリクスを確認してください。インバンドルールは現在のリクエストをブロックするか CAPTCHA を表示します。アウトオブバンドルールは、後続のシナリオで使うイベントを出力します。 AppSec の詳細解説と、関連するバウンサーガイドまたはnginx-bouncerを読み込んでください。

運用とトラブルシューティング

この順序で、サービスログ、cscli metrics、パーサー／未解析件数、シナリオのヒット数、有効な判定、バウンサーの最終取得時刻を確認します。「ログを取得できていない」「ログは取得できているが解析されていない」「解析済みだがシナリオにヒットしていない」「判定は存在するがバウンサーが古い」「バウンサーは適用したがプロキシのルーティングが誤っている」を区別してください。アラートのクエリ結果が空でも、安全である証拠とは見なさないでください。範囲を限定した検証資料には、トラブルシューティングガイドと運用チェックリストを使用してください。

プロファイルと通知は意図的に使用してください。cscli notifications test NAME で通知プラグインをテストします。Webhook シークレットや CTI キーをサンプルに記載しないでください。信頼境界を越える LAPI には TLS/mTLS を有効にし、コミュニティリスト／ブロックリストの取得に依存する前に内容を確認してください。

参考資料

• Docker のデプロイ
• 設定
• cscli コマンド
• AppSec WAF
• 運用チェックリスト
• トラブルシューティング
• 本番環境の強化
• データベース設定
• Hub コレクション
• Traefik バウンサー
• Nginx バウンサー