AWS-チープなりなセキュリティとコンプラ その3 WAF編
金は無くとも、使い続ける以上やることはやっておきましょうの続きです。
転職して少し立ち位置が変わる事になりましたが、その立ち位置なりに考えないといけないこともあるし、学びなので今後も続けていきたいと思います。
Amazon CloudFrontとかCDN（Content Delivery Network）などと大それた負荷対策など必要なく、ALB（Application Load Balancer）を分散目的ではなく、リバプロ代わりに利用してコンテンツを塩提供しているわけです。とりあえず、今まで実施できている内容としては
- ALB経由でのサーバの隠蔽
- サブネットをパブリックサブネットと内部サブネットに分割
- SGで内・外部共に必要以外のポートを制限
いわゆる物理的な対策のみになります。
これはこれでやっておかなければならんわけすが結局のところWebの脆弱性などからは守られているわけではなく、いくらマメにサーバ側でアップデートをかけてもイタチごっこです。それに、一人シス管状態だとすぐに対応するのも難しい場合があります。
Webの脆弱性のよくあるあるは以下のような攻撃です。
- ボットなどの大量アクセス
- SQLインジェクション
- クロスサイトスリンプティング
- ディレクトリ・トラバーサル
このあたりの不正攻撃への対応はWAF（Web Application FireWall)を利用するのが一般的です。
WAFを含めてなんとなく今できていること、やってないこと、今回やりたいことを整理するとこんな感じです。
| やること | 実装 | 相当している保護機能 | 保護しているレベル | 備考 |
| SG(セキュリティグループ）でのポート制限 | Yes | ファイアウォール | ネットワーク | パブリック/プライベート毎に利用されるポートのみに通信を制限し |
| ルール外のAWSの設定を通知 | 一応Yes | IDS（？） | 基盤 | 一応、SGや不用意な接続定義となっているものをSNSと組み合わせて 通知することができるけど、あくまでもIDSっぽいなんちゃって監視。 実際のOSレベル、サーバレベルまでの監視はログ、Lambda、SNSあたりを組み合わせれば近いことか可能かも |
| ネットワーク上での不正なプロコルを遮断 | No | IPS | ネットワーク | AWS Network Firewallで実現できるけどコストメリット考えると 規模的に見送り |
| Webアプリケーションの保護 | No | WAF | Webアプリケーション | 今回やりたいこと、AWS WAFとALBで実現可能 |
ということで、費用対効果的に基盤レイヤーは最低限やれることはしていると思うので、コンテンツサイドである「Webアプリケーションの保護」に関しても最低限はお手当しておこうという感じです。
AWS WAFに関しては「managed rule groups」と「own rules and roule groups」の二種類が選択できますが、早い話が
- AWSで用意したルールを使う
- 自分が頑張って作って適用する
の違いですお手軽に利用するのなら、当然「１．AWSで用意したルールを使う」、マネージドルールを利用します。
マネージドルールはセキュリティベンダーの有名所がルールを提供販売しています。セキュリティベンダーだけでなくAWS自体も提供を行っています。
ここではAWS提供のマネージメントルールを利用することを前提にします。
■WAFの設定
AWSのマネージメントコンソールのメニューから「AWS Firewall Manager」を選択します。
「Get Stared with AWS WAF」の「Create Web ACL」をクリックします。
Web ALCの設定ページに遷移します。以下、設定していきましょう。
- Name:ALCの名前
- Description:ACLの説明
- CloudWatch metrics name:そのままCloudWatch metricsの名前。作成後は変えられないのでご注意を
- Resurce Type:ACLを関連させる対象を選択します。ALBで利用したいので「Regional resources」にチェックします
さらに少し下の部分でACLを適用するリソースを追加します。
「Add AWS resources」をクリックしてWAFのACLを適用したいALBを選択し「Next」をクリックします
Add rules and rule groupsの画面に遷移します。「Add rules」のプルダウンメニューから「Add managerd rule groups」を選択します。
マネージドルールの一覧が表示されます（※実際にはもっと下に表示されています）、今回はAWS提供のルールを利用するので「AWS managed rule groups」を選択します。
表示をクリックするとさらに複数のルールグループが表示されます。
全部書くとまた長いので以下、今回選択したルールグループだけ紹介。
| 名前 | 説明 | Capacity |
| Core rule set | 一般的なものを始め出版物や共通脆弱性識別子（CVE）に記載があるような幅広い脆弱性に対する保護ルール ※基本ルールセットと考えて良いと思います | 700 |
| Amazon IP reputation list | Amazonで認識しているボットなどの脅威に関連付けれれているIPアドレスをブロックするルール | 25 |
| Linux operating system | Linux固有の脆弱性の要求をブロックするルール | 200 |
| PHP application | 安全ではないPHP関数のインジェクションや固有の脆弱性の悪性に関連するリクエストパターンをブロックする ※特に明示的に利用していないがプラグインなどで利用されてりするので有効にしときます | 100 |
| POSIX operating system | POSIX規格のOS固有の脆弱性の悪用に関連するリクエストパターンをブロックする ※ざっくりわかりやすくいえばUNIX系OSの脆弱性を悪用する攻撃の対策 | 100 |
| SQL database | SQLインジェクション攻撃などSQLデータベースの脆弱性を悪用するリクエストをブロックする | 200 |
| Bot Control | 2021/4/1 に発表された出来立てほやほやルール。一般的なボットトラフィックを可視化し、望ましくないトラフィックをブロックする | 50 |
ちなみに、「Capacity」の合計が1500を超えるグループを選択することはできません。「えーーい！めんどくせぇ！全部入り！」とかはできないです。
また各ルールを選択後、Editボタンが表示されるためEdit画面を表示しRouleを有効化する必要があります。ルールグループ選んだだけでは機能は有効にならないのでご注意ください。
「Set all rule actions to count」でグループのルール全てを有効化できます。今回は選んだグループルールのルールは全部有効にします。
Option設定もありますがそちらは無視して「Save rule」で保存し「Add managed rule group」画面下の「Add rules」で追加を実行します。
Add rules and rule groupsの画面に戻り、追加されたルールが表示され利用された「Capacity」の合計値の表示、「Default action」の選択になります。
マネージドルールはルールにマッチした場合に機能するので「Default action」はAllowにしておく必要があります。
Custum requestは特に何もせず「Next」を選択しましょう。
「Set rule priority」のページに遷移します。選択したルールの優先度の設定画面になります。
必要に応じて優先度を上げたいルールを上にあげます。
Configure metricsの名前の設定とテストリクエストの実行選択画面に遷移します。
ここの名前がグラフなどにも適用されます。特にに何変えずに「Next」で良いかと思います。
最後に確認の画面が表示されるので、「Create web ACL」で作成を実行します。
WAF＆ShieldのAWS WAF配下のWeb ACLsに作成したACLが追加されています。
※なんか追加されておらんというときは慌てず騒がず、画面右上のリージョン選択が正しいか確認しましょう。
ACLを選択すると以下のように、適用したルールの動作状況が確認できます。
これでALBで「Webアプリケーションの保護」が設定できました。セキュリティの知識があればALL Denyして特定の処理だけAllowとかするべきなんですが、設計も含めてとても時間がかかります。
それを考えれば、可視化も含めて考えれば必要な措置として導入できるのは便利です。
ただいまいち詳細がわからんので誤検知してアクセスできなくなった時の対処が難しいかもしれません。適用後は事前にある程度の打鍵をしてダメそうなルールがあれば一旦外すことも考えた方が良いです。
Rule actionでCoutを選択すると拒否はされずにカウントだけ行われるのでこちらで一旦、状態を見てから有効していくのも良いかと思います。