web-dev-qa-db-ja.com

サーバーが危険にさらされていることをどのようにして知っていますか?

私は最近、サーバーがハッキングされたクライアントを支援しました。ハッカーは、ホームページのヘッダーにいくつかのPHP=コードを追加して、ユーザーをポルノウェブサイトにリダイレクトしました。ただし、ユーザーがGoogleからのものである場合のみです。これにより、クライアントが特定するのが少し難しくなりました。クライアントGoogleからの新しいWebサイト訪問者のみがポルノサイトに誘導されます。

昨夜、別のクライアントにも同様のことが起こったようです。似たようなハックだと思いましたが、コードベースをチェックしたところ、悪意のあるコードは見つかりませんでした。彼のchromeブラウザはクライアントのWebサイトからwww(dot)pc-site(dot)comにリダイレクトしています。この動作は再現できません。悪意のあるコードが追加および削除されている可能性があると思います。サーバーがハッキングされたかどうかを確認するためのより包括的な方法。

この専用サーバー(およびホスティング会社Rackspace)にアクセスできる開発者は2人だけです。サーバーはRed Hat Linuxです。

サーバーがハッキングされているかどうかを確認するために実行する手順は何ですか?

45
Boz

[〜#〜]更新[〜#〜]

次のことを確認します。

  1. ログ。 rootアクセス権がある場合は、historyのようなものをチェックして、/var/logsのコマンド履歴とログファイルを取得する必要があります。

  2. ベースライン。アプリケーションやシステムファイルで使用するファイルハッシュのようなベースラインがある場合、これは非常に役立ちます。バックアップを使用して、以前の状態を比較することもできます。バックアップを使用してファイルを比較する場合は、可能であれば少し古いものを使用してください。サイトは少し前に危険にさらされていた可能性があり、リダイレクトがアクティブ化されたのは今回のみです。

  3. インクルードを確認します。ファイルがサーバー上にない可能性があります。それらは、<script src=”http://baddomain.com/s.js” />またはiframeタイプのタグなどのスクリプトが含まれる場合があります。画像、FlashのPDF(SWF)、ビデオファイルも除外しないでください。異なるコンテンツタイプのファイルにリンクを埋め込むことは、かなり一般的なトリックです。特にファイルの最初と最後で手動で検査することをお勧めします。ファイルは完全にlink/html/javascriptの場合もあれば、ファイルの末尾にリンクが続く正当な画像ファイルの場合もあります。

  4. 異常なファイルの日付、サイズ、権限を確認してください。 777。

  5. 異常なジョブがないかcronジョブを確認します。システムを危険にさらしている誰かがバックドアを離れ、何度も何度も侵入することがよくあります。 Cronは、これを達成できた場合に非常に人気のある方法です。

  6. ファイルの不在を確認します。ログにアクセスできない場合がありますが、ログの不在は、誰かが自分自身をクリーンアップしたことを示しています。

  7. 検索エンジンを使用します。当然のことながら、検索エンジンはすべてを見つけるのに優れています。 site:などのディレクティブを使用します。 site:yoursitehere.com baddomain.comヒットするかどうかを確認します。

  8. 多くの場合、リンクまたはリダイレクトは難読化されるため、1文字の変数を含む長いJavaScriptコードは慎重に分析する必要があります。

  9. 安全なワークステーションからサイトにWiresharkやtcpdumpなどのツールを使用してパケットキャプチャを実行します。それをファイルに保存し、URLの一部をファイルで検索します。

  10. 照会または更新される可能性のあるデータベースレコードを確認します。リンクは、PHPではなくデータベースに挿入できます。

  11. クライアントのワークステーションを除外しないでください。必要に応じて、無料のオンラインウイルススキャナーを使用してください。また、nslookupをチェックして、それがどのように解決されるかを確認してください。ブラウザの拡張機能を確認し、キャッシュをクリアして、hostsファイルを確認します。

それをクリーンアップするには(侵害されている場合)、ベアメタルに戻って再インストールする必要があります。それは痛いですが、あなたが本当にたくさんを得たことを確実にする唯一の方法です。

将来的にそれを防ぐには、次のことを行う必要があります(ただし、すでにこれらのいくつかを行っている可能性があります)。

  1. 安全な構成に関するベンダーの推奨事項の使用、最新のソフトウェアの使用など、サーバーを強化します。権限、パスワードポリシーなどの厳格なセキュリティ管理を適用します。 フォルダとファイルのアクセス許可の共有ホストアドバイス も参照してください。

  2. 低セキュリティ環境でのテスト、コードレビュー、テストなどの品質管理手順を実装します。

  3. Webアプリケーション/ Webサイトの脆弱性を、少なくとも1回はプロの認定テスターでテストしてください。 EC-Council、ISO 27001、およびPCI認定テスターを探します。 http://www.eccouncil.org/certification/licensed_penetration_tester.aspx

  4. OWASP www.owasp.orgと http://phpsec.org/projects/guide/2.html でWebアプリケーションのセキュリティリソースを確認してください。

  5. 侵入防止システム(IPS)ツールを使用します。ただし、ホスティングプロバイダーによっては、使用できるものに制限がある場合があります。ホストベースIPS専用の仮想マシンがある場合、ツールは問題ありません。

お役に立てば幸いです。それ以外の場合は、実行しているシステムに関する詳細情報を提供できますか?

45
Bernie White

@Dgarciaが言ったように、簡単な方法は、Tripwireまたは他のツールを使用して、ファイルまたはファイルのハッシュを監視し、変更を確認することです。これは、さまざまな種類の攻撃によって侵害されたサーバーを識別するために機能します。

  1. このプロセスに対抗するルートキットがインストールされている場合は機能しない可能性があります。
  2. これは、メモリのみの侵害の被害を受けたサーバーや、監視しているファイルに触れないサーバーでは機能しません。

1の場合、唯一のオプションはゼロからの再構築です

2の場合、最善のオプションはゼロから再構築することです。妥協するとバックドアが実装され、修正しようとするすべてのものが壊れる可能性がありますが、他の手順が役立つ場合があります。

  • ウェブサーバーとphpのバージョンを確認し、これらを使用してアドバイザリリストで既知のエクスプロイトを検索します。これは、侵害された可能性のある領域を特定するのに役立ちます。その後
  • webアプリケーションコードを確認する
  • ウェブサーバーの設定を確認してください
  • クライアントのマシン(hostsファイル、DNSなど)を確認します。実際に問題がある可能性があります。
7
Rory Alsop

これは非常に広いので、答えるのが難しい質問です。私の本の「ハッキング」には、マイナーと深刻の2つのカテゴリーがあります。ルートキットを深刻なカテゴリに分類し、平均的なスクリプトインジェクション攻撃をマイナーとして分類します。マイナーな攻撃ではそれらをクリーンアップできますが、それらを削除したり、すべてのアクセスを閉じて攻撃を繰り返したりしたことを100%確実にすることはできませんが、「この人は良いプログラマでしたか?」そして「その人の意図は何でしたか?」ルートキットは厄介なビジネスです。ルートキットを削除するには、完全なワイプと復元が必要です。 1つをリモートで検出することはほぼ不可能です。確実にするには、マシンとブートディスクに物理的にアクセスできる必要があります。

さらに重要なのは予防です。 「1オンスの予防は1ポンドの治療に値する」という格言は、この文脈では完全に真実です。システムのさまざまな側面を監視し、毎日または毎時間のレポートを送信できるソフトウェアをインストールします。 Tripwireについて言及しましたが、他にもツールがあります。私はいくつかの異なるツールを使用することをお勧めします-自家製のツールは見つけるのが難しく、オーサリングが難しくありません。強固な防御を構築し、システムへのアクセスを制限したい。世界中の誰もがSSHポートにアクセスできるようにしないでください(少なくとも、IPアドレス/小さなIP範囲で制限します)。専用のファイアウォールを各サーバーの前に貼り付けて、保護の層を追加します。箱自体を唯一の防御線にしたくはありません。 SSH/SSLを介してサーバーで重要なデータのみを管理するため、すべてが暗号化され、のぞき見から解放されます。オープンなWiFiネットワークからサーバーを管理しないでください。

多くのサイトがMySQLまたは同様のデータベースを使用しています。スキーマに依存する問題があるため、データベース内のXSS攻撃やその他の不正なデータなどを検出することは簡単ではありません。私はこの問題の解決策を見たことがありませんが、それらが存在することに疑いはありません。

6
Linders

高速な方法は、正常であることがわかっているすべてのファイルのmd5を持つことです。サイトの動作に問題があると思われる場合、または定期的な検査として、ファイルをチェックできます。 md5のいずれかが一致しない場合は、ファイルを比較して変更を熟読できます。

明らかに、これは動的ファイル(ログ、データベースダンプなど)では機能しません。変更を追跡できない場合。

もちろん、複数の方法(ログの検査...)と防止策がありますが、これは簡単で高速な方法です。

2
dgarcia