Imunify360 マルウェアスキャナー：機能、アップデート、および制限事項

Imunify360：多層的なホスティングセキュリティ

Imunify360は、単なるウイルススキャンツールではなく、複数の保護層を備えたLinux向けセキュリティソリューションです。その マルウェアスキャナー ファイルに含まれる既知または不審なコンテンツを検査します。ファイアウォールおよびIDS/IPSは、不審なネットワーク活動を監視・制限する一方、Webアプリケーションファイアウォール（略称：WAF）は、ルールに基づいてアプリケーションに到達する前のHTTPリクエストを評価します。レピュテーションチェックは、送信元や活動の分類に役立つさらなる指標を提供します。.

この区分は、各レイヤーが異なる段階で機能するため、ホスティング事業者にとって極めて重要です。 既知の脆弱性を狙ったHTTP攻撃は、WordPress、Joomla、Magentoがリクエストを処理する前に、WAFによって阻止される可能性があります。一方、悪意のあるアップロードは、ファイル検証の段階で問題となります。PHPウェブシェルが実行された場合、 先制防御 PHPの実行中に見られた不審な動作に対処するものですが、インシデント全体を遡及的に分析するものではありません。.

このモデルの名前は 多層防御: 単一の脆弱性や見落とされた発見だけで、顧客アカウントのセキュリティが左右されるべきではありません。 マルウェア検出は、既存の悪意のあるコードを可視化することはできますが、必ずしも元のエクスプロイトを阻止するわけではありません。同様に、WAFは攻撃をブロックすることはできても、すでに保存されたファイルや改ざんされたデータベースの内容をクリーンアップすることはできません。.

これらのいずれのレベルも、基本的な運用業務に代わるものではありません。CMSのコア、プラグイン、テーマ、拡張機能には、タイムリーなセキュリティアップデートが必要です。また、厳格なファイル権限設定やアクセス情報の分離により、アカウントが侵害された場合の被害を最小限に抑えることができます。 検証済みのバックアップがあれば復旧が可能であり、侵害が発見された場合は、インシデント分析によって侵入経路、影響範囲、および潜在的な持続性を明らかにする必要があります。. Imunify360 これによって、保護および検知のシグナルは提供されるものの、環境が完全に浄化されたという完全な証拠にはならない。.

Imunify360、ImunifyAV、ImunifyAV+の違い

機能リストは、それぞれ使用される製品に割り当てる必要があります。. Imunify360 は、より包括的なサーバーセキュリティソリューションです。ImunifyAVおよびImunifyAV+は、これとは別の製品であり、マルウェア対策機能を備えています。 これらの名称を同一視してしまうと、既存のスキャン機能とファイアウォール、リアルタイム保護、あるいはPHP保護を混同し、マネージドサーバーやリセラーサーバーに対して誤った期待を抱く恐れがあります。.

特に重要な点は、メーカーのドキュメントによると、リアルタイムスキャンとプロアクティブディフェンスが、ImunifyAVおよびImunifyAV+ではImunify360と同様の形で利用できないという点である。 リアルタイムスキャンは、新規または変更されたファイルを迅速に検出できます。一方、プロアクティブ・ディフェンスは、PHPの実行を独自の介入ポイントとして扱います。これらの機能はいずれも、スケジュール可能なファイルスキャンを補完するものではありますが、ファイルスキャンを不要にするものでも、アプリケーションのメンテナンスに取って代わるものでもありません。.

「Imunify Security Plugin」と呼ばれるWordPress拡張機能も、サーバーエージェントの独立した代替品ではありません。これはImunifyエージェントによって管理されており、WordPress.orgのディレクトリからは提供されていません。 WordPressの管理画面では、スキャンや保護に関する情報を確認できますが、表示される機能は、使用しているImunify製品や、エージェントおよび拡張機能の必要なバージョンによって異なります。.

したがって、運用ドキュメントを作成する際には、明確な現状把握を行うことが推奨されます。製品バリエーション、インストールされているエージェントのバージョン、ホスティングパネル、および有効化されている保護モジュールは、すべて変更履歴文書にまとめて記載する必要があります。 そうすれば、WordPressの管理者は、そのプラグインがファイアウォールルールを制御したり、サーバー上の他のユーザーアカウントを保護したりしていると誤解することなく、バックエンドで通知を適切に分類できるようになります。サーバー側のセキュリティアーキテクチャが依然として決定的な役割を果たします。.

マルウェアの検出が実際に何を意味するのか

バックグラウンドスキャンおよびオンデマンドスキャンでは、検出結果が管理インターフェースに、検出日時、ファイルパス、および検出理由とともに表示されます。 これらの情報は、トリアージの起点となります。ファイルパスにより、検出結果が顧客アカウントおよびアプリケーションに紐付けられ、時刻情報はデプロイ、アップロード、または不審なログエントリとの照合に役立ちます。ただし、これらは具体的な内容やその生成経路の検証に代わるものではありません。.

優先順位付けを行う上で、検知のタイプは重要です。本来は正当なファイルに悪意のあるコードが混入している場合、そのファイルの出所や変更履歴、および同じアカウント内でのさらなる改ざんについて調査する必要があることが多々あります。 一方、それ自体が有害であると認識されたファイルは、埋め込まれたウェブシェル、ドロッパー、または望ましくない管理ツールの存在を示唆している可能性があります。いずれの場合も、自動的な結論ではなく、文脈を考慮する必要があります。.

検出結果があるからといって、アカウント内のすべてのファイルが侵害されたことを証明するわけでもなければ、侵害の規模が自動的に明らかになるわけでもありません。逆に、検出結果のないスキャン結果が完全な安全性を証明するものでもありません。新しい種類のエクスプロイト、隠蔽されたコード、あるいは検出範囲外の持続性などについては、追加の調査が必要になる場合があります。 また、WAFやスキャナーによる検知結果がないからといって、攻撃が発生しなかったという証拠にはなりません。.

例えば、スキャナーがWordPressプラグイン内のPHPファイルを検出した場合、管理者はまず検出履歴とパスを保存し、そのファイルを信頼できる開発元または検証済みのバックアップと比較する必要があります。その後、プラグインのバージョン、管理者、アクセス情報、および潜在的なバックドアを確認する必要があります。 複数のWordPressプロジェクトを組織内に統合する際には、以下の指針が役立ちます。 Bloggerホスティングにおけるセキュリティ要件, 、ただし、個々の事案に応じた法医学的調査に代わるものではありません。.

スキャン方法、前提条件、および適用範囲

Imunify360の定期的なファイルスキャンは、ホスティング環境内の保存済みファイルを検査します。これらは、定期的なバックグラウンド実行だけでなく、モニタリングやサポートからの通知を受けた後の的を絞った検査にも適しています。 ただし、その検査結果は対象となったファイル群に限定されます。データベース内のコンテンツ、HTTPリクエスト中の攻撃、あるいはすでに悪用されているアクセス権などについては、追加の検査や保護層が必要となります。.

仝 リアルタイムスキャン この検査を特定の転送経路に拡大します。 HTTPおよびHTTPSによるアップロードのスキャンについては、ドキュメントではModSecurityが前提条件として挙げられており、FTPアップロードにはPure-FTPdが必要です。したがって、これらのサービスが有効であり、適切に設定されているかどうかは、サーバーごとに確認する必要があります。この機能は、エージェントをインストールしただけでは、すべてのアップロードチャネルに対して自動的に有効になるわけではありません。.

スキャン範囲には、アーカイブの検査も含まれます。ドキュメントによると、Imunify360 6.2 以降、ZIP アーカイブはデフォルトでスキャンされるようになっています。 これは特にプラグインパッケージ、バックアップアーカイブ、またはアップロードされた拡張機能において有用ですが、アプリケーションが後でそのアーカイブを安全でない方法で解凍するかどうか、あるいはその内容が技術的に許容されるものかどうかについては何も示していません。.

仝 マルウェアデータベーススキャナー (MDS) は、CMS の投稿、オプション、ウィジェットのコンテンツなどに悪意のあるコードが埋め込まれている場合、ファイルスキャンを補完します。 公式にサポートされているのは、WordPress、Joomla、Magento 2に限られます。独自のアプリケーション、異なるデータベース構造、またはその他のショップシステムについては、これに基づいてデータベースが完全にカバーされているとは見なさないでください。.

RapidScan およびデータベースのチェックをスケジュールする

RapidScanは、マルウェアスキャンの基本的な要件を変えるのではなく、繰り返し行われるスキャンのプロセスを変革します。Imunify360は、この目的のためにファイルのメタデータとハッシュ値をローカルに保存し、クラウドベースのデータベースとハッシュ値を照合します。 その後のスキャン実行時には、ローカルでの分析を、変更されたファイルやまだ未知のファイルに集中させることができます。.

最初のスキャンでは、まず通常の在庫チェックが必要です。メーカーによると、その後のスキャンでは処理速度が5倍から20倍に高速化される可能性があります。 この範囲は状況に応じたメーカーの目安であり、すべてのサーバーに対して確約されるものではありません。ファイルの規模や構成、変更頻度、利用可能なI/O性能、ネットワーク環境などが結果に影響を与えます。.

計画の観点から言えば、これは、変更されていないWebファイルが多数格納されたサーバーは、 RapidScan 継続的にアップロード、キャッシュ、またはログファイルを生成するアカウントよりも、より大きなメリットを得られます。 したがって、総実行時間だけでなく、変更前に影響を受けるパス、ファイルアクセス回数、I/O待機時間を記録しておく必要があります。そうすることで、推測ではなく具体的な原因に基づいて、スキャン範囲や除外対象を決定できるようになります。.

WordPressの投稿が改ざんされていたり、設定にスクリプトが仕込まれていたりする場合、単なるファイルスキャンだけでは不十分な可能性があります。MDSは、対応しているWordPressデータベースに対して、まず非介入モードで --scan 確認する。この手順ではデータに変更は加わらず、決定を下す前に、問題の発生箇所、ウェブサイトへの影響、および復旧の可能性を評価するための基礎を築くものです。.

一方、データの修正や復元は、コンテンツそのものへの介入となります。その前に、最新かつ検証済みのバックアップ、対象となるウェブサイトに関する技術的な承認、そして正当なコンテンツが変更されてしまった場合の復旧計画を準備しておく必要があります。多くの独立した顧客プロジェクトでは、次のような明確なコンテンツの分離が役立ちます。 マルチドメインホスティング 重要な点は、これが責任範囲を明確にし、発見物の割り当てを容易にするということです。.

MDSは、完全なインシデント分析の代わりにはなりません。 再出現したデータベースのマルウェアは、脆弱性のあるプラグイン、侵害された認証情報、あるいはファイルへのバックドアの存在を示唆している可能性があります。そのため、マルウェアが発見された場合は、データベースの内容に加え、CMS、拡張機能、ユーザーアカウント、および書き込み操作の発生源についても調査する必要があります。.

WordPressとの連携と、管理されたWAFの更新

「Imunify Security Plugin」と呼ばれるこのWordPress拡張機能は、サーバー上のImunifyエージェントによって管理されており、WordPress.orgのディレクトリからは提供されていません。 このプラグインは、WordPress管理者にステータス情報を表示するほか、導入されているImunify製品によっては、管理画面上でその他のセキュリティ機能も利用可能にします。したがって、これはユーザーインターフェースおよび補完的な機能であり、サーバー側のスキャンおよび保護メカニズムの代わりとなるものではありません。.

基本機能については、ドキュメントではサーバー側で少なくともImunify360 8.4.1が必要であると記載されています。WAF統合やAIボット管理などの機能は別途開発が進められており、それぞれ指定されたエージェントおよびプラグインのバージョンに紐づいています。 したがって、ロールアウトを行う前に、プラグインが存在するという事実だけで特定の保護機能が利用可能であると推測するのではなく、具体的なバージョンの組み合わせを確認してください。.

WAFも独立したレイヤーとして運用すべきである。以下、 imunify360-firewall 8.6.0 ModSecurityのルール更新を無効にし、利用可能なルールの一覧を表示し、特定のバージョンを選択するための手順が文書化されています。これにより、ホスティング事業者はルールの変更を管理された形でスケジュール設定し、必要に応じて既知の状態に切り替えることが可能になります。.

適切な手順としては、まず、代表的なWordPressページ、ショップのキャンペーン、アップロードデータを備えたステージングサーバー上で、新しいルールバージョンを導入します。関連する誤ブロックや機能上の問題が確認されなくなった段階で、初めて本番環境への段階的な移行を行います。 なお、このバージョン管理の対象となるのはModSecurityルールであり、マルウェアシグネチャ全体やエージェント全体、その他のImunifyコンポーネントは対象外です。.

管理された WAFルールの更新 すべての障害を防ぐことはできませんが、責任の所在を明確にすることは可能です。変更内容を誰が確認するのか、どのアプリケーションがテストケースとして使用されるのか、そしていつロールバックを行うのか。こうした質問は運用プロセスに組み込む必要があります。 CMSや拡張機能のタイムリーな更新、権限の厳格な管理、そしてテスト済みのバックアップは、依然として不可欠です。なぜなら、WAFではインストール済みのソフトウェアに存在する既知の脆弱性を排除することはできないからです。.

マルウェアの検出を確実に確認し、対処する

マルウェアの検出は調査のためのプロセスであり、必ずしも削除の指示を意味するわけではありません。 まず、管理画面で検出履歴、検出日時、完全なパス、および検出理由を確認してください。これらの情報は、そのファイルがプラグイン、テーマ、アップロードディレクトリ、あるいは独自に開発されたアプリケーションのいずれに属するものか、また同様の検出結果が以前に発生していたかどうかを判断するのに役立ちます。.

不審なPHPファイルは、同じバージョンの信頼できるメーカー提供のソースコード、または検証済みのバックアップと比較してください。標準コンポーネントの場合、個々の（場合によっては偽装された）コード行を単独で検討するよりも、全体を改めて照合する方が、多くの場合、より有意義な結果が得られます。 後で侵入経路を特定できるよう、変更を行う前に、発見されたファイルと関連するログを必ず保存しておいてください。.

根本原因の分析には、報告された経路以上の要素が含まれます。影響を受けるCMS、プラグイン、テーマのバージョンを更新し、ユーザーアカウントを確認し、正当な疑いがある場合はアクセス情報を変更してください。さらに、その他のウェブシェル、未知の管理者、不審なスケジュールされたタスクがないか確認してください。 1つのファイルが削除されたからといって、攻撃者が2つ目のアクセス経路を残していないとは限りません。.

データベースでの検出結果に対しては、修正作業によってコンテンツや設定が変更される可能性があるため、特に慎重に対応する必要があります。 スキャンはあくまで初期段階の検査であり、修正や復元を行うには、利用可能なバックアップ、技術的な承認、および復旧計画が前提となります。マルウェア・データベース・スキャナーは、WordPress、Joomla、Magento 2 について文書化されているデータベースの事例のみをサポートしており、任意のアプリケーションスキーマに対する一般的な検査を行うものではありません。.

Adminerが検出された場合、このツールは正規にインストールされている可能性がありますが、悪用される恐れのある機能を備えているため、検出されるのは当然のことです。 検出カテゴリをグローバルに無効化するのではなく、具体的なファイルの必要性、完全性、およびアクセス保護を確認してください。例外が避けられない場合は、アカウント単位やサーバー単位で検出を無効化するよりも、パスを厳密に限定して除外する方が、セキュリティ上の脆弱性をより効果的に抑えることができます。.

負荷、誤警報、および持続性を調査する

CPU使用率やI/O待ち時間が上昇した場合、除外処理を最初の対策として行うべきではありません。 まずは、スキャンイベント、影響を受けたパス、変更率、アクティブなプロセス、および負荷が発生した期間を把握してください。時間的な相関関係を分析して初めて、リアルタイムスキャンが関与している可能性があるのか、あるいはバックアップやインポート、不具合のあるアプリケーション、その他のサービスがリソースを消費しているのかが判明します。.

頻繁に記述されるログファイルは、繰り返しスキャン処理を引き起こす可能性があり、その結果、追加の負荷が生じる原因となる場合があります。 サポートケースの記録には、WordPressのログファイルにおけるこのパターンが記載されていますが、負荷がかかっているすべてのサーバーに当てはまる一般的な因果関係を示すものではありません。したがって、予防措置として顧客ディレクトリ全体を マルウェアスキャナー 除外する。.

例外には、明確に定義された目的、責任者、および定期的な見直しが必要です。 正当に生成され、非常にアクティブなパスについては、分析の結果、限定的な例外を認めることが妥当である場合もある。しかし、攻撃者がファイルを保存したり改ざんしたりする可能性のあるアップロードディレクトリやアプリケーションディレクトリへと、その例外が気づかれないうちに拡大されてはならない。.

データ整理後に繰り返し検出される項目は、以下の検査を行うべきであることを示唆している。 永続性 単なる削除だけでは不十分です。ファイルやデータベースに加え、cronジョブ、未知の管理者アカウント、アクセス情報、Webサーバーのログ、実行中のプロセスも検査の対象に含める必要があります。特に、スケジュールされたタスクは、悪意のあるコードを再度ダウンロードしたり、削除されたWebシェルを置き換えたりする可能性があります。.

Imunify360では、バージョン6.10以降、システムおよびユーザーのcrontabのスキャン機能を、実験的な機能として、かつデフォルトで無効化された状態で提供しています。これにより検査範囲は広がりますが、不審なジョブに対する手動での評価に代わるものではありません。 有効化する前に、負荷、互換性、および自社の運用への影響を確認してください。すべてのホスティング環境で一律に有効化すべきというわけではありません。.

運用、移行、および展開を決定する

ウェブサイトの数が少ない小規模なサーバーの場合、スケジュール可能なバックグラウンドスキャン、追跡可能な通知、および手動による対応措置の承認で十分である場合があります。一方、リセラーホスティングや共有ホスティング環境では、以下の要件が高まっています。 エスカレーション手順: 発見事項の評価は誰が担当するのか、顧客への連絡は誰が担当するのか、例外措置を講じることができるのは誰か、そしてアカウントの制限はどのような場合に適用されるのか。責任の所在を文書化しておくことで、サポート部門と管理部門の間に、是正措置やセキュリティ上の脆弱性が放置されるのを防ぐことができる。.

リアルタイム保護、スキャン間隔、および通知は、変更率やサーバーのリソースに合わせて調整する必要があります。 多くの独立した顧客アカウントでは、一貫した手順と追跡可能なログ記録が有効です。一方、単一のビジネスクリティカルなプロジェクトでは、多くの場合、調整されたメンテナンスおよび承認プロセスが追加で必要となります。アップデート、最小限の権限、テスト済みのバックアップといった基本的な保護対策は、これらとは関係なく常に必要です。.適切なウェブホスティングサービスを選ぶための基準

本番用リポジトリとテスト用環境は厳格に分離する必要があります。ベンダーは本番チャネルにおいて安定版を段階的に展開しており、その期間として最大で約2週間を想定しています。テスト用リポジトリ内でのみ利用可能な機能、あるいは --beta 表示されているからといって、必ずしも一般的に安定して利用可能であるとは限りません。.

制御された ロールアウト まず、バージョンの確認と、代表的なステージングサーバーまたはパイロットサーバーからの開始となります。アップデート後は、エージェントの状態、パッケージ管理、不審なログ、および顧客にとって重要な機能をチェックします。 特に問題が確認されない場合にのみ、段階的な展開に進みます。これにより、すべてのリスクが排除されるわけではありませんが、異常を早期に発見し、的確な対応を容易にします。.

Patchmanへの任意の移行は運用上の決定であり、自動的な近代化ではありません。 移行後は、従来のPatchmanの隔離領域からファイルを復元することはできなくなります。ドキュメントによると、Imunifyはクリーンアップされたファイルのバックアップを作成します。そのため、移行前に、運用担当者はデータの保管方法、復元手順、顧客への連絡、および責任の所在について、明確に定めておく必要があります。.

における具体的な更新の問題として imunify-common メーカーによると、Berkeley-DB ベースの RPM データベースを搭載した CloudLinux 8 における 1.3.21-1 の問題は、1.3.22-2 以降で修正されたとのことです。 したがって、これがアップデートに反対する一般的な根拠になるわけではありません。しかし、この事実は、メンテナンスウィンドウ、文書化されたバージョン、およびパッケージ管理の事後確認が、プロフェッショナルなアップデート手順に不可欠である理由を浮き彫りにしています。.