LoginSignup
3
2

はじめに

OCI WAF(Web Application Firewall)は、コンソール上で様々なルールを適用し、悪意のあるインターネット・トラフィックからのリクエストを除外することでweb アプリケーションを保護できるセキュリティ・サービスだと理解している。

例えば以下のような脅威がある。

  • 悪意のあるボット
  • アプリケーション・レイヤー(L7) DDOS 攻撃
  • クロスサイト・スクリプティング(XSS)
  • SQL インジェクション
  • Open Web Application Security Project (OWASP)で定義されたその他の脆弱性

これらを防ぐことができるOCI WAFには、WAFポリシーとエッジポリシーの2種類がある。
それぞれ詳細については以下を参照。
Webアプリケーション・ファイアウォールの概要

ゴール

ここでは、既に構築済のOCI上の以下構成に対して、FLBにプラグインして使うWAFポリシーでセキュリティ強化してみたいと思う。

image.png

事前準備

以下を参考に、OCI上で環境を構成する。

WAFポリシー作成

ここから、Web Application Firewall (WAF) を強制ポイントであるロード・バランサ (FLB) にプラグインしていく。

WAFポリシー作成

「ナビゲーション・メニュー」→「アイデンティティとセキュリティ」→「Web アプリケーション・ファイアウォール」の下の「ポリシー」をクリック。
image.png

「WAF ポリシーの作成」をクリック。

  • 基本情報
  • アクセス制御  ※ここでは一旦設定しない
  • レート制限  ※ここでは一旦設定しない
  • 保護  ※ここでは一旦設定しない
  • 強制ポイントの選択
  • 確認および作成

「WAF ポリシーの作成」では上記のようなセクションの構成となっているが、説明の都合上、ここでは「アクセス制御」・「レート制限」・「保護」については特に設定せず、WAF ポリシーの枠だけ作る。

  • 「基本情報」セクション:
    • 名前:WAFpolicy ※任意
    • コンパートメント:(ご自身のコンパートメント)
    • アクション:デフォルトのまま

「アクセス制御」・「レート制限」・「保護」は飛ばす。

  • 「強制ポイントの選択」セクション:
    • ファイアウォールの追加:作成したロードバランサを選択

「次」を選択する。

  • 「確認および作成」セクション:
    • 基本情報:設定した内容になっていること
    • アクセス制御:有効化されていないこと
    • レート制限:有効化されていないこと
    • 保護:有効化されていないこと
    • 強制ポイントの選択:追加した強制ポイントが正しいこと

「WAFポリシーの作成」をクリックする。
image.png

問題なければWAFポリシーの作成をクリックする。

作成し、アクティブになると以下のようになる。
赤枠で囲ったポリシーのところで、後続で記載する「アクセス制御」・「レート制限」・「保護」を設定できる。
image.png

レート制限ルールを追加してみる

「レート制限」オプションを構成して、指定した期間に一意のIPアドレスからのリクエスト数の閾値を設定する。

ポリシーの「レート制限」をクリックする。
image.png

「レート制限の管理」より5秒間に3 回という閾値を設定してみる。
image.png

  • 名称:任意
  • 条件:今回は特に設定しない ※任意
  • リクエスト制限:3
  • 期間(秒):5
  • アクション期間:空欄(=0 秒)
  • アクション名:「新規アクションの作成」を選択
    • 名前:limit-action_429 ※任意
    • タイプ:HTTPレスポンス
    • レスポンスコード:429 ※任意
    • レスポンス・ページ本文: 「Too many requests are being sent to Web Server.」
      image.png

「変更の保存」をクリックし、設定完了。
image.png

レート制限ルールが適用されているか確認

WAF ポリシーが更新され、アクティブ状態に戻ったことを確認したのち、ブラウザを開き、以下URLのように入力する。

URL
http://[Public IP of FLB]

Web ブラウザ・ページを5 秒で3 回以上リフレッシュして、以下のように指定したページ本文が表示されることを確認する。
image.png

試しに、5 秒で6 回と設定してレート制限確認を試してみたが…

上記、レート制限確認を試してみたが、5秒間で3回目のリフレッシュ・4回目のリフレッシュでtoo many requests~となってしまい、5 秒間で6 回という単純なロジックだけではなさそう(例えば、リクエスト間隔が5/6秒以下だったらブロックや2.5秒(半分)で3回(半分)リクエスト来たらブロック等。OCI内部のロジックになるので詳細は不明)。

2024/02/19時点のOracle Cloud Infrastructureドキュメントより、以下のように”最大数”というような記述もあるので、リクエスト実行のやり方(実行間隔)次第で、今回のように6回に満たなくてもブロックされることがありそう。
実際に本番環境のWebシステムを構築する際には、リクエスト制限、期間(秒)のチューニング・テストが必要になると思う。

リクエスト制限: 「期間」ボックスに割り当てられた時間値中に一意のIPアドレスが実行できるリクエストの最大数を入力します。
期間: リクエスト制限ボックスで指定した一意のIPアドレスから最大数のリクエストを実行できる秒数を入力します。

保護ルールを追加してみる

Oracle 管理のリクエスト保護機能を使用して悪意のあるトラフィックを検出するように、「保護ルール」を構成する。

ポリシーの「保護」をクリックする。
image.png

「リクエスト保護ルールの管理」より、XSSから保護するルールを設定してみる。
image.png

  • 名前:任意

  • 条件:今回は特に設定しない ※任意

  • アクション名:「新規アクションの作成」を選択

    • 名前:xss-action_503 ※任意
    • タイプ:HTTPレスポンス
    • レスポンスコード:503 ※任意
    • レスポンス・ページ本文: 「Service Unavailable: Web Server is secured against XSS attacks.」
      image.png
  • 本文検査:任意

  • 保護機能:「保護機能の選択」をクリック。

    • タグによるフィルタ: "XSS"と入力
    • バージョンによるフィルタ: 最新
    • 保護リスト: すべての保護をチェック
      image.png

「リクエスト保護ルールの追加」を確認してクリック。
「変更の保存」をクリックし、設定完了。
image.png

保護ルールが適用されているか確認

WAF ポリシーが更新され、アクティブ状態に戻ったことを確認したのち、ブラウザを開き、悪意のあるリクエストを模擬して、以下URLのように入力する。

URL
http://[Public IP of FLB]/index.html?<pstyle="background:url(javascript:alert(1))">

ブラウザにて、以下のように指定したページ本文が表示されることを確認する。
image.png

アクセス制御ルールを追加してみる

「アクセス制御」にて、様々な基準を満たす要求と応答の両方に対して明示的な処理を設定する。
今回は特定の地域(日本)からの要求はブロックするように、「アクセス制御」を構成する。

image.png

「リクエスト制御の管理」をクリック。

  • アクセス・ルール:「アクセス・ルールの追加」をクリック。
  • 名前:任意
  • 条件:「Country/Region」、「In list」、「Japan」を選択
  • アクション名:「新規アクションの作成」を選択
    • 名前:access-action_404 ※任意
    • タイプ:HTTPレスポンス
    • レスポンスコード:404 ※任意
    • レスポンス・ページ本文: 「Service Unavailable: The web server cannot be accessed.」
      image.png

「変更の保存」をクリック。
「アクセス・ルールの追加」をクリックすると、以下のように設定される。
image.png

  • デフォルト・アクション:「Pre-configured Allow Action」

「変更の保存」をクリックし、設定完了。
image.png

アクセス制御ルールが適用されているか確認

WAF ポリシーが更新され、アクティブ状態に戻ったことを確認したのち、ブラウザを開き、以下URLのように入力する。

URL
http://[Public IP of FLB]

私は日本からブラウザで入力したため、以下想定通りのメッセージが出力される。
image.png

実際に「Country/Region」を利用する場合は、どちらかというと日本以外からのアクセスをブロックするようなWEBサーバを構築するパターンの方が多そうなので、「Not in list」を利用することになると考えられる。

その他、挙動確認

「アクセス制御」・「レート制限」・「保護」の優先順位について

WAFポリシーでは「アクセス制御」・「レート制限」・「保護」それぞれ設定を入れることが可能。そのため、あらゆるケースを確認したわけではないが、3つ全てに設定を入れた場合において、どのポリシーから優先的にチェックされるのかを確認した。
URLは、いずれもXSSを模擬したURLを入力としている。

確認した結果をまとめると以下のようになった。

アクセス制御 保護 レート制限 表示結果
設定 設定 設定 「アクセス制御」のメッセージ
Service Unavailable: The web server cannot be accessed.
設定無 設定 設定 「保護」のメッセージ
Service Unavailable: Web Server is secured against XSS attacks.
設定無 設定無 設定 「レート制限」のメッセージ
Too many requests are being sent to Web Server.
※複数回実行の場合
  • 3つとも設定すると「アクセス制御」でブロックされた。
  • 「アクセス制御」のルールを削除し、残り2つ設定した状態の場合は「保護」でブロックされた。
  • 「保護」のルールも削除すれば、レート制限ルールが適用されているか確認と同様の状態になるので、複数回実行すると「レート制限」でブロックされた。

よって、アクセス制御 → 保護 → レート制限の順になった。

まとめ

今回は、WAFポリシーをパブリックFLBにプラグインして、2台のバックエンドサーバー(パブリックインスタンス)へのアクセスに対するセキュリティ強化を行ってみた。

また以下についても記述した。

次回は、WAFポリシーでブロックした場合に、運用管理者への通知(メール等)ができるようにしてみたいと思う。

参考URL

今回はXSSの「保護」ルールを適用してみたが、他にも多数OCIにて用意されている。詳細は以下。
【Oracle Cloud Infrastructure Documentation】Supported Protection Rules

3
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
2