AWS WAF 運用時に考えた5つのこと
はじめに
AWS WAFを運用する中で手を入れたポイント、あとになって 「設定しておいて良かった」 あるいは 「考慮すべきだった」 となりそうな項目について、入門者の方向けにまとめました。
このブログは、以前書いたブログ記事の続編・補完的な内容です。そのため「これからWAFを導入するぞ！」という場合には、こちらを先にお読み頂けると良さそうです。
1. ログの分析
WAFを構築してルールグループを決定した後も、定常的にログを確認しどのようなアクセスがBlock/Countされているかは確認しておくことをおすすめします。基本的なことですが、運用上もっとも大切なことだと個人的に考えているため、この「ログの分析」を1番にあげました。
可能であれば、現在利用していないルールグループについてもCountアクションで運用し、ログを確認しておくと良いと個人的には思っています。
理由は以下のとおりです。
- そもそも平常時のログを確認しておかなければ、異常を見つけることはできないから
- アクセス傾向などを相対的に比較するために、平時のログが必要であるから
- クリティカルな脆弱性に早急に対応したいとなった際、すぐに新規ルールを適用して正規のアクセスをブロックしてしまわないかの判断を行うには、予めCountアクションで運用し、ログを分析して誤検知が出ないことを確認しておけると良いから
ログ出力内容の一部削除
一方で、逆にログ出力にかかる費用を抑えたい場合であったり、センシティブな情報を含む場合、フィルタリングを設定する、またはログの一部の出力をマスキングする(Redactする)ことも可能です。
特定のfieldのRedact設定のみであれば、以下のチェックボックスから簡単に設定できます。
分析方法
次に具体的なログの分析方法ですが、最近ですとダッシュボードが充実しているためそちらでアクセス傾向を確認し、詳細を見るにはツールやCLIスクリプトを作成しておくと良いと思います。（以前の記事で触れているためここでは割愛します）
また最近では大規模な環境だとSIEM on AWSを検討しても良いかもしれません。
SIEM on AWS
こちらはOpenSearchを用いたログ分析基盤のCloudFormationテンプレートで、AWSの中の人が設計・保守されているようです。SIEMですのでWAF以外のAWSに関連する多様なログも扱うことができ、非常に強力なセキュリティソリューションです。
ある程度ログ分析に費用がかけられる場合、またはAWSアカウントやWebACLの数が多い場合には選択肢の一つになると思います。
2. ホワイトリスト運用と優先度
WAFを運用する中で、特定の条件下では恣意的にアクセスを許可したいという要件が稀にあります。たとえば、特定のIPアドレスからのアクセスについてはWAFのルールすべてを適用しない、といった具合です。
この場合、IPアドレスのリストを予め登録しておき、そのリストを元にマイルールを作成・適用するという手順になります。その後、登録されたIPアドレスから模擬攻撃のようなリクエストを行ったとしても、WAFでBlockされなくなるはずです。
さまざまな用途が考えられますが、例えば監視サービスで利用されているアクセス元のIPアドレス、脆弱性診断用に用いられる信頼できるIPアドレスなどは、登録しておいても良いかもしれません。
ところで、WAFルールグループの設定時に考えなくてはならないことの一つに、ルールグループの適用における優先度があります。上述のWAFのホワイトリストを利用している場合には、必ずそのホワイトリストの優先順位をBlockアクションのルールグループより高く設定しておく必要があります。
実際の所、少数のBlockアクションによるシンプルな運用であれば、どのルールグループを優先するか/しないかはそこまで重要ではありません。しかし、ログ分析をする中でどのルールで Terminate したかを見極めたい場合、つまりどのような性質の攻撃かを判断したい場合に、優先順位を考慮しておくべきだと考えられます。具体的な例としては、IPリピュテーションに基づくリストによるブロックは、優先順位を低く設定しておくことで、もし別のルールによって検知された場合にはそちらでTerminateし攻撃の性質がわかる可能性があります。もし逆に優先度を高く設定しているとIPアドレスのみで判定され、それより低い優先度のルールでは検査されません。
以上をまとめると、おすすめの優先度は以下のようになります。
- ホワイトリスト（IPリスト等）
- Countアクション運用ルールグループ
- Blockアクション運用ルールグループ
- Blockアクション運用IPリスト
3. WAF Bypassを防ぐために
WAFの運用で認識しておきたいものの一つに、 WAF Bypass があります。
文字通り、WAFを迂回できてしまうリクエスト(方法)が存在し、そのための対策を講じる必要があります。
セキュリティ強化のためにWAFを導入している場合、根本的な考え方として脆弱性全体の管理は別のサービスやツールで行い、WAFは脆弱性の排除を「補完する」位置づけと考えるべきかもしれません。しかしそうであったとしても 、なかったとしても、可能な範囲でBypassの対策を実施したいものです。
たとえば、AWS WAFで検査するリクエストには 検査できるバイト数に制限があり、 その上限の制約を逆手に取った攻撃手法が考えられるそうです。
調べてみると、Body、Header、Cookieなどそれぞれに制限があり、以下の公式ページに詳細が書かれています。
実はこの攻撃手法に対応できるサイズ制限に関するルールがAWSManagedRulesCommonRuleSet ルールグループにはあり、このCommonRuleSetルールグループを導入しておくことで当該のBypassを防ぐ効果が期待できます。
ルールグループ自体の導入が難しい場合であっても、ルール単位での導入であれば誤検知も少なくなりそうですので、一度は検討しても良いと思います。
4. カスタムレスポンス
WAFのレスポンスを加工し、Blockした際のレスポンスをデフォルトから変更することが可能です。たとえば、レスポンスコードを通常の403から429など任意のコードに変更することができます。
この機能は、マイルールを作成した場合（レートリミットの設定含む）では、比較的利用しやすいです。
しかし、マネージドルールでカスタムレスポンス機能を使う際は、ラベルを利用して別途マイルールを設定する必要があります。
具体的な方法は、以下の記事が参考になります。
ただしこのラベル機能を使ったWAF運用は複雑性が上がり、どのような挙動が設定されているかが一見わかりにくく、またログ分析も場合によっては難しくなるため、注意が必要です。個人的には、できるだけラベルを利用せずにWAFを運用したいです。
さらに、カスタムレスポンスの設定そのものについて、否定的な見方もあります。
カスタムレスポンス機能で WAF による BLOCK が実施されたことがわかるように設定することは、レスポンスの違いによって、攻撃者になんらかの推測可能な情報を与えることになり、セキュリティの観点からリスクになる可能性がある
以上のことから、WAFの機能としてはありますが、ケースバイケースで慎重に利用するほうが良さそうです。仮に、ルールの効果検証で一時的にレスポンスをわかりやすくしたい、といった場合には適しているかもしれません。
5. WAFフェイルオープン設定
ALBに紐づけたAWS WAFをフェイルオープ設定で運用することが可能です。
この設定を有効にしておくと、WAF障害発生時にリクエストを通過させることが可能です。一時的にWAFによる検査は行われなくなりますが、システムの可用性を重視したい、またはSLA等なんらかの要件がある場合に検討します。
実はこの機能は、ALB側に設定箇所があり、少しわかりにくいですがロードバランサーの「属性」を編集することで有効にできます。
おまけ：AWS以外のマネージドルールの検討
AWS WAFでは、AWSマネージドルール以外にも他のセキュリティベンダーが提供するマネージドルールを導入することができます。2023年末の時点では7社(19ルールグループ)から提供されており、今後もこのルールは増えそうです。
もし未検討の場合には、一度確認してみることをおすすめします。というのも、容易に各社のルールを試すことが可能であり、そのメリットは非常に大きいと考えられるからです。
それぞれのマネージドルールは、WebACLというAWS WAFの共通化されたプラットフォームの上で動作し、そのため有効/無効がAWSのマネージドコンソール上で完結します。個別のサービスを契約する必要はありません。またCountアクションを用いれば、それぞれのルールグループをある程度は評価・比較することが可能でしょう。
請求はAWSの利用費に含まれ、AWSのマネージドルールと同様に比較的廉価に利用できるルールもあります。
もし今後、各社のWAFやセキュリティサービスへの切り替えを検討する場合には、簡単な事前検証として利用することもできるかもしれません。（もちろんサービスとして別物である以上、技術的な仕様やサービス体制など相違点も多いはずですが）
おわりに
AWSのマネージドサービスの中には、構築/移行の段階でほぼほぼ構成が固まり、以降は手がかからないサービスも多いのですが、AWS WAFに限っては運用の中でチューニングがほぼ必須と言えます。
逆に言うと 設定の自由度が高く、柔軟性のあるサービス で、DoS攻撃対策やインジェクション対策を始めとして複数の用途に活用できるセキュリティ製品ではないかと思っています。
ログの分析を中止に据え、運用中の設定をいま一度見直していただくと、新たな発見があるかもしれません。
どなたかの参考になれば幸いです。
Discussion