Jayendra’s Blog

この記事は自己学習用に「AWS Web Application Firewall – WAF – Certification（Jayendra’s Blogより）」を日本語に訳した記事です。

AWS Web Application Firewall – WAF

  • AWS WAF は、CloudFront に転送された HTTP/HTTPS リクエストを監視し、コンテンツへのアクセスを制御できるようにする Web アプリケーションファイアウォールです。
  • WAF は、要求されたコンテンツまたはアクセス拒否 (HTTP 403) を使用して要求に応答する CloudFront に基づいて、リクエスト元の IP アドレスやクエリ文字列の値などの条件を定義できます。
  • CloudFront は、要求がブロックされたときにカスタムエラーページを返すように構成できます。
  • AWS WAF では以下の動作が可能です。
    • 指定されたもの以外のすべての要求を許可する – CloudFront がパブリック Web サイトのコンテンツを提供するが、攻撃者からの要求をブロックする場合に役立ちます。
    • 指定されたもの以外のすべての要求をブロックする – CloudFront が制限されたウェブサイトのコンテンツを提供するときに、ユーザーが Web 要求のプロパティによって容易に識別できるようにする場合に便利です。
    • 指定されたプロパティに一致する要求をカウントします – 定義されたプロパティに一致する要求をカウントできるため、新しいプロパティを使用して許可またはブロック要求を構成およびテストするときに役立ちます。Config が誤ってウェブサイトへのトラフィックのすべてをブロックしていないことを確認した後、設定は、許可または要求をブロックするために動作を変更するために適用することができます。

WAF の利点

  • 指定された条件を使用した Web 攻撃に対する追加の保護。
  • 条件は、次のような Web リクエストの特性を使用して定義できます。
    • リクエストの発信元の IP アドレス
    • リクエストヘッダーの値
    • リクエストに表示される文字列
    • リクエストの長さ
    • 悪意のある可能性がある SQL コードの存在 (これは SQL インジェクションと呼ばれます)
    • 悪意のある可能性があるスクリプトの存在 (これはクロスサイトスクリプティングと呼ばれます)
  • 複数の Web アプリケーションで再利用できるルール。
  • リアルタイムメトリックスとサンプル Web リクエスト。
  • WAF API を使用した自動管理。

WAF のしくみ

WAFでは、条件、ルール、およびWebアクセスコントロールリスト（Web ACL）を作成することによって、Web リクエストに対する動作を制御できます。

条件

  • 条件は、Web リクエストで監視する基本的な特性を定義します。
    • **悪意のあるスクリプト – xss (クロスサイトスクリプティング) ** – 攻撃者は、web アプリケーションの脆弱性を悪用するスクリプトを埋め込む。
    • リクエストの発信元の **IP アドレスまたはアドレス範囲。
    • クエリ文字列など、リクエストの指定された部分の長さ。
    • 悪意のある SQL – SQL インジェクション – 攻撃者は、Web リクエストに悪意のある SQL コードを埋め込むことによって、データベースからデータを抽出しようとする。
    • リクエストに表示される文字列 (たとえば、クエリ文字列に表示されるユーザーエージェントヘッダーまたはテキスト文字列に表示される値)。複数の値を取る条件もあります。

ルール

  • ルールは、基本的に条件の組み合わせで、許可またはブロックするリクエストを正確に対象としています。
  • ルールに複数の条件が含まれている場合、WAF　はすべての条件に一致するリクエストを探します。
  • たとえば、攻撃者から見た最近のリクエストに基づいて、次の条件を含むルールを作成する場合があります。
    • リクエストは、192.0.2.44 から来る。
    • ユーザーエージェントヘッダーに BadBot 値が含まれています。
    • クエリ文字列には、悪意のある SQL コードが含まれているように見えます。
  • ルールが渡され、関連付けられたアクションを実行するには、3つの条件をすべて満たす必要があります。

Web ACLs

  • Web ACLs が提供する。
    • ルールの組み合わせ
    • アクション: 各ルールに対して実行する許可、ブロック、またはカウント**
      • WAF は、リクエストがリストされている順序で Web ACL のルールと比較され、リクエストが一致する最初のルールに関連付けられているアクションを受け取ります。
      • Web ACL の複数のルールでは、WAF は、Web ACL にリストされている順序で各要求をルールに照らして評価します。
      • Web リクエストルール内のすべての条件に一致する場合、WAF は直ちにアクション (許可またはブロック) を実行し、Web ACL 内の残りのルールがある場合は、そのルールに対して評価しません。
  • デフォルト・アクション
    • WAF が、いずれかの規則のすべての条件に一致しないリクエストを許可またはブロックするかどうかを決定します。

Webアプリケーションファイアウォール・サンドイッチ・アーキテクチャ

注:-DDoS の回復性のホワイトペーパーから、AWS WAF を使用していません。

  • アプリケーション層での DDoS 攻撃は、一般的に、インフラストラクチャの攻撃に比べてトラフィックの少ないボリュームを持つ Web アプリケーションを対象としています。
  • WAF は、これらのタイプの攻撃を軽減するためにインフラストラクチャの一部として含めることができます。
  • WAFs は、XSS や SQL インジェクションなどの悪用をカバーする Web トラフィックに一連のルールを適用するフィルタとして機能しますが、HTTP GET または POST フラッドを軽減することにより、DDoS に対する回復力を構築するのにも役立ちます。
  • HTTP は、エンドユーザーがデータ (GET) をリクエストし、処理するデータを送信 (POST) するエンドユーザーとアプリケーションの間のリクエスト – 応答プロトコルとして機能します。高い速度で同じ URL をリクエストするか、アプリケーションからすべてのオブジェクトを要求することによって、フラッドの作業を取得します。POST フラッドは、高価なアプリケーションプロセス、すなわち、ログインやデータベースの検索を見つけることによって動作し、アプリケーションを圧倒するこれらのプロセスをトリガします。
  • WAFs は、特定の期間内にエンドユーザーごとのリクエスト数を制限する HTTP レート制限などのアプリケーションの可用性に影響を与えることから、これらの種類の攻撃を防ぐことができるいくつかの機能を備えています。しきい値を超えると、WAFs は新しいリクエストをブロックまたはバッファリングして、他のエンドユーザーがアプリケーションにアクセスできるようにすることができます。
  • WAFs は、HTTP リクエストを検査し、通常のパターンでは確認できないものを特定することもできます。
  • 「WAF サンドイッチ」では、WAF ソフトウェアを実行している EC2 インスタンス (AWS WAF ではありません) が AutoScaling グループに含まれ、2つの ELB ロードバランサーの間に配置されます。デフォルトの VPC 内のベーシックロードバランサーは、WAF EC2 インスタンスへのすべての着信トラフィックを分散させる、パブリックに直面しているロードバランサーのフロントエンドになります。
  • WAF サンドイッチパターンを使用すると、インスタンスは、トラフィックが昇格されたレベルにスパイクする必要があります追加の WAF EC2 インスタンスを拡張し、追加することができます。
  • トラフィックが検査およびフィルタ処理されると、WAF EC2 インスタンスはトラフィックを内部のバックエンドロードバランサーに転送し、その後、アプリケーション EC2 インスタンス全体にトラフィックを分散します。
  • この構成により、WAF EC2 インスタンスは、アプリケーション EC2 インスタンスの可用性に影響を与えることなく、容量の要求をスケーリングして満たすことができます。

AWS認定試験の練習問題

  • 質問はインターネットから収集され、答えは自分の知識と理解に基づいてマークされます（これはあなたと異なる場合があります）。
  • AWSサービスは毎日更新され、回答と質問はすぐに時代遅れになる可能性がありますので、それに応じて調査してください。
  • AWSのアップデートのペースを追うためにAWS試験の質問は更新されないため、基礎となる機能が変更されても質問が更新されないことがあります。
  • さらなるフィードバック、ディスカッション、修正を可能にします。
  1. あなたは非常に大きな電子商取引サイトの全体的なセキュリティの姿勢を強化するために雇われてきた。VPC 内では、Web と APP 層の両方の前でエルを使用する、S3 から直接提供される静的アセットを持つ、十分なアーキテクチャの多層アプリケーションを実行しています。彼らは、その動的データのために RDS と DynamoDB の組み合わせを使用しているし、EMR でさらに処理するために、S3 に毎晩アーカイブ。彼らは不審なログエントリを発見し、誰かが不正アクセスを取得しようとしている疑いがあるため、彼らは心配している。どのアプローチが、この種の攻撃に対してコスト効率の高いスケーラブルな緩和を提供しますか?
    1. DirectConnect のパートナーの場所でスペースをリースし、1G DirectConnect との接続を確立することを推奨し、彼らは、そのスペースにインターネット接続を確立すると、ハードウェアの web アプリケーションのファイアウォール (WAF) のトラフィックをフィルタリングします。次に、DirectConnect 接続を介してトラフィックを、VPC 内で実行されているアプリケーションに渡します。(費用効果はありません)
    2. Web 層サブネットへの明示的な受信拒否 NACL として、以前に特定された敵対的ソース IP を追加します。(新しいソースから保護しません)
    3. ホストベースの WAF を実行している EC2 インスタンスの新しい ELB とオートスケーリンググループを作成して、WAF 層を追加します。彼らは、新しい WAF 層 ELB に解決するためにルート53をリダイレクトします。WAF 層は、現在の Web 層にトラフィックを渡します。Web 層セキュリティグループは、WAF 層セキュリティグループからのトラフィックのみを許可するように更新されます。
    4. TLS 1.2 を Web 層 ELB からすべて削除し、高度なプロトコルフィルタリングを有効にするこれにより、ELB 自体が waf 機能を実行できるようになります。(ELB では高度なプロトコルフィルタリングはありません)

リファレンス