2026年8月13日

Apacheのmod_evasiveで過剰なアクセスを遮断する方法（DDoS対策としての効果と限界）

Webサーバー・Apache

mod_evasiveは、同じIPアドレスから短時間に大量のリクエストが来たときに、そのIPへ一定時間 403 を返して遮断するApacheのモジュールです。1台のサーバーから押し寄せる連続アクセスや乱暴なクローラーには効果がありますが、多数のIPから来る本格的なDDoSや回線を埋めるような攻撃は防げません。この記事では、インストールと設定、WordPressで誤遮断を起こさないしきい値の考え方、動作の確かめ方、そして「どこまで任せてよいか」の線引きを説明します。

mod_evasiveの仕組み

mod_evasiveは、リクエストごとに「接続元IP」と「URI」の組み合わせを記録し、次のどちらかの条件を超えたIPをブロックリストに入れます。

同じページへの連続アクセス: 同じIPから同じURIへのリクエストが、DOSPageInterval 秒の間に DOSPageCount 回を超えた
サイト全体への連続アクセス: 同じIPからのリクエストが、URIを問わず DOSSiteInterval 秒の間に DOSSiteCount 回を超えた

ブロックされたIPには DOSBlockingPeriod 秒の間 403 Forbidden を返します。ブロック中もアクセスを続けると、その間はブロック期間が延長されていく動きになります。つまり、攻撃を続けるIPは止めた時点から数えて遮断が続き、正常な利用者は少し待てば戻れる、という設計です。

注意したいのは、記録がApacheの子プロセスごとに持たれる点です。preforkのように複数のプロセスでリクエストを分けて処理する構成では、カウントがプロセスごとに分かれるため、設定値どおりに正確に数えられるわけではありません。「おおよその目安を超えた極端なアクセスを止める道具」と考えておくと、期待とのずれが小さくなります。

インストール

UbuntuやDebianでは、標準のリポジトリにパッケージがあります。

sudo apt update
sudo apt install libapache2-mod-evasive
sudo a2enmod evasive

RHEL系（AlmaLinux・Rocky Linuxなど）では、EPELリポジトリから入れるのが一般的です。

sudo dnf install epel-release
sudo dnf install mod_evasive

パッケージ名や設定ファイルの場所はディストリビューションの版によって変わることがあるので、インストール後に dpkg -L libapache2-mod-evasive や rpm -ql mod_evasive で配置されたファイルを確認してください（2026年10月現在）。多くの場合、設定ファイルは次の場所にあります。

Ubuntu・Debian: /etc/apache2/mods-available/evasive.conf
RHEL系: /etc/httpd/conf.d/mod_evasive.conf

なお、mod_evasiveは長い間大きな更新がない古いモジュールです。ディストリビューションが配布を続けている間は使えますが、新しく防御の仕組みを組むなら、後半で触れるほかの手段と組み合わせる前提で考えるのが現実的です。

設定ファイルを書く

設定を変える前に、元のファイルを複製しておきます。

sudo cp -a /etc/apache2/mods-available/evasive.conf /root/evasive.conf.bak

配布された設定ファイルには <IfModule ...> で囲まれた設定例がコメントアウトされています。囲みのモジュール名（mod_evasive20.c など）はビルドによって異なるため、書き換えずにそのまま使い、中身だけを編集します。WordPressサイト向けの出発点として、次のような値が使えます。

DOSHashTableSize    3097
DOSPageCount        10
DOSPageInterval     1
DOSSiteCount        150
DOSSiteInterval     1
DOSBlockingPeriod   60
DOSLogDir           /var/log/mod_evasive
DOSWhitelist        127.0.0.1
DOSWhitelist        203.0.113.*

この例は「同じページに1秒で10回を超える」か「サイト全体に1秒で150回を超える」アクセスをしたIPを、60秒間遮断する設定です。203.0.113.* は自社オフィスや監視サーバーのIPに置き換えてください。DOSWhitelist は1行に1つずつ書き、IPv4の末尾をワイルドカードにする形で範囲を指定できます。

DOSLogDir は、ブロック中のIPを記録するファイルを置くディレクトリです。既定では /tmp などが使われるため、Apacheの実行ユーザーだけが書き込める専用のディレクトリを用意します。

sudo mkdir -p /var/log/mod_evasive
sudo chown www-data:www-data /var/log/mod_evasive   # RHEL系は apache:apache

WordPressで誤遮断を起こさないしきい値

mod_evasiveの既定値は、同じページへのアクセスが1秒に2回を超えると遮断するという、かなり厳しいものです。WordPressでは正常な利用でもリクエストが多くなる場面があるため、既定値のまま使うと利用者や管理者自身が締め出されます。

1ページの表示で数十件のリクエストが出る: 画像・CSS・JavaScript・Webフォントもすべて DOSSiteCount に数えられます。画像の多い記事や、テーマとプラグインが多くのファイルを読み込むサイトでは、1回の表示で数十件になることもあります。
管理画面は同じURIに連続で送る: ブロックエディターはREST APIへ、Heartbeat APIや一部のプラグインは admin-ajax.php へ繰り返しリクエストを送ります。同じURIへの連続アクセスなので DOSPageCount に引っかかりやすくなります。
同じIPに多くの人がいる: 会社や学校、携帯回線では、多くの利用者が1つのIPを共有していることがあります。

しきい値を決めるときは、まず普段のアクセスログを見て、1つのIPが1秒あたり何件のリクエストを出しているかを把握します。次のコマンドは、アクセスログから「秒とIPの組み合わせ」ごとのリクエスト数を数え、多い順に表示します（ログの形式が標準のcombinedの場合）。

sudo awk '{print $4, $1}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -20

正常な利用での最大値に十分な余裕を持たせた値から始め、運用しながら少しずつ下げるほうが、厳しい値から始めて苦情を受けるよりも安全です。

反映と動作の確認

設定の文法を確認してから、グレースフルリスタートで反映します。

sudo apachectl configtest && sudo systemctl reload apache2   # RHEL系は httpd
sudo apachectl -M | grep evasive

evasive20_module のような名前が表示されれば、モジュールは読み込まれています。

動作確認は、本番ではなくステージング環境で、ホワイトリストに入っていない自分の端末から行います。次のように短時間に連続でアクセスすると、途中から 403 が返るはずです。

for i in $(seq 1 30); do curl -s -o /dev/null -w "%{http_code}\n" https://staging.example.com/; done

ブロックされると、DOSLogDir に dos- で始まるファイルが作られ、システムログにも遮断したIPが記録されます。記録先はディストリビューションによって異なるため、journalctl や /var/log/syslog、/var/log/messages を検索して確認します。

sudo ls /var/log/mod_evasive/
sudo journalctl --since "10 min ago" | grep -i evasive

確認が済んだら、テストで遮断された自分のIPは DOSBlockingPeriod が過ぎると自然に解除されます。

CDNやリバースプロキシの後ろでは注意する

CloudflareなどのCDNやロードバランサーの後ろにApacheがある場合、Apacheから見える接続元は、利用者ではなくCDNやプロキシのIPになります。この状態でmod_evasiveを有効にすると、多くの利用者のアクセスが少数のプロキシIPに集まって見えるため、正常な利用者をまとめて遮断してしまいます。

mod_remoteip で本来の接続元IPを復元する方法もありますが、mod_evasiveがその値を使うかどうかはビルドによって異なります。プロキシの後ろでは、mod_evasiveを使わずに、CDNやロードバランサー側のレート制限を使うほうが安全です。どうしても使う場合は、プロキシのIPをホワイトリストに入れたうえで、ステージングで挙動を確かめてください。

DDoS対策としての限界と組み合わせ方

mod_evasiveが止められるのは、1つのIPから大量に来るアクセスです。次のような攻撃には効果がありません。

数千から数万のIPに分散した、1つひとつは少ないアクセス
サーバーの回線そのものを埋めるような大量の通信（Apacheに届く前に回線があふれます）
TCPやTLSの接続段階を狙った攻撃

また、遮断してもApacheはリクエストを受け取って 403 を返す処理をしているため、サーバーの負荷がゼロになるわけではありません。

そのため、mod_evasiveは次のような手段と組み合わせて使います。

CDN・クラウド型WAF: 回線を埋める攻撃や分散した攻撃は、サーバーに届く前に止めるしかありません。大規模な攻撃への備えは、CDNやホスティング会社の防御機能が中心になります。
fail2ban: ログを監視して、条件に合うIPをファイアウォールで遮断します。Apacheに届く前に止められるため、繰り返し来るIPには効率的です。DOSSystemCommand で直接ファイアウォールを操作する方法もありますが、Apacheの実行ユーザーにroot権限のコマンドを許すことになるため、fail2banに任せるほうが安全です。
WordPress側の対策: wp-login.php への総当たりや xmlrpc.php への大量アクセスは、ログイン試行の制限や、使わないXML-RPCの無効化で負荷そのものを減らせます。

まとめ

mod_evasiveは、同じIPから短時間に大量のリクエストが来たときに一定時間 403 を返すモジュールで、1台からの連続アクセスや乱暴なクローラーへの対策になります。
既定値はWordPressには厳しすぎるため、アクセスログで普段のリクエスト数を確かめ、余裕を持った値から始めます。管理者や監視サーバーのIPはホワイトリストに入れます。
設定後は configtest を通してから再読み込みし、ステージングで遮断と解除の動きを確認します。
CDNやプロキシの後ろでは誤遮断が起きやすいため、プロキシ側のレート制限を優先します。
分散した攻撃や回線を埋める攻撃は防げないので、CDN・WAF・fail2ban・WordPress側の対策と組み合わせて使います。