손상된 서버를 어떻게 처리합니까?


601

이는 서버 보안-위반 이벤트에 대한 대응 (해킹)에 대한 정식 질문입니다
.

정식 버전
하나 이상의 서버가 해커, 바이러스 또는 기타 메커니즘에 의해 손상되었다고 생각합니다.

  • 첫 단계는 무엇입니까? 사이트에 도착하면 서버 연결을 끊고 "증거"를 유지해야합니다. 다른 초기 고려 사항이 있습니까?
  • 온라인 서비스를 다시 받으려면 어떻게해야합니까?
  • 같은 일이 즉시 다시 발생하지 않도록하려면 어떻게합니까?
  • 이 사건으로부터 배우기위한 모범 사례 또는 방법론이 있습니까?
  • 인시던트 대응 계획을 작성하려면 어디에서 시작해야합니까? 이것이 내 재해 복구 또는 비즈니스 연속성 계획의 일부 여야합니까?

원본 버전

2011.01.02- 서버가 어떻게 든 손상되어 공급자 에 대한 DOS 공격 으로 인해 일요일 오후 9시 30 분에 일을 시작했습니다. 인터넷에 대한 서버 액세스가 종료되었으므로 5-600 개 이상의 클라이언트 사이트가 다운되었습니다. 이제 이것은 FTP 해킹이거나 코드 어딘가의 약점이 될 수 있습니다. 내가 도착할 때까지 나는 확실하지 않다.

어떻게 빨리 추적 할 수 있습니까? 서버를 최대한 빨리 백업하지 않으면 많은 소송이 발생합니다. 도움을 주시면 감사하겠습니다. Open SUSE 11.0을 실행 중입니다.


2011.01.03- 도와 주셔서 감사합니다. 운 좋게도 나는이 서버를 책임지는 유일한 사람이 아니라 가장 가까운 사람이다. 우리는이 문제를 해결했지만 다른 상황에서는 다른 많은 사람들에게 적용되지 않을 수도 있습니다. 우리가 한 일을 자세히 설명하겠습니다.

우리는 그물에서 서버의 플러그를 뽑았습니다. 인도네시아의 다른 서버에서 서비스 거부 (DoS) 공격을 수행하고 있었으며 유죄 자도 그 기반을두고있었습니다.

먼저 서버에 500 개가 넘는 사이트가 있다는 점을 고려할 때 서버에서이 위치가 어디인지 확인하려고했지만 한동안 달빛이 비칠 것으로 예상했습니다. 그러나 SSH 액세스 권한을 유지하면서 공격이 시작된 시간에 편집 또는 생성 된 모든 파일을 찾기위한 명령을 실행했습니다. 운 좋게도 문제가되는 파일은 동절기 동안 만들어졌으며 그 당시 서버에 다른 파일은 많지 않았습니다.

그런 다음 ZenCart 웹 사이트 의 업로드 된 이미지 폴더에있는 문제 파일을 식별 할 수있었습니다 .

짧은 담배 휴식 후 파일 위치로 인해 파일 업로드 기능을 통해 파일이 제대로 확보되지 않았다고 결론을 내 렸습니다. 인터넷 검색 후 ZenCart 관리자 패널에서 레코드 회사를 위해 파일을 업로드 할 수있는 보안 취약점이 발견되었습니다. (실제로는 전혀 사용하지 않은 섹션)이 양식을 게시하면 파일이 업로드되고 파일의 확장자를 확인하지 않았으며 사용자가 로그인했는지 확인하지 않았습니다.

이는 공격용 PHP 파일을 포함하여 모든 파일을 업로드 할 수 있음을 의미했습니다. 감염된 사이트에서 ZenCart의 취약점을 보호하고 문제가되는 파일을 제거했습니다.

일이 끝나고 오전 2시 집에있었습니다


Moral -ZenCart 또는 다른 CMS 시스템에 보안 패치를 항상 적용하십시오. 보안 업데이트가 릴리스 될 때 전 세계는이 취약점을 인식합니다. -항상 백업을 수행하고 백업을 백업하십시오. -이런 시간에있을 누군가를 고용하거나 준비하십시오. 다른 사람이 서버 결함에 대한 혼란스러운 게시물에 의존하지 못하도록합니다.


7
나는 당신이 어떻게 느끼는지 알고 있습니다-우리는이 사이트에서 "유용한"해커들에게 매우 운이 좋았습니다. 앞으로 도움이되지 않는 손님을 찾는 경우를 대비하여이 질문에 대한 답변을 기대하고 있습니다.
Jarrod Dixon

186
도움을 받으려면 전문가에게 전화하십시오!
marcog

103
나는 똑똑한 아시리아 나 동정심을 느끼고 싶지 않으며 (나는 둘 다 아님) 물론, 나는 당신의 상황에 대한 세부 사항을 모르지만, 당신이 500-600 사이트 설정을 책임지는 유일한 사람이라면, 이 서버가 운영되는 방식의 근본적인 결함 일부 회사는 하루 종일 다른 작업을 수행하지 않고 서버를 유지 관리하는 전용 sysadmin을 사용합니다 . 프로그래머의 범위 내에 있지는 않지만 자동으로 수행 되지 않는 작업입니다 . 어쩌면 그것은 위기가 끝났을 때 고려해야 할 가치가 있습니다. 어쨌든 지금 당장 상황을 해결하는 데 행운이 있습니다.
Pekka 웃

커널 루트 키트가 완전히 구겨져 있고 루트 암호가 손상되었다고 가정하지 마십시오. 그것은 아마도 교활한 bash / perl 스크립트 일 것입니다. 합창단이 여기에서 무엇을하는지에 관계없이 형식을 지정하지 않고 정리할 수 있습니다 ... serverfault.com/questions/639699/…
Hayden Thring

답변:


1015

여기에 게시 한 내용에서 구체적인 조언을 제공하기는 어렵지만 블로그에 귀찮게 할 수 있었을 때 이전에 쓴 게시물을 기반으로 일반적인 조언이 있습니다.

당황하지 마십시오

가장 먼저, 침입 이전에 수행 된 백업에서 시스템을 복원하는 것 외에 "빠른 수정"이 없으며, 이는 적어도 두 가지 문제가 있습니다.

  1. 침입이 발생한 시점을 정확히 파악하기는 어렵습니다.
  2. 마지막 시간에 침입 할 수있는 "구멍"을 닫거나 발생했을 수있는 "데이터 도난"의 결과를 처리하는 데 도움이되지 않습니다.

이 질문은 해커의 피해자가 웹 서버에 침입하여 계속 반복해서 묻습니다. 대답은 거의 변하지 않지만 사람들은 계속 질문을합니다. 왜 그런지 잘 모르겠습니다. 아마도 사람들은 도움을 구할 때 본 답을 좋아하지 않거나 조언을 해줄 사람을 찾을 수 없습니다. 또는 사람들이이 질문에 대한 답변을 읽고 자신의 사례가 왜 특별하고 온라인에서 찾을 수있는 답변과 다른지 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. 가능하면 손상된 시스템에서 복구를 실습하여 재해 복구 계획의 일부로 만드십시오. 이것은 아마도 당신이 겪을 수있는 또 하나의 "재난 시나리오"일뿐입니다. 단순히 일반적인 '서버 실에서 잡힌 화재'와는 다른 자체 문제와 문제가있는 것입니다.

... 그리고 마지막으로

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

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


8
사람들이 방향을 시작할 수 있도록 훌륭한 게시물을 준비하려면 +1하십시오. 아마추어 서버 관리자가 처음으로 '해킹'을했을 때이 패닉 모드에 들어가는 것이 얼마나 흔한 지 알고 있습니다. 그것은이다 거대한 그 자리에있을 수있는 실수,하지만 발생합니다. 희망은 이것이 같은 사람에게 두 번 일어날 수 없다는 것입니다.
Andrew Barber

33
+1 "...하지만 지금은 자아가 당신이해야 할 일을 방해 할 때가 아닙니다." 이것은 Sys Admins가 때때로 이해하는 데 중요합니다. 당신이 아무리 지식이 많더라도 항상 당신보다 더 지식이 있거나 영리한 사람들이 있습니다.
Grahamux

11
좋은 대답입니다. 왜 모든 사람들이 "콜 법 집행"단계를 선택 사항으로 취급하는지 잘 모르겠습니다. 다른 사람의 데이터에 대한 책임이 있고 소송에 대해 걱정하는 경우 가장 먼저해야 할 일 중 하나 여야합니다.
wds

8
아주 좋은 글쓰기, 단 하나의 문제- "한 번에 영향을받을 가능성이있는 사람에게 완전하고 솔직한 공개" 존경하지만 항상 정확한 것은 아닙니다. 타협에 대응하기 위해 일부 거버넌스 코너를 줄여야 할 수도 있습니다. 그러나 회사는 일반적으로 약간의 여유를 줄입니다. 그러나 공개 여부는 구체적으로 데이터 보호에 영향이있을 때 급여 등급 이상의 문제 일 수 있습니다. 법적 의미가있을 수 있습니다. 데이터 보호 책임자에게 즉시 알리고 (그렇지 않은 경우) 전체 공개를 촉구하는 것이 좋습니다.
TheoJones

5
@GilesRoberts 가상 머신 호스트에는 일반적으로 게스트 설정을 조작 할 수있는 제어판이 있으며 RDP 또는 SSH를 사용하지 않고 실제로 게스트에 로그인하지 않고도 원격으로 제어 할 수 있습니다. 호스트 컨트롤을 사용하여 게스트를 격리 한 다음 원격보기 도구를 사용하여 여가 시간에 게스트를 조사 할 수 있어야합니다.
Rob Moir

204

머리 위에 약간있는 것 같습니다. 괜찮아. 상사에게 전화하여 긴급 보안 대응 예산 협상을 시작하십시오. $ 10,000는 시작하기에 좋은 곳입니다. 그런 다음 보안 사고 대응을 전문으로하는 회사에 전화를 걸려면 누군가 (PFY, 동료, 관리자)를 확보해야합니다. 많은 사람들이 24 시간 이내에 응답 할 수 있으며, 도시에 사무실이 있으면 더 빨리 응답 할 수도 있습니다.

또한 고객을 심사 할 사람이 필요합니다. 의심 할 여지없이 누군가 이미 있습니다. 어떤 일이 일어나고 있는지, 상황을 처리하기 위해 무엇을하고 있는지, 질문에 대답하기 위해 누군가와 전화를 걸어야합니다.

그런 다음에 ...

  1. 침착하십시오. 사고 대응을 담당하는 경우 이제 최고의 전문성과 리더십을 입증해야합니다. 귀하가하는 모든 일을 문서화하고 관리자 및 경영진에게 귀하가 취하는 주요 행동에 대해 계속 알리십시오. 여기에는 대응 팀과의 협력, 서버 비활성화, 데이터 백업 및 온라인으로 다시 가져 오기가 포함됩니다. 세부 사항은 필요하지 않지만 30 분마다 사용자의 의견을들을 수 있습니다.

  2. 현실적이 되십시오. 당신은 보안 전문가가 아니며, 모르는 것이 있습니다. 괜찮아. 서버에 로그인하고 데이터를 볼 때 한계를 이해해야합니다. 부드럽게 밟습니다. 조사 과정에서 중요한 정보를 습득하거나 나중에 필요할 수있는 정보를 변경하지 않도록하십시오. 불편 함을 느끼거나 추측하고 있다면, 그 곳은 경험이 풍부한 전문가를 대신하여 인수 할 수있는 좋은 장소입니다.

  3. 깨끗한 USB 스틱과 여분의 하드 드라이브를 구입하십시오. 여기에서 증거를 수집 할 것입니다. 관련이 있다고 생각되는 모든 것을 백업하십시오. 법 집행 기관이 관여하지 않더라도 소송이 발생하는 경우이 증거가 귀사가 보안 사고를 전문적이고 적절한 방식으로 처리했음을 증명해야합니다.

  4. 가장 중요한 것은 손실을 막는 것입니다. 손상된 서비스, 데이터 및 시스템에 대한 액세스를 식별하고 차단합니다. 바람직하게는 네트워크 케이블을 당겨야합니다. 당신이 할 수없는 경우, 전원을 당겨.

  5. 다음으로 공격자를 제거하고 구멍을 닫아야합니다. 네트워크를 가져와 공격자가 더 이상 대화 형 액세스 권한을 가지고 있지 않을 수 있습니다. 이제 백업, 스크린 샷 및 개인 관찰 메모를 사용하여 식별, 문서화 또는 영향을받는 서버에서 드라이브를 제거하고 전체 디스크 이미지 복사를 통해 기록한 다음 남은 코드와 프로세스를 제거해야합니다. . 이 다음 부분은 백업이 없으면 빨라집니다. 공격자는 시스템에서 직접 손을 떼려고 시도 할 수 있지만, 남은 모든 것을 확보 할 수는 없습니다. 루트킷은 악의적이며 모두 감지 할 수있는 것은 아닙니다. 가장 좋은 대응책은 침입에 사용한 취약점을 식별하고 영향을받는 디스크의 이미지 복사본을 만든 다음 영향을받는 시스템을 지우고 알려진 양호한 백업에서 다시로드하는 것입니다. 님' 맹목적으로 백업을 신뢰하지 마십시오. 그것을 확인하십시오! 새 호스트가 네트워크에서 다시 연결되기 전에 취약점을 복구하거나 닫은 다음 온라인 상태로 만드십시오.

  6. 모든 데이터를 보고서로 구성하십시오. 이 시점에서 취약점이 닫히고 호흡 할 시간이 있습니다. 이 단계를 건너 뛰려고 유혹하지 마십시오. 나머지 프로세스보다 훨씬 중요합니다. 보고서에서 문제, 팀의 대응 방법 및이 사건이 다시 발생하지 않도록 조치를 취하는 단계를 식별해야합니다. 최대한 자세하게 설명하십시오. 이는 귀하만을위한 것이 아니라 귀하의 관리 및 잠재적 소송의 방어를위한 것입니다.

그것은 무엇을해야하는지에 대한 높은 평가입니다. 대부분의 작업은 단순히 문서화 및 백업 처리입니다. 당황하지 마십시오, 당신은 그 일을 할 수 있습니다. 나는 강하게 당신이 전문 보안 도움을받을 것을 권장합니다. 진행중인 작업을 처리 할 수 ​​있더라도 도움이 매우 중요하며 일반적으로 더 쉽고 빠르게 프로세스를 수행 할 수있는 장비가 제공됩니다. 상사가 비용을 부담하면 소송 처리와 비교할 때 매우 작다는 것을 상기 시키십시오.

당신은 당신의 상황에 대한 위안을 가지고 있습니다. 행운을 빕니다.


19
+1 좋은 답변입니다. OP에 사전 정의 된 "응급 응답"이없는 것으로 들리며, 게시물은 다른 좋은 점 중에서 설정을 수행하도록 지시해야합니다.
Rob Moir

109

CERT에는 유닉스 또는 NT 시스템 손상으로부터 복구하기위한 문서 단계 가 있습니다. 이 문서의 특정 기술적 세부 사항은 다소 오래되었지만 여전히 일반적인 조언이 많이 적용됩니다.

기본 단계를 간단히 요약하면 다음과 같습니다.

  • 보안 정책 또는 관리를 참조하십시오.
  • 제어권 확보 (컴퓨터를 오프라인으로 전환)
  • 침입 분석, 로그 가져 오기, 무엇이 잘못되었는지 파악
  • 수리 물건
    • 깨끗한 운영 체제 버전을 설치하십시오 !!! 시스템이 손상된 경우 신뢰할 수 없습니다.
  • 다시 업데이트 할 수 없도록 시스템 업데이트
  • 재개 작업
  • 미래를위한 정책 업데이트 및 문서

나는 특별히 당신에게 섹션 E.1을 지적하고 싶습니다.

E.1. 컴퓨터가 손상된 경우 커널, 이진, 데이터 파일, 실행중인 프로세스 및 메모리를 포함하여 해당 시스템의 모든 항목이 수정되었을 수 있습니다. 일반적으로 기계에 백도어가없고 침입자 수정이 없다고 믿을 수있는 유일한 방법은 운영 체제를 다시 설치하는 것입니다.

트립 와이어와 같은 시스템이 이미없는 경우 시스템을 정리했다고 100 % 확신 할 수있는 방법이 없습니다.


26
심지어 tripwire는 커널 모듈 등으로 속일 수 있습니다. 다시 설치하십시오.
reconbot

위기에 대응하는 방법에 관한 관련 질문 도 여기서 유용 할 수 있습니다.
Zoredache

67
  1. 문제를 식별 하십시오. 로그를 읽으십시오.
  2. 포함 합니다. 서버 연결이 끊어졌습니다.
  3. 근절 . 영향을받는 시스템을 다시 설치하십시오. 해킹 된 하드 드라이브를 지우지 말고 새 하드 드라이브를 사용하십시오. 더 안전하고 백업되지 않은 못생긴 해킹을 복구하고 무슨 일이 있었는지 알아 내기 위해 법의학을 수행하려면 오래된 것이 필요할 수 있습니다.
  4. 복구하십시오 . 필요한 것을 설치하고 백업을 복구하여 클라이언트를 온라인 상태로 만드십시오.
  5. 후속 조치 . 문제가 무엇인지 파악하고 다시 발생하지 않도록하십시오.

52

Robert의 "쓴 약"은 정답이지만 완전히 일반적인 내용입니다 (질문과 마찬가지로). 하나의 서버와 600 개의 클라이언트가 있지만 관리 문제가 있고 풀 타임 sysadmin이 절실히 필요한 것처럼 들리지만 지금은 도움이되지 않습니다.

이 상황에서 약간의 손 잡기를 제공하는 호스팅 회사를 운영하고 있기 때문에 많은 손상된 시스템을 다루지 만 자체 모범 사례를 다루고 있습니다. 우리는 타협 된 고객이 타협의 본질을 절대적으로 확신하지 않는 한 항상 재건하도록 지시합니다. 장기적으로 다른 책임있는 경로는 없습니다.

그러나 DoS 공격이나 IRC 경비원 또는 고객의 사이트 및 데이터와 전혀 관련이없는 무언가를 원했던 스크립트 키디의 희생자 일 것입니다. 따라서 재 구축시 임시 조치로 상자에 강력한 아웃 바운드 방화벽을 설치하는 것을 고려할 수 있습니다. 사이트 기능에 절대적으로 필요하지 않은 모든 아웃 바운드 UDP 및 TCP 연결을 차단할 수 있다면 손상된 상자를 사용자로부터 빌린 사람에게 무용지물로 만들 수 있으며 공급자의 네트워크에 미치는 영향을 0으로 완화 할 수 있습니다.

이 프로세스는 이전에 수행하지 않은 경우 몇 시간이 걸리고 방화벽을 고려한 적이 없지만 공격자가 클라이언트 데이터에 계속 액세스 할 위험이있는 클라이언트 서비스를 복원하는 데 도움이 될 수 있습니다 . 한 대의 컴퓨터에 수백 명의 고객이 있다고 말했기 때문에 신용 카드 번호로 가득 찬 600 개의 전자 상거래 시스템이 아닌 소규모 비즈니스를위한 소규모 브로셔 웹 사이트를 호스팅하고 있다고 생각합니다. 이 경우 이는 허용 가능한 위험 일 수 있으며, 시스템을 다시 가져 오기 전에 600 개 사이트에서 보안 버그를 감사하는 것보다 시스템을 더 빨리 온라인으로 되돌릴 수 있습니다. 그러나 어떤 데이터가 있으며 그 결정을 내리는 것이 얼마나 편안한 지 알게 될 것입니다.

이것은 절대적으로 최선의 방법은 아니지만 지금까지 고용주에서 일어나지 않은 일이라면 손가락을 흔들어 SWAT 팀에게 수만 파운드를 요구하는 것이 잘못이라고 생각합니다. )은 실용적인 옵션처럼 들리지 않습니다.

ISP의 도움은 매우 중요합니다. 일부 ISP 는 콘솔 서버와 네트워크 부팅 환경 (플러그는 있지만 어떤 종류의 기능을 찾을 수 있는지 알고 있습니다)을 제공하여 네트워크 연결이 끊어진 상태에서 서버를 관리 할 수 ​​있습니다. 이것이 옵션이라면 요청하고 사용하십시오.

그러나 장기적으로 Robert의 게시물과 각 사이트 및 해당 설정에 대한 감사를 기반으로 시스템 재구성을 계획해야합니다. 팀에 sysadmin을 추가 할 수없는 경우 ISP에 sysadminning 도움말 및 이러한 종류의 항목에 대한 24 시간 응답을 지불 하는 관리 호스팅 거래를 찾으십시오. 행운을 빕니다 :)


41

다시 설치해야합니다. 정말로 필요한 것을 저장하십시오. 그러나 실행 가능한 모든 파일이 감염되어 변조 될 수 있습니다. 나는 파이썬에서 다음 썼다 : http://frw.se/monty.py 아무것도 후 변경 및 한 경우는 검사, 주어진 디렉토리와 당신이 그것을 실행할 때 모든 파일의 MD5-sumbs를 생성 출력 무엇을 파일이 변경되고 파일에서 변경된 내용

이상한 파일이 정기적으로 변경되는지 확인하는 데 도움이 될 수 있습니다.

그러나 지금해야 할 일은 인터넷에서 컴퓨터를 제거하는 것입니다.


13
그래서 ... 당신은 tripwire를 구현했습니다.
womble

13
예, 뭔가 문제가 있습니까?
Filip Ekberg

1
언 플러그 +1, 분석 (누군가에 실제 법의학을 할 수) 닦아
오스카 Duveborn

4
익명의 파이썬 스크립트와 문서화되고 (어떤) 잘 이해되고 이해가 잘되는 표준 솔루션 중에서 선택한다면 그들이 이전의 것을 고르기를 바라고 있습니까?
tripleee

37

참고 : 이것은 권장 사항이 아닙니다. 내 특정 인시던트 응답 프로토콜 Grant unwin의 경우 수정되지 않은 것 같습니다 .

우리의 학업 시설에는 계산 만하는 약 300 명의 연구원이 있습니다. 웹 사이트가있는 600 명의 클라이언트가 있으므로 프로토콜이 다를 수 있습니다.

서버가 손상된 프로토콜을 얻는시기 의 첫 단계 는 다음과 같습니다.

  1. 공격자가 루트 (권한 상승)를 얻을 수 있는지 확인
  2. 영향을받는 서버를 분리하십시오. 네트워크 또는 전원? 별도의 토론을 참조하십시오 .
  3. 다른 모든 시스템 확인
  4. 라이브 CD에서 영향을받는 서버 부팅
  5. (선택 사항) 모든 시스템 드라이브의 이미지를dd
  6. 사후 포렌식을 시작하십시오. 로그를보고 공격 시간을 파악한 다음 해당 시간에 수정 된 파일을 찾으십시오. 어떻게 대답 하시겠습니까? 질문.

    • 동시에 복구를 계획하고 실행하십시오.
    • 서비스를 재개하기 전에 모든 루트 및 사용자 비밀번호를 재설정하십시오

"모든 백도어 및 루트킷이 정리 되었더라도"시스템을 신뢰하지 마십시오. 처음부터 다시 설치하십시오.


23
-1 서버를 전원에서 분리 하시겠습니까? 법의학 데이터의 절반을 잃어 버렸습니다!
Josh Brower

@ 조쉬, 나는 내 대답을 조정했다-이제 그것은 무엇을 뽑을 것인가 질문에 중립적이다.
Aleksandr Levchuk

5
RAM 법의학 (예 : / dev / shm)이 도움이 될 수 있습니다. 전원 케이블을 뽑는 것을 선호합니다 (그러나 로그인하고 rsync/ proc 직전 에 시도하십시오 ). 또한 RAM 포렌식이 가능하도록 빈번한 VM 스냅 샷을 도입 할 수도 있습니다. 전원 케이블을 사용해야하는 이유는 다음과 같습니다. (1) 해킹 된 시스템에서 법의학을 수행 할 때 "범죄 현장 전체를 밟고 있습니다". (2) 루트 키트는 계속 작동 합니다. 네트워크 링크 다운 이벤트 에서 악의적 인 사람이 무언가를 실행하는 것 (예 : 시스템 삭제)은 어렵지 않습니다 . Kyle Rankin은 법의학 소개 강의 ( goo.gl/g21Ok )에서 전원 케이블을 뽑는 것을 권장했습니다.
Aleksandr Levchuk

4
모든 IR 프로토콜에 맞는 크기는 없습니다. 어떤 조직은 어떤 이유로 든 손상된 시스템을 잠시 동안 온라인 상태로 유지해야 할 수도 있습니다. (RAM 및 임시 로그 법의학, 침입자와의 상호 작용 등) 필자의 요점은 "손상된 서버의 전원 플러그를 뽑아내는 것보다 일반적인 IR 프로토콜 (위의 Jakob Borgs)을 권장하는 것이 좋습니다. "
Josh Brower

31

제한된 경험에서 리눅스의 시스템 손상은 Windows에서보다 '포괄적'인 경향이 있습니다. 루트 키트는 시스템 바이너리를 사용자 정의 코드로 대체하여 맬웨어를 숨길 가능성이 훨씬 높으며 커널 핫 패칭 장벽이 약간 낮습니다. 또한 많은 맬웨어 작성자의 홈 OS입니다. 일반적인 지침은 항상 영향을받는 서버를 처음부터 다시 작성하는 것이며, 이유에 대한 일반적인 지침입니다.

그 강아지를 포맷하십시오.

그러나, 당신이 재건 할 수 없거나 (또는 ​​그 힘이 필요로하는 당신의 격렬한 주장에 반하여 그것을 재건하지 못하게된다면), 당신은 무엇을 찾고 있습니까?

침입이 발견 된 후 오랜 시간이 걸렸고 시스템 복원이 완료된 것처럼 들리기 때문에 시스템 복원을 위해 스탬피드에 들어간 흔적이 스탬핑되어 서비스를 복원했을 가능성이 매우 높습니다. 불행한 사람.

비정상적인 네트워크 트래픽은 상자에서 아무 것도 실행하지 않아도되며 서버가 작동 중이거나 수행하는 동안 수행 할 수 있으므로 찾기 가장 쉬운 방법 일 것입니다. 물론, 네트워크 장비는 포트 스패닝을 허용합니다. 찾은 것은 진단 일 수도 있고 아닐 수도 있지만 최소한 정보 일뿐입니다. 비정상적인 트래픽을 얻는 것은 시스템이 여전히 손상되어 있으며 평탄화해야한다는 강력한 증거입니다. 실제로 재 포맷이 실제로 다운 타임 가치가 있다고 TPTB에 확신을주는 것으로 충분할 것입니다.

실패하면 시스템 파티션을 dd-copy하여 다른 상자에 마운트하십시오. 손상된 시스템과 동일한 패치 수준에서 서버와 내용을 비교하십시오. 다른 모양 (md5sum)을 식별하고 손상된 서버의 간과 된 영역을 가리킬 수 있습니다. 이것은 디렉토리와 바이너리를 선별하는 많은 작업이며 다소 노동 집약적입니다. 재 포맷 / 재 구축보다 더 노동 집약적 일 수 있으며 실제로 실제로 재 포맷을 수행하는 것에 대해 TPTB를 공격하는 또 다른 일이 될 수 있습니다.


2
'그 강아지를 포맷하십시오.' -+1, 현인 조언. 또한보십시오 : "궤도에서 벗어나는 것이 유일한 방법입니다."
에이버리 페인

31

@Robert Moir, @Aleksandr Levchuk, @blueben 및 @Matthew Bloch는 모두 응답에서 거의 주목을 받았습니다.

그러나 다른 포스터의 답변은 다릅니다-일부는 더 높은 수준에 있으며 어떤 절차를 갖추어야하는지에 대해 이야기합니다 (일반).

나는 이것을 여러 개의 개별적인 부분으로 나누기를 선호한다. 1) 심사, AKA 고객 및 법적 시사점을 다루는 방법과 그로부터 어디로 가야하는지 식별 (Robert and @blueben에 의해 잘 나열 됨) 영향 완화 3 ) 사고 대응 4) 사후 포렌식 5) 치료 항목 및 아키텍처 변경

(여기에 보일러 플레이트 SANS GSC 인증 응답 명세서를 삽입하십시오) 과거의 경험을 바탕으로 다음과 같이 말합니다.

고객 응답, 알림, 법률 및 향후 계획을 처리하는 방법에 관계없이 현재 주요 문제에 집중하고 싶습니다. OP의 원래 질문은 실제로 # 2 및 # 3과 직접 관련이 있으며 기본적으로 공격을 중지하고 고객을 원래 상태로 최대한 빨리 온라인 상태로 되돌려 보내며 응답에 잘 설명되어 있습니다.

나머지 답변은 훌륭하며 향후에 발생하는 것을 방지하고 더 잘 대응할 수있는 식별 된 모범 사례와 방법을 많이 다루고 있습니다.

그것은 실제로 OP 예산과 그들이 속한 산업 분야, 원하는 솔루션 등에 달려 있습니다.

현장 전용 SA를 고용해야 할 수도 있습니다. 보안 담당자가 필요할 수도 있습니다. 또는 Firehost 또는 Rackspace Managed, Softlayer, ServePath 등과 같은 완전히 관리되는 솔루션이 필요할 수도 있습니다.

그것은 실제로 그들의 비즈니스에 효과적인 것이 무엇인지에 달려 있습니다. 그들의 핵심 역량이 서버 관리에 있지 않을 수 있으며,이를 개발하려는 것은 이치에 맞지 않습니다. 또는 이미 훌륭한 기술 조직으로 올바른 채용 결정을 내리고 전담 팀을 구성 할 수 있습니다.


1
예, 다릅니다. 우리는 알고 있습니다. 그렇게 말하는 것이 실제로 도움이되지는 않습니다.
DOK

27

일을하고 서버를 살펴본 후 문제를 파악했습니다. 다행히도 사무실을 닫고 로그 및 캐시 파일을 제외하고 파일을 작성하지 않아야하는 일요일에 문제가되는 파일이 시스템에 업로드되었습니다. 그 날 어떤 파일이 생성되었는지 알아 내기 위해 간단한 쉘 명령으로 파일을 찾았습니다.

문제가되는 모든 파일이 일부 기존 zencart 사이트의 / images / 폴더에있는 것 같습니다. 바보가 아닌 이미지를 관리자 섹션의 이미지 업로드 섹션에 업로드 할 수있는 보안 취약점이있는 것으로 보입니다. 문제가되는 .php 파일을 삭제하고 이미지가 아닌 파일 업로드를 허용하지 않도록 업로드 스크립트를 수정했습니다.

돌이켜 보면, 그것은 매우 간단했고 나는 iPhone으로 출근길에이 질문을 제기했다. 모든 도움을 주셔서 감사합니다.

앞으로이 게시물을 방문하는 사람을 참조하십시오. 나는 것 없는 전원 플러그를 당겨 좋습니다.


그랜트. 우리 중 많은 사람들이 생각하는 것보다 훨씬 덜 심각했습니다. 이 토론은 나에게 의사 소통에 대한 교훈을 가르쳐 주었고, 음란 한 반응에 대해 생각할 수있는 좋은 팁과 음식을 많이주었습니다.
Aleksandr Levchuk

3
다시와 주셔서 감사합니다. 알다시피, 귀하의 질문은 많은 토론을 불러 일으켰습니다. 나는 당신이 이것에 너무 심하게 타격을받지 않았고 결국 당신의 해결책이 아주 간단하다는 것을 기쁘게 생각합니다.
Rob Moir

5
이것은 질문에 대한 답변이 아닌 설명 (또는 질문에 텍스트로 포함)이어야합니다.
Techboy

5
@Techboy : 아직 자신의 SO 및 SF 계정을 연결하지 않은 것 같으므로 질문을 편집 할 수 없습니다. @Grant : 사용자 페이지의 "계정"패널을 통해 계정을 연결할 수 있습니다.
Hippo

1
기본 구성이 없으면 루트킷을 실행하지 않는 방법을 어떻게 알 수 있습니까?
유닉스 청소부

18

광범위한 기술 답변에 거의 기여하지 않지만 다음 중 일부에 유의하십시오.

비 기술적 조치 :

  • 사건을 내부적으로보고하십시오.
    CYA 기술로 나타날 수있는 인시던트 대응 계획이 아직없는 경우 IT 부서가 유일 하게이 서버 의 비즈니스 영향 을 판단 할 수있는 유일한 장소는 아닙니다 .
    비즈니스 요구 사항에 따라 기술적 인 문제가 발생할 수 있습니다. "내가 말했듯이"이라고 말하지 말고 비즈니스 문제의 우선 순위는 처음에이 손상된 서버를 사용하는 이유입니다. ( " 후 조치 보고서를 위해 남겨 두십시오. ")

  • 보안 사고를 다루는 것은 옵션이 아닙니다.

  • 지방 당국에보고.
    ServerFault는 법적 조언을위한 장소는 아니지만 사고 대응 계획에 포함되어야합니다.
    일부 지역 및 / 또는 규제 된 산업에서는 보안 사건을 현지 법 집행 기관, 규제 기관에보고하거나 영향을받는 고객 / 사용자에게 알리는 것이 필수적입니다.
    그럼에도 불구하고보고 결정이나 실제보고는 IT 부서에서만 이루어지지 않습니다. 경영진 및 법률 및 기업 커뮤니케이션 (마케팅) 부서의 참여를 기대하십시오.
    인터넷은 경계가 거의없는 큰 장소이지만, 많은 경찰서에 존재하는 사이버 범죄 부서는 디지털 범죄를 해결하고 유죄를 정의 할 수 있습니다.


16

나는 그것이 모두 이것으로 귀결된다고 생각한다.

직업을 소중히 생각한다면 계획을 세우고 정기적으로 수정하십시오.

계획 실패는 실패 할 계획이며 시스템 보안 이외의 다른 곳에서는 사실이 아닙니다. 때 <편집 됨> 팬 안타, 당신은 더 잘 처리 할 준비가 될 것입니다.

여기에 적용되는 또 다른 말이 있습니다 : 예방이 치료보다 낫습니다 .

여기에서 전문가가 기존 시스템을 감사하도록 권장하는 여러 가지 권장 사항이 있습니다. 나는 이것이 잘못된 시간에 질문을하고 있다고 생각합니다. 이 질문은 시스템이 설치 될 때 질문을 받았으며 답변이 문서화되었습니다. 또한 질문은 "사람들이 침입하는 것을 어떻게 막을 수 있습니까?" "왜 사람들이 침입 할 수 있어야합니까?" 네트워크의 많은 허점에 대한 감사는 새로운 허점이 발견되고 이용 될 때까지만 작동합니다. 반면, 처음부터 특정 방식으로 만 신중하게 구성된 무용으로 특정 시스템에 응답하도록 설계된 네트워크는 감사의 혜택을받지 않으며 자금은 낭비가됩니다.

인터넷에 시스템을 설치하기 전에 스스로에게 물어보십시오. 100 % 인터넷을 사용해야합니까? 그렇지 않다면하지 마십시오. 인터넷에서 볼 수있는 것을 결정할 수있는 방화벽 뒤에 배치하십시오. 더 좋은 점은, 만약 방화벽이 당신에게 (역 프록시 나 어떤 종류의 통과 필터를 통해) 전송을 가로 챌 수 있다면, 정당한 행동 만이 일어나도록 허용하는 것입니다.

이는 인터넷 풀링 프록시가 서버 풀에서 멀리 떨어진 공격을 막기 위해 사용하려는 인터넷 뱅킹 설정이 있거나 인터넷 뱅킹 설정이있는 곳입니다. 보안 전문가 인 마커스 라넘 (Marcus Ranum) 은 리버스 프록시를 사용하여 알려진 유효한 URL 만 허용하고 그 밖의 모든 것을 404 서버로 전송 함으로써 반대 접근 방식을 취하도록 설득했습니다 . 놀랍게도 시간의 시험을 견뎌냈습니다.

기본 허용을 기반으로 한 시스템 또는 네트워크는 예측하지 못한 공격이 발생하면 실패 할 수 있습니다. 기본 거부는 내부에있는 어떤 것도 보지 않는 한 외부에서 볼 수 없도록하기 때문에 무엇이 들어오고 들어 가지 않는지에 대해 훨씬 더 큰 제어력 을 제공합니다 .

즉,이 모든 것이 만족할만한 이유는 없습니다. 위반 후 처음 몇 시간 동안 계획을 세워야합니다. 완벽한 시스템은 없으며 인간은 실수를 저지 릅니다.


15

멋진 온라인 사용자가 최근에 침입자가 시스템을 손상시킬 수있는 방법을 찾도록 도와주었습니다. 일부 크래커는 파일에서 수정 시간을 단축하여 추적을 숨기려고합니다. 수정 시간을 변경하면 변경 시간이 업데이트됩니다 (ctime). 통계와 함께 ctime을 볼 수 있습니다.

이 하나의 라이너는 ctime으로 정렬 된 모든 파일을 나열합니다.

find / -type f -print0 | xargs -0 stat --format '%Z :%z %n' | sort -nr > /root/all_files.txt

따라서 손상 시간을 대략 알고 있으면 어떤 파일이 변경 또는 생성되는지 확인할 수 있습니다.


당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.