そのIPブロックする前に
攻撃を受けたとき、アクセスログを眺めていると「このIPレンジごと落としてしまいたい」という衝動に駆られることがあります。でもちょっと待ってください。CIDRブロックは手軽に見えて、意外なところに地雷が埋まっています。
CIDRでブロックすると何が起きるか
攻撃元のIPが 203.0.113.45 だったとして、同じ /24 から何十件もアクセスが来ていたら「このサブネットごとブロックしよう」となりますよね。でも実際にやってみると、しばらくして「サイトが見れない」という問い合わせが届くことがあります。
調べてみると、ブロックしたCIDRに お客様のIPが含まれていた、というケースが思いのほか多いです。
攻撃元とお客様が同じサブネットにいることはレアケースのように思えますが、ISPやデータセンター、プロキシサービスのIPレンジは広大で、他のユーザーも普通に使っています。サポートコストを考えると、雑なCIDRブロックは割に合わないことが多いです。
本当に「外国のIP」か確認する
ということで、ブロックする前に「このCIDRに日本のIPが含まれていないか」を確認するフローを整備しました。使っている情報源は主に4つです。
RDAP
RDAP（Registration Data Access Protocol） はWhoisの後継プロトコルで、IPアドレスの割り当て情報をJSONで取得できます。APNIC・ARIN・RIPE・LACNIC・AFRINICといった各地域レジストリのAPIに問い合わせると、そのIPが属するCIDRブロック・国・登録名などが返ってきます。
ここで注意が必要なのが CIDRのサイズ。たとえば /8 のような巨大ブロックが返ってくることがあって、そのままブロックに使うと影響範囲が広大になります。RDAPの結果はあくまで「登録上の割り当て」なので、実際にルーティングされている経路とはズレがあります。
BGPの実経路情報（Team Cymru）
そこで Team Cymru のWhoisサービス も合わせて使います。BGPで実際にアナウンスされている経路情報をもとに、IPのASN（自律システム番号）と国コードを教えてくれます。RDAPで大きなブロックが返ってきたときでも、実経路ベースで絞り込む参考にできます。
GeoIP（ip-api.com）
さらに GeoIP で位置情報も確認します。GeoIPはISPや実際の運用者情報も取れるので、ASN名・組織名をチェックして有名クラウド事業者のIPかどうかも判断できます。
逆引きDNS（PTR）
PTRレコードも確認します。*.ap-northeast-1.compute.amazonaws.com のようなホスト名が返ってくれば、それはAWSのIPです。逆引きに .jp ドメインや国内ISPっぽいパターンが含まれていたら日本からのアクセスの可能性が高いと判断できます。
APNICの日本CIDRリストと照合する
上記の情報を組み合わせて「日本のIPが含まれているか」を判定するわけですが、念のためAPNICが公開している 日本のCIDR割り当てリスト とも突合します。
このファイルから JP|ipv4 の行を抜き出してCIDRに変換すると、日本に割り当てられたIPレンジの一覧が作れます。ブロック候補のCIDRがこのリストと重なっていたら、そのままブロックするのは危険です。
それでもWhitelistが必要になる
ここまでやっても引っかかるケースがあります。
Cloudflareのようなリバースプロキシを経由してサービスにアクセスしているお客様がいると、接続元IPはCloudflareのCIDR（アメリカのIP）になります。GeoIPでは「US」と判定されますし、日本のCIDRリストにも含まれません。でも実際のユーザーは日本にいます。これはもう調べようがないので、CloudflareのCIDRをホワイトリストに入れるしかありません。
ということで、ホワイトリストには以下を管理することになりました。
- Googlebot のCIDR（Googleが公式に公開しているリスト）
- APNICの日本IPリスト
- 手動登録CIDR（CloudflareやFastlyなど、CDN・プロキシサービスのIPレンジ）
ブロック前にこのホワイトリストと照合して、重複があればブロックしない、という運用です。
実際にやらかしたトラブル例
理屈で説明するより、実際に踏んだ事例のほうが刺さるかもしれないので紹介します。
GCPからのスキャン攻撃 → Google Search Consoleも死んだ
GCPのIPレンジから大量のスキャンが来たので、そのCIDRをまとめてブロックしました。攻撃は止まりましたが、しばらくして Google Search Console からのクロールも同じIPレンジを通っていたことが判明。インデックスに影響が出かけました。
GCPのCIDRはGoogleのサービス全般に使われているので、雑に落とすと思わぬところに巻き込まれます。
AWSアメリカIPをブロック → Let’s Encrypt証明書の更新が失敗
「アメリカからの不審な接続」を遮断したら、Let’s Encrypt の認証サーバー（AWSのIPを使っています）もブロックされてしまい、証明書更新が通らなくなりました。更新失敗に気づかず放置すると証明書期限切れになります。
結論：クラウド系は /32、それ以外の国外CIDRは思い切ってDROP
これらの経緯から、現在はIPの種別によってブロック粒度を使い分けています。
AWS・GCPのIPについては /32（単一IP）でブロックします。これらのCIDRはGoogleのクローラーやLet’s Encryptの認証サーバーなど、インフラ的に重要なサービスと同居していることが多く、CIDRごと落とすと想定外のものまで巻き添えになります。またTTL管理（一定期間でクリア処理）も必要となります。偽のクレジット情報で登録して大量に攻撃してくるような事例があるようですが、この辺はクラウドベンダー側の対応に期待するしかありません。
一方、それ以外の国外IP——中国・ロシア・東南アジア・東欧など——は、日本のCIDRリストやホワイトリストに引っかからないことを確認したうえで、CIDRごとまとめてDROPしています。正直なところ、こういったレンジから日本向けのウェブサービスに正規ユーザーが来ることはほぼなく、来たとしてもそのリスクよりスキャン・ブルートフォースを通し続けるコストのほうが高いです。
整理するとこうなります
| 対象 | ブロック単位 | 理由 |
|---|---|---|
| AWS・GCP等のクラウド事業者 | /32 | 同CIDRにクローラー・認証サーバー等が混在 |
| その他の国外IP | CIDR単位でDROP | 正規ユーザーの混在リスクが低い |
RDAP・BGP・GeoIP・逆引き・APNICで調べる手間をかけているのは、この振り分けを正確にやるためでもあります。「顧客・エンドユーザーが使う可能性のある日本のCIDRが含まれていないか、また重要なサービスが混在するクラウド系かどうか」を機械的に判定して、安全にCIDRブロックできるものはCIDRで、そうでないものは /32 で——という運用が今のところ無難な落としどころだと弊社では考えています。
