CrowdSec は、サーバーのログを読み取って攻撃の兆候を検知し、必要に応じて遮断までつなげるオープンソースのセキュリティエンジンです。この記事では、CrowdSec を「ログ分析の道具」として使う方法に絞り、ログの読み込み設定、パースできているかの確認、アラートの中身の読み方、過去ログの分析、誤検知への対応までを説明します。遮断の設定より先に、何が検知されているかを正しく読めるようにすることが目的です。
CrowdSec がログを処理する流れ
CrowdSec の処理は、おおまかに次の段階に分かれています。どこで止まっているかを切り分けるために、まずこの流れを押さえておきます。
- 取り込み（acquisition）: 指定したログファイルや journald などから行を読み込みます。
- パース（parsers）: 1 行ずつ解析し、IP アドレス、URL、ステータスコードなどの項目に分解します。
- シナリオ（scenarios）: 「短時間に同じ IP からログイン失敗が続く」といった振る舞いのパターンに当てはまるかを判定します。当てはまるとアラートになります。
- 判定（decisions）: アラートに応じて、IP を一定時間遮断するなどの判定を作ります。
- 遮断（remediation components / bouncers）: ファイアウォールや Web サーバー側で判定を実行します。
ログ分析として見るのは主に 1〜3 の段階です。遮断用のコンポーネントを入れなければ、検知と記録だけを行う使い方もできます。導入直後はこの形で様子を見ると、誤検知で正当な利用者を締め出す心配がありません。
パーサーやシナリオは「コレクション」という単位で Hub から配布されています。Nginx や Apache、SSH、WordPress 向けのものが用意されています。コレクションの名前や中身は更新されるため、導入前に cscli hub list や公式の Hub ページで確認してください（2026年10月現在）。
ログの取り込みを設定する
インストール時に、主要なサービスのログは自動で検出されることがあります。自動検出されなかったログや、場所を変えているログは、取り込み設定を追加します。設定ファイルは /etc/crowdsec/acquis.yaml か、/etc/crowdsec/acquis.d/ 配下に置きます。
# /etc/crowdsec/acquis.d/nginx.yaml
filenames:
- /var/log/nginx/access.log
- /var/log/nginx/error.log
labels:
type: nginxlabels.type は、どのパーサーでこのログを読むかを決める値です。ここが合っていないと、ログは読み込まれてもパースされません。設定後は対応するコレクションを入れて、サービスを再起動します。
sudo cscli collections install crowdsecurity/nginx
sudo systemctl restart crowdsecリバースプロキシや CDN の背後にある場合
Cloudflare などの CDN やロードバランサーの背後にあるサーバーでは、Web サーバーのログに残る送信元 IP がプロキシの IP になっていることがあります。この状態で分析すると、プロキシの IP が攻撃元として記録され、遮断まで進めば正当な利用者もまとめて締め出されます。Nginx の real_ip モジュールなどでクライアントの実 IP をログに残す設定を先に済ませてください。
パースできているかを確認する
ログ分析で最初に確認するのは、ログが正しく読めているかです。cscli metrics で、取り込みとパースの件数を確認できます。
sudo cscli metrics取り込みの項目では、ファイルごとに読み込んだ行数、パースできた行数、できなかった行数が表示されます（表示の形式はバージョンにより異なります）。パースできなかった行が大半を占める場合は、ログの形式とパーサーが合っていません。Nginx の log_format を独自に変えているときによく起きます。
特定の行がどう解釈されるかは cscli explain で確かめられます。
# 1 行を指定して確認
sudo cscli explain --type nginx \
--log '203.0.113.5 - - [22/Oct/2026:10:00:00 +0900] "POST /wp-login.php HTTP/1.1" 200 1234 "-" "Mozilla/5.0"'
# ファイルを指定して確認
sudo cscli explain --type nginx --file /var/log/nginx/access.log出力には、どのパーサーを通過したか、どのシナリオに投入されたかが段階ごとに表示されます。途中で処理が止まっていれば、その段階が原因です。
アラートを読み解く
検知された内容は cscli alerts で確認します。
# 最近のアラート一覧
sudo cscli alerts list
# 特定の IP やシナリオで絞り込む
sudo cscli alerts list --ip 203.0.113.5
sudo cscli alerts list --scenario crowdsecurity/http-probing
# 1 件の詳細（どのログ行が根拠になったか）
sudo cscli alerts inspect -d 123一覧では、シナリオ名、送信元 IP、国や AS などの情報、件数が表示されます。ここで見るべきは「どのシナリオが多いか」と「同じ IP や同じ AS が繰り返し出ていないか」です。たとえば WordPress サイトなら、wp-login.php への総当たりや、存在しないプラグインのファイルを探るスキャンが上位に来ることがよくあります。
inspect の詳細表示では、アラートの根拠になったログ行（イベント）を確認できます。誤検知かどうかの判断は、シナリオ名だけで行わず、実際のリクエスト内容を見て行ってください。
集計したい場合は JSON 形式で出力し、jq などで加工すると便利です。
sudo cscli alerts list -o json | jq -r '.[].scenario' | sort | uniq -c | sort -rn過去のログをまとめて分析する
CrowdSec には、既存のログファイルをさかのぼって読み込み、シナリオに当てはまる振る舞いを洗い出すモード（フォレンジックモード）があります。過去に不審なアクセスがなかったかを調べるときに使えます。
sudo crowdsec -c /etc/crowdsec/config.yaml \
-dsn file:///var/log/nginx/access.log.1 -type nginx -no-api結果は cscli alerts list で確認します。設定によっては本番と同じデータベースにアラートが記録されるため、本番サーバーで実行する前に、ログを検証用の環境へコピーして試すのが安全です。オプションの細部はバージョンで変わることがあるので、公式ドキュメントで最新の書き方を確認してください。
誤検知に対応する
社内からの監視、自分たちの外形監視サービス、検索エンジンのクローラーなどが検知されることがあります。対応の流れは次のとおりです。
cscli alerts inspectで根拠になったログ行を確認し、本当に正当な通信かを判断します。- 遮断の判定が出ていれば、
cscli decisions listで確認し、cscli decisions delete --ipで解除します。 - 今後も検知させたくない送信元は、ホワイトリスト（許可リスト）に登録します。
ホワイトリストは、パーサーの一種として YAML ファイルで定義する方法が長く使われてきました。新しいバージョンでは cscli から許可リストを管理する機能も加わっています。どちらが使えるかはバージョンによるため、導入しているバージョンのドキュメントで確認してください。範囲を広く取りすぎると、本当の攻撃も見逃すことになります。登録は必要最小限の IP や範囲にとどめます。
分析結果を運用に生かす
ログ分析で傾向が見えてきたら、遮断用のコンポーネント（nftables や iptables 向けのファイアウォール用、Nginx 用、WordPress プラグインとして提供されているものなど）を導入して、判定を実際の遮断につなげられます。いきなり本番で有効にせず、まずは判定の内容を数日確認し、誤検知の傾向をつかんでから進めてください。設定ファイルを変更する前には、/etc/crowdsec/ 一式のバックアップを取っておくと元に戻せます。
まとめ
- CrowdSec は「取り込み → パース → シナリオ → 判定 → 遮断」の順に処理し、ログ分析で見るのは主に前半の 3 段階です。
- 取り込み設定の
labels.typeがパーサーの選択を決め、合っていないとパースされません。プロキシ配下では実 IP をログに残す設定を先に行います。 cscli metricsでパースの成否、cscli explainで 1 行ごとの処理経路、cscli alerts listとinspectで検知内容と根拠のログ行を確認できます。- 過去ログはフォレンジックモードで分析できますが、検証用の環境で試すのが安全です。
- 誤検知は根拠のログ行を確認してから判定を解除し、許可リストへの登録は最小限にとどめます。