コンテンツ管理システム（CMS）を使うと、コンテンツの作成、更新、管理が簡単になります。一方で、サーバー侵害やデータ窃取につながる脆弱性が生じることもあります。
こうした攻撃を防ぐ Cloudflare の機能は多くあります。ただし、ログインや画像のアップロードなど、通常の管理作業を妨げる場合もあります。適切に設定すれば、必要な機能を失わずにサイトを守れます。
この段階では、ゾーンのセキュリティ機能を強化します。例外を入れるまでは、管理機能が追加で使えなくなることがあります。そのため、管理作業の停止を見込んだうえで変更することをおすすめします。
以下は推奨するセキュリティ対策の概要であり、包括的なガイドではありません。製品や機能の詳細は、各デベロッパードキュメントを参照してください。
WAF Managed Rulesets は、さまざまな攻撃に対する即時の防御を提供する、事前設定済みのルールセットです。定期的に更新されます。多くのルールはデフォルトで有効ですが、すべてではありません。Cloudflare Managed Ruleset を確認し、利用中のコンテンツ管理システム向けにタグ付けされていて、まだ有効になっていないルールがあれば、有効にすることをおすすめします。
Managed Rulesets をカスタマイズする機能には有料プランが必要でした。一方、Free Cloudflare Managed Ruleset ↗ は、新しい Cloudflare ゾーンに自動でデプロイされます。このルールセットは、非常に幅広いトラフィック種別で、誤検知を最小限に抑えるよう設計されています。現時点では、次のルールが含まれます。
- URI と HTTP ヘッダー内のペイロードに一致する Log4J ルール
- Shellshock ルール
- よくある WordPress の脆弱性を突く攻撃に一致するルール
加えて、OWASP Core Ruleset の異常スコアのしきい値、Paranoia Level、個別ルールなど、多くの項目を設定できます。XSS と SQL インジェクション関連のルールは、有効にしておくとよいです。
最小権限の原則に従い、管理画面からテスト操作を実行し、何がブロックされ、何が許可されるかを確認します。その情報をもとに、対象を絞った例外を作れます。想定どおりに動かない場合は、次を確認してください。
- DNS レコードがプロキシされている
- WAF を妨げる Rules がない（Disable Security に設定した Page Rule など）
Firewall Events に十分なサンプルが残るまでリクエストを発生させたあと、Managed rules セクションで実行されたアクションを確認します。
次に、この情報を使い、管理操作を妨げているルールだけを除外する Skip ルールを作成します。
このルールは、できるだけ厳密に定義することをおすすめします。とくに、後述の追加防御がない場合は重要です。具体的な条件はサイトごとに異なります。使えるフィールドの例は次のとおりです。
- IP Source Address
- AS Num
- Cookie
- User Agent
ルールは、CMS の管理画面部分にのみ適用してください。WordPress の場合は、「URI Path contains /wp-admin/」のような条件を設定できます。
これらのフィールドはなりすませるため、これだけではセキュリティ対策になりません。目的は、管理機能が必要な条件にだけ機能を復元することです。アクセスの保護には、ほかのツールや機能（CMS ログインの強力なパスワードを含む）を使います。
次に、Firewall のログを使い、スキップするルールを選びます。例外を追加してください。WordPress では、次を選びました。
完了したら、ログインを妨げるルールセットにも、同様のルールを作成します。この例では、「OWASP Core Ruleset 949110」だけをスキップすれば十分でした。
注: CMS 以外の部分で問題が出る場合は、有効にした CMS 向けルールをスキップするルールの追加も検討してください。手順は上記と同じです。上で有効にした Cloudflare Managed Ruleset のルールをスキップするよう設定します。hostname、URI、cookie を条件に、演算子は does not equal、does not match、does not contain を使えます。
Skip ルールは、Execute ルールより高い優先度に設定してください。
公開部分を攻撃から守るセキュリティを上げ、必要な管理機能も戻しました。ログイン情報が弱い、または漏えいした場合に備え、管理画面へアクセスできる対象をさらに制限できます。
管理画面へのアクセスを制限するには、Zero Trust ↗ Web Applications が最適です。デバイスではなくユーザー単位で制限でき、細かい制御が可能です。Self-hosted の Web アプリケーションのセットアップは簡単です。詳しくは、Zero Trust デベロッパードキュメントの Self-hosted applications を参照してください。
Web アプリケーションを設定すると、制限したコンテンツへアクセスする前に、何らかの認証が必要になります。デフォルトの方法は、メールによる多要素認証です。
ログインできない機器の認証向けに設計されています。一方で、mTLS はデバイス証明書による多要素認証（知っていることと持っているもの）としても使えます。
次の手順を行います。
- クライアント証明書を作成し、証明書と鍵の両方をデバイスに保存します。
- 証明書をコンピューターのキーストアにインポートします。macOS の Keychain では、ブラウザーでテストするの手順を使えます。
- 正しいホストを追加して mTLS を有効にします。
- SSL/TLS > Client Certificates で、Create mTLS Rule を選びます。
- When incoming requests match で、URI Path フィールドに値を入力し、ルールの対象を管理画面に絞ります。絞らないと、公開コンテンツへの訪問者もブロックします。
- クライアント証明書が検証されない場合、管理画面へのリクエストを Block するようルールを設定します。
- Deploy を選びます。管理画面へのすべてのリクエストで、有効なクライアント証明書を確認する WAF カスタムルールが作成されます。
注: 証明書の検証で問題がある場合は、プライベートウィンドウでページを開いてみてください。それで成功する場合、以前成功した TLS 状態がブラウザーにキャッシュされている可能性があります。
レート制限ルールは、攻撃者がパスワードを推測する ブルートフォース攻撃 ↗ からログインページを守るのに役立ちます。式に一致するリクエストのレート制限と、その制限に達したときのアクションを定義できます。
Rate Limiting Rules は、すべてのプランで従量課金なしで利用できます。詳しくは デベロッパードキュメント を参照してください。