MBSD-SOCのMSS(マネージドセキュリティサービス)では、様々なセキュリティ製品の監視に対応していますが、近年Webアプリケーションファイアウォール(WAF)の需要が非常に高まっています。そこで、WAF監視のサービスラインナップにCloudflare Webアプリケーションファイアウォールを加えました。

ラインナップに加えるにあたり、 Cloudflareのセキュリティ機能を検証しましたので、各機能の特徴を、運用方法の観点等も含めて、複数回に分けてご紹介します。

本検証に当たり、クラウドフレア・ジャパン様には多大なサポートを頂きました。厚く感謝を申し上げます。

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

Cloudflareとは

Cloudflareは、コンテンツデリバリネットワーク(CDN)サービスのグローバルシェア上位企業です。セキュリティに関してはDDoS防御やWAF機能などを提供しています。また、「1.1.1.1」のパブリックDNSを運営していることでも知られています。

CloudflareのWAF/セキュリティ機能

CDNを利用するにあたり、セキュリティ機能も利用することができます(プランにより利用できる機能が異なります)。Cloudflareのセキュリティ機能は、「ファイアウォール」という名称で提供されており、WAF機能を含め様々な機能が提供されています。

今回は、 「ファイアウォール」 のメインであるWAF機能のマネージドルールについてご紹介します。

図1.セキュリティ機能

マネージドルール

一般的にWAFは、不正通信の特徴を定義したシグネチャにより攻撃を検知・遮断します。
Cloudflare WAFでは、シグネチャがマネージドルールとして提供されています。マネージドルールは大きく分けて、Cloudflareマネージドルールと、OWASP ModSecurity Core Rule Set(OWASPルール)の２つから構成されています。

まず、検証結果の結論を先にご紹介します。

マネージドルール全体として、元々がCDNサービスのためWAF専用機のような高度な設定はできませんが、設定方法は簡単/シンプルで手軽に利用することができます。しかしながら、適切に運用することで多くの攻撃を検知/遮断でき、これだけでもWAFとして十分機能するものと考えられます。また、別途ご紹介する多くの機能とも組み合わせることで、十分すぎるほどの防御効果が得られます。
CDNとWAFをセットで検討している場合にはCloudflareは有力な候補になりうると考えられます。

それでは、各ルールの仕様面での主な特徴をご紹介します。

図2.ルールの特徴

各ルールの特徴について、実際の運用を想定してもう少し踏み込んでご紹介します。

Cloudflareマネージドルール

Cloudflareマネージドルールにはデフォルト設定が用意されており、以下のような設定になっています。

• 有効になっているルールは全体の4割程です。多くが無効化されている理由は、古い脆弱性に対するルール、サイトの仕様によっては誤検知する、等が考えられます。
• 有効になっているルールのアクションは、ほとんどが遮断設定です。

これは、ユーザー自身がWAFを運用する場合において、WAFの知識がなくてもある程度の効果が得られるようになっていると考えられます。
WAFの運用は非常に難しく、サイトの仕様に応じてルールを適切に遮断/無効化チューニングしないと、アラート数が非常に多くなり影響確認等のアラート対応に多くの人的リソースが必要となります。また、遮断/無効化に変更する際の判断において、誤検知の傾向確認、検知する攻撃の重要度等、高度な知識とスキルが要求されます。Cloudflare WAFはルールの検知条件が非公開のため詳細な確認はできませんが、デフォルト設定では、検知精度が高い(誤検知する可能性が低い)ものが有効化/遮断設定になっており、アラート対応がほぼ不要、といった設定になっていると考えられます。

設定方法自体はとても簡単です。ルール一覧画面から、変更したいルールに対してプルダウンでアクションを選択するだけです。変更するとすぐに反映されます。

図3.ルール設定画面

一番気になると思われるのが、”どの程度攻撃を検知できるか”といった点ですが、WAFはあくまで防御対象サイトに対しての効果で判断する必要があるため、「スキャンツールを回して何件検知できた」といった定量的な評価はあまり意味を持ちません。また、どのような攻撃を検知できないかについても公にするのは好ましくないため、可能な範囲でご紹介します。

提供されているルール数としては、全部で400件超で、数としては少ない印象です。しかしながら、ルール名を見る限りでは、WAFとして検知すべき主要な攻撃の種類はほぼ網羅しているように見受けられます。また、検知条件非公開のため詳細は不明ではありますが、ルール数以上の攻撃はカバーされているように思われます。ルール名として複数条件が含まれていると想定されるものが複数あり(一つのルールで複数のOSコマンド実行を検知できると推測できるもの等)、実際に攻撃リクエストを投げて、１つのルールで複数の攻撃を検知することができました。尚、一つのルールに複数条件が含まれているということは、重要な攻撃の検知にとても有効なルールなのに一部の検知条件で誤検知することにより遮断設定にできない、といったことが発生する可能性があります。

様々な攻撃リクエストで検知確認したところ、デフォルト設定ではやはり検知できないものが多くありましたが、全てのルールを有効化した際には多くの攻撃を検知することができました。わずかに検知できないものが確認できましたが、全ての攻撃を検知することは現実的に難しいですし、ルールは頻繁にアップデートされているので今後検知できるようになる可能性もあります。また、防御対象サイトに影響がない攻撃まで検知する必要もないかと思われます。とはいえ、状況によっては独自にルールを追加して防御する必要がある場合もありますが、Cloudflareではファイアウォールルールという機能でルールを作成することができます。

WAFにおける一般論ではありますが、効果を最大限に得るためには、ルールの適切なチューニングが必要になります。Cloudflare WAFにおいては、デフォルト設定からの変更として、必要なルールの有効化、誤検知がないルールの遮断設定、過剰検知するルールの無効化を行います。
また、重要な攻撃の検知に有効なルールなのに一部の検知条件で誤検知することにより遮断設定にできない、といったルールに対しては、遮断できる検知条件のみでファイアウォールルールを作成する、といった対応も検討が必要になります。
ルールによっては、どうしても無効化も遮断設定もできないようなものもあります。そのようなルールで検知したアラートに対しては、影響確認等の対応を行う必要があります。
高度なスキルを要するチューニングやファイアウォールルールの作成、検知アラートの影響確認は、SOCベンダーの利用が効果的です。

図4.Cloudflareマネージドルールのチューニング設定イメージ

OWASPルール

OWASPルールは、デフォルトの設定というものは特にありません。
OWASPルールにも様々な攻撃の種類に関するものが数多く提供されていますが、スコア加算は種類別ではなく、単純に検知条件にマッチした全ルールのスコア合算値で閾値判定します。
各ルールの検知条件は単純なものが多いと想定されるため、サイトの仕様や通信内容によっては、正常な通信でもスコアが大きくなってしまう可能性があります。
閾値(機密度)は用意された３段階(高/標準/低)から選択するのみです(機密度のため”低”の方が値が大きい)。各ルールに対して設定できるのは有効/無効のみで、個別のスコア値は変更することはできません(仮に細かく変更できたとしたら、どのような値にチューニングすればいいかに頭を悩ますことにはなります)。

また、チューニングを検討するにあたり、さらに色々な制約があります。

• OWASPルールの閾値とアクションのペアは１つしか設定することができません。
  (“閾値：高”は検知、”閾値：低”は遮断といったことを同時に設定することができません)
• 閾値超過しないとロギングされません。
• ルールには評価順序があります。順序が上位のルール(Cloudflareマネージドルール等)で遮断された場合は、下位のOWASPルールは評価・ロギングされません。

図5.OWASPルールの動作例

遮断設定する際には、”閾値：高”の状態で検知傾向をよく見極めた上で、過剰検知するルールは無効化し、実際に設定する閾値を選択する必要があります。
(一度”閾値：低”で設定してしまうと、小さいスコア値でどのように誤検知するか確認できなくなってしまいます)

攻撃検知の検証においては、実際にCloudflareマネージドルールで検知できない攻撃をOWASPルールのアノマリで検知できた事例が複数ありました。サイトによっては遮断設定にできない可能性もありますが、より多くの攻撃を検知するには有効です。

OWASPルールの使用は、サイトの方針によって大きく変わるかと思われます。
例えば、”誤遮断のリスクよりも防御優先のサイト”であれば積極的に活用できるかと思われます。“求められるセキュリティレベルは高いが誤遮断は許容されないサイト”の場合は、チューニングやアラート対応が必要になり、運用の難易度が高いため、やはりSOCベンダーの利用が必要と考えられます。

ペイロードのロギング

CloudflareマネージドルールとOWASPルールに共通する大きな特徴として、攻撃を検知した際に、検知した部分のペイロード(通信の中身)をロギングすることができます。クラウドWAFサービスによってはペイロードをロギングできないサービスもありますが、MBSD-SOCではペイロードをロギングできることを非常に重視しています。
ペイロードは、アラート対応時に非常に重要な情報です。アラート検知した際の影響判断において、ペイロード情報がないとどのような攻撃なのか確認することができません。また、チューニングの際にもペイロード情報がないと、攻撃を検知したのか、正常通信の誤検知なのかの判断が難しくなります。
“メーカーデフォルト設定任せで遮断前提”という思想のWAFであれば、ペイロードロギングの必要性は低いかもしれませんが、WAFを適切に運用し効果を最大限に得るためには、地味な機能ではありますが、ペイロードのロギングはとても重要な機能です。

アクション

ルールの検知条件にヒットした際のアクションとして、”シミュレート(検知)”、”ブロック(遮断)”の他に、”チャレンジ”というものが選択できます。”チャレンジ”は、ブラウザの画面にCAPTCHAが表示されます。閲覧者は適切な画像を選択することで、閲覧を継続することができます。このアクションは、スキャンやbot等に対しては実質遮断の効果が得られると思われます。
活用例としては、攻撃検知に非常に有効なルールなのに稀に誤検知してしまい”ブロック(遮断)”にできない、といった場合に有効です。

まとめ

マネージドルールで設定できる内容は、ほぼご紹介した範囲内のもののみで、非常に簡単/シンプルです。
OWASPルールにおいては、現在の仕様では設定の柔軟性にはやや欠けるところがあるため今後の改善が期待されますが、マネージドルール全体として、WAF運用に必要な機能が揃っており、適切にチューニングすることで多くの攻撃を検知/遮断することができます。
これだけでもWAFとして十分機能するものと考えられますが、他のセキュリティ機能とも組み合わせて活用することで、さらに防御効果を高めることができます。

次回は、ユーザがルールを作成することができるファイアウォールルール機能についてご紹介します。