uploadディレクトリ .m3u8スパム攻撃の目的と「410 Gone」による対処法

ホームページ（ウェブサイト）を運営し、定期的にGoogle Search Consoleを確認していると、見に覚えのないディレクトリ構造やURLのエラー報告に直面することがあります。

特に、ルート直下の/upload/ディレクトリ配下に、数字の羅列に拡張子「.m3u8」がついたファイルが大量に表示される現象は、昨今よく見られるスパム攻撃の痕跡です。

Search Console 404 存在しないm3u8ファイル（そもそも/ルート直下に/upload/というディレクトリは設置していない）

自社の大切な事業用ドメインの評価を守るためには、これらの悪意あるアクセスに対して適切かつ迅速なサーバー設定を行うことが重要です。ここでは、より専門的な視点から、このスパム攻撃のメカニズムと、404ではなく410ステータスコードを用いた効果的な排除方法を解説します。

Search Consoleに表示される数字の羅列と.m3u8の正体

まずは、なぜ存在しないはずのURLがSearch Console上に「ページにリダイレクトがあります」や「見つかりませんでした（404）」として大量に記録されるのか、その背景を紐解いていきます。

見に覚えのない/upload/ディレクトリ構造

WordPressをはじめとする一般的なCMSを標準的な構成で運用している場合、アップロードした画像などのメディアファイルが保存されるディレクトリは、概ね「/wp-content/uploads/」のような階層に位置しており、ルート直下に「/upload/」というディレクトリが存在することは通常ありません。

それにもかかわらず、Search Consoleのインデックスカバレッジレポートに「/upload/123456789.m3u8」のようなURLが突如として現れることがあります。

この「.m3u8」という拡張子は、動画配信用のプレイリスト形式のファイルです。

ホームページの管理者が意図して動画配信サーバーを構築していない限り、これらのファイルが自サイトに存在するはずがありません。

海外スパムネットワークによる偽装リンクの目的

この現象の多くは、海外の海賊版動画サイトやスパムネットワークが、他人の正常なドメインを偽装リンクとして悪用していることに起因します。

攻撃者は、どこか別の場所に設置した不正なリダイレクト元や動画の配信元として、ランダムに抽出したドメイン（ここではあなたのホームページ）のURLを勝手に生成し、外部の掲示板やスパムサイトのネットワークに大量に書き込みます。

検索エンジンのクローラーであるGooglebotなどは、ウェブ上のリンクを辿る性質があるため、それらの外部スパムリンクを発見すると対象ドメインの/upload/配下に何かファイルがあるかもしれないと認識し、あなたのサーバーに対してクロールを試みます。

結果として、実際には存在しないURLへのアクセス履歴が残り、Search Consoleに数字の羅列が記録されていきます。

Botnetによる攻撃のメカニズムと脅威

Botnet（ボットネット）とは、悪意のあるプログラムに感染して攻撃者に乗っ取られた、無数のコンピューターやサーバー、通信機器などで構成されるネットワークを指します。
先述したような海外のスパムネットワークは、手作業でホームページ（ウェブサイト）の偽装リンクをひとつひとつ生成しているわけではありません。

彼らはこのBotnetを利用して、世界中のさまざまなIPアドレスから分散的に、そして完全に自動化された状態でドメインの悪用や脆弱性のスキャンを行っています。

攻撃者はプログラムを用いてランダムな数字の羅列と.m3u8を組み合わせたURLを大量に生成し、Botnetを経由して一斉に外部の掲示板やスパムサイトへ書き込みます。

さらに、対象のサーバーに対して実際に侵入可能な隙がないか、ボットから直接アクセスして探りを入れてくることもあります。
このような自動化された大規模な攻撃に対しては、手動で個別のURLを精査して対処することは現実的ではありません。
だからこそ、サーバーの最も外側にある入り口、つまりApacheのレイヤー（.htaccess）において、システムとして一括で機械的かつ即座に遮断する仕組みを構築することが非常に重要になります。

クローラー制御において404ではなく「410 Gone」を推奨する理由

これらの不正なURLに対するアクセス要求があった際、サーバーがどのように応答するかがSEOの観点で非常に重要になります。

一般的な「404 Not Found」で返すよりも、「410 Gone」を用いることを強く推奨します。

検索エンジンに対する404と410の伝わり方の違い

通常、存在しないURLへのアクセスに対しては「404 Not Found（未検出）」というステータスコードが返されます。

404は、「現在は見つからないが将来的に再度作成されるかもしれない」というニュアンスを含んでいるため、検索エンジンは一定の期間をおいて、再度そのURLが存在しないか再クロールを試みる傾向があります。

一方、「410 Gone（消滅）」は、対象のURLは完全に削除され、今後も復活することはないという明確な意思表示です。

完全消滅の伝達によるクロールバジェットの保護

大量に生成されたスパムURLに対して404を返し続けると、クローラーは後でページができるかもしれないと判断し、無駄な再巡回を繰り返す可能性があります。

これは、本来ホームページ内の重要なページを巡回するために使われるべきクロールバジェット（検索エンジンの巡回枠）を激しく浪費することに繋がります。

ここで410を返すことにより、Googleに対して対象URLが存在しないことを強力かつ即座に学習させ、無駄なインデックス登録やクロールの試行を速やかに停止させることができます。
自社事業を支えるホームページの健全性を保つためには、この明確なステータスコードの伝達が効果を発揮します。

Apacheレイヤーでの即時遮断とサーバー内ファイルの確認手順

ここからは、実際にサーバーへ設定を行い、不正なリクエストを一網打尽に排除するための具体的な手順と、実被害の有無を確認する方法を解説します。

.htaccessによるWordPress起動前の処理

対象がWordPressで構築されたホームページであっても、PHPやデータベースを介したCMS側の404処理を実行させてはいけません。

CMSを起動させてしまうと、リクエストのたびにサーバーのリソースを消費してしまい、大量のアクセスがあった場合に表示速度の低下やサーバーダウンを招く恐れがあります。

そのため、ApacheなどのWebサーバーのレイヤーで即座に処理を完結させます。

サイトルートにある.htaccessファイルの最上部（# BEGIN WordPressよりも前の行）に、特定のディレクトリや拡張子へのアクセスを即時410で遮断するルールを追記します。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/upload/ [NC,OR]
RewriteCond %{REQUEST_URI} .m3u8$ [NC]
RewriteRule ^.*$ - [G,L]
</IfModule>

この設定により、外部からの不審なアクセス要求に対して、数ミリ秒という一瞬でサーバー標準の「410 Gone」を返すことが可能になります。

サーバー直下に不正な実フォルダがないかの確認

クローラーの遮断設定と併せて、攻撃者によって実際にファイルが置かれていないかの確認も重要になります。
FTPソフトやサーバーのファイルマネージャーを使用し、wp-config.phpなどが置かれているルートディレクトリ内を確認します。
もし、身に覚えのない「/upload/」というフォルダが実在し、中にファイルが存在する場合は、CMSの脆弱性などを突かれて不正に作成された痕跡の可能性があります。
その場合は中身を確認した上で、フォルダごと削除するなどの対応が必要です。
実体が存在せず、アクセスした際に先ほどの410ステータスが正常に返るのであれば、被害は外部からのリンクによるものだけと判断できます。

robots.txtによるクローラーの巡回遮断と適用タイミング

サーバー側での直接的なアクセス遮断に加えて、robots.txtを活用した巡回制御も合わせて検討します。ただし、設定を行うタイミングには注意が必要です。

Googlebotへの巡回拒否設定

robots.txtは、検索エンジンのクローラーに対してこのディレクトリにはアクセスしないでくださいと明示するためのファイルです。

ドメイン直下のrobots.txtに、/upload/ディレクトリや.m3u8拡張子への巡回拒否（Disallow）を追記することで、クローラーがサーバーへアクセスしてくる行為そのものをブロックします。

Googlebotが外部スパムリンクを踏んでサーバーへアクセスしてくる行為そのものを遮断し、クロールバジェット（巡回枠）を浪費させない設定です。

ドメイン直下の robots.txt に以下を追記します。

User-agent: *
Disallow: /upload/
Disallow: /*.m3u8$

注意点（410設定との連携）

すでにGoogleの検索結果やサーチコンソールに上がってきているURLは、.htaccess による410 Gone をGooglebotに踏ませてきれいになった後に設定してください。

410ステータス浸透後にrobots.txtを適用する理由

すでにSearch Consoleのレポートに多数のエラーURLが上がってきている状態では、すぐにはrobots.txtの記述を追加しない方が良い場合があります。

robots.txtでクロールを拒否してしまうと、GooglebotはそもそもそのURLにアクセスできなくなるため、私たちが設定した「410 Gone（完全に消滅した）」という正しいステータスを読み取ることができなくなります。

その結果、Search Console上のエラー表記が長期間残り続けてしまう可能性があります。

まずは.htaccessによる410処理をクローラーに踏ませて、URLの消滅をGoogleに認識させます。

410ステータスが浸透し、インデックスやレポートから対象の数字の羅列が消滅した段階で、将来的なアクセスを防ぐためにrobots.txtを適用するのが、より専門的には正しい順序と言えます。

410が浸透してサーチコンソールから消えた段階、あるいは最初からサーバーアクセスを一切遮断したい場合に robots.txt を適用してください。