サーバーのログを眺めると、げんなりします。SSHへのブルートフォース、ポートスキャン、素性の知れないアクセス——世界中の悪性IPが、四六時中ドアを叩いてくる。かといって、これらのIPを1つずつ手で調べて遮断するのは非現実的だし、どこか1つの脅威リストに頼っても穴が残る。防御側は、攻撃の物量に対して常に不利です。ipblocklist（bitwire-it製）は、この非対称を少しでも埋めるための——25以上の脅威インテリジェンスソースを束ね、2時間ごとに更新される“悪性IPの遮断リスト”です。ファイアウォールに読み込ませるだけで、既知の脅威IPをまとめて遮断できます。

この記事を読むと、①ipblocklistで結局何ができるのか（既知の悪性IPをファイアウォールで一括遮断し、2時間ごとに自動更新する）、②どんな課題を解決するのか（脅威IPの手動収集の限界と、単一ソースの穴）、③何を代替できるのか（手作業のIP収集、単一の脅威フィード依存）が分かります。防御全体の設計を先に押さえたい方は、サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストを合わせて読むと、IP遮断がどの層の対策なのかが立体的に掴めます。

ipblocklist：25以上の脅威インテリジェンスソースを束ね、2時間ごとに更新される悪性IPの遮断リスト。攻撃元(inbound)とC2/ボットネット宛先(outbound)を両面で遮断
ipblocklistは、複数の脅威フィードを束ねた“悪性IPの一括遮断リスト”。攻撃元と悪性通信先の両面を塞ぐ。
この記事のポイント
  • ・ipblocklistは、25以上のソースを束ね2時間ごとに更新される悪性IP遮断リスト。
  • ・inbound（攻撃元）とoutbound（C2・ボットネット等の悪性通信先）の2種類を提供。
  • ・公開URLをファイアウォール/ipsetに読み込ませるだけで、既知の脅威IPを遮断できる。
  • ・主要パブリックDNSリゾルバを除外し、正規サービスの巻き込みを避ける配慮あり。
  • ・⚠️リストのデータはCC BY-NC-SA 4.0（非商用）。商用利用は基本不可。

1. ipblocklistとは：2時間ごと更新の悪性IP遮断リスト

ipblocklistの全体像：25以上の脅威ソースを集約し、2時間ごとに更新、inboundとoutboundの2つのリストとして公開、ファイアウォールで既知の悪性IPを遮断
ipblocklistの全体像。複数ソース→集約→2時間ごと更新→2種のリスト→ファイアウォールで遮断。

ipblocklistは、「既知の悪いIPアドレス」を集めたテキストのリストです。GitHubの一文は「悪いIPで満たされたIPリスト——2時間ごとに更新」。ソフトウェアというより、継続的にメンテナンスされる“脅威データ”そのものを提供するプロジェクトです。

使い方の発想はシンプルです。世の中には、スパムやスキャン、攻撃を繰り返す悪性IPが大量に存在します。それらのIPを一覧にしておき、ファイアウォールに「このリストのIPは全部ブロック」と教える——これがipblocklistの基本的な使い方です。手作業で1つずつIPを調べる代わりに、すでに束ねられ・更新され続けるリストを丸ごと使えるわけです。

ipblocklistが実用的なのは、次の3点を押さえているからです。

・集約されている：25以上の脅威インテリジェンスソースを束ね、単一フィードの穴を補う
・新しい：2時間ごとに更新され、比較的新しい脅威IPをカバーする
・2面をカバー：攻撃元（inbound）と悪性通信先（outbound）の両方を用意する

「脅威IPの収集・更新・集約」という重労働を、丸ごと肩代わりしてくれる——これがipblocklistの本質です。防御側が自前でやると膨大な手間になる部分を、公開リストとして受け取れます。

補足すると、この「集約リスト」というジャンル自体は新しいものではなく、firehol/blocklist-ipsetsやstamparm/ipsumなど、著名な先行プロジェクトがいくつも存在します。そうした中でipblocklistが持つ特徴は、「2時間ごと」という更新頻度の高さと、inbound/outboundという用途別の明快な2分割、そしてすぐ使える単純な形式（プレーンなIP/CIDRのテキスト）にあります。脅威IPは時間とともに入れ替わる——攻撃者はIPを使い捨て、乗っ取られたホストは駆除される——ため、更新が古いリストは急速に価値を失います。2時間ごとという頻度は、この“鮮度”を重視した設計だと言えます。もちろん更新が速い分、リストの中身も頻繁に変わるので、後述するように自動更新の仕組み（cron等）とセットで運用するのが前提になります。

ひとことで
  • ・ipblocklist＝25以上のソースを束ね2時間ごとに更新する“悪性IPの一括遮断リスト”。
  • ・攻撃元(inbound)と悪性通信先(outbound)の両面をファイアウォールで塞げる。

2. なぜ必要か：単一ソース・手動収集の穴を、集約リストで塞ぐ

手動収集や単一ソース依存の課題（追いきれない・穴が残る・更新が止まる）を、ipblocklistが25以上のソース集約・2時間ごと更新・両面カバーで解決する対比図
解決するのは「脅威IPを追い続けるのは非現実的」という、防御側の構造的な不利。

ipblocklistが解決するのは、脅威IPに対する防御が構造的に抱える「追いきれない」問題です。攻撃側は膨大かつ流動的で、防御側が手作業で対応するのは現実的ではありません。

具体的な困りごとはこうです。

・手動収集は非現実的：日々変わる悪性IPを、人力で調べて登録し続けるのは無理がある
・単一ソースには穴：1つの脅威フィードだけでは、そのソースが拾えない脅威を見逃す
・更新が止まる：自前のリストは、メンテナンスが滞れば古びて役に立たなくなる
・攻撃元しか見ていない：着信の遮断だけでは、内部から悪性宛先への発信を止められない

ipblocklistは、これらを「集約された・更新され続けるリスト」で解決します。手動収集の限界には25以上のソースの集約で応え、単一ソースの穴には複数ソースの束ねで応え、更新の停滞には2時間ごとの更新で応え、攻撃元のみの弱点にはoutbound（悪性通信先）リストで応える——という具合です。

誤解しないでほしい点
  • ・ipblocklistは「これさえ入れれば安全」ではない。多層防御の1レイヤーとして使う。
  • ・脅威フィードゆえ誤検知の可能性はゼロではない。重要環境ではテスト適用から。

コスト面のメリットも見逃せません。商用の脅威インテリジェンスフィードは高価で、個人や小規模組織には手が届きにくいものです。ipblocklistは、複数のオープンな脅威ソースを束ねた結果を無料で公開しているため（※データは非商用ライセンス）、個人サーバーや自宅ラボでも、それなりの品質の脅威フィードを導入できるという点で、防御の民主化に寄与しています。もちろん商用フィードのような手厚いサポートやSLAはありませんが、「無料で・自動更新される・両面をカバーする」という3点だけでも、多くの個人・小規模環境にとっては十分に価値があります。

この必要性が効いてくるのは、インターネットに面したサーバーやネットワークを運用しているほどです。攻撃の物量にさらされる環境ほど、「既知の悪性IPを機械的に弾く」ことの費用対効果が高くなります。ipblocklistは、防御の“足切り”を自動化し、人手を、リストで拾えない未知の脅威の分析に振り向けられるようにするものだと捉えると、価値が分かりやすいでしょう。

3. inbound と outbound：攻撃元と通信先の両面をブロック

ipblocklistの2つのリスト：inbound（攻撃元＝スパム・スキャン・SSH/RDPブルートフォース・Web攻撃の発信元、受信側に適用）とoutbound（悪性通信先＝C2・ボットネット・マルウェア配布・フィッシング、送信側に適用）
inboundは着信（攻撃元）を、outboundは発信（悪性宛先）を塞ぐ。両面あることが強み。

ipblocklistの特徴は、2種類のリストで「攻撃元」と「悪性通信先」の両面をカバーすることです。ここが単なる着信ブロックリストとの違いです。

inbound.txt（攻撃元のブロック）：「こちらへ悪意ある接続を仕掛けてくる発信元」のリストです。含まれるのは、スパム・スキャン・SSHやRDPへのブルートフォース・Web攻撃などの発信元。ファイアウォールの受信側（WAN IN / INPUT）に適用し、攻撃が届く前に弾きます。

outbound.txt（悪性通信先のブロック）：「マルウェアが通信しようとする悪性の宛先」のリストです。含まれるのは、C2（Command & Control）サーバー、ボットネットの司令塔、マルウェア配布サイト、フィッシングホストなど。ファイアウォールの送信側（LAN OUT / OUTPUT）に適用します。

このoutboundが重要です。万一、内部の端末がマルウェアに感染しても、そのマルウェアがC2サーバーと通信しようとする発信を遮断できれば、被害の拡大（指令の受信、データの持ち出し）を食い止められます。

セキュリティの世界では、防御を「侵入を防ぐ」ことだけに寄せると脆くなります。どれだけ着信を固めても、フィッシングメールのリンクを踏む、正規のソフトに紛れたマルウェアを入れてしまう——といった経路で、内部への侵入は起こり得ます。そこで効くのが「侵入されても、悪さをさせない」という発想です。マルウェアの多くは、感染後に外部のC2サーバーへ“コールバック”して指令を受け取ることで初めて本格的に動き出します。この最初の通信をoutboundリストで断ち切れれば、ランサムウェアの暗号化指令やデータ持ち出しといった致命的なフェーズに進ませずに済む可能性が高まります。「入口(inbound)を固め、出口(outbound)で被害を封じ込める」という二段構えは、現代の多層防御の基本形であり、ipblocklistが2種類のリストを提供する理由もここにあります。着信ブロックだけの単純なブロックリストと、決定的に思想が違う点です。

2つのリストの役割を整理すると次のとおりです。

リスト 塞ぐもの 含まれるIP 適用先
inbound.txt 攻撃の着信 スパム・スキャン・SSH/RDPブルートフォース・Web攻撃の発信元 受信（WAN IN / INPUT）
outbound.txt 悪性への発信 C2・ボットネット・マルウェア配布・フィッシング 送信（LAN OUT / OUTPUT）
設計思想が効くところ
  • ・inboundで「攻撃を入れない」、outboundで「感染しても悪性通信させない」。攻守両面。
  • ・特にoutboundは、侵入後の被害拡大（C2通信・情報持ち出し）を抑える最後の砦になりうる。

4. 仕組み：25以上のソースを集約し、DNSリゾルバを除外する

ipblocklistの中身は、複数の脅威インテリジェンスソースを集約（アグリゲート）するという、地味だが効くアプローチです。集約元には、Spamhaus・AbuseIPDB・Emerging Threats・AlienVault OTXなどを含む25以上のソースが挙げられています。

なぜ集約が効くのか。単一の脅威フィードは、それぞれ得意な脅威の種類や観測範囲が異なります。あるソースはスパムに強く、別のソースはマルウェアC2に強い、といった具合です。複数を束ねれば、単独では見逃す脅威を広くカバーできます。この集約の流れを図にすると次のようになります。

flowchart TD S1["Spamhaus"] --> AG["集約・重複排除
2時間ごと"] S2["AbuseIPDB"] --> AG S3["Emerging Threats"] --> AG S4["AlienVault OTX"] --> AG S5["... 25以上のソース"] --> AG AG --> EX["除外処理
主要パブリックDNSリゾルバ等"] EX --> IN["inbound.txt
攻撃元"] EX --> OUT["outbound.txt
悪性通信先"]

この図で見逃せないのが、集約の後に入る除外処理です。ipblocklistは、主要なパブリックDNSリゾルバを除外する配慮を入れています。これは、正規に使われるサービス（公開DNSなど）が誤ってブロックされ、通信に支障が出るのを防ぐためです。脅威フィードは「弾きすぎ」ても業務を止めてしまうので、「広く弾きつつ、正規サービスは巻き込まない」バランスが実運用では重要になります。ライブ統計はbitwire.itのダッシュボードで公開されており、リストの規模や更新状況を確認できます。

集約元として挙げられている各ソースには、それぞれ得意分野があります。Spamhausはスパム送信元やボットネットの追跡で長年の実績があり、AbuseIPDBは世界中の管理者から報告された悪性IPをスコア付きで集約します。Emerging Threatsは侵入検知（IDS/IPS）の文脈で知られ、AlienVault OTXはコミュニティ駆動の脅威インテリジェンスを提供します。これらは観測の網もスコアリングの基準も異なるため、あるソースが拾えない脅威を、別のソースが拾うという補完関係が生まれます。ipblocklistの価値は、こうした「性格の違う25以上のフィードを、重複を排除しつつ1つのリストに束ねる」オーケストレーションにあります。個人でこれらを個別に契約・購読し、2時間ごとにマージする——と考えれば、その手間を肩代わりしてくれるありがたみが分かります。

ただし、集約ゆえの注意もあります。元ソースの品質やポリシーが、そのまま集約リストに反映されるという点です。たとえば、あるソースが積極的に広めにIPを載せる方針なら、その分だけ誤検知（正常IPの巻き込み）のリスクも上がります。だからこそ、後述するように「いきなり全面DROPではなく、まずLOGで様子を見る」導入が推奨されます。脅威フィードは“魔法の白黒リスト”ではなく、確率的に怪しいIPの集まりだと捉えておくのが、健全な付き合い方です。

5. 使い方：ファイアウォール/ipsetに読み込ませる（自動更新）

ipblocklistの使い方：inbound.txt/outbound.txtを定期取得→ipsetに読み込み→iptablesでドロップ→cronで2時間ごとに自動更新する運用フロー
基本運用：リストを取得→ipsetに読み込み→iptablesで遮断→cronで自動更新。

使い方は、公開されているリストURLをファイアウォールやipsetに読み込ませるのが基本です。ここでは、これはセキュリティの実対策なので、Linuxでの代表的な設定例を示します。まず、ipset にリストを読み込み、iptables でそのipsetをドロップ対象にします。

# ipsetを作成
sudo ipset create bad_inbound hash:net

# inboundリストを取得してipsetに投入
curl -s https://raw.githubusercontent.com/bitwire-it/ipblocklist/main/inbound.txt \
  | grep -Eo '([0-9]{1,3}\.){3}[0-9]{1,3}(/[0-9]+)?' \
  | while read ip; do sudo ipset add bad_inbound "$ip" -exist; done

# 受信(INPUT)でドロップ
sudo iptables -I INPUT -m set --match-set bad_inbound src -j DROP

リストは2時間ごとに更新されるので、cron で定期的に取得し直すと効果的です。たとえば2時間おきに更新するなら、次のようなcron設定にします。

# 2時間ごとに inbound/outbound を再取得して ipset を更新するスクリプトを実行
0 */2 * * * /usr/local/bin/update-ipblocklist.sh

運用の流れをまとめると、こうなります。

・inbound.txt / outbound.txt を取得する
・inboundは受信(INPUT)側、outboundは送信(OUTPUT)側のipsetに読み込む
・iptables等で、それぞれのipsetをドロップ対象にする
・cronで2時間ごとに再取得し、ipsetを更新する
・まずはログ監視（LOG）から始め、誤検知が無いか確認してからDROPに切り替える

outbound（悪性通信先）側も同様に設定します。こちらは送信（OUTPUT）チェーンに適用し、内部から悪性の宛先への通信をドロップします。感染端末のC2通信を止める“最後の砦”になるため、inboundとセットで入れておく価値があります。

# outbound用のipsetを作成し、outboundリストを投入
sudo ipset create bad_outbound hash:net
curl -s https://raw.githubusercontent.com/bitwire-it/ipblocklist/main/outbound.txt \
  | grep -Eo '([0-9]{1,3}\.){3}[0-9]{1,3}(/[0-9]+)?' \
  | while read ip; do sudo ipset add bad_outbound "$ip" -exist; done

# 送信(OUTPUT)でドロップ（内部→悪性宛先を遮断）
sudo iptables -I OUTPUT -m set --match-set bad_outbound dst -j DROP

「取得 → ipsetに読み込み → ドロップ → cronで自動更新」が基本の型です。UniFi/OPNsense/pfSenseなどのファイアウォール製品でも、URLベースの動的ブロックリストとして同様に取り込めます。導入初期は、いきなりDROPせずLOGで様子見してから本適用するのが安全です。具体的には、まず -j DROP の代わりに -j LOG --log-prefix "ipblocklist: " を使ってマッチしたトラフィックをログに出し、正規の通信が引っかかっていないかを数日観察してから、DROPに切り替えます。この一手間を惜しむと、思わぬ正規サービスの遮断で業務が止まる——という事故につながりかねません。脅威フィードの導入は「攻めの遮断」と「守りの検証」を両輪で進めるのが鉄則です。

6. 注意点：ライセンス（非商用）・誤検知・自己責任

ipblocklist導入判断：個人サーバー・自宅ラボ・非商用環境の防御に刺さる一方、リストのデータはCC BY-NC-SA（非商用）・誤検知の可能性・多層防御の一部という注意点
導入判断の観点。赤は価値が出る条件、⚠️はライセンス・誤検知などの重要な注意点。

最後に、導入すべきかの判断材料と、特に重要な注意点を整理します。

ipblocklistが向いている人

・インターネットに面したサーバーを運用し、攻撃の足切りを自動化したい
・自宅ラボ・個人サーバーで、既知の悪性IPを手軽に遮断したい
・outboundで内部の感染端末のC2通信を止める備えをしたい
・非商用の環境で使う（ライセンスの制約に該当しない）

慎重に判断すべきケース

・商用環境・商用製品で使いたい（後述のライセンスに抵触）
・誤検知が許されない基幹システム（テスト適用・ログ監視が前提）
・これ1つで万全を期待している（多層防御の一部にすぎない）

最も重要な注意点がライセンスです。リポジトリのソースコードはMITですが、配布されるブロックリストのデータ自体はCC BY-NC-SA 4.0（表示・非商用・継承）です。これは、集約元にSpamhausなど商用利用を禁じるソースが含まれるためです。つまり、リストのデータを商用の環境・製品で使うことは基本的に許可されていません。商用利用を検討する場合は、各データソースのライセンスを個別に確認する必要があります。

導入前チェック（重要）
  • ・⚠️ リストのデータはCC BY-NC-SA 4.0（非商用）。商用環境・製品での利用は基本不可。
  • ・脅威フィードゆえ誤検知の可能性はゼロではない。まずLOGで様子見→DROPへ。
  • ・これ1つで安全にはならない。多層防御（WAF・EDR・パッチ・監視）の一レイヤーとして使う。

もう1点、多層防御の一部として使うこと。ipblocklistは「既知の悪性IP」を弾く強力な足切りですが、未知の攻撃や、正規IPを踏み台にした攻撃は止められません。WAF・EDR・パッチ管理・ログ監視といった他の対策と組み合わせてこそ効きます。防御全体の設計は、サプライチェーンセキュリティ2026のような俯瞰の中でIP遮断を位置づけると、過信も軽視もせずに使えます。

まとめ

ipblocklistは、「脅威IPの収集・更新・集約という重労働を、公開リストとして肩代わりする」プロジェクトです。25以上のソースを束ね、2時間ごとに更新し、攻撃元（inbound）と悪性通信先（outbound）の両面を塞ぐ——ファイアウォールに読み込ませるだけで、既知の脅威に対する自動の足切りが手に入ります。

結論
  • ・ipblocklistは、25以上のソースを束ね2時間ごとに更新される悪性IP遮断リスト。
  • ・inbound（攻撃元）とoutbound（C2・ボットネット等の悪性通信先）の両面をカバー。
  • ・ファイアウォール/ipsetに読み込ませ、cronで自動更新するのが基本の運用。
  • ・主要DNSリゾルバを除外し、正規サービスの巻き込みを避ける配慮あり。
  • ・⚠️ リストのデータはCC BY-NC-SA（非商用）。商用利用は基本不可。多層防御の一部として使う。

セキュリティに「これさえやれば安全」という銀の弾丸はありませんが、手間をかけずに底上げできる対策は積極的に取り入れる価値があります。ipblocklistは、まさにその「低コストで防御の底上げになる」タイプの対策です。既知の悪性IPを機械的に弾くだけで、ログに並ぶ攻撃の試行は目に見えて減り、その分、運用者は本当に対処すべき事象の分析に集中できます。ノイズが減ることは、監視の質そのものを上げる効果もあります。守りの底上げと運用負荷の軽減を同時に得られる、費用対効果の高い一手だと言えるでしょう。「攻撃の物量を、まず機械的に足切りしたい」なら、まずはLOGモードでinbound.txtを試し、誤検知が無いか確認してからDROPに切り替えてみてください。ただし商用利用はライセンス上不可な点だけは、導入前に必ず確認を。防御全体の設計はサプライチェーンセキュリティ2026を合わせてどうぞ。

参照ソース

・bitwire-it/ipblocklist (GitHub) — 公式リポジトリ。リストの種類・集約ソース・更新頻度・ライセンスの一次ソース。
・inbound.txt（攻撃元IPリスト） — 攻撃元IPの実データ（2時間ごと更新）。
・outbound.txt（悪性通信先IPリスト） — C2・ボットネット等の悪性宛先IPの実データ。