Webサーバのセキュリティの要点は？～Webシェル侵害から考える公開サーバのハードニング～

Webサーバのセキュリティの要点は？～Webシェルを想定した公開サーバのハードニングを考える

2026年9月、国内で公表されるセキュリティインシデントが頻発しています。特に目立つのが「Webサーバなどの公開サーバ」への攻撃被害です。今回は、TrendAI™ の日本のインシデントレスポンスチームの担当者が、実際のインシデント対応から見えたWebサーバへの攻撃と現状に即した対策について解説します。

グラフ：国内で公表されたセキュリティインシデントのうち、アタックサーフェス別の割合（2025年9月～2026年9月）。グラフに数値が入っている項目が公開システム系（Webサーバ、Webアプリケーション、クラウドサーバ）（TrendAIによる調査。2026年10月6日現在）

攻撃が増加する時代、Webサーバの守り方を考え直す

Webサーバ起点のセキュリティインシデントが頻発

TrendAI™ の日本国内のインシデントレスポンスチームでは、昨今Webサーバなど公開サーバを起点とするサイバー攻撃に起因するインシデントケースを多く対応しています。対応したケースにおいては、公開しているアプリケーションに含まれるCVEが割り当てられた脆弱性や、アプリケーションの仕組みを悪用する弱点となるCWE（共通脆弱性）^※1を原因として、Webシェル^※2や不審ファイルが設置されてしまう事例を観測しています。結果、Webサーバから更に異なるサーバやシステムへと横展開され、結果的に情報窃取されてしまう流れが発生しています。
※1 CWE（Common Weakness Enumeration）：MITRE社が策定した、ソフトウェアにおけるセキュリティ上の弱点（脆弱性）の種類を識別するための共通の基準。脆弱性タイプを4つに大別し、脆弱性の識別、リスクの低減、再発防止策の情報源とすることを目指している。
※2 Webシェル：攻撃者がWebサーバを遠隔操作するために不正に設置する悪質なスクリプト（プログラム）。本稿後段で詳しく解説する。

EPPなどのエンドポイントセキュリティ製品をサーバに導入すれば、パターンファイルによってマルウェアを検知することは可能です。しかし、Webサーバの侵害の起点となるWebシェルや関連ファイルの多くは、ファイル固有のパターンのみで確実に検知できないケースが少なくありません。多種多様なサイバー攻撃が行われる現状においては、アタックサーフェスの筆頭に挙げられるWebサーバ自体の設定や構成を強固にすることが最重要です。この強固にする活動こそ「ハードニング」であり、攻撃からサーバを守る大事な取り組みです。

Webサーバセキュリティで考慮するべき3つのこと

Webサーバで公開しているサービス、アプリケーションでは、侵害されないための「脆弱性を管理し対処する」こと、Webサーバが侵害された際に「攻撃者の悪用を限定的に抑える」こと、そして、「異常を迅速に検知し、安全に切り離して復旧できる」ことが重要です。

本記事では、攻撃の流れ、公開サーバの脆弱性管理の視点、サーバのハードニングによる防御と、インシデントに備えたログ管理について説明していきます。

昨今の国内被害事例における攻撃の流れ

攻撃者は「Webシェル」をどう悪用するのか？

被害組織において多く悪用されている事例として「Webシェルが設置され、内部のサーバが探索、情報窃取される」ことが多く発生しています。WebシェルはWeb経由で受け取った指示に応じて、サーバ側で処理を行う悪意あるプログラムです。例えば、攻撃者がWebブラウザから指示を送ると、サーバ上でBash^※等のコマンド処理が動き、ファイル一覧を閲覧、異なるサーバへのアクセスも可能となってしまう場合があります。ブラウザは操作の窓口であり、実際にコマンドの処理が行われるのはWebサーバなどの被害端末上で動作しています。
※Bash（Bourne Again shell）：Unix系OSで使用される「シェル（命令受渡しプログラム）」の一つ。

サイバー攻撃者によって、Webシェルが設置されるケースでは、アップロード機能の不備やアプリケーション、ライブラリの脆弱性、管理機能やログイン機能の悪用などを端緒にしているケースが多いです。これらの悪用時に、外部からファイルを書き込める場所でPHPファイルやJSPファイル^※が実行できてしまうと、Webシェルの設置に繋がってしまう恐れがあります。
※JSP（Java Server Pages）ファイル：Webサーバ上で動くJavaのプログラムの形式の1つ。

このWebシェルが攻撃者により操作され、コマンドが送り込まれることで、Webシェルが設置されたサーバとつながっているデータベースが閲覧され、情報窃取に至るケースがインシデントレスポンスの支援において多く観測されています。Webシェルが実行されると、Webサーバ上のコマンドは通常のOS権限相当で動作してしまう場合があり、これにより情報の探索やデータベースへの接続が行えてしまう事例が発生しています。

被害に遭う確率を下げるための脆弱性管理

「Webサーバのセキュリティ」を阻む脆弱性の壁

インシデントレスポンスチームが支援するケースの多くで、「事情がありセキュリティ対策がWebサーバに未導入であった」、「古い脆弱性の対処が行えないままであった」、「一時的にメンテナンス用に開放した設定を戻しておらず、悪用された」と管理が行き届いていないサーバから侵入されている事例が多く確認されています。
攻撃を検知するためのセンサーがサーバに設置されておらず、悪用されるリスクのある脆弱性が長期間残っている状態は、攻撃者にとって格好の的となり得てしまいます。センサーや監視が行えていない状況では、侵害が始まったことや、攻撃の兆候、活動を捉えることができず、結果的に攻撃者からの他システムへの侵害を許してしまう形となってしまいます。

単に「脆弱性が出たらパッチを当てよう」、「CVSSのSeverityがHigh以上は当てよう」では済まない時代になっています。ソフトウェアサプライチェーンと同様に、構築運用しているWebサーバなどの公開サーバがどのようなライブラリ、パッケージ、構成ファイルを持つのかを把握しておくことが重要です。何がサーバで動作しているのか分からない状態ではなく、何のソフトウェアがどのバージョンで動作しているのかを管理し、情報が得られ次第パッチの適用を早期に検討することが重要です。しかし、昨今のCVE発行と脆弱性発見報告の増加、サイバー攻撃の増加傾向から、これらの悪用がエンジニアの判断より先に行われてしまうリスクも考えられます。

「仮想パッチ」という対抗手段

このような脆弱性に対処するための仮想パッチ（Virtual Patch）は一つの有効手段です。仮想パッチはサーバを運用するエンジニアが脆弱性情報を入手し、パッチの適用を検討している間に攻撃を受けてしまうリスクを軽減することができる機能です。特定の脆弱性に対する攻撃通信を防御するルールを自動的適用することで、パッチ適用までのリスクを一時的に下げることが期待できます。この仮想パッチを適用している数日間に早期にパッチの適用を行うことも一つの運用案となるでしょう。

また、脆弱性はCVEが割り当てられたものだけではありません。CWEと呼ばれる共通脆弱性が存在します。Webサーバにおいて、テキストや数値を入力でき、サーバに対して処理を渡す機能を持っている場合は、入力される文字列を制御、確認し、不適切であれば受け付けないようにするなどの対処が必要です。このようなCWEも含めた理解とともに、サーバが脆弱ではない状態を維持しなければなりません。

資産管理と監視による検知対応

Webサーバのセキュリティ状況を可視化・管理する

脆弱性を含め、管理されたサーバであることも重要です。知らないプログラムが動作していた、誰がログインしていたのか分からない、設定が書き換えられていた、セキュリティ対策を導入していると思い込んでいたーー。攻撃者が狙いそうな理由、セキュリティの穴が無いことを「管理された状態で維持運用できていること」が把握できる監視、そしてシステム、体制であることも重要です。

セキュリティ対策や製品は導入して終わりではありません。環境や組織に合わせて運用ができる体制を整え、環境固有のアラートを減らし、検知状況を確認し、対応が必要なときに調査できることが重要です。例えば、次のような環境の変化による検知は監視の一つになり得ます。

・想定していないサービスやプロセスが起動した
・新しいユーザが追加、cron^※1やsystemd^※2サービスが追加された
・Web公開の領域や設定ファイルが変更された
・Webサーバを送信元として、普段通信しない宛先に通信が発生した
・EPPやEDR、ログ転送などの機能が停止した
※1 cron：Unix系OSにおいて、指定した日時や定期的なスケジュールでプログラムやコマンドを自動実行する機能。
※2 systemd（システムディー）：Linuxの起動処理やシステム全体の管理を行う標準的な初期化システムおよびサービスマネージャーのこと。

もちろん、Webサーバではこれらの行動はアップデートやアプリケーションの更新、バージョンアップなどにより発生する場合もあります。しかし、これらはサイバー攻撃者がWebサーバに攻撃を行った時もサーバに残りやすい痕跡でもあります。有効なWebサーバの資産管理を考える際、「何台のサーバがどのOSで動いているのか」だけではなく、構成や脆弱性の管理、そしてログ、設定ファイルの変更管理、セキュリティ製品の稼働確認まで守るべき時代が来ている、と言えます。

このような考え方はインシデント発生時にも早期に気づきを与えてくれる重要な要素です。「このファイルはいつからあったのか」、「通信として出ている宛先はサービスで利用しているか」、「ログインされているユーザは通常運用の範疇か」と一から調べるのではなく、平時から正常な状態を把握しておくことで、異常な状態を見つけ、調査や封じ込めの判断も容易となります。

Webサーバへ設置される不審ファイルから身を守る

公開サーバに有効なハードニングを行うには？

Webサーバなどの公開サーバにおいては、多くの環境でLinux/Unix系OSが使われています。これらのサーバを守るためのハードニングの観点についていくつか記述します。読者の皆さんの組織において対策が行えているかの見直しのための1つの観点としていただければ幸いです。

1.Webサーバを実行するプロセスにアプリケーションを書き換える権限を持たせない
プログラムを自分自身で書き換え、新規作成する必要は基本としてありません。エンジニアの手で検証したうえで差し替える運用であれば、Webサーバのプロセス自身で、Webサーバのコードやプログラムを追加させる行動はすべて怪しいと判断し、止めることができます。プロセスが業務上プログラムされた内容に沿って読み書きするフォルダと、プロセス自身が動作するために必要なフォルダの読み書き権限を制限することで、Webシェルの設置と実行を防ぐことができます。

2.Webサーバ領域の読み書き権限を制御する
Webサーバにアップロードされるファイルを、可能ならば別のホストやWebサーバが扱わない領域へ分離します。アップロードされた内容を直接PHPやJSPなどのプログラムとして処理されないようにすることで、Webシェルとして読み込まれるリスクを減らすことができます。PHPではHTTPから実行できるファイルを必要な入口にのみ絞り、PHP-FPM側で処理対象の拡張子を制限する。Apache Tomcatでは不要な自動デプロイを停止する等が考えられます。

3.脆弱性の修正と実装の見直しを行う
Webサーバで動作しているアプリケーションで、サービス提供において不要な機能が有効になっているか、使われているかを確認します。必要のないライブラリが読み込まれ、それらが脆弱性を持っていた場合、悪用されるリスクが存在してしまいます。

対象はOSから始まり、PHP、Java、フレームワーク、プラグイン…果てにはそれらが依存するライブラリまで広く把握しなければなりません。一つの脆弱性が必ずしも、攻撃が最後まで辿り着けてしまう要因になり得るものではありませんが、いくつもの要素が重なりあい、複雑ながらも攻撃に繋がってしまうリスクがあります。

アプリケーション側では、入力する長さや型、範囲を検証するとともに、安全に処理が渡される実装が必要です。SQLは命令と分離して渡す、表示する文字列はコードとして解釈されない形に変換、利用者への操作については許可する範囲を確認する。このような修正が難しい場合、問題の含まれる機能や処理を制限するか停止することも判断として重要です。また、WAF（Web Application Firewall）や仮想パッチも緩和策の一種です。ただしこれらは緩和であり、根本的対処ではないことに留意しなければなりません。

Webサーバから繋がるデータベースを守る

Webサーバの背後にある「重要資産」を守るには？

サーバが侵害された後には、攻撃者は本来の狙いである重要な資産、業務データや個人情報が保管されたデータベースを狙います。彼らはこのようなデータを販売、あるいは脅迫に用いるために窃取を試みます。この重要資産を守るために、重要な点を4点紹介します。

1.アプリケーションが用いるDBアカウントを最小権限にする
Webサーバからデータベースにアプリケーションが接続する際、用いるアカウントの必要なテーブルやView、操作は必要最低限とします。閲覧できる範囲やデータベースの操作を限定的にすることで、万が一Webサーバが侵害された際にも、窃取される恐れのあるデータを限定的とすることで予想外の被害を抑える、あるいは気づくことが期待できます。

2.通常用いられるSQLクエリを把握する
固定的、あるいは業務的に分かり切っているデータを取り扱うものであれば、実行されるSQL^※クエリのパターンはある程度定型的なものとなります。SQLクエリを制限あるいは監視できる製品の場合は、通常用いられないSQLを検知、拒否することも一つの対策となるでしょう。普段使われない参照（SELECT）が検知できれば、悪意ある攻撃にも早期に気づくことができます。
※SQL（Structured Query Language）：リレーショナルデータベース（RDB）を操作・管理するための国際標準のデータベース言語。MySQLやOracle DatabaseはSQLが使用されているデータベース言語の1つ。

3.SELECTを含むクエリにおいてDB監査を有効にする
データベースへのログイン成功と失敗を記録するのみでは、このようなデータ侵害における重要な材料が抜け漏れてしまいます。テーブルの参照、DDL、権限変更、エクスポートを含め、SELECTクエリ^※によるデータ参照が記録されることで、万一の際の被害範囲を明確にすることができます。デフォルトでは無効になっていることも多く、意識して有効にすべき設定の一つです。ログの出力量を調整しながら、監視と記録ができる運用に乗せていくことが大事です。これらはインシデント発生時にも被害範囲を明確にする観点から、一つの重要な情報となり得ます。
※SELECTクエリ：データベースに対する検索のためのクエリ。

4.外部への通信量と持ち出し経路を把握する
データベースへアクセスされ、悪意ある閲覧やデータの窃取が行われた際にどのようにデータが持ち出されるのかを把握しておく必要があります。Webシェルから直接操作がされる、あるいは実行ファイルが設置されデータを持ち出す、外部へとリモート接続を行い、データを持ち出す。このような経路を把握し、通常の通信と攻撃された際の通信を記録、監視できているかどうかで、未然に防ぐ、早期に気づき対処することが期待できます。

AIの暗躍、それでも変わらない守るべきこと

AIの悪用と観測したサイバー攻撃の関連性

ここまで記述してきたWebシェル悪用の事例、考え方と対策は一部分にすぎません。しかし当社が支援を行ったインシデントレスポンス事例の中で、このような攻撃にはいくつかの特徴と疑念点が浮かび上がっています。それはこれらの攻撃の裏でAIが動作しているのではないか？という一つの懸念です。

挙げられる特徴や、ログの動きは次のようなものがあります。
・設置されるWebシェルや不審ファイルにコメントアウト^※があり、攻撃対象の組織やサービスの名称が書かれている
・悪用された脆弱性が、直近で公開された「In the Wild（悪用が観測されている）」として認知が広い脆弱性（Exploit）ではない（人間が持つベストプラクティス以外の情報を悪用している）
・攻撃の試行錯誤のレスポンスとそれらを見直すスピードが旧来よりも迅速である（失敗と改善のスピードが速い）
・狙いが定まった後は網羅的に攻撃するのではなく、得られたレスポンスから限定的に攻撃を仕掛け、成功と失敗を見極める（最短経路を探していると推測）
※コメントアウト：プログラムのソースコードの一部を一時的に無効化し、コンピュータに実行させないようにする処理機能のこと。

これまでインシデント対応行ってきた筆者としては、2025年以前の公開サーバ関連のインシデント対応ケースと比べ、人力（攻撃者）で行なわれている攻撃と、機械（AI）が行なっているであろう攻撃の違い、そしてサイバー攻撃のさらなる巧妙化を肌で感じています。現状、必ずしもこれらの攻撃がAIを直接的に用いたものであるという証拠があるわけではありませんが、ログだけ見ても「これまでとは違う挙動」を捉えていることは事実です。

「AIの悪用を懸念する」前に抑えておくべきこと

攻撃者の裏にAIの存在があろうが無かろうが、Webサーバをはじめとした公開系の情報資産は、常に攻撃を受けるリスクがあること、攻撃を受けた際に組織が正しく対処ができるかどうかについては「AIが攻撃をしている」ことに限らず、備えなければならない重要な観点です。AIによる攻撃が増加したとしても、行うべき基本事項は今までと大きく変わりません。

守るべき資産を考え、リソースを投入し、適切な対策を施し、対策が行えているかを定期的に見直し、監視することは今までと変わりません。今まで対策を行えていたのであれば今一度見直しを、対策を行えず弱点が放置されている懸念があれば、一度「緩んだ紐を締めなおす機会」が来ていると考えてください。

サイバー攻撃が多発するこの世の中で、システムが安定的に動作し、日々のパッチの適用と設定の管理を、一つの運用として既に行えている組織があるのであれば、非常に素晴らしい取り組みができている組織と言えるでしょう。システムを利用する顧客、組織・従業員だけでなく、システムに関わるエンジニアが安心して運用するため、サーバの稼働状況を把握し、正しい運用が行えているか再度見直してみてはどうでしょうか。

（関連記事）
・「polyfill.io問題」再燃に学ぶサプライチェーンセキュリティ
・Webスキミングとはどのような攻撃なのか？～決済情報の非保持化でも被害に遭う脅威～
・経済産業省「ASM（Attack Surface Management）導入ガイダンス」を解説～ASMという組織のセキュリティ強化方法のススメ
・EmEditorの利用者を狙った水飲み場攻撃～ソフトウェアサプライチェーンリスクの影響を考察する
・日本のホテル産業を狙ったフィッシングキャンペーンを観測～ブロックチェーンプラットフォーム「TON」を悪用する手口を解説