サーバーが2回目の侵害を受けたため、攻撃元を特定できません
サーバーの脆弱性を追跡するのに助けが必要です。私のサーバーは、ファイルがウイルスに感染したダウンロードに置き換わることで2度目の侵害を受けました。
ファイルシステムの日付によると、45分の間にサーバー上の4つのexeファイルが同じウイルスの名前が変更されたバージョンに置き換えられました。
私のWebサーバーは、カーネルバージョン2.6.32-31-genericでUbuntu 10.4.3 LTSを実行しており、完全にパッチが適用され、最新の状態に保たれています。
シェルにアクセスする唯一の方法は、SSHとUSBスティックで私が持っているパスワードで保護された秘密鍵を使用することです。パスワードSSHログインが無効になっており、サーバーのログ（変更できることはわかっていますが、変更できないと信じる十分な理由があります）は、SSHがサーバーへのログインに使用されなかったことを示しています。
Webサービスソフトウェアスタックは非常に複雑です。 PHP（5.3.3-1）w/Suhosin v0.9.29、nginx 1.0.9（現在は1.0.10に更新））、Tomcat（刑務所にあり、私は関連付けられていないと思われる）、およびMySQL 5.1.41。
最初の攻撃の時点で、頭痛の緩和を目的として、私は冷静にchmod -R 777の私のウェブディレクトリに満足していたことを認めます。今、私はPHPスクリプトの完全な混乱を実行します。これには、WordPress、vBulletin、およびいくつかの自家製製品が含まれますが、これらに限定されません。最初の2つは常に最新で、後者はかなり書かれています。ユーザー入力値をエスケープまたは正規化するように細心の注意を払ってください。
ファイルのアクセス許可は弱いものの、サーバーアクセスは厳しく制限されているため、ランダムコードの実行を許可する多くのPHPスクリプトの1つに脆弱性があると疑いました。
それ以来、ファイルのアクセス許可を完全にロックダウンしました。 nginx/phpは両方ともwww-data：www-dataとして実行され、すべてのファイルには実行と読み取りの権限のみが与えられます（chmod -R 550 /var/www）。
しかし、今日、このすべての後、私のサーバーは再び侵害されました。
問題は、置き換えられたファイルには550許可、SSHログはログインがないことを示し、次に何をするか、または次に試すかについて完全に迷っています。
非常に基本的なPHPスクリプトに置き換えられたパスへの攻撃を再現することを試みました：
$file = fopen('/var/www/mysite.com/path/to/file', 'w');
fwrite($file, 'test');
fclose($file)
しかし、それにより、適切なアクセス許可拒否エラーが発生しました。
誰でもお願いできますか、この脆弱性の原因を次にどこに探すべきか教えてください。ファイルのアクセス許可で何か不足していますか？
サーバーは、一度侵害されると、ほとんど永久に「なくなる」ことを知っています。しかし、それは実際にはここではオプションではありません。/var/logフォルダー全体を再帰的に調べて、問題のあるファイル名を探して何かを見つけようとしましたが、何も見つかりませんでした。
また、最初の攻撃時に配置された可能性があるcronフォルダーまたはその他の場所にあるスクリプトを検索しましたが、（a）何も見つかりませんでした。（b）何も見つかりませんでした。/etc /内のファイルはwww-dataで変更できません（nginx/PHPの侵入ポイントを想定）。
どちらの場合も、感染したファイルの名前をnginxアクセスログ（結合したスタイル）でgrepしましたが、何も見つかりませんでした。ただし、私のgrepsからファイル名を覆い隠す方法はたくさんあることは理解しています。
攻撃者が侵入した方法を見つけるためのいくつかのテクニック：
- 攻撃者が変更したことがわかっているファイルのタイムスタンプを確認し、すべてのログを調べて、各タイムスタンプにできるだけ近いエントリを探します。他の人が言ったように、WebアクセスログとWebエラーログは、最初の攻撃ベクトルの証拠を保持する可能性が最も高いですが、他のログファイルも同様に手掛かりを保持している可能性があります。エラーログは多くの場合、最良の手がかりを保持しています。ネットワークからアクセス可能なすべてのデーモンのログも確認するのに適しています。
- また、あなたが知っているものに近いタイムスタンプを持つ他のファイルを探す価値があるかもしれません。
/etc/passwdは明白なものですが、ログファイルに異常なタイムスタンプが付けられていると、疑わしい場合があります。 logrotateが毎日同時に実行され、ログファイルの1つにこの時間と一致しないタイムスタンプが含まれている場合、おそらくそれが変更されて彼のトラックをカバーしているため、彼の操作についてもう少し詳しく知ることができます。ユーザーのホームディレクトリにある.bash_historyファイルを忘れないでください。findコマンドはこれを処理できるはずです。 - Webアクセスログに対して scalp を実行します。元の攻撃は、ファイルが表示される前に発生した可能性があります。 Scalpは誤検知を生成しますが、手動で異常を分析するには、潜在的な疑わしいログエントリを絞り込みます。また、完全に攻撃を逃す可能性もありますが、完全ではありませんが、役立つ場合があります。
侵害されたシステムのフォレンジックにあまり時間をかけないでください。他の人が指摘したように、攻撃者は元の攻撃のすべての証拠を削除し、ルートキットを追加して自分の存在を隠す機会がありました。彼が何かを逃した場合、または彼が試みさえしなかった場合、上記のタスクは機能するかもしれませんが、彼がうまく身を隠した場合、あなたは貴重な時間を無駄にするだけでしょう。
攻撃の発信元を見つけられなかった場合は、問題のサーバーをワイプして再インストールします。ただし、次回の攻撃に備えて、いくつかの追加を行います。
- Syslogの変種を使用して、ログを別のサーバーに送信します。 （ rsyslog と syslog-ng が推奨される選択肢です）このサーバーは、ログを受信するだけで、ログインキーやパスワードを他のサーバーと共有しないでください。目標は、ログが改ざんまたは削除されないようにすることです。
- デフォルトを超える追加のロギングを追加します。ジェフはすでにAppArmorについて言及しましたが、Ubuntuを使用しているので、これがおそらく最良の選択でしょう。ログがログボックスに送信されていることを確認します。
- 監査デーモン をインストールしてオンにします。ログがログボックスに送信されていることを確認します。
- Snort、PHP-IDS、mod_securityなどのIDSを実行します。 （または複数の場合、これらのツールはまったく同じ働きをしません）一部のハードウェアファイアウォールにはIDS/IPSモジュールが付属しています。 IDSからのログがログボックスに送信されていることを確認します。
- [〜＃〜] aide [〜＃〜] または Tripwire などのファイル整合性監視システムを追加します。これらのツールからのログがログボックスに送信されていることを確認してください。
- ログを監視します。 Splunkのようなものは商用のSIEMシステムでは不十分で、無料でインストールでき、限られた量のログを分析できます。サーバーのnormalと一致するルールを設定し、フィルターで除外します。残っているものは何でも詳しく調べる価値があります。
完全なネットワークパケットキャプチャなどの時間とお金がある場合は、他にもできることがたくさんありますが、実際には、これは、単独のシステム管理者が処理できると期待できるすべてのことです。攻撃者が再び現れた場合、攻撃が行われるとすぐに、攻撃ベクトルを見つける可能性が高くなり、攻撃者を検出する可能性が高くなります。
@Isziはここで完全に正しいです。良いルートキットはその存在の証拠を見ることを防ぐので、完全にワイプして再構築する必要があります。
そうでなければ、あなたが今やっていることは無意味であるという強い可能性があります。いずれの場合も、サーバーを信頼できなくなります。
ムハンマド、場合によっては、システム（通常はPhpMyAdmin）の脆弱性を悪用してサーバーにファイル（主に/ tmp）をアップロードしたボットによって攻撃が行われたことを確認しました。何が起こるかというと、これらのファイルはそのまま残り、攻撃者がボットログを調べて最初の侵害された場所で構築を開始するまで、管理者は気付かないでしょう。
PhpMyAdmin、vBulletin、または使用しているスクリプトの脆弱性が悪用された可能性があります。後で脆弱なアプリを更新しましたが、すでに妥協が行われています。
再構築を行わない場合、攻撃者が残したファイルがシステムを侵害するために再度使用されたことが起こります。システムにOSSECをインストールし、重要なファイル/フォルダーを監視すると、そのようなアクティビティの検出に役立ち、より迅速にアクションを実行できます。
すでに提供されているコメントにいくつかの考えを追加するだけです。 @symcbeanが言うように、サードパーティのコードが問題の原因である可能性があります。
私が推測を危険にさらすつもりなら、私はWordpressアプリケーションと関連するプラグインをあなたの妥協の原因である可能性が高いと考えます。最近Wordpressプラグインで多数のセキュリティの問題が発見され、それらの多くが積極的に悪用されているため、100％最新ではないものがインストールされていると問題が発生する可能性があります。
問題のWordpress部分への対処に関しては、wordpressセキュリティスキャナーである wpscan および secure wordpressプラグイン
通常、サーバーをワイプする余裕がないと言うと、構成をリセットする時間が多すぎることを意味します。ただし、これに対処する方法があり、脆弱性をすぐに見つける必要はありません-侵害されたファイルを置き換える必要があります。クリーンファイルをインターネットに公開する前にセキュリティを実装することをお勧めします。それらを一度壊したものがそれらを再び壊すでしょう。
以下のステップはDebianに焦点を当てています（あなたはどちらかを言っていないので、私は自分の好みを採用しました）が、Red Hatシステムでそれらを実行することもできます。 Red Hatベースのシステムでは、AppArmorの提案を対応するSELinuxセットアップに置き換える方が簡単な場合があります。 「dpkg」を対応する「yum」コマンドに変更します。
インストール済みのパッケージを使用して新しいシステムを構築します。
dpkg --get-selectionsは、dpkg --set-selectionsを使用して新しいシステムにパイプできるリストを提供します。Nginxとそれが使用する他のデーモン（Tomcatなど）を大幅に制限するようにapparmorを構成します。構成ファイルとWebページファイルの読み取りのみを許可します。実行している内容によっては、一部の書き込みをWebディレクトリーに対して有効にする必要がある場合があります。構成で、子プロセスがApacheの制限を強制的に継承するようにしてください。
他のすべてをコピーして戻します。
AppArmorログに細心の注意を払ってください。 Apacheがその権限に違反しようとしているのを確認したら、それをHTTPアクセス/エラーログと関連付けて、何が問題を起こしているかを判断できます。
また、すべてのデーモンの周囲に必須のアクセス制御を確立することは、最新かつ期待されるベストプラクティスであることを宣言します。これは脆弱性にパッチを適用しないままにすることを許すわけではないことに注意してください。多層防御は、欠陥を見つけやすくするためのものであり、負担を完全にシフトさせるためのものではありません。また、サーバーがサイトの訪問者への妥協点を提供している可能性があるという考えに非常に注意してください。
サーバー上の4つのexeファイルが同じウイルスの名前が変更されたバージョンに置き換えられました...私のWebサーバーはUbuntu 10.4.3を実行しています
サーバーにファイルアップロード機能がすでにあることを意味します。これは、穴を探すのに適した場所です。
サーバーは、一度危険にさらされると、ほとんど永久に「なくなる」ことを知っています。
そうではありません。適切な準備をすれば、システムを既知の状態（ホストベースのIDSとバックアップ）に戻すことが常に可能になります。しかし、それでも元の脆弱性がなくなるわけではありません。しかし、追加のバックドアが設置されることはなくなります。
wordPress、vBulletin、およびいくつかの自家製製品を含むがこれらに限定されない
ああ、神様。他の誰かが書いたからといって、それが安全であるとは限りません。オープンソースだからといって、安全だとは限りません。コードを適切に監査するスキルを持っている場合でも、Wordpressコードベースは巨大であり、vbulletinも巨大です。これは大きな作業になります。また、両方ともWordpressとvbulleting（IRC）は、サードパーティのプラグインをサポートしています。これらのプラグインは、多くの場合、コア製品よりも品質がはるかに劣ります。
Apacheを実行している場合は、mod_securityを使用して攻撃ベクトルを特定することをお勧めします。ただし、負荷がかなり高い場合でも、ファイルのmtimeとアクセスログを一致させることができるはずです（ご存じのとおり、ファイル名を確認するのは時間の無駄です）。