こんにちは、ハブユーザーの皆様。 最後に、匿名を条件に彼の問題の解決策を説明できる別のクライアントを得ました。 カットの下には、同時にいくつかの方法で顧客のサイトに現れた悪意のあるコードとの戦いがどのように起こったかについての物語があります。 多くの人々が大量の記事を好まないという事実のために、今回は、できるだけ簡潔にすべてを述べようとしました。
初期データは以下の通りです。 Ubuntu 10.04を実行している仮想サーバーがあります。 顧客が自分で管理します。 サーバーには13のサイトがあり、そのうち12がWordPressにデプロイされ、1つは静的なhtmlページで構成されています。 ファイルの内容はFTP経由で管理され、2台のコンピューターからのみ管理されます。 1台のMac、Win7およびライセンスされたKAVを搭載した2台目のPC。
定期的に、1〜2週間ごとに感染します-難読化された挿入がphpスクリプトコードに表示されます。 クライアントは最初の会話で、同じiframeコードが常にスクリプトに表示されると言いましたが、後で判明したように、いくつかのマルウェアがありました。 最終的に、サイトはGoogleとYandexの発行から飛び去り、訪問者の数は徐々にゼロになりました。
最初の検査の後、さらに興味深い詳細がいくつか見つかりました。
- すべてのブログは、MySQLをルートとして使用していました。
- 内部からサイトを管理するために、VDSで単一のユーザーが作成され、そのホームフォルダーにすべてのWebディレクトリが同時に配置されました。
- PHPはApacheモジュールとしてインストールされたため、Apacheモジュールはすべてのサイト（www-data）に代わって機能しました。 したがって、すべてのリソースに影響を与えるには、少なくとも1つのリソースで欠陥を見つけるだけで十分です。
- 各ブログには、セキュリティ関連の多くのプラグインがインストールされました—いくつかのWPスキャナー、チェックサムなど。
- 多くのファイルで、悪意のあるコードはネイティブのコードよりも多くのスペースを占めました-繰り返し感染している間、ロボットはスクリプト内のコードの存在をチェックしませんでした。
これはすべて深刻な問題を追加しました。 この段階で、問題は単純ではないことが明らかになりました。このトラブルからクライアントを救うためには、FTPパスワードとクライアントマシンの保護だけでなく動作する必要があります（このような状況でよくあることです）。
次に、考えられる感染経路のリストがまとめられ、それぞれを確認する必要がありました。 まず、単にその普及のため、リモートアクセスサービスから以前に盗まれたパスワードの助けを借りた感染のオプションが検討されました。 もちろん、Win-machineでの新しいKAVは良い議論ですが、ウイルス対策ソフトウェアがインストールされる前にパスワードが盗まれる可能性があります。 管理者がすぐにそれらを置き換えるという事実ではありません。
2番目は、あらゆる種類のバックドアを介した感染でした。 管理者が時間どおりにWPを更新せず、一部のシェルがサイトにアップロードされ、悪意のあるコードが絶えず感じられるようになったとします。
3番目のオプションとして、サイトスクリプトの脆弱性による感染が検討されました。 技術的な理由により更新できないため、WP 2.9.2はいくつかのリソースにインストールされました。 このバージョンの作業時には、TrackBack関数でのSQLインジェクションのみが知られており、どのサイトのクライアントでも使用されていませんでした。 しかし、プラグインとテーマを忘れないでください。 また、しばしばエラーを見つけます。 さらに、phpBBフォーラムバージョン3.0.8がいずれかのサイトにインストールされました。 動作していませんでした（データベースへの接続なし、構成ファイル内の誤ったデータ）が、それでもチェックすることにしました。 このバージョンの脆弱性に関する情報の公開ソースには見つかりませんでしたが、公式フォーラムにはそのハッキングを説明するトピック（
http://www.phpbb.com/community/viewtopic.php?f=46&t=2119662 ）があります。 ただし、データベースへの接続がない場合、このバージョンのフォーラムがハッキングされないという保証はないため、問題はありません。
その後、過去数日間にわたってWebおよびftpサーバーのログがチェックされました。 好奇心が強いものが判明しました。 一度、ロボットは1日に1回FTP認証に合格し、すぐにシャットダウンしました。 アカウントの有効性を確認したようです。 もう1つは毎日FTPにアクセスし、常に異なる12個のスクリプトをダウンロードし、悪意のある挿入がない場合は状況を修正しました。 出入り口はWebサーバーのログで照らされており、人々は主にYandexから来ました。 サイトのさまざまなポイントから発信されたモバイルブラウザのユーザーの奇妙なリダイレクトもありました。 ルート.htaccessを介して実装されました。 さらに、3つのWebシェルが見つかりましたが、POST要求が時々送信されました。 一般に、12のサイトはすべて、あらゆる種類のマルウェアで溢れかえっていました。
最初に、クライアントは、現在の危険な挿入物に触れないように求められ、これらのトラブルがすべて認識される前に作成されたバックアップコピーを単純にロールアップしました。 しかし、詳細な研究の後、彼女はまた、上記のすべてをほんの少しだけ持っていることが判明しました。 したがって、各問題を個別に処理することが決定されました。
ここで、感染源が排除されなければ、そのような戦いは役に立たないと退却する必要があります。 コードを可能な限りきれいにすることができます-悪意のある挿入は引き続き返されます。 したがって、次の作業が行われました。
- 各サイトに対して、データベースへのアクセス権のみを持つ個別のMySQLユーザーが作成されました。
- OSのサイトごとに個別のユーザーが作成され、対応する権限がそのディレクトリに設定されました。 WPインストールドキュメントで指定されたディレクトリについては、777の質問はありませんでした。 所有者のみが最大の書き込み権限を持ちました。
- ApacheとPHPのバンドルは、ユーザー所有者に代わってphp.iniとインタープリターを別々にサイトスクリプトで動作させるために、mod_phpからphp-cgi + suPHPに再作成されました。
- FTPアクセスは、クライアントが使用するプロバイダーのネットワークからのみ許可されました。
- 各サイトのデータベースでは、アカウントのあるテーブルで、管理者がどこから来たのかわからないかどうかがチェックされました。
- 役に立たないため、WPセキュリティに関連するすべてのプラグインを削除しました。
- 上記のフォーラムへのアクセスは閉鎖されています。
- MySQLルート、管理目的で以前に使用されたOSユーザー、および12の各サイトの管理者アカウントに対して、新しいパスワードが設定されました。
これらすべてのアクションの後、計算は次のようになりました。 悪意のあるコードとシェルが一掃されるとすぐに、待機します。 何かが見逃されて再び感染が発生した場合、すべてのサイトがファイルシステムとデータベースの両方で互いに隔離されているため、そのソースを即座に計算できます。
今度は掃除する時でした。 まず、コードの署名スキャナーである単純なスクリプトが作成されました。 難読化された挿入物は次々に収集され、そのベースに配置されました。 スクリプトは、コマンドですぐにすべての破損したファイルをクリアする必要がありました。 この作業のおかげで、リダイレクタのいくつかのオプションが見つかりました（検索エンジンから来た人のために機能していました）と、顧客が最初に話したiframeが1つありました。 その後、クラウンが作成され、コンソールユーティリティを使用してサイトのソースコードを定期的にチェックし、「system（」、「base64_decode（」など）などのフレーズを探しました。見つかった場合、管理者と私にメールで報告する必要がありました。すべてのウイルスが難読化されているわけではありません。WPテーマ（および各サイトでは標準ではありません）では、このような挿入物が多数見つかりました。それらは著作権の削除に対する一種の保護を表します。誤検出を避けるために、通常の形式に復元する必要がありました。
その後、サイトコードはすぐに削除され、出入り口とシェルは削除され、.htaccesssが修正されました。 数日後、ファイルへの変更は観察されなかったため、問題は解決されたと考えられます。
そしてもう一つ。 出入り口を調査する過程で、httpを介してコンテンツがロードされるホストが見つかりました。 このホストのWebサーバーには、他のハッキングされたサイトの名前にちなんで名付けられたいくつかのディレクトリがありました。 検出されたドメインにも出入り口があることをすばやく確認して、それらをウェブマスターと管理者に書きました。 残念ながら、私は単一の答えを受け取っていません。 それらへの出入口の充填はまだ保存されています。 しかし、私は配信サーバーに対処することができました。 ウクライナの会社から借りたVDSであることが判明しました。VDSは苦情を受け、数日間チェックを行った後、このサーバーをネットワークから切断しました。
上記のすべてに基づいて、次の推奨事項をウェブマスターとウェブリソース管理者に伝えたいと思います。
- データベースとOSレベルの両方でサイトを分離します-感染した場合、脆弱なサイトをすぐに特定します。つまり、悪意のあるコードがサーバーに到達した最初の欠陥がより迅速に発見されます。
- Apache2 + PHPバンドルで作業する場合、各サイトのスクリプトがその所有者（fcgi、cgi + suPHP、apache2-mpm-itkなど）に代わって実行されるようにインストールします-このようにして、悪意のあるコードが1つのサイトに移動できなくなります他人に感染します。
- サーバーで作業するアドレスに対してのみFTPアクセスを許可します。 突然旅行に出かけたり、プロバイダーを変更した場合は、SSHでいつでもIPホワイトリストを調整できます。
- 強力なパスワードを忘れないでください。 多くのロボットがネットワーク上で常に動作しており、標準リンク（admin：admin、site_name：ftppasswordなど）を使用してFTPサーバーへのアクセスの詳細を選択しています。
- Webアプリケーションをインストールする場合、ドキュメントで指定されているディレクトリに777を無意識に配置しないでください。 Webサーバーが所有者に代わってスクリプトを実行し、これらのディレクトリに何かを書き込む場合、書き込み権限はすべての人にではなく、スクリプトの所有者にのみ必要です（原則として、これはディレクトリの所有者でもあるため、700十分）。
- まあ、標準的なフレーズ（同じ単語が人に何度も繰り返されると、潜在意識に陥ります）-あなたのサイトにインストールされているWebアプリケーションの更新をお楽しみに。 可能であれば、セキュリティメーリングまたはサポートフォーラムの対応するセクションを購読してください。 パッチよりもはるかに早く、近づいてくる問題について知ることができます。
お時間をいただきありがとうございます。 この記事から何か役に立つことを学んだことを願っています。