Cloudflare WAF機能の紹介第２回ファイアウォールルール編

MBSD-SOCのMSS(マネージドセキュリティサービス)では、WAF監視のサービスラインナップにCloudflare Webアプリケーションファイアウォールを加えました。
前回の記事に引き続き、Cloudflareのセキュリティ機能をご紹介していきます。今回は「ファイアウォールルール」について、主な機能と活用事例をご紹介します。

※クラウドサービスのため、仕様は随時変更されることが想定されます。本記事の内容は2021年1月時点までの検証結果を元にしています。

図1.セキュリティ機能

ファイアウォールルールの基本機能

ファイアウォールルールは、ユーザ自身が作成できるルールで、様々な条件を組み合わせてルールを作成することができます。イメージとしては、一般的なファイアウォールをレイヤ7まで拡張したもので、防御機能をさらに強化することもできますし、防御効果を維持したまま正規ユーザーの通信を通過させる、といったことも可能で、使い方次第で非常に強力なツールとなります。

ルール作成に必要な情報は、ルール名 / 条件式の組合せ / アクション、の３点のみです。
条件式は、主にレイヤ3/レイヤ4/レイヤ7の情報を指定できます。IPアドレス、送信元IPアドレスの国、ポート番号、URI、HTTPヘッダ、HTTPボディ、独自の脅威情報(送信元IPアドレスやbotのスコア)等、様々なものを指定することができます。
アクションは、検知/遮断/チャレンジ(前回の記事でご紹介)の他に、以下のようなものも設定できます。

許可　　：他のファイアウォールルールをバイパスします。ただし、マネージドルールはバイパスしません。
スキップ：他のセキュリティ機能を選択し、バイパスさせることができます。

各ファイアウォールルールの評価順序も指定することができます。

作成方法

ファイアウォールルールは、GUIから簡単に作成することができます。

図2.ルール作成画面

図2では、ルール作成の例として、特に意味のあるものではありませんが、

ルール名：Example Rule
条件：送信元IPアドレスが「192.0.2.0/24」、且つURIパスに「/example/」を含む、且つメソッドが「GET」
アクション：ブロック

としています。
オペレータはフィールドに応じて、等号・不等号、含む、正規表現、また、それらの否定等、様々なものを指定できます。

条件部分は、2種類の方法で作成することができます。

①式ビルダー
図2の通り、GUIから視覚的な操作のみで作成可能です。
ただし、フィールドとして選択できるものは一部のみとなっており、あまり複雑なルールを作成することはできませんが、シンプルなルールであれば簡単に作成することができます。

②式エディター
式ビルダーでは自動的に式が入力されますが、「式を編集」リンクをクリックすることで、ルールを直接記載することができ、より複雑なルールを作成することができます。

Cloudflare Firewall Rules languageという独自の言語ではありますが、

と、and/orの組み合わせであり、使用できるフィールドや演算子、詳細な記載方法は、ドキュメントが提供されているため、作りたいルールが明確であれば作成の難易度は高くないと思われます。

活用例

具体的にどのようなルールを作成することができるか、いくつか事例をご紹介します。

許可リスト
CMSは製品によっては、サイトメンテナンス時にXSS等のルールで検知してしまう可能性がありますが、その場合は遮断設定を解除する必要があります。また、脆弱性診断をする際に、セキュリティ機能をオフにして診断したい場合があります。そのような場合に、送信元IPアドレスを指定して、全てのセキュリティ機能をバイパスする(検知/遮断しない)することで、遮断設定を維持したまま目的の作業を行うことができます。
※次回の記事で別機能による実現方法をご紹介予定です。

図3.許可リスト

また、なんからの理由により特定ページのみセキュリティ機能を無効化したいといった場合には、URIパスを指定して全セキュリティ機能をバイパスすることで実現できます。

管理画面へのアクセス元制限
WordPress等のCMSや、一般向けと管理者向けでパスが異なるアプリケーション等において、管理者が特定のIPアドレスからしかアクセスしない場合に有効です。IPアドレスとURIパスの組み合わせで、管理者向け画面へのアクセスを制限することができ、外部からの攻撃を防ぐことができます。管理者のIPアドレスが固定でない場合は、アクションをチャレンジ(CAPTCHA)にするだけでもかなりの防御効果が得られる可能性があります。
※こちらも次回の記事で別機能による実現方法をご紹介予定です。

図4.管理画面へのアクセス元制限

国名での送信元許可
送信元として国名を条件にすることができるため、国内からのアクセスを想定したサイトであれば、思い切って日本以外からのアクセスを全て遮断する、といったことができます。攻撃の大半は国外からのため、攻撃防御という観点であれば非常に有効な策となります。完全に遮断したくない場合は、アクションをチャレンジにするのも有効かもしれません。
また、国名としてTorを指定することもできます。Tor自体は悪いものではないですし、正規の閲覧者がTor経由でアクセスすることも当然考えられますが、攻撃者も利用することがありますので、Torを制御の条件に加えるという案もありかと思われます。

図5.国名での送信元許可

脆弱性対応
既存で提供されているルールでも多くの脆弱性を狙った攻撃を検知できると思われますが、特定の脆弱性を確実に検知/遮断したい場合には、専用のルールを作成する必要があるケースもあります。
例えば、リモートコード実行の脆弱性に対してであれば、主にURIパスやヘッダー、クエリストリング、リクエストボディのパラメータ等を指定して作成することになります。
ただし、脆弱性や攻撃コードを理解した上で、適切な条件で作成する必要があります。

遮断できないCloudflareマネージドルールの補完
サイト仕様によって誤検知してしまうルールに対して、検知条件を厳しくして遮断できるルールとして作成することができます。
また、前回の記事でもご紹介した通り、一つのルールの中に複数検知条件が含まれているものがあり、一部の検知条件で誤検知するために遮断設定にできないものもある可能性があります。そのようなルールに対しても、遮断できる検知条件のみで作成することができます。
ただし、Cloudflareマネージドルールは検知条件が非公開のため、検知条件を推測した上で、検知傾向をよく見極めて作成する必要があります。

図6.遮断ルール作成

運用上の注意

WAFに相当するルール(カスタムシグネチャ)を作成することもできますが、ファイアウォールルールはWAF専用機能というわけではないため、ペイロードはロギングされません。ユーザー自身が作成したルールのため検知条件は当然分かりますが、検知した際にどのような攻撃だったのか、誤検知した際にどの部分で誤検知してしまったのかを確認することはできません。
また、条件にマッチしたものは全てロギングされます。アクションが許可やスキップでもロギングされてしまいます。他の機能(次回ご紹介予定)で代替できるルールの場合には、許可通信の不要なロギングを回避することもできます。

まとめ

ファイアウォールルールは、一部の情報や活用例しかご紹介することができませんでしたが、アイディア次第で色々なルールを作ることができます。送信元やURIパス等の簡単な条件であればGUI操作だけで直観的に作成することができますし、マネージドルールに不足しているルールを作成することもでき、活用の幅がとても広い機能です。
MBSD-SOCではこれまで多くのカスタムシグネチャを作成してきた実績がありますが、この機能はSOCエンジニア目線としても非常に面白く、これだけでもとても価値の高い機能です。

次回は、マネージドルール、ファイアウォールルールをさらに補完する、その他の様々なセキュリティ機能をご紹介します。

マネージドサービス事業部

MBSD-SOC