AWS WAFを体感14日くらいかけて設計構築、テストまで無事に乗り越えることができたのでこの苦労を忘れない、知識&技術を忘れにくくするため、誰かがAWS WAFの設計構築の役に立つことを願ってブログに綴ります。

1.そもそもWAFってなあに?!😇

WAFは”Web Application Firewall”の頭文字3文字から作られた略称です。
具体的にはWebアプリケーションを悪意のある攻撃者から保護するために使用されるセキュリティツールの一種です。

WAFは、Webアプリケーションに対する攻撃や脆弱性から保護する役割を果たします。一般的なファイアウォールは、ネットワークレベルのトラフィックを制御するのに対して、WAFはWebアプリケーションに対する特定の攻撃や不正なアクセスを監視・検出し、それらをブロックする機能を持っています。

一般的なWAFは、以下の機能や特徴を備えています📝

1-1.脆弱性対策

一般的なWebアプリケーションの脆弱性に対する保護を提供します。例えば、SQLインジェクション、クロスサイトスクリプティング(XSS)、クロスサイトリクエストフォージェリ(CSRF)などの攻撃からWebアプリケーションを守ります。

1-2.URIPath、Body、Cookie、クエリストリングの検査

WAFは、UTIPathやBody、CookieなどHTTPSリクエスト内のデータを監視し、検査・フィルタリングを行い不正なデータや攻撃的なパターンを検出して遮断することができます。

1-3.アクセス制御

WAFは、アクセス制御ポリシーや設定に基づいて、許可されたトラフィックのみを通過させます。特定のIPアドレス、国または地域からのアクセスをブロックしたり、許可したりすることができます。

1-4.トラフィックログの監視

WAFは、攻撃や不正なアクセスの試行をトラフィックログに記録し、監視・分析することができます。これにより、セキュリティインシデントの早期発見や対応が可能になりますが、一般的にWAFの生ログは読みづらいため、誰でも見やすく判断しやすいように工夫が必要になります。

以上の4点がWAFの具体的な機能、役割となります。WAFはWebアプリケーションのセキュリティを向上させる重要なツールであり、一般的にはWebサーバーやアプリケーションの前段に配置されます。

2.一般的なWAFとAWS WAFによって何が変わるのか?!

2-1.デプロイメントの違い

一般的なWAFとAWS WAFの大きな違いとして先に挙げる違いはデプロイメントの違いと言えます。一般的にはWAFは自社で設計構築したオンプレミス(物理環境)環境内にハードウェアや仮想マシンとして自社のインフラストラクチャ内に配置されます。一方でAWSのWAFはAmazon Web Services(AWS)クラウド上にデプロイされます。

2-2.管理とメンテナンスの手間が省ける

一般的なWAFでは、自社での管理とメンテナンスが必要です。
例えば、セキュリティポリシーの設定やアップデート、パフォーマンスの監視などを基本的には自社で全て行う必要があります。AWS WAFでは、AWSが管理とメンテナンスを担当します。これにより、自社で行なってきた運用負荷やコストを大幅に削減することが期待できます。

3.拡張性

AWS WAFはAWSクラウドのスケーラブル(自由に拡張できる)なインフラストラクチャ上に構築されているため、需要に応じて自動的にスケーリングすることができます。一方、一般的なWAFでは、インフラストラクチャのスケーリングの仕組みやスケーリングするタイミングなど自社で管理・設計する必要があります。また、スケーリングするリソースが足らない場合はリソースを調達してくるコストが発生しますがAWS WAFではマネージドサービスになるため、そのような手間は発生しません。

4.AWS WAFはすぐに使える!

AWS WAFは、他のAWSサービス(例:Amazon CloudFront、AWS Application Load Balancer、APIGateway)との統合がシームレスに行えます。これにより、WAFの機能をすぐに利用することができます。一般的なWAFでは、これらの統合を自社で構築する必要があります。また、AWSはクラウドインフラストラクチャとなるため、TerraformやAWS CloudFormationなどのIaCコードを使ってコードでの構築も可能です。開発段階ではマネージメントコンソールで検証し安定した後はコード化すると構築・変更・削除がスピーディに実施できるようになります。

5.料金モデル

一般的なWAFでは、ハードウェアやライセンスに関連する初期投資やライセンス料金が発生する場合がありますがAWS WAFでは、利用したリソースに対して従量課金されるため、必要なときに必要な範囲でのみ支払いが発生します。

AWS WAF料金

3.AWS WAFの設定方法

AWS WAFの設定方法は基本的には1つのWebACLにルールを作成していく設定方法になります。
以前のWAFバージョンv1から現在はv2に変更されこの辺りの設定の柔軟性も大幅に上がっており個人的には非常に使いやすいと思いました。前に、OracleCloudのWAFを設計した経験がありますが、設定のわかりやすさ、やり易さはAWSがやりやすかった印象ですが、関連付けはOracleCloudの場合はドメインベースに対してAWSはCloudFront,ALB,APIGateway,Cognitoと固定されてるので両者それぞれ一長一短っといったところでしょうか。

AWS WAFのWebACLに各ルールを追加したコンソール上の状態は以下に示すような状態になります。
通常はWAF WebACLを作った直後はルールは1個もない状態なのでWAF WebACL作成後はすぐにルールを作成して設定を入れてあげないとWAFが働かないので注意しましょう。

また、WAFのルールにはAWSが用意したマネージドルールとユーザー自身でカスタマイズして作成する独自ルールの2種類があります。そのほか、各セキュリティベンダー社が用意したルールもありますが基本的にはAWSのマネージドルール、又はカスタムルールになるかと思います。AWSマネージドルールを使えば特に難しい設定などは考えずにすぐに関連づけたいリソースに紐付けるとWAFの機能が使えるようになりますが基本的にマネージドルールはブラックボックスになっているため予期せぬリクエストまでブロックしてしまったり過剰な制限がかかる懸念もあるため、個人的にはカスタムルールで自分で作った方があとあとは管理や編集が楽になると思いました。

上記を踏まえて基本的な設定方法について説明していきます。

3-1.マネージメントコンソールからの設定方法

①AWS WAFのサービスを開く

AWSマネージメントコンソールの検索窓へ”WAF”を入力してサービスからWAFを選択します。しばらく何回もWAFにアクセするのであれば⭐️マークを押してAWSコンソールのブックマークバーに入れときましょう☝️

②リージョンサービスを保護したいWebサービスが存在するリージョンに合わせる

基本的には東京にリソースがある場合は東京を選択しますが、ここで注意が必要なのはCloudFrontの場合です。本記事ではAPIGatewayを保護しますので東京リージョンを選択します。
※詳細は下記の公式ドキュメントをご参照ください。
WAFで保護できるリソース

③Create web ACLからWeb ACLを作成する

Create web ACLを選択すると以下の基本設定の項目に値を入力します。

Add AWS resourcesをクリックしWebACLと関連づけるリソースを選択します。
※ここは後からでも設定できますし変更もできます。

今回はAPIGatewayの事前に作成したサンプルのMyApiに関連づけます。
関連づけるAPI Gatewayのリソースを選択したらAddを選択します。関連づけるAPIGatewayのリソースはいくつでもOKです。

Nextをクリックします。

次はWebACLのルールを追加します。追加するルールはAWS側で用意されたAdd managed rule groupsか自分で要件に合わせてカスタムできるAdd my on rules and rule groupsのどちらかを選択します。個人的にはマネージドルールよりは後者のカスタムルールで調整するのがオススメです。

マネージドルールは選択して終わりなので、本記事ではAdd my on rules and rule groupsを説明します。

 Rule builderでのルールの作成の方法はRule visual editorまたはRule JSON editorのどちらかで設定します。今回は例としてURIパスに1000バイト以上のリクエストがあった時を条件にブロックする設定にします。

Name: 任意の名前
Type: Regular rule
※ Rate-based-ruleは指定した回数(最低レート5分あたり100回)を超えた場合にルールを発動します。特定のIPアドレスが1000回リクエストしてきた時にそのIPアドレスをブラックリストに追加する設定などに有効です。

レートベースのルールステートメント

今回は以下のように設定します。

if a request : matches the statement
Inspect : URI path
Match type: Size greater than
Size in bytes: 1000
Action: Block


Add ruleを追加するとルールが作成したWebACLに追加されます。

注意しないといけない設定はDefault web ACLのAction設定です。ここをBlockにしてしまうとWebACLのルールが適応されない許可されたリクエストであっても全て弾かれてしまうので設定がちゃんとAllowになってることを確認しましょう。※私はこの設定で全部Blockされてしまう苦い思い出があります💦

上記の設定が終わったらNextをクリックします。

Set rule priorityを聞かれます。ここではリクエストに対して設定したどのルールを優先して適応させるかを設定するんですが今回は1つしかルールがないのでこのままです。

次もそのままの設定で進みます。最後の設定確認画面で設定に問題なければCreate web ACLをクリックします。

コンソール上で作成したWebACLと追加したルールが確認できます。

カスタムルールでも手順的にはさほど難しくもなく簡単に設定ができたと思います。

動作確認

作成したURIPathサイズ制限のルールが紐づいているAPIに対してcurlコマンドを使って動作確認をしてみます。

ターミナルやAWS CloudShellから適当にリクエストを投げます。

curl -X GET "https://wi9eplhyub.execute-api.ap-northeast-1.amazonaws.com/v1/HKATobKlmWJLL4W6AAfHOs0LtZKG5f0s9TCikMZFVvSvMGjHn6wGDiF8rlok7D8Y3YKMkqMPAUI1OsiITipVTLOc9VYdGQyfXNCKchZxio4WlAHF1c0tH1rd6Qs2Ss04lRZ6z1qTbRSzyfYm2C1Qw3VhTPN8lvYPz7ytypv5F9QMo4paBGX09pi8YlKP16g9YnTlH8Y21InPOWeXD8EjXd5wrE0CrYNOksFmt0YE5qGj9aEQFY2abz2XytPtZNKc4phKl5MVq05dtzG83uD6rcTCojZfQVGv3XLbyhK4ZCcot4RcjtuPDxg0JD541G5CBYV1V6EodZXPXDSnFOM3DGD0o80NG6Qr1dozXLVbO39I6OHxtSwsAnrYRsB0FHZMg4UGbMNDTZaytdsedMtHMjOP1USnh2KuA504SGpRJjEzCKIF8YuyhAIMgBkYyfOFhX8ZCzzXunH1bcyEIM5mAYXFcoNqThvLfbGVLd37GFtYQru2E8PPAnVyYbn5iiiGmaCf6bUP2Y1WLuC3ihCnrC0cfdRx0S8ps10qGq14IcRNQ6G6hiwKMgwvdFSxoA87v3SiWKacmnzfiWmoufsasHSDovRx9hGGDMcM5vZi6nN5dmqRDULstdNuyjCcEuietfYGRBAGvcSAZKiB8SHjxCNdCXusL2vH0FlWkBkG8UxzI8fAwEIePEZ3rleLy3WiNNUbALbEZT73BAj4tyv5JqCfHl44M9gBw48RLGaTnj5rtSEWcAXzntCmM8QAwll9cGy1XEckNCFNBREqvJFe32ztoJPC45VkwQwNn4NJQlluBQBaDz6DCdWgEOQle0SHr8xzrV1qOmmN4j5UGcqmsa97xUFt9o7ZX2J59YAgYdAhsA2FiUNgvcERbsUVBU39rDcvgcAMeKmRppIOPs2VoKVIUu8wZkVciQI3y04eZLSGdIXUmHZ9uryMbTKKGI3nc77wVmxjatVzjvptTIebYqNKG8jYMkT5w7x9WpzqY"

上記のコマンドを実行するとレスポンスとして{“message”:”Forbidden”}が返ってきました。

コンソール上のサンプルリクエストを確認するとしっかりBlockされていることが確認できました。
念の為、URIPathのサイズ制限に引っかからないようにリクエストを投げてみました。想定だとリクエストはAllowされAPIGatewayまで届くはずです。

レスポンスは先ほどとは違い{“message”:”Missing Authentication Token”}が帰ってきました。APIの認証トークンを持っていないためAPIGatewayの認証は失敗していますがWAFを通過してAPIGatewayにリクエストが届いてることがイメージできます。

コンソールでも確認するとリクエストが許可されていることがわかりました。

以上で、AWS WAFの備忘録とさせていただきますが、今回はマネコンで説明していますが、CloudFormationの実装の方が後々は楽なのでまた後日追記してご説明したいと思います。

今後WAFを設計実装する方の誰かの参考になれば幸いです。ありがとうございました!

ドメインはお名前.comで!

こちらのブログでもお名前.comさんのドメインを使わせていただいています!キャンペーンと合わせるとお得に.comや.jpなどのドメインを手に入れることが可能です!

にほんブログ村 IT技術ブログ IT技術メモへ
にほんブログ村

投稿者 izumi kikumura

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です