AWS WAF
料金
- Web ACL 5.00USD/月あたり (時間で案分)
- ルール 1.00USD/月あたり (時間で案分)
- リクエスト 0.60USD/100 万リクエストあたり
プラス
- マネージドルールの利用料金
マネージドルールの料金は Marketplace とかで探してみると金額がわかる
Fortinet Managed Rules for AWS WAF - Complete OWASP Top 10
設定されているルール数とそれらを処理したリクエスト数に応じて料金が発生する
AWS WAF を紐付ける CloudFront や ALB 、 API Gateway の料金は別途発生する
さらに知っておくべきこととして
- AWS Managed Rules の使用に関しての追加料金などはありません
- AWS Marketplace の販売者が提供するマネージド型ルールにサブスクライブすると、販売者が設定したマネージド型ルール料金がかかります
- AWS WAF の料金体系には変更はありません
WAF の作成
AWS WAF 用 AWS Managed Rules の発表
AWS WAF、AWS Shield、AWS Firewall Manager とは
だいぶ以前はWAFを設定したいけどマネージドルールはなんか評価低いのばかりでお金に見合う対価があるのか微妙で、
AWSの標準WAF ACLs を CloudFormation から導入して格安に運用していたんだけど
ついにAWSのマネージドルールが出たらしく実際に設定してみる
WAF ACLsの作成
ルールを作成する際に「Add managed rule groups」 を選択する
マネージドルールに「AWS managed rule groups」ができてる
Admin protection 公開された管理ページへの外部アクセスをブロックできるルール
Contains rules that allow you to block external access to exposed admin pages. This may be useful if you are running third-party software or would like to reduce the risk of a malicious actor gaining administrative access to your application.
Amazon IP reputation list
ボットやその他のAmazon脅威インテリジェンスに基づくソースをブロックするルール
This group contains rules that are based on Amazon threat intelligence. This is useful if you would like to block sources associated with bots or other threats.
Core rule set
OWASPの出版物や一般的なCommon Vulnerabilities and Exposures（CVE）に記載されているものを含む、広範な脆弱性の悪用に対する保護が提供
Contains rules that are generally applicable to web applications. This provides protection against exploitation of a wide range of vulnerabilities, including those described in OWASP publications and common Common Vulnerabilities and Exposures (CVE).
Known bad inputs
脆弱性の悪用または発見に関連付けられている要求パターンをブロックできるルール
Contains rules that allow you to block request patterns that are known to be invalid and are associated with exploitation or discovery of vulnerabilities. This can help reduce the risk of a malicious actor discovering a vulnerable application.
Linux operating system
LFI攻撃など、Linux固有の脆弱性の悪用に関連する要求パターンをブロックするルール
Contains rules that block request patterns associated with exploitation of vulnerabilities specific to Linux, including LFI attacks. This can help prevent attacks that expose file contents or execute code for which the attacker should not have had access.
PHP application
安全でないPHP関数の挿入など、PHPの使用に固有の脆弱性の悪用に関連する要求パターンをブロックするルール
Contains rules that block request patterns associated with exploiting vulnerabilities specific to the use of the PHP, including injection of unsafe PHP functions. This can help prevent exploits that allow an attacker to remotely execute code or commands.
POSIX operating system
LFI攻撃を含むPOSIX / POSIXライクなOSに固有の脆弱性の悪用に関連するリクエストパターンをブロックするルール
Contains rules that block request patterns associated with exploiting vulnerabilities specific to POSIX/POSIX-like OS, including LFI attacks. This can help prevent attacks that expose file contents or execute code for which access should not been allowed.
SQL database
SQLインジェクション攻撃など、SQLデータベースの悪用に関連する要求パターンをブロックできるルール
Contains rules that allow you to block request patterns associated with exploitation of SQL databases, like SQL injection attacks. This can help prevent remote injection of unauthorized queries.
Windows operating system
Windows固有の脆弱性（PowerShellコマンドなど）の悪用に関連する要求パターンをブロックするルール
Contains rules that block request patterns associated with exploiting vulnerabilities specific to Windows, (e.g., PowerShell commands). This can help prevent exploits that allow attacker to run unauthorized commands or execute malicious code.
WordPress application
WordPressサイト固有の脆弱性の悪用に関連するリクエストパターンをブロックするルール
The WordPress Applications group contains rules that block request patterns associated with the exploitation of vulnerabilities specific to WordPress sites.
これいれておけばオッケー！みたいなルールか他マネージドルールみたいに数個かと思ったらわりと細分化されていた
一般的なWebシステムに対してマネージドルールを入れようと思った場合、
- Amazon IP reputation list
- Core rule set
- Known bad inputs
- SQL database
これらをベースに組み合わせやシステム要件を見ながら調整するかんじかな
有効化する際に「Set rules action to count」も有効化するとブロックはせずカウントのみとなる
マネージドルールを選択してルールリストを見てみると
Capacity に基づいて Web ACL rule capacity units used が減っているのがわかる
だいぶ以前は
[WAF] - [ACLs] - [Rules]
と紐付いていてACLs あたり Rules は 10 までという上限があったのですが、
WAF Capacity Unit (WCU) という考え方のルールに新しく変わり
[WAF] - [ACLs] - [WCU] The total capacity units used by the web ACL can’t exceed 1500.
という考え方に変わり、 ACLs に設定出来る WCU 最大 1500 以内であればルールを追加管理できるようになった
マネージドルールの場合「Capacity」のところに消費する WCU が記載されている
マネージドじゃない場合の手動でルールを定義する場合は１ルール１WCUなのか？
まぁそれらは置いておいて次に進むとルールの Priority が設定できる
上から順番に処理されるためネットワーク層に対するWAFポリシー系を上げておく
CloudWatch メトリクスの指定、そのまま
以上で作成完了
AWS リソースとの関連付け
今回は ALB 向けに作っていたので 既存の ALB に紐付ける
ALB側から見ても関連付けされて無いように見えるが、ちゃんと有効になっており
例えばデフォルトアクションを「Block」にすればちゃんと 403 画面が表示される
テスト
試しに ShellShock 時の脆弱性攻撃に似せた UserAgent 設定にしてアタックしても防がれなかった
user-agent: () { :;}; echo something>/var/www/html/new_file
Scutum とか Akamai とかは防いでくれるけど、まぁ無料だとこんなもんなのかな？
某ブログで確認してた URL リクエストを投げてみてもブロックされず
$ curl -X GET -d '? or 1=1-- ' https://hogehoge.com/index.html
メトリクスとかで見たいのに確認出来ない
少し運用しながら確認してみる
