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

내가 게시물을 기반으로 오래 전에 썼음 블로그에 여전히 귀찮게 할 수 있었을 때 돌아 왔습니다.

이 질문은 웹 서버에 침입 한 해커의 피해자가 계속해서 질문하고 있습니다. 대답은 거의 변하지 않지만 사람들은 계속 질문합니다. 이유를 잘 모르겠습니다. 아마도 사람들은 도움을 구할 때 본 답변이 마음에 들지 않거나 조언을 해줄 믿을 수있는 사람을 찾지 못할 수도 있습니다. 또는 사람들은이 질문에 대한 답변을 읽고 자신의 사례가 온라인에서 찾을 수있는 답변과 다른 이유의 5 %에 ​​너무 집중하고 그들의 사례가 거의 동일 할 경우 질문과 답변의 95 %를 놓치게됩니다. 그들이 온라인에서 읽은 것처럼.

그것은 저에게 첫 번째 중요한 정보 덩어리를 가져옵니다. 나는 당신이 특별한 독특한 눈송이라는 것을 정말로 고맙게 생각합니다. 귀하의 웹 사이트도 귀하와 귀하의 사업을 반영하거나 최소한 고용주를 대신하여 귀하의 노력을 반영한 것임을 감사드립니다. 그러나 외부에있는 누군가에게, 컴퓨터 보안 담당자가 당신을 도우려고 시도하고 도움을주기 위해 문제를보고 있든, 심지어 공격자 자신이든, 당신의 문제는 그들이 겪은 다른 모든 경우와 적어도 95 % 동일 할 것입니다. 본 적이 있습니다.

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

방금 서버가 해킹 당했다는 사실을 알게되었습니다. 이제 무엇?

공포에 질리지 말 것. 절대 서둘러 행동하지 말고, 일이 일어나지 않은 척하거나 전혀 행동하지 않는 것처럼 절대 시도하지 마십시오.

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

이 단계 중 일부는 상처를 입을 것입니다. (귀하의 웹 사이트에 내 세부 정보의 사본이 없으면) 이러한 단계 중 일부 또는 일부를 무시해도 상관 없지만 결국에는 더 나은 결과를 얻을 수 있습니다. 약의 맛이 끔찍할 수 있지만 때로는 치료법이 효과가 있기를 원한다면 간과해야합니다.

문제가 이미있는 것보다 더 악화되는 것을 막 으세요 :

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

이 마지막 단계를 수행하는 것이 여전히 주저합니까? 이해합니다. 그러나 다음과 같이보십시오.

일부 지역에서는 이러한 종류의 개인 정보 침해에 대해 당국 및/또는 피해자에게 알릴 법적 요구 사항이있을 수 있습니다. 고객이 문제에 대해 이야기하도록하면 짜증을 낼 수 있지만, 말하지 않으면 훨씬 더 짜증을 낼 수 있으며, 누군가가 신용 카드 정보를 사용하여 8,000 달러 상당의 상품을 청구 한 후에야 스스로 알게됩니다. 귀하의 사이트에서 훔쳤습니다.

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

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

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

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

아무도 필요 이상으로 오랫동안 오프라인 상태를 유지하고 싶어하지 않습니다. 그것은 주어진다. 이 웹 사이트가 수익을 창출하는 메커니즘이라면 빠르게 온라인으로 되돌려 야한다는 압박이 심할 것입니다. 위험에 처한 유일한 것이 귀하/귀하의 회사의 평판이더라도 이는 여전히 신속하게 백업해야하는 많은 압력을 유발합니다.

그러나 너무 빨리 온라인으로 돌아 가려는 유혹에 굴복하지 마십시오. 대신 가능한 한 빨리 문제의 원인을 이해하고 온라인으로 돌아 가기 전에 문제를 해결하지 않으면 거의 확실하게 다시 한 번 침입의 희생양이 될 것입니다. "한 번 해킹당하는 것은 불행으로 분류 될 수 있습니다. 곧바로 다시 해킹당하는 것은 부주의 한 것 같습니다. "(Oscar Wilde에게 사과와 함께).

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

미래 위험 감소

가장 먼저 이해해야 할 것은 보안은 인터넷 연결 시스템을 설계, 배포 및 유지 관리하는 전체 수명주기 동안 적용해야하는 프로세스이며 나중에 값이 싼 것처럼 코드에 몇 개의 계층을 적용 할 수있는 것이 아니라는 것입니다. 페인트. 적절한 보안을 유지하려면 프로젝트의 주요 목표 중 하나로서이를 염두에두고 처음부터 서비스와 애플리케이션을 설계해야합니다. 나는 그것이 지루하다는 것을 알고 당신은 전에 그것을 모두 들었고 당신의 베타 web2.0 (베타) 서비스를 웹에서 베타 상태로 만드는 "압력 맨"을 "실감하지 못한다"는 것을 알고 있지만 사실은 이것이 계속된다는 것입니다. 처음 말한 것이 사실이고 아직 거짓말이 아니었기 때문에 반복된다.

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

공격이 성공할 확률을 줄이기 위해 취할 수있는 조치는 무엇입니까?

예를 들면 :

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

성공적인 공격의 결과를 줄이기 위해 취할 수있는 조치는 무엇입니까?

주택 홍수의 낮은 층의 "위험"이 높지만 이사를해야 할만큼 충분히 높지 않다고 판단하는 경우, 최소한 대체 할 수없는 가보를 위층으로 옮겨야합니다. 권리?

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

... 그리고 마지막으로

나는 아마도 다른 사람들이 중요하다고 생각하는 것의 끝을 빠뜨리지 않았을 것입니다. 그러나 위의 단계는 당신이 해커의 희생양이 될만큼 운이 좋지 않다면 적어도 당신이 일을 분류하는 데 도움이 될 것입니다.

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

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

_{(출처 : flickr.com )}

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

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

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

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

재 구축에 대한 확신을 가질 수있을만큼 충분히 테스트 된 재해 복구 루틴이 없거나, 시간이 얼마나 걸리거나 영향이 무엇인지 불분명합니다 ... 또는 백업이 신뢰할 수 없거나 위험 분석가 손상된 시스템의 범위를 이해하지 못합니다. 여러 가지 이유를 생각할 수 있습니다.

나는 그것이 기본 루틴과 정책에서 대부분 잘못되었다고 말하고 싶습니다. 그것은 당신이 공개적으로 인정하고 싶은 것이 아니라 대신 방어적인 자세를 취합니다. 적어도 나는 당신이 어떤 각도로 보더라도 손상된 시스템을 지우지 않는 것을 보거나 방어 할 수 없습니다.

나는 이전에 시스템에 핵을 넣지 않았기 때문에 그들이 들어온 벡터에 대한 일부 분석과 이후 사용에 대한 분석을 수행하고 그들이 내부로 들어간 곳을 볼 수 있습니다.

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

• 즉, 핫 스탠바이 상태에서 깨끗한 시스템을 확보 할 수 있고 루팅 된 박스를 격리하기 위해 빠르고 향상된 네트워크 보안을 제공 할 수있는 권한이 있습니다.