최근 해킹과 보안에 관한 3 가지 흥미로운 스레드가 있습니다.

손상된 서버를 어떻게 처리합니까? .
해킹 된 서버가 해킹 된 방법 찾기
파일 권한 질문

마지막 것은 직접 관련이 없지만 웹 서버 관리를 쉽게 망칠 수있는 방법을 강조합니다.

수행 할 수있는 몇 가지 사항이 있으므로, 잘못된 일이 발생 하기 전에 공격의 후면 효과를 제한하기위한 모범 사례와 슬픈 경우에 대응하는 방법에 대한 제안을하고 싶습니다.

서버와 코드를 보호하는 것뿐만 아니라 감사, 로깅 및 대응 조치도 중요합니다.

모범 사례 목록이 있습니까, 아니면 웹 서버를 지속적으로 분석하는 소프트웨어 나 전문가에게 의존하고 싶습니까?

그렇다면 목록과 아이디어 / 의견을 공유 할 수 있습니까?

최신 정보

몇 가지 좋고 흥미로운 의견을 받았습니다.

간단한 목록을 원하므로 IT 보안 관리자뿐만 아니라 웹 팩트 마스터 마스터 에게도 유용합니다 .

모든 사람이 정답과 정답을 주었다고해도 현재 Robert 는 가장 간단하고 명확하며 간결하고 sysadmin1138 은 가장 완벽하고 정확하기 때문에 Robert 를 선호합니다 .

그러나 아무도 사용자의 관점과 인식을 고려하지 않습니다. 이것이 가장 먼저 고려되어야한다고 생각합니다.

사용자가 내 해킹 된 사이트를 언제 방문 할 것인지에 대한 합리적인 정보. 데이터를 어디에 보관해야 하는가가 아니라 화난 사용자를 진정시키는 방법입니다.

데이터, 미디어, 기관 및 경쟁 업체는 어떻습니까?

집중해야 할 두 가지 큰 영역이 있습니다.

1. 들어가기 어렵게 만들기
2. 과거 1 지점에 도착한 사람의 이벤트를 조용하고 효율적으로 처리하기위한 정책 및 절차 작성

들어가기 어렵게 만들기

이것은 매우 복잡한 주제이며 많은 부분은 WTF가 사실 이후에 발생했는지 파악하기에 충분한 정보가 있는지 확인하는 데 중점을 둡니다. 단순성을위한 추상 글 머리 기호 :

• 로그 유지 (보안 정보 이벤트 관리 참조)
  • 소스 정보를 그대로 유지하면서 성공 및 실패에 대한 모든 권한 부여 시도.
  • 방화벽 액세스 로그 (사용중인 경우 서버 별 방화벽을 포함해야 할 수 있음).
  • 웹 서버 액세스 로그
  • 데이터베이스 서버 인증 로그
  • 응용 프로그램 별 사용 현황 로그
  • 가능하면 SIEM은 의심스러운 패턴에 대해 경고를 표시 할 수 있습니다.
• 적절한 액세스 제어 시행
  • 모든 곳에서 권리가 올바르게 설정되어 있는지 확인하고 가능한 한 '게으른 권리'( "모든 사람에게만 읽어주십시오")를 피하십시오.
  • 절차를 실제로 따르고 있는지 확인하기 위해 정기적으로 ACL을 감사하고 문제 해결이 완료된 후 임시 문제 해결 단계 ( "모든 사용자가 읽고 작동하는지 확인하십시오")가 올바르게 제거되었습니다.
  • 모든 방화벽 통과 규칙을 정당화하고 주기적으로 감사해야합니다.
  • 웹 서버 및 파일 시스템 ACL 모두 웹 서버 액세스 제어를 감사해야합니다.
• 변경 관리 시행
  • 보안 환경에 대한 변경 사항은 둘 이상의 사람이 중앙에서 추적하고 검토해야합니다.
  • 이 프로세스에는 패치가 포함되어야합니다.
  • 공통 OS 빌드 (템플릿)를 사용하면 환경을 단순화하고 변경 사항을보다 쉽게 ​​추적하고 적용 할 수 있습니다.
• 손님 계정을 비활성화합니다.
• 모든 비밀번호가 기본값으로 설정되어 있지 않은지 확인하십시오.
  • 상용 애플리케이션은 사전 정의 된 비밀번호로 사용자를 설정할 수 있습니다. 그것들을 바꾸십시오.
  • 많은 IT 어플라이언스에는 잘 알려진 사용자 / 암호 쌍이 함께 제공됩니다. 일 년에 한 번만 로그인하더라도 변경하십시오.
• 최소 권한을 연습하십시오. 사용자에게 실제로 필요한 액세스 권한을 부여하십시오.
  • 관리자에게는 두 계정 설정이 현명합니다. 전자 메일 및 기타 사무 업무에 사용되는 일반 계정 하나와 개인 정보 보호 업무를위한 보조 계정입니다. VM을 사용하면보다 쉽게 ​​살 수 있습니다.
  • 일반 관리자 / 루트 계정을 정기적으로 사용하지 마십시오. 누가 언제 무엇을하고 있었는지 추적하기는 어렵습니다.

누군가가 들어오는 사건을 조용하고 효율적으로 처리하기위한 정책 및 절차 작성

보안 이벤트 정책은 모든 조직에 필수적입니다. 사람들이 이와 같은 사건에 직면했을 때 비합리적인 경향이 있기 때문에 "머리가 잘린 상태로 달리는"단계의 반응을 크게 줄입니다. 침입은 크고 무서운 일입니다. 침입으로 인한 수치심은 그렇지 않으면 수평이 아닌 시스템 관리자가 잘못 반응하기 시작할 수 있습니다.

조직의 모든 수준에서 정책을 알고 있어야합니다. 사건이 클수록 고위 경영진은 어떤 방식 으로든 참여할 가능성이 높으며, 사물 처리를위한 절차를 설정하면 "도움말"을 높이는 데 크게 도움이됩니다. 또한 사고 대응에 직접 관여하는 기술자가 중간 관리 부서가 나머지 조직과 인터페이스하는 절차의 형태로 커버 수준을 제공합니다.

재해 복구 정책은 DR 정책이 시작되기 전에 특정 서비스를 사용할 수없는 기간을 이미 정의한 것이 이상적입니다. 이러한 유형의 이벤트 는 재해 이므로 사고 대응에 도움이됩니다 . 이벤트가 복구 창이 충족되지 않는 유형 인 경우 (예 : 핫 백업 DR 사이트는 변경된 데이터를 실시간으로 가져오고 침입자는 DR 사이트로 복제되기 전에 많은 데이터를 삭제했습니다. 따라서 콜드 리커버리 절차를 사용해야합니다.) 그런 다음 고위 경영진이 리스크 평가 대화에 참여해야합니다.

사고 대응 계획의 일부 구성 요소 :

• 손상된 시스템과 노출 된 데이터를 식별하십시오.
• 최종 기소를 위해 법적 증거를 보유해야하는지 여부를 조기에 결정하십시오.
  • 증거를 보관 해야 할 경우 반드시 필요한 경우가 아니라면 해당 시스템에 대해 아무 것도 만지지 마십시오 . 로그인하지 마십시오. 로그 파일을 조사하지 마십시오. 하다. 아니. 접촉.
  • 증거를 보관하려면 인증 된 컴퓨터 법의학 전문가가 증거 처리 규칙과 호환되는 방식으로 시스템을 해체 할 수있을 때까지 손상된 시스템을 온라인 상태 로 유지해야 하지만 연결을 끊어야 합니다.
    • 손상된 시스템의 전원을 끄면 데이터가 손상 될 수 있습니다.
    • 스토리지 시스템이이를 허용하는 경우 (이산 SAN 장치) 연결을 끊기 전에 영향을받는 LUN의 스냅 샷을 생성하고 읽기 전용으로 플래그를 지정하십시오.
  • 증거 처리 규칙은 복잡하고 너무 쉽게 정리할 수 있습니다. 그들에게 훈련을받지 않았다면하지 마십시오. 대부분의 일반 SysAdmin에는 이러한 종류의 교육이 없습니다.
  • 증거가 유지되면 서비스 손실을 하드웨어 손실 재해 로 취급하고 새 하드웨어로 복구 절차를 시작하십시오.
• 어떤 종류의 재해에 대한 사전 설정 규칙에는 어떤 종류의 통지가 필요합니다. 법과 규정은 지역에 따라 다릅니다.
  • '노출'및 '증명 된 타협'과 관련된 규칙은 다양합니다.
  • 통지 규칙에는 커뮤니케이션 부서가 참여해야합니다.
  • 필요한 통지가 충분히 크면 최상위 경영진이 참여해야합니다.
• DR 데이터를 사용하여 서비스를 온라인으로 다시 가져 오기 전에 "WTF가 방금 발생한"시간을 얼마나 소비 할 수 있는지 결정하십시오.
  • 서비스 복구 시간에는 종속 된 항목을 파악하는 작업이 필요할 수 있습니다. 그렇다면 서비스가 복원 된 후 해부 대상 장치의 드라이브 이미지를 가져옵니다 (증거 사본이 아니며 기술자가 리버스 엔지니어링하는 것임).
  • 혼란을 정리하는 것뿐만 아니라 영향을받는 시스템을 완전히 재구성하는 서비스 복구 작업을 계획하십시오.
  • 경우에 따라 서비스 복구 시간이 부족하여 손상이 발생한 것을 식별 한 직후에 디스크 이미지를 가져와야하며 법적 증거를 보유하지 않아야합니다. 서비스가 재 구축되면 무슨 일이 있었는지 알아내는 작업이 시작될 수 있습니다.
• 침입자가 침입 한 방법 및 한 번 수행 한 작업과 관련된 정보를 보려면 로그 파일을 확인하십시오.
• 들어온 방법 및 들어온 내용과 관련된 정보를 위해 변경된 파일을 확인하십시오.
• 방화벽 로그를 통해 데이터의 출처, 데이터를 보낸 위치 및 전송 한 데이터 양에 대한 정보를 확인하십시오.

타협 전에 정책과 절차를 마련 하고 타협이 발생 했을 때이를 구현할 사람들에게 잘 알려진 것은 단지 필요한 일입니다. 사람들이 똑바로 생각하지 않을 때 모든 사람에게 대응 프레임 워크를 제공합니다. 고위 경영진은 소송과 형사 고발에 대해 우호적 일 수 있지만 실제로 사건을한데 모으는 것은 비용이 많이 드는 과정이며 사전에 분노를 약화시킬 수 있음을 아는 것입니다.

또한 이러한 종류의 이벤트는 전체 재난 대응 계획에 반영되어야합니다. 타협은 '손실 된 하드웨어'응답 정책을 트리거 할 가능성이 높으며 '데이터 손실'응답을 트리거 할 가능성이 높습니다. 서비스 복구 시간을 알면 서비스 복구에 필요하기 전에 보안 대응 팀이 실제 손상된 시스템 (법적 증거를 유지하지 않는 경우)을 넘겨 줄 수있는 시간에 대한 기대치를 설정하는 데 도움이됩니다.

적절한 헬프 데스크 절차가 도움이 될 수있는 방법

고객이 여기에서 처리되는 방식을 고려해야합니다 (헬프 데스크에 문의하는 내부 및 외부 고객 모두에게 적용됨).

우선, 의사 소통이 중요합니다 . 사용자는 비즈니스 중단에 대해 화를 내며 침입의 일부로 발생할 수있는 정보 유출의 정도 / 결과에 대해 우려 할 수 있습니다. 이러한 사람들에게 정보를 제공하면 지식을 공유하는 것이 좋다는 관점과 그들이들을 필요가 있다는 약간 덜 분명한 관점에서 자신의 분노와 우려를 관리하는 데 도움이 될 것입니다. 상태.

이 시점에서 헬프 데스크 및 IT 관리는 "우산"으로 작동하여 침입을 수행하는 사람들을 보호하고 그 작업을 방해하는 수많은 문의로부터 서비스를 복원합니다.

1. 고객에게 현실적인 업데이트를 시도하고 게시하고 고객과 협력하여 서비스를 온라인으로 복구해야하는 긴급 성을 결정하십시오. 고객의 요구를 인식하는 것이 중요하지만 동시에 고객에게 실행 불가능한 일정을 지시 할 수는 없습니다.
2. 헬프 데스크 팀이 어떤 정보를 공개 할 수 있고 공개 할 수 없는지, 그리고 소문과 추측을 장려해서는 안된다는 것을 확인하십시오 (그리고 조직이 취하거나 겪을 수있는 법적 조치를 방해 할 수있는 어떠한 것도 절대 논의해서는 안됩니다).
3. 헬프 데스크가 수행해야 할 한 가지 긍정적 인 일은 침입과 관련된 모든 통화를 기록하는 것입니다. 이는 침입 자체와이를 처리하기 위해 수행 한 프로세스로 인한 중단을 측정하는 데 도움이 될 수 있습니다. 침입과 완화에 시간과 재정 비용을 모두 투입하는 것은 미래의 전략을 개선하는 데 매우 도움이 될 수 있으며 모든 법적 조치에 분명히 도움이 될 수 있습니다. ITIL 사건과 문제 기록 은 여기에서 도움이 될 수 있습니다. 침입 자체와 완화는 별도의 문제로 기록 될 수 있으며 각 발신자는 하나 또는 두 문제 모두의 사건으로 추적됩니다.

배포 표준이 도움이되는 방법

세트 템플리트 (또는 최소한 체크리스트)에 배치하면 배치 템플리트의 사용자 정의 / 업그레이드에 대한 변경 제어 / 관리 연습과 함께 도움이됩니다. 다른 작업을 수행하는 서버 (예 : 메일 서버 템플릿, 웹 서버 템플릿 등)를 설명하기 위해 여러 템플릿을 가질 수 있습니다.

템플릿은 OS와 앱 모두에서 작동해야하며, 보안뿐만 아니라 사용하는 모든 설정을 포함해야하며, 사람의 실수를 최대한 제거하기 위해 수동 (예 : 체크리스트)을 적용하는 것이 아니라 스크립트 (예 : 템플릿)를 사용하는 것이 이상적입니다.

이것은 여러 가지 방법으로 도움이됩니다.

• 당신이 / 복원 침입이 걸릴 장소 (당신이주의하지하는 경우에 빨리 다시 할 수 있습니다 안 이 템플릿이 때문에 '있는 그대로'에서 배포 알고 취약이다, 그러나 당신이 다시 "마지막으로 성공한 구성을 얻을 수 있습니다 " 라이브 배포 전에 추가 강화 작업을 수행해야합니다. 배포 템플릿이 제대로 잠겨 있는지 확인한 후 배포 템플릿을 업데이트해야합니다.)
• 해킹 된 서버와 비교할 수있는 "기준"을 제공합니다
• 처음에는 침입으로 이어질 수있는 불필요한 오류를 줄입니다.
• 보안을 위해 패치 / 업그레이드 또는 절차 적 변경이 필요한 경우 (또는 해당 사안에 대한 다른 이유) 변경이 필요한 시스템을 쉽게 확인하고 테스트를 작성하기 쉽기 때문에 변경 및 패치 관리에 도움이됩니다. 변경 사항이 올바르게 적용되는지 확인하십시오.
• 모든 것이 가능한 한 일관적이고 합리적이라면, 비정상적이고 의심스러운 사건이 조금 더 튀어 나오도록 도와줍니다.

대부분의 서버는 대부분의 예방을 위해 호스트 및 네트워크 방화벽, 안티 바이러스 / 스파이웨어 소프트웨어, 네트워크 IDS 및 호스트 IDS를 사용합니다. 여기에는 최소 개인 정보, 필수가 아닌 프로그램 제거, 업데이트 등의 모든 일반 지침과 함께 Nagios, Cacti 및 SIEM 솔루션과 같은 제품을 사용하여 다양한 기본 라이닝 및 이벤트 발생시기 알림을 제공합니다. 우리의 HIDS (OSSEC)는 많은 SIEM 유형 로깅을 수행합니다. 우리는 기본적으로 가능한 한 많은 것을 차단하려고 시도하지만, 중앙에 로그인하여 어떤 일이 발생하면 분석하고 상관시킬 수 있습니다.

실제로 원하는 것은 3 가지 기본 영역으로 나눌 수 있습니다.

1. 표준 시스템 구성
2. 시스템 / 애플리케이션 모니터링
3. 사고 대응

이용 가능한 정보 (보증) 담당자가 있다면 반드시 그들과 대화해야합니다. 인시던트 응답은 종종 해당 사무소의 유일한 목적이지만 나머지는 영향을받는 모든 당사자에 대한 공동 개발 노력이어야합니다.

셀프 포밍의 위험이 있으므로 관련 질문에 대한이 답변은 유용한 리소스를 많이 색인화해야합니다 . LAMP 서버 보안을위한 팁.

이상적으로는 지원되는 OS 수가 가장 적고 기본 이미지를 사용하여 각 OS를 빌드해야합니다. 서버가 제공하는 모든 서비스를 제공하는 데 필요한만큼만베이스에서 벗어나야합니다. 편차는 문서화되어야하거나 PCI / HIPAA / etc 등을 충족해야하는 경우 필요할 수 있습니다. 또는 기타 규정 준수. 배포 및 구성 관리 시스템을 사용하면 이와 관련하여 많은 도움이 될 수 있습니다. 구체적인 내용은 OS, cobbler / puppet / Altiris / DeployStudio / SCCM 등에 크게 좌우됩니다.

정기적 인 로그 검토를 수행해야합니다. 옵션이 주어지면 SIEM이 매우 도움 이 될 수 있지만 구매 가격과 구축 비용 모두 비싸다는 단점이 있습니다. 로그 분석에 대한 의견은 IT Security SE 사이트에서이 질문을 확인하십시오. 로그 분석을 어떻게 처리합니까? 여전히 너무 무거 우면 LogWatch와 같은 일반적인 도구조차도 상황에 대한 좋은 컨텍스트를 제공 할 수 있습니다. 그러나 중요한 부분은 로그를 전혀 보는 데 시간이 걸리는 것입니다. 이것은 정상적인 행동을 구성하는 것에 익숙해 져서 비정상을 인식하는 데 도움이됩니다.

로그 검토 외에도 서버 상태를 모니터링하는 것도 중요합니다. 계획 여부에 관계없이 언제 변경이 발생하는지 아는 것이 중요합니다. Tripwire 와 같은 로컬 모니터링 도구를 사용 하면 관리자에게 변경 사항을 알릴 수 있습니다. 불행히도 SIEM 및 IDSes와 마찬가지로 튜닝 및 / 또는 구매 비용이 비싸다는 단점이 있습니다. 또한, 적절한 조정이 없으면 경보 임계 값이 너무 높아서 양호한 메시지가 잡음으로 손실되고 쓸모 없게됩니다.

적절한 SIEM ( Security Information and Event Management ) 정책을 사용하면 보안 수명을 쉽게 연장 할 수 있습니다.

나는 보안 전문가가 아니므로 주로 그들에게 연기합니다. 그러나 최소한의 특권으로 시작 하면 거의 항상 작업이 훨씬 쉬워집니다. 이를 치유 치료와 같이 적용하면 파일 권한, 런타임 사용자, 방화벽 규칙 등 보안의 여러 측면에서 효과적입니다. KISS는 결코 해를 끼치 지 않습니다.

여기에 언급 된 대부분의 솔루션은 호스트 및 네트워크 수준에서 적용 가능하지만 안전하지 않은 웹 응용 프로그램은 잊어 버리는 경우가 많습니다. 웹 응용 프로그램은 가장 일반적으로 간과되는 보안 허점입니다. 웹 응용 프로그램을 통해 공격자는 데이터베이스 나 호스트에 액세스 할 수 있습니다. 방화벽, IDS, 방화벽은 이러한 방화벽으로부터 사용자를 보호 할 수 없습니다. OWASP는 가장 중요한 10 가지 취약점 목록을 유지 관리하고 이에 대한 수정 사항을 제공합니다.

http://www.scribd.com/doc/19982/OWASP-Web-Security-Guide