AWS WAF と Snort の比較：WordPress を守るならどちらをどこに置くか

AWS WAF と Snort は、どちらも「不正な通信を見つけて止める」道具ですが、見ている層と置き場所が違うため、単純な優劣ではなく構成で選ぶものです。AWS WAF は CloudFront や ALB の前段で HTTP リクエストを検査するマネージドな Web アプリケーションファイアウォール、Snort はサーバーやネットワーク上でパケットを検査するオープンソースの IDS/IPS です。この記事では、両者の違いを整理したうえで、WordPress サイトの構成ごとの選び方と、併用する場合の考え方を説明します。

それぞれの位置づけ

AWS WAF

AWS WAF は、CloudFront、Application Load Balancer、API Gateway などの AWS のサービスに関連付けて使う WAF です。Web ACL というルールの集まりを作り、リクエストの URL、ヘッダー、本文、送信元 IP などの条件で許可・遮断・カウント（記録のみ）を決めます。AWS が用意するマネージドルールグループには、一般的な Web 攻撃向けのもののほか、WordPress や PHP アプリケーション向けのものも用意されています（2026年10月現在）。

TLS は CloudFront や ALB で終端されるため、HTTPS の中身をそのまま検査できるのが大きな利点です。サーバーの管理は不要で、設定はマネジメントコンソールや API、Terraform などのツールで行います。

Snort

Snort は Cisco の Talos が開発を続けているオープンソースの侵入検知・防御システムで、現在の主流は Snort 3 です。サーバーやネットワーク機器の近くに置き、流れるパケットをシグネチャ（ルール）と照合します。HTTP だけでなく、SSH、DNS、SMTP などあらゆるプロトコルを対象にできるのが特徴です。

一方、HTTPS の中身はそのままでは見えません。HTTP の内容まで検査したい場合は、TLS を終端したリバースプロキシの後ろに置くなど、構成を工夫する必要があります。ルールセットはコミュニティ版のほか、Talos が提供する登録制・有償のものがあり、提供範囲や配信のタイミングは変わることがあるため、公式サイトで確認してください。

比較表

費用の考え方も異なります。AWS WAF は Web ACL、ルール、リクエスト数などに応じた従量課金で、Bot Control などの追加機能は別料金です。Snort はソフトウェア自体は無償ですが、動かすサーバーの費用と運用の工数がかかります。具体的な料金は変わるため、AWS の料金ページで確認してください。

WordPress の構成ごとの選び方

AWS 上で CloudFront や ALB を使っている場合

WordPress を EC2 や ECS で動かし、前段に CloudFront か ALB を置いている構成なら、Web 攻撃への対策は AWS WAF が第一候補です。HTTPS の中身を検査でき、ログイン画面への総当たりや既知の脆弱性を狙ったリクエストを、サーバーに届く前に止められます。

導入時は、いきなり Block にせず、マネージドルールを Count（記録のみ）で動かして誤検知を確認するのが安全です。WordPress ではブロックエディターの保存（REST API への送信）や admin-ajax.php への通信が、本文の内容によって SQL インジェクションやクロスサイトスクリプティングのルールに当たることがあります。ログで当たったルールを確認し、管理画面へのパスに限って特定のルールを Count に変える、といった調整をしてから Block に切り替えます。

ログイン画面への総当たりには、レートベースのルールが使えます。次は wp-login.php へのリクエストを送信元 IP ごとに数えて制限する例です。

{
  "Name": "rate-limit-wp-login",
  "Priority": 10,
  "Action": { "Block": {} },
  "Statement": {
    "RateBasedStatement": {
      "Limit": 100,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "ByteMatchStatement": {
          "SearchString": "/wp-login.php",
          "FieldToMatch": { "UriPath": {} },
          "TextTransformations": [ { "Priority": 0, "Type": "LOWERCASE" } ],
          "PositionalConstraint": "EXACTLY"
        }
      }
    }
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "rateLimitWpLogin"
  }
}

Limit は評価期間（既定では5分）あたりの件数です。設定できる最小値や評価期間の選択肢は変更されることがあるため、最新のドキュメントで確認してください。CloudFront の後ろに ALB がある構成で ALB 側に WAF を付けると、送信元 IP が CloudFront のものになる点にも注意が必要です。その場合は CloudFront 側に付けるか、転送されたヘッダーの IP を使う設定を検討します。

VPS や専用サーバーで動かしている場合

AWS のサービスを経由しない構成では、AWS WAF はそもそも使えません。この場合の Web 攻撃対策は、ModSecurity などのサーバー上の WAF、Cloudflare などの CDN 型 WAF、WordPress のセキュリティプラグインが中心になります。Snort は、それらと並べて「サーバー全体への不審な通信を検知する」役割で使うのが現実的です。

Snort を WordPress サーバー上で動かす場合、まずは検知のみで運用し、どんなアラートが出るかを把握します。ローカルルールの例です。

# local.rules（Snort 3 の例）
alert http $EXTERNAL_NET any -> $HOME_NET any (
    msg:"WP login POST burst";
    flow:to_server,established;
    http_method; content:"POST";
    http_uri; content:"/wp-login.php";
    detection_filter:track by_src, count 20, seconds 60;
    sid:1000001; rev:1;
)

# 設定とルールの読み込みを確認してから起動する
snort -c /usr/local/etc/snort/snort.lua -R /usr/local/etc/snort/local.rules -T
snort -c /usr/local/etc/snort/snort.lua -R /usr/local/etc/snort/local.rules -i eth0 -A alert_fast

インストール先のパスやインターフェース名は環境に合わせてください。このルールは HTTP の中身を見るため、HTTPS で受けている場合は TLS を終端した後ろの通信を見せる必要があります。ログイン試行の制限そのものは、Fail2ban やプラグインのほうが手軽に実現できることも多いので、Snort には「ほかの仕組みで見えない通信を見つける」役割を期待するとよいでしょう。

併用するという選択

両者は競合するものではないため、規模が大きいサイトでは併用も選択肢になります。たとえば次のような分担です。

• AWS WAF：インターネットからの HTTP/HTTPS リクエストを入口で検査し、既知の攻撃や総当たりを止める
• ネットワーク型 IDS：VPC 内の通信を監視し、侵入後の不審な外部通信や、HTTP 以外のプロトコルの異常を検知する

AWS 上で後者を実現する方法としては、EC2 上で Snort を動かして VPC トラフィックミラーリングで通信を受け取る構成のほか、Suricata 互換のルールを使える AWS Network Firewall を使う構成もあります。どちらが適しているかは、管理の手間と必要な検査内容で決まります。対応するインスタンスタイプや機能の範囲は変わるため、導入前に公式ドキュメントを確認してください。

選ぶときのチェックポイント

• WordPress の前段に CloudFront や ALB があるか（無ければ AWS WAF は選べない）
• 守りたいのは Web アプリケーションへの攻撃か、サーバー全体への不審な通信か
• HTTPS の中身を検査する必要があり、それをどこで終端しているか
• サーバーやルールを継続して更新・調整する体制があるか
• 誤検知が出たとき、誰がどのログを見て判断するか

まとめ

• AWS WAF は AWS のサービスの前段で HTTP/HTTPS を検査するマネージドな WAF、Snort はパケットを検査するオープンソースの IDS/IPS で、役割が違う
• AWS 上で CloudFront や ALB を使う WordPress なら、Web 攻撃対策は AWS WAF が第一候補。Count で誤検知を確認してから Block にする
• VPS などでは AWS WAF は使えないため、サーバー型 WAF やプラグインと組み合わせ、Snort は検知の役割で使う
• 規模が大きいサイトでは、入口の WAF と内部のネットワーク型 IDS を併用する構成も考えられる
• 料金やルールセットの提供内容は変わるため、導入前に公式情報で確認する

• CloudFrontとAWS WAFでWordPressを守る構成
• WordPressにWAFを導入する手順