技術系は久々の投稿になりますね。
白"雪姫"です。
今回のお話は、セキュリティ方面です。
登壇出来たこともあり、どんなことをしてたのかを一般的な範囲で書けるようになったので
苦労してたことを思い出しながらちょもちょも書いていこうと思います。
その殆どは、AWSかもしれませんが・・・・・(笑)
さて、本題に入りましょう。
今回は、AWS WAFで苦労した点についてお伝えします。
aws.amazon.com
まず、AWS WAFとは、AWSマネージドの Web Application Firewallのサービスです。
Applicationとつくように、OSI参照モデル7層であるアプリケーション層への脅威を緩和するためのサービスです。
このAWS WAFは、2015年にリリースされた物をバージョン1、その後、2019年末頃にリリースされたものがバージョン2です。
そんなAWS WAFを使用したいと、当時対応していたプロジェクトに入っていた、セキュリティ認証のコンサルタントに入っていた方に相談をしたところ、
「OWASP ZAP TOP10に準拠したルールだったら認めるけども、それ以外なら、どういうルールなのかしっかり理解して提示できる資料が必要、またログの出力とかも確認させて欲しい」
と言われました。
その時は、バージョン1のものでこちらが提供されていました。
が、記事の公開年を見ていただくと分かりますが2017年になります。
いくら公式といえど、少し古いです。
当然バージョン2も出て、だいぶ浸透してきている時期になります。
調べてみても2020年で当該アップデートは終了する。なんて注意書きも書いてありますね。
今回はできる限り、バージョン1で利用していた無料ルールをMarketPlaceの高額ルールを使わないでやるというのが目標になっていました。
また、この記事を執筆しているときと要件も少し変わってますので、最新にされたい方は私の記事を参考に最新の攻撃手法などを調べるようにしてください。
当時の認証規格のWAFの要件には以下がありました。
「最新の情報を常に取り入れ、それを適用、正常に動作していることを確認すること」
また、先述のとおりログを取る必要があり、ログの取得要件は次の通り。
「いつ（Date）・どこから（SrcIP）・どこに（DstIP）・プロトコル（TCP/UDP等）・許可拒否・URI・拒否した場合はどのルールなのか」
そして、ログの保存要件があります。
「取得したログは、1年間保持し、少なくとも3ヶ月分は即時に取り出せるようにしておくこと」
この時点でお気づきの方はお気づきかもしれません。
許可のルールを通過させてたら膨大なログ、出るよね・・・・？と。
このシステムはそこまでアクセスも来るような物ではなかったので、CloudWatch Logsで事足りたので、CloudWatch Logsに出力して保存期間を1年としました。
アクセス数が多かったり、取りこぼしを防がないとならないと言った要件がある場合は、Kinesis Data Firehoseを利用してください。
元のお話に戻りまして・・・。
先にログ要件を片付けましょう。AWS WAFは設定でログが出せるようになっています。
マネジメントコンソールのにログイン後、WAF & Shield
左ペインのWeb ACLsから該当するWEB ACLを選択して右ペインのLogging and metricsにて設定します。
このとき、ログストリームを新しく作るのですが、その際は必ず aws-waf-logs-から始まるように作成してください。
当時の私はこの制約を知らず、丸々1日ログが出ない？なんで？と時間を溶かしました。
また、Redacted fieldsというオプションがあります。
ここで先程のログ要件を満たすように設定をするので、以下のオプションを選択します。
・HTTP method
・URI Path
・Single header
必要な設定を行い、ログ取得の準備ができました・・・！！
ここで冒頭で紹介しましたOWASPの概略を確認します。
概略は以下のサイトにあります。
www.synopsys.com
プログラマ（開発者）向けなので、私のようなインフラエンジニアは読まなくても良いよみたいなことを言われていたためきちんと理解をしている訳では無いのですが、重点的な対策を行う必要があるのはTOP10のものが該当するそうです。のちに後悔してめちゃくちゃ読みまくってますが・・・。
また、その時その時の流行に合わせて内容も変わります。現在必要な物は必ず確認しておくと良いでしょう。
そして、本記事のもとになったプロジェクトの当時のTOP10は、次の通りです。
- インジェクション対策（SQLInjection）
- アクセス制御の不備（認証情報の漏洩）
- 機密情報の保護
- XML External Entites（XXE）
- Broken Access Control(アクセス設定の不備）
- セキュリティ設定のミス
- Cross-Site Scripting(XSS)
- Insecure Deserialization(安全ではないデシリアライゼーション)
- Using Components with Known Vulnerabilities(既知の脆弱性対策）
- Insufficient Logging and Monitoring(不十分なログと監視設定)
となります。
これら上記の10項目のうち、WAFで対策設定が可能なものは、1・2・5・7・9の5項目です。
10番に関しては先に記載したAWS WAFの設定で追加対策という形となりますが、基本対策はプログラマ（開発）側にて行う必要があります。
必要となるルールは、
- Paid rule groups内のBot Control
- Free rule groups内のAdmin protection・Core rule set・Linux operation system・SQL database
です。
次にRulesです。
設定方法は先程のWeb ACLから行い、Rulesの所のAdd rulesから"Add Managed rule gorups"を選択します。
まず必ず入れるのはBotコントロールです。
AWS Managed rule groupsのPaid rule groupsの中にあるBot Controlです。
説明を引用します。（詳しくは設定時のLearn Moreなどをご覧ください。）
Provides protection against automated bots that can consume excess resources, skew business metrics, cause downtime, or perform malicious activities. Bot Control provides additional visibility through Amazon CloudWatch and generates labels that you can use to control bot traffic to your applications.
ん？？？何言ってるかわからないって？
このルールは、企業アクセスが通常アクセスでは無いbotのアクセスを可視化、遮断しますよ。というものです。
これが必要な理由は、このシステムをbotサーチなどで発見されたくないためです。パブリック公開されていますが、大量にアクセスされても困るシステムですので。
設定したルールは、2番と5番の対策にも繋がる形となります。
残りの対策はどのルールがどの対策かを詳細記載していきますが、長くなってきてしまったので次の記事にさせてもらおうかなと思います。
