HN 日本語サマリー

← 一覧へ戻る
インフラ・DevOps

PHPはColdFusionサーバーで動作していますか？確認方法と削除方法

Is PHP Running on Your ColdFusion Server? How to Check, and Remove It (gregoryalexander.com)

19 pointsby rmason12 コメント

要約

Windowsサーバー上のIISでColdFusionまたはLuceeを実行しており、PHPを意図的にインストールしたことがない場合、PHPがサーバーに存在する可能性が高いです。この記事では、PowerShellを使用して数分でPHPの存在を確認し、安全に削除する方法を解説します。PHPの緊急パッチ公開に伴うセキュリティ対策の必要性についても触れています。

全文翻訳

PHPはColdFusionサーバーで動作していますか？確認方法と削除方法

［画像］

Windowsサーバー上のIISでColdFusionまたはLuceeを実行しており、PHPを意図的にインストールしたことがない場合、この情報が役立ちます。あなたのサーバーにはPHPが存在する可能性が高いです。コントロールパネル、数年前のphpMyAdminのインストール、あるいはホストのセットアップイメージによって残された可能性があります。ここでは、PowerShellを使って数分で確認し、何も使用されていない場合は安全に削除する方法を説明します。

セキュリティ修正を数年間適用せずに済ませられた時代を覚えています。今では、毎週のように何かを追いかけているような気分です。パッチ適用、緩和策、存在しないはずのページを攻撃するボット。AI時代はこんなものです、ため息。

先日、テストブログにサインインしようとしたところ、管理ページがプレーンなIISエラー「403 Forbidden」で拒否され、PHPによる緩和策でmultipart form-dataリクエストがブロックされたというメッセージが表示されました。私のブログはColdFusionで書かれており、PHPコードは一切実行していません。それなのに、なぜPHPのセキュリティルールがサインインを妨げたのでしょうか？

目次

何が起こったのか

タイミングは偶然ではありませんでした。2026年10月21日、PHPは、認証されていないリクエストがサーバー上でコードを実行できる2つの重大な脆弱性（PHP2Shellとニックネームが付けられた）に対する緊急パッチをリリースしました。Webリクエストを処理するすべてのPHPセットアップが影響を受けました：PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeed。修正するには、PHPの新しいバージョン（8.5.12、8.4.27、8.3.36、または8.2.35）をインストールする必要があります。

私のホスティング会社は、その週にWebサーバーのセキュリティルールで対応しました。このルールはIISのサーバー全体にわたるURL Rewriteルールにあり、すべてのサイトに適用され、content typeがmultipart/form-dataのリクエストを、アドレスに関係なくブロックしました。これは、ファイルをアップロードできるフォームがブラウザで使用するエンコーディングであり、多くのフォームがアップロードしない場合でもこれを使用します。

PHP自身の推奨事項には、これらのリクエストをブロックすることは含まれていません。それはパッチ適用であり、それまでは session.upload_progress.enabled をオフにし、post_max_size を下げることです。公式の緩和策のいくつかはPHPがアップロードをどのように処理するかに関するものなので、ホストが最も強力な手段に訴えたのも理解できます。PHPサイトにとっては、それは荒削りですが理解できる防御策です。私のColdFusionサイトにとっては、管理サインインフォーム、すべての画像アップロード、およびすべてのファイルアップロードが4つのサイトすべてで同時に失敗することを意味しました。このルールは、.php アドレスだけでなく、すべてのアドレスに一致しました。

ルールを .php アドレスに限定した後（詳細は後述）、すべてが再び機能するようになりました。そこで、私は当然の疑問を抱きました：なぜこのサーバーにPHPが存在するのか？答えは、私が数年前に1つのMySQLデータベースを管理するために依頼したphpMyAdminのインストールでした。それはまだそこにあり、サイトフォルダ内にあり、そのログインページはインターネット全体に公開されていました。PHPがもはや使用されていないことを伝えると、ホストは包括的なルールを解除し、私はPHPが他に何か残していないか探しました。

チェック1：IISは.phpファイルをPHPに送信していますか？

IISは、ハンドラーマッピングが指示した場合にのみPHPを実行します。サーバー上のPowerShellを管理者として開きます：

Import-Module WebAdministration
Get-WebHandler -PSPath 'IIS:\Sites' | Where-Object { $_.path -like '*.php' } | Select-Object name, path, scriptProcessor

何も表示されない場合、IISはPHPを実行していません。もし以下のようなものが表示された場合、それはPHPを実行しています。これは、サーバーの設定を継承するすべてのサイトに対して行われます：

name    path  scriptProcessor
----    ----  ---------------
FastCGI *.php C:\php\php-cgi.exe

ハンドラーの name と scriptProcessor のパスをメモしてください。削除する際に両方が必要になります。

チェック2：サイトにPHPファイルはありますか？

PowerShellの Get-ChildItem -Recurse は機能しますが、長年アップロードされた画像があるサーバーでは、数分かけてクロールする可能性があります。Windows自身の dir コマンドははるかに高速です。これは、Webルート下のPHPファイルの数をカウントします：

cmd /c "dir C:\inetpub\wwwroot\*.php /s /b" 2>$null | Measure-Object | Select-Object Count

カウントがゼロでない場合、これはそれらがどのフォルダにあるかを示します。最も多いものから順に表示されます：

cmd /c "dir C:\inetpub\wwwroot\*.php /s /b" 2>$null | ForEach-Object { Split-Path $_ -Parent } | Group-Object | Sort-Object Count -Descending | Select-Object -First 25 Count, Name | Format-Table -AutoSize

私の環境では、2つのフォルダで約4,500ファイルが見つかりました。どちらもphpMyAdminのものでした。1つはサイト内にあり、もう1つはWebルートにコピーされており、IISのデフォルトWebサイトがサーバーのベアIPアドレスにアクセスしたときに提供されていました。

認識できないPHPファイルが見つかった場合、特に画像やアップロードフォルダに散在していたり、最近変更されたりした場合は、侵入の可能性として扱い、注意してください。攻撃者はアップロードフォルダに小さなPHP「Webシェル」をドロップすることを好みます。これは最も最近変更されたものを一覧表示します：

cmd /c "dir C:\inetpub\wwwroot\*.php /s /b" 2>$null | Get-Item | Sort-Object LastWriteTime -Descending | Select-Object -First 15 LastWriteTime, Length, FullName | Format-Table -AutoSize

チェック3：PHPはインストールされていますか、または実行されていますか？

Get-Process php* -ErrorAction SilentlyContinue | Select-Object Name, Id, StartTime
Test-Path C:\php

php-cgi.exe プロセスがないということは、最近PHPページを要求したものがなかったということです。IISはオンデマンドでそれを起動します。チェック1のハンドラーが重要です。

チェック4：インターネットから何が見えますか？

任意のコンピューターから、ご自身のサイトの通常のURLにアクセスしてみてください：

foreach ($path in "phpmyadmin/", "phpMyAdmin/", "pma/", "info.php") {
    $url = "https://www.mysite.com/$path"
    try { $r = Invoke-WebRequest $url -UseBasicParsing -TimeoutSec 15; "$($r.StatusCode) $url" }
    catch { "$($_.Exception.Response.StatusCode.value__) $url" }
}

200で応答するものはすべて確認する価値があります。インターネットに公開されたphpMyAdminのログインページは、招待状のようなものです。ボットは一日中パスワードを試行し、すべての試行でPHPが起動し、データベースに接続します。

安全な削除方法

これらの手順を順番に実行し、事前にバックアップを取ってください。すべてのステップは元に戻すことができます。

1. IISの設定をバックアップする

IISは設定のスナップショットを作成し、1つのコマンドで復元できます：

& "$env:windir\System32\inetsrv\appcmd.exe" add backup "before-php-removal"

以下のすべてを元に戻すには：appcmd.exe restore backup "before-php-removal"。

2. phpMyAdmin（およびその他のPHPアプリケーション）をWebフォルダから移動する

削除ではなく移動してください。設定ファイルにはデータベースのパスワードが含まれている可能性があるため、数週間はプライベートな場所に保管しておき、何か必要になった場合に備えてください：

New-Item -ItemType Directory -Force C:\Temp\removed-php | Out-Null
Move-Item C:\inetpub\wwwroot\mysite\phpmyadmin C:\Temp\removed-php\phpmyadmin-mysite

Move-Item がファイルが使用中であるとエラーを出す場合、PHPがそれを開いています。iisreset /stop、移動、その後 iisreset /start を実行してください。（サイトは数秒間停止します。）また、「パスの一部が見つかりませんでした」というメッセージが表示された場合は、ソースではなく宛先フォルダが存在しないことを意味します。これは私を騙しました。

後でMySQLを管理するには、リモートデスクトップ経由でサーバー上のデスクトップツール（HeidiSQLやMySQL Workbenchなど）を使用すれば、phpMyAdminが提供していたすべての機能を、公開されたログインページなしで実行できます。

3. .phpファイルを入り口でブロックする

IISのリクエストフィルタリングは、ハンドラーが処理する前にファイル拡張子を拒否できます。サーバーレベルで追加すると、すべてのサイトがカバーされます：

Add-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/security/requestFiltering/fileExtensions' -Name '.' -Value @{ fileExtension = '.php'; allowed = 'false' }

これで、ファイルが存在するかどうかにかかわらず、すべての .php アドレスは「404 - リクエストフィルタリングモジュールはファイル拡張子の拒否が設定されています」というエラーになります。

4. ハンドラーとFastCGIエントリを削除する

チェック1で見つけたハンドラー名（私の場合は FastCGI）と php-cgi.exe のパスを使用します：

Remove-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/handlers' -Name '.' -AtElement @{ name = 'FastCGI' }
Remove-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter 'system.webServer/fastCgi' -Name '.' -AtElement @{ fullPath = 'C:\php\php-cgi.exe' }

再度チェック1を実行してください。何も表示されなくなるはずです。

5. 最後にPHPをアンインストールする

PHPがインストーラーからインストールされた場合は、[アプリ] > [インストール済みアプリ] から削除してください。単なるフォルダ（例: C:\php）の場合は、削除する前に数週間 C:\php-removed に名前を変更してください。何か問題が発生した場合、すぐに気づくことができ、名前を変更するだけで元に戻せます。

PHPがホストによってインストールされた場合は、ステップ5の前にホストに問い合わせてください。ホスト自身の監視スクリプトはおそらくPHPを必要としないでしょうが、それは彼らのインストールです。

このようなルールを維持する必要がある場合

もしかしたら、どこかでPHPを実行しているかもしれませんし、ホストがそのルールを維持したいかもしれません。その場合は、すべてのアドレスではなく、PHPアドレスにスコープを絞ってください。ルールの <match url="*.php" /> が問題のすべてでした。これを .php アドレスのみに変更すると、ColdFusionのフォームはそのままになります（ルールの名前を使用してください）：

Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter "system.webServer/rewrite/globalRules/rule[@name='PHP Mitigation']/match" -Name url -Value '\.php($|/)'

パターン内の単一引用符に注意してください。最初に appcmd.exe で同じ変更を試みましたが、PowerShellは引用符を静かに壊しました。エラーはなく、変更もありませんでした。単一引用符を使用した Set-WebConfigurationProperty は、最初の試行で成功しました。C:\Windows\System32\inetsrv\config\applicationHost.config ファイルで結果を確認してください。

LinuxとApache上のLucee

同じ質問ですが、コマンドが異なります：

php -v                          ## PHPコマンドラインがインストールされているか？
apachectl -M | grep -i php      ## ApacheがPHPを実行しているか（php_module, proxy_fcgi to php-fpm）？
find /var/www /home -name "*.php" 2>/dev/null | head -50

DebianおよびUbuntuでは、sudo a2dismod php8.3（バージョンによる）と sudo systemctl restart apache2 でApacheがPHPを実行しないようにします。その後、何も必要ないことを確認したら、パッケージマネージャーでパッケージを削除します。Virtualminなどのコントロールパネルは、それ自身のツールのためにPHPをインストールすることがよくあるため、アンインストールする前に確認してください。

注意点

  • サーバー全体に適用されるルールは、すべてのサイトに影響します。 PHP用に作成されたルールが、私のColdFusionのサインインとアップロードをブロックしました。予期せず403エラーが発生した場合、IISのエラーページ全体を読んでください。私の場合はルール名が記載されていました。
  • ホストはスクリプトを再実行します。 私のホストは実行ごとにルールを再作成したため、ローカルでの修正がサイレントに元に戻される可能性がありました。ホストに変更した内容とその理由を伝えてください。
  • 設定の編集が間違った web.config に保存されることがあります。 私の最初の修正はサイトの web.config に入ってしまい、何も変わりませんでした。IISが実際に読み取るファイルを Select-String で素早く確認すれば、10分は節約できたでしょう。
  • Trusted Cache が修正を隠します。 問題を診断中に .cfm ファイルを手動で置き換えた場合、ColdFusionはコンパイル済みの古いコピーを実行し続けます。新しいファイル名を使用するのが簡単な回避策です。
  • PHPの削除はパッチの代わりにはなりません。 PHPを実行している場合は、今すぐ8.5.12、8.4.27、8.3.36、または8.2.35（またはそれ以降）にアップデートし、可能な限り php.ini で session.upload_progress.enabled = 0 を設定してください。PHP 8.1以前はPHPプロジェクトからのアップデートは提供されなくなりました。PHPの削除が正しい選択肢となるのは、何もPHPを使用していない場合のみです。

さらに読む

この投稿は2026年10月23日午後11時39分に投稿され、3748回のビューがありました。

コメントは0件です。