どのようなサイトが狙われているか？Cloudflareセキュリティログから見る攻撃の傾向と対策
Cloudflare無料プランで運用している静的サイトのセキュリティ画面を確認したところ、直近7日間でブロックされたリクエストは543件ありました。その中には、WordPressの設定ファイルである wp-config.php を探すアクセスが多数含まれていました。
この記事では、このログをもとに、どのようなアクセスが届いていたのか、どのような国や地域からのアクセスが多かったのか、そして無料プランでどのような対策ができるのかを整理します。
対象期間と環境
対象は、Cloudflareの無料プランで運用している静的サイトです。期間は、ダッシュボードのセキュリティ分析画面で「直近7日間」を選択した範囲です。
この分析には限界があります。集計の対象は、ブロックされたリクエストだけです。ブロックされなかったリクエストは含まれていません。User-Agentやリクエストヘッダといった生ログも確認していないため、攻撃手法の分類は、アクセスされたパスから推測したものです。また、WAF Managed RulesとWAF Custom Rulesの件数は確認できましたが、どのルールが何件ブロックしたかという内訳は、画面から調査できませんでした。
全体像
ブロックされたリクエストは合計542件で、アクションはすべてBlockでした。Managed ChallengeとJS Challengeによる処理は0件です。検知した仕組みの内訳は、WAF Managed Rulesが284件、WAF Custom Rulesが251件、Rate Limitingが0件でした。
届いていたアクセスの種類
設定ファイルとバックアップファイルの探索
最も目立ったのは、wp-config.php とその派生ファイル名を狙ったアクセスです。パス別の件数を合計すると約146件になりました。ただし、パス別の集計とブロック総数の集計は別の表示であるため、全体に占める割合は目安にとどまります。
件数が多かったのは wp-config.php~ の27件、続いて拡張子なしの wp-config.php が24件、.bak が17件、.save が13件、.old が9件、.swp が8件でした。ほかにも、_old2021 のように年号を付けたもの、.zip や .backup、.orig、.txt といったものまで、さまざまな名前が試されていました。
チルダ付きのファイルや .swp はエディタが作る一時ファイルで、.bak や .old は手作業でバックアップを取るときによく付ける名前です。こうしたファイルが公開ディレクトリに残っていると、設定情報を読み取られるおそれがあります。このような名前が並んでいることから、バックアップや編集の過程で残ったファイルを探す自動スキャンだと考えられます。
機密ファイルや開発用ファイルの探索
wp-config.php 以外では、/.git/HEAD が4件、/wp-json/batch/v1 が5件ありました。/.git/HEAD は、公開されてしまったGitリポジトリを探すスキャンでよく使われるパスです。/wp-json/batch/v1 は、WordPressのREST APIを探すものと考えられます。
そのほか、/index.php、/_next、/@fs/wp-config.php も1〜2件ずつありました。使用しているフレームワークの種類を探るものや、既知の脆弱性の探索である可能性がありますが、ログの詳細がないため、目的は特定できません。
ログイン画面や管理画面、APIの探索
/login が29件、/dashboard が27件、/api が18件、/api/auth が14件、/admin が8件でした。認証や管理に関わるパスを探すアクセスで、ブルートフォース攻撃などの前段階の探索の可能性があります。ただし、実際にログイン試行が行われたかどうかは、今回の画面からは判断できません。
規則性のないパスと、コンテンツへのアクセス
/aaabbbccc、/1、/fb、/fwc、/fzh のような、規則性のないパスへのアクセスもありました。存在しないパスへの応答を確認するものかもしれませんが、目的は特定できません。
また、技術記事のURL、タグ一覧、カテゴリ一覧、画像、JavaScriptファイル、favicon、robots.txt なども、ブロックされたリクエストの中に含まれていました。これらは、コンテンツを網羅的に収集するボットによるアクセスの可能性があります。ただし、ブロックの理由は画面から分からないため、攻撃と断定はできません。
アクセス元の国と地域
国別では、中国が約237件で最も多く、続いてシンガポールが59件、オランダが55件、台湾が39件、フランスが35件でした。そのあとに、アメリカ24件、ブラジル23件、香港18件、ドイツとロシアが各14件、ポーランド10件が続きます。カナダが6件、韓国が4件、リトアニアが2件、スウェーデンが1件、Torが1件でした。
この数字は、Cloudflareが判定したアクセス元の国や地域であり、攻撃者の所在地を示すとは限りません。VPSやクラウド、プロキシなどを経由した通信では、アクセス元の国と実際の操作者の所在地が一致しない場合があるためです。
どのようなサイトが狙われるのか
今回のログの範囲では、静的サイトであっても、WordPressの設定ファイルやログイン画面、管理画面、APIを探すアクセスが届いていました。アクセスされたパスは、今回のサイトの構成とは関係なく、一般的によく使われるファイル名や画面名が中心でした。こうした点から、特定のサイトを狙ったものではなく、不特定多数のサイトに向けた自動的なスキャンが含まれていると考えられます。
そのため、サイトの規模や使っている技術にかかわらず、公開されているサイトであれば、同様のアクセスが届く可能性があると言えます。
無料プランでできる対策
Cloudflareの公式ドキュメントで確認できた、無料プランで使える機能を紹介します。
まず、Free Managed Rulesetです。広く悪用されている脆弱性に対する保護を提供するもので、公式ドキュメントによると、すべてのプランで利用でき、無料プランではデフォルトでデプロイされています。
次に、Bot Fight Modeです。無料プランで利用でき、既知のボットのパターンに一致するトラフィックをチャレンジします。オンとオフを切り替えるだけの機能で、動作を細かく調整することや、カスタムルールでスキップすることはできません。
カスタムルールを使うと、リクエストの条件に応じて、Block、Managed Challenge、Skip、Logといったアクションを設定できます。たとえば、サイトに存在しないはずのパスへのアクセスをブロックする、といった使い方が考えられます。導入するときは、いきなりBlockにするのではなく、まずLogで該当するリクエストを確認してから切り替えると、必要なアクセスを止めてしまうリスクを減らせます。無料プランで作成できるルール数の上限は、公式ドキュメントで確認してください。
ログイン画面やAPIを持つサイトでは、Rate Limitingも選択肢になります。公式ドキュメントによると、無料プランではカウントの基準がIPに固定され、期間は10秒、アクションはBlock、ブロック期間は10秒という設定になります。
WAFの設定とは別に、サーバー側の基本的な対策も重要です。バックアップファイルや一時ファイルを公開ディレクトリに置かないこと、.git ディレクトリや .env などの設定ファイルをデプロイ対象に含めないこと、使っているソフトウェアやライブラリを最新の状態に保つことです。今回のログに現れたファイル名は、そうした残りやすいファイルを狙ったものと考えられるため、そもそもファイルが存在しない状態にしておくことが、確実な備えになります。
最後に、ログの確認についてです。セキュリティ画面に表示されるのはブロックされたリクエストなので、ブロックされなかったリクエストについては、別途アクセスログなどで確認する必要があります。
まとめ
Cloudflare無料プランの静的サイトで、直近7日間に542件のリクエストがブロックされました。最も多かったのは wp-config.php とその派生ファイル名を探すアクセスで、パス別の合計は約146件でした。ほかにも、.git の探索、ログイン画面や管理画面、APIの探索などが確認できました。国別では中国が約237件と最も多かったものの、この数字は攻撃者の所在地を示すものではありませんが、攻撃を防ぐ目的であればこうした情報を使って攻撃の対策をすることができるでしょう。
無料プランでも、Free Managed Ruleset、Bot Fight Mode、カスタムルール、Rate Limitingといった基本的な機能を使うことができます。これに加えて、バックアップファイルや設定ファイルを公開ディレクトリに置かないといった基本的な運用を行うことが重要で、こうした対策を組み合わせることで最低限の攻撃対策ができるのではないかと考えています。
この記事がどなたかのお役に立てれば幸いです。