Linux環境へのCrowdSec導入ガイド：分散型IPSを構築してブルートフォースやWeb攻撃を遮断する

先週火曜日の午前2時14分、本番ノード3台でメモリ警告が一斉に発令され、PagerDutyからのアラートで叩き起こされました。システムのRAM使用率は92%を超え、毎秒およそ4,000リクエストの負荷によってNginxのワーカープロセスがスラッシングを起こしていました。/var/log/auth.logとNginxのアクセスログを詳しく解析したところ、典型的な「Low and Slow（低速かつ長期）」型の協調スキャン攻撃を受けていることが判明しました。

攻撃者は/api/v1/auth/loginのエンドポイントに対してクレデンシャルスタッフィング攻撃を仕掛けると同時に、ポート22番のSSHをプローブしていました。一握りのデータセンターIPから大量のトラフィックを送りつけるのではなく、約8,500ものレジデンシャルプロキシをローテーションさせながらアクセスしていたのです。各IPは5分間にたった1回しかリクエストを送ってこないため、標準的なレート制限の閾値を容易にすり抜けていました。

Table of Contents

アプローチ比較：孤立した防御 vs 協調型脅威インテリジェンス

何千ものローテーションするレジデンシャルアドレスから攻撃を受けると、単体で動作するセキュリティツールでは太刀打ちできません。従来のログ解析ツールと最新の協調型侵入防止システム（IPS）を比較することで、根本的な課題が浮き彫りになります。

1. 単体型のログ監視ツール（Fail2Banなど）

Fail2Banのようなツールは、正規表現を用いてローカルのログファイルを監視します。特定のIPが「10分以内に5回のSSH接続失敗」といったあらかじめ設定された閾値を超えると、iptablesやnftablesに一時的なドロップルールを追加します。この仕組みは、単一のVPSインスタンスから実行されるノイズの多いスクリプト攻撃には非常に効果的です。

しかし、分散型ボットネットはこのロジックを完全に回避してしまいます。攻撃者が10,000台のノードを協調させ、各ノードから1日に1回しかログイン試行を行わない場合、Fail2Banの閾値を超えることはありません。サーバーは孤立した状態で攻撃を受け止めるしかなく、その同一IPがわずか数分前に他の500台のサーバーを標的にしていたとしても検知できないのです。

2. 集中型のエンタープライズSIEM / クラウドWAF

クラウドエッジプロバイダー（CloudflareやAWS WAFなど）やマネージドSIEMは、膨大なグローバル脅威フィードを保持しています。これらはHTTPトラフィックがオリジンサーバーに到達する前に適切にフィルタリングしてくれます。しかし、トレードオフも存在します。トラフィックが急増するとリクエストごとの従量課金が跳ね上がり、またエッジプロキシではカーネルレベルで動作するSSH、SFTP、独自のソケットリスナーといった生のTCPサービスを保護することができません。

3. 協調型の検知と対処（CrowdSec）

CrowdSecはセキュリティの役割を「検知（Security Engine）」と「適用（Bouncers）」の2つに疎結合化しています。コアデーモンはGoのゴルーチンと宣言型YAMLシナリオを使用してローカルログを解析します。サーバーが悪意あるアクティビティを検出すると、ローカルでIPを即座にブロックし、同時に匿名化されたアラートをCrowdSecの中央コンセンサスエンジンに送信します。

この中央エンジンは、180カ国以上・数万台のアクティブノードから送られるシグナルを処理します。コンセンサスアルゴリズムによってレポートを検証し、誤検知を排除した上で、精査されたブロックリストをすべての参加ノードへと配信します。ネットワーク内の他のサーバーが事前に攻撃者を検知しているため、攻撃者があなたのスタックに触れる前に、Linuxホストが不正なパケットを水際で破棄できるのです。

メリット・デメリット：本番環境におけるCrowdSecの評価

どのようなアーキテクチャの選択にもトレードオフが伴います。本番環境でCrowdSecを運用する際の主な評価ポイントは以下の通りです。

メリット

コミュニティ主導の脅威インテリジェンス： 手動でリストを管理したり、高価な商用脅威フィードを購読したりすることなく、50,000件以上の既知の悪意あるアクティブIPに対するプロアクティブな防御が可能になります。
疎結合アーキテクチャ： ログ解析とファイアウォールによる遮断処理が完全に分離されています。アプリケーションサーバーでログを解析してエッジルーター側でパケットをドロップさせたり、NginxやTraefikのバウンサーを介して自動的にCAPTCHAを表示させたりといった柔軟な構成が可能です。
極めて軽量なリソース消費： Go言語で開発されたCrowdSecデーモンは、通常40〜60 MB程度のRAMしか消費せず、一般的なトラフィック下でのCPU使用率も1%未満です。JavaベースのSIEMエージェントやPython製スクレイパーと比べても遥かに軽量です。
拡張性の高いHubエコシステム： Nginx、SSH、Postfix、Docker、PostgreSQLなどに対応したコミュニティメンテナンスのパーサーやシナリオを、cscliパッケージマネージャーを使って数秒で導入できます。

デメリット

複数コンポーネントのセットアップが必要： コアエンジンは攻撃を「検知」するだけであり、単体ではパケットの遮断を行いません。実際にトラフィックをドロップするには、別途レメディエーションバウンサー（nftablesバウンサーなど）をインストールする必要があります。この設定を怠るとサーバーが無防備なままになります。
アウトバウンド接続が必須： ローカルのログ解析やキャッシュされたブロックリストの適用はオフラインでも機能しますが、コミュニティのコンセンサスアップデートを取得するには、CrowdSecの中央APIに対するアウトバウンドのHTTPS通信（ポート443）が必要となります。

推奨セットアップ：アーキテクチャと構成

堅牢なLinux踏み台サーバーや単一ノードの本番環境では、以下のスタック構成を推奨します。

CrowdSec Security Engine： systemdジャーナル、SSHの認証ログ、Webサーバー（Nginx/Caddy）のログを読み取り、振る舞いパターンを監視・追跡します。
ファイアウォール・レメディエーションバウンサー（nftables / iptables）： ポート8080経由でLocal API（LAPI）と通信し、Linuxカーネルのパケットフィルターにドロップルールを直接書き込みます。
CrowdSec Hubコレクション： crowdsecurity/linux、crowdsecurity/sshd、crowdsecurity/nginxなどの事前パッケージ化された検知プロファイル群です。

新しいセキュリティツールをパブリックインターフェースに公開する前に、まずは管理者認証情報を確実に保護してください。私自身、インシデント対応中や新しいノードを立ち上げる際は、toolcraft.app/ja/tools/security/password-generator のブラウザベースのパスワード生成ツールを使って、強度の高いrootおよびサービス用パスワードを生成しています。通信を介さずクライアント側だけで完結して処理されるため安全です。基礎的なアクセス権限を固めた上で、自動防御の構成に進みましょう。

導入手順：Linuxへのステップバイステップ展開

以下の手順は、Ubuntu 22.04 / 24.04 および Debian 12 を対象としています。

ステップ1：CrowdSecリポジトリの登録とエンジンのインストール

CrowdSec公式のセットアップスクリプトを使用してリポジトリを追加し、コアデーモンをインストールします。

# 公式リポジトリパッケージのダウンロードと登録
curl -s https://install.crowdsec.net | sudo bash

# CrowdSecセキュリティエンジンのインストール
sudo apt-get update
sudo apt-get install -y crowdsec

インストール中、エンジンはOpenSSHやNginxなどの稼働中サービスを/var/logから自動スキャンします。そして、初期のログ取得設定を/etc/crowdsec/acquis.yaml内に自動生成します。

ステップ2：ログ取得とコレクションの確認

CrowdSecが検出したサービスを確認し、インストール済みの検知シナリオを一覧表示します。

# 検出されたログソースとパーサーのスループットを確認
sudo cscli metrics

# 有効なコレクションの一覧を確認
sudo cscli collections list

Nginxなどのリバースプロキシを運用している場合は、CrowdSec Hubから対応するシナリオコレクションを直接インストールします。

# 標準的なNginxおよびHTTP保護シナリオのインストール
sudo cscli collections install crowdsecurity/nginx
sudo cscli collections install crowdsecurity/http-cve

# 新しいシナリオを適用するためにCrowdSecをリロード
sudo systemctl reload crowdsec

ステップ3：ファイアウォール・レメディエーションバウンサーのインストール

コアエンジンは攻撃を検知するだけです。実際にブロックを実行するにはレメディエーションコンポーネントが必要です。nftablesを採用している最新のLinuxディストリビューションでは、ネイティブのバウンサーパッケージをインストールします。

# ファイアウォール・レメディエーションバウンサーのインストール
sudo apt-get install -y crowdsec-firewall-bouncer-nftables

バウンサーがLocal API（LAPI）に正常に登録されたことを確認します。

# 登録済みバウンサーの一覧を表示
sudo cscli bouncers list

出力結果にcrowdsec-firewall-bouncer-nftablesが表示され、有効なAPIキーとアクティブなステータスが確認できれば成功です。

ステップ4：アクティブな防御決定（Decisions）のテストと確認

CrowdSecは起動直後にコミュニティのコンセンサスブロックリストを取得します。ローカルの判定データベースを確認し、現在有効なブロック一覧をチェックしてみましょう。

# 現在有効なBANおよびコミュニティコンセンサスによるブロック一覧を表示
sudo cscli decisions list

実際の環境でローカル遮断が機能しているかを検証するため、RFC 5737で定義されているテスト用IPアドレスに対して一時的な手動BANをシミュレートします。

# テスト用IPに対して15分間のテストBANを適用
sudo cscli decisions add --ip 192.0.2.1 --duration 15m --reason "手動テストBAN"

# ルールが登録されたことを確認
sudo cscli decisions list --ip 192.0.2.1

# テスト用の判定を削除
sudo cscli decisions delete --ip 192.0.2.1

ステップ5：Central Consoleへの登録

サーバー群全体を一元的に可視化し、単一のダッシュボードから受信攻撃を監視するために、ノードをCrowdSec Console（個人利用は無料）に連携させます。

# コンソールの登録トークンを使用してインスタンスを登録
sudo cscli console enroll <登録キー>

# 同期を確立するためにサービスを再起動
sudo systemctl restart crowdsec

あの深夜2時の緊急対応時、CrowdSecを導入したことで20分も経たずに事態は沈静化しました。nftablesバウンサーが稼働した瞬間、3,200件を超える不正なレジデンシャルIPからの接続がLinuxカーネルのパケットフィルターレベルで直接破棄されました。98%に達していたNginxワーカーのCPU負荷は一気に4%まで急減し、メモリも解放され、正規のユーザーへのサービス提供を何事もなかったかのように継続することができました。