.htaccessでWebサイトを守る「nG Firewall」。20年にわたる進化とAI時代の有効性

企業やサービスから個人情報の漏洩や不正アクセスのニュースが相次いでいます。
毎日のように報道を目にする状況で、Webサイトのセキュリティを改めて考える機会が増えました。
大規模なサービスだけの問題ではなく、小さなWebサイトでも守り方を見直しておきたいところです。

セキュリティ対策といえば、筆者も以前は「6G Firewall」をよく使っていました。
最近はCloudflareなどを利用するようになり、いつの間にか使わなくなっていたのですが、久しぶりに思い出して調べてみると、開発は今も続いていて、2026年10月時点では「8G Firewall」に進化していました。

当時6Gを入れていたのは、追加費用や新しいミドルウェアが不要で、.htaccessを編集できるWeb担当者なら手軽に導入できたからです。
誤検知には気をつけつつ、「とりあえず入れておこう」という感覚で使っていました。

あれから約20年。
今ではAIが脆弱性の探索や攻撃パターンの生成を支援する時代です。
昔ながらの正規表現による防御に、まだ意味はあるのでしょうか。

nG Firewallは、Webサーバーで動く軽量なルールセット

nG Firewall（Perishable Press公式）は、Jeff Starr氏が開発するWebサーバー向けのセキュリティルール集です。
「nG」は「nth Generation（第n世代）」を意味し、本家の8G Firewallはその第8世代に当たります。

名称については、少しもったいない気もします。
「nG Firewall」だけでは何を守るものなのか伝わりにくい。例えば「○○ Firewall NG」のように、用途が分かる名前を先に置く方が、覚えやすいし検索もしやすそうです。
とはいえ、世代番号そのものが歴史を表す名前になっているのも、このプロジェクトらしいところです。

Apacheでは.htaccessまたはサーバー設定にルールを追加して利用します。
怪しいURLやクエリ文字列、User-Agentなどの特徴を照合し、条件に一致したリクエストをWebアプリケーションに届く前に拒否する仕組みです。
PHPやデータベースを動かす前に遮断できるため、不要な処理を減らす効果も期待できます。

WordPress専用ではなく、Apache上の一般的なWebサイトでも利用できます。
ソフトウェアを常駐させるタイプのファイアウォールというより、Webサーバーの設定として使うフィルタリングルールと考えると分かりやすいでしょう。

なお、本家はApache向けですが、Nginxなどに対応したコミュニティ製の派生版も存在します。

1Gから8Gまで、何が変わったのか

歴代の公式記事をたどると、ルールを増やす一方だったわけではないことが見えてきます。
特に初期には、「誰が来たか」を判定する方法から「何をしようとしているか」を見る方法へ、大きく舵を切っています。

※初期の「1G」は当時の正式な記事名ではなく、後から世代として整理した呼び方です。
表の時期は各世代の登場時期の目安で、現行記事の最終更新日ではありません。

1G〜2G：大量のブラックリストを捨てる

出発点になったUltimate htaccess Blacklistは、悪質なクローラーやスクレイパーのUser-Agentを列挙する方式でした。
しかしUser-Agentは簡単に偽装でき、IPアドレスも攻撃ごとに変わります。
相手を一件ずつ追いかける方式では、リストの管理も終わりません。

そこで登場したのが2G Blacklistです。
作者はアクセスログに現れる攻撃URLの共通点に注目し、攻撃元が異なっても共通する文字列を狙うことで、従来の350件以上の設定を約37行に置き換えたと説明しています。

この発想は今でも面白い。
攻撃元の名前を覚えるのではなく、実際に届いたリクエストの特徴を見て判定する。
nG Firewallの核は、この頃にできていました。

3G〜4G：異なる入口を組み合わせて守る

3G Blacklistでは、URLやクエリ文字列だけでなく、User-AgentやIPアドレスの検査を組み合わせる形になりました。

続く4G Blacklistは、HTTPメソッドのフィルタリングなども含むモジュール構成を採用。
条件を部分的に使ったり、サイトに合わせて調整したりしやすくなっています。

ただ、弾く条件を広げれば、正常なアクセスまで巻き込む可能性があります。
当時の変更履歴には、WordPressやプラグインとの互換性を改善するため、特定の遮断条件を削除・調整した記録も残っています。

ルールを増やすほど安心、という単純な話でもないんですよね。

5G〜6G：誤検知を減らす方向へ

5G Blacklistでは、偽装しやすいIPやUser-Agentに過度に頼らず、リクエスト文字列のパターンを重視する方針がより明確になります。
作者は、その方が少ない誤検知で防御できると説明しています。

6G Firewallでは、開発・テストとフィードバックを重ね、正常なリクエストを邪魔しないようにルールが見直されました。

特定のHTTPメソッドを一律に拒否すると、REST APIを利用するサイトでは支障が出る場合もあります。

Webアプリケーションが複雑になるほど、怪しい文字列を機械的に弾くだけでは済まなくなってきたわけです。

7G〜8G：小ささを保ったまま、運用を改善

7G Firewallは公式の説明で約12KB。
ブロックしたリクエストを記録するための追加手順も案内され、誤検知を調べる運用面が改善されました。
ただし専用の管理画面が付いてくるわけではなく、ログ取得には追加設定が必要です。

8G Firewallは約17KB。
長期のベータテストを経て、公式が本番利用向けとして公開しています。
無料かつオープンソースで、Apache向けの軽量なルールセットという基本路線は変わっていません。

2026年10月時点では本家公式ページで8Gが現行世代として紹介されています。
なお、別のWordPress製品にも「9G Firewall」という名前が使われていますが、Perishable Press本家の次世代版という意味ではないようです。

AIによる攻撃にも通用するのか

AIを利用した攻撃でも、最終的にWebサイトへ届くのはHTTPリクエストです。
そこに8Gが検出できる既知のパターンがあれば、AIで生成されたかどうかに関係なく遮断できる可能性があります。

ただし、AIを使った攻撃の厄介なところは、失敗したリクエストを手掛かりに次の攻撃パターンを作って実行し続ける点です。

Cloudflareが2026年9月に公開したWAFのテストでは、AIモデルがエンコーディングや攻撃データの置き場所を変え、HTTPレスポンスを見ながら試行を繰り返しました。
計1,107回の試行から人手で検証に値する事象を絞り込んでおり、単にWAFを通過したことを「侵入成功」とは扱っていません。
AIがリクエストを変えながら何度も試してくるとなると、固定のルールだけで対応するのはなかなか難しそうです。

ここで8Gの守備範囲を整理しておきます。

この表はあくまで8Gの仕組みに基づく整理で、AI攻撃への検出率を実測したものではありません。
また、Anthropicの2026年9月の脅威レポートにあるように、攻撃者によるAI利用はWebサイトへのリクエスト生成だけに限らず、認証情報の窃取や標的調査など、そもそも.htaccessでは防げない工程もあります。

CloudflareなどのWAFと、どう使い分けるか

Cloudflareのような前段のWAFは、マネージドルール、Bot対策、レート制限などを組み合わせられます。
nG Firewallはオリジンサーバー側で、決まった条件に一致するリクエストを小さな設定で拒否します。

役割が違うため併用はできますが、同じ攻撃を二重に検査しても、防御性能が上がるとは限りません。
Cloudflare側ですでに遮断できる攻撃は、オリジンへ届かないからです。

CloudflareなどのWAFをまだ使っていないサイトなら、nG Firewallは追加防御の選択肢になります。
すでにWAFを使っているなら、まず既存のルールで何を防げているかを確かめ、追加する効果と誤検知・保守の負担を比べたいところです。
いずれの場合も、WordPressのプラグインにある認可不備のように、リクエストの文字列だけでは判断できない問題まで解決するものではありません。

また、.htaccessに書けば必ず高速、というわけでもありません。
ルールの評価にはコストがあり、Apacheでの設定方法やアクセス量によって影響は変わります。
導入を検討するなら、公式の8G配布ページから現行ルールを取得し、まずステージング環境で動作確認を推奨します。
特にサイト内検索、管理画面、REST API、フォーム送信、外部サービスからのコールバックあたりは確認が必要でしょう。
既存の.htaccessをバックアップし、403が増えたときのログ確認と差し戻し手順も用意しておくと安心です。

約20年続いた仕組みの価値

振り返ると、nG Firewallの進化で印象的なのは、ルールを増やすこと以上に、何を見て遮断するかを見直し続けたことでした。
大量のUser-Agentリストから攻撃URLの特徴へ。
複数層の条件を組み合わせ、さらに誤検知や運用の負荷を減らす方向へ。

AIによって攻撃の探索や変形が速くなった今、静的なルールだけでWebサイトを守り切るのは難しいでしょう。
ソフトウェアの更新、入力検証、認可設計、適切なWAFやレート制限といった多層的な設計が必要です。

それでも、既知の悪質なリクエストをアプリケーションに届く前に弾く、といった役割は残ります。
全部を一つの製品に任せるのではなく、守れる範囲を理解して適切に組み合わせることが大事だと思います。
この製品は手軽に導入できる点が魅力ですが、歴史を追うと、誤検知と向き合いながら改善を続けてきたところにも惹かれます。

しばらく使っていませんでしたが、これを機に8G Firewallの再導入を検討しようと思います。
もちろん、今のWAFとの役割の重複や誤検知には注意しながら。

参考資料

• nG Firewallの概要（Perishable Press）
• 初期のUltimate htaccess Blacklist
• 2G Blacklist
• 3G Blacklist
• 4G Blacklist
• 5G Blacklist（2013年版）
• 6G Firewall
• 7G Firewall
• 8G Firewall
• AIを用いたWAF検証（Cloudflare、2026年）
• AIの悪用事例に関する報告（Anthropic、2026年）