スカイネット侵入後のセキュリティリークを見つける方法は？
数日前、友人のサーバーが侵入しました。攻撃により、有効なパスワードを提供せずに、有効なアカウントを許可する新しいSSHデーモンがインストールされました。ログイン後、各アカウントは自動的にroot権限を取得し、サーバーは次のように応答します。
攻撃はまた、侵入を示したsyslogエントリを削除し（syslogのログでそれを把握しました）、/etc/apt/sources.listのDebianパッケージの場所のパスを変更しました。
サーバーはDebianEtchで実行されており、攻撃中は最新ではありませんでした。Apache/ PHPにはすべてのセキュリティ更新プログラムがインストールされていませんでした。これらの更新が欠落しているために侵入が発生した可能性があると考えていますが、実際にはわかりません。攻撃の前日、Wordpress 3.0.1;をインストールしましたが、Wordpressのインストールがドアオープナーであったかどうかはわかりません。
サーバー上のどのセキュリティリークが侵入を許可したかを見つける方法はありますか？
攻撃者がルートを取得すると、ログを含むシステムを変更できるため、攻撃者がどのように侵入したかを判断するのが難しいことがよくあります。ネットワークを介して別のシステムにログを送信しない限り、特にログが変更されていることに言及しているため、運が悪い可能性があります。
明らかに、学んだ教訓は、パッチを最新の状態に保つ必要があるということです。通常、パッチは、yum/apt-getを介してリリースされてから1日以内に適用されます。
PHP、Apache、またはWordpress）に対する攻撃は、おそらく攻撃者にWebサーバーの特権を与えるだけであることに注意してください。しかし、あなたの説明から、彼らは間違いなくルートになっているようです。 Webアプリを介して、Apacheからrootにアクセスできるようにするための別の妥協点がありましたが、SSHなどの弱いrootパスワードを介して侵入したのではないかと思います...
ただし、攻撃する方法を知っていると、おそらくそれをクリーンアップすることはできません。あなたの説明から、この時点でマシンは非常に深刻な危険にさらされています。最善の策は、新しいOSを最初からインストールし、システムをバックアップすることです。古いボックスから持ち込んだすべてのデータとソフトウェアを監査します。危険にさらされたボックスを修正することは非常に困難です。
いずれにせよ、調べる方法があるかどうかについてのあなたの質問に答えるために、ここに何が起こったのかを探すためのいくつかの一般的な場所があります：
- / var/log/syslogまたは/ var/log/messages-おそらくログのギャップや説明できないアクティビティによって、攻撃が発生した可能性がある時期を探します。
- / var/log/securityのように他のログが消去されなかった可能性があります
- ルートやWebサーバーを含むさまざまなアカウントの.bash_history。これにより、実行したコマンドや実行内容に関する情報が提供される場合があります。
- 認識していない実行中のプロセス、または異常なディレクトリや名前から実行されている可能性のある認識しているプロセスを探します。実行中のプロセスのさまざまなプロセスID（$ PID）の/ proc/$ PIDおよび/ proc/$ PID/fdを確認します。
- おそらく「最後」はあなたに何かを教えてくれるでしょうが、彼らはおそらくそれを一掃しました。
- rkhunterは、システムで何が危険にさらされているかを知らせ、より多くの情報を探すことができる場所を見つけるのに役立ちます。
- Apacheログには異常なアクティビティの兆候が見られる場合がありますが、実際にシステムを破壊した攻撃から常に受ける攻撃を除外するのは難しい場合がよくあります。
この作業の多くは、異なるログファイル間の深刻な相互相関であり、何が興味深いのか、何が単なるノイズなのかを調べます。
この種の調査を行うことは迅速な作業ではありません。特に初めての場合は、おそらく4時間以上かかるでしょう。
なんらかのリモートロギングがない限り、おそらく運が悪いでしょう。
これを「教訓」までチョークで書き、システムを最初から再インストールして（真剣に、そのステップをスキップしないでください！）、新しいシステムにパッチを適用しておくのが最善だと思います。
私の経験では、自動更新を行う方が、手動で更新を行い、遅れてこれが発生するリスクを負うよりも、悪い自動パッチの後でクリーンアップする必要があるリスクがある方がはるかに優れています。最初のケースでは、ベンダー/ディストリビューションのパッチが不良であるという非常にまれなイベントでは、通常、最悪の場合、数分の作業で問題を修正できます。システムが妥協すると、全体が再構築され、多くの時間が失われます。