CrowdSecによる協調型侵入防止基盤の本番構築｜誤検知チューニング・ブロックリスト設計・切り戻し

CrowdSecの協調型防御モデルを理解する

CrowdSecは、従来のIPSと異なり「脅威インテリジェンスを参加者間で共有するコミュニティ駆動型」のアーキテクチャを採用しています。攻撃を検知したノードがその情報をCrowdSec CTI（Cyber Threat Intelligence）ネットワークに提供し、他のノードが同じ攻撃元からの接続を事前にブロックできる仕組みです。

構成要素は大きく三層に分かれます。まずSecurity Engine（旧称: Agent）がログを監視してシナリオマッチングを行い、アラートを生成します。次にBouncerがネットワーク層・アプリケーション層でブロック処理を実行します。そしてLAPI（Local API）がEngineとBouncerを仲介しながら、決定情報をCrowdSec CTIと同期します。

2026年時点での最新安定版はCrowdSec 1.6系です。1.5以前から大きく変わった点として、Hub（シナリオ・パーサーの配布基盤）のAPI仕様が刷新され、cscli hub upgradeの挙動が変更されています。既存環境をアップグレードする場合は、リリースノートでブレーキングチェンジを確認してから作業してください。

インストールとLAPI・Bouncer接続の初期構成

Debian/Ubuntu系では公式リポジトリを追加してインストールします。

curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash
sudo apt install crowdsec

インストール直後、CrowdSecはシステム上のログファイルを自動検出してコレクション（パーサー＋シナリオのセット）を提案します。提案内容を確認するには以下のコマンドを使います。

sudo cscli collections list
sudo cscli scenarios list

Webサーバー向けにnginxコレクションを追加する場合は次のようにします。

sudo cscli collections install crowdsecurity/nginx
sudo systemctl reload crowdsec

Bouncerは用途に応じて選択します。代表的なものはcrowdsec-firewall-bouncer-iptables（iptables/nftablesによるL3ブロック）とcrowdsec-nginx-bouncer（HTTPレイヤーのブロック）です。ファイアウォールBouncerを導入する場合は以下のとおりです。

sudo apt install crowdsec-firewall-bouncer-nftables
sudo systemctl enable --now crowdsec-firewall-bouncer

Bouncerは/etc/crowdsec/bouncers/配下の設定ファイルでLAPIエンドポイントとAPIキーを参照します。APIキーはsudo cscli bouncers add <name>で生成し、設定ファイルへ転記します。設定後にsudo cscli bouncers listで接続確認できます。

誤検知のチューニング：ホワイトリストとシナリオ除外

本番導入直後によくあるつまずきが、監視ツール・CDN・社内IPアドレスの誤ブロックです。CrowdSecの誤検知対策には「ホワイトリスト」と「シナリオの無効化」という二段構えのアプローチがあります。

ホワイトリストによるIP除外は、/etc/crowdsec/parsers/s02-enrich/配下にYAMLファイルを追加します。

# /etc/crowdsec/parsers/s02-enrich/mywhitelist.yaml
name: myorg/mywhitelist
description: "Internal and monitoring IPs"
whitelist:
  reason: "Internal network and monitoring"
  ip:
    - "192.168.1.0/24"
    - "10.0.0.5"
  expression:
    - evt.Meta.source_ip startsWith "203.0.113."

ファイルを配置後はsudo systemctl reload crowdsecで反映します。ホワイトリストはパーサー段階で評価されるため、該当IPはアラートそのものが生成されません。

特定シナリオの無効化は誤検知率が高いシナリオに対して行います。一般的には、共有ホスティング環境やCDN経由のアクセスが多い環境でHTTPシナリオが誤反応しやすい傾向があります。

sudo cscli scenarios remove crowdsecurity/http-probing
sudo systemctl reload crowdsec

シナリオを削除する前に、sudo cscli decisions listとsudo cscli alerts listでどのシナリオが何件のアラートを生成しているか確認することを推奨します。特定シナリオのパラメータ（閾値・期間）を調整したい場合は、Hubから取得したYAMLをローカルコピーして/etc/crowdsec/scenarios/に配置することでオーバーライドできます。

ブロックリスト設計：CTI連携とカスタムリストの使い分け

CrowdSecのブロックリストは「コミュニティ共有の動的リスト」と「自組織で管理するカスタムリスト」の組み合わせで設計します。

CTI連携リスト（Blocklists）はCrowdSec Consoleで購読管理します。無料枠でも「CrowdSec Community Blocklist」が利用でき、LAPIが定期的に差分を取得してBouncerに配布します。サブスクリプション型の商用リスト（Firehose等）は有料プランで利用でき、より広範なIPレピュテーション情報を得られます。

リストのサイズ管理は見落とされがちな設計ポイントです。iptables/nftablesのipsetはエントリ数が数万を超えてくるとメモリ消費と照合コストが問題になる場合があります。一般的な目安として、Bouncerが処理するルール数を定期的に確認します。

sudo nft list ruleset | grep -c "crowdsec"

カスタムリスト（手動決定）はcscli decisions addで追加します。期間・スコープを明示的に指定することが運用の基本です。

# 特定IPを72時間ブロック
sudo cscli decisions add --ip 198.51.100.45 --duration 72h --reason "manual-block-investigation"

# ASN単位でブロック（慎重に）
sudo cscli decisions add --scope Autonomous-System --value 64496 --duration 24h --reason "suspicious-asn"

ASN・国単位でのブロックは広範な巻き込み誤検知を引き起こすリスクがあるため、本番では事前に影響範囲を評価してから実施してください。想定例として、特定国からの通信が業務上不要なシステム（B2B SaaS等）では国単位ブロックが有効な場合があります。一方、一般公開のWebサービスでは同じ設定が正規ユーザーをブロックするリスクを伴います。

動作検証：アラートとDecisionの確認フロー

設定変更後は以下の順で動作を確認します。

• パーサーのテスト：sudo cscli explain --log "sample log line" --type nginx でログ行がどのシナリオにマッチするか確認できます。
• シナリオのドライラン：本番投入前はsimulationモードを有効化し、アラートを生成するがDecision（ブロック）は発生しない状態でログを蓄積します。
• アラート確認：sudo cscli alerts list --limit 20 で直近のアラートを確認し、誤検知が含まれないか評価します。
• Decision確認：sudo cscli decisions list で実際にブロックリストへ登録されたIPと期限を確認します。

simulationモードの有効化は以下の手順です。

# 特定シナリオをシミュレーションモードに
sudo cscli simulation enable crowdsecurity/http-probing

# 全シナリオをシミュレーションモードに（初期検証時）
sudo cscli simulation enable --global

Prometheus形式のメトリクスはhttp://localhost:6060/metricsで取得でき、Grafanaと組み合わせてアラート発生数・シナリオ別マッチ率をダッシュボード化することが推奨されます。CrowdSec Console（クラウドUI）でも同様の可視化が可能で、複数ノードの集中管理に向いています。

切り戻し手順と長期運用の注意点

CrowdSecを本番で運用するうえで、切り戻しシナリオを事前に整理しておくことは重要です。

即時切り戻し（緊急時）：Bouncerを停止すればブロック処理はただちに無効化されます。Security Engineを止めてもBouncerが動いている間はすでに登録済みのDecisionが有効なまま残るため、Bouncerの停止が最速の切り戻し手段です。

sudo systemctl stop crowdsec-firewall-bouncer

特定Decision（ブロックエントリ）の削除：誤ってブロックしたIPを手動で解除する場合は次のようにします。

# IPでの削除
sudo cscli decisions delete --ip 198.51.100.45

# 全Decisionのフラッシュ（慎重に）
sudo cscli decisions delete --all

長期運用での注意点として以下を押さえておいてください。

• Hubのコレクション・シナリオは定期更新が必要です。sudo cscli hub update && sudo cscli hub upgradeを定期実行するcronジョブを組むことが一般的です。
• SQLiteバックエンド（デフォルト）は大規模環境でI/Oがボトルネックになる場合があります。高トラフィック環境ではPostgreSQLへの移行を検討します。
• CTI連携のブロックリストは外部サービスへの依存を意味します。CTIエンドポイントへの疎通が途絶えた場合の動作（既存Decisionが維持されるか、期限切れで消えるか）を事前に確認しておいてください。
• 2026年現在、CrowdSec AppSec Component（WAFルール）が1.6系で正式リリースされています。Nginx/Apacheとの統合により、L7レベルのSQLi・XSSシグネチャ検知も同一エージェントで管理できるようになりました。既存構成への追加導入時は、nginx-bouncerのバージョン互換性を確認してください。

協調型防御の効果はコミュニティへの貢献（アラートの共有許可）と直結します。プライバシーポリシーや社内セキュリティポリシーと照らし合わせながら、共有スコープを適切に設定したうえで運用を継続することが、長期的な防御品質の向上につながります。