はじめに

Wordpressサーバーを運用するにあたり、セキュリティー対策として、AWS　WAFを導入する機会があったのですが、思わぬエラーが出たため、書き留めます。

環境構築図

WAFの概要

流れ

WAFの導入
導入直後、サイト閲覧
導入後、画像アップロード時、エラー
uploadのパスのみ、コアルールセットを適用しない方法
導入後、問い合わせフォームでのエラー
ログの保存方法

WAFの導入

WAFの導入方法についてはこちらの記事を参考にしてください。

ルールの詳細はこちら

導入方法でも説明されていますが、WAF導入時は必ずCountアクションに設定してください。
正しくWordPressのサイトを閲覧していても、どこかでBLOCKされる可能性があります。

私が今回導入したルールは、こちらです。

Wordpress application
SQL database
PHP application
Linux operating system
Core rule set
Anonymous IP list
Amazon IP reputation list

導入直後、サイト閲覧

導入直後、サイトを適当に閲覧した後に、WAFのCOUNTを確認してみると、コアルールセットのNoUserAgent_HEADERがCOUNTされていました。

NoUserAgent_HEADERとは、「HTTP User-Agent ヘッダーのないリクエストをブロックする」という意味です。
UserAgent_HEADER自体、chromeでは、2023年には、廃止を決めているなど、特にブロックする必要はありません。

そのため、NoUserAgent_HEADERは、COUNTモードにしたまま、他のすべてのルールをBLOCKにしました。

導入後、画像アップロード時、エラー

Wordpressでメディアアップのロードで画像がアップロードできないエラーが発生しました。

サーバーの負荷が高いか十分なリソースがないため画像の後処理に失敗しました。
もっと小さな画像をアップロードしてみてください。推奨する最大サイズは2500ピクセルです。

サーバーから予期しないレスポンスがありました。
ファイルは正しくアップロードされているかもしれません。
メディアライブラリもしくはページをリロードして確認してください。

WAFを確認してみると、コアルールセットの以下2つのルールがBLOCKされていました。

CrossSiteScripting_BODY

組み込み XSS 検出ルールを使用して、URI パスの値を検査し、一般的なクロスサイトスクリプティング (XSS) パターンをブロックします。AWS WAF。パターンの例には、などのスクリプトあります。

SizeRestrictions_BODY

リクエスト本文のサイズが最大 10,240 バイトを超える場合、ブロックする

SizeRestrictions_QUERYSTRING

URI クエリ文字列の長さが最大 2,048 バイトを超える場合、ブロックする

対処法は3つ

COUNTモードにする
管理画面ページを使用するIPが限られている場合、ホワイトリストにIPアドレスを追加します。
BLOCKされたURIであるwp-admin/upload.php（仮）のみコアルールセットを適用せず、他すべてのURIは、上記2つのルールも含めて、すべてのルールを適用する。

セキュリティー面を考えると2が最もよいです。

2,3に関して、方法を説明いたします。

ホワイトリストにIPアドレスを追加する方法は、下記の記事参考にしてください。

uploadのパスのみ、コアルールセットを適用しない方法

正規表現パターンセット（Regex pattern sets）を作成します。
ルールグループを作成します。

名前を決めます。CloudWatchメトリクスにも記録されるようです。
正規表現パターンセットのuploadとマッチしたら、ALLOWするルールを作成します。日本語訳するとわかりやすいです。

↓日本語訳

作成したルールグループをWAFに加え、コアルールセットよりも優先順位を高くすると、wp-admin/upload.phpのみコアルールセットが適用されずに、ALLOWされます。

ちなみにwp-admin/upload.php以外のパスもコアルールセットに入れたくない場合、正規表現パターンセットを作成し、ルールグループに追加するとよいです。

WAF導入後、問い合わせフォームでのエラー

問い合わせフォームを送るとき、エラーが起き、送れませんでした。
コアルールセットの以下1つがBLOCKされていました。

GenericRFI_BODY

リクエスト本文の値を検査し、ウェブアプリケーションの RFI (リモートファイルインクルージョン) を悪用しようとするリクエストをブロックします。パターンの例には、:// などがあります。

先程の対処法を参考に、対処しましょう。

WAF導入後、phpMyAdminでsqlのエクスポートができない(404エラー)

AWSManagedRulesSQLiRuleSetのSQLi_QUERYARGUMENTSのルールでブロックされていました。

SQLi_QUERYARGUMENTS

組み込みの AWS WAF SQL インジェクション match ステートメントを使用して、すべてのクエリパラメータの値に、悪意のある SQL コードに一致するパターンがないかを検査します。

対処法

こちらは、sqlのエクスポートするIPが特定している場合、特定のIPのみ許可（ホワイトリスト）するようにしましょう。
先程の対処法は、パスに対して、コアルールセットよりもルールグループを優先させる方法でしたので、
同様にパスではなく、特定のIPのルールグループを作成し、AWSManagedRulesSQLiRuleSetよりもルールグループを優先させるとよいです。

WordPressでBLOCKされやすいWAFルール

今回のWordPressにWAFを適用するにあたり、以下の4つのルールがBLOCKされましたので、COUNTにしております。
もしくは、特定のIPや特定のパスのみルールを適用しない方法もありますので、状況に応じて対応しましょう。
同様の構築をする際に、参考になればと思います。

コアルールセット:AWSManagedRulesCommonRuleSet

ルール	意味
NoUserAgent_HEADER	HTTP User-Agent ヘッダーのないリクエストをブロックする
CrossSiteScripting_BODY	組み込み XSS 検出ルールを使用して、URI パスの値を検査し、一般的なクロスサイトスクリプティング (XSS) パターンをブロックします。AWS WAF。パターンの例には、などのスクリプトあります。
SizeRestrictions_BODY	リクエスト本文のサイズが最大 10,240 バイトを超える場合、ブロックする
SizeRestrictions_QUERYSTRING	URI クエリ文字列の長さが最大 2,048 バイトであることを確認します。
GenericRFI_BODY	リクエスト本文の値を検査し、ウェブアプリケーションの RFI (リモートファイルインクルージョン) を悪用しようとするリクエストをブロックします。パターンの例には、:// などがあります。

SQL データベース:AWSManagedRulesSQLiRuleSet

ルール	意味
SQLi_QUERYARGUMENTS	組み込みの AWS WAF SQL インジェクション match ステートメントを使用して、すべてのクエリパラメータの値に、悪意のある SQL コードに一致するパターンがないかを検査します。

ログの保存方法

下記の記事通りすると、COUNTとBLOCKのみWloudWatchLogsに保存できます。

「aws-waf-logs-」で始まるロググループを作成する必要あり

WordPress + AWS WAF設定時の注意点