今日、DigitalOcean から、DDoS 攻撃が行われていたため、Droplet が切断されたという通知を受けました。
彼らは私に調査して原因を突き止めるよう依頼しました。
これは Ubuntu 14 で、6 つの Apache VirtualHost が稼働していました。すべて稼働中でした。
私のサイトの 1 つは、いくつかのプラグインを備えた WordPress インストールでした。
別のサイトには Google Maps API コードが含まれていました。
残りには私のオリジナルのコードのみが含まれていました。
まだサーバーにログインしていません。ログインしたら、この問題の原因となっているソフトウェアを適切に見つけるには、どのような手順を踏めばよいでしょうか?
これは、パスワードに SSH キーを使用していなかったために発生したと思われます。
答え1
まず、このような事態に対処しなければならないことにお悔やみ申し上げます。しかし、これは解決できます。まず、次の点について言及する必要があります。
これは、パスワードに SSH キーを使用していなかったために発生したと思われます。
99%そうではないと確信しています。私が20年以上の経験で個人的に対処し、クリーンアップしたWebサーバーの侵害のほとんどすべては、アプリケーションレベルの欠陥とないSSH または SFTP に接続されているもの。実際、ほとんどの Web 開発者/管理者は SSH/SFTP レベルの侵害に対処することはありません。フロント フェイス コードの欠陥は、多くのマルウェアやパブリック Web システムへの不当な侵入の主なエントリ ポイントです。
そしてあなたの場合は、次のように述べています。
これは Ubuntu 14 で、6 つの Apache VirtualHost が稼働していました。すべて稼働中でした。
私のサイトの 1 つは、いくつかのプラグインを備えた WordPress インストールでした。
別のサイトには Google Maps API コードが含まれていました。
私の推測では、WordPress のアップデートやパッチを最新の状態に保っていなければ、WordPress のインストールが脆弱だったと考えられます。WordPress コアだけでなく、プラグインも同様です。
既存のコードベース、データベース、および構成をバックアップします。
私が最初に行うことは、index.php各サイトのルート インデックスに「メンテナンスのためダウン」という設定をして、Apache 仮想ホストを無効にすることです。また、TAR/Gzip アーカイブを使用して各仮想ホストのインストールのコピーを作成し、それをダウンロードして、フォレンジック調査に利用します。これは、MySQL データベースのダンプや関連する構成ファイルを含むすべての Apache 仮想サーバーに対して行う必要があります。
ディレクトリに感染の兆候がないか確認し/tmp/、必要に応じて削除します。
次にお勧めするのは、/tmp/サーバー上のディレクトリをダンプして再作成することです。Linuxウェブサーバー上のマルウェア感染の多くは、そのペイロードのかなりの部分をディレクトリに配置するためです/tmp/。この回答ではしかし、結局のところ、次のことを行うことになります。
まず、/tmp/ディレクトリを調べて、そこにあってはならないものがないか確認してください。Linux システム上のマルウェアの 10 件中 9 件は、 にインストールできます/tmp/。
何を入れるべきか、入れるべきでないかがわからない場合は、/tmp/悪いものを削除するために、簡単だが極端な方法があります。コマンドラインでこれをオンラインで実行するだけです。
rm -rf /tmp && mkdir /tmp && chown root:root /tmp && chmod 1777 /tmp
または、次のように各コマンドを個別に実行します。
sudo rm -rf /tmp
sudo mkdir /tmp
sudo chown root:root /tmp
sudo chmod 1777 /tmp
次に、サーバーを再起動して、問題が解決するかどうかを確認します。問題が解決した場合、おめでとうございます。ただし、元のシステムの原因が何であれ、システムに侵入できるため、まだ危機は去ったわけではなく、再び感染するのは時間の問題です。つまり、これにより、システムの弱点によって引き起こされた混乱は解消されますが、その弱点が何であるかを特定して強化する必要があります。
Bash の「shellshock」脆弱性チェック。
そして、他の回答では、「shellshock」の脆弱性を確認する方法についてのヒントを提供しますbash。このサイトは優れたテストツールを提供していますサーバーがbash「シェルショック」エクスプロイトに対して脆弱かどうかを確認します。正直なところ、これは発見されて以来、私がパッチを適用しなければならなかった最も一般的なセキュリティ ホールの 1 つです。したがって、これがサーバーの弱点である可能性も十分にあります。bash脆弱性が見つかった場合に修正する方法については、すべての OS レベル コンポーネントをアップグレード/パッチする方法に関する以下のセクションを参照してください。これを実行し、bash同様にアップグレード/パッチを適用する必要があります。
すべての OS レベル コンポーネントをアップグレード/パッチ適用します。
大変なことのように聞こえるかもしれませんが、実際には Linux システムではセキュリティ パッチが常にリリースされています。Ubuntu や CentOS などの標準化された Linux インストールを使用している場合は、次のようにパッケージ インストーラーから更新/アップグレードを実行するだけで済みます。Ubuntu では、次のようにします。
sudo apt-get update
sudo apt-get upgrade
しばらくシステムを更新していない場合は、対処が必要なパッチや更新が大量に見つかるかもしれません。慌てないでください。これは正常な動作です。 と を実行しupdateてupgrade待つだけです。その後再起動が必要になるかもしれませんが、それが完了すると、コア OS は完全にパッチが適用され、最新の状態になります。
Apache 仮想サーバー コード システム (WordPress および Google API など) のコードベースを評価します。
覚悟してください。これはもっとひどい部分です。コードベースをダウンロードして評価する必要があります。潜在的に感染しました。うまくいけば、侵害されたサイトは 1 つまたは 2 つだけです。これを実行する方法は各設定に特有ですが、一般的には、各サイトを開発環境に読み込み、WordPress コアをアップグレードし、プラグインをアップグレードし、すべてが正常に動作するかどうかを確認してから、そのコードがクリーン/安定していると見なす必要があります。
ここまで、この手順をかなり単純化してきました。しかし、実際には、パッチやアップグレードを行った後でも、WordPress コアにマルウェア コードが残っている可能性があります。そのため、もう 1 つの方法は、各 WordPress サイトをゼロから再構築することです。データベースとテンプレートはそのままにして、基本的に新しいクリーンな WordPress コアからサイトを再構築します。
確かに、それは大変な作業のように思えますが、異なるコードベースを持つ仮想サーバーが多数ある場合は、選択の余地はありません。
死後のアドバイス。
これはすべての場合に有効というわけではありませんが、こう言えます。クリーンなコードベースのバックアップと、場合によっては GitHub リポジトリは、上記の面倒な最後の「評価」ステップなしで混乱を解消する方法です。
私がやっているのは、作業しているデータベース ドライブのサイトで定期的に MySQL ダンプを実行し、クリーンなコア コードベースが GitHub にあることを確認することです。そうすれば、マルウェア感染が発生した場合、MySQL バックアップを調べて、GitHub からクリーンなコードを再展開し、コードベースがクリーンであることを保証できます。サーバー自体が信じられないほど壊れている場合はどうでしょうか? 感染したシステムをダンプし、新しい Linux システムを再構築し、コードを展開し、データベースをインポートし、構成を調整して、それで終わりにします。
覚えておいてください。すべての Web サイトの 99% は、データベース、コードベース、および一連の構成で構成されているだけです。感染していないコードを「フリーズ」またはバックアップするクリーンな方法と、MySQL データベースのバックアップがあれば、構成関連の作業だけを処理すれば済みます。これは、コードを最初からクリーンアップするのに比べれば、さほど面倒ではありません。