5

AWS でホストされている Web アプリケーションに AWS WAF を使用して、追加のルールベースのセキュリティを提供する必要があります。ELB で WAF を直接使用する方法が見つかりませんでした。WAF には Cloudfront に WEB ACL を追加して、ルールに基づいてアクションをブロックする必要があります。そのため、アプリケーション ELB CNAME を cloudfront に追加し、ドメイン名、IP ブロック ルールを含む WebACL、および HTTPS プロトコルのみを cloudfront で更新しました。残りはすべてデフォルトのままです。ELB CNAME を使用した WAF と Cloudfront の両方が追加されたら、WAF のブロック IP ルールにある IP アドレスの 1 つから CNAME ELB にアクセスしようとしました。その IP アドレスから Web アプリケーションにアクセスできます。また、作成された Web ACL の cloudwatch メトリクスを確認しようとしましたが、ヒットすらしていません。まず、私がやっていることを達成するための良い方法はありますか?次に、クラウドフロントに ELB CNAME を追加する特定の方法はありますか?

ありがとう、ジェイ

4

1 に答える 1

23

サービスの更新:以下の元の拡張された回答は、それが書かれた時点では正しいものでしたが、2016 年 12 月 7 日の時点で、Application Load Balancer (elbv2) を直接統合できるようになったため、主にクラシック ELB に適用されます。ウェブ アプリケーション ファイアウォール (Amazon WAF) を使用します。

[2016-12-07] より、AWS WAF (Web Application Firewall) が Application Load Balancer (ALB) で利用可能になりました。VPC の Application Load Balancer (内部と外部の両方) で AWS WAF を直接使用して、ウェブサイトとウェブサービスを保護できるようになりました。今回のローンチにより、お客様は Amazon CloudFront と Application Load Balancer の両方で AWS WAF を使用できるようになりました。

https://aws.amazon.com/about-aws/whats-new/2016/12/AWS-WAF-now-available-on-Application-Load-Balancer/


これらの部品がどのように組み合わされるかについて、明確にする必要があるようです。

では、保護したい実際のサイトがapp.example.com.

ELB に割り当てられたホスト名 (example-123456789.us-west-2.elb.amazonaws.com など) を指す CNAME elb.example.com があるように聞こえます。これらのホスト名のいずれかにアクセスすると、CloudFront または WAF で構成されているものに関係なく、ELB に直接接続されます。これらのマシンは引き続きインターネット経由でアクセスできます。

ここでの秘訣は、トラフィックを CloudFront にルーティングすることです。ここで、WAF によってファイアウォールで保護できます。これは、いくつかの追加の処理が必要であることを意味します。最初に、これは追加のホスト名が必要であることを意味するため、DNS で app.example.com を構成します。ディストリビューションに割り当てられた dxxxexample.cloudfront.net ホスト名を指す CNAME (または Route 53 を使用している場合はエイリアス) として。

テスト用に、割り当てられた CloudFront ホスト名を使用して sitr に直接アクセスすることもできます。ブロックされた IP アドレスからこのエンドポイントにアクセスすると、実際にはリクエストが拒否されるはずです。

したがって、CloudFront エンドポイントは、ELB に直接ではなく、トラフィックを送信する必要がある場所です。

それはあなたのELBをまだ露出させたままにしませんか?

はい、そうです...次のステップはその穴を塞ぐことです。

カスタムオリジンを使用している場合は、カスタムヘッダーを使用して、ユーザーが CloudFront をバイパスしてオリジンからコンテンツを直接リクエストするのを防ぐことができます。

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/forward-custom-headers.html

ここでの考え方は、サーバーと CloudFront だけが知っている秘密の値を確立するということです。CloudFront はすべてのリクエストとともにヘッダーでこれを送信し、サーバーはその値が存在することを要求します。そうしないと、503 Service Unavailable や 403 Forbidden、さらには 404 Not Found などの愚かな動作をしてエラーがスローされます。

そのため、ヘッダー名 (like X-My-CloudFront-Secret-String) とラ​​ンダムな文字列 (like )o+mJeNieamgKKS0Uu0A1Fqk7sOqa6Mlc3を作成し、これを CloudFront のカスタム オリジン ヘッダーとして構成します。ここに示す値は任意の例です。これは何でもかまいません。

次に、このヘッダーと一致する値が存在しないリクエストを拒否するようにアプリケーション Web サーバーを設定します。これは、リクエストが特定の CloudFront ディストリビューションからのものであることがわかるからです。他のもの (例外を作成する必要がある ELB ヘルスチェック以外) は CloudFront ディストリビューションからのものではないため、定義上は許可されていないため、サーバーはエラーでそれを拒否する必要がありますが、エラーメッセージ。

このヘッダーとその期待値は、CloudFront によってブラウザーに送り返されないため、秘密のままです。CloudFront が ELB に送信するリクエストで、順方向にのみ送信されます。

ELB (elb.example.com ホスト名) の SSL 証明書を取得し、HTTPS を使用してすべてのリクエストを ELB に転送するように CloudFront を設定する必要があることに注意してください。CloudFront と ELB の間のトラフィックが傍受される可能性は低いですが、これは実装を検討する必要がある保護です。

また、必要に応じて、ELB セキュリティ グループで CloudFront IP アドレス範囲のみを許可することで、CloudFront から到着しないすべてのリクエストをブロックすることで、ほとんどの不正アクセスを削減 (ただし、排除ではない) することもできます。CloudFront アドレス範囲は文書化されています(JSON で検索してください)。として指定されたブロックを指定しCLOUDFRONT、ELB セキュリティ グループでこれらのみを許可します)。まだ技術的には誰でも許可していますELB にアクセスするための CloudFront ディストリビューション。CloudFront ディストリビューションはプール内の IP アドレスを他の CloudFront ディストリビューションと共有するため、リクエストが CloudFront から到着したという事実は、それが CloudFront ディストリビューションからのものであるという十分な保証にはなりませ。また、新しいアドレス範囲が CloudFront に追加された場合に、それらをセキュリティ グループに追加する必要があることがわかるように、変更通知にサインアップする必要があることにも注意してください。

于 2016-11-18T00:30:45.860 に答える