侵害されたサーバーに対処するにはどうすればよいですか？
これは 正規の質問 サーバーセキュリティについて-違反イベントへの応答（ハッキング）
関連項目：
正規バージョン
ハッカー、ウイルス、またはその他のメカニズムによって1つ以上のサーバーが危険にさらされていると思います。
- 私の最初のステップは何ですか？サイトに到着したとき、サーバーを切断し、「証拠」を保持する必要がありますが、他に最初の考慮事項はありますか？
- サービスをオンラインに戻すにはどうすればよいですか？
- 同じことがすぐに再発しないようにするにはどうすればよいですか？
- この事件から学ぶためのベストプラクティスまたは方法論はありますか？
- インシデント対応計画をまとめたい場合、どこから始めればよいですか？これは私の災害復旧または事業継続計画の一部にする必要がありますか？
オリジナルバージョン
2011.01.02-午後9時30分に仕事に向かっています。私たちのサーバーがなんらかの危険にさらされて、プロバイダーへの [〜＃〜] dos [〜＃〜] 攻撃を引き起こしたため、日曜日に。インターネットへのサーバーアクセスがシャットダウンされました。つまり、5〜600以上のクライアントサイトがダウンしています。これは、FTPハック、またはコードのどこかの弱点である可能性があります。そこに着くまではわからない。
これをすばやく追跡するにはどうすればよいですか？サーバーをできるだけ早くバックアップしないと、私たちは多くの訴訟に巻き込まれます。どんな助けでもありがたいです。 Open SUSE 11.0を実行しています。
2011.01.03-皆様のご協力に感謝いたします。幸い、私はこのサーバーを担当する唯一の人物ではありませんでした。この問題はなんとか解決しましたが、状況によっては他の多くの問題には当てはまらない場合があります。私たちがしたことを詳しく説明します。
サーバーをネットから外しました。インドネシアの別のサーバーでサービス拒否攻撃を実行（実行しようとして）ており、有罪者もそこに拠点を置いていました。
私たちは最初に、これがサーバーのどこから来ているのかを特定しようとしました。サーバーに500を超えるサイトがあることを考えると、しばらくの間、月明かりが当たると予想しました。ただし、SSHアクセスがまだあるため、攻撃が開始されたときに編集または作成されたすべてのファイルを見つけるコマンドを実行しました。幸いなことに、問題のファイルは冬の休暇中に作成されたため、その時点ではサーバー上に他の多くのファイルが作成されていませんでした。
次に、 ZenCart Webサイト内のアップロードされた画像フォルダー内にある問題のファイルを特定できました。
短いタバコの休憩の後、ファイルの場所が原因で、安全に保護されたファイルアップロード機能を介してアップロードされたに違いないと結論付けました。少し調べたところ、ZenCart管理パネル内で、レコード会社の写真のファイルをアップロードできるというセキュリティの脆弱性があることがわかりました。 （実際には使用されなかったセクション）、このフォームを投稿すると、ファイルがアップロードされただけで、ファイルの拡張子はチェックされず、ユーザーがログインしているかどうかもチェックされませんでした。
これは、PHP攻撃用のファイルを含む）すべてのファイルをアップロードできることを意味しました。感染サイトのZenCartで脆弱性を保護し、問題のファイルを削除しました。
仕事は終わり、私は午前2時に家にいた。
The Moral-ZenCart、またはその他のCMSシステムには常にセキュリティパッチを適用してください。セキュリティアップデートがリリースされたときと同様に、全世界がこの脆弱性を認識しています。 -常にバックアップを実行し、バックアップをバックアップします。 -このような時にそこにいる誰かを雇うか、手配する。誰もがサーバー障害に関するパニックのある投稿に依存しないようにするため。
ここに投稿した内容から具体的なアドバイスをするのは難しいですが、私が何年も前に書いたブログにまだ悩まされていたときに基づいた一般的なアドバイスがあります。
パニックにならないでください
まず最初に、侵入前に作成されたバックアップからシステムを復元する以外に「迅速な修正」はなく、これには少なくとも2つの問題があります。
- 侵入がいつ発生したかを特定することは困難です。
- 彼らが最後に侵入することを可能にした「穴」を閉じるのを助けたり、また起こったかもしれない「データ盗難」の結果に対処したりしません。
この質問は、ハッカーがWebサーバーに侵入した被害者から繰り返し尋ねられます。答えが変わることはめったにありませんが、人々は質問をし続けます。理由はわかりません。おそらく、人々はヘルプを検索したときに見た答えが気に入らない、またはアドバイスを提供するために信頼できる誰かを見つけることができないだけかもしれません。あるいは、この質問への回答を読んで、ケースが特別で、オンラインで見つけられる回答とは異なる5％の理由に過度に集中しすぎて、ケースが十分に近い場合、質問と回答の95％を見逃しているのかもしれません。彼らがオンラインで読むものとして。
これにより、最初の重要な情報が表示されます。私はあなたが特別なユニークなスノーフレークであることを本当に感謝しています。あなたのウェブサイトもあなたとあなたのビジネスを反映したものであることを感謝します。少なくとも、雇用主のためにあなたの努力が反映されています。しかし、問題を調べてあなたを助けようとしているコンピュータセキュリティ担当者であれ、攻撃者自身であれ、外を見ている人にとっては、問題は他のすべてのケースと少なくとも95％同一である可能性が非常に高いです。今まで見た。
個人的に攻撃を行わないでください。また、ここに続く推奨事項や、他の人から個人的に得た推奨事項を取り入れないでください。あなたがウェブサイトのハックの犠牲者になった後にこれを読んでいるなら、私は本当に申し訳ありません、そしてあなたがここで何か役立つものを見つけられることを本当に望みますが、あなたのエゴがあなたが必要とするものに邪魔をする時ではありません行う。
サーバーがハッキングされたことがわかりました。今はどうですか？
パニックにならない。絶対に急いで行動しないでください。絶対に、起こったことのないふりをしたり、行動したりしないでください。
まず、災害がすでに発生していることを理解してください。これは拒否の時ではありません。何が起こったかを受け入れ、それについて現実的になり、影響の結果を管理するための対策を講じるときです。
これらの手順の一部は害を及ぼす可能性があり、（ウェブサイトに私の詳細のコピーが保存されていない限り）これらの手順のすべてまたは一部を無視してもかまいませんが、それはあなた次第です。しかし、それらを正しくフォローすることは、結局物事をより良くするでしょう。薬はひどい味がするかもしれませんが、本当に治療法を機能させたい場合は、それを見落とさなければならないことがあります。
問題がすでにあるよりも悪化するのを防ぐ：
- 最初にすべきことは、影響を受けるシステムをインターネットから切断することです。他にどんな問題があったとしても、システムをWebに接続したままにしておくと、攻撃を続けることしかできません。これは文字通りかなりの意味です。それが必要な場合は、誰かが物理的にサーバーにアクセスしてネットワークケーブルを取り外しますが、他のことをする前に被害者を強盗から切り離してください。
- 侵入先のシステムと同じネットワーク上にあるすべてのコンピューターのすべてのアカウントのすべてのパスワードを変更します。いえいえ。すべてのアカウント。すべてのコンピューター。はい、そうです、これはやり過ぎかもしれません。一方、そうでない場合もあります。どちらかわからないよね？
- 他のシステムを確認してください。他のインターネット向けサービス、および財務データやその他の商業的に機密データを保持するサービスには特に注意してください。
- システムが誰かの個人データを保持している場合は、データ保護の責任者に通知し（それがあなたでない場合）、完全な開示を要請します。これはタフだと思う。これが痛いのは知っています。多くの企業がカーペットの下でこの種の問題を一掃することを望んでいることを知っていますが、企業はそれに対処する必要があり、あらゆる関連するプライバシー法に注意して対処する必要があります。
ただし、問題について顧客に説明してもらうように顧客を苛立たせても、顧客に知らせなければはるかに苛立ち、誰かがクレジットカードの詳細を使用して8,000ドル相当の商品を請求した後でないと、顧客は気付かないでしょう。あなたのサイトから盗みました。
以前に言ったことを覚えていますか？悪いことはすでに起こっています。唯一の問題は、あなたがそれにどれだけうまく対処するかです。
問題を完全に理解する：
- この段階を完全に完了するまで、影響を受けるシステムをオンラインに戻さないでください。ただし、実際にこの記事の執筆を決定する際の転機となった投稿者になりたい場合を除きます。人々が安っぽく笑うことができるようにその投稿にリンクするつもりはありませんが、本当の悲劇は人々が過ちから学ぶことができないときです。
- 「攻撃された」システムを調べて、どのようにして攻撃がセキュリティの侵害に成功したかを理解します。攻撃が「どこから来たのか」を見つけるためにあらゆる努力を払ってください。そうすることで、将来どのようにシステムを安全にするためにどのような問題があり、対処する必要があるかを理解できます。
- 今度は「攻撃された」システムを調べて、攻撃がどこに行ったかを理解し、どのシステムが攻撃で侵害されたかを理解します。侵害されたシステムがシステムをさらに攻撃するための踏み台になる可能性があることを示唆するすべての指針を確実にフォローアップしてください。
- すべての攻撃で使用されている「ゲートウェイ」が完全に理解されていることを確認してください。これにより、攻撃を適切に閉じ始めることができます。 （たとえば、システムがSQLインジェクション攻撃によって侵害された場合、システムが侵入した特定の欠陥のあるコード行を閉じる必要があるだけでなく、すべてのコードを監査して、同じタイプの間違いがないかどうかを確認する必要があります。別の場所で作成されました）。
- 複数の欠陥が原因で攻撃が成功する可能性があることを理解してください。多くの場合、攻撃は、システム内の1つの主要なバグを見つけることではなく、いくつかの問題（時にはそれ自体が軽微で些細なこと）を組み合わせてシステムを危険にさらすことで成功します。たとえば、SQLインジェクション攻撃を使用してコマンドをデータベースサーバーに送信し、攻撃しているWebサイト/アプリケーションが管理ユーザーのコンテキストで実行されていることを発見し、そのアカウントの権限を踏み台として他の部分を危険にさらしています。システム。または、ハッカーがそれを好むように、「人々が犯す一般的な間違いを利用するオフィスのある日」です。
検出したエクスプロイトまたはルートキットを「修復」してシステムをオンラインに戻すだけではないのですか？
このような状況で問題となるのは、そのシステムをもう制御できないことです。それはもはやあなたのコンピュータではありません。
システムを制御していることを確実にする唯一の方法は、システムを再構築することです。システムに侵入するために使用されたエクスプロイトを見つけて修正することには多くの価値がありますが、侵入者が制御を獲得すると、システムに他に何が行われたか確信が持てません（確かに、リクルートするハッカーにとって前例はありません）システムをボットネットに組み込み、自分たちが使用したエクスプロイトにパッチを適用し、他のハッカーから「彼らの」新しいコンピュータを保護し、ルートキットをインストールします）。
復旧の計画を立て、ウェブサイトをオンラインに戻し、それに固執する：
誰もが必要以上にオフラインになることを望んでいません。それは当然です。このWebサイトが収益を生み出すメカニズムである場合、すぐにオンラインに戻すというプレッシャーが強くなります。唯一の問題があなた/あなたの会社の評判であるとしても、これはまだ物事を迅速に回復させるために多くのプレッシャーを生み出しています。
ただし、あまりにも早くオンラインに戻りたいという誘惑に負けないでください。代わりに、できるだけ早く移動して問題の原因を理解し、オンラインに戻る前に問題を解決してください。そうしないと、ほぼ間違いなくもう一度侵入の被害に遭い、「一度ハッキングされることは不幸に分類される可能性があります。すぐに再びハッキングされるのは不注意のように見えます」（オスカーワイルドへの謝罪）。
- このセクションを始める前に、侵入の成功につながったすべての問題を最初から理解していると思います。私はケースを誇張したくありませんが、あなたがそれを最初にしていないなら、あなたは本当にする必要があります。ごめんなさい。
- 恐喝/保護金を支払うことはありません。これは簡単なマークのしるしであり、あなたがそのフレーズを使って自分を説明することは望ましくありません。
- 完全に再構築せずに同じサーバーをオンラインに戻そうとしないでください。古いハードウェアで新しいボックスを構築したり、サーバーを軌道から取り出してクリーンインストールしたりすることは、元のシステムの隅々まで監査して元に戻す前にクリーンであることを確認するよりもはるかに速いはずです。再びオンライン。これに同意しない場合は、システムが完全にクリーンアップされていることを確認することが実際に何を意味するのかわからないか、Webサイトの展開手順が厄介な混乱です。おそらく、ライブサイトの構築に使用できるバックアップとテスト展開がサイトにあり、ハッキングされていない場合は最大の問題ではありません。
- ハッキング時にシステムで「ライブ」であったデータを再利用する場合は、十分に注意してください。あなたは私を無視するだけなので「絶対にしない」とは言いませんが、率直に言って、整合性を保証できないことがわかっている場合は、データを保持することの影響を考慮する必要があると思います。理想的には、侵入前に作成したバックアップからこれを復元する必要があります。それができない、またはできない場合は、データが汚染されているため、そのデータには細心の注意を払う必要があります。このデータが直接ではなく顧客またはサイトの訪問者に属している場合は、他人への影響に特に注意する必要があります。
- システムを注意深く監視します。将来的には継続的なプロセスとしてこれを行うように解決する必要があります（下記を参照）。ただし、サイトがオンラインに戻った直後の期間は、特に注意を払う必要があります。侵入者はほぼ確実に戻ってきます。侵入者が再び侵入しようとしていることに気付いた場合は、以前に使用したすべての穴に加えて、自分自身のために作成した穴を本当に閉じているかどうかをすばやく確認でき、役立つ情報を収集できます。地元の法執行機関に渡すことができる情報。
将来のリスクを軽減します。
最初に理解する必要があるのは、セキュリティは、インターネットに面するシステムの設計、展開、および保守のライフサイクル全体にわたって適用する必要があるプロセスであり、後で安価なようにコードにいくつかのレイヤーを重ねることはできないということです。ペイント。適切に安全であるためには、サービスとアプリケーションを最初からこれをプロジェクトの主要な目標の1つとして念頭に置いて設計する必要があります。退屈だし、聞いたことがあるだろうし、ベータ版のWeb2.0（ベータ版）サービスをウェブ上でベータ版のステータスにするという「プレッシャーマンに気づかない」と私は思うが、これは事実です。それが最初に言われたときに真実であり、それがまだ嘘になっていないので、繰り返されます。
リスクを排除することはできません。あなたもそれをしようとするべきではありません。ただし、すべきことは、どのセキュリティリスクが自分にとって重要であるかを理解し、リスクの影響とリスクが発生する確率の両方を管理および削減する方法を理解することです。
攻撃が成功する可能性を減らすためにどのような手順を実行できますか？
例えば：
- 人々があなたのサイトに侵入することを可能にする欠陥は、パッチが利用可能なベンダーコードの既知のバグでしたか？もしそうなら、あなたはあなたのインターネットに面したサーバー上のアプリケーションにパッチを当てる方法へのアプローチを再考する必要がありますか？
- 人々があなたのサイトに侵入することを可能にする欠陥は、パッチが入手できないベンダーコードの未知のバグでしたか？私は、このような何かがあなたに噛み付くときはいつでも、サプライヤーを変えることを推奨しません。なぜなら、それらすべてに問題があり、このアプローチをとれば、せいぜい1年でプラットフォームが足りなくなるからです。ただし、システムが常にダウンしている場合は、より堅牢なものに移行するか、少なくともシステムを再構築して、脆弱なコンポーネントが綿のウールで包まれたまま、敵の目からできるだけ離れているようにします。
- この欠陥は、あなた（またはあなたのために働いている請負業者）が開発したコードのバグですか？もしそうなら、ライブサイトへの展開のためにコードを承認する方法へのアプローチを再考する必要がありますか？改善されたテストシステム、またはコーディングの「標準」の変更によってバグが検出された可能性があります（たとえば、テクノロジーが万能ではない場合でも、十分に文書化されたコーディングテクニックを使用することで、SQLインジェクション攻撃が成功する確率を減らすことができます。 ）。
- この欠陥は、サーバーまたはアプリケーションソフトウェアの展開方法に問題があったためですか？その場合、可能な場合は自動化された手順を使用してサーバーを構築および展開していますか？これらは、すべてのサーバーで一貫した「ベースライン」状態を維持し、各サーバーで実行する必要のあるカスタム作業の量を最小限に抑え、したがって、間違いを犯す機会を最小限に抑えるのに非常に役立ちます。同じことがコードの展開にも当てはまります。Webアプリの最新バージョンを展開するために何か特別なことをする必要がある場合は、自動化して、常に一貫した方法で実行されるようにしてください。
- システムの監視を改善することで、侵入を早期に発見できましたか？もちろん、24時間監視またはスタッフの「オンコール」システムは費用対効果が高くない場合がありますが、Webに面したサービスを監視して問題が発生した場合に警告できる会社は世界中にあります。あなたはこれを買う余裕がないかそれを必要としないと決めるかもしれません、そしてそれは大丈夫です...ただそれを考慮に入れてください。
- 必要に応じてtripwireやnessusなどのツールを使用します。時間をかけて、環境に適したいくつかの優れたセキュリティツールの使用方法を学び、これらのツールを最新の状態に保ち、定期的に使用してください。
- セキュリティの専門家を雇って、Webサイトのセキュリティを定期的に「監査」することを検討してください。繰り返しますが、これを買う余裕がない、または必要がないと判断するかもしれませんが、それで十分です。
攻撃が成功した場合の影響を減らすために、どのような手順を実行できますか？
家の洪水の下層階の「リスク」が高いと判断したが、移動が必要なほど高くない場合は、少なくともかけがえのない家族の家宝を2階に移動する必要があります。正しい？
- インターネットに直接公開されるサービスの量を減らすことはできますか？内部サービスとインターネット向けサービスの間に何らかのギャップを維持できますか？これにより、外部システムが危険にさらされている場合でも、これを踏み台として使用して内部システムを攻撃する可能性が制限されます。
- 保存する必要のない情報を保存していますか？そのような情報を他の場所にアーカイブできるときに「オンライン」で保存していますか。この部分には2つのポイントがあります。明らかなのは、あなたが持っていない情報を他人が盗むことができないことです。2番目のポイントは、保存が少ないほど、保守とコーディングの必要性が少なくなるため、バグが侵入する可能性が少なくなります。コードまたはシステム設計。
- Webアプリに「最小アクセス」の原則を使用していますか？ユーザーがデータベースから読み取るだけでよい場合は、Webアプリがこれをサービスするために使用するアカウントに読み取りアクセスのみが許可されていることを確認し、書き込みアクセスは許可せず、システムレベルのアクセスは許可しないでください。
- 何かにあまり経験がなく、それがビジネスの中心ではない場合は、アウトソーシングを検討してください。言い換えれば、デスクトップアプリケーションコードの記述について話している小さなWebサイトを運営していて、サイトから小さなデスクトップアプリケーションの販売を開始する場合は、クレジットカード注文システムをPaypalなどの誰かに「アウトソーシング」することを検討してください。
- 可能な場合は、侵害されたシステムからの回復を実践することを障害回復計画の一部にします。これはおそらく、遭遇する可能性のあるもう1つの「災害シナリオ」であり、通常の「サーバールームが発火した」/「ファービーを食べている巨大なサーバー」のようなものとは異なる独自の一連の問題と問題があるものです。
...そして最後に
私はおそらく他の人が重要だと考えることの終わりを省いていませんが、ハッカーの犠牲になるほど運が悪い場合は、上記の手順で少なくとも問題の整理に役立つはずです。
何よりも：パニックに陥らないでください。行動する前に考えてください。決定したらしっかりと行動し、私のステップリストに追加するものがあれば、以下にコメントを残してください。
少し頭上にいるようです。それで大丈夫です。上司に電話して、緊急のセキュリティ対応予算について交渉を始めます。 10,000ドルから始めるのがよいでしょう。次に、セキュリティインシデントレスポンスに特化した会社に電話をかけるために誰か（PFY、同僚、マネージャー）を雇う必要があります。多くの人は24時間以内に応答できますが、都市にオフィスがある場合はさらに速くなることがあります。
また、顧客のトリアージを行う誰かが必要です。間違いなく、誰かがすでにそうです。何が起こっているのか、状況を処理するために何が行われているのかを説明し、質問に答えるために、誰かが彼らと電話をする必要があります。
次に、する必要があります...
落ち着いて。インシデント対応を担当している場合、今やるべきことは最大限の専門性とリーダーシップを示す必要があります。あなたが行うすべてのことを文書化し、マネージャーと経営陣にあなたが取った主な行動について知らせておきましょう。これには、対応チームとの連携、サーバーの無効化、データのバックアップ、および物事を再びオンラインにすることが含まれます。細かいことは必要ありませんが、30分ごとに連絡があります。
現実的になる。あなたはセキュリティの専門家ではないので、知らないことがあります。それで大丈夫です。サーバーにログインしてデータを見るときは、自分の限界を理解する必要があります。軽く踏みます。調査の過程で、重要な情報に踏み込んだり、後で必要になる可能性があるものを変更したりしないでください。不快に感じる場合や推測している場合は、立ち寄って経験豊富な専門家に引き継ぐのに適した場所です。
クリーンなUSBスティックと予備のハードドライブを入手します。ここで証拠を収集します。関連があると思われるすべてのもののバックアップを作成します。 ISPとの通信、ネットワークダンプなど。法執行機関が関与していなくても、訴訟の場合は、この証拠により、会社が専門的かつ適切な方法でセキュリティインシデントを処理したことを証明する必要があります。
最も重要なのは損失を止めることです。侵害されたサービス、データ、マシンへのアクセスを特定して遮断します。できれば、ネットワークケーブルを引っ張ってください。できない場合は、電源を入れます。
次に、攻撃者を削除して穴を閉じる必要があります。おそらく、あなたがネットワークをプルしたため、攻撃者はもはやインタラクティブなアクセスができません。次に、特定し、文書化して（バックアップ、スクリーンショット、独自の個人的な観察メモを使用して、またはできれば影響を受けるサーバーからドライブを削除し、完全なディスクイメージコピーを作成して）、彼が残したコードとプロセスをすべて削除する必要があります。 。バックアップがないと、この次の部分は面倒です。手でシステムから攻撃者のもつれを解こうとすることはできますが、彼が置き去りにしたものすべてを手に入れたことを確信することはできません。ルートキットは悪質で、すべてが検出できるわけではありません。最善の対応は、彼が侵入に使用した脆弱性を特定し、影響を受けるディスクのイメージコピーを作成し、影響を受けるシステムをワイプして、既知の適切なバックアップからリロードすることです。バックアップを盲目的に信頼しないでください。確認してください！新しいホストが再びネットワークに接続する前に脆弱性を修復またはクローズしてから、オンラインにします。
すべてのデータをレポートに整理します。この時点で脆弱性は閉じられ、少し時間を割くことができます。このステップをスキップするように誘惑されないでください。プロセスの残りの部分よりもさらに重要です。レポートでは、問題の原因、チームの対応、このインシデントの再発を防ぐための手順を特定する必要があります。できるだけ詳しく説明してください。これはあなたのためだけでなく、あなたの経営陣のために、そして潜在的な訴訟の防御としてです。
これは、何をすべきかを非常に高く評価したものです。ほとんどの作業は、単にドキュメントとバックアップの処理です。慌てないでください、あなたはそれをすることができます。私強く専門のセキュリティヘルプを受けることをお勧めします。あなたが起こっていることを処理することができたとしても、彼らの助けは非常に貴重であり、彼らは通常、プロセスをより簡単かつより速くするための機器が付属しています。あなたの上司が犠牲を払うなら、訴訟を処理することと比較すると、それは非常に小さいことを彼に思い出させてください。
あなたはあなたの状況に私の慰めを持っています。幸運を。
CERTには文書 NIXまたはNTシステムの侵害からの回復手順 が適切です。このドキュメントの特定の技術的な詳細はやや古くなっていますが、一般的なアドバイスの多くはまだ直接適用されます。
基本的なステップの簡単な要約はこれです。
- セキュリティポリシーまたは管理者に相談してください。
- コントロールを取得する（コンピューターをオフラインにする）
- 侵入の分析、ログの取得、問題の原因の特定
- 修復物
- クリーンバージョンのオペレーティングシステムをインストールします!!!システムが危険にさらされている場合、それを信頼することはできません。
- システムを更新して、これが二度と起こらないようにする
- 操作を再開する
- 将来のポリシーとドキュメントを更新する
特にセクションE.1を示したいと思います。
E.1。マシンが侵害された場合、カーネル、バイナリ、データファイル、実行中のプロセス、メモリなど、そのシステム上のあらゆるものが変更されている可能性があることに注意してください。一般に、マシンにバックドアや侵入者の変更がないことを信頼する唯一の方法は、オペレーティングシステムを再インストールすることです
Tripwireのようなシステムがまだ設置されていない場合、システムをクリーンアップしたことを100％確信する方法はありません。
- 特定問題。ログを読みます。
- 含む。サーバーを切断したので、完了です。
- 根絶。ほとんどの場合、影響を受けるシステムを再インストールします。ただし、ハッキングされたハードドライブを消去せず、新しいハードドライブを使用してください。それはより安全であり、バックアップされなかった醜いハックを回復し、何が起こったかを調べるために科学捜査を行うには、古いものが必要になる場合があります。
- 回復。必要なものをインストールし、バックアップを回復してクライアントをオンラインにします。
- フォローアップ。問題が何であったかを理解し、それが再発しないようにします。
ロバートの「苦い丸薬」の答えはまともですが、完全に一般的です（あなたの質問と同様）。 1台のサーバーと600台のクライアントがある場合、管理上の問題があり、フルタイムのsysadminが緊急に必要であるように聞こえますが、それでも今は役に立ちません。
私はこの状況で少し手を握るホスティング会社を運営しているので、私は多くの危険にさらされたマシンを扱いますが、私たち自身のベストプラクティスも扱います。私たちは常に、侵害されたクライアントが侵害の性質を完全に確信していない限り、再構築するように伝えます。長期的には他に責任のあるルートはありません。
ただし、あなたはほぼ間違いなく、DoS攻撃の発射台、またはIRCバウンサー、または顧客のサイトとデータとはまったく無関係の何かをしたかったスクリプトキディの犠牲者にすぎません。したがって、再構築中の一時的な対策として、ボックスに重いアウトバウンドファイアウォールを導入することを検討してください。すべてのアウトバウンドUDPおよびTCP接続をブロックできれば、サイトの機能に絶対に必要ではありません。 、侵害されたボックスを借用している誰にとっても無用にして、プロバイダーのネットワークへの影響をゼロにすることができます。
このプロセスは、これまでに実行したことがなく、ファイアウォールを考慮したことがない場合は数時間かかる可能性がありますが、攻撃者にアクセスを許可し続けるリスクがある状態でクライアントサービスを復元するのに役立ちますクライアントデータに。 1台のマシンに何百ものクライアントがあるとおっしゃっていますが、クレジットカード番号がいっぱいの600のeコマースシステムではなく、小規模ビジネス向けの小さなパンフレットWebサイトをホストしていると思います。その場合、これは許容できるリスクであり、600のサイトでセキュリティバグを監査するよりも早くシステムをオンラインに戻すbefore何でも戻す。しかし、そこにはどのようなデータがあり、その決定をどの程度快適に行うことができるかがわかります。
これは絶対にベストプラクティスではありませんが、これまで雇用主で起こっていなかった場合は、指を振ってSWATチームに彼らが感じるかもしれない何かのために数万ポンドを要求するのはあなたの責任です（ただし、不当です！ ）は実用的なオプションのようには聞こえません。
ここでのISPのヘルプはかなり重要になります-一部のISP コンソールサーバーとネットワークブート環境を提供します （プラグですが、少なくともどのような種類の機能を探すかを知っています）これにより、サーバーはネットワークから切断されています。これがまったく選択肢である場合は、それを要求して使用します。
しかし、長期的には、Robertの投稿に基づいてシステムの再構築を計画し、各サイトとその設定の監査を計画する必要があります。システム管理者をチームに追加できない場合は、システム管理のヘルプとこの種のことに対する24時間の応答に対してISPに支払う managed hosting 取引を探してください。幸運を ：）
再インストールする必要があります。本当に必要なものを保存します。ただし、実行可能なすべてのファイルが感染して改ざんされる可能性があることに注意してください。私はpythonで次のように書きました： http://frw.se/monty.py これは、指定されたディレクトリにすべてのファイルのMD5サムを作成し、次に実行すると、何かがあるかどうかをチェックします変更された後、どのファイルが変更され、どのファイルが変更されたかを出力します。
これは、奇妙なファイルが定期的に変更されているかどうかを確認するのに便利です。
しかし、今すべきことは、コンピューターをインターネットから削除することだけです。
注：これは推奨事項ではありません。私の特定のインシデントレスポンスプロトコル おそらくしない Grant unwinのケースに変更なしを適用しません。
私たちの学術施設には、計算のみを行う約300人の研究者がいます。あなたはウェブサイトを持つ600のクライアントを持っているので、あなたのプロトコルはおそらく異なるでしょう。
サーバーが危険なプロトコルを取得したときの最初のステップは、
- 攻撃者がroot（昇格された特権）を獲得できたことを識別する
- 影響を受けるサーバーを取り外します。ネットワークまたは電力？ 別の議論 を参照してください。
- 他のすべてのシステムを確認する
- 影響を受けるサーバーをライブCDから起動します。
- （オプション）
ddを使用してすべてのシステムドライブのイメージを取得します 死後の科学捜査を開始します。ログを見て、攻撃の時間を把握し、その時間に変更されたファイルを見つけます。 How？の質問に答えてみてください。
- 並行して、リカバリを計画して実行します。
- サービスを再開する前に、すべてのrootおよびユーザーパスワードをリセットします
「すべてのバックドアとルートキットがクリーンアップされた」としても、そのシステムを信頼せず、ゼロから再インストールしてください。
@Robert Moir、@ Aleksandr Levchuk、@ blueben、および@Matthew Blochはすべて、その回答でかなり注目されています。
ただし、ポスターごとに答えは異なります。一部は高レベルであり、適切な手順（一般）について話し合うものもあります。
私はこれをいくつかの部分に分けたいと思います1）トリアージ、別名どのように顧客と法的影響に対処し、そこからどこへ行くかを特定します（Robertと@bluebenによって非常によくリストされています2）影響の軽減3 ）インシデント対応4）死後の科学捜査5）修復項目とアーキテクチャの変更
（ボイラープレートSANS GSC認定の応答ステートメントをここに挿入）過去の経験に基づいて、次のように言います。
お客様の対応、通知、法的、および将来の計画の処理方法に関係なく、当面の主要な問題に焦点を当てたいと思います。 OPの元の質問は、実際には直接＃2と＃3にのみ関係します。基本的に、攻撃を停止し、顧客を元の状態でできるだけ早くオンラインに戻す方法です。
残りの応答は素晴らしく、特定された多くのベストプラクティスと、それが将来発生するのを防ぐだけでなく、より適切に応答する方法の両方をカバーしています。
それは実際にはOPの予算と、OPが属する業界のセクター、望ましいソリューションが何かなどに依存します。
おそらく、専用のオンサイトSAを雇う必要があります。多分彼らは警備員を必要としています。あるいは、FirehostまたはRackspace Managed、Softlayer、ServePathなどの完全に管理されたソリューションが必要な場合もあります。
それは本当に彼らのビジネスのために何がうまくいくかに依存します。おそらく、彼らのコアコンピテンシーはサーバー管理に含まれておらず、それを開発しようとしても意味がありません。または、多分彼らはすでにかなり技術的な組織であり、適切な採用決定を行い、専任チームをフルタイムで育成することができます。
私の限られた経験では、Linuxでのシステムの侵害は、Windowsでの侵害よりも「包括的」である傾向があります。ルートキットには、マルウェアを隠すためにカスタマイズされたコードでシステムバイナリを置き換えることが含まれている可能性がはるかに高く、カーネルのホットパッチへの障壁は少し低くなっています。さらに、それは多くのマルウェア作成者のホームOSです。一般的なガイダンスは、影響を受けるサーバーを常に最初から再構築することであり、理由のための一般的なガイダンスです。
その子犬をフォーマットします。
しかし、あなたが再構築できない場合（またはそれが必要であるというあなたの激しい主張に対してそれを再構築させない能力）、あなたは何を探しますか？
侵入が発見されてからしばらく前のようで、システムの復元が行われたため、サービスの復元のために侵入者の痕跡が踏みにじられた可能性があります。残念です。
異常なネットワークトラフィックはおそらく最も簡単に見つけることができます。これは、ボックスで何も実行する必要がなく、サーバーが稼働しているときに何でも実行できるためです。もちろん、あなたのネットワーク機器がポートスパニングを許可していると思います。あなたが見つけたものは診断的なものかもしれませんし、そうでないかもしれませんが、少なくともそれは情報です。異常なトラフィックを取得することは、システムが依然として侵害されており、フラット化が必要であることを示す強力な証拠になります。 TPTBに、再フォーマットが本当にダウンタイムの価値があることを納得させるのに十分かもしれません。
失敗した場合は、システムパーティションのddコピーを取り、別のボックスにマウントしてください。侵害されたものと同じパッチレベルのサーバーとコンテンツを比較し始めます。これは何が違って見えるのか（これらのmd5sumsも）を特定するのに役立ち、侵害されたサーバーの見落とされている領域を指し示す可能性があります。これは、ディレクトリとバイナリをふるいにかけることの多くであり、かなり労働集約的です。これは、再フォーマット/再構築よりも労働集約的である可能性があり、実際に本当に必要な再フォーマットを実行することについてTPTBを攻撃するもう1つのことかもしれません。
仕事に取り掛かり、サーバーを確認した後、問題を解決することができました。幸いなことに、問題のファイルは日曜日にシステムにアップロードされましたが、オフィスは閉鎖されており、ログとキャッシュファイルを除いて、ファイルを作成する必要はありません。その日に作成されたファイルを見つけるための簡単なシェルコマンドを使用して、ファイルを見つけました。
問題のファイルはすべて、一部の古いzencartサイトの/ images /フォルダー内にあるようです。管理セクションの画像アップロードセクションに画像をアップロードできない（curlを使用した）セキュリティの脆弱性があったようです。問題のある.phpファイルを削除し、アップロードスクリプトを修正して、画像以外のファイルのアップロードを禁止しました。
振り返ってみると、それは非常に単純であり、私は仕事の途中で私のiPhoneでこの質問をしました。助けてくれてありがとう。
将来この投稿にアクセスする人の参照用。 しない電源プラグを抜くことをお勧めします。
広範な技術的回答に貢献することはほとんどありませんが、次の点にも注意してください。
非技術的なアクション：
社内でインシデントを報告します。
インシデント対応計画をまだ持っていない場合、それはCYAの手法と思われるかもしれませんが、IT部門だけがビジネスへの影響を判断するのに最適な場所ではありません侵害されたサーバーの。
ビジネス要件は、技術的な懸念に勝る場合があります。 「私はあなたにそう言った」と言ってはいけません。ビジネス上の懸念の優先順位が、最初にこの侵害されたサーバーを使用している理由だと言ってはいけません。 （ "アクション後のレポートに残します。"）セキュリティインシデントを隠すことはオプションではありません。
地方自治体への報告
ServerFaultは法的助言の場ではありませんが、これはインシデント対応計画に含める必要があるものです。
一部の地域および/または規制された業界では、セキュリティインシデントを地域の法執行機関、規制機関に報告（特定）するか、影響を受ける顧客/ユーザーに通知することが義務付けられています。
それにもかかわらず、報告するという決定も実際の報告もIT部門だけで行われるわけではありません。経営陣、法務および企業コミュニケーション（マーケティング）部門の関与を期待してください。
あまり期待しないでください。インターネットは国境の意味がほとんどない大きな場所ですが、多くの警察に存在するサイバー犯罪部門はデジタル犯罪を解決しており、裁判に有罪をもたらす可能性があります。
私はそれはすべてこれに要約すると思います：
あなたの仕事を評価するなら、あなたは計画を持っているべきであり、それを定期的に改訂するべきです。
計画に失敗すると失敗する計画であり、それはシステムのセキュリティ以外には真実ではありません。 <編集済み>がファンに当たったときは、対処する準備をしておくとよいでしょう。
ここで適用される別の（やや定番の）発言があります：予防は治療よりも優れています。
ここには、既存のシステムを監査するエキスパートを獲得するためのいくつかの推奨事項があります。これは間違った時に質問をしていると思います。この質問は、システムが導入されたときに尋ねられるべきであり、回答は文書化されていました。また、「どうすれば人々が侵入するのを防ぐことができるのか」という質問ではありません。それは、「なぜ人々が侵入できるのか」ということです。ネットワークの多数のホールの監査は、新しいホールが発見されて悪用されるまで機能します。一方、慎重に振付されたダンスで特定のシステムに特定の方法でのみ応答するようにゼロから設計されたネットワークは、監査のメリットがまったくなく、資金が無駄になります。
システムをインターネットに配置する前に、自問してみてください-これは100％インターネットに面している必要がありますか？そうでない場合は、しないでください。インターネットの表示を決定できるファイアウォールの背後に置くことを検討してください。さらに良いことに、ファイアウォールが（リバースプロキシまたはパススルーフィルターを介して）送信を傍受できる場合は、それを使用して正当なアクションのみを許可することを検討してください。
これは完了しました-どこかにインターネットバンキングセットアップがあり、サーバーのプールから攻撃を誘導するために使用するインターネットに面した負荷分散プロキシがあります。セキュリティの専門家であるマーカス・ラナムは、逆のアプローチを取ることを リバースプロキシを使用して、既知の有効なURLのみを許可し、他のすべてを404サーバーに送信する と確信させました。それは驚くほど時間の試練に耐えました。
デフォルトの許可に基づいたシステムまたはネットワークは、予想していなかった攻撃が発生すると失敗する運命にあります。デフォルトの拒否を使用すると、何を取得し、何を取得しないかをより詳細に制御できます。内部の何も外部から見られないようにするためです。 。
とは言っても、これらすべてに満足する理由はありません。違反後の最初の数時間は、計画を立てておく必要があります。完璧なシステムはなく、人間は間違いを犯します。
最近、ニースのオンラインユーザーが、攻撃者がシステムを侵害する方法を見つけるのに役立ちました。一部のクラッカーは、ファイルの変更時間を偽造することで痕跡を隠そうとします。変更時刻を変更すると、変更時刻が更新されます（ctime）。あなたはstatでctimeを見ることができます。
この1つのライナーは、ctimeでソートされたすべてのファイルをリストします。
find / -type f -print0 | xargs -0 stat --format '%Z :%z %n' | sort -nr > /root/all_files.txt
したがって、侵害の時間を大まかに知っている場合は、どのファイルが変更または作成されたかを確認できます。