あなたの管理するWebサーバーに、見覚えのないPHPファイルが置かれていたとしたら——それがWebシェルかもしれません。Webシェルは攻撃者がサーバーに設置する遠隔操作ツールで、一度設置されると何度でも自由にサーバーを操作できる状態が続きます。
ログを見ても一見正常なHTTPリクエストしか残らず、アンチウイルスにも引っかからないことが多いため、発見が数ヶ月遅れる事例も珍しくありません。この記事では、Webシェルの設置経路・動作の仕組みから、ログによる検知手順、除去と再発防止策まで、現場で使えるレベルで解説します。

Webシェルとは?なぜ危険なのか
Webシェル(Web Shell)とは、攻撃者がWebサーバー上に設置する悪意あるスクリプトファイルです。PHP・ASP・JSPなどのサーバーサイドスクリプト言語で書かれ、Webサーバーのプロセス上で動作します。
攻撃者がブラウザや専用ツールからこのファイルにHTTPリクエストを送るだけで、サーバー上のOSコマンドを自由に実行できます。「シェル」という名前の通り、Linuxのターミナル操作をWeb経由でリモートから行うような感覚です。
通常のマルウェアとの違い
・永続性: サーバー上にファイルとして設置されるため、サーバーを再起動しても消えません
・ステルス性: 一見すると正規のPHPファイルのように見えるケースがあります。ファイル名をimage.phpやconfig_bak.phpなどと偽装します
・操作の自由度: ファイル閲覧・改ざん・データベースへのアクセス・データ窃取・他サーバーへの攻撃拠点化まで可能です
・検知困難性: 通信がHTTPリクエストとして行われるため、ファイアウォールをすり抜けやすく、アクセスログにも一見正常なリクエストとして記録されます
国内でも官公庁や医療機関のWebサーバーにWebシェルが設置され、データ窃取や改ざんの踏み台にされた事例が報告されています。CMSやWebアプリケーションを運用しているなら、他人事ではありません。
Webシェルが設置される主な経路
1. ファイルアップロード機能の悪用
最も多い侵入経路が、Webアプリケーションのファイルアップロード機能の不備です。画像や文書ファイルのアップロードを受け付ける際に、アップロードされたファイルの種類を正しく検証していないと、PHPスクリプトを偽装した悪意あるファイルをアップロードできてしまいます。
拡張子のチェックだけでは不十分で、MIMEタイプの確認やファイルの実体(マジックバイト)の検証が必要です。ファイルアップロード脆弱性とは?仕組み・被害事例・対策をわかりやすく解説も参考にしてください。
2. SQLインジェクション経由でのファイル書き込み
SQLインジェクションを使ってデータベースのファイル書き込み機能(MySQLのINTO OUTFILEなど)を悪用し、Webシェルをサーバーに書き込む手口があります。SQLインジェクションと組み合わせることで、ファイルアップロード機能がなくても設置できるケースがあります。
3. CMSの脆弱なプラグイン
WordPressのプラグインや、古いバージョンのCMSに存在する脆弱性を突かれると、認証なしでファイルを書き込まれるケースがあります。パッチが未適用の環境は特に狙われます。実際、公開されている脆弱性情報をもとに自動化ツールで大量スキャンされ、脆弱なサイトにWebシェルが設置される事案が継続的に報告されています。
4. 認証情報の漏洩によるFTP/SSH直接アップロード
FTP・SFTP・SSH認証情報が漏洩した場合、攻撃者が直接ファイルをアップロードすることもあります。フィッシングや不正アクセスで認証情報が窃取された後のケースです。
Webシェルの動作の仕組み
典型的なPHP製Webシェルは、外部から受け取ったパラメータをそのままOSコマンドとして実行するシンプルな構造を持ちます。
# Webシェルの最小構成(概念説明のみ・実環境での試行は不正アクセス禁止法に抵触します) # GETパラメータで受け取ったコマンドをOSに渡すだけの構造 # 攻撃者はブラウザから以下のようにアクセスするだけでコマンドが実行される # https://target.example.com/uploads/img.php?cmd=id # レスポンス: uid=33(www-data) gid=33(www-data) groups=33(www-data) # 攻撃者が確認する情報の例 # https://target.example.com/uploads/img.php?cmd=uname+-a # https://target.example.com/uploads/img.php?cmd=cat+/etc/passwd # https://target.example.com/uploads/img.php?cmd=ls+-la+/var/www/html/
実際に使われるWebシェルはさらに高機能で、ファイルマネージャ・コマンド実行画面・データベース操作UIが一体化した「c99」「r57」「China Chopper(チャイナチョッパー)」といったものが知られています。また、コードをBase64エンコードや文字列分割で難読化して検知を回避するケースも多くあります。
Webシェルの検知手順
1. ファイルシステムの変化を確認する
Webシェルはサーバー上にファイルとして存在します。最近変更・作成されたファイルを洗い出すことが第一歩です。
# 過去7日以内に変更・作成されたPHPファイルをWebルート配下で検索 find /var/www/html -name "*.php" -type f -newer /tmp/check_point -ls # 最終更新日でPHPファイルを一覧(不審なファイルを探す) find /var/www/html -name "*.php" -type f \ -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort -r | head -50 # アップロードディレクトリにPHPファイルがないか確認 find /var/www/html/wp-content/uploads -name "*.php" -o -name "*.phtml" # 世界書き込み可能な設定になっているファイルを確認 find /var/www/html -type f -perm -o+w
ファイルの整合性監視ツール(AIDE)を導入しておくと、変更されたファイルを自動で検知できます。Linuxファイル整合性監視(AIDE)入門|サーバー改ざんを即検知する実践設定ガイドで具体的な設定手順を解説しています。
また、Linuxサーバーの基本的なセキュリティ設定については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。
2. Webアクセスログを解析する
Webシェルへのアクセスはログに残ります。通常のページとは異なるアクセスパターンを探します。
# 画像・アップロードディレクトリへのPHPファイルへのアクセスを確認 grep "\.php" /var/log/nginx/access.log | grep -E "/uploads/|/images/" # POSTリクエストが多いファイルを確認(コマンド実行はPOSTが多い) awk '$6=="\"POST" {print $7}' /var/log/nginx/access.log \ | sort | uniq -c | sort -rn | head -20 # 不審なユーザーエージェントを含むアクセスを確認 grep -iE "(curl|python-requests|wget|nikto|sqlmap|hackbar)" \ /var/log/nginx/access.log # 同一IPから短時間に大量アクセスしているIPを確認 awk '{print $1}' /var/log/nginx/access.log \ | sort | uniq -c | sort -rn | head -20
3. Webシェル検知ツールを活用する
オープンソースの検知ツールを使うことで、難読化されたWebシェルも発見しやすくなります。
・ClamAV: 既知のWebシェルシグネチャに対応しています。定期スキャンをcronで自動化することを推奨します。ClamAV入門|Linuxサーバーのマルウェアスキャン設定と自動化実践ガイドを参考にしてください
・PHP-Malware-Finder: Yara(マルウェア検知ルール記述言語)を使い、難読化されたPHPコードのパターンをスキャンします
・Linux Malware Detect(LMD/maldet): PHPの難読化コードや既知のWebシェルシグネチャの検知に強みを持ちます
# ClamAVでWebルート全体をスキャン(ログを残す) clamscan -r --infected /var/www/html \ --log=/var/log/clamav/webshell_scan.log # maldet(Linux Malware Detect)のインストールと実行 # https://www.rfxn.com/projects/linux-malware-detect/ からダウンロード maldet --scan-all /var/www/html maldet --report # 最新レポートを表示
Webシェルを発見したときの除去と対応手順
1. まずサーバーを隔離する
Webシェルを発見したら、まず外部からのアクセスを制限します。被害の拡大(データ窃取の継続・他サーバーへの横展開)を防ぐためにも、ファイルを削除する前にネットワーク隔離を優先してください。iptablesやセキュリティグループで外部通信を一時的に遮断し、保守IPのみ許可する形が安全です。
2. 証拠を保全する
削除前に、発見したWebシェルファイルのコピーと関連するアクセスログを別のメディア(USBや別サーバー)に保存します。インシデント調査や法的対応のために証跡が必要になります。ファイルのハッシュ値(SHA256)も記録しておきましょう。
3. ファイルを削除・検疫する
Webシェルファイル本体を削除します。類似ファイルが他の場所にもないか全体をスキャンしてから、まとめて処理します。1つ発見した場合、他にも複数設置されているケースが多いです。
4. 侵入経路を特定して塞ぐ
ファイルを削除しただけでは、攻撃者はすぐに再設置できます。アクセスログを遡り、どの経路で設置されたかを必ず特定し、根本的な対処をします。
・ファイルアップロード処理の検証ロジックを修正する
・CMSおよびプラグインをすべて最新版にアップデートする
・漏洩した可能性のある認証情報(FTP・SSH・CMS管理者)をすべて変更する
・不要なFTPアクセスポートを無効にする
5. バックアップからの復元を検討する
長期間発見されていなかった場合、バックアップがすでに汚染されている可能性があります。感染前の確実な状態のバックアップを特定してから復元作業を進めましょう。
中小企業でも今日からできること
完璧な対策を一度に実施するのは難しいものです。優先度の高い対策から取り組みましょう。
| 対策 | 具体的な内容 | 難易度 |
|---|---|---|
| ファイルアップロード拡張子の制限 | 許可する拡張子(画像・PDF)をホワイトリストで厳格に制限する | 低(設定変更) |
| アップロードディレクトリでのPHP実行無効化 | /uploads/ など、PHPが実行されないようWebサーバー設定を変更する | 低(設定変更) |
| CMS・プラグインの最新化 | WordPressとプラグインを常に最新バージョンに保つ | 低(定期作業) |
| WAFの導入 | Webシェルのアップロード試行や不審なリクエストをフィルタリングする | 中(設定が必要) |
| 定期スキャンの自動化 | ClamAVなどのスキャンをcronで週次実行し、結果をメール通知する | 低(cronで自動化) |
| ファイル整合性監視の導入 | AIDEでWebルート配下のファイル変化を自動検知する | 中(設定が必要) |
WAFを使ったWebアプリケーション防御の詳細はWAFとは?Webアプリケーションファイアウォールの仕組み・選び方・導入手順をわかりやすく解説を参照してください。
Nginxでアップロードディレクトリのスクリプト実行を無効化する
WordPressを運用している場合、アップロードディレクトリでPHPが実行されないようNginxに設定を追加することで、Webシェルが設置されても実行を防ぐことができます。
# /etc/nginx/conf.d/no-php-in-uploads.conf に追記 # WordPressのアップロードディレクトリでのPHP実行を禁止する server { ... location ~* /wp-content/uploads/.*\.(php|php5|phtml|pl|py|sh)$ { deny all; return 403; } ... } # 設定を反映 nginx -t && systemctl reload nginx # Webサーバーの実行ユーザーを確認(不要な権限がないか) ps aux | grep -E "nginx|php-fpm" | grep -v grep
よくある誤解と注意点
【注意1】「SSLを使っているから安全」は誤り
HTTPS化はデータの暗号化であり、Webシェルへのアクセス自体を防ぐものではありません。攻撃者はHTTPS越しでもWebシェルを操作できます。SSLは通信の盗聴を防ぐ仕組みであり、サーバー上のファイル設置とは無関係です。
【注意2】「アンチウイルスが入っているから安全」は誤り
Webシェルは難読化されることが多く、シグネチャベースのアンチウイルスでは検知できない亜種が存在します。挙動検知(EDR)や専用の静的解析ツールとの組み合わせが重要です。
【注意3】「ファイルを削除すれば解決」とは限らない
侵入経路を塞がずにファイルだけ削除しても、攻撃者はすぐに再設置できます。除去と同時に根本的な脆弱性への対処が必須です。また、1つのWebシェルを除去しても他の場所にバックドアが残っているケースもあります。
【注意4】WordPressの「テーマエディター」は無効化を推奨
WordPressの管理画面には、テーマのPHPファイルを直接編集できる「テーマエディター」機能があります。管理者アカウントが乗っ取られると、この機能を使ってWebシェルを埋め込まれる可能性があります。不要であれば wp-config.php に以下を追加して無効化しましょう。
# wp-config.php に追記してファイル編集機能を無効化 define('DISALLOW_FILE_EDIT', true); define('DISALLOW_FILE_MODS', true); # プラグイン・テーマの追加・更新も禁止

本記事のまとめ
・Webシェルとは: 攻撃者がWebサーバーに設置する悪意あるスクリプトで、Web経由でサーバーを遠隔操作可能にする永続的なバックドアです
・主な設置経路: ファイルアップロード脆弱性・SQLインジェクション・CMSプラグインの欠陥・認証情報漏洩によるFTP/SSH直接アップロード
・検知方法: 最近変更されたファイルの確認・Webアクセスログの解析・ClamAVやmuldetなどのスキャンツール活用
・対応手順: 隔離→証拠保全→ファイル削除→侵入経路の特定と修正の順で進める
・予防策: アップロードディレクトリのPHP実行無効化・ファイル拡張子のホワイトリスト制限・CMS最新化・WAF導入・定期スキャンの自動化
Webシェルはいったん設置されると長期間潜伏します。「設置されにくい環境を作ること」と「設置されても早期に発見できる仕組みを持つこと」の両方が重要です。今日からできる対策を一つずつ積み上げていきましょう。
PR
体系的に学ぶ 安全なWebアプリケーションの作り方 第2版(徳丸浩/SBクリエイティブ)
ファイルアップロード脆弱性・SQLインジェクション・XSSなど、Webシェルの設置につながる攻撃手法とその根本的な対策を体系的に解説した定番書です。Webシステムを開発・運用するエンジニアに幅広く読まれています。
