SSHログインの失敗が認証ログに積み重なり、スキャナーがWebサイトを巡回して露出した管理者用パスを探る——CrowdSecはこうしたログソースやHTTPリクエストを読み取り、どのアドレスが不審な挙動をしているかを判断し、サービスの前段に配置された別の対処コンポーネントにブロック指示を渡します。ユーザーが目撃した情報をプロジェクトに報告すると、それがコミュニティのブロックリストとしてキュレーションされ、あらゆる導入環境で取得できるようになります。バージョン1.8.0は8月31日にリリースされました。
今回の大きな変更点は、HTTPを検査するエンジンの半分を担うCrowdSec WAFにボット検知機能が加わったことです。これを有効にすると、クライアントはサイトに到達する前にチャレンジとフィンガープリンティングのページを通過することになります。CrowdSecはこのチャレンジを採点し、設定したルールに照らしてフィンガープリントを照合したうえで、そのクライアントが正当なものかどうかを判定します。
一部の正規訪問者がはじかれる可能性
このチャレンジにはSSE4.1と書き込み可能かつ実行可能なメモリ領域が必要なため、古いクライアントやハードニングされたクライアントでは解決できません。Cookieを無効にしている訪問者には、何が問題だったのかを伝える明示的なエラーメッセージが表示されるようになりました。この機能は、ボットだけでなくすべての訪問者の前に立ちはだかるページであるため、全面的に有効化する前に実際のユーザー層を対象にテストしておくべきでしょう。
ログ取り込みを乗っ取る2つの経路を封鎖
今回のリリースでは、ログを取り込む部分であるHTTPおよびk8s-auditの各データソースに存在した2件のサービス拒否(DoS)脆弱性も修正されています。HTTP収集データソースには、展開後のボディサイズに上限がなく、送信者側が指定するContent-Lengthをそのまま信用してしまう問題がありました。Kubernetes監査Webhookも、リクエストボディを無制限に読み込んでいました。いずれも取り込み側に存在する問題であり、つまり攻撃を監視しているはずのコンポーネント自体が、攻撃対象になり得るということです。CrowdSecにHTTP経由、あるいはk8s監査Webhook経由でログを送っている場合、ボットに関心があるかどうかにかかわらず、このリリースのこの部分は自分に関係すると考えるべきです。
専用のKubernetesデータソースが新設され、apiserverから直接ログを取得できるようになったことで、クラスター運用者にとって収集作業の一手間が省けます。式言語に追加された新しいHTTPヘルパーにより、パーサーやシナリオが判定処理の最中に外部サービスへ問い合わせできるようになりました。ローカルAPIの決定情報ストリームエンドポイントには性能面の改善が加えられており、これは1つのAPIに対して多数の対処コンポーネントを運用しているユーザーにとって特に意味のある変更です。
ボット検知機能は、有効化するまではオフのままです。一方、2件のデータソース修正はボット検知の有効/無効にかかわらず適用されるため、こちらこそが今回のリリースを適用すべき強い理由と言えるでしょう。
CrowdSecはGitHubから無償で入手できます。
翻訳元: https://www.helpnetsecurity.com/2026/09/01/crowdsec-1-8-0-bot-detection/
