SRE部 佐竹です。
今回は AWS WAF と WafCharm の運用知見に関するブログです。
はじめに
WafCharm に関しては以前ブログで取り上げました。
上記ブログ内の最下部に掲載しました以下の構成図の通り、WafCharm の Web ACL Config 1つに対しては WafCharm の Web Site Config を複数設定することができます。
これはつまり、1つの AWS WAF の Web ACL に複数の ALB をアタッチできることを示しています。また WafCharm では Web ACL を1つ作ると、5,000 円/1WebACL の月額 が発生するため、Web ACL の数は必要ではない限り増やさないほうが安く運用できます。
そういうわけで、Web ACL を1つ作成しこれを共有利用している状態となるわけですが、この時に少々困ったことが起きます。
WafCharm から送信されるアタック検知アラート
WafCharm の Notification を有効にしている場合、設定したメールアドレスに WafCharm Attack Detected. という件名のメールが送信されます。以下がその例です。
Attacks as follows were detected This report includes up to 10 attacks detected in every buffer interval. If you need to check more information and attacks, visit your AWS console. WebACL Name(WebACL ID): waf-acl-for-wafcharm(exxxxxxx-xxxx-9999-xxxx-xxxxxxxxx6b) Matches Rule Name: XSS-qs-001 Time(UTC): Tue, 15 Sep 2020 08:44:06 GMT Source IP: 111.222.111.222 Source Country: JP Action: BLOCK URI: /japan/hoge.php Query String: id=%3Cscript%3Ealert(%27XSS%27);%3C/script%3E Matches Rule Name: XSS-qs-001 Time(UTC): Tue, 15 Sep 2020 08:44:13 GMT Source IP: 111.222.111.222 Source Country: JP Action: BLOCK URI: /japan/hoge.php Query String: id=%3Cscript%3Ealert(%27XSS%27);%3C/script%3E
上記ログは、私が検証のために XSS を実行した際のアラートです。
アラートからどのシステムで問題があったのかわからない
上記アラートを見ていただけるとわかるのですが、URI はフルパスが表示されているわけではありません。Web ACL と ALB が1:1で紐づいている場合は、「どの Web ACL で発生したのか」を見れば対象のシステムが特定可能ですが、先に書いたように複数の ALB を1つの Web ACL に紐づいている場合はここから「どの ALB で発生したのか？」＝「どのシステムで発生したのか？」を追いかける必要があります。
これを追いかけるには、AWS WAF のログを確認します。AWS WAF のログの設定は以下のナレッジセンターの記事を参照ください。
本記事では AWS WAF のログ出力は設定済の前提で話を続けます。
ブロックが発生した ALB を特定する
CloudWatch メトリクスを確認する
以下のメトリクスを表示します。
AWS/WAFV2 BlockedRequests WebACL: waf-acl-for-wafcharm Region: ap-northeast-1 Rule: ALL
BlockedRequests にて CloudWatch で WafCharm のアラートに記載がある Time(UTC) の時間帯にブロックがあったのか確認をします。今回は 2020-09-30 17:25 UTC にブロックされた記録があるので、これを調査することにします。
AWS WAF のログが出力されている S3 バケットに移動する
どの S3 バケットに出力されているのかわからない場合は、以下の手順で確認可能です。
AWS WAF > Web ACLs > waf-acl-for-wafcharm とマネジメントコンソールを移動し Logging and metrics のタブを選択してください。Edit logging を押下すると、どの Amazon Kinesis Data Firehose Delivery Stream が紐づいているのかがわかります。次は紐づいている Amazon Kinesis Data Firehose Delivery Stream の設定を確認します。
「こちら」のリンクをクリック頂くと、東京リージョンの Kinesis Data Firehose delivery streams が表示されます。この一覧から、先ほど調べたものと同じ Name のものを確認します。右端に出力先となっている S3 が記載されています。
なお、マネジメントコンソールでは S3 バケットの名称のみが表示されており、どのAWSアカウントに存在するのかの情報は確認できないようです。リンクからジャンプしても別のAWSアカウントに S3 バケットを作成している場合は表示されませんので注意してください。
ブロックされた日付のログが含まれている.gzファイルを開く
S3 バケットに移動できたら Amazon S3/waf/アカウントID/2020/09/30/17 とディレクトリを掘り進めていきます。
ファイル名を見て、ブロックされた日付のログが含まれている.gzファイルを選択します。
選択するとメニューが表示されるので、右端にある「Select from」を押下して実行します。
S3 Select を実行し httpSourceId を確認する
S3 Select 実行のための設定を行います。
- File format : JSON に変更します
- JSON type : このままで問題ありません
- Compression : GZIP が選択されていることを確認します
「Show file preview」を押下した後「Next」を押下して継続します。次に以下の画面表示に遷移します。
エディタには以下のクエリがデフォルトで表示されています。
select * from s3object s limit 5
本クエリのままで一覧に表示されるJSONは ALLOW を含んだログになるため BLOCK に絞り込みを行います。下記のクエリを実行して、ブロックされたログを表示させます。limit の 1 は必要に応じて増やしてください。
select * from S3Object s where s."action" = 'BLOCK' limit 1
このクエリを「Run SQL」から実行すると以下の通りになります。
ブロックのログが表示されていることがわかりました。また httpSourceId が確認できます。
httpSourceId
httpSourceId は、「ウェブ ACL トラフィック情報のログ記録」に記載があるように、以下の通りの項目です。
httpSourceId
ソース ID。このフィールドには、関連する Amazon CloudFront ディストリビューションの ID、API Gateway の REST API、または Application Load Balancer の名前が表示されます。
この通り、httpSourceId には AWS WAF を紐づけたリソースが表示されます。今回は ALB ですが、以下の表記になっていました。
"httpSourceId": "AWSアカウントID-app/ELB名/ターゲットグループ",
この情報を利用して、どのシステムにアラートが発生したのか確認が可能となります。
なお、クエリは以下のように改変することによって、表示項目を減らしたりできるので状況に応じて使い分けてみてください。
select s."action", s."httpSourceId" from S3Object s where s."action" = 'BLOCK' limit 1
まとめ
今回は WafCharm のアラートが発生（つまり AWS WAF でブロックが発生）した場合に、どのシステムが関係しているのかを調査する方法について記載させていただきました。ブログでは AWS WAF のログからブロックが発生した ALB を特定する方法を具体的に記載しました。本調査は AWS WAF の保守を行う場合の基本的な調査手法になってくると思いますので、是非押さえておきたい手順です。
ではまたお会いしましょう。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023 Japan AWS Top Engineers/2020-2023 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
