侵害されたサーバーに対処するにはどうすればよいですか？
私のサーバーの1つ以上が、ハッカー、ウイルス、またはその他のメカニズムによって侵害されていると思います。
- 私の最初のステップは何ですか？サイトに到着したとき、サーバーを切断し、「証拠」を保持する必要があります。他に初期の考慮事項はありますか？
- サービスをオンラインに戻すにはどうすればよいですか？
- 同じことがすぐに再発しないようにするにはどうすればよいですか？
- この事件から学ぶためのベストプラクティスまたは方法論はありますか？
- インシデント対応計画をまとめたい場合、どこから始めればよいですか？これは私の災害復旧または事業継続計画の一部にする必要がありますか？
これは、このトピックの正規の投稿であることを意味します。 元はserverfaultから 。
元々はserverfaultから。Thanks to Robert Moir（RobM）
ここに投稿した内容から具体的なアドバイスをするのは難しいですが、私が何年も前に書いたブログにまだ悩まされていたときに基づいた一般的なアドバイスがあります。
パニックにならないでください
まず最初に、侵入前に作成されたバックアップからシステムを復元する以外に「迅速な修正」はなく、これには少なくとも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つの「災害シナリオ」であり、通常の「サーバールームが発火した」/「ファービーを食べている巨大なサーバー」のようなものとは異なる独自の一連の問題と問題があるものです。
...そして最後に
私はおそらく他の人が重要だと考えることの終わりを省いていませんが、ハッカーの犠牲になるほど運が悪い場合は、上記の手順で少なくとも問題の整理に役立つはずです。
何よりも：パニックに陥らないでください。行動する前に考えてください。決定したらしっかりと行動し、私のステップリストに追加するものがあれば、以下にコメントを残してください。
Linuxでファイルを「削除不可」にするには、attributes、具体的には「不変」属性を使用します。属性を確認するには lsattr を、属性を変更するには chattr を参照してください。
ただし、これは根本的な原因にのみ答えます。 重要なことは、あなたのマシンが敵意のある制御を受け、ハイジャッカーが自分の不正な目的のために物事をインストールしたことです。特に、あなたがしようとしているようなクレンジングの試みにもかかわらずエントリを開いたままにするために、彼はおそらく rootkit をインストールしました。ルートキットは、マシン自体からは見えない方法でカーネルやシステムバイナリを変更している可能性があります。要するに、あなたのマシンは保存できないということです; 確実にマシンを再びきれいにして、ディスクを再フォーマットして最初から再インストールすることで節約する方法はありません。
将来の心配や頭痛から身を守ってください。 システムを軌道からnuke 。
ServerFaultからのクロスポストへの返信で言ったように。それは良い説明です。また、攻撃の種類によっても異なります。うまくいけば、または残念ながら、この攻撃は騒々しいので、進行中の攻撃として認識しました。または、攻撃の初期段階であることが合理的に確実である場合、この操作の順序は従うべき良い青写真と言えます。
しかし、あなたが知っている妥協の兆候が感染の全体像を描いていない可能性があり、その程度を理解するまでPCを切断することはあなたの最善の利益にならないかもしれません、私はそれを見つける方が良いかもしれないと主張しますエントリポイントと、影響を受けるシステム/デバイスをネットワークから削除する前に制御できないシステム。
問題の真実は、それらのアクターがあなたのシステムにあなたが思ったよりも長く存在していて、あまりに早く手を見せた（つまり、私があなたが私のシステムに座っていることに気付いた）ことで、根絶するのがはるかに困難になる可能性があります。
簡単な答えはありませんが、RobMが提供する答えは、十分な出発点です。すべてのプレッシャーにより、複数の正しい答えがあり、間違った答えになることもあります。不確実性の原則が適用されるのとほぼ同じように、試してみるまで、答えが正確かどうかはわかりません。
また、 （PDF）NIST Computer Security Incident Handling Guide も確認する必要があります。
この方法論は実際のシナリオとまったく同じですが、以下の方法が考えられます。
•私の最初のステップは何ですか？サイトに到着したときに、サーバーを切断し、「証拠」を保持する必要があります。他に初期の考慮事項はありますか？
Ans：もちろん、サーバーをネットワークから切断する必要がありますが、サーバーの電源を切ったりシャットダウンしたりしないでください。状況、インシデントの影響、および証拠（サーバーをシャットダウンすると、メモリ上のデータが消去される場合があります）。
危機管理とコミュニケーション–危機管理とDR/BCPポリシーがある場合は、前述の手順に従います。これもシナリオの影響を受けます。この場合、これはウイルスの増殖である可能性があるため、プロセスに従う必要がある場合があります。
•サービスをオンラインに戻すにはどうすればよいですか？
Ans：上記のように、危機管理/ DR/BCPの指示に従ってください。これは状況によって異なります。
たとえば、このウイルスが時限爆弾であるか、サーバーで何らかのアクションとランサムウェア攻撃によってトリガーされた場合、DRをすぐに立ち上げないことをお勧めします（これにより、DRサーバーから別のマルウェアの拡散がトリガーされる可能性があります）。最善の方法は、ネットワークへのインシデントの影響を評価し、サービスを回復するために必要なアクションを実行することです。
•同じことがすぐに再発しないようにするにはどうすればよいですか？
Ans：同じインシデントの再発を防ぐために、インシデントの根本原因をできるだけ早く特定する必要があります。上記の回答で示したように、ランサムウェアのシナリオでは、マルウェアがDR /バックアップに伝播されないようにする必要がある場合があります。
ネットワークの脆弱性が原因でインシデントが発生した場合（たとえば、ファイアウォールポートが誤って開かれ、攻撃がこのポートを介して行われた場合）、インシデントの再発を回避するために、既知の/識別された脆弱性を閉じるために直ちに対処する必要があります。
•このインシデントから学ぶためのベストプラクティスまたは方法論はありますか？
Ans：はい、すべての事件は本質的にユニークである可能性があります。したがって、危機管理/ DR/BCP手順を更新して、そのようなインシデントの学習を反映させます。
そのようなインシデントの回避/早期検出のために、予防的モニタリング/インシデント識別を実施することが常に推奨されます。たとえば、SOC（セキュリティオペレーションセンター）またはSIEM（セキュリティインシデントイベント管理）ツールを展開できます。
•インシデント対応計画をまとめたい場合、どこから始めればよいですか？これは、災害復旧または事業継続計画の一部にする必要がありますか？
Ans：これはBCP/DR計画の一部であり、通常は危機管理（BCP計画の一部）でカバーされている必要があります。
すべてをバックアップします。サンドボックスタイプの環境でフォレンジックを実行できるようにします。
次に、0から開始します-はい、NOTHINGから。
新しいO/S-完全にパッチされています。アプリケーション-バックアップからの最新のデータファイル....（可能であれば、侵害される前）。そうでない場合は、コンテンツと権限をすべてスキャンする必要があります。
次に、ハッカーがどのように侵入したかを徹底的に見直し、それが再び発生しないことを確認します。
何が起こったのかを見つけたら、それが再び起こらないように対策を講じ、発見した内容を（内部的および/または外部的に）公開します（対策は省略できます）。
これから学ばない限り-あなたは再び同じ運命に苦しむでしょう。