루트 손상 후 다시 설치 하시겠습니까?


58

서버 손상에 대해이 질문을 읽은 후에 사람들이 왜 탐지 / 정리 도구를 사용하거나 시스템을 손상시키는 데 사용 된 구멍을 수정하여 손상된 시스템을 복구 할 수 있다고 생각하는지 궁금해지기 시작했습니다.

해커가 수행 할 수있는 다양한 루트 키트 기술과 그 밖의 모든 것을 감안할 때 대부분의 전문가는 운영 체제를 다시 설치 해야한다고 제안합니다 .

더 많은 사람들이 왜 궤도에서 시스템을 이륙시키고 핵무기를 사용 하지 않는지 더 나은 아이디어를 얻고 자합니다 .

다음은 몇 가지 요점입니다.

  • 포맷 / 재설치로 시스템을 청소하지 않는 조건이 있습니까?
  • 어떤 유형의 조건에서 시스템을 청소할 수 있다고 생각하며 언제 전체 재설치를 수행해야합니까?
  • 전체 재설치를 수행하는 것에 대한 어떤 추론이 있습니까?
  • 다시 설치하지 않기로 선택했다면, 자신이 청소하고 추가 손상이 다시 발생하지 않도록 합리적으로 확신하기 위해 어떤 방법을 사용합니까?

답변:


31

보안 결정은 궁극적으로 어떤 제품을 출시할지에 대한 결정과 마찬가지로 궁극적으로 위험에 대한 비즈니스 결정입니다. 해당 컨텍스트에서 프레임을 구성하면 수평을 맞추지 않고 다시 설치하기로 결정한 것이 합리적입니다. 기술적 관점에서 엄격하게 고려할 때 그렇지 않습니다.

비즈니스 결정에 일반적으로 적용되는 사항은 다음과 같습니다.

  • 가동 중지 시간에 측정 가능한 금액이 얼마나됩니까?
  • 고객이 왜 다운했는지에 대해 약간의 정보를 공개해야하는 경우 비용이 얼마나 듭니까?
  • 재설치를 위해 사람들을 끌어 내야 할 다른 활동은 무엇입니까? 비용이 얼만데?
  • 오류없이 시스템을 가동시키는 방법을 알고있는 올바른 직원이 있습니까? 그렇지 않은 경우 버그를 해결하는 데 비용이 어떻게됩니까?

따라서 이와 같은 비용을 추가 할 때 "잠재적으로"여전히 손상된 시스템을 계속 사용하는 것이 시스템을 다시 설치하는 것보다 낫다고 간주 될 수 있습니다.


1
"Bit IT는 궁극적으로 비싸다"에 관한 Richard Bejtlich의 훌륭한 게시물을 읽어보십시오. 요약하자면 , "시스템이 중단되어야 할 때"생산성 적중 "으로 인해 손상된 시스템을 기업 내에서 운영하는 것이 더 저렴하지는 않습니다. 보안 분석을 활성화하십시오. "
Josh Brower

2
나는 이것에 대해 잠시 동안 생각했고, 훼손 될 가능성이있는 시스템을 배치하는 것이 더 합리적인 이유를 생각 해낼 수 없었다.
duffbeer703

1
또한 손상된 시스템을 배포하거나 온라인 상태로 유지하고 싶지 않습니다. 그러나 이것은 기술자입니다. 그리고 그는 Bejtlich에 동의하지 않습니다. 왜냐하면 그가 손실 방지 운동이라고 말하지만 사업은 그것을 그렇게 취급하지 않기 때문입니다. 비즈니스는 위험의 관점에서 그것을 똑바로 본다. 예를 들어, 소송이 발생하는 경우 보험에 가입하여 보험에 가입 할 수 있으며, 이것이 그들이 위험을 처리하는 방식입니다. 그리고 Richard는 이것을 그의 주장에 무게를 두지 않습니다. 나는이 생각에 동의하지 않는다고 말했지만, 그것이 당신이 그것을 이해하는 방법입니다. 이것이 OP가 요구 한 것입니다.
K. 브라이언 켈리

또한 Bejtilich에 대해서는 어느 정도 동의하지 않지만 적어도 마지막 의견을 인용하겠습니다.이 토론에 또 다른 차원이 추가 되었기 때문에 "측정"위험은 농담입니다. 손실을 측정하는 것은 거의 불가능합니다. (경쟁 업체가 향후 10 년 동안 제품을 개선하기 위해 데이터를 훔칠 때 손실되는 금액을 알려주십시오.) 비용 측정은 회사를 떠나는 돈을 추적 할 수 있기 때문에 신뢰할 수있는 결과를 생성 할 가능성이 가장 높은 운동입니다. 이 게시물에. 나는 손실을 측정하고 싶지만 실제 숫자를 산출하지는 않습니다. 위험 측정은 대단한 추측입니다. "
Josh Brower

...하지만 우리의 전체 보험 산업과 민사 법원 시스템은 위험을 측정하고 손실에 대한 달러 수치를 기준으로합니다. 따라서 이러한 접근 방식 담당자에게 허용됩니다.
Brian Knoblauch

30

내가 블로그에 귀찮게 할 수 있었을 때 내가 옛날에 쓴 포스트에 근거한다 .

이 질문은 해커의 피해자가 웹 서버에 침입하여 계속 반복해서 묻습니다. 대답은 거의 변하지 않지만 사람들은 계속 질문을합니다. 왜 그런지 잘 모르겠습니다. 아마도 사람들은 도움을 구할 때 본 답변을 좋아하지 않거나 조언을 줄 수있는 사람을 찾을 수 없습니다. 또는 사람들이이 질문에 대한 답변을 읽고 자신의 사례가 특별하고 왜 온라인에서 찾을 수있는 답변과 다른지 5 %에 ​​너무 집중하고 질문의 95 %를 놓치고 사례가 충분히 가까운 곳에있을 경우 그들이 온라인으로 읽는 것과 같이.

그것은 정보의 첫 번째 중요한 너겟으로 연결됩니다. 나는 당신이 특별한 독특한 눈송이라는 것을 정말로 감사합니다. 귀하와 귀하의 비즈니스를 반영하거나 최소한 고용주를위한 귀하의 노력을 반영한 귀하의 웹 사이트도 감사합니다. 그러나 컴퓨터 보안 담당자가 사용자 나 공격자 자신을 도와주기 위해 문제를보고 있는지 여부에 관계없이 외부를 조사하는 사람에게는 문제가 다른 모든 사례와 95 % 이상 동일 할 가능성이 큽니다. 이제까지 본.

공격을 개인적으로 취하지 말고 여기에 따르거나 다른 사람들로부터 개인적으로 얻는 권장 사항을 취하지 마십시오. 웹 사이트 해킹의 희생자가 된 후이 글을 읽는다면 정말 죄송합니다. 여기서 도움이되는 것을 찾을 수 있기를 바랍니다.하지만 자아가 필요한 것을 방해 할 시간이 아닙니다. 하다.

서버가 해킹 당했다는 것을 알게되었습니다. 이제 뭐?

당황하지 마십시오. 절대로 서둘러 행동하지 말고 절대로 절대 일어나지 않았고 전혀 행동하지 않는 척하지 마십시오.

첫째 : 재난이 이미 일어난 것을 이해하십시오. 이것은 거부 할 때가 아니다. 지금까지 일어난 일을 받아들이고 현실에 대해 영향을 미치고 영향의 결과를 관리하기위한 조치를 취할 때입니다.

이러한 단계 중 일부는 해를 입을 수 있으며 (귀하의 웹 사이트에 내 세부 정보 사본이없는 경우)이 단계 중 일부 또는 전부를 무시해도 크게 신경 쓰지 않지만 결과적으로 더 나은 결과를 얻을 수 있습니다. 약은 끔찍한 맛이있을 수 있지만 때로는 치료법이 실제로 효과가 있기를 간과해야합니다.

문제가 기존보다 악화되는 것을 막으십시오 :

  1. 가장 먼저해야 할 일은 인터넷에서 영향을받는 시스템의 연결을 끊는 것입니다. 다른 문제가 무엇이든 시스템을 웹에 연결 한 상태로두면 공격이 계속 될 수 있습니다. 나는 이것을 문자 그대로 의미합니다. 누군가 실제로 서버를 방문하여 필요한 경우 네트워크 케이블을 분리하되 다른 조치를 취하기 전에 피해자를 머그컵에서 분리하십시오.
  2. 손상된 시스템과 동일한 네트워크에있는 모든 컴퓨터의 모든 계정에 대한 모든 암호를 변경하십시오. 아니야 모든 계정 모든 컴퓨터 예, 당신 말이 맞아요. 이것은 과잉 일 수 있습니다. 반면에 그렇지 않을 수도 있습니다. 당신은 어느 쪽도 모르십니까?
  3. 다른 시스템을 확인하십시오. 다른 인터넷 연결 서비스와 재무 또는 기타 상업적으로 민감한 데이터를 보유한 서비스에 특히주의하십시오.
  4. 시스템에 개인의 개인 데이터가있는 경우 한 번에 영향을받는 사람에게 완전하고 솔직하게 공개하십시오. 나는 이것이 어렵다는 것을 안다. 나는 이것이 상처받을 것이라는 것을 안다. 많은 기업들이 카펫 아래에서 이런 종류의 문제를 해결하기를 원하지만 당신이 그 문제를 해결해야 할 것을 두려워합니다.

이 마지막 단계를 여전히 주저하고 있습니까? 이해합니다 그러나 이것을 다음과 같이보십시오 :

일부 지역에서는 당국 및 / 또는 피해자에게 이러한 종류의 개인 정보 침해를 알리는 법적 요구 사항이있을 수 있습니다. 그러나 고객에게 문제가 있다고 말하면 고객에게 문제를 말하게하고, 고객이 말하지 않으면 훨씬 더 짜증을 내며, 누군가가 신용 카드 세부 정보를 사용하여 $ 8,000 상당의 상품을 청구 한 후에 만 ​​고객을 찾아냅니다. 귀하의 사이트에서 훔쳤습니다.

내가 이전에 말한 것을 기억하십니까? 나쁜 일이 이미 일어났다 . 이제 유일한 질문은 당신이 그것을 잘 처리하는 것입니다.

문제를 완전히 이해하십시오.

  1. 실제로이 기사를 작성하기로 결정한 사람이되고 싶지 않다면이 단계가 완전히 완료 될 때까지 영향을받는 시스템을 온라인으로 되돌려 놓지 마십시오. 사람들이 싼 웃음을 얻을 수 있도록 게시물에 연결하지 않습니다. 이 첫 번째 단계를 따르지 않은 결과에 대해 경고하기 위해 연결합니다.
  2. '공격 된'시스템을 조사하여 공격이 보안을 손상시키는 데 성공한 방법을 이해하십시오. 공격이 어디에서 발생했는지 파악하기 위해 모든 노력을 기울여서 향후 어떤 문제가 발생했는지 이해하고 향후 시스템을 안전하게 유지하기 위해 해결해야합니다.
  3. '공격 된'시스템을 다시 조사하십시오. 이번에는 공격이 진행된 위치를 파악하여 공격에서 어떤 시스템이 손상되었는지 이해할 수 있습니다. 손상된 시스템이 시스템을 더 공격하기위한 발판이 될 수 있음을 나타내는 모든 지침을 따르십시오.
  4. 모든 공격에 사용 된 "게이트웨이"를 완전히 이해하여 제대로 닫을 수 있도록하십시오. (예를 들어 시스템이 SQL 인젝션 공격에 의해 손상된 경우 침입 한 특정 코드 라인을 닫아야 할뿐만 아니라 모든 코드를 감사하여 동일한 유형의 실수인지 확인해야합니다. 다른 곳에서 만들어졌습니다).
  5. 하나 이상의 결함으로 인해 공격이 성공할 수 있음을 이해하십시오. 종종 공격은 시스템에서 하나의 주요 버그를 찾는 것이 아니라 시스템을 손상시키기 위해 여러 문제 (때로는 사소하고 사소한)를 함께 묶어 성공합니다. 예를 들어, SQL 주입 공격을 사용하여 데이터베이스 서버에 명령을 보내고 공격하는 웹 사이트 / 응용 프로그램이 관리 사용자의 컨텍스트에서 실행 중이고 해당 계정의 권한을 디딤돌로 사용하여 시스템. 또는 해커가 "오늘날 사무실에서 사람들이 저지르는 일반적인 실수를 이용"이라고 부르기도합니다.

복구 계획을 세우고 웹 사이트를 다시 온라인 상태로 만들고 유지하십시오.

아무도 더 이상 오프라인 상태가되기를 원치 않습니다. 그것은 주어진 것입니다. 이 웹 사이트가 수익 창출 메커니즘이라면 온라인으로 신속하게 되돌려 야한다는 압박이 심할 것입니다. 유일하게 위험에 처한 것이 귀사 / 귀사의 명성이지만, 이는 여전히 상황을 신속하게 복구해야하는 많은 압력을 발생시키고 있습니다.

그러나 온라인으로 너무 빨리 돌아 가려는 유혹에 굴복하지 마십시오. 대신 온라인으로 돌아 가기 전에 문제를 일으킨 원인을 이해하고 해결하기 위해 가능한 한 빨리 이동하십시오. 그렇지 않으면 다시 한 번 침입에 희생 될 것입니다. "한 번 해킹당하는 것은 불행으로 분류 될 수 있습니다. 나중에 바로 해킹당하는 것은 부주의 한 것처럼 보인다 "(오스카 와일드에게 사과 함).

  1. 이 섹션을 시작하기 전에 처음부터 성공적인 침입으로 이어진 모든 문제를 이해했다고 가정합니다. 사건을 과장하고 싶지는 않지만, 먼저 그렇게하지 않았다면 실제로해야합니다. 죄송합니다.
  2. 협박 / 보호 비용을 지불하지 마십시오. 이것은 쉬운 마크의 표시이며 당신이 그 단어가 당신을 묘사하는 데 사용되는 것을 원하지 않습니다.
  3. 완전한 재 구축없이 동일한 서버를 다시 온라인 상태로 만들려고하지 마십시오. 기존 하드웨어에서 새 상자를 구축하거나 "궤도에서 서버를 압축하고 새로 설치"하는 것이 이전 시스템의 모든 구석 구석을 감사하여 다시 배치하기 전에 깨끗한 지 확인하는 것보다 훨씬 빠릅니다. 다시 온라인으로. 동의하지 않으면 시스템을 완전히 정리했는지 또는 웹 사이트 배포 절차가 부당한 지저분하다는 것을 실제로 알 수없는 것입니다. 아마도 실제 사이트를 구축하는 데 사용할 수있는 사이트의 백업 및 테스트 배포가있을 것입니다. 그렇지 않은 경우 해킹 당하지 않는 것이 가장 큰 문제는 아닙니다.
  4. 해킹 당시 시스템에서 "실시간"데이터를 재사용하는 데 매우주의하십시오. "절대로하지 말아라"라고 말하지는 않을 것이지만, 솔직히 말해서 무결성을 보장 할 수 없다는 것을 알면 데이터를 유지하는 결과를 고려해야 할 것입니다. 이상적으로는 침입 전에 만든 백업에서이를 복원해야합니다. 당신이 그것을 할 수 없거나하지 않을 경우, 그 데이터는 오염되어 있기 때문에 매우 조심해야합니다. 이 데이터가 고객이 아닌 고객이나 사이트 방문자에게 속한 경우 특히 다른 사람에게 미치는 영향에 대해 알고 있어야합니다.
  5. 시스템을주의 깊게 모니터링하십시오. 향후 진행중인 프로세스로이 문제를 해결해야하지만 (아래에 자세히 설명) 사이트가 온라인으로 돌아간 직후에 추가로주의를 기울여야합니다. 침입자는 거의 확실하게 돌아올 것이며, 다시 침입하려고하는 것을 발견 할 수 있다면 이전에 사용했던 모든 구멍과 자신을 위해 만든 구멍을 모두 닫았는지 빠르게 확인할 수있을 것입니다. 현지 법 집행 기관에 전달할 수있는 정보.

미래의 위험을 줄입니다.

가장 먼저 이해해야 할 것은 보안은 인터넷 대면 시스템을 설계, 배포 및 유지 관리하는 전체 수명주기에 걸쳐 적용해야하는 프로세스이며, 나중에 싸구려처럼 코드를 몇 층 밟을 수는 없습니다. 페인트. 제대로 보안을 유지하려면 서비스와 응용 프로그램을 프로젝트의 주요 목표 중 하나로서 처음부터 설계해야합니다. 나는 지루하고 당신이 전에 그것을 들었고 베타 웹 2.0 (베타) 서비스를 웹상에서 베타 상태로 만드는 "압박자를 깨닫지 못한다"는 것을 알고 있지만, 사실은 이것이 그것이 처음으로 말되었고 그것이 아직 거짓말이되지 않았기 때문에 반복되기.

위험을 제거 할 수 없습니다. 그렇게하려고해서는 안됩니다. 그러나 수행해야 할 일은 어떤 보안 위험이 중요한지 이해 하고 위험영향과 위험이 발생할 확률 을 관리하고 줄이는 방법을 이해하는 것입니다.

공격이 성공할 확률을 줄이기 위해 어떤 조치를 취할 수 있습니까?

예를 들면 다음과 같습니다.

  1. 사람들이 사이트를 침입 할 수있는 결함으로 인해 공급 업체 코드에서 알려진 버그가 발견 되었습니까? 그렇다면 인터넷 연결 서버에서 응용 프로그램을 패치하는 방법에 대한 접근 방식을 다시 생각해야합니까?
  2. 사람들이 귀하의 사이트를 침입 할 수있는 결함으로 인해 공급 업체 코드에서 알 수없는 버그가 있었습니까? 나는 이런 문제가 당신에게 물릴 때마다 변화하는 공급 업체를 옹호하지 않습니다. 왜냐하면 그들은 모두 문제가 있기 때문에이 접근법을 취하면 최대 1 년 안에 플랫폼이 부족할 것입니다. 그러나 시스템이 지속적으로 다운되는 경우보다 강력하거나 최소한으로 마이그레이션해야합니다. 취약한 구성 요소가 면봉으로 싸서 적대적인 눈에서 가능한 멀리 떨어져 있도록 시스템을 다시 설계해야합니다.
  3. 결함이 귀하 (또는 귀하를 위해 일하는 계약자)가 개발 한 코드의 버그입니까? 그렇다면 실제 사이트에 배포하기 위해 코드를 승인하는 방법에 대한 접근 방식을 다시 생각해야합니까? 개선 된 테스트 시스템 또는 코딩 "표준"변경으로 버그가 발견 될 수 있습니다 (예 : 기술이 만병 통치약이 아닌 경우, 잘 문서화 된 코딩 기술을 사용하여 성공적인 SQL 주입 공격의 가능성을 줄일 수 있습니다. ).
  4. 서버 또는 응용 프로그램 소프트웨어 배포 방식에 문제가 있었기 때문에 결함이 있었습니까? 그렇다면 자동화 된 절차를 사용하여 가능한 경우 서버를 구축 및 배포하고 있습니까? 이는 모든 서버에서 일관된 "기준선"상태를 유지하는 데 큰 도움이되므로 각 서버에서 수행해야하는 사용자 지정 작업의 양을 최소화하고 따라서 실수가 발생할 가능성을 최소화 할 수 있습니다. 코드 배포도 마찬가지입니다. 최신 버전의 웹앱을 배포하기 위해 "특별한"작업을 수행해야하는 경우이를 자동화하고 항상 일관된 방식으로 수행되도록 노력하십시오.
  5. 더 나은 시스템 모니터링으로 침입이 조기에 포착되었을 수 있습니까? 물론 24 시간 모니터링 또는 직원을위한 "통화"시스템은 비용 효율적이 아닐 수 있지만 웹 대면 서비스를 모니터링하고 문제가 발생할 경우이를 알리는 회사가 있습니다. 당신은 당신이 이것을 감당할 수 없거나 필요하지 않다고 결정할 수도 있습니다. 그리고 그것은 괜찮습니다 ... 그냥 고려하십시오.
  6. 적절한 경우에는 트립 와이어 및 네스 우스와 같은 도구를 사용하십시오. 그러나 내가 말 했으므로 맹목적으로 사용하지 마십시오. 환경에 적합한 몇 가지 유용한 보안 도구를 사용하는 방법을 배우고 이러한 도구를 최신 상태로 유지하고 정기적으로 사용하십시오.
  7. 보안 전문가를 고용하여 정기적으로 웹 사이트 보안을 '감사'하십시오. 다시 말하지만, 당신이 이것을 감당할 수 없거나 필요하지 않다고 결정할 수도 있습니다.

성공적인 공격의 결과를 줄이기 위해 어떤 조치를 취할 수 있습니까?

가정 홍수의 낮은 층의 "위험"이 높지만 이동을 보증하기에 충분히 높지 않다고 결정한 경우 최소한 대체 할 수없는 가족 가보를 위층으로 이동시켜야합니다. 권리?

  1. 인터넷에 직접 노출되는 서비스의 양을 줄일 수 있습니까? 내부 서비스와 인터넷 연결 서비스간에 약간의 간격을 유지할 수 있습니까? 따라서 외부 시스템이 손상 되더라도이를 스프링 보드로 사용하여 내부 시스템을 공격 할 가능성이 제한됩니다.
  2. 저장할 필요가없는 정보를 저장하고 있습니까? 다른 곳에 보관할 수있을 때 그러한 정보를 "온라인"으로 저장하고 있습니까? 이 부분에는 두 가지 점이 있습니다. 분명한 것은 사람들이 가지고 있지 않은 정보를 사람들이 훔칠 수 없다는 것입니다. 두 번째 요점은 저장 공간이 적고 유지 관리 및 코드 작성이 적고 버그가 발생할 가능성이 적다는 것입니다 코드 또는 시스템 설계
  3. 웹 앱에 "최소 액세스"원칙을 사용하고 있습니까? 사용자가 데이터베이스에서 읽기만하면되는 경우, 웹 앱이 서비스를 제공하는 데 사용하는 계정에 읽기 권한 만 있고 쓰기 권한은 허용하지 않으며 시스템 수준의 액세스는 허용하지 않아야합니다.
  4. 경험이 많지 않고 비즈니스의 중심이 아닌 경우 아웃소싱을 고려하십시오. 다시 말해, 데스크톱 응용 프로그램 코드 작성에 대해 이야기하는 작은 웹 사이트를 운영하고 사이트에서 작은 데스크톱 응용 프로그램을 판매하기로 결정한 경우 신용 카드 주문 시스템을 Paypal과 같은 사람에게 "아웃소싱"하는 것이 좋습니다.
  5. 가능하면 손상된 시스템에서 복구를 실습하여 재해 복구 계획의 일부로 만드십시오. 이것은 아마도 당신이 겪을 수있는 또 하나의 "재난 시나리오"일뿐입니다. 단순히 일반적인 '서버 실에서 잡힌 화재'와는 다른 자체 문제와 문제가있는 것입니다. (XTZ에 따라 편집)

... 그리고 마지막으로

아마도 다른 사람들이 중요하다고 생각하는 것들을 끝내지 않았을 것입니다. 그러나 위의 단계는 해커에게 피해를 입힐만큼 운이 좋지 않은 경우 물건을 분류하는 데 도움이 될 것입니다.

무엇보다도 : 당황하지 마십시오. 행동하기 전에 생각하십시오. 결정을 내린 후에는 단호하게 행동하고 내 단계 목록에 추가 할 내용이 있으면 아래에 의견을 남겨주십시오.


+1, 매우 훌륭하고 포괄적입니다.
Avery Payne

감사합니다 에이버리, 당신의 사진이 훨씬 더 빨리 같은 말을하지는 않겠지 만 지금은 투표에서 벗어났습니다!
Rob Moir

SF가 답변을 즐겨 찾기로 표시 할 수 있기를 바랍니다. 또한 교차 게시하거나 교차 게시해야한다는 답변을 많이 보았습니다. 어쨌든, 나는 철저한 답변을 좋아합니다. 일부만 아는 것보다 모든 것을 아는 것이 좋습니다.
Avery Payne

1
추가해야 할 한 가지는 DR 계획의 일부로 만드십시오 !!! 소규모 회사에는 서버가 몇 대 밖에 없을 수 있습니다. 서버가 발생하기 전에 고려해야 할 사항입니다. 분리, 평가, 핵 공격, 재 구축 만하면됩니다.
XTZ 2016 년

멋진 XTZ가 목록에 있습니다.
Rob Moir 2016 년

19

항상 궤도에서 핵을 피하십시오. 확실한 유일한 방법입니다.

대체 텍스트
(출처 : flickr.com )

대부분의 시스템은 내재적 인 암시 적 신뢰를 갖는 전체 론적 엔티티입니다. 손상된 시스템을 신뢰한다는 것은 시스템 침해를 시작한 사람을 신뢰한다는 암시 적 진술입니다. 다시 말해:

당신은 그것을 믿을 수 없습니다. 청소에 신경 쓰지 마십시오. 기계를 즉시 분리하고 분리하십시오. 진행하기 전에 위반의 본질을 이해하십시오. 그렇지 않으면 같은 일을 다시 한 번 초대합니다. 가능한 경우 위반 날짜와 시간을 얻으려고 참조 프레임을 만드십시오. 백업에서 복원하는 경우 백업 자체에 손상의 사본이 없는지 확인해야하기 때문에이 기능이 필요합니다. 복원하기 전에 삭제-바로 가기를 사용하지 마십시오.


6

실제로, 대부분의 사람들은 너무 오래 걸리거나 너무 혼란 스러울 것이라고 생각하기 때문에하지 않습니다. 나는 수많은 고객들에게 지속적인 문제 가능성에 대해 조언했지만, 그 이유 중 하나 때문에 종종 의사 결정자가 다시 설치를 중단합니다.

즉, 입력 방법과 손상의 전체 범위를 알고 있다고 확신하는 시스템 (일반적으로 IDS, SELinux 또는 침입 범위를 제한하는 유사한 시스템을 갖춘 견고한 오프 머신 로그)에서 죄책감을 느끼지 않고 다시 설치하지 않고 정리를 수행했습니다.


2

재 구축에 대해 확신을 가질만큼 충분히 테스트 된 재난 복구 루틴이 없거나 백업에 시간이 오래 걸리거나 그 영향이 무엇인지 확실하지 않거나 백업이 신뢰할 수 없거나 위험 분석가 인 경우가 대부분입니다. 손상된 시스템의 범위를 이해하지 못합니다. 여러 가지 이유를 생각할 수 있습니다.

나는 그것이 기본 루틴과 정책에서 대부분 어색한 것이라고 말하고 싶지만 공개적으로 인정하고 싶지는 않지만 대신 방어 자세를 취합니다. 적어도 나는 당신이 보는 각도에 관계없이 손상된 시스템을 닦지 않는 것을 보거나 방어 할 수 없습니다.


2

나는 그들이 시스템에 들어 가지 않았기 때문에 그들이 온 벡터와 그 이후의 사용에 대한 분석을 수행하고 그들이 어디로 들어 갔는지 확인할 수 있습니다.

일단 당신이 뿌리를 내렸다면 당신은 라이브 허니팟을 가지고 있으며 그것은 단지 해킹 그 이상을 제공 할 수 있습니다. -특히 경찰을 위해.

  • 즉, 핫 스탠바이 상태에서 깔끔한 시스템을 구축 할 수 있고 루팅 된 박스를 격리하기 위해 빠른 네트워크 보안 기능을 제공 할 수 있다는 사전 준비가되어있다.
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.