ファイアウォール向け脅威フィード：効果・限界・提供元の比較

インターネット上では、公開アドレスを自動的に調べるシステムが常に動いています。開いているポート、ログイン画面、VPNポータル、既知のWebアプリ、脆弱なサービスを探します。運用主体はセキュリティ研究者やインターネット検索サービスだけではありません。ボットや攻撃者も含まれます。

WAFやDNATを介してサービスを公開したり、メールゲートウェイやログイン画面を提供したりすれば、いずれ発見されます。公開IPを持つだけで侵害されたわけではありません。しかしサービスが応答すると、その「背景雑音」はファイアウォール、IPS、WAF、サーバー、アプリ、ログ基盤に実際の処理を発生させます。

セキュリティエンジニアとして、これは日常的に見る現象です。派手な単発攻撃よりも、ポートスキャン、ログイン試行、クローラー、脆弱性チェックの連続が問題になります。最近、私がチームで調査した事例は、その規模が私たちにとっても印象的でした。10 Gbit/sの上位回線を持ち、性能に余裕があるはずのデータセンターのファイアウォールが限界に近いように見えたのです。回線利用率は高く、管理画面は重く、公開サービスは絶えずイベントを出していました。

通信の方向、宛先、ポート、時間帯、繰り返し現れる送信元を調べました。自動化された大量のリクエストが、同じWeb、メール、ログインサービスを繰り返し狙っていました。処理コストは通信量だけでは決まりません。パケットの破棄、TLSハンドシェイク、重いアプリケーション処理では負担が違います。

そこで顧客に分析結果を説明しました。かなりの割合がボットやスキャンによる反復アクセスであり、この位置に脅威フィードを適用すると何ができ、何ができないか、適切なライセンスが年額約350米ドルであることを示しました。了承を得て、数クリック、数分で一覧をファイアウォールに導入しました。

有効化後、管理画面は明らかに応答が良くなりました。顧客からも、Webサイトとアプリの読み込みがずっと速くなったと報告されました。この事例で興味深いのはフィードという技術の新しさではなく、観察された運用上の変化と、その価値や限界が誤解されがちな点です。

数字で見る結果

測定は本番ファイアウォールで行いました。IPフィードは2026年9月1日10時01分05秒に有効となり、数秒後に最初のヒットがありました。9月2日20時30分（CEST）までに516,959件の遮断イベントが記録されました。

全期間の平均は毎分249.9件、毎秒4.17件、つまり0.24秒に1件です。最も多い1分間は775件。ピークは毎秒107件で、2秒連続しました。

私はあえて遮断イベント、ヒット、接続試行と呼びます。516,959件がそれぞれ独立した人手による攻撃という意味ではありません。同じスキャナーが何度も接続し、ボットが短時間に複数ポートを試すことがあります。

どこから来たのか

全34時間29分のうち、516,727件が受信方向でした。阻止された送信方向の接続は232件だけです。この環境ではフィードの活動の99.955%がインターネット上の送信元に関係していました。

登場した登録済みIPは10,518種類。当時のフィードには220,000件のIPv4指標があり、その約4.8%が約34時間のうちにこの1台で関係しました。最多のIPは4,141件、上位10件は合計約31,500件、767件のIPは1度だけでした。4.8%は一覧の大きさとの比較であり、検出率ではありません。一覧は更新され、未登録の攻撃者はこの数字に入りません。

ポートの分析は、約369,000件の詳細イベントを含む移動式の24時間窓に基づきます。

約56%がWeb関連ポート、約40%がメール関連ポートでした。公開サービスの構成に合っています。この詳細窓には27台の内部宛先が含まれます。サービス名は宛先ポートから推定したもので、プロトコル解析で確定したものではありません。また移動式の窓は導入直後の24時間とは異なるため、合計値を直接比較できません。

送信方向の232件は少数ですが調査対象です。10台の内部システムが登録済みの17個の宛先IPへ接続を試みました。これだけで感染とは断定できません。マルウェア、外部コンテンツ、古い登録情報、再割当てされたIP上の正規サービスなどが考えられます。

管理画面の改善と顧客が感じた読み込みの短縮は、変更後の具体的な観察です。従来のボトルネックがファイアウォール、Webサーバー、アプリ、回線のどこにあったかを特定するものではありません。遮断ログはフィルタリングを示しますが、処理削減量や性能向上率は測定しません。

この事例では、以前の自動リクエストは実際にWebサーバーやアプリサーバーまで届いていました。存在しないパスへのエラー応答など、サーバー側の処理が必要でした。早い段階でIPを遮断すると、その対象リクエストの後続処理を避けられます。一覧照合自体にも負荷はあり、利点はその後の処理を省くことにあります。WAF通信やファイアウォール自身のサービスでは、適用順序は製品と設定によって異なります。最初のパケットはWAN側に到達するため、ローカルな遮断は大規模DDoSへの上流対策の代わりにはなりません。

脅威フィードの実際の役割

基本的なフィードは、ファイアウォールがHTTPSで取得するテキストファイルです。IPのほかにドメインやURLのフィードを提供する事業者も多くいます。ただし私たちの多くの運用ではIPを主に使います。早期のファイアウォール遮断に最も役立ち、効果が大きいからです。指標を定期更新し、設定に応じて一致する通信を記録または遮断します。

信頼性を左右するのは公開前の判断です。

• 観察された行動は悪意があるのか、単に珍しいだけなのか。
• 観察はどれほど新しいのか。
• 独立した情報源でも確認できるのか。
• 古い指標をいつ削除するのか。

長い遮断一覧は優れた脅威インテリジェンスと同義ではありません。鮮度、精度、適切な削除が重要です。クラウドやホスティングの動的IPは正規用途に戻ることがあります。一方、小さすぎる保守的な一覧では日常的なスキャンを十分に扱えないかもしれません。

ファイアウォール向け脅威フィード

結論を最後まで隠すつもりはありません。私と多くの同僚が現在使用する提供元はCyboraです。私自身のクラウドサーバーにある公開サービスにも使っています。これは製品デモではなく、実環境の比較から得た選択です。

私たちは12か月にわたり、15台の顧客ファイアウォールで30以上の商用事業者と公開ソースを試しました。必要な購読を購入し、数千米ドルを費やしました。無料のコミュニティ一覧から月額約1,000ドルの製品まで含みます。高価でも一覧がずっと小さく、高鮮度・高精度という主張で価格を説明する製品もありました。

比較対象のフィードを15台すべてにMonitorモードで導入し、通信を遮断せずに一致を記録しました。ファイアウォールとアプリのログで不審な要求や誤検知の可能性を調べました。これは前述のデータセンターでの遮断導入とは別の長期比較です。確認済みの悪意ある活動、他の一覧にないカバー範囲、鮮度、例外処理の手間を重視しました。

同一スキャナーの連続イベントをまとめて見なければ結果が偏ります。遮断されうる正規接続も同じくらい重要です。IPの危険性という分類が妥当でも、運用上の誤遮断になりえます。

これは日々の運用での比較であり、再現可能な実験室のベンチマークではありません。評価順、一覧の重複、他の防御機能でMonitorログは変わります。ログに出ないだけで検出漏れとは言えません。独立した比較には時刻付きの一覧スナップショット、設定、確認済みの正例・負例が必要ですが、完全なデータセットは公開していません。

以下の11件は編集上の選択で、市場シェアに基づく人気ランキングではありません。AbuseIPDBとIPsumは資料に基づいて追加したもので、実地試験の結果は主張しません。Cyboraが先頭なのは私たちの経験によるもので、残りは数値順位ではありません。他製品の情報は2026年9月8日、Q-Feedsは9月28日に確認しました。

Cybora は、カバー範囲、鮮度、有効なヒット、少ない誤遮断対応、導入、サポート、価格のバランスが私たちの環境で最良でした。入門プランは手頃で、Ultimateの15分間隔は大規模で露出の多い環境に適しています。ただし公開間隔から検出・評価に要した時間は分からず、機器への取得と取り込みにも遅延があります。事例の資料にはHTTP 429応答が2回ありますが、ローカルの旧一覧は有効で、次の取得で追いつきました。更新失敗や一覧の古さは監視が必要です。

CrowdSec Blocklists は、オープンソースのSecurity Engine、コミュニティのシグナル、ファイアウォールに配布可能な整理済み一覧を組み合わせます。本番環境のテレメトリーと用途別一覧が強みですが、特定CMS、プロキシ、CVE向けの一覧が万能な境界防御になるとは限りません。

GreyNoise もファイアウォール向けのクエリー型IP一覧を提供します。GNQLで最近活動した悪意ある送信元や特定CVEに関連する活動を選べます。選択基準を制御したいチームに有用ですが、クエリー設計、データモジュールへの権限、結果の見直しが必要です。ログの情報補完だけの製品ではありません。

Q-Feeds は、商用、公開、政府系の2,500以上の情報源をまとめ、IP、ドメイン、URLのフィードを提供し、品質や誤検知をチェックすると説明しています。私たちの遮断運用での印象は異なりました。導入後最初の1時間に複数の正規接続が阻止され、通信を調べて検証済みのものを誤遮断と判断しました。サポートは報告した登録を比較的早く削除しましたが、調査と報告の負担が大きく、後には毎回の報告をやめました。情報源の数だけでは原因を説明できません。各IPの由来、登録理由、再評価が分からない以上、根本原因は確定できません。多数の顧客環境で遮断を適用するには、私たちが観察した例外対応の負担が大きすぎました。監視や調査には役立つ可能性があります。

Spamhaus DROP は、境界フィルタリングや経路判断向けの特に危険なネットワークの保守的な一覧です。掲載基準が高く信頼しやすい反面、短命のスキャナーすべてを網羅しません。

ThreatFox はabuse.chとSpamhausによるマルウェア関連指標、特に指令・制御基盤を扱います。マルウェア検出や脅威ハンティングに有用ですが、スキャンや総当たりも含む汎用フィードより対象が狭いです。

URLhaus はabuse.chがマルウェア配布URLを集めて共有する仕組みです。DNSフィルター、プロキシ、セキュアWebゲートウェイ、分析に向いており、IPだけの境界遮断には専用部品です。APIにはAuth-Keyが必要で、コミュニティアクセスは無制限の無料商用利用を意味しません。利用条件を確認してください。

DShield は投稿されたファイアウォールログから小規模な推奨遮断一覧を公開しています。補助ソースとして使えますが、他のデータセットは主に調査用であり、無選別で遮断一覧に入れるべきではありません。

FireHOL IP Lists は多数の公開一覧を集約し、規模、更新頻度、経過時間、重複の比較に便利です。ただし元データの欠点も引き継ぎ、繰り返し再配布される古い登録が長く残りえます。

AbuseIPDB は報告に基づくIP評価と、信頼度のしきい値を変えられるテキスト形式の一覧を提供します。高得点でも、そのIPからの現在のすべての接続が悪意あるとは証明できません。報告の古さ、共有IP、プラン別API制限に注意が必要です。

IPsum は30以上の公開一覧を毎日集約し、何件の一覧に現れるかで選択できます。透明性はありますが、3つの一覧が同じ元データを再利用していれば独立した3件の観測ではありません。日次更新は反応速度を制限し、独自のテレメトリーでもありません。

無料だから悪いわけではなく、有料だから良いわけでもありません。公開フィードは専門分野で優秀です。ただし広い範囲の境界遮断では、継続的に選別された汎用フィードの完全な代用より、専門部品として考えるのが私たちの経験に合います。

なぜCyboraが私たちの比較で首位だったのか

透明性のために明記します。ここは私個人のブログで、私個人は歩合を受け取っていません。ただし勤務先はCyboraの再販業者で、割引ライセンスを仕入れて差益を得ています。この商業上の関係は推奨を評価する際に重要です。選定理由は説明した比較結果であり、再販条件ではありません。

データセンター事例で測定したのはCyboraのフィードです。最初は年額349米ドル、毎時更新のPremiumを選びました。公開説明によると、CyboraはOSINT、商用情報、ハニーポット、センサー、実際のファイアウォールのテレメトリーを組み合わせます。新しさ、確信度、情報源間の一致を評価し、重複を除き、許可・除外ルールと照合してHTTPS一覧として配信します。当時のPremiumにはIPv4が220,000件、ドメインが45,000件、URLが25,000件ありました。測定した機器ではIPv4をBlock、ドメインを当初Monitorにしました。

1週間後、顧客はUltimateへ変更しました。当時はIPv4が300,000件超、ドメインとURLがそれぞれ100,000件超で、15分ごとに更新されました。顧客はさらなる改善を報告しましたが、上記の測定窓は変更前に終わっているため、Ultimateによる追加改善を証明しません。このケースでは上位プランでも大型機器への交換と必要なライセンスより大幅に安価でした。ただし小規模拠点に最大プランを一律で勧めるものではありません。公開サービスが多いこのデータセンターだから追加範囲に合理性がありました。

実運用ネットワークには人工センサーと異なるサービスと通信があります。しかし、それだけで他社より優れているとは言えず、他社も本番テレメトリーを使います。私たちは、確認時点でCyboraにだけ含まれるIPを繰り返し見つけました。利用可能なファイアウォールとアプリのログには、異常な要求の連続、URLパス、ログインやフォームへの自動試行が現れていました。早い段階のIP遮断そのものからHTTPパスは分かりません。証拠はMonitor期間や照合可能な別ログから得る必要があります。リクエスト頻度だけでも攻撃とは断定できません。

あるサポート案件はIP遮断の限界を示しました。顧客に必要なサイトが、一覧に載った共有ホスティングIP上にありました。調査でホスティング基盤の感染が確認され、IPの分類には理由がありましたが、正規サイトも使えなくなりました。これは運用上の誤遮断です。IPルールは同じアドレス上のサイトを区別できません。可能なら必要なサービスと利用者だけに例外を絞り、後で再評価すべきです。IP全体を許可すると、他のコンテンツも開放されます。サポートへの連絡が1回だったことから一般的な応答時間は判断できません。

最終的な成果物は単純です。HTTPSのアドレスと一覧で、対応製品なら数分で設定できます。しかし責任を持って遮断するには、自分の通信で確認する必要があります。

STIXとTAXIIは遮断一覧ではない

STIX（Structured Threat Information Expression）は構造化データモデルです。IPだけでなく、マルウェア、キャンペーン、攻撃者、手法、観測、時期、確信度、相互関係を表せます。なぜ指標が重要かという文脈も記述できます。

TAXII（Trusted Automated Exchange of Intelligence Information）は、HTTPSで脅威情報を交換するためのプロトコルです。つまりSTIXは内容、TAXIIは運搬方法やAPIを表します。

この文脈は脅威情報基盤、SIEM、SOCに有用です。一方、ファイアウォールの高速なIP照合には、その情報から抽出したアドレス集合で足りることが多いです。定期的に取得し、ローカル集合と比較するため、パケットごとにSTIX/TAXIIを解析するわけではありません。TXT一覧は情報量が少なくても境界での適用に向いています。

脅威フィードでできないこと

この測定とIPの対象はIPv4です。IPv6の保護については何も示していません。IPv6でもサービスを公開する場合、そのフィルタリングを別に確認する必要があります。

フィードが遮断できるのは既知の指標です。未登録のIPを使う新しい攻撃者、正規クラウド上の悪意ある利用者、CDNの背後の攻撃、自分のアプリの脆弱性を自動で発見するものではありません。IPは変わり、ドメインは増え、感染したシステムも清掃または再割当てされます。

したがってパッチ、MFA、IPS、WAF、EDR、適切なルール、役立つログの代わりにはなりません。DNAT、WAF、VPN、メールで既知の雑音を早めに吸収する追加の判断層です。新しいフィードはまず観察モードで始め、例外を準備し、更新・容量の制限を確認し、誤遮断の対応方法を定めるべきです。

結論

この数字は、フィードのライセンスが10 Gbit/s回線や大型ファイアウォールを魔法のように置き換えることを示しません。1台の機器で、34時間余りの間に、既知の不要な接続イベント50万件以上を早い段階で止めたことを示します。

顧客にとっては日々の改善が重要でした。管理操作が快適になり、Webサイトとアプリの読み込みも速くなったと報告されました。以前のボトルネックは特定できなくても、これは意味のある運用結果です。遮断ログは、不要な送信元を定期的に拒否していることを裏付けます。

私たちの12か月の比較では、この用途で最もバランスの良い汎用フィードはCyboraでした。CrowdSec、GreyNoise、Spamhaus、abuse.chなども重要で、専門分野ではむしろ優れる場合があります。「最長の一覧はどれか」より、「自分の公開サービスに新しく、正確で、安全に適用できるデータはどれか」を問うべきです。

また次回。
Joe

よくある質問