
ファイアウォール向け脅威フィード:効果・限界・提供元の比較
Security Network目次
インターネット上では、公開アドレスを自動的に調べるシステムが常に動いています。開いているポート、ログイン画面、VPNポータル、既知のWebアプリ、脆弱なサービスを探します。運用主体はセキュリティ研究者やインターネット検索サービスだけではありません。ボットや攻撃者も含まれます。
WAFやDNATを介してサービスを公開したり、メールゲートウェイやログイン画面を提供したりすれば、いずれ発見されます。公開IPを持つだけで侵害されたわけではありません。しかしサービスが応答すると、その「背景雑音」はファイアウォール、IPS、WAF、サーバー、アプリ、ログ基盤に実際の処理を発生させます。
セキュリティエンジニアとして、これは日常的に見る現象です。派手な単発攻撃よりも、ポートスキャン、ログイン試行、クローラー、脆弱性チェックの連続が問題になります。最近、私がチームで調査した事例は、その規模が私たちにとっても印象的でした。10 Gbit/sの上位回線を持ち、性能に余裕があるはずのデータセンターのファイアウォールが限界に近いように見えたのです。回線利用率は高く、管理画面は重く、公開サービスは絶えずイベントを出していました。
通信の方向、宛先、ポート、時間帯、繰り返し現れる送信元を調べました。自動化された大量のリクエストが、同じWeb、メール、ログインサービスを繰り返し狙っていました。処理コストは通信量だけでは決まりません。パケットの破棄、TLSハンドシェイク、重いアプリケーション処理では負担が違います。
そこで顧客に分析結果を説明しました。かなりの割合がボットやスキャンによる反復アクセスであり、この位置に脅威フィードを適用すると何ができ、何ができないか、適切なライセンスが年額約350米ドルであることを示しました。了承を得て、数クリック、数分で一覧をファイアウォールに導入しました。
有効化後、管理画面は明らかに応答が良くなりました。顧客からも、Webサイトとアプリの読み込みがずっと速くなったと報告されました。この事例で興味深いのはフィードという技術の新しさではなく、観察された運用上の変化と、その価値や限界が誤解されがちな点です。
優れた脅威フィードの最大の価値は、遮断したIPの数ではなく、その先のシステムで発生しなくなった処理にあります。
数字で見る結果
測定は本番ファイアウォールで行いました。IPフィードは2026年9月1日10時01分05秒に有効となり、数秒後に最初のヒットがありました。9月2日20時30分(CEST)までに516,959件の遮断イベントが記録されました。
| 有効化からの経過 | 遮断イベント |
|---|---|
| 5分 | 1,117 |
| 15分 | 3,490 |
| 1時間 | 12,020 |
| 12時間 | 177,702 |
| 24時間 | 350,686 |
全期間の平均は毎分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時間窓に基づきます。
| サービス | イベント | 概算比率 |
|---|---|---|
| HTTPS、TCP 443 | 157,819 | 42.8% |
| SMTPS、TCP 465 | 119,233 | 32.4% |
| HTTP、TCP 80 | 48,911 | 13.3% |
| メール送信、TCP 587 | 16,771 | 4.6% |
| SMTP、TCP 25 | 10,723 | 2.9% |
| DNS、UDP 53 | 4,919 | 1.3% |
| Ethereum/P2P、TCP 30303 | 2,660 | 0.7% |
| SSH、TCP 22 | 229 | 0.06% |
イベントの約56%がWebポート、40%がメールポートを対象とし、詳細窓には27台の内部宛先が含まれました。サービス名はポートからの推定で、プロトコル解析による確認ではありません。この移動式24時間窓は導入直後の24時間とは異なり、合計を直接比較できません。
送信方向の232件は10台の内部システムと17個の登録済み宛先に関係します。感染の証明ではありませんが、マルウェア、外部コンテンツ、古い登録、再割当てIP上の正規サービスなどを調べるべきです。
変更後、管理画面は軽くなり、顧客も読み込みの短縮を報告しました。以前のボトルネックがファイアウォール、サーバー、アプリ、回線のどこにあったかは特定できません。ログが示すのはフィルタリングであり、節約した資源や性能向上率ではありません。
それまでは自動リクエストがWeb・アプリサーバーに届き、存在しないパスにも応答が必要でした。早期のIP遮断が後続処理を省きました。一覧照合にも負荷はあり、利点はその後の処理を避けることです。適用順は製品と設定によります。最初のパケットはWANへ届くため、大規模DDoSには上流対策が必要です。
脅威フィードはファイアウォールの性能を増やしません。既知の攻撃ノイズにその性能を浪費させないのです。
脅威フィードの実際の役割
基本的なフィードは、ファイアウォールがHTTPSで取得するテキストファイルです。IPのほかにドメインやURLのフィードを提供する事業者も多くいます。ただし私たちの多くの運用ではIPを主に使います。早期のファイアウォール遮断に最も役立ち、効果が大きいからです。指標を定期更新し、設定に応じて一致する通信を記録または遮断します。
信頼性を左右するのは公開前の判断です。
- 観察された行動は悪意があるのか、単に珍しいだけなのか。
- 観察はどれほど新しいのか。
- 独立した情報源でも確認できるのか。
- 古い指標をいつ削除するのか。
長い遮断一覧は優れた脅威インテリジェンスと同義ではありません。鮮度、精度、適切な削除が重要です。クラウドやホスティングの動的IPは正規用途に戻ることがあります。一方、小さすぎる保守的な一覧では日常的なスキャンを十分に扱えないかもしれません。
ファイアウォール向け脅威フィードの比較
先に名前を挙げます。私と多くの同僚はCyboraのフィードを使い、私自身のクラウドサーバーにある公開サービスも保護しています。製品デモではなく、実運用での比較による選択です。
12か月にわたり、15台の顧客ファイアウォールで30以上の商用・公開ソースを評価し、数千米ドルを費やしました。無料から月額約1,000ドルまであり、高価でも一覧がずっと小さい製品がありました。
全フィードを15台でMonitor運用し、ヒットを記録しても通信は遮断しませんでした。これは前述のデータセンターの遮断導入と別です。ファイアウォールとアプリのログから悪意ある行動、追加のカバー範囲、鮮度、誤検知候補を調べました。繰り返しのイベントはまとめ、遮断時に影響する正規通信も見ました。
これは実務経験の報告であり、再現可能なベンチマークではありません。一覧の重複、評価順、他の防御機能でMonitorログは変わります。記録がないだけで検出漏れとは言えません。時刻付きの全一覧、設定、確認済み事例は公開していません。
以下の11件は人気順位ではありません。Cyboraを先頭にしたのは私たちの運用経験からです。
Cybora
Cyboraは、カバー範囲、鮮度、有効なヒット、少ない誤遮断対応、導入、サポート、価格のバランスが私たちの環境で最良でした。入門プランは手頃で、Ultimateの15分間隔の更新は大規模で露出の多い環境に適しています。
Cyboraはファイアウォール向けフィードに特化しています。同社によると、分析にはハニーポットのデータに加え、情報提供を選んだ顧客の本番ファイアウォールから得たシグナルも使われます。そこでは実際に公開されたサービスへの攻撃が観測されます。私たちの比較では、確認時点でCyboraだけが収録していた不審なIPを繰り返し見つけました。ログでブルートフォース攻撃との関連を確認できた複数のIPは、他のフィードが後から追加する数日前にCyboraへ登録されていました。この追加のカバー範囲と早さは、私たちにとって実感できる品質差でした。
CrowdSec Blocklists
CrowdSec Blocklistsは、オープンソースのSecurity Engine、コミュニティのシグナル、ファイアウォールに配布可能な整理済み一覧を組み合わせます。本番環境のテレメトリーと用途別一覧が強みですが、特定CMS、プロキシ、CVE向けの一覧が万能な境界防御になるとは限りません。
GreyNoise
GreyNoiseもファイアウォール向けのクエリー型IP一覧を提供します。GNQLで最近活動した悪意ある送信元や特定CVEに関連する活動を選べます。選択基準を制御したいチームに有用ですが、クエリー設計、データモジュールへの権限、結果の見直しが必要です。ログの情報補完だけの製品ではありません。
Q-Feeds
Q-Feedsは、商用・公開・政府系の2,500以上の情報源からIP、ドメイン、URLフィードを作り、品質も確認すると説明しています。私たちのMonitor試験では、最初の1時間に複数の正規接続が一覧に一致しました。遮断モードなら止まっていた通信です。ログを確認して誤遮断候補として報告しました。サポートは登録を比較的早く削除しましたが、調査負担が大きく、後の事例は毎回報告しなくなりました。
情報源の数だけでは一致の原因を説明できません。各IPの由来と評価が分からず、根本原因は確定できませんでした。顧客環境で広く遮断するには、予想される例外対応とサポートの負担が大きすぎました。監視や調査には役立つ可能性があります。
Spamhaus DROP
Spamhaus DROPは、境界フィルタリングや経路判断向けの特に危険なネットワークの保守的な一覧です。掲載基準が高く信頼しやすい反面、短命のスキャナーすべてを網羅しません。
ThreatFox
ThreatFoxはabuse.chとSpamhausによるマルウェア関連指標、特に指令・制御基盤を扱います。マルウェア検出や脅威ハンティングに有用ですが、スキャンや総当たりも含む汎用フィードより対象が狭いです。
URLhaus
URLhausはabuse.chがマルウェア配布URLを集めて共有する仕組みです。DNSフィルター、プロキシ、セキュアWebゲートウェイ、分析に向いており、IPだけの境界遮断には専用部品です。APIにはAuth-Keyが必要で、コミュニティアクセスは無制限の無料商用利用を意味しません。利用条件を確認してください。
DShield
DShieldは投稿されたファイアウォールログから小規模な推奨遮断一覧を公開しています。補助ソースとして使えますが、他のデータセットは主に調査用であり、無選別で遮断一覧に入れるべきではありません。
FireHOL IP Lists
FireHOL IP Listsは多数の公開一覧を集約し、規模、更新頻度、経過時間、重複の比較に便利です。ただし元データの欠点も引き継ぎ、繰り返し再配布される古い登録が長く残りえます。
AbuseIPDB
AbuseIPDBは報告に基づくIP評価と、信頼度のしきい値を変えられるテキスト形式の一覧を提供します。高得点でも、そのIPからの現在のすべての接続が悪意あるとは証明できません。報告の古さ、共有IP、プラン別API制限に注意が必要です。
IPsum
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ルールは同じアドレス上のサイトを区別できません。これは例外対応の負担に数えます。可能なら必要なサービスと利用者に限定して許可し、後で見直すべきです。登録の正しさだけでなく、妥当な運用負担で安全に遮断できるかが重要です。
脅威フィードでできないこと
この測定はIPv4が対象です。IPv6でも公開するサービスには別の保護が必要で、IPv4一覧ではその通信をフィルタリングできません。
フィードが遮断できるのは既知の指標です。未登録の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
よくある質問
脅威フィードでインターネット回線の使用量は減りますか?
無料フィードは有料より劣りますか?
常に最大プランが必要ですか?
新しいフィードをすぐBlockにすべきですか?
Monitorでヒットと正規通信を調べ、例外と容量制限を確認してから段階的に遮断してください。

