概要

Webアプリケーションを公開すると、システムの脆弱性を狙った攻撃的なリクエストもやってきます。Webアプリケーションに対するよく知られた攻撃を防ぐシステムは、WAF(Web Application Framework)と呼ばれています。AWSではこれをManaged Serviceとして提供しています。aumoではAWS WAFを運用しています。ここでは、AWS WAFを運用して分かった課題と解決法について説明します。

AWS WAFについて

本題に入る前に、対象サービスであるAWS WAFについて説明します。AWS WAFは、ロードバランサーやCloudFrontと協調して動作します。毎月数千円程度で良く知られた攻撃を防ぐことができます。最近の社会情勢を見ると、とりあえず設定しておいた方が良さそうです。

どんな攻撃を防げるか

攻撃を特定するルールが用意されており、それを適用することで防ぐことができます。ルールには、以下のものがあります。

コアルールセット (CRS) マネージドルールグループ

良くある攻撃方法の詰め合わせです。具体的には、以下のものがあります。

• UserAgent: nmapなど不正なボットやUA欠落
• SizeRestrictions: 極端に大きなリクエスト
• EC2MetaDataSSRF: Amazon EC2 メタデータを盗み出す試みがないか
• GenericLFI: ローカルファイルインクルージョン (LFI) を悪用する形跡がないか
• RestrictedExtensions: 読み取りや実行が安全でないシステムファイルの拡張子
• GenericRFI: RFI (リモートファイルインクルード) を悪用しようとする試み
• CrossSiteScripting: 一般的なクロスサイトスクリプティング (XSS) パターンがないか

管理者保護マネージドルールグループ

管理ページへの外部アクセスをブロックするためのルール。

• AdminProtection: 管理用に確保されている URI パスの有無

既知の不正な入力マネージドルールグループ

脆弱性の悪用または発見に関連するリクエストパターンをブロックする。

• JavaDeserializationRCE: Java デシリアライゼーション Remote Command Execution (RCE) の試行を示すパターンがないか
• Host_localhost_HEADER: リクエストのホストヘッダーにlocalhost を示すパターンがないか
• PROPFIND_METHOD: リクエストの HTTP メソッドにPROPFIND がないか
• ExploitablePaths: 悪用可能なウェブアプリケーションパスにアクセスする試みがないか
• Log4JRCE: Log4j の脆弱性の存在の有無

SQL データベースマネージドルールグループ

SQL インジェクション攻撃などの SQL データベースの悪用に関連するリクエストパターンをブロックする。

• SQLi: 感度低めでSQLインジェクション検知
• SQLiExtendedPatterns: 感度高めでSQLインジェクション検知

Linux オペレーティングシステムマネージドルールグループ

Linux 固有の脆弱性の悪用に関連するリクエストパターンをブロックする。

• LFI: Linux 固有のローカルファイルインクルージョン (LFI) 攻撃

POSIX オペレーティングシステムマネージドルールグループ

POSIXオペレーティングシステムに固有の脆弱性の悪用に関連するリクエストパターンをブロックする。

• UNIXShellCommandsVariables: Unix システムで実行されるウェブアプリケーションのコマンドインジェクション、LFI、パストラバーサルの脆弱性を悪用する試みがないか

Windows オペレーティングシステムマネージドルールグループ

PowerShell コマンドのリモート実行など、Windows 固有の脆弱性の悪用に関連するリクエストパターンをブロックする。

• WindowsShellCommands: WindowsShell コマンドインジェクション
• PowerShellCommands: PowerShell コマンドインジェクション

PHP アプリケーションマネージドルールグループ

PHP プログラミング言語の使用に固有の脆弱性の悪用に関連するリクエストパターンをブロックする。

• PHPHighRiskMethodsVariables: PHP スクリプトコードインジェクションの試行がないか

WordPress アプリケーションマネージドルールグループ

WordPress サイト固有の脆弱性の悪用に関連するリクエストパターンをブロックする。

• WordPressExploitableCommands: 脆弱なインストールやプラグインで悪用される可能性のある高リスクWordPress コマンドがないか
• WordPressExploitablePaths: 悪用しやすい脆弱性があることがわかっているWordPressファイルがないか

Amazon IP 評価リストマネージドルールグループ

ボットやその他の脅威に関連付けられている IP アドレスをブロックする。

• AWSManagedIPReputationList: 悪意のあるアクティビティに積極的に関与していると特定された IP アドレス
• AWSManagedReconnaissanceList: 偵察を実行している IP アドレス
• AWSManagedIPDDoSList: DDoS アクティビティにアクティブに関与していると識別された IP アドレス

匿名 IP リストマネージドルールグループ

VPN、プロキシ、Tor ノード、ウェブホスティングプロバイダーなどからのリクエスト。

• AnonymousIPList: クライアントの情報を匿名化することがわかっているソース (TOR ノード、一時プロキシ、その他のマスキングサービスなど) の IP アドレス
• HostingProviderIPList: ウェブホスティングプロバイダーとクラウドプロバイダーの IP アドレス

設定方法

基本的には、必要なルールを選んで設定するだけです。特定の条件下でのみ適用するような例外処理も可能です。ここでは、それらの設定方法について説明します。

基本

AWS WAFの画面を開き、”Create Web ACL”ボタンをクリックします。

名前とWAFの適用対象リソースを選択して、Nextボタンをクリックします。

次の画面で”Add Rules”の”Add managed rule groups”をクリックすると、ルールを選択可能となります。

ここまでで説明したルールは、”AWS managed rule groups”の”Free rule groups”にあります。

必要なルールのトグルをonにすると、”Edit”というボタンが現れます。これをクリックすると、ルールの詳細設定画面が表示されます。

rule actionは、こだわりがなければ空欄にしておくと、デフォルトの動作となります。”Override rule group action to count”のチェックをonにすると、検知した攻撃をブロックせずにカウントだけする状態となります。最初はここをonにしておき、問題なければチェックを外してブロックします。あとはNextをクリックしていけば、設定が作られます。

例外

特定のURLでは、ルールを解除したいケースがあります。そのような場合、ルール設定ではCountにしておきます。

すると、対象リクエストには、検知したというフラグが立っているがブロックされていない状態となります。カスタムルールを設定して、「フラグが立っている」AND「URLがxxxでない」の場合ブロックするようにします。

運用して分かった課題と解決法

ここからが本題です。WAFのルースを適用したところ、想定外の課題が発生しました。ここでは、それらの課題と解決法について説明します。

画像がアップロードできない

画像がアップロードできないとの連絡を受けました。画像情報はHTTP POSTのrequest bodyに載せて、送信しています。「コアルールセット (CRS) マネージドルールグループ」の中に、サイズ超過をチェックするルールがあります。対象ルールであるSizeRestrictions_BODYは、8 KB (8,192 バイト) を超えるリクエストボディを検査します。そのため、8KBを超える、ほぼ全ての画像が検知に引っかかっていました。上記例外設定手法で、SizeRestrictions_BODY をカウントのみにして、対象API以外をブロックするカスタムルールを設定しました。

大きなフォームデータ送信

一部のフォームデータが更新できないとの連絡を受けました。確認すると、対象フォームのデータが8KBを超えていました。例外が増えすぎたため、例外設定したカスタムルールを削除してSizeRestrictions_BODYを無効化しました。

利用している外部サービスがBadBot判定

適用前にカウントのみで適用したところ、利用している外部サービスが引っかかっていました。「コアルールセット (CRS) マネージドルールグループ」の中にUserAgent_BadBots_HEADERがあります。説明には、リクエストが不正なボットであることを示す一般的な User-Agent ヘッダー値を検査します。パターンの例には、nessus、nmap などがあります。nmapなどの明らかなBadBotだけでなく、良く知られたSaaSサービスも含まれていました。上記例外設定手法で、UserAgent_BadBots_HEADERをカウントのみとし、対象サービスのUser-Agentを例外指定するカスタムルールを設定しました。

外部サービスと通信できない

HTTP Endpointを提供している外部サービスからリクエストが失敗するとの連絡を受けました。外部サービスからは、HTTPを使ってサービス連携しています。つまり、相手側もシステムなので、クラウドもしくはオンプレデータセンターで運用されている可能性が非常に高い状態です。「匿名 IP リストマネージドルールグループ」の中に、HostingProviderIPListがあります。これは、エンドユーザートラフィックのソースになる可能性が低いウェブホスティングプロバイダーとクラウドプロバイダーの IP アドレスのリストです。つまり、これにかかっている可能性が非常に高い状態です。相手側のIPレンジが不明だったため、HostingProviderIPListを無効化(Count)することで対応しました。

どんな攻撃がどのくらいブロックされたか

ブロックした数としては、BadBotsが圧倒的多数で、次がIPReputationListです。しかし、攻撃対策ルールも数は少ないがほぼ検知されています。おすすめ設定としては、「コアルールセット (CRS) マネージドルールグループ」と「Amazon IP 評価リストマネージドルールグループ」を設定し、他は必要に応じて設定するのが良さそうです。

まとめ

アプリケーションを最新の状態に保ち、脆弱性を作り込まないことが最も重要です。しかし、状況によって放置されるシステムが発生してしまうことがあります。WAFを入れることで、脆弱性を隠すことができます。皆様のお役に立てれば幸いです。