サーバーの健全性を守る：中国発の悪質スクレイパーと脆弱性スキャンIPを遮断する実践ガイド

Webサイトの運営者やインフラエンジニアであれば、誰もが一度は次のような悪夢を経験したことがあるのではないでしょうか。何気ない深夜、サーバー監視システムがけたたましいアラートを鳴らし、CPU使用率が予告なしに100％へと跳ね上がり、メモリが逼迫。一般の読者がアクセスしても「502 Bad Gateway」や「504 Gateway Timeout」の無機質なエラー画面しか表示されなくなる――。

慌ててSSHターミナルからWebサーバーのアクセスログ（Access Log）を確認すると、そこに並んでいるのは生身のユーザーによる閲覧ではなく、特定のIPアドレス帯から押し寄せる毎秒数百件もの暴力的なアクセスリクエストの山です。

これらは、GooglebotやBingbotのようにWebの標準規範を順守する正規の検索エンジンクローラーではありません。サーバーの帯域を食いつぶし、オリジナル記事を勝手に盗用してコピーサイト（コンテンツファーム）を構築したり、AI学習用のデータを無断収集したり、脆弱性を執拗に探査したりする「悪質スクレイパー（Bad Bots & Scrapers）」です。

数ある迷惑トラフィックの中でも、中国の特定通信回線から飛来する無断クローラーは、リクエスト頻度が極めて高く、並行接続数が異常で、なおかつ一切のルールを無視するため、世界中のエンジニアを悩ませる公害となっています。本稿では、直近で活発に活動している高リスクIP帯を公開し、CDNエッジ層からWebサーバー層、Linuxカーネルファイアウォール層に至る多層防御の実践的な構築手順を解説します。

---

1. なぜ悪質スクレイパーを断固としてブロックすべきなのか？

初心者のサイト運営者の中には、「アクセス数が増えればサイトのSEOにプラスになるのではないか？」と淡い期待を抱く人もいるかもしれません。しかし、現実は完全にその逆です。

悪質なボットがもたらすのは、サーバーとサービス運営に対する純粋な破壊的被害だけです。

1. サーバー性能の低下と接続のパンク： WordPressなどの動的CMSや自作のバックエンドでは、リクエストごとにPHP/Node.jsプロセスが起動し、データベースへクエリを発行します。悪質クローラーが1秒間に数十〜数百回もアクセスを仕掛けると、DB接続プール（Connection Pool）とCPUリソースが一瞬で枯渇し、正規のユーザーがアクセス不能に陥ります。
2. robots.txt の完全な無視： 良心的な検索エンジンはルートディレクトリの robots.txt を読み込み、クロール間隔（Crawl-delay）や拒否設定を守りますが、グレーゾーンのスクレイパーは拒否ルールを完全に無視し、むしろアクセス禁止パスを狙い撃ちにして収集します。
3. User-Agent の偽装と脆弱性の探査： 通常のChromeブラウザやGooglebotを装いながら、/wp-login.php、/.env、/phpmyadmin、/.git/config といった機微なパスを執拗にスキャンし、設定ファイルの放置や脆弱なパスワードを探し回ります。
4. オリジナルコンテンツの盗難と従量課金帯域の浪費： 心血を注いで執筆した記事が公開数分後にコピーサイトへ転載されるだけでなく、従量課金制のクラウドサーバー（AWS、GCP、Linodeなど）を利用している場合、月末に莫大な転送料金の請求書が届くことになります。

---

2. 直近の高リスクIPおよびCIDRブロックリスト

複数のWebマスターコミュニティおよびサーバーログの突合により、中国電信（広東省等の地域）に属する以下のIPアドレスおよび /24 ネットワーク帯が、過剰な並行スクレイピングとディレクトリ探索を繰り返していることが確認されています。これらはグローバルブラックリストに登録して即時遮断することを推奨します。

1. 個別の高リスクIPアドレス

• 14.153.206.108
• 14.155.182.76
• 14.155.204.129

2. 集中的に活動する /24 サブネット（帯域ごと遮断）

• 14.155.183.0/24 （14.155.183.1 〜 14.155.183.254）
• 14.155.184.0/24 （14.155.184.1 〜 14.155.184.254）
• 14.155.185.0/24 （14.155.185.1 〜 14.155.185.254）
• 14.155.230.0/24 （14.155.230.1 〜 14.155.230.254）

---

3. 3つの防衛線を張る多層防御の実践設定

迷惑クローラーの攻撃を完全に断ち切るには、単一の手法だけでは不十分です。「CDNエッジ層 $\rightarrow$ Webサーバー層 $\rightarrow$ カーネルファイアウォール層」の3段階による立体的な防御網を構築することが極めて有効です。

---

第1の防衛線：Cloudflare CDN / WAF エッジ防御（推奨・最優先）

トラフィックをCloudflare経由（オレンジの雲を有効化）にする手法は、コストパフォーマンスが最も高く、オリジンサーバーの負荷が実質ゼロになる最善策です。悪質なアクセスはユーザーに最も近いエッジサーバーで直接シャットアウトされ、手元のサーバーに到達すらさせません。

1. カスタムWAFルールの作成（Custom Rules）

Cloudflareダッシュボードにログインし、「セキュリティ」$\rightarrow$「WAF」$\rightarrow$「カスタムルール」へ移動します。

• ルール名：Block Known Bad Crawler Subnets
• 一致条件：フィールドに「受信元IPアドレス」$\rightarrow$「次の中に含まれる（is in）」を選択、または式エディターに以下を入力：

  (ip.src in {14.153.206.108 14.155.182.76 14.155.204.129 14.155.183.0/24 14.155.184.0/24 14.155.185.0/24 14.155.230.0/24})

• アクション：ブロック（Block） を選択。

2. ボット対策機能の有効化（Bot Fight Mode）

• 「セキュリティ」$\rightarrow$「ボット」で「Bot Fight Mode」をオンにします。
• サイトの読者が主に日本、台湾、欧米であり、中国本土での商用展開が一切ない場合は、地理的ルールを設定することも有効です。「ip.geoip.country eq "CN" かつ正規の検索エンジンでない場合」に「マネージドチャレンジ（Managed Challenge）」を要求することで、ヘッドレスブラウザによる自動スクレイピングスクリプトの99％を一掃できます。

---

第2の防衛線：Nginx リバースプロキシ層での接続即時切断

CDNを介していない場合や、Webサーバー内部で二重のフィルタリングを行いたい場合は、Nginxの設定ファイルで特定IPを直接遮断します。

重要なポイントとして、悪質ボットに対しては標準の deny（403 Forbiddenを返す）ではなく、Nginx固有の return 444; を使用することを推奨します。444 はHTTPヘッダーやエラーページを一切返さず即座にTCP接続を切断するため、サーバーの通信リソースを最大限に節約できます。

/etc/nginx/conf.d/block_bad_bots.conf を作成・編集します：

# 高リスクな悪質IPおよびサブネットを指定
geo $bad_client {
    default         0;
    14.153.206.108  1;
    14.155.182.76   1;
    14.155.204.129  1;
    14.155.183.0/24 1;
    14.155.184.0/24 1;
    14.155.185.0/24 1;
    14.155.230.0/24 1;
}

server {
    listen 80;
    listen 443 ssl http2;
    server_name example.com;

    # ブラックリストに該当した場合は即座に接続を切断
    if ($bad_client) {
        return 444;
    }

    # その他の通常設定...
}

設定を再読み込みして反映します：

sudo nginx -t && sudo systemctl reload nginx

---

第3の防衛線：Linux カーネルファイアウォール（iptables + ipset）

ボットのアクセス量がNginxのワーカープロセスを消費するほど膨大になった場合、最も低レイヤーでの究極の解決策は、Linuxのカーネル空間（Kernel Space）でパケットを直接破棄（DROP）することです。

多くの人が iptables -A INPUT -s ... -j DROP を何行も並べがちですが、ルール数が肥大化すると線形探索によってパケット処理速度が低下します。大規模なリストを高速処理するには「ipset」ハッシュテーブルを使用するのが鉄則です。

1. ツール導入とipsetテーブル作成

# Ubuntu / Debian
sudo apt-get install ipset iptables-persistent -y

# bad_crawlers という名称のネットワークハッシュテーブルを作成
sudo ipset create bad_crawlers hash:net

2. 対象IPとサブネットの追加

sudo ipset add bad_crawlers 14.153.206.108
sudo ipset add bad_crawlers 14.155.182.76
sudo ipset add bad_crawlers 14.155.204.129
sudo ipset add bad_crawlers 14.155.183.0/24
sudo ipset add bad_crawlers 14.155.184.0/24
sudo ipset add bad_crawlers 14.155.185.0/24
sudo ipset add bad_crawlers 14.155.230.0/24

3. iptables カーネルルールへのバインド

# bad_crawlers に一致する受信パケットを無条件で破棄（DROP）
sudo iptables -I INPUT -m set --match-set bad_crawlers src -j DROP

# 再起動後も設定を永続化
sudo ipset save > /etc/ipset.conf
sudo netfilter-persistent save

ipsetのハッシュルックアップにより、登録件数が数万件に達しても、Linuxカーネルはマイクロ秒単位で判定してパケットを破棄できるため、CPUやメモリを無駄に消費しません。

---

防御手法の総合効果比較

各防御アプローチの特徴とリソース消費を比較整理しました。

防御手段	防御レイヤー	サーバー負荷	設定の難易度	防御効果の評価
robots.txt	プロトコル規約層	極小	極めて平易	無効（悪質ボットは完全に無視）
Cloudflare WAF	CDN / エッジ層	ゼロ消費（最適）	低い	極めて高い、パケットがサーバーに到達しない
Nginx return 444	Webアプリケーション層	微小	中程度	良好、データ送信を拒否し即時TCP遮断
Linux ipset + iptables	OSカーネル層	極めて低い（ハッシュ探索）	中〜高	極めて優秀、大規模トラフィック攻撃に必須

---

まとめ：サイトの静的化こそが恒久的な根本対策

悪質なスクレイパーとの戦いは、まさに終わりのないいたちごっこです。攻撃者は今日遮断されたIPを捨て、明日には別のプロキシ経由で再び現れます。

アクセスログを定期的に監視しブラックリストを更新することに加え、根本的なアーキテクチャの改善こそが最も確実な防壁となります。例えば Astro のようなモダンな静的サイトジェネレーター（SSG）を導入し、動的なDB処理をビルド時に純粋なHTML、CSS、JavaScriptへと変換しておく設計です。

リクエストのたびにデータベースへ接続する必要がなくなれば、たとえ何百万回の不正アクセスを受けようとも、静的なテキストファイルを配信するだけの極めて軽量な処理で済みます。DBダウンの不安から完全に解放され、サーバーの安定稼働を末永く保ち続けることができます。