【nginx】迷惑なアクセスをdenyでブロック！IPアドレス指定によるアクセス拒否ガイド

By /

【Nginx】迷惑なアクセスをdenyでブロック！IPアドレス指定によるアクセス拒否ガイド

はじめに

WebサイトやWebアプリケーションを運営する上で、セキュリティ対策は避けて通れない重要な課題です。日々、世界中からあなたのサーバーに向けて、意図しない様々なアクセスが試みられています。これらは、脆弱性を探す自動スキャン、ログインフォームへの総当たり攻撃（ブルートフォース攻撃）、コンテンツの不正なコピー（スクレイピング）、コメントスパムの投稿など、多岐にわたります。

このような迷惑なアクセスは、放置しておくと深刻な問題を引き起こす可能性があります。サーバーのリソースを無駄に消費し、正規ユーザーの体験を損なうだけでなく、最悪の場合、セキュリティインシデントにつながり、情報漏洩やサイトの改ざんといった壊滅的な被害をもたらすこともあります。

幸いなことに、高機能なWebサーバーソフトウェアであるNginxには、こうした脅威に対抗するための強力なアクセス制御機能が標準で備わっています。その中でも最も基本的かつ効果的な手法の一つが、特定のIPアドレスからのアクセスを拒否することです。

本記事では、Nginxのdenyディレクティブを中心としたIPアドレスベースのアクセス制御について、初心者の方にも分かりやすく、そして中級者以上の方にも役立つ応用的な内容まで、網羅的に解説します。この記事を読み終える頃には、あなたは迷惑なアクセス元を特定し、Nginxの設定ファイルに数行書き加えるだけで、それらをシャットアウトする技術を身につけていることでしょう。サーバーの平和を守るための第一歩を、ここから踏み出しましょう。

第1章: なぜIPアドレスによるアクセス拒否が必要なのか？

具体的な設定方法に入る前に、まずはなぜIPアドレスを指定してアクセスを拒否する必要があるのか、その背景と目的を深く理解しておきましょう。

1-1. 迷惑アクセスの種類と実態

あなたのWebサーバーのアクセスログには、あなたが意図しないであろうアクセスの記録が数多く残されています。これらは、主に以下のような種類に分類できます。

  • ブルートフォース攻撃 (Brute-force Attack):
    WordPressのwp-login.phpやSSHのポートなど、IDとパスワードで認証する箇所に対して、考えられる全ての組み合わせを機械的に試行し、不正ログインを試みる攻撃です。成功すれば、管理者権限を乗っ取られてしまいます。

  • 脆弱性スキャナ (Vulnerability Scanner):
    Webサイトが使用しているソフトウェア（CMS、プラグイン、ミドルウェアなど）に存在する既知の脆弱性を探すための自動化されたツールです。特定のファイル（例: /.env, /phpmyadmin/）へのアクセスを試み、弱点を見つけ出して攻撃の足がかりにします。

  • コンテンツスクレイピング (Content Scraping):
    Webサイト上の記事、商品情報、価格などのコンテンツを、プログラムを使って自動的に、かつ大量に収集する行為です。競合サイトの分析目的で行われることもありますが、多くはコンテンツを丸ごと盗用し、別のサイトに掲載するために行われます。

  • コメントスパム (Comment Spam):
    ブログのコメント欄や掲示板、問い合わせフォームなどに、宣伝やフィッシングサイトへのリンクを含む無関係な内容を自動で大量に投稿する行為です。サイトの品質を低下させ、ユーザーに不快感を与えます。

  • リソース枯渇型攻撃 (Resource Exhaustion Attack):
    DoS (Denial of Service) 攻撃やDDoS (Distributed Denial of Service) 攻撃の予兆として、特定のURLや重い処理を伴うページに対して、単一または複数のIPアドレスから集中的にアクセスを仕掛ける行為です。サーバーのリソースを使い果たさせ、サービスを停止に追い込むことを目的とします。

1-2. 迷惑アクセスがもたらす具体的な被害

これらの迷惑アクセスは、単に「気持ちが悪い」というだけでは済みません。実質的な被害をもたらします。

  • サーバーリソースの浪費:
    不正なリクエスト一つ一つに応答するために、サーバーのCPU、メモリ、ネットワーク帯域といった貴重なリソースが消費されます。これが積み重なると、サーバー全体のパフォーマンスが低下します。

  • パフォーマンスの低下:
    サーバーリソースが迷惑アクセスの処理に追われると、正規のユーザーからのリクエストへの応答が遅くなります。ページの表示が遅くなれば、ユーザーは離脱してしまい、ビジネス上の機会損失や顧客満足度の低下につながります。

  • セキュリティインシデントのリスク増大:
    脆弱性スキャンやブルートフォース攻撃は、本格的なサイバー攻撃の前段階です。これらを放置することは、攻撃者に侵入の扉を開けたままにしているのと同じであり、情報漏洩やサイト改ざんのリスクを著しく高めます。

  • ログの汚染:
    アクセスログが大量のノイズ（迷惑アクセスの記録）で埋め尽くされると、本当に調査すべき問題（アプリケーションのエラーや正規ユーザーの異常な挙動など）を発見するのが困難になります。

1-3. IPアドレスベースのアクセス制御の有効性とその限界

こうした問題に対し、攻撃元のIPアドレスを特定してブロックするというアプローチは、非常に有効な対策の一つです。

【有効性】
* シンプルかつ強力: Nginxの設定ファイルに1行追加するだけで、特定の攻撃元からの通信を完全に遮断できます。
* 即効性: 設定をリロードした瞬間から効果を発揮し、進行中の攻撃を素早く止めることができます。
* 低コスト: Nginxの標準機能であり、追加のソフトウェアやコストなしに実装できます。

しかし、IPアドレスベースのブロックは万能薬ではありません。その限界も理解しておく必要があります。

  • IPアドレスの変更: 攻撃者はプロキシサーバーやVPN、あるいはボットネット（マルウェアに感染した多数のコンピュータ群）を利用して、攻撃元のIPアドレスを頻繁に変更します。一つのIPをブロックしても、すぐに別のIPから攻撃が再開されるケースは少なくありません。
  • 大規模攻撃への無力さ: 何万、何十万ものIPアドレスから同時に行われるDDoS攻撃に対して、手動でIPアドレスを一つずつ追加していく方法では到底追いつきません。
  • 誤ブロックのリスク:
    • 動的IP: 一般家庭のインターネット回線では、接続するたびにIPアドレスが変わる（動的IP）ことが多いため、ある時点で悪意のあるユーザーが使っていたIPアドレスを、後日、全く無関係な正規ユーザーが利用する可能性があります。
    • 共有IP: 大学や企業、集合住宅、そして特にスマートフォンのキャリアネットワーク（CGN: Carrier-Grade NAT）などでは、一つのグローバルIPアドレスを多数のユーザーが共有しています。このIPアドレスをブロックしてしまうと、攻撃者だけでなく、多数の正規ユーザーまで巻き込んでアクセスできなくしてしまいます。

【結論】
IPアドレスによるアクセス拒否は、セキュリティ対策の第一の防衛ラインとして非常に重要かつ効果的です。特に、単一または少数のIPから執拗に繰り返される攻撃に対しては絶大な効果を発揮します。ただし、その限界を認識し、他のセキュリティ対策（WAF、Fail2ban、CDNなど）と組み合わせることで、より堅牢な多層防御体制を築くことが理想的です。

第2章: Nginxアクセス制御の基礎 – ngx_http_access_module

それでは、NginxでIPアドレスによるアクセス制御を実現する中核的な機能、ngx_http_access_moduleについて学んでいきましょう。

2-1. ngx_http_access_moduleとは？

ngx_http_access_moduleは、Nginxに標準で組み込まれているモジュールの一つです。特別なインストール作業は必要なく、Nginxがインストールされていればすぐに利用できます。このモジュールの主な役割は、リクエストを送信してきたクライアントのIPアドレスに基づいて、そのアクセスを許可するか、あるいは拒否するかを決定することです。非常にシンプルですが、前章で述べたような多くの脅威に対する最初の防衛線として機能します。

2-2. 主要なディレクティブ: allowとdeny

このモジュールが提供するディレクティブ（設定項目）は、主にallowとdenyの2つです。名前から直感的に理解できる通り、それぞれ「許可」と「拒否」を意味します。

  • denyディレクティブ
    指定されたクライアントからのアクセスを拒否します。
    構文: deny address | CIDR | unix: | all;

    • address: deny 192.0.2.1; のように、特定のIPv4またはIPv6アドレスを指定します。
    • CIDR: deny 198.51.100.0/24; のように、CIDR（サイダー）表記を用いてIPアドレスの範囲を指定します。/24は、198.51.100.0から198.51.100.255までの256個のIPアドレスを意味します。
    • unix:: UNIXドメインソケットからのアクセスを拒否します。（通常、Webアクセス制御ではあまり使いません）
    • all: deny all; のように記述し、全てのクライアントからのアクセスを拒否します。これは特定のIPアドレスのみを許可したい場合に非常に役立ちます。

  • allowディレクティブ
    指定されたクライアントからのアクセスを許可します。
    構文: allow address | CIDR | unix: | all;

    denyと同様のパラメータ（address, CIDR, unix:, all）を取ります。

2-3. ディレクティブの評価順序

allowとdenyを複数記述した場合、Nginxはどのように動作するのでしょうか？ ここが非常に重要なポイントです。

Nginxは、設定ファイルに書かれている上から順にルールを評価し、最初にマッチしたルールを適用します。

具体例を見てみましょう。

“`nginx

例1: 192.0.2.100だけを拒否し、他は全て許可

deny 192.0.2.100;
allow 192.0.2.0/24;
``
この場合、192.0.2.100からのアクセスは、最初のdenyルールにマッチするため**拒否**されます。192.0.2.50からのアクセスは、最初のdenyルールにはマッチせず、次のallow`ルールにマッチするため許可されます。

では、この順番を逆にするとどうなるでしょうか。

“`nginx

例2: 意図しない挙動

allow 192.0.2.0/24;
deny 192.0.2.100;
``
この場合、192.0.2.100からのアクセスは、192.0.2.0/24の範囲に含まれるため、最初のallowルールにマッチしてしまいます。その結果、**許可**されてしまい、2行目のdeny`ルールは評価されません。このように、ルールの記述順序は結果に直結します。

【重要な暗黙のルール】
もし、記述されたどのallow/denyルールにもマッチしなかった場合、そのアクセスはデフォルトで許可されます。

この仕様を理解すると、特定のIPアドレスだけを許可し、その他すべてを拒否する「ホワイトリスト方式」の書き方が見えてきます。

“`nginx

例3: ホワイトリスト方式（推奨パターン）

allow 203.0.113.10; # 許可したいIPアドレス
allow 203.0.113.11; # 許可したいIPアドレス
deny all; # 上記以外、すべて拒否
``
この設定では、203.0.113.10と203.0.113.11からのアクセスは最初のallowルールにマッチして許可されます。それ以外のすべてのIPアドレス（例:8.8.8.8）は、どのallowルールにもマッチせず、最後のdeny all;`にマッチするため、すべて拒否されます。管理画面へのアクセス制限などに応用できる、非常に強力な設定です。

2-4. 設定可能なコンテキスト

allowとdenyディレクティブは、Nginxの設定ファイルの様々な場所（コンテキスト）に記述できます。記述した場所によって、ルールの適用範囲が変わります。

  • httpコンテキスト:
    nginx.confファイル内のhttp { ... }ブロック内に記述します。ここに書かれたルールは、そのNginxサーバーがホストする全てのWebサイト（バーチャルホスト）に適用されます。サーバー全体でブロックしたいIPアドレスがある場合に便利です。

  • serverコンテキスト:
    sites-available/your_site.confなどの設定ファイル内のserver { ... }ブロック内に記述します。ここに書かれたルールは、そのserverブロックで定義された特定のWebサイトにのみ適用されます。

  • locationコンテキスト:
    serverブロック内のlocation /path/ { ... }ブロック内に記述します。ここに書かれたルールは、そのlocationブロックがマッチする特定のURLパスにのみ適用されます。例えば、「サイト全体は公開するが、/adminディレクトリだけは特定のIPからしかアクセスさせない」といった、より詳細な制御が可能です。

  • limit_exceptコンテキスト:
    locationブロック内でさらにHTTPメソッド（GET, POSTなど）を限定してルールを適用したい場合に用います。例えば、「GETリクエストは誰でも許可するが、POSTリクエストは特定のIPからのみ許可する」といった制御に使えます。

一般的には、特定のサイトの特定のディレクトリ（例: 管理画面）を保護したい場合はlocationコンテキスト、サイト全体でブロックしたい場合はserverコンテキスト、サーバー全体で共通のブラックリストを適用したい場合はhttpコンテキスト、というように使い分けるのが良いでしょう。

第3章: 実践！IPアドレスを指定してアクセスを拒否する

理論を学んだところで、いよいよ具体的な設定方法を見ていきましょう。ここでは、様々なシナリオに応じた実践的な設定例を紹介します。

3-1. 準備: Nginxの設定ファイル

作業を始める前に、基本的な手順と注意点を確認します。

  1. 設定ファイルの場所の確認:
    Nginxの設定ファイルは、OSやインストール方法によって場所が異なります。一般的な場所は以下の通りです。

    • メイン設定ファイル: /etc/nginx/nginx.conf
    • サイトごとの設定ファイル: /etc/nginx/conf.d/ or /etc/nginx/sites-enabled/

  2. バックアップの作成:
    設定ファイルを編集する前には、必ずバックアップを取りましょう。万が一、設定ミスでNginxが起動しなくなっても、元に戻せるようにするためです。
    bash
    # 例: default.confをバックアップ
    sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak

  3. 設定ファイルの編集:
    vimやnanoなどのテキストエディタで設定ファイルを開き、必要なディレクティブを追記・編集します。
    bash
    sudo nano /etc/nginx/sites-available/default

  4. 構文チェック:
    編集が終わったら、設定ファイルの構文が正しいかを確認します。このステップを怠ると、リロード時にエラーが発生し、最悪の場合はサービスが停止する可能性があります。
    bash
    sudo nginx -t
    syntax is okとtest is successfulと表示されれば成功です。エラーが出た場合は、メッセージをよく読んで修正してください。

  5. 設定の反映（リロード）:
    構文チェックが通ったら、Nginxを再起動せずに設定を反映させるreloadコマンドを実行します。これにより、サービスを停止することなく新しい設定が適用されます。
    bash
    sudo systemctl reload nginx
    # または
    # sudo service nginx reload
    # または
    # sudo nginx -s reload

3-2. 基本的な拒否設定

最も基本的な、単一または複数のIPアドレスを拒否する方法です。

  • 単一のIPアドレスを拒否する
    特定の迷惑なIPアドレス198.51.100.123からのアクセスをサイト全体で拒否したい場合、serverブロックに以下のように記述します。

    “`nginx
    server {
    listen 80;
    server_name example.com;

    # 迷惑なIPアドレスを拒否
deny 198.51.100.123;

location / {
    # ... いつもの設定
    root /var/www/html;
    index index.html;
}
# ... 他の設定

    }
    “`

  • 複数のIPアドレスを拒否する
    複数のIPアドレスを拒否したい場合は、denyディレクティブを必要な数だけ並べて記述します。

    “`nginx
    server {
    # …
    # 迷惑なIPアドレスリスト
    deny 198.51.100.123;
    deny 203.0.113.55;
    deny 2001:db8:ffff::1; # IPv6アドレスも同様に拒否可能

    location / {
    # ...
}
# ...

    }
    “`

3-3. CIDR表記でIPアドレス範囲を拒否する

特定のISPやクラウドプロバイダー、あるいは特定の国からの攻撃が集中している場合、CIDR表記を使ってIPアドレスの範囲（サブネット）をまとめて拒否するのが効率的です。

例えば、192.0.2.0から192.0.2.255までの256個のIPアドレスすべてをブロックしたい場合、以下のように記述します。

“`nginx
server {
# …
# 特定のネットワーク範囲を拒否
deny 192.0.2.0/24;

location / {
    # ...
}
# ...

}
“`

CIDR表記は、攻撃元が特定のデータセンターから来ていることが明らかな場合に特に有効です。

3-4. 特定の国からのアクセスをまとめて拒否する (GeoIP2モジュール利用)

特定の国からのスパムや攻撃が非常に多い場合、その国全体からのアクセスをブロックしたいと考えるかもしれません。IPアドレスのリストを一つ一つ追加するのは現実的ではありませんが、NginxのGeoIP2モジュールを使えばこれを実現できます。

注意: この方法は、正規のユーザーまでブロックしてしまうリスクが高いため、適用は慎重に検討してください。

  1. モジュールのインストール:
    使用しているOSのパッケージマネージャでnginx-modules-geoip2のようなパッケージをインストールするか、Nginxをソースからコンパイルする際に--with-http_geoip2_moduleオプションを追加します。
    bash
    # Ubuntu/Debianの場合
    sudo apt-get update
    sudo apt-get install nginx-full libnginx-mod-http-geoip2

  2. GeoIP2データベースの準備:
    MaxMind社が提供する無料のGeoLite2データベースをダウンロードし、サーバー上の適切な場所（例: /usr/share/GeoIP/）に配置します。GeoLite2-Country.mmdbというファイルが必要です。

  3. Nginxの設定 (nginx.conf)
    httpブロックに、データベースの場所と、国コードを取得するための変数を定義します。

    “`nginx

    /etc/nginx/nginx.conf

    http {
    # …
    # GeoIP2データベースの読み込み
    geoip2 /usr/share/GeoIP/GeoLite2-Country.mmdb {
    $geoip2_country_code country iso_code;
    }
    # …
    }
    “`

  4. サイトごとの設定ファイルでの拒否設定
    serverブロック内で、先ほど定義した変数$geoip2_country_codeを使って条件分岐を行います。以下の例では、中国（CN）とロシア（RU）からのアクセスを拒否します。

    “`nginx
    server {
    # …
    # 特定の国からのアクセスをブロック
    if ($geoip2_country_code ~ (CN|RU)) {
    return 444; # 応答を返さずに接続を切断
    }

    location / {
    # ...
}
# ...

    }
    “`

3-5. 拒否されたアクセスへの応答

denyディレクティブによってアクセスが拒否された場合、Nginxはデフォルトで403 ForbiddenというHTTPステータスコードを返します。これは「アクセス権がありません」という意味です。しかし、この応答をカスタマイズすることも可能です。

  • 404 Not Foundを返す
    攻撃者に「ここには何もない」と思わせ、ターゲットとしての興味を失わせることを期待する戦略です。error_pageディレクティブを使います。

    “`nginx
    server {
    # …
    deny 198.51.100.123;
    error_page 403 =404; # 403エラーを404として処理する

    # ...

    }
    “`

  • 444 Connection Closed Without Responseを返す
    これはNginx独自のステータスコードで、クライアントに何の応答も返さずに一方的に接続を切断します。攻撃ツールによっては、応答がないことでタイムアウトし、攻撃効率を下げさせる効果が期待できます。また、サーバー側も応答を生成するリソースを節約できます。
    この方法を実現するには、denyの代わりにifとreturnを使います（mapディレクティブを使う方がより推奨されます。第4章参照）。

    “`nginx

    この方法はif in locationの問題があるため、mapの使用を推奨

    location / {
    if ($remote_addr = “198.51.100.123”) {
    return 444;
    }
    # …
    }
    “`

  • カスタムエラーページを表示する
    親切な（あるいはユーモラスな）エラーページを表示することもできます。

    “`nginx
    server {
    # …
    error_page 403 /errors/403.html;
    location = /errors/403.html {
    root /var/www/special_pages;
    internal; # 内部リダイレクトでのみアクセス可能にする
    }

    location / {
    deny 198.51.100.123;
    # ...
}

    }
    “`

第4章: 応用編 – よりスマートなアクセス制御

基本的な拒否設定に慣れてきたら、次はより効率的で管理しやすい、スマートなアクセス制御の方法を見ていきましょう。

4-1. 設定ファイルの分割とインクルード (include)

拒否したいIPアドレスのリストが長くなってくると、メインの設定ファイルが非常に見づらくなります。このような場合は、拒否リストを別のファイルに切り出し、includeディレクティブで読み込むのがベストプラクティスです。

  1. 拒否リスト用のファイルを作成する
    例えば、/etc/nginx/block_ips.confというファイルを作成し、その中にdenyディレクティブだけを記述します。

    “`bash

    /etc/nginx/block_ips.conf の中身

    deny 198.51.100.123;
    deny 203.0.113.55;
    deny 192.0.2.0/24;

    … 新しいIPを追記していく

    “`

  2. メインの設定ファイルからインクルードする
    serverブロックやhttpブロックなど、ルールを適用したい場所でincludeディレクティブを使ってこのファイルを読み込みます。

    “`nginx

    /etc/nginx/sites-available/default

    server {
    listen 80;
    server_name example.com;

    # 拒否IPリストを読み込む
include /etc/nginx/block_ips.conf;

location / {
    # ...
}
# ...

    }
    “`

この方法のメリットは計り知れません。
* 可読性の向上: メインの設定ファイルがスッキリし、ロジックが追いやすくなります。
* 管理の容易さ: IPアドレスの追加・削除はblock_ips.confを編集するだけで済みます。
* 再利用性: 複数のserverブロックで同じ拒否リストを共有できます。

4-2. 特定のパスだけを保護する

サイト全体ではなく、WordPressの管理画面(/wp-admin/)や開発者用の特別なパスなど、特定のURLだけを厳しく保護したいケースは非常に多いです。これはlocationブロックと「ホワイトリスト方式」を組み合わせることで実現できます。

以下の例では、/wp-admin/ディレクトリへのアクセスを、203.0.113.0/24というIPアドレス範囲（例: 自社のオフィスネットワーク）からのみ許可し、それ以外からのアクセスはすべて拒否します。

“`nginx
server {
# …
location / {
# サイトの通常部分
try_files $uri $uri/ /index.php?$args;
}

# WordPress管理画面へのアクセス制限
location ~ ^/wp-admin/ {
    # 許可するIPアドレス/範囲
    allow 203.0.113.0/24;
    # 上記以外、すべて拒否
    deny all;

    # 通常のPHP処理設定 (deny allの後ろに書く)
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
}

# ...

}
“`
これは非常に強力なセキュリティ対策であり、ブルートフォース攻撃の大部分を無効化できます。

4-3. mapディレクティブを使った高度な制御

ifディレクティブは便利ですが、多用するとパフォーマンスに影響を与える可能性があり、Nginxのコミュニティでは「If is Evil」という言葉があるほどです。より推奨される方法は、mapディレクティブを使うことです。

mapは、ある変数の値に基づいて、新しい変数の値を設定する機能です。これを使って、IPアドレスのブラックリストを効率的に管理できます。

  1. mapブロックをhttpコンテキストに定義する
    nginx.confのhttpブロック内に、$remote_addr（クライアントのIPアドレス）をキーとして、ブロック対象の場合は1、それ以外は0を返す$is_blockedという変数を定義します。

    “`nginx

    /etc/nginx/nginx.conf

    http {
    # …
    # IPアドレスブラックリストの定義
    map $remote_addr $is_blocked {
    default 0; # デフォルトはブロックしない

        # --- ブロックしたいIPをここに追加 ---
    "198.51.100.123"    1;
    "203.0.113.55"      1;
    "~^192\.0\.2\."       1; # 正規表現で範囲指定も可能
    # -----------------------------------
}
# ...

    }
    ``
    ホスト名を    mapのキーにすることも可能です (map $host $is_blocked { … }`)。

  2. serverブロックで変数を評価する
    サイトごとの設定ファイルで、$is_blocked変数が1かどうかをチェックし、1であれば接続を拒否します。return 444;（応答なしで切断）と組み合わせるのが効果的です。

    “`nginx

    /etc/nginx/sites-available/default

    server {
    # …
    # ブラックリストに載っているIPであれば接続を拒否
    if ($is_blocked) {
    return 444;
    }

    location / {
    # ...
}
# ...

    }
    “`

このmap方式のメリット:
* ifをserverコンテキストのトップレベルで一度だけ使うため、パフォーマンス上の懸念が少ない。
* ブラックリストの管理をnginx.confの一箇所に集約できる。
* ブラックリストを別ファイルに切り出してincludeすることも可能で、管理性がさらに向上する。

4-4. アクセスログから拒否対象IPを自動でリストアップする

日々、アクセスログを眺めて手動でIPアドレスを追加するのは大変な作業です。簡単なシェルスクリプトを組んで、疑わしいアクセスのIPアドレスを抽出する作業を半自動化してみましょう。

例えば、WordPressのログインページwp-login.phpに対して、存在しないユーザー名で大量にPOSTリクエストを送ってくるIPアドレスを特定するには、以下のようなコマンドが役立ちます。

“`bash

/var/log/nginx/access.log から “POST /wp-login.php” を含む行を抽出し、

IPアドレス($1)で集計して、アクセスの多い順にトップ20を表示する

grep “POST /wp-login.php” /var/log/nginx/access.log | awk ‘{print $1}’ | sort | uniq -c | sort -nr | head -n 20
実行結果例:
1523 198.51.100.123
891 203.0.113.55
…
``
この結果から、198.51.100.123や203.0.113.55が明らかに怪しいと判断できます。これらのIPアドレスをコピーして、block_ips.confやmap`ブロックに追加します。

同様に、404エラーを多発させているIP（脆弱性スキャナの可能性）を特定することもできます。
bash
awk '($9 == "404") {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 20

これらのコマンドを定期的に実行することで、新たな脅威に素早く気づき、対処することができます。ただし、これはあくまで補助ツールであり、結果を鵜呑みにせず、誤検知の可能性も考慮して最終的な判断は人間が行うべきです。

第5章: 注意点とベストプラクティス

IPアドレスによるアクセス拒否は強力ですが、使い方を誤ると予期せぬトラブルを招くこともあります。最後に、運用上の注意点とベストプラクティスをまとめます。

5-1. 誤って自分自身をブロックしないために

最もやってはいけない失敗が、自分自身や会社のIPアドレス、あるいは正常な運用に必要なサービスのIPアドレスをブロックしてしまうことです。特にdeny all;を使ってホワイトリスト方式を実装する際には、細心の注意が必要です。

  • 自分のIPを確認: 作業前にcurl ifconfig.meなどのコマンドで自分のグローバルIPアドレスを確認しましょう。
  • 許可リストを整備: 会社の固定IP、リモートワーク中の開発者のIP、外部の監視サービス（UptimeRobot, Mackerelなど）のIPレンジは、必ずallowリストに追加しておきましょう。

5-2. 動的IPアドレスと共有IPの問題

第1章でも触れましたが、この問題は非常に重要です。
* 動的IP: 悪意のあるユーザーが使っていたIPをブロックしても、そのユーザーはルーターを再起動するだけでIPアドレスが変わり、再びアクセス可能になるかもしれません。
* 共有IP (CGN): スマートフォンからのアクセスは、多くの場合、携帯キャリアが管理する巨大なNAT（CGN）を経由します。このIPアドレスを一つブロックすると、同じ基地局に接続している何百、何千という無関係なユーザーがサイトにアクセスできなくなる可能性があります。安易に携帯キャリアのIPレンジをブロックするのは絶対に避けるべきです。

IPアドレスでブロックする際は、そのIPが誰のものなのか、whoisコマンドなどである程度調査する癖をつけるのが良いでしょう。
bash
whois 198.51.100.123

5-3. IPv4とIPv6の両方に対応する

インターネットは徐々にIPv6への移行が進んでいます。最近では、スマートフォンからのアクセスを中心に、IPv6でのアクセスも珍しくありません。アクセスログを確認し、攻撃元がIPv6アドレス（例: 2001:db8::abcd:1234）を使っていないか確認しましょう。もし使われているなら、denyディレクティブにもIPv6アドレスを記述する必要があります。

5-4. パフォーマンスへの影響

数個から数百個程度のdenyルールであれば、パフォーマンスへの影響はほとんどありません。しかし、これが数千、数万という単位になると、Nginxの起動やリロードにかかる時間が増加し、メモリ使用量も増大する可能性があります。

非常に大規模なブラックリストを運用したい場合は、Nginxのdenyディレクティブだけでなく、Linuxのファイアウォール機能とipsetを組み合わせる方法などを検討する価値があります。ipsetは大量のIPアドレスを非常に高速に検索できるため、Nginxに到達する前のパケットレベルで効率的にトラフィックを破棄できます。

5-5. Nginxだけで頑張りすぎない – 他のツールとの連携

IPアドレスブロックは万能ではありません。より高度で自動化された防御を実現するためには、他のツールとの連携が不可欠です。

  • Fail2ban: ログファイルを常時監視し、「5分以内にログイン失敗を10回繰り返したIP」のようなルールを定義して、該当するIPアドレスを自動的にファイアウォール（iptablesなど）で一定期間ブロックしてくれるツールです。Nginxとの相性は抜群で、ブルートフォース攻撃対策の自動化に絶大な効果を発揮します。

  • WAF (Web Application Firewall): ModSecurityのようなWAFをNginxに組み込むことで、IPアドレスだけでなく、リクエストの内容自体を検査できます。SQLインジェクションやクロスサイトスクリプティング（XSS）といった、アプリケーションの脆弱性を狙った攻撃パターンを検知し、ブロックします。

  • CDN / クラウド型WAF: CloudflareやAWS WAF、Akamaiといったサービスを利用するのも非常に有効な手段です。これらのサービスは、ユーザーとあなたのサーバーの間に立ち、世界中の攻撃情報を集約した脅威インテリジェンスに基づいて、悪意のあるトラフィックをサーバーに到達する前にフィルタリングしてくれます。特に、大規模なDDoS攻撃に対しては、個人のサーバーで対抗するのはほぼ不可能なため、これらのサービスの利用が必須となります。

まとめ

本記事では、Nginxのdenyディレクティブを軸に、迷惑なアクセスをIPアドレスでブロックするための方法を、基礎から応用まで詳細に解説してきました。

  • 第1章では、ブルートフォース攻撃や脆弱性スキャンといった迷惑アクセスの実態と、それらがもたらす被害、そしてIPブロックの有効性と限界について学びました。
  • 第2章では、アクセス制御の核となるngx_http_access_moduleのallow/denyディレクティブの基本的な使い方と、ルールが評価される順序について理解を深めました。
  • 第3章では、単一IPの拒否からCIDRでの範囲指定、さらにはGeoIP2モジュールを使った国単位でのブロックまで、具体的な設定方法を実践的に紹介しました。
  • 第4章では、includeによる設定ファイルの分割、locationでのパス指定、mapディレクティブを使った効率的なリスト管理など、よりスマートで管理しやすい応用テクニックを探求しました。
  • 第5章では、自分をブロックしないための注意点や、Fail2ban、WAF、CDNといった他のセキュリティツールとの連携の重要性を確認しました。

IPアドレスによるアクセス拒否は、Webサイトやアプリケーションを運営する上でのセキュリティ対策の基本の「き」です。シンプルながら即効性があり、多くの脅威からサーバーを保護する最初の防衛線として、非常に強力な武器となります。

しかし、今日のサイバー攻撃はますます巧妙化、分散化しています。IPブロックだけに頼るのではなく、常にアクセスログを監視して脅威の動向を把握し、必要に応じて設定を見直すことが重要です。そして、Fail2banによる自動化やWAFによるアプリケーション層の保護、CDNによる大規模攻撃への備えなど、複数の防御策を組み合わせた「多層防御」の考え方を取り入れることが、あなたの貴重なデジタル資産を末永く守り続けるための鍵となるでしょう。

この記事が、あなたのサーバーの平和と安全に貢献できれば幸いです。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール