AWS WAFを導入する時に確認しておきたいこと

EC2のみでWebサーバーをたて本番稼働している環境について、AWS WAFを導入したい旨のご相談をいただくことがあります。AWS WAFを導入する前に知っておきたいこと、確認していただきたいことをご紹介します。

WAFで悪意のないユーザーの通信を遮断してしまうリスクを認識しておく

AWS WAFに限らず、WAFは悪意のないユーザーの通信を遮断してしまう恐れがあります。導入しただけで完了するサービスではありません。WAFのログを確認し、誤検知しているルールはカウントに変更するといった運用が必要です。運用の支援が必要な場合、WafCharm（ワフチャーム）を検討します。WafCharmはCSC社が提供するAWS WAFのルール作成や運用を支援するサービスです。詳しくはブログをご覧ください。

WAFでは防げない攻撃もある

IPA テクニカルウォッチ「DOM Based XSS」に関するレポートでは、URLのフラグメント識別子の値を使った攻撃の場合は、スクリプトに相当する文字列がサーバーに送信されないため、WAFでの防御が期待できない旨が紹介されています。アプリケーションやOS、ミドルウェアを最新の状態に保ち、WAFで追加の保護を実施するという考え方をしましょう。WAFでは防げない攻撃もあるからです。

緊急時の通知が必要か確認する

WAFの運用には、24時間365日監視センターが見守り、緊急時には電話で通知するといったこともあり得ます。このような用途ではAWS WAFは機能的に不足があります。パートナー製品のWAFを検討しましょう。24時間365日の監視や通知にはそれなりのコストがかかるので、コストとの相談になります。

どのようなルールを作るか

AWS WAFの中でどのようなルールをどうやって作るのかを検討します。AWS WAFは2019年12月に大きくアップデートが行われ、AWS WAFv2ができました。以前のWAFはWAF Classicという扱いになっています。AWS WAFv2では、AWSが提供するマネージドルールを利用できるようになりました。 詳しくはブログをご覧ください。基本的にはCommonRuleSetをベースにLinuxならLinux用、WindowsならWindows用のルールを追加していくような使い方になるかと思います。

ALBまたはCloudFrontが導入済みか

AWS WAFはALBまたはCloudFrontに割り当てて利用します。EC2に直接割り当てることはできません。ALBやCloudFrontが未導入の場合に特に気をつけたいポイントを紹介します。EC2だけで運用しているケースでは、ALBを導入すると良いでしょう。

Zone Apexを利用しているか

サブドメインを含まないドメイン名をZone Apexと言います。example.jpドメインを所有している時にサイトをexample.jpで公開している場合、Zone Apexを利用しているケースに該当します。www.example.jpや、faq.example.jpはサブドメインがついているため、Zone Apexではありません。Zone Apexは多くのDNSサーバーで、CNAMEを登録できないという制約があります。ELBやCloudFrontは固定のIPアドレスを持たず、「myALB-1234567890.ap-northeast-1.elb.amazonaws.com」といったDNS名を持ちます。Zone Apexに対応していないDNSサーバーでは、ELBとCloudFrontのCNAMEを登録できません。DNSサーバーが対応していない場合は、Route 53への変更を検討します。Rout 53はZone Apexのレコードについても登録が可能です。

ALBを導入する場合、複数AZのサブネットがあるか

ALBを作成するには、アベイラビリティゾーン（AZ）が異なる2つのサブネットを指定する必要があります。VPCのアドレスに余裕がある場合はサブネットを作成します。アドレスに余裕がない場合は、IPアドレスの拡張を検討します。

ACM証明書への置き換えを検討する

httpsのサイトの場合、EC2上にSSL証明書を配置していることがあります。 CloudFrontやALBでもその証明書をそのまま利用できますが、AWS Certificate Managerによる無料のSSL証明書を利用できます。ACMは多くのお客様の本番環境で利用されています。ACMの利用には、メール認証またはドメイン認証が必要になります。証明書はドメイン認証レベルです。EV SSL証明書が必要なケースでは適していません。

カスタムエラーページは必要か

AWS WAFが通信をブロックすると、「403 Forbidden」のページを表示します。「このページには接続できません。ご不明な場合、xxまでご連絡ください。」と言ったカスタマイズされたページを表示するには、CloudFrontが必要です。詳細はAWS WAFのブロック時にカスタムエラーページを表示するをご覧ください。

移行の場合

本番環境でWAFを運用中のケースで、コスト面で魅力的なAWS WAFに切り替えたいケースがあります。移行に関連して注意したいポイントを紹介します。

課金方法

AWS WAF の料金ページはこちらです。最低月6ドルから使える超低下価格が魅力です。アクセスが頻繁なサイトではリクエスト課金が多くなる点に注意が必要です。リクエスト数とアクセス数は異なる点にも気をつけましょう。例えば、画像が多いサイトでは1アクセスにあたり、10リクエストしているようなケースがあります。

コンソールから確認できるログは3時間分だけ

AWSコンソールから確認できるAWS WAFのログは過去3時間分だけであり、それより前のログはS3に溜まったファイルを見る形になります。また、ログファイルをそのまま見るのは大変なため、Amazon Athenaでクエリを実行して、閲覧するケースが多いです。運用の変更点として許容できるのか検討します。

動作はブロックまたは検知のみ

AWS WAFでは問題のある通信箇所のみ取り除いて、EC2に渡すといった処理はできません。通信をブロックするまたは検知のみになります。

WAF自体にCDN機能はない

SaaS型のWAFの場合、CDN機能を持っている場合があります。当該製品をやめる場合は、CloudFrontとAWS WAFへの変更が必要です。

検知時の通知メールの考慮

パートナー製品のWAFの場合、攻撃を検知したメールに攻撃元のIPアドレス、国、URL、攻撃内容などが記載されているかと思います。AWS WAFには標準でそのような機能はありません。通知が必要な場合、WafCharmを検討します。詳しくはブログをご覧ください。

さいごに

AWS WAFを導入する前に知っておきたいこと、確認していただきたいことをご紹介しました。色々と紹介しましたが、AWS WAFは他のAWSサービスと同様にすぐに初めてすぐに辞められます。確認検討は行いつつ、実際に試してみると良いと思います。