AWS-チープなりなセキュリティとコンプラ その3 WAF編

2021年8月8日

金は無くとも、使い続ける以上やることはやっておきましょうの続きです。
転職して少し立ち位置が変わる事になりましたが、その立ち位置なりに考えないといけないこともあるし、学びなので今後も続けていきたいと思います。

前回のconfig

Amazon CloudFrontとかCDN(Content Delivery Network)などと大それた負荷対策など必要なく、ALB(Application Load Balancer)を分散目的ではなく、リバプロ代わりに利用してコンテンツを塩提供しているわけです。とりあえず、今まで実施できている内容としては

  • ALB経由でのサーバの隠蔽
  • サブネットをパブリックサブネットと内部サブネットに分割
  • SGで内・外部共に必要以外のポートを制限

いわゆる物理的な対策のみになります。
これはこれでやっておかなければならんわけすが結局のところWebの脆弱性などからは守られているわけではなく、いくらマメにサーバ側でアップデートをかけてもイタチごっこです。それに、一人シス管状態だとすぐに対応するのも難しい場合があります。
Webの脆弱性のよくあるあるは以下のような攻撃です。

  • ボットなどの大量アクセス
  • SQLインジェクション
  • クロスサイトスリンプティング
  • ディレクトリ・トラバーサル

このあたりの不正攻撃への対応はWAF(Web Application FireWall)を利用するのが一般的です。
WAFを含めてなんとなく今できていること、やってないこと、今回やりたいことを整理するとこんな感じです。

やること実装相当している保護機能保護しているレベル備考
SG(セキュリティグループ)でのポート制限Yesファイアウォールネットワークパブリック/プライベート毎に利用されるポートのみに通信を制限し
ルール外のAWSの設定を通知一応YesIDS(?)基盤一応、SGや不用意な接続定義となっているものをSNSと組み合わせて
通知することができるけど、あくまでもIDSっぽいなんちゃって監視。
実際のOSレベル、サーバレベルまでの監視はログ、Lambda、SNSあたりを組み合わせれば近いことか可能かも
ネットワーク上での不正なプロコルを遮断NoIPSネットワークAWS Network Firewallで実現できるけどコストメリット考えると
規模的に見送り
Webアプリケーションの保護NoWAFWebアプリケーション今回やりたいこと、AWS WAFとALBで実現可能

ということで、費用対効果的に基盤レイヤーは最低限やれることはしていると思うので、コンテンツサイドである「Webアプリケーションの保護」に関しても最低限はお手当しておこうという感じです。
AWS WAFに関しては「managed rule groups」と「own rules and roule groups」の二種類が選択できますが、早い話が

  1. AWSで用意したルールを使う
  2. 自分が頑張って作って適用する

の違いですお手軽に利用するのなら、当然「1.AWSで用意したルールを使う」、マネージドルールを利用します。
マネージドルールはセキュリティベンダーの有名所がルールを提供販売しています。セキュリティベンダーだけでなくAWS自体も提供を行っています。
ここではAWS提供のマネージメントルールを利用することを前提にします。

■WAFの設定

AWSのマネージメントコンソールのメニューから「AWS Firewall Manager」を選択します。
「Get Stared with AWS WAF」の「Create Web ACL」をクリックします。


Web ALCの設定ページに遷移します。以下、設定していきましょう。

  1. Name:ALCの名前
  2. Description:ACLの説明
  3. CloudWatch metrics name:そのままCloudWatch metricsの名前。作成後は変えられないのでご注意を
  4. 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 listAmazonで認識しているボットなどの脅威に関連付けれれているIPアドレスをブロックするルール25
Linux operating systemLinux固有の脆弱性の要求をブロックするルール200
PHP application安全ではないPHP関数のインジェクションや固有の脆弱性の悪性に関連するリクエストパターンをブロックする
※特に明示的に利用していないがプラグインなどで利用されてりするので有効にしときます
100
POSIX operating systemPOSIX規格のOS固有の脆弱性の悪用に関連するリクエストパターンをブロックする
※ざっくりわかりやすくいえばUNIX系OSの脆弱性を悪用する攻撃の対策
100
SQL databaseSQLインジェクション攻撃などSQLデータベースの脆弱性を悪用するリクエストをブロックする200
Bot Control2021/4/1 に発表された出来立てほやほやルール。一般的なボットトラフィックを可視化し、望ましくないトラフィックをブロックする50
Windows固有などもあるのでそこは環境などにより取捨選択してください

ちなみに、「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を選択すると以下のように、適用したルールの動作状況が確認できます。

bot control以外
bot Controlはこのような専用画面

これでALBで「Webアプリケーションの保護」が設定できました。セキュリティの知識があればALL Denyして特定の処理だけAllowとかするべきなんですが、設計も含めてとても時間がかかります。
それを考えれば、可視化も含めて考えれば必要な措置として導入できるのは便利です。
ただいまいち詳細がわからんので誤検知してアクセスできなくなった時の対処が難しいかもしれません。適用後は事前にある程度の打鍵をしてダメそうなルールがあれば一旦外すことも考えた方が良いです。
Rule actionでCoutを選択すると拒否はされずにカウントだけ行われるのでこちらで一旦、状態を見てから有効していくのも良いかと思います。