LoginSignup
1
0

OCI WAFで脆弱なアプリを保護する - エッジ・ポリシーの場合 -

Last updated at Posted at 2023-06-06

前回の記事では、WAFポリシーを作成しましたので、今回はGlobal WAFであるエッジ・ポリシーの手順を紹介します。エッジ・ポリシーは、OCI WAFがリリース時から提供されている基本のWAF機能で、OCI以外のプラットフォームで動作するWEBアプリケーションを対象にすることができます。
また、Regional WAFの場合は、ロードバランサーのIPで直接動作させることができましたが、Global WAFでは、ターゲットとなるWEBサーバへのアクセスをWAF経由になるようにDNSレコードの書き換えが必要になります。

そのため、今回のターゲットとなるDVWA(脆弱なアプリケーション)は、パブリックのIPに対するFQDNが必要です。ドメインを持っていない場合は、無料のドメインを取得するなどの準備をしておいて下さい。

※詳細な手順は、OCIチュートリアルにもありますので、こちらもあわせてご参照下さい。

エッジ・ポリシーの作成

  • OCIメニューから、アイデンティティとセキュリティ -> WEBアプリケーション・ファイアウォール -> ポリシーからWAFポリシーの作成を選択。エッジポリシーの場合は、画面下部のレガシー・ワークフローから作成
    image.png

  • プライマリ・ドメインとWAFのオリジン名には、DVWAのFQDN、URIにDVWAのパブリックIPを指定して作成
    image.png

  • 作成されたエッジ・ポリシーの保護ルールに以下の3つのルールIDでフィルタし、ルールに対するアクションをブロックに変更する
    9420000, 941140, 9410000
    image.png

  • すべて公開を選択し、ポリシーの編集を反映させる。更新には10分以上かかるので、その間にDNSにCNAMEのレコードを追加する。参考手順
    image.png

WAFポリシーの動作確認

FQDNでDVWAにアクセス(DNS名前解決されCNAMEで指定したWAF -> DVWAのアクセスルートになる)
http://DVWAのFQDN/DVWA-master/login.php

  • この手順でクロスサイト・スクリプティングとSQLインジェクションを実行する。正しくWAFが動作していれば、下記のリクエストをブロックしたメッセージが表示される
    image.png

  • エッジポリシーの詳細 -> ログから確認する。エッジポリシーの場合は、Loggingとの連携機能がないので、ログ参照できるのはこの画面のみでフィルターやグラフなどの機能はない
    image.png

Logging Analyticsとのログ連携

エッジポリシーのログは7日間保存。実際の運用では、ログを長期保管するためのオブジェクト・ストレージのバケットを用意し、WAFのログを常にバケットに書き込むようにOracle Supportにリクエストする必要がある。もしくは、OCI-CLIコマンドから自身でWAFのログを取得することも可能

ここでは、手早く確認するためにCLIを使ってログをダウンロードし、そのログをオブジェクトストレージに置き、Logging Analyticsがそこから直接収集するという方式を試してみる

※OCI-CLIが実行できる事前設定が必要。また、SR依頼で出力されるログとCLIで出力されるログのフォーマットは異なるため、以下の手順やログ・ソースは、CLIの場合のみ有効

#Object Storageのバケット作成
oci os bucket create --name waflog --compartment-id ocid1.compartment.oc1..

#CLIでWAFのログをダウンロード ※パラメータで日付を指定し、ファイル名に日時を追加
oci waas waf-log list --waas-policy-id ocid1.waaspolicy.oc1.. --time-observed-greater-than-or-equal-to 2023-06-02T00:00+09:00 --time-observed-less-than 2023-06-03T00:00+09:00 --all > waflog_`date +%Y%m%d%H%M`.log

#ログをObject Storageにアップロード
oci os object put -bn waflog --file waflog_xxxxxxx.log

#ログのフォーマットを正しく読み込むためのカスタム・ソースを下記のGithubからダウンロードする
wget https://github.com/western24/wafedge/blob/main/waf_edge_v1.zip
  • カスタム・ソースをLogging Analyticsにインポートする
    ログ・アナリティクス -> 管理、画面下部にある構成コンテンツのインポート。ソース、パーサーにwaf_edge_v1がそれぞれ追加されていることを確認
    image.png

  • Object Storageの位置を記述したJSONを準備。ここでは、waf_edge_log.jsonのファイル名で作成
    {
    "name": "名前",
    "compartmentId": "コンパートメントID",
    "osNamespace": "Object Storageのネームスペース",
    "osBucketName": "バケット名",
    "logGroupId": "Logging Analyticsのロググループ ID",
    "logSourceName": "waf_edge_log"
    }

#Logging AnalyticdがObject Storageからログの収集を開始するコマンド。パラメータ HISTORIC_LIVEは、バケットにある古いログから順に収集し、継続的に最新のログを取得することを意味する
oci log-analytics object-collection-rule create --from-json file://waf_edge_log.json --namespace-name namespace --collection-type HISTORIC_LIVE --poll-since BEGINNING
  • waf_edge_v1のログ・ソースのログがLogging Analtyicsに表示される。Logging Analyticsは定期的にバケットを参照しているので、新規ファイルが追加されるとログを取り込んでいく
    image.png

OCIサポート経由のWAFログとLogging Analytics連携

WAFのログをオブジェクト・ストレージに出力する方法は、こちらのCLIタブにあるオブジェクト・ストレージへのWAFログの配信の手順に従い設定する
大まかな手順の流れは、WAFのログを格納するObject Storageのバケットを作成、そのバケットにアクセスできる権限を持つユーザーを作成。そして、以下の必要な情報を埋めて、SRでエッジポリシーのログ出力としてリクエスト。通常1~2日でログの出力されるようになる

  1. Primary Domain name of the application: エッジポリシーで指定した対象のFQDN
  2. Access Key: ユーザーの顧客秘密キーのアクセス・キー
  3. Secret Key: ユーザーの顧客秘密キーのアクセス・キーのパスワード
  4. WAF Policy: エッジポリシーのOCID
  5. Bucket Name: Object Storageのバケット名
  6. Bucket OCID: バケットのOCID
  7. Bucket Region: Object Storageのリージョン
  8. Namespace: Object Storageのネームスペース
  9. Tenancy OCID: テナントのOCID
  10. Compartment OCID: コンパートメントのOCID
  11. Region identifier: エッジ・ポリシーのあるリージョン
  • バケットのWAFログは、以下のようなディレクトリ構成となり、caching_logsはアクセス・ログ、modsec_logsはポリシーに違反したログが書き込まれる
    image.png

  • ここでは、ポリシー違反したログ(modsec_logs)をLogging Analyticsに連携する設定を行う。ログのフォーマットを正しく読み込むためのカスタム・ソースを下記のGithubからダウンロードする
    https://github.com/western24/wafedge/blob/main/waf_modseclogs.zip

  • カスタム・ソースをLogging Analyticsにインポートする
    ログ・アナリティクス -> 管理、画面下部にある構成コンテンツのインポート。ソース、パーサーにwaf_modseclogsがそれぞれ追加されていることを確認
    image.png

Object Storageの位置を記述したJSONを準備。ここでは、waf_modseclogs.jsonのファイル名で作成
{
"name": "名前",
"compartmentId": "コンパートメントID",
"osNamespace": "Object Storageのネームスペース",
"osBucketName": "バケット名",
"logGroupId": "Logging Analyticsのロググループ ID",
"logSourceName": "waf_modseclogs",
"objectNameFilters":["FQDN/年/月/日/modsec_logs/*"]
}

※objectNameFiltersは、実際に出力さているバケットのmodsec_logsログのディレクトリを見ながら設定する。ワイルドカード(*)の指定も可能

#Logging AnalyticdがObject Storageからログの収集を開始するコマンド。パラメータ HISTORIC_LIVEは、バケットにある古いログから順に収集し、継続的に最新のログを取得することを意味する
oci log-analytics object-collection-rule create --from-json file://waf_modseclogs.json --namespace-name namespace --collection-type HISTORIC_LIVE --poll-since BEGINNING
  • waf_modseclogsのログ・ソースのログがLogging Analtyicsに表示される。Logging Analyticsは定期的にバケットを参照しているので、新規ファイルが追加されるとログを取り込んでいく
    image.png

※Object Collectionルールで指定できるObject Storageのバケットは一つのみ。
WAFのログは、caching_logsとmodsec_logsに2種類のログがひとつのバケットにまとめて出力されるので、caching_logsも同様にLogging Analyticsに取り込む場合は、別のバケットを作成し、移動するなどの対応が必要

以上がGlobal WAFと呼ばれるエッジポリシーの設定手順の流れです。ロードバランサー型のWAFポリシーとは、動作や設定がかなり異なる点がご理解頂けるのではないかと思います。
特にエッジポリシーのログは、Logging Analyticsにログを分析するパーサーが提供されていないので、今回のように自身でカスタム・パーサーを作成する必要があります。ただ、JSON形式の場合は比較的簡単にできますので、SR経由の場合のログはご自身で験してみて下さい。JSONではないですが、カスタムパーサーの作成手順はこちら

また、ポリシーの保護ルールの設定もWAFポリシーとは若干異なったり、ポット対策などWAFポリシーにはない機能もありますので、このテスト環境で実際の挙動や差異を確認する用途としてもお役立て頂ければ幸いです。

脆弱なアプリケーション(DVWA)をOCIにデプロイする
OCI WAFで脆弱なアプリを保護する - WAFポリシーの場合 -

1
0
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
1
0