この記事は、前編 を読んでくださった方向けの続きの記事です。
前回記事で、OWASP ZAP TOP10の１・２・５・７・９・（１０）の対策のうちBot 対策を説明しました。
1. インジェクション対策（SQLInjection）Access Control(アクセス設定の不備）XSS )脆弱性 対策）
についての説明記事です。
こちらは、5・7番への対策です。URI が判明した場合認証攻撃などをされるので、対策に役に立ちます。
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. コンテンツ内の管理者ページへのアクセスを制御します。サードパーティ ソフトウェアもしくは悪意のある者の管理アクセスを制御するのに役に立つ
9番及び前編で記載したTOP10ひいてはOWASPで推奨される全ての対策になりますが、ルール名に記載の通りプログラムの中心部で使われるであろう想定から作られるの対策 となるので一部対策が甘いところがあるので「このルール入れればじゃあ良いじゃん」なんてことは思わないようにしてください。
中心にあるもののルールセットというのが、言い方としては正しいですが、内容は以下の様に英語で記載されてます。
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. 何か、見た用語が出てきましたね。OWASPというワードとvulnerabilitiesという言葉です。フレームワーク などを使われてると思いますが、それの中心となるプログラムに対しての「脆弱性 」や「OWASP」の対策が講じられているか、講じられていない場合、WAFの方で一時的に対処しましょう
既知の脆弱性 の対策方法でも有りますので、9番の対策をします。
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. と、先に私が、日本語記載した物そのままでした・・・。詳細はLearnMoreを読んで頂いた方がより良い理解が出来るかとおもいます。
1番と9番の対策です。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. 非認証なオペレーションも対策してくれる様です。
ここまでつらつらと書きましたが以上が対策に設定するルールです。
ルールは本執筆中はこのように並んでいます。
Free rule groups OWASPの順番で並べてみます。
OWASP TOP10の内容
AWS WAFのルール備考
1.インジェクション対策
SQL database
2.アクセス制御の不備（認証情報の漏洩）
Bot Control
5.Broken Access Control(アクセス設定の不備）
Bot Control,Admin protection
7.Cross-Site Scripting(XSS )
Admin protection
9.Using Components with Known Vulnerabilities(既知の脆弱性 対策）
Core rule set,SQL database
Insufficient Logging and Monitoring(不十分なログと監視設定)
Bot Controlあくまで付随対策なのでプログラム(開発)側でしっかり対策が必要
AWS WAFではもう1つ気にすることがあります。
一通りルールを選択が終わり、次へとすると、ルールの適用する順番を聞かれます。
rule priority ここで、考えるのは、パケットが来た時にどういった順番で動作をするのかです。
パケットを受け取ると、まずはアプリケーションを通過、その後、アプリケーションのミドルウェア を通過、OSを通過、とOSI参照モデル の下の方へいきます。
紹介したルールは
BotRule
Admin protection
Core rule set
Linux operation systemSQL database 対策順番はOSが一番最後になりますので
BotRule
Admin protection
Core rule set
SQL databaseLinux operation system が、正解です。
悩ましいと思われるのは、URLの様な見える物、権限を取られたら困る物
Admin等の固有URI 等が見えますし、権限上の管理権限等が付与されている場合もあります。Bot の対策後Adminを対策、Core ruleによるプログラムの対策、SQL の対策後、OSの対策
設定後は、ログの確認をして、完了です。
log-sample こんな感じに出てきます。
要件に満ちているかを確認するため、以下に完全貼り付けをします（重要情報は、＊＊＊にて潰しますが）
{
"timestamp": 1706422856469, <strong>←UnixTimeによる時間</strong>
"formatVersion": 1,
"webaclId": "arn:aws:wafv2:us-east-1:＊＊＊＊＊＊＊＊:global/webacl/test/133cfd57-461a-4011-bd47-eb9cfaacaaec", <strong>←どのACLか</strong>
"terminatingRuleId": "Default_Action",
"terminatingRuleType": "REGULAR",
"action": "BLOCK", <strong>←許可か拒否か</strong>
"terminatingRuleMatchDetails": [],
"httpSourceName": "＊＊＊＊",<strong>←Source Protocol</strong>
"httpSourceId": "＊＊＊＊＊＊＊",
"ruleGroupList": [
{
"ruleGroupId": "AWS#AWSManagedRulesAdminProtectionRuleSet",
"terminatingRule": null,
"nonTerminatingMatchingRules": [],
"excludedRules": null,
"customerConfig": null
},
{
"ruleGroupId": "AWS#AWSManagedRulesCommonRuleSet",
"terminatingRule": null,
"nonTerminatingMatchingRules": [],
"excludedRules": null,
"customerConfig": null
},
{
"ruleGroupId": "AWS#AWSManagedRulesSQLiRuleSet",
"terminatingRule": null,
"nonTerminatingMatchingRules": [],
"excludedRules": null,
"customerConfig": null
},
{
"ruleGroupId": "AWS#AWSManagedRulesLinuxRuleSet",
"terminatingRule": null,
"nonTerminatingMatchingRules": [],
"excludedRules": null,
"customerConfig": null
}
],
"rateBasedRuleList": [],
"nonTerminatingMatchingRules": [],
"requestHeadersInserted": null,
"responseCodeSent": null,
"httpRequest": {
"clientIp": "＊＊＊＊＊＊",<strong>←SrcIP</strong>
"country": "＊＊", <strong>←SrcCountry</strong>
"headers": [
{
"name": "User-Agent",
"value": "Wget/1.17.1 (linux-gnu)"
},
{
"name": "Accept",
"value": "*/*"
},
{
"name": "Accept-Encoding",
"value": "identity"
},
{
"name": "Host",
"value": "＊＊＊＊＊" ←DstHost
},
{
"name": "Connection",
"value": "Keep-Alive"
}
],
"uri": "/＊＊＊＊＊＊", <strong>←アクセスしたURI</strong>
"args": "REDACTED",
"httpVersion": "HTTP/1.1",
"httpMethod": "REDACTED",
"requestId": "tCwsXZBRpUZy_JHczpC6U0CL30m_C6U2FCDaluiXTJWmakHqEBUm_w=="
},
"ja3Fingerprint": "81bacd5d10832264bc04b9041be2a088"
} なお、UnixTimeでしかログ上では表示されないので、CloudWatchLogsの時間を参照にするとアクセスしてきた時間を見る方が解析はしやすい かと思います。
長くなりましたが、設定は以上です。
