AWSセキュリティ【AWS WAF】: Web ACLs 作成

以前の投稿で、AWS提供のOWASP Top 10 テンプレートファイルを使って、「AWS WAF Classic」にWeb ACLを設定したが、あちらはそれなりに骨の折れる作業でした。

そして、AWS WAF Classic に対して、New AWS WAF(V2)には、以下のメリットがあります。

  • AWSマネージドルールと呼ばれる機能で、直接作成しなくとも、複雑なルールを調整できるようになり、SQLインジェクションやクロスサイトスクリプティングなど、一般的脅威から保護できます。
  • AWS内チームによって、新しい脅威が発見されると即座にルールが追加されるので、新しい脅威に対しても守られます。
  • Web ACLキャパシティユニット(WCU)導入により、Webアクセスコントロールリスト(ACL)ごとの10個のルール制限はなくなり、何百ものルールを作成できます。
    (WCU制限は1500だが、今回は AWSManagedRulesCommonRuleSet=700、AWSManagedRulesPHPRuleSet=100、AWSManagedRulesSQLiRuleSet=200 で合計=1000 で1500以内に収まった)
  • WebACLのルールを構成するステートメントに、AND/OR/NOT演算子など組み合わせることで、より複雑なルールロジックが可能になりました。

そして、AWS WAF の アクセスコントロールの仕方の情報はあまり世の中に出回っていなくて、以前投稿の OWASP Top 10 テンプレートによる設定も、かなり苦労した感があります。そして今回は、AWSドキュメントからの情報によって、AWS WAF ver2 でマネージドルールを適用することができました。 OWASP Top 10 テンプレートよりも簡単にセットアップできたのでお勧めです。

Web ACLs 生成

WebACLs名を
「Mikolabo-WebACLs」
とした

WebサイトのALB配下に
仕掛けるので、
「Regional resources
(ALB、API-GW、AppSync)」
を選択

「Add AWS resources」
をクリック

Webサイトの上位ALBを選択

Webサイトの上位ALBをチェックして

「Next」をクリック

マネージドルールの適用

「Add rules」→
「Add managed rule groups」をクリック

AWS WAFは、ウェブリクエスト本文の最初の8,192バイト(8 KB)のみを検査します。
Webリクエストの本文を検査する管理ルールグループを使用する場合は、本文の検査の前にサイズ制約ルールを実行して、本文のサイズが8KBを超えるリクエストをブロックすることを検討してください。

(・・と警告出るが、今回は対処しない)

AWS WAFに組み込み可能なビルトインルールセット

Core rule set

コアルールセット (CRS) ルールグループには、ウェブアプリケーションに一般的に適用可能なルールが含まれる。
これらは、OWASP の出版物や多くの共通脆弱性識別子 (CVE) に記載されているものを含め、幅広い脆弱性の悪用から
保護するのに有用。すべての AWS WAF ユースケースでこのルールグループを使用することの検討を推奨

PHP application

PHP アプリケーションルールグループには、安全でない PHP 関数のインジェクションなど、PHP プログラミング言語
の使用に固有の脆弱性の悪用に関連するリクエストパターンをブロックするルールが含まれる。
これにより、攻撃者が許可されていないコードまたはコマンドをリモートで実行できる脆弱性の悪用を防ぐ。
アプリケーションが連結するサーバーに PHP がインストールされている場合は、このルールグループを使用すること
の検討を推奨

SQL database

SQL Database ルールグループには、SQLインジェクション攻撃などの SQL データベースの悪用に関連する
リクエストパターンをブロックするルールが含まれる。
これにより、不正なクエリのリモートインジェクションを防ぐことが可能。
アプリケーションが SQL データベースと連結している場合は、このルールグループを使用することの
検討を推奨。

選択されたルールを確認

WCUの合計を確認

“デフォルトアクションを
許可(Allow)か
拒否(Block)を選択”

ルールセットを選択して、
「Move up」「Move Down」で
ルールの優先度(適用順序)を
指定できるが
今回はこのまま。

サンプルリクエストを有効にする

サンプルリクエストを無効にする

除外してサンプリングされた
リクエストを有効にする

「Next」をクリック

設定したWebACLsの内容を確認

(WebACLs)をクリック

AWS WAF → WebACLs → (WebACLs) → Overview

WebACL設定直後のアクセスコントロール状況を確認できる。

AWS WAF → WebACLs → (WebACLs) → Rules

AWSManagedRulesCommonRuleSet を展開

AWS WAF → WebACLs → (WebACLs) → (Rules) → Details

ビルトインルールセットの内容を確認できる。

AWS WAF → WebACLs → Bot Control

Bot Controlは、TLS ハンドシェイク、HTTP 属性、IP アドレスなどのリクエストメタデータを分析することで、ボットの発信元と目的を特定します。

特定されるボットはスクレーパー、SEO、クローラ、サイトモニターなどのタイプにカテゴリー分けされます。

Bot Controlが認識した望ましくないボットに対しては、そのトラフィックをブロックできます。

ユーザーは、WAF 設定の中に定義されたデフォルトのアクションをシンプルに受け入れ、望ましくないボットトラフィックをブロックすることができます。

また、その設定を独自にカスタマイズすることも可能です。

例えば、レスポンス機能をカスタマイズして、ボットの識別結果に応じたレスポンスを返させたり、新しいヘッダーを挿入してそのリクエストにフラグを付けたりができます。

AWS WAF → WebACLs → Assciated AWS resouces

WebACLを
Amazon API Gateway REST API、Application Load Balancer、
AWS AppSync  に関連付けます。

WebACL⇔AWSリソースの関連付けON/OFF、複数の関連付け
(WebACLとAWSリソースの関係は
 1対多)を設定できます。

AWS WAF → WebACLs → Custom response bodies

AWS WAFを使ってリクエストがブロックされた場合のHTTPステータスコードをカスタマイズできます。

  • 特定URLへリダイレクトするよう設定できます。
  • ブロック応答がステータスコード403で固定だったものが、200番台から500番台までのステータスコードを返せます。
  • レスポンスボディも変更できるので、ブロック時柔軟な対応ができます。

AWS WAF → WebACLs → Logging and metrics

AWS WAFから直接CloudWatch Logs、S3に出力できます。

注意点

  • CloudWatch Logsロググループ名およびS3バケット名はaws-waf-logs-から始まる名前です。
  • CloudWatch Logs
    WebACLと同じリージョン、同じアカウントに作成すること
    CloudFront用のWebACLはバージニアリージョンにロググループを作成します
  • S3バケット
    異なるリージョンのバケットにも出力可能
    WebACLと異なるアカウントに出力可能(設定要)
    AWS WAFはSSE-S3またはSSE-KMSによる暗号化をサポート(AWS管理キーはサポート外)

AWS WAF → IP sets

IPアドレスでアクセス制限をかけられます。

以下のようなケース

  • 開発環境には自社ネットワークからしかアクセスさせない
  • 本番環境の管理系セグメントには、管理セグメントからしかアクセスさせない

AWS WAF → Regex pattern sets

正規表現パターンセットを作成

AWS WAF → Rule groups

WebACLでは、個々のルールアクションをcountに設定し、結果のルールグループアクションをcountに上書きすることで、ルールグループとそのルールの動作を変更できます。

ルールグループのテスト、ルールグループ内のルールからの誤検出の特定、管理ルールグループによるリクエストの処理方法のカスタマイズなどの作業に役立ちます。

AWS WAF → AWS Marketplace

AWS WAF MarketplaceはAWS WAFサービスのためにサードパーティが用意したルールセットを使ったサービスです。

最初から整備されたルールなので、提供元サードパーティのサポートを受けながら運用ができます。
WAFが影響したトラブル時の判断などに対応しやすくなると思われ、運用面での不安を軽減できると思われます。

数回クリックするだけで管理されたルールを購読し、高価なプロフェッショナルサービスにサインアップすることなく、使用するものに対してのみ支払うことができます。
管理ルールは自動的に更新され、契約やサブスクリプションの確約はありません。管理ルールは時間単位で課金されます。

AWS WAFによって、意図せず通常の通信がブロックされたときの対応

WordPress管理画面からの投稿処理が変更できなくなったり、All-in-One WP Migration でのバックアップ、インポート処理が途中で止まったりしたが、WAFの影響であった。
WAFを無効化したら、処理できるようになった!!

WAF → Web ACLs → OverView をクリックして、どのような通信でブロックされたかを確認する。
1ページ目から確認していって、12ページ目に Block を確認できた。

WordPress管理画面から投稿処理をして、エラー(403 Forbidden)が表示された。

そのときの画面のURIが「http://35.78.52.203/wp-admin/post.php」だったので、上イメージから確認して、
「Rule inside rule group」の欄にある「AWS#AWSManagedRulesCommonRuleSet#SizeRestrictions_BODY」
がBlockしたと分かる。

Block された通信の内容も確認できる。

AWS WAF → Web ACLs → 
Mikolabo-WebCALs → 
AWS-AWSManagedRulesCommonRuleSet

をクリック、さらに「Edit」で

「AWS-WSManagedRulesCommonRuleSet」の内容を変更できる。

個別のルールを変更できる。
(左の操作で「SizeRestrictions_BODY」
 だけを無効化する)

「SizeRestrictions_BODY」だけを無効化されているのが分かる。

このように、ルールは無効化できるが、上記操作だけでは解決できなかった。
この操作をルール1つずつに適用して行って、操作が可能になる個別のルールを探っていけば良いのだが、大変なので、
メンテナンスの前に、WAFの機能をまとめて一時的に無効化することにした。

WAFのルールを無効化してメンテナンスする

メンテナンス時には下記の操作(「AWS-AWSManagedRulesCommonRuleSet、PHP application」 について、全項目を無効化)を実施してメンテナンス作業を終了したら、有効化した。

Core rule set のルールをまとめて無効化して

メンテナンスが終わり次第、
有効化することにした。

「PHP application」も同様に無効化。

このWAFルールの一時的な無効化によって、All-in-One WP Migration によるバックアップ、インポート操作と投稿処理ができるようになった。