[セッションレポート]AWS WAFを使ってウェブアプリケーションをセキュアに #reinvent
昨日発表されたAWS WAFの紹介セッション「NEW LAUNCH! Securing Web Applications with AWS WAF」を聞いてきました。
従来のWAFとAWS WAFの比較
従来のWAF
- 設定すべきことが多すぎる
- 誤検知が多い
- APIが無いため設定変更の自動化ができない
AWS WAFの特徴
- 設定が簡単
- 柔軟にカスタマイズできる
- 既存の環境に簡単に導入できる
設定手順
AWS WAFの設定単位はWeb ACLです。
AWS WAFの防御対象はCloudFrontディストリビューションなので、作成したACLをディストリビューションに割り当てて利用します。
Web ACLはRuleに対するアクション(検知 or ブロック)をまとめたものです。
そして、Ruleは複数のConditonを組み合わせたものになります。
例えば、社外からの管理画面ログインを防ぐ場合は
条件①) IP: 社内IPのレンジ
条件②) URIに/wp-login.phpが含まれる
の2つのConditionを作成し、
Ruleで
(not 条件①) and (条件②)
を作り、
ACLで
上記Ruleに当てはまるリクエストをブロック
という設定を行います。
詳しくは下記の記事をご覧ください。
[新機能]AWS WAFがリリースされました!#reinvent
[新機能]AWS WAFの概要簡単まとめ! #reinvent
Conditionの種類
ConditionはRuleで抽出されるリクエストの条件を指定するものですが、次の3種類があります。
文字列条件とSQLインジェクション条件では、リクエスト内の文字列に変換をかけた上で検索することもできます。
変換の種類は次の5つです。
- 小文字化
- HTMLデコード
- 空白除去
- コマンドラインの単純化(例: 「,」や「;」をスペースに変換)
- URLデコード
Ruleの作成
作成したConditionを利用してRuleを作成します。
複数の条件を組み合わせた場合は、すべての条件に適合したリクエストが抽出されるようになります。
Web ACLの作成
Ruleにマッチしたリクエストに対して、下記のいずれかアクションを指定します。
- 許可する
- ブロックする
- CloudWatchでカウントする
Ruleを複数指定した時はマッチするまで順番に評価されます。
マッチしなかったリクエストにはデフォルトのアクション(許可 or ブロック)が適用されます。
VPCのNetwork ACLと同じです。
Web ACL設定パターン
公開サイトではデフォルトでアクセスを許可し、既知の脅威だけブロックすることが多いそうです。
制限されたサイトではデフォルトでブロックし、安全であることがわかっているリクエストだけ許可することが多いそうです。
設定の自動化
Web ACLにもAPIがあるので、ログから不正なアクセス元を割り出してブロックすることも可能です。
AWS CLIからAWS WAFのWeb ACLを定義してみた #reinvent
セッションではALERT LOGICを使ってブラックリストを更新する方法と、AWS Lambdaを使って更新する方法が紹介されていました。
感想
これだけ簡単にしかも安くWAFを導入できるようになるとは思いませんでした。
攻撃パターンの設定はユーザ自身で行う必要があるのですが、ユーザグループ等によって設定パターンが蓄積されていく気がします。
また、CloudFrontへのアクセス制限をIPアドレスでできるようになっただけでも、かなり嬉しいです。
CloudFrontにはVPCのセキュリティグループ相当のものがなかったため、リリース前に一般からのアクセスを防ぐのは困難でした。
今回、WAFの機能としてIPアドレスを条件としたアクセス制限がかけられるようになったので、リリース前は関係者のみアクセスを許し、リリース時に一般公開することができるようになりました。