カテゴリ

キーワード

2022/02/07

シス開の日常

アトラスのAWS WAF通知―アップデートの変遷

こんにちは、L小川です。今回はWAFに関する話題です。

WAFのブロック/検知時にチャットツールへ通知するのはよくある運用かと思います。

アトラスでもWAFの検知情報をSlackに通知しており、通知の仕組みをアップデートしてきました。

今回はWAF通知方法の変遷についてご紹介します。

WAF通知の運用方法

WAF通知の仕組みをご紹介する前に、WAF通知の運用方法について簡単に説明します。

WAFのアクション「ALLOW・BLOCK・COUNT」のうち、COUNT（検知）の場合のみSlackに通知し、URIやクエリなどの情報からブロックすべきかどうかをエンジニアが判定します。

以下のキャプチャがSlack通知の例です。

画像：WAF_Slack通知例

WAFで検知した内容はGoogle スプレッドシート(以下スプレッドシート)で作成した管理表に記録し、IPアドレス/文字列ブロックの検討材料として使うほか、ブロック履歴としても使います。

AWS WAF (Classic)から始まった

まだAWS WAFv2がなく、今のAWS WAF Classicがまだ「AWS WAF」と呼ばれていた2017年頃からAWS WAFを使い始めました。

当時の通知フロー

  1. WAFでSQLiやXSSの攻撃を検出
  2. WAFのメトリクス数が1以上になったらCloudWatch アラームで検知
  3. CloudWatch アラームのステータスがALARMになったらSNSへ通知
  4. SNSから通知用Lambdaを起動し、Slackに通知
  5. 監視担当者が通知内容を確認・管理表に記載し、必要に応じてIPをブロック
  • 画像：WAF導入当初の通知フロー図

通知用Lambda(Python)では、Boto3のget-sampled-requestsメソッドを用いて、過去5分間のWAFの検知情報を取得します。

  • 画像：CloudWatchアラームをトリガにしたWAF情報取得の概要図

しばらく上記の方法で運用していたのですが、この方法だとステータスがALARMになっている間の攻撃については通知できません。

  • 画像：CloudWatchアラームをトリガにしたWAF情報取得の問題点

そこで、AWS WAFv2への移行に合わせてWAF検知情報の取得方法も改修することにしました。

そしてWAFv2へ

先述の方法ではステータスがALARMになったタイミングでSNSへ通知を送っていましたが、ALARMからOKになった際にもSNSに通知を送り、ALARMの間の情報を取得するようにしました。

※ Boto3のdescribe_alarm_historyメソッドで直近のアラームがOKになった時刻を取得し、get_sampled_requestsメソッドで現在時刻までのWAFの情報を取得します。

  • 画像：CloudWatchアラームのをトリガにしたWAF情報取得(改良版)の概要図

管理表への記入を自動化

監視対象サービス・WAFで検知される攻撃が増え、監視担当者の負担が大きくなってきたため、通知用LamdbaからスプレッドシートにWAF情報を自動記入するようにしました。

※ AWS lambda でgoogle spread sheetを操作したくなったのでやってみた [その1]を参考にしました。

攻撃によっては通知までに時間がかかる場合も

WAF情報の取りこぼしが無くなり、管理表への記入も自動化できた……と思ったのですが、残念ながらパーフェクトというわけにはいきませんでした。

通常、ステータスがALARMからOKになるまでに5分くらいかかるのですが、ステータスがALARMの間に別の攻撃を検知するとALARM状態の時間は延びていきます。

もしも定期的にアクセスし続けるような攻撃があり、ALARM状態が長く続いてしまうと、OKになるまで検知情報を通知できず、対応が遅れる原因になります。

  • 画像：CloudWatchアラームをトリガにしたWAF情報取得(改良版)の問題点

解決策

AWS WAFの機能アップデートで、2021年11月からWAFのログがCloudWatchLogsに出力できるようになりました。

先述のWAF通知が遅れる懸念を解消するため、CloudWatchLogsへのログ出力をトリガーに通知用Lambdaを起動することにしました。

CloudWatchLogsでLambdaサブスクリプションを作成すると、ログが出力されるたびにLambdaが起動されます。

CloudWatchLogsを使った場合のフローは、下図のようになります。

画像：CloudWatchLogsを利用したWAF情報取得の概要図

 

CloudWatch アラームのALARM/OKをトリガーにした方法では、ALARM状態が長く続くと通知するまでに時間がかかってしまいますが、CloudWatchLogsを使った場合では、検知・ログ出力のたびにLambdaが起動するので、大きなタイムラグは発生しません。

やってみた結果

通知フローは「WAF → CloudWatchLogs → Lambda」とシンプルなものになり、検知の取りこぼしや通知のタイムラグも生じないという、大変ありがたい機能アップデートでした！

通知用Lambdaについても、WAFのログを整形・通知するだけの処理になり、すばやく改修できるようになりました。

AWSの機能アップデートに便乗した改善でしたが、より速く正確にセキュリティ対応するための基盤になったと思います。

今回の記事がAWS WAFを利用する際の参考になれば幸いです。

それでは、またお会いしましょう！

関連記事