ルート侵害後に再インストールしますか?


58

サーバーの侵害に関するこの質問を読んだ後、なぜ人々が検出/クリーンアップツールを使用して、またはシステムを侵害するために使用された穴を修正するだけで、侵害されたシステムを回復できると信じ続けているのか疑問に思い始めました。

ハッカーができるさまざまなルートキットテクノロジーやその他のすべてのことを考えると、ほとんどの専門家は、オペレーティングシステム再インストールすることをお勧めします。

私は、なぜより多くの人々が軌道からシステムを脱いで核兵器にしないのか、より良いアイデアを得たいと思っています。

ここにいくつかのポイントがありますが、私は対処したいと思います。

  • フォーマット/再インストールがシステムをきれいにしない条件はありますか?
  • どのような条件下でシステムをクリーニングできると思いますか?また、いつ完全に再インストールする必要がありますか?
  • 完全な再インストールを行うことに反対する理由は何ですか?
  • 再インストールしないことを選択した場合、どの方法を使用して、クリーンアップを行い、さらなる損傷の再発を防止したと合理的に確信します。

回答:


31

セキュリティ上の決定は、最終的には、どの製品を市場に投入するかに関する決定と同様に、リスクに関するビジネス上の決定です。そのコンテキストでフレーム化する場合、レベリングせずに再インストールするという決定は理にかなっています。厳密に技術的な観点から考えると、そうではありません。

通常、このビジネス上の決定に含まれるものは次のとおりです。

  • ダウンタイムはどれくらいの費用がかかりますか?
  • ダウンした理由を顧客に少し説明しなければならない場合、どれくらいの費用がかかる可能性がありますか?
  • 再インストールを行うために、他のどのようなアクティビティから人々を引き離す必要がありますか?コストは何ですか?
  • エラーなしでシステムを立ち上げる方法を知っている適切な人がいますか?そうでない場合、バグのトラブルシューティングを行う際に費用がかかりますか?

したがって、これらのコストを合計すると、システムを再インストールするよりも、「潜在的に」妥協したシステムを継続する方がよいと見なされる場合があります。


1
いくつかの時間を取って、「上のリチャードBejtlichの優れた記事をお読みください格安ITが最終的に高価であるが、要約すると、」システムがに中断しなければならないときに撮影した生産性のヒット『「原因で、企業内で動作する危険にさらさシステムを残して安価ではありません』セキュリティ分析を有効にします。」
ジョシュブロウワー

2
私はしばらくこれについて考えましたが、侵害される可能性のあるシステムを展開する方が理にかなっている理由を思い付くことができません。
duffbeer703 09年

1
侵害されたことがわかっているシステムも展開したり、オンラインにしたりしたくないでしょう。しかし、これは技術者としての私です。そして、私はこれについてBejtlichに反対します、なぜなら彼は損失防止運動であると言いますが、ビジネスはそれをそのように扱っていないからです。ビジネスはリスクの観点からそれを見ており、当然のことです。たとえば、彼らは訴訟の際に彼らをカバーするために保険に頼ることができ、それは彼らがリスクに対処する方法です。そして、リチャードは彼の議論にこれを考慮しません。私はこの考えに同意するとは言いませんでしたが、それはあなたがそれを理解する方法であり、それがOPが求めていたものです。
K.ブライアンケリー

また、Bejtilichにはある程度異議を唱えますが、少なくともこの議論に別の側面を追加するため、最後のコメントを引用させていただきます。「測定」リスクは冗談です。損失の測定はほとんど不可能です。(競合他社が今後10年間で製品を改善するためにデータを盗むとどれだけ失うかを教えてください)コストを測定することは、会社を出るお金を追跡できるため、信頼できる結果を生み出す可能性が最も高い運動です。この投稿で。損失を測定したいのですが、実際の数値は得られません。リスクの測定は巨大な推測です。」
ジョシュ

...さらに、保険業界全体と民事裁判所システムは、リスクを測定し、損失にドルの数字を乗せることに基づいています。どうやらそのアプローチ担当者に受け入れられるようです。
ブライアンノブラウフ

30

私が何年も書いた投稿に基づいて、私はまだブログに悩まされることができました。

この質問は、ハッカーの被害者がWebサーバーに侵入するたびに繰り返し尋ねられます。答えはめったに変わりませんが、人々は質問をし続けます。理由はわかりません。おそらく、人々はヘルプを検索するときに見た答えが気に入らないか、アドバイスをくれる信頼できる人を見つけることができません。または、おそらくこの質問の回答を読んで、自分のケースが特別な理由の5%に集中しすぎて、オンラインで見つけることができる回答とは異なり、ケースが十分に近い場合に質問と回答の95%を見逃しますオンラインで読むものとして。

それは、情報の最初の重要なナゲットに私をもたらします。あなたが特別なユニークなスノーフレークであることを本当に感謝しています。あなたのウェブサイトもあなたとあなたのビジネスを反映しているか、少なくとも雇用主に代わってあなたの努力を反映していることを感謝しています。しかし、外を見ている誰かにとって、あなたを助けようとするコンピュータセキュリティの人、または攻撃者自身でさえ、あなたの問題は彼らが持っている他のすべてのケースと少なくとも95%同一である可能性が非常に高い今まで見た。

個人的に攻撃を受けないでください。また、ここに続く推奨事項や、他の人から個人的に得た推奨事項を受け入れないでください。あなたがウェブサイトのハックの被害者になった後にこれを読んでいるなら、私は本当に申し訳ありません、そしてあなたがここで役立つ何かを見つけることができることを本当に望みます行う。

サーバーがハッキングされたことがわかりました。それで?

パニックになるな。絶対に急いで行動しないでください。絶対に行動しないで絶対に行動しないでください。

まず、災害がすでに起こっていることを理解してください。これは否定の時ではありません。起こったことを受け入れ、それについて現実的になり、影響の結果を管理するための措置を講じる時です。

これらのステップのいくつかは傷つきます。(あなたのウェブサイトが私の詳細のコピーを保持していない限り)これらのステップの全部または一部を無視してもかまいませんが、そうすることで最終的に物事が良くなります。薬はひどい味がするかもしれませんが、治療法を本当に有効にしたい場合、それを見落とさなければならないことがあります。

問題がそれ以上に悪化するのを防ぎます。

  1. 最初にすべきことは、影響を受けるシステムをインターネットから切断することです。他の問題が何であれ、システムをWebに接続したままにしておくと、攻撃の継続のみが可能になります。これは文字通り非常に意味があります。誰かに物理的にサーバーを訪問してもらい、それが必要な場合はネットワークケーブルを外しますが、他のことを試みる前に被害者を強盗から切り離します。
  2. 侵入先のシステムと同じネットワーク上にあるすべてのコンピューター上のすべてのアカウントのすべてのパスワードを変更します。いやいや。すべてのアカウント。すべてのコンピューター。はい、そうです、これはやり過ぎかもしれません。一方、そうではないかもしれません。あなたはどちらの方法も知らないのですか?
  3. 他のシステムを確認してください。インターネットに面する他のサービスや、金融データやその他の商業上重要なデータを保持するサービスには特に注意してください。
  4. システムが誰かの個人データを保持している場合は、影響を受ける可能性のある人に一度に完全かつ率直に開示します。これは難しいことを知っています。私はこれが傷つくことを知っています。多くの企業がこの種の問題をカーペットの下で解決したいと思っていることは知っていますが、私はあなたがただそれに対処しなければならないのではないかと心配しています。

まだこの最後の一歩を踏み出すのをheしていますか?分かりました しかし、次のように見てください:

一部の場所では、この種のプライバシー侵害の当局および/または被害者に通知する法的要件があります。しかし、あなたの顧客が問題についてあなたに話してもらうのが面倒な場合、あなたが彼らに話さない場合、彼らははるかにイライラし、彼らはクレジットカードの詳細を使用して誰かが8,000ドル相当の商品を請求した後に自分自身を見つけるサイトから盗みました。

以前言ったことを覚えていますか?悪いことはすでに起こっています。現在の唯一の問題は、それをうまく処理することです。

問題を完全に理解します。

  1. この記事が実際にこの記事を書くことを決定する転換点となった人になりたくない限り、この段階が完全に完了するまで、影響を受けるシステムをオンラインに戻さないでください。私はこの投稿にリンクしていないので、人々が安っぽく笑うことができる。この最初のステップに従わなかった場合の結果について警告するためにリンクしています。
  2. 「攻撃された」システムを調べて、攻撃がセキュリティの侵害に成功した方法を理解します。攻撃がどこから来たのかを見つけるためにあらゆる努力を払ってください。そうすれば、あなたが抱えている問題を理解し、将来システムを安全にするために対処する必要があります。
  3. 「攻撃された」システムをもう一度調べて、今回は攻撃がどこに行ったかを理解し、攻撃でどのシステムが侵害されたかを理解します。侵害されたシステムがシステムをさらに攻撃するための踏み台になる可能性があることを示唆するポインターをフォローアップするようにしてください。
  4. すべての攻撃で使用される「ゲートウェイ」が完全に理解されていることを確認してください。そうすれば、それらを適切に閉じ始めることができます。(たとえば、システムがSQLインジェクション攻撃によって侵害された場合、侵入した特定の欠陥のあるコード行を閉じる必要があるだけでなく、すべてのコードを監査して同じタイプの間違いがあるかどうかを確認します他の場所で作成されました)。
  5. 複数の欠陥が原因で攻撃が成功する可能性があることを理解してください。多くの場合、攻撃はシステム内の1つの大きなバグを見つけることではなく、システムを危険にさらすためにいくつかの問題(時にはそれ自体が些細で些細なこと)を結び付けることで成功します。たとえば、SQLインジェクション攻撃を使用してコマンドをデータベースサーバーに送信し、攻撃しているWebサイト/アプリケーションを発見し、管理ユーザーのコンテキストで実行し、そのアカウントの権限を踏み台として使用して、システム。または、ハッカーが「オフィスでのある日、人々が犯すよくある間違いを利用して」と呼ぶのを好むように。

回復のための計画を立て、ウェブサイトをオンラインに戻し、それに固執する:

誰よりも長くオフラインになりたくない。それは当然です。このウェブサイトが収益を生むメカニズムである場合、すぐにオンラインに戻すというプレッシャーが激しくなります。危機にonlyしているのがあなた/あなたの会社の評判だけであるとしても、これは物事をすぐに元に戻すために多くのプレッシャーを生み出しています。

ただし、すぐにオンラインに戻りたいという誘惑に負けないでください。代わりに、できるだけ早く移動して問題の原因を理解し、オンラインに戻る前に解決します。そうしないと、ほぼ確実に再び侵入の犠牲になります。すぐに再びハッキングされるのは不注意に見える」(オスカーワイルドに謝罪)

  1. このセクションを開始する前に、侵入の成功につながったすべての問題を最初から理解していることを前提としています。私はケースを誇張したくはありませんが、もしあなたが最初にそれをしていなければ、本当に必要です。ごめんなさい。
  2. 恐black /保護金を決して支払わないでください。これは簡単な印のしるしであり、あなたがその言葉を使ってあなたを説明するのは望ましくありません。
  3. 完全に再構築せずに同じサーバーをオンラインに戻したいと思わないでください。古いシステムの隅々を監査して元に戻す前にクリーンであることを確認するよりも、古いハードウェアで新しいボックスを構築したり、「軌道からサーバーを破棄してクリーンインストールを行う」方がはるかに高速です。再びオンライン。それに同意しない場合は、おそらく、システムを完全にクリーンにすることの本当の意味がわからないか、Webサイトの展開手順が厄介です。おそらく、ライブサイトの構築に使用できるサイトのバックアップとテスト展開があり、ハッキングされないことが最大の問題ではないでしょう。
  4. ハッキング時にシステム上で「ライブ」であったデータを再利用する場合は、十分に注意してください。あなたはただ私を無視するので「絶対にやらない」とは言いませんが、率直に言って、データの整合性を保証できないとわかったときにデータを保持することの結果を考慮する必要があると思います。理想的には、侵入前に作成されたバックアップからこれを復元する必要があります。それができない、またはできない場合は、そのデータが汚染されているため、そのデータに十分注意する必要があります。このデータが直接あなたではなく顧客またはサイト訪問者に属している場合、他者への結果に特に注意する必要があります。
  5. システムを注意深く監視します。これを将来の進行中のプロセスとして解決する必要があります(以下で詳しく説明します)が、サイトがオンラインに戻った直後の期間中は注意するためにさらに苦労します。侵入者はほぼ確実に戻ってきます。侵入者が再び侵入しようとしているのを見つけることができれば、以前に使用したすべての穴と自分のために作った穴を本当に閉じているかどうかをすぐに確認できます。地元の法執行機関に伝えることができる情報。

将来のリスクを減らす。

最初に理解する必要があることは、セキュリティは、インターネットに面したシステムの設計、展開、保守のライフサイクル全体に適用する必要があるプロセスであり、後でコードのように数層を平手打ちできるものではないことですペイント。適切にセキュリティを確保するには、これをプロジェクトの主要な目標の1つとして念頭に置いて、サービスとアプリケーションを最初から設計する必要があります。私はそれが退屈であり、あなたはそれをすべて聞いたことがあること、そしてあなたはあなたのベータweb2.0(ベータ)サービスをウェブ上でベータステータスにする「プレッシャーマンに気付いていない」ことを知っていますが、事実はこれが続くことですそれが最初に言われたときに真実であり、まだ嘘になっていないので、繰り返されます。

リスクを排除することはできません。あなたもそうしようとするべきではありません。ただし、どのセキュリティリスクが重要であるかを理解し、リスク影響とリスクが発生する可能性の両方を管理および軽減する方法を理解する必要があります。

攻撃が成功する確率を下げるために、どのような手順を踏むことができますか?

例えば:

  1. 人々があなたのサイトに侵入するのを許した欠陥は、パッチが利用可能なベンダーコードの既知のバグでしたか?もしそうなら、インターネットに面したサーバー上のアプリケーションにどのようにパッチを当てるかについてのアプローチを再考する必要がありますか?
  2. 人々があなたのサイトに侵入することを許した欠陥は、ベンダーコードの未知のバグであり、パッチは利用できませんでしたか?私は、このような何かがあなたに噛み付く時はいつでもサプライヤーの変更を提言することはほとんどありません。ただし、システムが絶えずあなたを失望させている場合は、より堅牢なものに移行するか、少なくとも、脆弱なコンポーネントが綿毛に包まれ、敵の目から可能な限り離れるようにシステムを再設計する必要があります。
  3. この欠陥は、あなた(またはあなたのために働いている請負業者)によって開発されたコードのバグでしたか?もしそうなら、あなたはあなたのライブサイトへの展開のためのコードをどのように承認するかについてあなたのアプローチを再考する必要がありますか?改善されたテストシステム、またはコーディング「標準」の変更でバグをキャッチできましたか(たとえば、技術は万能薬ではありませんが、十分に文書化されたコーディング手法を使用することで、SQLインジェクション攻撃が成功する確率を減らすことができます) )。
  4. この欠陥は、サーバーまたはアプリケーションソフトウェアの展開方法に問題があったためですか?可能な場合、サーバーを構築および展開するために可能な限り自動化された手順を使用していますか?これらは、すべてのサーバーで一貫した「ベースライン」状態を維持するのに非常に役立ち、各サーバーで実行する必要があるカスタム作業の量を最小限に抑えるため、間違いを犯す機会を最小限に抑えることができます。同じことがコードの展開にも当てはまります。Webアプリの最新バージョンを展開するために「特別な」ことを行う必要がある場合は、それを自動化し、常に一貫した方法で実行されるようにしてください。
  5. システムのより良い監視により、侵入を早期に発見できたでしょうか?もちろん、スタッフの24時間監視または「オンコール」システムは費用対効果が低いかもしれませんが、あなたに代わってWeb対応サービスを監視し、問題が発生した場合に警告できる会社があります。あなたはこれを買う余裕がないか、それを必要としないと決めるかもしれません、そしてそれはちょうど良いです...ちょうどそれを考慮に入れてください。
  6. 必要に応じて、tripwireやnessusなどのツールを使用しますが、私がそう言ったので盲目的に使用しないでください。環境に適したいくつかの優れたセキュリティツールの使用方法を学び、これらのツールを常に最新の状態に保ち、定期的に使用してください。
  7. ウェブサイトのセキュリティを定期的に「監査」するために、セキュリティの専門家を雇うことを検討してください。繰り返しますが、あなたはこれを買う余裕がないか、それを必要としないと決めるかもしれません。

攻撃が成功した場合の結果を減らすために、どのような手順を踏むことができますか?

あなたの家の洪水の下層階の「リスク」が高いが、移動を保証するほど高くないと判断した場合は、少なくともかけがえのない家宝を上に移動する必要があります。右?

  1. インターネットに直接さらされるサービスの量を減らすことはできますか?内部サービスとインターネット向けサービスの間にある種のギャップを維持できますか?これにより、外部システムが危険にさらされた場合でも、内部システムを攻撃するための踏み台としてこれを使用する可能性が制限されます。
  2. 保存する必要のない情報を保存していますか?他の場所にアーカイブできる場合、そのような情報を「オンライン」で保存していますか。この部分には2つのポイントがあります。明らかなことは、人々があなたから持っていない情報を盗むことができないことであり、2番目のポイントは、保存する量が少ないほど、メンテナンスやコーディングの必要性が少なくなるため、バグが入り込む可能性が少なくなることですコードまたはシステム設計。
  3. Webアプリに「最小アクセス」原則を使用していますか?ユーザーがデータベースからの読み取りのみが必要な場合は、Webアプリがこれを処理するために使用するアカウントに読み取りアクセスのみを許可し、書き込みアクセスを許可せず、システムレベルのアクセスを許可しないようにします。
  4. 経験があまりなく、ビジネスの中心ではない場合は、アウトソーシングを検討してください。言い換えれば、デスクトップアプリケーションコードの記述について話している小さなWebサイトを運営していて、そのサイトから小さなデスクトップアプリケーションの販売を開始することに決めた場合、Paypalなどにクレジットカード注文システムを「アウトソーシング」することを検討してください。
  5. 可能な場合は、障害が発生したシステムからの復旧の練習を災害復旧計画の一部にしてください。これは間違いなくあなたが遭遇するかもしれない別の「災害シナリオ」であり、通常の「サーバールームが発火した」/「巨大なサーバーがファービーを食べる」ことによって侵入されたものとは異なる独自の一連の問題や問題があるだけです。(編集、XTZごと)

... そして最後に

他の人が重要だと考えるものの終わりはおそらく残していませんが、上記の手順は、少なくともハッカーの犠牲になるほど運が悪い場合は、整理を始めるのに役立つはずです。

とりわけ:パニックにならないでください。行動する前に考えてください。決定したらしっかりと行動し、ステップのリストに何か追加したいことがあればコメントを残してください。


+1、非常に素晴らしい、非常に包括的な。
エイブリーペイン

エイブリーに感謝します。あなたの写真がこれほど早く同じことを言っていないかはわかりませんが、今は投票していません!
ロブ・モイア

SFに回答をお気に入りとしてマークする機能があればいいのにと思います。また、クロスポストしたい、またはクロスポストする必要があるという、私が見た多くの答えがあるようです。とにかく、私は徹底的な答えのファンです-あなたはそれの一部だけを知っているよりむしろそれをすべて知っている方が良いです。
エイブリーペイン

1
あなたが追加する必要がある1つのこと、これをあなたのDR計画の一部にしてください!!! 小規模な企業には少数のサーバーしか存在しない可能性があります。これは、発生する前に考慮する必要があります。実行するときにできることは、隔離、評価、廃棄、再構築のみです。
XTZ

素晴らしいXTZがリストに載っています。
ロブモアー

19

常に軌道からそれを破棄します。確認する唯一の方法です。

代替テキスト
(ソース:flickr.com

ほとんどのシステムは、内部の暗黙的な信頼を持っている全体的なエンティティです。侵害されたシステムを信頼することは、システムの侵害を最初から犯した人を信頼するという暗黙の声明です。言い換えると:

あなたはそれを信頼することはできません。クリーニングを気にしないでください。すぐにマシンを切断して分離します。先に進む前に違反の性質を理解してください。そうでない場合は、同じことをもう一度繰り返してください。可能であれば、違反の日付と時刻を取得してみてください。そうすれば、参照の枠組みができます。バックアップから復元する場合、バックアップ自体に侵害のコピーがないことを確認する必要があるため、これが必要です。復元する前にワイプ-ショートカットを使用しないでください。


6

実際に言えば、ほとんどの人は、時間がかかりすぎるか、破壊的すぎると思うので、それをしません。私は数え切れないほどのクライアントに問題が継続する可能性があることをアドバイスしましたが、多くの場合、意思決定者によってこれらの理由のいずれかで再インストールが失敗します。

そうは言っても、侵入方法と被害の全範囲を知っていると確信しているシステム(通常はIDS、侵入の範囲を制限する同様のIDSを備えた固体のオフマシンログ)、罪悪感を感じることなく、再インストールせずにクリーンアップを実行しました。


2

ほとんどの場合、リビルドを実行する自信があると判断できるほど十分にテストされたディザスタリカバリルーチンがないか、どのくらいの時間がかかるか、どのような影響があるのか​​、またはバックアップが信頼できない、またはリスクアナリストが不明です。侵害されたシステムの範囲を理解しないでください。多くの理由が考えられます。

私はそれが主に基本的なルーティンとポリシーで見落としているものだと言っていて、それはあなたが公然と認めたいものではありません-その代わりにあなたは防御的なスタンスを取ります。少なくとも、どのような角度から見ても、侵害されたシステムを拭かないようにしたり、防御したりすることはできません。


2

私は以前にシステムを非核化していないので、彼らが入ったベクターの分析とその後の使用の分析を行い、それらがどこに到達したかを見ることができます。

ルート化されたら、ライブハニーポットがあり、ハック以外にも多くのことができます。-特に警察のために。

  • それは、ホットスタンバイでクリーンなシステムを取得し、ルート化されたボックスを分離するために高速なネットワークセキュリティを提供できるようになったと言いました。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.