Skip to main content

AWS WAF

AWS WAF解説 構成図

Overview​

AWS WAFは、Webアプリケーションに対する攻撃から保護するサービス。
AWS WAFは、OSI参照モデルの7層(アプリケーション層)を防御し、SQLインジェクション、クロスサイトスクリプティング、OSコマンドインジェクション、DDoS攻撃などの攻撃を防ぐために利用される。

  • L7(HTTP/HTTPS) アプリケーション層の防御
  • Web ACLによりアクセスの制限を実現
  • SQL InjectionやXSS, アプリケーション固有の攻撃に対応
tip

AWS WAFはCloudFrontと連携してWEBアプリケーションに対する特定のIPアドレスへのアクセス制限を実施できます。

Image from Gyazo

Webトラフィックをフィルタリングするカスタムルールを作成することで、アプリケーションの脆弱性を悪用しようとする攻撃から保護でき、作成したルールは、次のAWSサービスに設定できます。

  1. CloudFront
  2. ALB
  3. API Gateway
  4. AppSync

保護したいすべてのアプリケーションごとにルールを再作成する必要はなく、1つのルールセットを作成し、アプリケーション間で再利用できる。

AWS WAF各用語​

  • Web ACL ウェブアクセスコントロールリストで Rules を紐づける
    1つのWeb ACLに適用可能な Rule は10個まで CloudFront, ALB, API GatewayにWebACLを関連付けして利用。

  • Rules 具体的な条件を指定する Condition を紐付け管理する 1つのRuleに適用可能な Condition は10個まで。

＜Conditions＞ 防ぎたい攻撃の条件を具体的に定義する SQL InjectionやXSSの Condition が用意されている アプリケーション固有の攻撃に対応する場合は独自の条件を記述する。

AWS WAFでWeb Applicationを防御する手順​

  1. アクセス制御の目的に合わせて Condition を作成
  2. 作成した Condition を含む Rule を作成
  3. 作成した Rule を適用するための Web ACL を作成
  4. 作成したRuleを Web ACL に適用
  5. Web ACLをCloudFront, ALB, API Gatewayのいずれかに適用

AWS WAF で許可または拒否可能なリクエスト​

AWS WAFでは以下の種類のリクエストを許可または拒否することが可能。 AWS WAFでは、1 Web ACLに設定できるルール数には限りがあるためサイトの用途に応じて適切に選択することが重要。

  • 送信元IPアドレスが、特定のIPアドレスまたはIPアドレス範囲
  • 送信元IPアドレスが、特定の国
  • リクエストの特定の部分の文字列マッチング（正規表現可）
  • 指定した長さを超えている
  • SQLインジェクションやクロスサイトスクリプトが含まれている

ASN（自律システム番号）とは​

ASN（Autonomous System Number）は、インターネット上の大きなネットワークのまとまり（AS: Autonomous System）に割り当てられる番号。
ざっくり言うと「どのネットワーク事業者・組織から来た通信か」を示す識別子。

  • IPアドレス: 個々の端末や通信元を識別
  • ASN: そのIPをまとめるネットワーク運用主体を識別

同じASN配下には多数のIPレンジが存在するため、IP単位よりも広い粒度で制御できるのが特徴。

AWS WAFでASNを検査するメリット​

AWS WAFでASNを条件に許可・拒否できるようになると、IP単位の追いかけ運用を減らしやすくなる。

  1. 攻撃元のIPが頻繁に変わる場合でも、同一ASNならまとめて対処しやすい
  2. 既知の悪性トラフィックが多いネットワーク単位で遮断できる
  3. 逆に、信頼できるパートナー企業のASNだけ許可する設計もできる

IPブロックとASNブロックの使い分け​

IPでブロックすべきケース​

  • 単一IPまたは狭いIPレンジからのピンポイント攻撃
  • 誤検知リスクを最小化したい初動対応
  • 一時的に短時間だけ遮断したい

ASNでブロックすべきケース​

  • ボットやスキャンが同じ事業者ネットワーク（同ASN）から継続的に来る
  • 攻撃側がIPを短時間でローテーションしている
  • 個別IPのブラックリスト運用コストが高すぎる

併用パターン（実務向け）​

  1. まずIPで緊急遮断して被害を止める
  2. ログを見て同一ASNからの再発が多ければASNルールを追加
  3. 誤遮断を避けるため、業務上必要な通信は例外ルールで許可

ユースケース​

1. ログインAPIへのブルートフォース対策​

  • 症状: ログイン試行が大量発生し、IPが次々に変わる
  • 対応: レートベースルール + ASN条件で拒否
  • 狙い: IPローテーションを伴う攻撃をネットワーク単位で抑える

2. 管理画面を特定ネットワークだけに限定​

  • 症状: 管理画面は社内・委託先のみ利用
  • 対応: 許可ASNを明示し、それ以外を拒否
  • 狙い: 公開面を大きく縮小して不正アクセスリスクを下げる

3. スクレイピング/在庫監視ボット対策​

  • 症状: 商品詳細APIに高頻度アクセス、IPを変えながら継続
  • 対応: 既知のボット発生元ASNを段階的に遮断
  • 狙い: アプリ負荷と転売/情報取得系の自動アクセスを低減

運用時の注意点​

  1. ASNは大きなネットワーク単位のため、正規ユーザーを巻き込む可能性がある
  2. いきなり本番遮断せず、まずCountで影響を観測してからBlockへ切り替える
  3. CloudWatchやWAFログで継続的に効果測定し、例外ルールを育てる

参考​