이 페이지의 내용

감사 침입 및 보안 이벤트 모니터링 요약

아무리 안전한 환경이라도 침입과 공격을 적극적으로 모니터링해야 합니다. 보안 시스템을 갖추고 있다고 해서 공격을 받지 않을 것이라고 생각한다면 잘못된 것입니다.

침입을 감사하고 모니터링하는 것은 다음과 같은 여러 가지 이유에서 중요합니다.

• 실행 중인 컴퓨터 환경은 공격에 노출될 가능성이 있습니다. 보안이 아무리 철저해도 공격 받을 위험은 있게 마련입니다.
• 공격은 보통 몇 번의 실패 끝에 성공합니다. 공격을 모니터링하지 않으면 성공하기까지 시도된 공격을 찾아낼 수 없습니다.
• 성공한 공격을 빨리 찾아낼수록 손해를 더 빨리 막을 수 있습니다.
• 공격에서 복구하려면 공격으로 입은 손해를 파악해야 합니다.
• 감사 및 침입 감지를 통하여 공격자를 알아낼 수 있습니다.
• 감사와 침입 감지를 결합하면 정보를 연관시켜 공격 패턴을 파악하는 데 도움이 됩니다.
• 보안 로그를 정기적으로 검토하면 잘못된 권한 또는 느슨한 계정 잠금 설정 등 드러나지 않았던 보안 구성 문제를 식별할 수 있습니다.
• 공격이 감지된 후, 감사 정보를 이용해 손상된 네트워크 리소스를 파악할 수 있습니다.

이 장에서는 사용자 환경을 감사하여 공격을 찾아내는 최선의 방법을 제공하고, 공격이 발생하고 있음을 나타내는 동작을 감지하도록 특별히 설계된 소프트웨어인 침입 감지 시스템의 사용을 포함하여 침입 모니터링에 대한 내용을 다룹니다.

감사

전반적인 보안 전략의 일부로 사용자 환경에 맞는 감사 수준을 결정해야 합니다. 감사에서는 성공 여부에 관계 없이 네트워크를 위협하는 공격 또는 위험 평가에 따라 유용하다고 판단한 리소스에 대한 공격을 식별해야 합니다.

감사 범위를 결정할 때는 범위가 넓어질수록 감사 이벤트가 더 많이 생성되고 따라서 중대한 이벤트를 찾아내기가 더욱 어려워진다는 점을 명심해야 합니다. 감사 범위가 광범위한 경우 중요한 이벤트를 필터링하는 Microsoft Operations Manager와 같은 추가 도구의 사용을 고려해야 합니다.

감사 이벤트는 성공 이벤트와 실패 이벤트의 두 범주로 나눌 수 있습니다. 성공 이벤트는 사용자가 리소스에 성공적으로 액세스했음을 나타내고 실패 이벤트는 액세스를 시도했지만 실패했음을 나타냅니다. 실패 이벤트는 사용자 환경에서의 공격 시도를 추적하는 데 매우 유용하지만 성공 이벤트는 해석하기가 훨씬 어렵습니다. 성공 감사 이벤트는 대부분 단순히 정상적인 작동을 나타내는 것이지만, 가까스로 시스템에 대한 액세스 권한을 얻은 공격자 역시 성공 이벤트를 생성합니다. 경우에 따라서는 이벤트 패턴이 이벤트 자체만큼이나 중요합니다. 예를 들어, 여러 번 실패한 끝에 성공한 경우 이는 시도된 공격이 궁극적으로 성공했음을 나타내는 것일 수 있습니다.

가능하면 감사 이벤트를 사용자에 대하여 확보한 다른 정보와 결합해야 합니다. 예를 들어, 사용자가 휴가를 떠날 경우 휴가 기간 동안 해당 사용자의 계정을 비활성화한 후 기간 중에 계정이 다시 활성화되는지 감사할 수 있습니다.

감사 활성화 방법

사이트, 도메인, OU 또는 로컬 시스템 수준에서 그룹 정책을 사용하여 감사를 활성화합니다. 감사 정책 설정은 다음 위치에 있습니다.

컴퓨터 구성\Windows 설정\보안 설정\로컬 정책\감사 정책

일반적으로 Active Directory 계층 구조의 상위 수준에서 감사를 구현하여 감사 설정의 일관성을 유지해야 합니다. 이 가이드에서는 구성원 서버 및 도메인 컨트롤러 OU 수준에서 감사를 구현합니다. 자세한 내용은 4장 "역할 기반의 서버 보안"을 참조하십시오.

도메인과 다르게 감사를 수행하고자 하는 서버가 있을 수 있습니다. 로컬 시스템에 대한 그룹 정책을 편집하거나 Windows 2000 Server Resource Kit의 Auditpol.exe 유틸리티를 사용하여 이러한 시스템에서 감사를 구성할 수 있습니다.

참고:로컬 시스템에 대한 그룹 정책에 액세스하려면 MMC를 시작한 다음 그룹 정책 스냅인을 추가하여 로컬 컴퓨터를 스냅인의 포커스로 설정하십시오.

이벤트 로그 설정 정의

감사에 의해 생성된 모든 이벤트는 이벤트 뷰어에 나타납니다. 생성된 이벤트가 이벤트 로그에 저장되는 방법을 결정해야 합니다. 이벤트 뷰어나 그룹 정책에서 각 설정을 직접 정의할 수 있습니다. 이 가이드에서는 그룹 정책에서 이벤트 뷰어 설정을 정의합니다. 권장 설정 방법은 4장 "역할 기반의 서버 보안"을 참조하십시오.

그룹 정책에 정의된 설정을 수정하거나 다른 수준에서 설정을 적용해야 할 경우가 있습니다. 예를 들어, IIS 서버에서 보안 로그가 꽉 차서 시스템이 종료되었을 수 있습니다. 이를 방지하려면 IIS 서버 OU에서 그룹 정책을 수정하여 보안 로그의 크기를 늘리거나 보안 로그가 꽉 차도 시스템이 종료되지 않도록 정책을 수정해야 합니다. 그룹 정책에서 보안 로그 설정을 정의하려면 다음과 같이 하십시오.

OU에서 그룹 정책을 사용하여 이벤트 로그 설정을 수정하려면

1. 시작을 누르고관리 도구를 선택한 다음Active Directory 사용자 및 컴퓨터를 선택합니다.
2. 콘솔 트리에서 감사 정책을 정의할 OU를 마우스 오른쪽 단추로 누른 다음등록 정보를 누릅니다.
3. 그룹 정책탭을 선택하고 편집할그룹 정책 개체를 선택한 다음편집을 누릅니다.
4. 그룹 정책 편집기에서컴퓨터 구성\Windows 설정\보안 설정\이벤트 로그\이벤트 로그 설정으로 이동합니다.
5. 사용자 요구 사항에 맞게 설정을 수정합니다.

그룹 정책에서 이벤트 뷰어 설정을 제거하는 경우 대신 이벤트 뷰어에서 직접 정의할 수 있습니다. 그러나 비슷한 컴퓨터에서 일관된 설정이 적용되도록 그룹 정책에서 이벤트 뷰어 설정을 정의하는 것이 좋습니다.

감사할 이벤트

Windows 2000에서는 보안 이벤트에 사용할 수 있는 몇 가지 감사 범주를 제공합니다. 기업의 감사 전략을 설계할 때 다음과 같은 보안 감사 이벤트 범주를 포함시킬 것인지 결정해야 합니다.

• 로그온 이벤트
• 계정 로그온 이벤트
• 개체 액세스
• 디렉터리 서비스 액세스
• 권한 사용
• 프로세스 추적
• 시스템 이벤트
• 정책 변경

다음 절에서는 특정 범주에 대해 감사를 사용할 때 반환되는 일반적인 몇 가지 이벤트 ID에 대해 자세히 설명합니다.

참고:이벤트 로그 정보를 검색하고 수집하는 데 사용하는 도구에 대해서는 이 장 뒷부분의 "수동적 감지 방법"에서 설명합니다.

로그온 이벤트

로그온 이벤트를 감사하는 경우 사용자가 컴퓨터에 로그온하거나 로그오프할 때마다 로그온이 시도된 컴퓨터의 보안 로그에 이벤트가 생성됩니다. 사용자가 원격 서버에 연결할 때에도 원격 서버의 보안 로그에 로그온 이벤트가 생성됩니다. 로그온 이벤트는 로그온 세션 및 토큰이 작성되거나 삭제될 때 각각 만들어집니다.

로그온 이벤트는 서버에서 대화형으로 로그온하려고 한 시도를 추적하거나 특정 컴퓨터에서 시작된 공격을 조사하는 데 유용합니다. 성공 감사는 로그온 시도가 성공할 때 감사 항목을 생성합니다. 실패 감사는 로그온 시도가 실패할 때 감사 항목을 생성합니다.

참고:로그온 이벤트에는 컴퓨터 및 사용자 로그온 이벤트가 모두 포함됩니다. Windows NT 또는 Windows 2000 기반 컴퓨터에서 네트워크 연결이 시도된 경우 컴퓨터 계정 및 사용자 계정 모두에 대해 별도의 보안 이벤트 로그 항목이 나타납니다. Windows 9x 기반 컴퓨터에서는 디렉터리에 컴퓨터 계정이 없으며 네트워크 로그온 이벤트에 대해 컴퓨터 로그온 이벤트 항목이 생성되지 않습니다.

구성원 서버 및 도메인 컨트롤러 기본 정책의 일부로, 성공 및 실패 로그온 이벤트에 대한 감사가 활성화됩니다. 따라서 터미널 서비스를 실행하는 컴퓨터에 연결하는 터미널 서비스 로그온 및 대화형 로그온에 대해 다음과 같은 이벤트 ID가 예상됩니다.

표 6.1: 이벤트 로그에 나타나는 로그온 이벤트

로그온 이벤트 항목을 사용하여 다음 보안 이벤트를 진단할 수 있습니다.

• 로컬 로그온 시도 실패다음 이벤트 ID는 실패한 로그온 시도를 나타냅니다. 529, 530, 531, 532, 533, 534 및 537. 공격자가 로컬 계정의 사용자 이름과 암호 조합을 추측하려 했지만 실패한 경우 이벤트 529 및 534가 발생합니다. 하지만 이러한 이벤트는 사용자가 암호를 잊어버렸거나 네트워크 환경을 통해 네트워크 탐색을 시작한 경우에도 발생할 수 있습니다. 대규모 환경에서는 이러한 이벤트를 효율적으로 해석하기가 어렵습니다. 일반적으로, 이런 패턴이 반복적으로 발생하거나 다른 비정상적인 요인과 함께 발생하는 경우에는 조사를 해야 합니다. 예를 들어, 한밤중에 529 이벤트가 여러 번 발생한 후에 528 이벤트가 발생하면 암호 공격이 성공했음을 나타내는 것일 수 있습니다. 물론 관리자가 실수한 것일 수도 있습니다.
• 계정의 잘못된 사용530, 531, 532 및 533 이벤트는 모두 사용자 계정이 잘못 사용되었음을 나타냅니다. 모두 계정/암호 조합이 올바르게 입력되었지만 다른 제한에 의해 로그온이 성공하지 못했음을 나타냅니다. 가능하면 이벤트를 조사하여 잘못 사용한 적이 있었는지 또는 현재의 제한 사항을 수정해야 하는지 판단해야 합니다. 예를 들면 특정 계정의 로그온 시간을 늘려야 할 수도 있습니다.
• 계정 잠김이벤트 539는 계정이 잠겼음을 나타냅니다. 암호 공격이 실패했음을 나타낼 수도 있습니다. 같은 사용자의 이전 529 이벤트를 찾아서 로그온 시도 패턴을 확인해야 합니다.
• 터미널 서비스 공격터미널 서비스 세션이 끝난 후에도 프로세스가 계속 실행될 수 있도록 세션이 연결된 상태로 남아 있을 수 있습니다. 이벤트 ID 683은 사용자가 터미널 서비스 세션에서 로그아웃하지 않았음을 나타내고 이벤트 ID 682는 전에 연결이 끊긴 세션에 다시 연결되었음을 나타냅니다.

계정 로그온 이벤트

사용자가 도메인에 로그온하면 도메인 컨트롤러에서 로그온이 처리됩니다. 도메인 컨트롤러에서 계정 로그온 이벤트를 감사하는 경우 계정이 유효한지 확인하는 도메인 컨트롤러에 이 로그온 시도가 기록됩니다. 인증 패키지에서 사용자 자격 증명이 유효한지 확인할 때 계정 로그온 이벤트가 생성됩니다. 도메인 자격 증명이 사용될 때 계정 로그온 이벤트는 도메인 컨트롤러의 이벤트 로그에만 생성됩니다. 제시한 자격 증명이 로컬 SAM 데이터베이스 자격 증명인 경우 계정 로그온 이벤트는 서버 보안 이벤트 로그에 생성됩니다.

계정 로그온 이벤트는 도메인 내의 유효한 아무 도메인 컨트롤러에나 기록될 수 있으므로 도메인 컨트롤러 간에 보안 로그를 통합하여 도메인 내의 모든 계정 로그온 이벤트를 분석해야 합니다.

참고:로그온 이벤트와 마찬가지로 계정 로그온 이벤트에도 컴퓨터 및 사용자 로그온 이벤트가 모두 포함됩니다.

구성원 서버 및 도메인 컨트롤러 기본 정책의 일부로 성공 및 실패 계정 로그온 이벤트에 대한 감사가 활성화됩니다. 따라서 네트워크 로그온 및 터미널 서비스 인증에 대해 다음과 같은 이벤트 ID가 예상됩니다.

표 6.2: 이벤트 로그에 나타나는 계정 로그온 이벤트

이러한 이벤트 각각에 대해 이벤트 로그에 각 개별 로그온에 대한 자세한 정보가 나타납니다. 계정 로그온 이벤트 항목을 사용하여 다음 보안 이벤트를 진단할 수 있습니다.

• 도메인 로그온 시도 실패이벤트 ID 675와 677은 도메인에 로그온하는 데 실패했음을 나타냅니다.
• 시간 동기화 문제클라이언트 컴퓨터의 시간이 인증 도메인 컨트롤러의 시간과 5분(기본값) 이상 차이가 날 경우 보안 로그에 이벤트 ID 675가 나타납니다.
• 터미널 서비스 공격터미널 서비스 세션이 끝난 후에도 프로세스가 계속 실행될 수 있도록 터미널 서비스 세션이 연결된 상태로 남아 있을 수 있습니다. 이벤트 ID 683은 사용자가 터미널 서비스 세션에서 로그아웃하지 않았음을 나타내고 이벤트 ID 682는 전에 연결이 끊긴 세션에 다시 연결되었음을 나타냅니다. 연결이 끊어지는 것을 막거나 연결이 끊긴 세션을 끝내려면 RDP-TCP 프로토콜 등록 정보의 터미널 서비스 구성 콘솔에서연결이 끊긴 세션을 끝내는 시간 간격을 정의하십시오.

계정 관리

계정 관리 감사는 사용자나 그룹이 작성, 변경 또는 삭제된 시간을 판단하는 데 사용됩니다. 이 감사를 사용하여 보안 사용자가 작성된 시간 및 작업을 수행한 사람을 알 수 있습니다.

구성원 서버 및 도메인 컨트롤러 기본 정책의 일부로 계정 관리 내의 성공 및 실패에 대한 감사가 활성화됩니다. 따라서 보안 로그에 다음과 같은 이벤트 ID가 기록됩니다.

표 6.3: 이벤트 로그에 나타나는 계정 관리 이벤트

보안 로그 항목을 참조하여 다음 계정 관리 이벤트를 진단할 수 있습니다.

• 사용자 계정 만듦이벤트 ID 624와 626은 사용자 계정이 만들어진 시간과 활성화된 시간을 확인합니다. 계정 작성이 조직 내의 특정인에게만 제한되는 경우에 이 두 이벤트를 사용하여 권한이 없는 사람이 사용자 계정을 작성했는지 여부를 확인할 수 있습니다.
• 사용자 계정 암호 변경됨사용자 이외의 사람이 암호를 수정한 경우 다른 사용자가 계정을 탈취한 것일 수 있습니다. 암호 변경을 시도하여 성공했음을 나타내는 이벤트 ID 627 및 628을 찾으십시오. 이벤트 정보를 검토하여 다른 사용자 계정에서 암호 변경을 수행했는지 또는 해당 계정이 사용자 계정 암호를 재설정할 수 있는 헬프 데스크나 기타 서비스 지원팀 직원의 계정인지를 확인합니다.
• 사용자 계정 상태가 변경됨공격자는 공격하는 동안 사용한 계정을 삭제하거나 비활성화하여 흔적을 숨기려고 시도할 수 있습니다. 발생한 모든 이벤트 ID 629 및 630을 조사하여 권한이 있는 트랜잭션인지 확인해야 합니다. 또한 이벤트 ID 626이 발생한 다음 얼마 지나지 않아 이벤트 ID 629가 발생한 경우를 찾아보십시오. 이는 비활성화된 계정이 활성화되어 사용되었다가 다시 비활성화되었음을 나타내는 것일 수 있습니다.
• 보안 그룹 수정도메인 관리자, 관리자, 운영자 그룹 또는 관리 기능을 위임 받은 사용자 정의 글로벌, 범용 또는 도메인 로컬 그룹으로 구성원 변경 내용을 검토해야 합니다. 글로벌 그룹 구성원 수정의 경우 이벤트 ID 632 및 633을 찾고 도메인 로컬 그룹 구성원 수정의 경우에는 이벤트 ID 636 및 637을 찾으십시오.
• 계정 잠금계정이 잠기면 PDC 에뮬레이터 작업 마스터에 두 개의 이벤트가 기록됩니다. 644 이벤트는 계정 이름이 잠겼음을 나타내므로 이 이벤트 뒤에 642 이벤트가 기록되면 현재 계정이 잠겨 있음을 알리기 위해 사용자 계정이 변경됨을 나타냅니다. 이 이벤트는 PDC 에뮬레이터에만 기록됩니다.

개체 액세스

시스템 액세스 컨트롤 목록(SACL)이 있는 Windows 2000 기반 네트워크의 모든 개체에 대해 감사를 활성화할 수 있습니다. SACL에는 개체에 대한 작업을 감사 대상 사용자 및 그룹 목록이 들어 있습니다. Windows 2000에서 조작할 수 있는 대부분의 개체에는 SACL이 있습니다. 여기에는 NTFS 드라이브, 프린터 및 레지스트리 키의 파일 및 폴더가 포함됩니다.

SACL은 액세스 제어 항목(ACE)들로 구성됩니다. 각 ACE에는 세 가지 정보가 들어 있습니다.

• 감사할 보안 사용자
• 감사할 특정 액세스 유형(액세스 마스크라고 함)
• 실패, 성공 또는 둘 다 등 감사할 액세스 유형을 표시하는 플래그

보안 로그에 이벤트를 표시하려면 먼저개체 액세스 감사를 활성화한 후 감사할 각 개체에 대해 SACL을 정의합니다.

Windows 2000에서의 감사는 개체에 대한 핸들이 열릴 때 생성됩니다. Windows 2000에서는 커널을 통해서만 프로그램이 개체에 액세스하도록 허용하는 커널 모드 보안 하위 시스템을 사용합니다. 이 시스템을 사용하면 프로그램에서 보안 시스템을 건너뛰려고 시도할 수 없습니다. 커널 메모리 공간이 사용자 모드 프로그램과 분리되어 있으므로 프로그램은 핸들이라는 데이터 구조를 통해 개체를 참조합니다. 다음은 전형적인 액세스 시도입니다.

1. 사용자가 프로그램에게 개체(예:파일/열기)에 액세스하도록 지시합니다.
2. 프로그램이 원하는 액세스 종류(읽기, 쓰기 등)를 지정하여 시스템의 핸들을 요청합니다.
3. 보안 하위 시스템이 요청된 개체의 DACL을 사용자 토큰과 비교하여, DACL에서 사용자 그룹이나 사용자와 일치하며 프로그램이 요청한 액세스 권한도 갖는 항목을 찾습니다.
4. 시스템이 요청된 개체의 SACL을 사용자 토큰과 비교하여, SACL에서 프로그램에 반환되는 적절한 권한이나 프로그램이 요청한 권한과 일치하는 항목을 찾습니다. 일치하는 실패 감사 ACE가 요청되었으나 승인되지는 않은 액세스와 일치하면 실패 감사 이벤트가 생성됩니다. 일치하는 성공 감사 ACE가 허가된 액세스와 일치하면 성공 감사 이벤트가 생성됩니다.
5. 액세스가 허가되면 시스템은 프로그램에 핸들을 반환하므로 핸들을 사용하여 개체에 액세스할 수 있습니다.

감사가 일어나고 이벤트가 생성되는 시점에는 아직 개체에 수행된 작업이 없다는 점에 유의해야 합니다. 이것은 감사 이벤트를 해석할 때 중요한 사항입니다. 파일을 쓰기 전에 쓰기 감사가 생성되고 파일을 읽기 전에 읽기 감사가 생성됩니다.

모든 감사에서 그렇듯이 감사하는 개체 액세스도 대상을 정해 놓고 접근해야 합니다. 감사 계획에서, 감사해야 하는 개체 유형을 결정하고 감사된 각 개체 유형에 대해 모니터링할 액세스 시도 유형(성공, 실패 또는 둘 다)을 결정하십시오. 감사 대상이 너무 광범위하면 시스템 성능에 많은 영향을 주고 필요 이상으로 많은 데이터가 수집됩니다.

감사를 시행할 때는 일반적으로 신뢰할 수 없는 계정에서 시도된 액세스를 포함하여 선택된 개체에 대한 모든 액세스를 감사하려고 할 것입니다. 이렇게 하려면 감사할 개체의 SACL에 Everyone 그룹을 추가합니다. 개체 액세스 성공을 감사할 때 조심해야 합니다. 감사 과정에서 보안 로그에 아주 많은 감사 항목이 작성될 수 있습니다. 그러나 중요한 파일의 삭제를 조사하는 경우에는 성공 감사 이벤트를 검사하여 파일을 삭제한 사용자 계정을 판단해야 합니다.

구성원 서버 및 도메인 컨트롤러 기본 정책은 개체 액세스의 성공 및 실패를 모두 감사하도록 설정됩니다. 그러나 개체 자체에 대해서는 아무런 SACL도 설정되지 않으므로 사용자 환경의 요구에 맞게 설정해야 합니다. SACL은 개체에서 직접 정의하거나 그룹 정책을 사용하여 정의할 수 있습니다. 감사를 요구하는 개체가 여러 컴퓨터에 존재하는 경우 그룹 정책에서 SACL을 정의해야 합니다.

개체 액세스에 대한 감사 결과 보안 로그에 다음 이벤트가 나타납니다.

표 6.4: 이벤트 로그에 나타나는 개체 액세스 이벤트

특정 개체 액세스 이벤트를 찾는 경우 먼저 이벤트 ID 560을 조사해야 합니다. 이벤트 정보에는 유용한 정보가 들어 있으므로 검색할 특정 이벤트를 찾으려면 이벤트 정보를 검색해야 합니다. 표 6.5는 수행해야 하는 일부 작업 및 수행 방법을 보여줍니다.

표 6.5: 개체 액세스 이벤트 560에 대한 주요 감사 작업 수행 방법

디렉터리 서비스 액세스

Active Directory 개체에는 이와 연관된 SACL이 있으므로 감사할 수 있습니다. 이미 설명했듯이 계정 관리를 감사하여 Active Directory 사용자 및 그룹 계정을 감사합니다. 그러나 구성 및 스키마 명명 컨텍스트와 같은 다른 명명 컨텍스트의 개체에 대한 수정을 감사하려면 개체 액세스를 감사한 후 감사할 특정 컨테이너에 대해 SACL을 정의해야 합니다. Active Directory 개체의 SACL에 나열된 사용자가 해당 개체에 액세스를 시도할 때 감사 항목이 생성됩니다.

ADSIEDIT MMC 스냅인을 사용하여 구성 명명 컨텍스트(및 기타 명명 컨텍스트)에서 개체 및 컨테이너에 대한 SACL을 수정할 수 있습니다. 필요한 컨텍스트를 ADSIEDIT 콘솔에 표시한 다음고급 보안 설정대화 상자에서 개체에 대한 SACL을 수정하면 됩니다.

발생한 이벤트가 아주 많고 대부분이 문제가 없는 이벤트이므로 디렉터리 서비스 액세스에 대한 특정 이벤트를 찾기는 매우 어렵습니다. 따라서 구성원 서버 및 도메인 컨트롤러 기본 정책은 디렉터리 서비스 액세스에 대해 실패한 이벤트만 감사합니다. 이는 공격자가 Active Directory에 대해 권한이 없는 액세스를 시도한 시간을 확인하는 데 도움이 됩니다.

시도된 디렉터리 액세스는 보안 로그에 ID 565의 디렉터리 서비스 이벤트로 표시됩니다. 보안 이벤트 정보의 세부 사항을 확인해야만 이벤트와 관련한 개체를 알 수 있습니다.

권한 사용

사용자는 IT 환경에서 작업하면서 정의된 사용자 권한을 이용합니다. 권한 사용의 성공 및 실패를 감사할 경우 사용자 권한을 이용하려고 할 때마다 이벤트가 생성됩니다.

권한 사용을 감사하더라도 모든 사용자 권한이 감사되는 것은 아닙니다. 기본적으로 다음 사용자 권한은 감사에서 제외됩니다.

• 통과 검사 생략
• 프로그램 디버그
• 토큰 개체 작성
• 프로세스 수준 토큰 바꾸기
• 보안 감사 생성
• 파일 및 디렉터리 백업
• 파일 및 디렉터리 복원

그룹 정책에서백업 및 복원 권한 사용 감사보안 옵션을 활성화하여 백업 및 복원 사용자 권한을 감사하지 않는 기본 동작을 무시할 수 있습니다.

권한 사용 성공을 감사하면 보안 로그에 아주 많은 항목이 생성됩니다. 이러한 이유로 구성원 서버 및 도메인 컨트롤러 기본 정책은 권한 사용 실패만 감사합니다.

권한 사용에 대한 감사를 활성화하면 다음 이벤트가 생성됩니다.

표 6.6: 이벤트 로그에 나타나는 권한 사용 이벤트

다음은 특정 사용자 권한을 사용할 때 존재할 수 있는 일부 이벤트 로그 항목의 예입니다.

• 운영 체제의 일부로 동작합니다. SeTcbPrivilege 사용자 권한이 표시된 이벤트 ID 577 또는 578을 찾습니다. 이 권한을 사용한 사용자 계정이 이벤트 정보에서 식별됩니다. 이 이벤트는 운영 체제의 일부로 동작하여 보안 권한을 높이려고 한 사용자의 시도를 나타낼 수 있습니다. 예를 들어, GetAdmin 공격에서는 이 권한을 사용한 관리자 그룹에 자신의 계정을 추가하려고 시도합니다. 이 이벤트에 대해 유일한 항목은 시스템 계정 및 이 사용자 권한을 할당한 서비스 계정에 대한 것입니다.
• 시스템 시간을 변경합니다. SeSystemtimePrivilege 사용자 권한이 표시된 이벤트 ID 577 또는 578을 찾습니다. 이 권한을 사용한 사용자 계정이 이벤트 정보에서 식별됩니다. 이 이벤트는 실제로 이벤트가 발생한 시간을 숨기기 위하여 시스템을 변경하려고 했음을 나타낼 수 있습니다.
• 원격 시스템에서 강제로 종료합니다. SeRemoteShutdownPrivilege 사용자 권한이 표시된 이벤트 ID 577 및 578을 찾습니다. 이 권한이 할당된 특정 보안 ID(SID)와 이 권한을 할당한 보안 사용자의 사용자 이름이 이벤트 정보에 들어 있습니다.
• 장치 드라이버를 로드 또는 언로드합니다. SeLoadDriverPrivilege 사용자 권한이 표시된 이벤트 ID 577 또는 578을 찾습니다. 이 권한을 사용한 사용자 계정이 이벤트 정보에서 식별됩니다. 이 이벤트는 사용자가 권한이 없는 또는 트로이 목마 버전 장치 드라이버를 로드하려고 했음을 나타낼 수 있습니다.
• 감사 및 보안 로그를 관리합니다. SeSecurityPrivilege 권한이 표시된 이벤트 ID 577 또는 578을 찾습니다. 이 사용자 권한을 사용한 사용자 계정이 이벤트 정보에서 식별됩니다. 이 이벤트는 이벤트 로그가 삭제될 때와 권한 사용에 대한 이벤트가 보안 로그에 기록될 때 발생합니다.
• 시스템을 종료합니다. SeShutdownPrivilege 사용자 권한이 표시된 이벤트 ID 577을 찾습니다. 이 권한을 사용한 사용자 계정이 이벤트 정보에서 식별됩니다. 이 이벤트는 컴퓨터를 종료하려고 할 때 발생합니다.
• 파일 또는 다른 개체의 소유권을 얻습니다. SeTakeOwnershipPrivilege 사용자 권한이 표시된 이벤트 ID 577 또는 578을 찾습니다. 이 권한을 사용한 사용자 계정이 이벤트 정보에서 식별됩니다. 이 이벤트는 공격자가 개체에 대한 소유권을 얻어서 현재 보안 설정을 건너 뛰려고 시도하고 있음을 나타낼 수 있습니다.

프로세스 추적

Windows 2000 기반 컴퓨터에서 실행되는 프로세스에 대한 자세한 추적 정보를 감사하는 경우 이벤트 로그에 프로세스를 작성하고 종료하려고 한 시도가 나타납니다. 또한 프로세스가 개체에 대한 핸들을 생성하려고 하거나 개체에 대한 간접 액세스를 얻으려고 시도한 시간도 기록됩니다.

작성된 감사 항목 수가 너무 많기 때문에 구성원 서버 및 도메인 컨트롤러 기본 정책은 프로세스 추적에 대한 감사를 활성화하지 않습니다. 그러나 성공 및 실패에 대해 감사하는 경우 다음 이벤트 ID가 이벤트 로그에 기록됩니다.

표 6.7: 이벤트 로그에 나타나는 프로세스 추적 이벤트

시스템 이벤트

사용자나 프로세스가 컴퓨터 환경을 변경하면 시스템 이벤트가 생성됩니다. 컴퓨터 종료나 시스템 시간 변경 등과 같은 시스템 변경 시도를 감사할 수 있습니다.

시스템 이벤트를 감사할 경우 보안 로그가 삭제된 시간도 감사합니다. 공격자가 환경을 변경한 후 흔적을 지우려고 시도하는 경우가 많으므로 이것은 아주 중요합니다.

구성원 서버 및 도메인 컨트롤러 기본 정책은 시스템 이벤트의 성공 및 실패를 감사합니다. 감사 결과 이벤트 로그에 다음 이벤트 ID가 나타납니다.

표 6.8: 이벤트 로그에 나타나는 시스템 이벤트

이러한 이벤트 ID를 사용하여 많은 보안 문제를 찾아낼 수 있습니다.

• 컴퓨터 종료/다시 시작이벤트 ID 513은 Windows 종료를 나타냅니다. 서버가 종료되거나 다시 부팅된 시간을 파악하는 것은 아주 중요합니다. 드라이브나 응용 프로그램을 설치하여 다시 부팅해야 하거나 서버를 유지 보수하기 위해 종료했다가 다시 시작하는 경우 등 부팅이 필요한 경우는 아주 많습니다. 하지만 공격자는 시스템이 시작될 때 시스템에 액세스하기 위해 서버를 강제로 다시 부팅할 수 있습니다. 이벤트 로그와 비교할 수 있도록 컴퓨터가 종료되는 모든 경우를 기록해 두어야 합니다.

  공격은 컴퓨터의 재시작과 관련되어 있는 경우가 많습니다. 이벤트 로그를 조사하여 서버가 다시 시작된 시간과, 이것이 계획되었던 것이었는지 여부를 판단할 수 있습니다. 시스템 로그에 자동으로 생성되는 몇 가지 다른 이벤트와 같이 이벤트 ID 513은 Windows 시작을 나타냅니다. 여기에는 이벤트 로그 서비스가 시작되었음을 나타내는 이벤트 ID 6005가 포함됩니다.

  이 항목 외에 시스템 로그에서 서로 다른 두 이벤트 로그 항목 중 하나를 찾아 보십시오. 관리자가 컴퓨터를 다시 시작한 경우와 같이 이전 종료에 문제가 없다면 이벤트 로그 서비스 중단을 나타내는 이벤트 ID 6006이 시스템 로그에 기록됩니다. 항목의 정보를 조사하여 종료를 시작한 사용자를 판단할 수 있습니다.

  예상치 않은 재시작(이벤트 ID 6008)으로 인해 다시 시작된 경우 <날짜 <시간에 발생한 이전의 시스템 종료는 예상하지 않았던 것입니다. 이것은 컴퓨터를 종료시킨 서비스 거부 공격이 있었음을 의미할 수 있습니다.

  그러나 이 이벤트는 전원 문제나 장치 드라이버 장애로 인해 발생할 수도 있습니다.

  파란색 오류 화면이 나타난 후 시스템이 다시 시작된 경우 시스템 로그에 덤프 저장 소스와 함께 이벤트 ID 1001이 기록됩니다. 실제 파란색 화면의 오류 메시지는 이벤트 정보에서 검토할 수 있습니다.

  참고:이벤트 ID 1001 항목도 기록에 포함시키려면 시스템 제어판 애플릿의 복구 설정 섹션에서시스템 로그에 이벤트 기록옵션의 확인란을 선택해야 합니다.

• 보안 로그 수정 또는 삭제공격자는 감지되는 것을 막기 위하여 보안 로그를 수정하거나 공격하는 동안 감사를 비활성화하거나 보안 로그를 삭제할 수 있습니다. 아주 오랫동안 보안 로그에 기록되는 항목이 없으면 이벤트 ID 612 및 517을 찾아서 감사 정책을 수정한 사용자를 판단하십시오. 발생한 모든 이벤트 ID 517을 보안 로그가 삭제된 시간을 나타내는 실제 로그와 비교해야 합니다. 권한이 없는 사용자가 보안 로그를 삭제한 경우에는 이전의 보안 로그에 있는 이벤트를 숨기기 위한 시도로 볼 수 있습니다. 이벤트 정보에 로그를 삭제한 사용자 이름이 포함됩니다.

정책 변경

감사 정책은 사용자 환경에서 감사할 변경 내용을 정의하므로 공격 시도가 있었는지 판단하는 데 도움이 됩니다. 그러나 철저한 공격자가 변경 내용이 감사되지 않도록 감사 정책 자체를 변경할 수도 있습니다.

정책 변경을 감사하는 경우 감사 정책을 변경하려는 시도뿐 아니라 다른 정책 및 사용자 권한 변경 시도도 파악됩니다. 구성원 서버 및 도메인 컨트롤러 기본 정책은 정책 변경의 성공 및 실패를 감사합니다. 이벤트 로그에서 다음 이벤트를 볼 수 있습니다.

표 6.9: 이벤트 로그에 나타나는 정책 변경 이벤트

여기서 찾아야 할 가장 중요한 이벤트는 이벤트 ID 608과 609입니다. 공격이 여러 번 시도되었기 때문에 이러한 이벤트가 기록되었을 수 있습니다. 아래의 모든 예에서 사용자 권한이 할당된 경우에는 이벤트 ID 608이 생성되고 권한이 제거된 경우에는 609가 생성됩니다. 각 경우에 사용자 권한에 할당된 특정 SID와 권한을 할당한 보안 사용자의 사용자 이름이 이벤트 정보에 기록됩니다.

• 운영 체제의 일부로 동작합니다이벤트 정보에서 seTcbPrivilege 사용자 권한을 갖는 이벤트 ID 608 및 609를 찾습니다.
• 도메인에 워크스테이션을 추가합니다. 이벤트 정보에서 SeMachineAccountPrivilege 사용자 권한을 갖는 이벤트를 찾습니다.
• 파일 및 디렉터리를 백업합니다. 이벤트 정보에서 SeBackupPrivilege 사용자 권한을 갖는 이벤트를 찾습니다.
• 통과 검사를 건너 뜁니다. 이벤트 정보에서 SeChangeNotifyPrivilege 사용자 권한을 갖는 이벤트를 찾습니다. 이 사용자 권한을 사용하면 액세스할 권한이 없는 디렉터리의 트리도 통과할 수 있습니다.
• 시스템 시간을 변경합니다. 이벤트 정보에서 SeSystemtimePrivilege 사용자 권한을 갖는 이벤트를 찾습니다. 이 사용자 권한은 보안 사용자가 시스템 시간을 변경하도록 허용하므로 이벤트가 발생한 시간을 마스크할 가능성이 있습니다.
• 영구 공유 개체를 작성합니다. 이벤트 정보에서 SeCreatePermanentPrivilege 사용자 권한을 갖는 이벤트를 찾습니다. 이 사용자 권한을 갖는 사용자는 파일 및 인쇄 공유를 작성할 수 있습니다.
• 프로그램을 디버그합니다. 이벤트 정보에서 SeDebugPrivilege 사용자 권한을 갖는 이벤트를 찾습니다. 이 사용자 권한을 갖는 사용자는 임의의 프로세스에 접속할 수 있습니다. 기본적으로 이 권한은 관리자에게만 할당됩니다.
• 원격 시스템에서 강제로 종료합니다. 이벤트 정보에서 SeRemoteShutdownPrivilege 사용자 권한을 갖는 이벤트를 찾습니다.
• 예약 우선 순위를 높입니다. 이벤트 정보에서 SeIncreaseBasePriorityPrivilege 사용자 권한을 갖는 이벤트를 찾습니다. 이 권한을 갖는 사용자는 프로세스 우선 순위를 수정할 수 있습니다.
• 장치 드라이버를 로드 및 언로드합니다. 이벤트 정보에서 SeLoadDriverPrivilege 사용자 권한을 갖는 이벤트를 찾습니다. 이 사용자 권한을 갖는 사용자는 트로이 목마 버전의 장치 드라이버를 로드할 수 있습니다.
• 감사 및 보안 로그를 관리합니다. 이벤트 정보에서 SeSecurityPrivilege 사용자 권한을 갖는 이벤트를 찾습니다. 이 사용자 권한을 갖는 사용자는 보안 로그를 보고 삭제할 수 있습니다.
• 프로세스 수준 토큰을 바꿉니다. 이벤트 정보에서 SeAssignPrimaryTokenPrivilege 사용자 권한을 갖는 이벤트를 찾습니다. 이 사용자 권한을 갖는 사용자는 시작된 하위 프로세스와 연관된 기본 토큰을 변경할 수 있습니다.
• 파일 및 디렉터리를 복원합니다. 이벤트 정보에서 SeRestorePrivilege 사용자 권한을 갖는 이벤트를 찾습니다.
• 시스템을 종료합니다. 이벤트 정보에서 SeShutdownPrivilege 사용자 권한을 갖는 이벤트를 찾습니다. 이 사용자 권한을 갖는 사용자는 시스템을 종료하고 새 장치 드라이브 설치를 시작할 수 있습니다.
• 파일 또는 기타 개체의 소유권을 얻습니다. 이벤트 정보에서 SeTakeOwnershipPrivilege 사용자 권한을 갖는 이벤트를 찾습니다. 이 사용자 권한을 갖는 사용자는 개체나 파일의 소유권을 얻어서 NTFS 디스크의 모든 개체나 파일에 액세스할 수 있습니다.

참고:이러한 감사 이벤트는 특정 보안 사용자에게 해당 사용자 권한이 할당되었다는 것만 식별합니다. 즉, 보안 사용자가 해당 권한을 사용하여 작업을 수행했음을 의미하지는 않습니다. 감사 이벤트는 사용자 권한 정책이 수정된 시간을 판단합니다.

참고:사용자 권한 사용에 대한 자세한 내용은 Michael Howard와 David LeBlanc가 저술한 "Writing Secure Code"(Microsoft Press, ISBN: 0-7356-1588-8)를 참조하십시오.

이벤트 로그 보호

나중에 참조할 수 있도록 이벤트 로그 항목을 관리하려면 여러 단계를 거쳐 이벤트 로그의 보안을 유지해야 합니다. 여기에는 다음 작업이 필요합니다.

• 모든 이벤트 로그를 덮어쓰고 관리하는 저장소에 대한 정책을 정의합니다. 정책에 모든 필수 이벤트 로그를 설정하여 그룹 정책으로 적용해야 합니다.
• 정책에 전체 이벤트 로그, 특히 보안 로그를 처리하는 방법이 정의되었는지 확인합니다. 보안 로그가 가득 차면 서버가 종료되도록 하는 것이 좋습니다. 어떤 환경에서는 이렇게 설정하는 것이 실용적이지 않을 수 있지만 이 점은 반드시 고려해야 할 부분입니다.
• 보안 정책 설정을 활성화하여 이벤트 로그에 대한 게스트 액세스를 방지하여 로컬 게스트가 시스템, 응용 프로그램 및 보안 로그에 액세스할 수 없도록 합니다.
• 시스템 이벤트가 성공 및 실패한 경우를 모두 감사하여 보안 로그 내용을 지우려는 시도가 있었는지 확인합니다.
• 감사 설정을 보거나 수정할 수 있는 모든 보안 사용자는 스마트 카드 로그온과 같이 두 가지 요소를 사용한 인증 방법이나 복잡한 암호를 사용하여 보안 사용자 계정 공격을 통해 감사 정보에 액세스하는 것을 막아야 합니다.

이러한 설정은 모두 4장 "역할 기반의 서버 보안"에 설명된 구성원 서버 및 도메인 컨트롤러 그룹 정책 개체에서 정의됩니다.

설명된 단계 외에도 이벤트 로그 정보가 최대한 안전할 수 있도록 실질적인 추가 조치를 취해야 합니다.

• 보안 계획에 모든 서버에 대한 물리적 보안 조치도 포함시켜 공격자가 감사를 수행하는 컴퓨터에 실제로 접근하지 못하도록 해야 합니다. 공격자는 로컬 디스크 하위 시스템에서 실제 *.evt 파일을 수정하거나 삭제하여 감사 항목을 제거할 수 있습니다.
• 실제 서버와는 별도의 위치에서 이벤트 로그를 제거하거나 저장하는 방법을 구현합니다. 예를 들어, 예약된 작업을 사용하여 정기적으로 CD-R이나 한 번 기록 후 반복해서 읽을 수 있는 미디어에 기록해 두거나 서버와는 별도의 위치에 있는 다른 네트워크에 이벤트 로그를 기록하는 방법이 있습니다. 백업을 백업 테이프나 CD-R과 같은 외부 미디어에 복사하는 경우 화재나 기타 자연 재해가 발생했을 때 건물에서 미디어를 옮겨야 합니다.

참고:이벤트 로그에 게스트가 액세스하는 것을 막으면 이벤트 로그에 도메인 구성원이 아닌 사용자가 액세스하는 것을 제한할 뿐입니다. 기본적으로 도메인의 모든 사용자가 시스템 및 응용 프로그램 로그에 액세스할 수 있고 보안 로그에 대한 액세스만이 제한됩니다.감사 및 보안 로그 관리사용자 권한이 할당된 보안 사용자가 보안 로그에 액세스할 수 있습니다. 기본적으로 이 권한은 관리자 및 Exchange Enterprise Server에만 할당됩니다.

기타 감사 구현 방법

감사를 구성하는 것 외에, 서버 환경의 보안을 효율적으로 감사하기 위해 다음과 같은 추가 작업을 수행해야 합니다.

• 이벤트 로그의 정기적인 검토 일정 지정
• 기타 응용 프로그램 로그 파일 검토
• 설치한 서비스 및 드라이버 모니터링
• 열린 포트 모니터링

이벤트 로그의 정기적인 검토 일정 지정

앞에서 설명했듯이 보안 로그 및 생성될 수 있는 기타 이벤트 로그는 중앙에서 통합하거나 이동식 미디어에 기록하여 검토할 수 있도록 해야 합니다. 로그 검토는 감사에서 가장 많이 누락되는 단계입니다.

한 사람 또는 한 팀의 업무에 이벤트 로그 검토를 정기적인 작업으로 명시해야 합니다. 보안 로그에 수집되는 데이터 양에 따라 이벤트 로그 검토 일정을 매일 또는 매주로 지정할 수 있습니다. 일반적으로 일정은 네트워크에 구현된 감사 수준에 따라 달라집니다. 감사에 포함되는 이벤트가 많을수록 로그 항목의 크기가 커집니다. 정기적인 이벤트 로그 검토 일정을 지정하면 다음과 같은 이점이 있습니다.

• 보다 신속하게 보안 문제를 감지합니다. 이벤트 로그를 매일 검토하면 보안 이벤트를 24시간 이내에 검토하게 됩니다. 따라서 보안상의 취약점을 신속하게 감지하여 복구할 수 있습니다.
• 책임이 분명해집니다. 이벤트 로그의 정기적인 검토가 필요한 경우 로그 파일 검토 작업을 담당한 사람이 가능성 있는 공격을 식별하는 일의 최종 책임자가 될 수 있습니다.
• 이벤트를 덮어쓰거나 서버가 중단될 위험이 줄어듭니다. 로그 파일의 이벤트를 검토한 후, 나중에 검토할 수 있도록 보관해 놓고 현재 이벤트 로그에서 제거할 수 있습니다. 이렇게 하면 이벤트 로그가 꽉 찰 위험이 줄어듭니다.

기타 응용 프로그램 로그 파일 검토

Windows 2000 이벤트 로그에서 보안 이벤트를 검토하는 것 외에 응용 프로그램에서 작성한 로그도 검토해야 합니다. 응용 프로그램 로그에서 가능성 있는 공격에 대해 이벤트 로그의 정보를 보충할 수 있는 유용한 정보를 찾을 수도 있습니다. 사용자 환경에 따라 응용 프로그램 로그 파일을 하나 이상 검토해야 합니다.

• 인터넷 정보 서비스(IIS)IIS는 웹, FTP, NTP(Network Time Protocol) 및 SMTP 서비스에 연결하려는 시도를 추적하는 로그 파일을 작성합니다. IIS에서 실행되는 각 서비스는 별도의 로그 파일을 유지 관리하며 %WinDir%\System32\Logfiles 폴더에 W3C 확장 로그 파일 형식으로 로그 파일을 저장합니다. 각 서비스는 로깅 정보를 세분해서 분류하기 위해 별도의 폴더를 관리합니다. 또는 Microsoft SQL Server와 같은 ODBC 호환 데이터베이스에 로그를 저장하도록 IIS를 구성할 수 있습니다.
• ISA(Internet Security and Acceleration) 서버ISA 서버는 패킷 필터, ISA 서버 방화벽 서비스 및 ISA 서버 웹 프록시 서비스에 대한 로그를 제공합니다. IIS와 마찬가지로 로그는 기본적으로 W3C 확장 로그 파일 형식으로 저장되며, 그 대신 ODBC 호환 데이터베이스에 기록될 수도 있습니다. ISA 서버 로그 파일은 기본적으로C:\Program Files\Microsoft ISA Server\ISALogs 폴더에 저장됩니다.
• 인터넷 인증 서비스(IAS)IAS는 원격 인증 전화 접속 사용자 서비스(RADIUS) 프로토콜을 사용하여 원격 액세스 인증을 위한 집중식 관리 인증 및 계정을 제공합니다. 기본적으로 계정 요청, 인증 요청 및 주기적인 상태 요청은 %WinDir%\System32\Logfiles 폴더의 IASlog.log 파일에 기록됩니다. 로그 파일을 IAS 형식이 아닌 데이터베이스 호환 파일 형식으로 저장할 수도 있습니다.
• 타사 응용 프로그램여러 가지 타사 응용 프로그램에서 로컬 로깅 기능을 구현하여 응용 프로그램에 대한 자세한 정보를 제공합니다. 자세한 내용은 해당 응용 프로그램의 도움말 파일을 참조하십시오.

참고:로그 파일을 유지 관리하는 모든 컴퓨터는 시간이 동일한 시계를 사용해야 합니다. 이렇게 하면 관리자가 컴퓨터와 서비스 사이에서 이벤트를 비교하여 공격자가 수행한 작업을 확인할 수 있습니다. 시간 동기화에 대한 자세한 내용은 이 장 뒷부분의 "시간 동기화의 중요성" 절을 참조하십시오.

설치된 서비스 및 드라이버 모니터링

컴퓨터를 대상으로 한 많은 공격은 컴퓨터에 설치된 서비스를 공격하는 방법이나 공격자가 컴퓨터에 액세스할 수 있도록 트로이 목마가 포함된 드라이버 버전으로 유효한 드라이버를 바꾸는 방법으로 이루어집니다.

다음 도구를 사용하여 컴퓨터에 설치된 서비스 및 드라이버를 모니터링할 수 있습니다.

• 서비스 콘솔서비스 MMC 콘솔은 로컬 컴퓨터나 원격 컴퓨터의 서비스를 모니터링하는 데 사용됩니다. 관리자는 이 콘솔을 사용하여 설치된 모든 서비스를 구성, 일시 중지, 중지, 시작 또는 다시 시작할 수 있습니다. 이 콘솔을 사용하여 자동으로 시작하도록 구성된 서비스 중에 현재 시작되지 않은 서비스가 있는지 확인합니다.
• Netsvc.exe관리자는 Windows 2000 Server Resource Kit에 포함된 이 명령줄 도구를 사용하여 명령줄에서 원격으로 서비스 상태를 시작, 중지, 일시 중지, 계속 또는 쿼리할 수 있습니다.
• SvcMon.exe이 도구는 로컬 및 원격 컴퓨터에서 서비스의 상태 변경 여부(시작 또는 중지)를 모니터링합니다. 이러한 상태 변경을 감지하기 위하여 서비스 모니터링 도구는 폴링 시스템을 구현합니다. 모니터링하는 서비스가 중지되거나 시작될 때 서비스 모니터링 도구가 전자 메일을 보내서 알립니다. 서비스 모니터 구성 도구(smconfig.exe)를 사용하여 모니터링할 서비스, 폴링 간격 및 서버를 구성해야 합니다.
• Drivers.exe이 도구가 실행되는 컴퓨터에 설치된 모든 장치 드라이버를 표시합니다. 드라이버 파일 이름, 디스크에 있는 드라이버의 크기 및 드라이버가 연결된 날짜를 포함한 정보가 출력됩니다. 연결 날짜를 이용하여 새로 설치된 드라이버를 식별할 수 있습니다. 업데이트된 드라이버가 최근에 설치된 것이 아니면 교체된 드라이버일 수 있습니다. 항상 이 정보를 이벤트 뷰어의 시스템 재시작 이벤트와 관련하여 생각하십시오.

참고:워크스테이션 서비스를 포함하여 모든 서비스를 쿼리할 수는 있지만 사용자가 모든 서비스를 직접 중지할 수 있는 것은 아닙니다. 현재 활성 연결이 많은 경우 서비스를 일시 중지하거나 쿼리할 수는 있지만 원격으로 강제 종료할 수는 없습니다. 일부 서비스에는 다른 서비스가 종속되어 있습니다. 종속된 서비스가 종료되지 않은 상태에서 서비스를 종료하려고 하면 실패합니다.

열린 포트 모니터링

공격은 대상 컴퓨터에서 실행되고 있는 알려진 서비스를 식별하기 위해 포트 검색을 수행하면서 시작되는 경우가 많습니다. 서버에서 열려 있는 포트를 주의 깊게 모니터링해야 합니다. 이는 일반적으로 사용자가 직접 포트를 검색하여 액세스할 수 있는 포트를 판단하는 것을 의미합니다.

포트 검색은 대상 컴퓨터에서 로컬로 수행한 다음 원격 컴퓨터에서도 수행해야 합니다. 공용 네트워크에서 컴퓨터에 액세스할 수 있는 경우 외부 컴퓨터에서 포트 검색을 수행하여 방화벽 소프트웨어가 원하는 포트에만 액세스를 허용하는지 확인해야 합니다.

Netstat.exe는 TCP 및 UDP에 대해 열린 포트를 모두 표시할 수 있는 명령줄 유틸리티입니다. Netstat 명령은 다음 구문을 사용합니다.

NETSTAT [-a] [-e] [-n] [-s] [-pproto] [-r] [interval]


다음은 각 구문에 대한 설명입니다.

• -a모든 연결 및 수신 대기 포트를 표시합니다.
• -e이더넷 상태를 표시합니다.-s옵션과 함께 사용할 수 있습니다.
• -n주소와 포트 번호를 숫자 형태로 표시합니다.
• -p protoproto에 의해 지정된 프로토콜에 대한 연결을 표시합니다. proto는 TCP 또는 UDP일 수 있습니다. -s 옵션과 함께 사용되면 프로토콜 상태별로 표시합니다. proto는 TCP, UDP 또는 IP일 수 있습니다.
• -r라우팅 테이블을 표시합니다.
• -s프로토콜별 통계를 표시합니다. 기본적으로 TCP, UDP 및 IP에 대한 통계가 표시되며-p옵션을 사용하여 기본값의 하위 집합을 지정할 수 있습니다.
• interval몇 초 간격으로 일시 중지하면서 선택된 통계를 반복해서 다시 표시합니다. Ctrl+C를 눌러 통계 표시를 중지할 수 있습니다. 이 구문이 생략되면 netstat가 현재 구성 정보를 한 번만 출력합니다.

로컬 컴퓨터의 열린 TCP 및 UDP 포트를 나열할 경우, \%WinDir%\System32\Drivers\Etc\ 폴더에 있는 서비스 파일의 항목에 기반한 이름으로 포트 번호가 변환됩니다. 포트 번호만 보려면-n스위치를 사용하십시오.

열린 포트가 인식되지 않은 것으로 나타나면 해당 서비스가 컴퓨터에서 필요한 서비스인지 확인해야 합니다. 필요한 서비스가 아닌 경우 연관된 서비스를 비활성화하거나 제거하여 컴퓨터가 해당 포트에서 수신하지 못하게 해야 합니다. 이 가이드에 포함된 구성원 서버 및 도메인 컨트롤러 기본 정책을 적용하면 많은 서비스가 비활성화됩니다.

많은 서버가 방화벽이나 패킷 필터링 라우터에 의해 보호되고 있으므로 원격 컴퓨터에서도 포트 검색을 수행하는 것이 좋습니다. 원격 포트 검색에 사용할 수 있는 타사 도구(일부 프리웨어 포함)가 많이 있습니다. 원격 포트 검색을 통해 외부 사용자가 컴퓨터에 연결하려고 할 때 사용 가능한 포트를 찾아낼 수 있습니다.

참고:포트 검색을 통해 침입 감지 시스템을 테스트하여 포트 검색이 진행되는 동안 시스템에서 감지하는지 확인하십시오. 침입 감지 시스템에 대한 자세한 내용은 이 장 뒷부분의 "능동적 감지 방법" 절을 참조하십시오.

침입 및 보안 이벤트 모니터링

침입 및 보안 이벤트 모니터링에는 수동 작업과 능동 작업이 모두 포함됩니다. 많은 침입은 공격이 일어난 후 로그 파일의 검사를 통해 감지됩니다. 이러한 사후 공격 감지를 수동적 침입 감지라고도 합니다. 로그 파일의 검사를 통해서만 로그 정보를 기반으로 공격을 검토하고 복구할 수 있습니다.

공격이 발생될 때 침입 시도를 감지할 수도 있는데, 이러한 방법을 능동적 침입 감지라고 하며 알려진 공격 패턴이나 명령을 찾아서 해당 명령의 실행을 차단합니다.

이 절에서는 공격으로부터 네트워크를 보호하기 위해 두 가지 형태의 침입 감지를 구현하는 데 사용할 수 있는 도구에 대해 설명합니다.

시간 동기화의 중요성

여러 컴퓨터의 침입과 보안 이벤트를 모니터링할 때는 반드시 컴퓨터의 시계를 동기화해야 합니다. 동기화된 시간을 통해 관리자는 공격이 진행될 때 여러 컴퓨터에서 발생한 사항을 복구할 수 있습니다. 시간을 동기화하지 않으면 특정 이벤트의 발생 시간과 이벤트들이 어떻게 얽혀 있는지를 정확하게 판단하기 어렵습니다. 시간 동기화에 대한 자세한 내용은 3장 "Windows 2000 그룹 정책을 사용한 보안 관리"를 참조하십시오.

수동적 감지 방법

수동 침입 감지 시스템에는 이벤트 로그와 응용 프로그램 로그의 수동 검토가 사용됩니다. 이벤트 로그 데이터에 있는 공격 패턴의 분석 및 감지가 검사됩니다. 이벤트 로그를 검토할 때 여러 가지 도구와 유틸리티, 응용 프로그램을 사용할 수 있습니다. 이 절에서는 각 도구를 사용해서 정보를 조정하는 방법을 요약합니다.

이벤트 뷰어

Windows 2000 보안 로그는 당연히 Windows 2000 이벤트 뷰어 MMC 콘솔에서 볼 수 있습니다. 이벤트 뷰어를 사용하여 응용 프로그램 로그, 보안 및 시스템 로그를 볼 수 있으며 이벤트 뷰어에서 특정 이벤트를 찾는 필터를 정의할 수 있습니다.

이벤트 뷰어에서 필터를 정의하려면

1. 콘솔 트리에서 특정 이벤트 로그를 선택합니다.
2. 보기 메뉴에서필터를 선택합니다.
3. 필터링에 사용할 매개 변수를 선택합니다.

등록 정보대화 상자의필터탭에서 다음 특성을 정의하여 이벤트 항목을 필터링할 수 있습니다.

• 이벤트 형식필터를 정보, 경고, 오류, 성공 감사, 실패 감사 또는 여러 이벤트 유형의 조합으로 제한할 수 있습니다.
• 이벤트 소스이벤트를 생성한 특정 서비스나 드라이버입니다.
• 범주필터를 특정 이벤트 범주로 제한할 수 있습니다.
• 이벤트 ID검색할 특정 이벤트 ID를 알고 있으면 해당 이벤트 ID의 목록으로 필터를 제한할 수 있습니다.
• 사용자특정 사용자가 생성한 이벤트로 이벤트 표시를 제한할 수 있습니다.
• 컴퓨터특정 컴퓨터가 생성한 이벤트로 이벤트 표시를 제한할 수 있습니다.
• 날짜 간격특정 시작 날짜와 종료 날짜 사이의 이벤트로 표시를 제한할 수 있습니다.

필터가 적용되면 필터링된 이벤트 목록을 쉼표나 탭으로 구분한 목록으로 내보내서 데이터베이스 응용 프로그램으로 가져올 수 있습니다.

이벤트 로그 덤프 도구(Dumpel.exe)

이벤트 로그 덤프는 Windows 2000 Server Resource Kit, 부록 1(Microsoft Press, ISBN: 0-7356-1279-X)에 포함되어 있는 명령줄 도구입니다. 이 도구는 로컬 또는 원격 시스템의 이벤트 로그를 탭으로 구분한 텍스트 파일로 덤프합니다. 그런 다음 파일을 스프레드시트나 데이터베이스로 가져와서 자세히 조사할 수 있습니다. 특정 이벤트 형식을 필터링하는 데에도 이 도구를 사용할 수 있습니다.

dumpel.exe 도구의 구문은 다음과 같습니다.

dumpel -ffile [-s\\server] [-llog [-msource]] [-en1 n2 n3...] [-r] [-t] [-dx]


다음은 각 구문에 대한 설명입니다.

• -f file출력 파일의 이름을 지정합니다.-f에 대한 기본값은 없으므로 파일을 지정해야 합니다.
• -s server덤프할 이벤트 로그와 관련된 서버를 지정합니다. 서버 이름 앞의 백슬래시는 선택적입니다.
• -l log덤프할 로그(시스템, 응용 프로그램, 보안)를 지정합니다. 지정한 로그 이름이 유효하지 않으면 응용 프로그램 로그가 덤프됩니다.
• -m source리디렉터(rdr), 직렬 등과 같이 레코드를 덤프할 소스를 지정합니다. 소스는 하나만 지정할 수 있으며 이 스위치가 사용되지 않으면 모든 이벤트가 덤프됩니다. 레지스트리에 등록되지 않은 소스가 사용되면 응용 프로그램 로그에서 이 유형의 레코드가 검색됩니다.
• -en1 n2 n3이벤트 id nn에 대한 필터(10까지 지정 가능).-r스위치가 사용되지 않으면 이러한 유형의 레코드만 덤프되고-r스위치가 사용되면 해당 유형의 레코드를 제외한 모든 레코드가 덤프됩니다. 이 스위치가 사용되지 않으면 지정된소스 이름의 모든 이벤트가 선택됩니다.-m스위치가 없으면 이 스위치를 사용할 수 없습니다.
• -r필터링을 통해 특정 소스나 레코드만 선택할지 또는 제외할지를 지정합니다.
• -t각 문자열이 탭으로 구분되도록 지정합니다.-t가 사용되지 않으면 문자열이 공백으로 구분됩니다.
• -d x지난 x일 동안의 이벤트를 덤프합니다.

참고:Dumpel은 시스템, 응용 프로그램 및 보안 로그 파일의 내용만 검색할 수 있습니다. 파일 복제 서비스(RFS), DNS 또는 디렉터리 서비스 이벤트 로그의 내용을 쿼리할 때는 Dumpel을 사용할 수 없습니다.

EventCombMT

EventCombMT는 여러 서버의 이벤트 로그를 동시에 분석하여 각 서버마다 검색 기준에 포함되는 별도의 실행 스레드를 엽니다. EventCombMT를 사용하여 다음을 수행할 수 있습니다.

• 검색할 단일 이벤트 ID 또는 복수 이벤트 ID 정의하나의 이벤트 ID 또는 공백으로 구분된 여러 이벤트 ID를 포함시킬 수 있습니다.
• 검색할 이벤트 ID의 범위 정의범위에는 시작 ID와 끝 ID가 포함됩니다. 예를 들어, 이벤트 ID 528과 이벤트 ID 540을 포함하여 그 사이에 있는 모든 이벤트를 검색할 경우 범위를 528 > ID < 540으로 정의합니다. 이벤트 로그에 쓰는 대부분의 응용 프로그램이 순차 이벤트 범위를 사용하므로 아주 유용합니다.
• 특정 이벤트 로그로 검색 제한시스템, 응용 프로그램 및 보안 로그를 검색하도록 선택할 수 있습니다. 도메인 컨트롤러에서 로컬로 실행할 경우 FRS, DNS 및 AD 로그도 검색할 수 있습니다.
• 특정 이벤트 메시지 유형으로 검색 제한오류, 정보, 경고, 성공 감사, 실패 감사 또는 성공 이벤트를 검색하도록 제한할 수 있습니다.
• 특정 이벤트 원본으로 검색 제한특정 이벤트 원본의 이벤트를 검색하도록 제한할 수 있습니다.
• 이벤트 설명 내의 특정 텍스트 검색각 이벤트에서 특정 텍스트를 검색할 수 있습니다. 특정 사용자나 그룹을 추적할 경우에 유용합니다.

  참고:AND, OR 또는 NOT과 같은 검색 논리를 특정 텍스트에 포함시킬 수 없습니다. 또한 인용 부호로 텍스트의 범위를 정할 수 없습니다.

• 현재 날짜와 시간에서 이전으로 거슬러 검색하기 위한 특정 시간 간격 정의지난 주, 일, 월의 이벤트로 검색을 제한할 수 있습니다.

도구 설치

도구를 설치하려면 이 가이드에 있는 자동 압축 풀기 SecurityOps.exe 파일의 압축을 풉니다. 압축이 풀리면서 C:\SecurityOps\EventComb 폴더가 만들어집니다. 압축을 푼 뒤, EventCombMT.exe 파일을 두 번 누르면 EventCombMT 도구를 실행할 수 있습니다.

EventComb 도구 실행

EventComb 도구를 사용하는 첫 번째 단계는 이벤트 로그 검색에 포함될 컴퓨터를 정의하는 것입니다.

컴퓨터를 검색에 추가하려면

1. EventCombMT 유틸리티의 도메인 상자에 올바른 도메인이 자동 검색되는지 확인합니다. 다른 도메인의 이벤트 로그를 검색하려면도메인 상자에 새 도메인 이름을 직접 입력합니다.
2. 검색 목록에 컴퓨터를 추가하려면Select To Search/Right Click to Add아래의 상자를 마우스 오른쪽 단추로 누릅니다. 그림 6.1과 같은 팝업 메뉴가 나타납니다.

   
   현재 사용하는 브라우저가 인라인 프레임을 지원하지 않을 경우여기를 눌러 새 창에서 볼 수 있습니다.

   그림 6.1 자동 검색되지 않는 컴퓨터를 검색 목록에 추가

   다음 옵션을 사용할 수 있습니다.

   • Get DCs in Domain현재 도메인의 모든 도메인 컨트롤러를 목록에 추가합니다.
   • Add Single Server서버나 워크스테이션을 이름별로 목록에 추가할 수 있습니다.
   • Add all GCs in this domain선택된 도메인에 글로벌 카탈로그 서버로 구성되는 모든 도메인 컨트롤러를 추가할 수 있습니다.
   • Get All Servers브라우저 서비스를 사용하여 도메인에 있는 모든 서버를 추가합니다. 모든 도메인 컨트롤러가 서버에서 제외됩니다.
   • Get Servers from File검색 범위에 포함될 모든 서버를 표시한 파일을 가져올 수 있습니다. 텍스트 파일에서 한 줄에 한 서버만 입력해야 합니다.
3. 목록에 서버를 추가했으면 검색 대상 서버를 선택해야 합니다. 선택된 서버는 목록에서 강조 표시됩니다. Ctrl 키를 누른 상태로 마우스 단추를 눌러 여러 개의 서버를 선택할 수 있습니다.

검색할 이벤트 로그와 이벤트 유형 지정

이벤트 로그 검색에 포함시킬 서버를 선택했으면 사용할 이벤트 로그와 이벤트 유형을 선택하여 검색 범위를 좁힐 수 있습니다.

EventCombMT 유틸리티에서 검색 대상으로 다음 이벤트 로그를 선택할 수 있습니다.

• 시스템
• 응용 프로그램
• 보안
• FRS(파일 복제 서비스 로그)
• DNS(DNS 서버 로그)
• AD(디렉터리 서비스 로그)

검색에 포함할 이벤트 유형도 선택할 수 있습니다:

• 오류응용 프로그램 로그와 시스템 로그에 기록되며 FRS, DNS 및 디렉터리 서비스 로그에도 나타납니다.
• 정보응용 프로그램 로그와 시스템 로그에 기록되며 FRS, DNS 및 디렉터리 서비스 로그에도 나타납니다.
• 경고응용 프로그램 로그와 시스템 로그에 기록되며 FRS, DNS 및 디렉터리 서비스 로그에도 나타납니다.
• 성공 감사응용 프로그램이 성공 감사를 응용 프로그램 로그에 등록할 경우 보안 로그나 응용 프로그램 로그에서 발생합니다. 예를 들어, ADMT(Active Directory Migration Tool)가 응용 프로그램 로그에 성공 감사 이벤트를 기록합니다.
• 실패 감사응용 프로그램이 실패 감사를 응용 프로그램 로그에 등록할 경우 보안 로그나 응용 프로그램 로그에서 발생합니다. 예를 들면 ADMT가 응용 프로그램 로그에 실패 감사 이벤트를 기록합니다.
• 성공아주 드물게 응용 프로그램 로그와 시스템 로그에 기록되며 FRS, DNS 및 디렉터리 서비스 로그에도 나타납니다. 이벤트 뷰어에서 성공 이벤트는 정보 이벤트 유형으로 표시됩니다.

참고:이벤트 ID가 나타나는 이벤트 로그와 해당 ID의 이벤트 유형에 대해 자세히 알고 있으면 정보를 검색 기준에 포함시켜 검색 시간을 단축하십시오.

검색 저장

EventCombMT를 사용하여 검색을 저장하고 나중에 다시 로드할 수 있습니다. 이는 EventCombMT를 자주 사용하여 IIS 서버에서 특정 이벤트 집합을 검색하고 도메인 컨트롤러에서는 다른 이벤트 집합을 검색할 때 유용합니다.

검색 기준은HKLM\Software\Microsoft\EventCombMT아래 레지스트리에 저장되며 쉽게 편집할 수 있습니다.

검색 결과 파일

검색 결과는 기본적으로 C:\Temp 폴더에 저장됩니다. 결과에는 EventCombMT.txt라는 요약 파일이 포함되며 이벤트 로그 검색에 포함된 각 컴퓨터에 대해 ComputerName-EventLogName_LOG.txt라는 별도의 텍스트 파일이 생성됩니다. 별도로 생성된 텍스트 파일에는 이벤트 로그에서 추출된 검색 기준과 일치하는 모든 이벤트가 있습니다.

EventCombMT 사용 예

EventCombMT의 사용 방법을 설명하기 위해 도메인 컨트롤러 재부팅과 계정 잠금을 감지하도록 구성하는 방법을 살펴봅니다.

EventCombMT를 사용하여 도메인 컨트롤러의 재시작을 검색하려면

1. EventCombMT 도구에서 올바른 도메인 이름으로 도메인이 구성되어 있는지 확인합니다.
2. 도메인 이름 아래에 있는 Select to Search/Right Click to Add 상자를 마우스 오른쪽 단추로 누른 다음Get DCs in Domain을 누릅니다.

   참고:계정 로그온 이벤트나 계정 관리 이벤트와 같은 이벤트를 검색할 때는 모든 도메인 컨트롤러를 검색하도록 하십시오. Windows 2000에서 계정 관리에 다중 마스터 모델을 사용하기 때문에 도메인의 모든 도메인 컨트롤러에서 계정을 추가, 수정 또는 삭제할 수 있습니다. 마찬가지로 인증도 도메인의 모든 도메인 컨트롤러에서 확인할 수 있습니다. 따라서 특정 업데이트나 인증 시도가 발생하는 위치가 확실하지 않을 수 있습니다.

3. Select to Search/Right Click to Add상자를 마우스 오른쪽 단추로 누른 다음Select All Servers in List를 누릅니다.
4. 도구의Choose Log Files to search섹션에서System로그만 선택합니다.
5. 도구의Event Types섹션에서 b>Error와Informational를 선택합니다.
6. Event IDs상자에 다음 이벤트 ID1001 6005 6006 6008를 입력합니다.
7. Search단추를 누르기 전에 검색 기준이 아래의 그림처럼 정의되어 있는지 확인한 다음 Search를 누릅니다.

   
   현재 사용하는 브라우저가 인라인 프레임을 지원하지 않을 경우여기를 눌러 새 창에서 볼 수 있습니다.

   검색이 끝나면 자동으로 열리는 로그 디렉터리에 검색 결과가 표시됩니다.

로그 항목을 검토하려면

1. File메뉴에서Open Log Directory를 선택합니다.
2. C:\Temp 폴더에서 도메인 컨트롤러의 출력 파일을 두 번 클릭하여 EventCombMT 도구가 기록한 특정 이벤트를 봅니다. 아래와 유사한 출력이 나타납니다.

1001,INFORMATIONAL,Save Dump,Wed Nov 28 05:45:50 2001,,컴퓨터가 버그 확인으로 다시 부팅되었습니다.
버그 확인은: 0x000000d1 (0x00000004, 0x00000002, 0x00000000, 0x84c983dc). 출력은 다음에 저장되었습니다: C:\WINDOWS\MEMORY.DMP.
6005,INFORMATIONAL,EventLog,Wed Nov 28 05:45:46 2001,,이벤트 로그 서비스가 시작되었습니다.
6008,ERROR,EventLog,Wed Nov 28 05:45:46 2001,,11/28/2001의 5:33:47 AM에서 이전에 예기치 않은 시스템 종료가 있었습니다.
6005,INFORMATIONAL,EventLog,Tue Nov 27 14:10:53 2001,,이벤트 로그 서비스가 시작되었습니다.
6006,INFORMATIONAL,EventLog,Tue Nov 27 14:09:26 2001,,이벤트 로그 서비스가 중지되었습니다.
6005,INFORMATIONAL,EventLog,Tue Nov 27 10:11:37 2001,,이벤트 로그 서비스가 시작되었습니다.


6006 이벤트는 도메인 컨트롤러 종료 권한을 가진 사용자가 계획된 종료를 시작했음을 나타냅니다. 6005 이벤트는 이벤트 로그 서비스가 시작되었음을 나타냅니다. 이 이벤트는 서비스가 시작될 때 발생합니다.

6008과 1001 이벤트는 컴퓨터를 종료하지 않은 상태에서 전원이 꺼졌거나 잠기거나 파란색 화면이 발생해서 컴퓨터를 다시 시작했음을 나타냅니다. 1001 이벤트가 있으면 파란색 화면이 발생한 것이므로 관련 디버그 정보와 디버그 파일에 대한 참조가 포함됩니다.

EventCombMT 도구가 반환한 이벤트를 밝혀진 시스템 정지 시간과 비교 검토합니다. 일치하지 않는 이벤트가 있으면 조사하여 서버가 공격을 받지 않았는지 확인해야 합니다.

EventCombMT에는 보안 이벤트를 검색하는 데 사용할 수 있는 미리 정의된 여러 검색이 포함됩니다. 예를 들면 계정 잠금 이벤트를 검색하는 미리 정의된 검색이 있습니다.

EventCombMT를 사용하여 계정 잠금을 검색하려면

1. EventCombMT 도구에서 올바른 도메인 이름으로 도메인이 구성되어 있는지 확인합니다.
2. 도메인 이름 아래의Select to Search/Right Click to Add상자를 마우스 오른쪽 단추로 누른 다음Get DCs in Domain을 누릅니다.
3. Select to Search/Right Click to Add상자를 마우스 오른쪽 단추로 누른 다음Select All Servers in List를 누릅니다.
4. Searches메뉴에서Built In Searches를 누른 다음Account Lockouts을 누릅니다. EventCombMT 유틸리티는 다음 그림과 같이 구성됩니다.
5. Search를 누릅니다.
6. 검색이 끝나면 자동으로 열리는 로그 디렉터리에 검색 결과가 표시됩니다.

참고:EventcombMT와 함께 제공되는 그 밖의 미리 정의된 검색에는 파일 복제 서비스 검색, Active Directory의 SID 업데이트와 NETLOGON DNS 등록 실패 검색, 하드웨어 디스크 오류, DNS 인터페이스 오류 등이 있습니다. 사용자가 사용자 정의 검색을 정의하고 저장할 수도 있습니다.

이벤트 컬렉션

감사의 주요 목적 중 하나는 공격자가 네트워크에서 수행한 동작을 식별하는 것입니다. 공격자가 네트워크의 여러 컴퓨터와 장치를 손상시킬 수 있으므로 공격의 정도를 파악하기 위해서는 많은 컴퓨터의 정보를 조정하고 통합할 수 있어야 합니다.

로그 유틸리티를 데이터베이스로 가져오면 여러 로그의 정보를 쉽게 조정할 수 있습니다. 모든 컴퓨터에서 시간이 동기화되면 시간 필드를 정렬할 수 있으므로 시간 간격을 기준으로 이벤트를 추적하기 쉬워집니다.

다음 절에서는 이벤트 로그 정보를 중앙 위치로 모으는 데 사용할 수 있는 몇 가지 도구와 유틸리티에 대해 간단히 설명합니다.

스크립팅

원격 컴퓨터의 이벤트 로그 정보를 모아서 중앙 위치에 저장하는 스크립트를 작성할 수 있습니다. 스크립팅을 사용하면 예약된 작업을 사용해서 스크립트를 실행하는 시기를 선택하고 이벤트 로그가 중앙 위치에 복사된 후에 수행할 조치를 선택할 수 있습니다.

간단한 예로 Windows 2000 Server Resource Kit의 Dumpel.exe를 사용하는 배치 파일을 만든 다음 제어판에서 예약된 작업을 사용하여 정기적으로 배치 파일을 시작할 수 있습니다.

Windows 2000 Resource Kit, 부록 1에는 Eventquery.pl이 들어 있습니다. 이 스크립트는 Windows 2000을 실행하는 로컬 및 원격 컴퓨터에서 이벤트 뷰어 로그의 이벤트를 표시하고 특정 이벤트를 찾을 수 있는 다양한 필터를 제공하는 Perl 스크립트입니다.

참고:이 스크립트를 사용하려면 Windows 2000 Server Resource Kit의 ActivePerl을 설치해야 합니다.

Microsoft Operations Manager

Microsoft Operations Manager 2000은 기업에서 Windows 2000 및 관련 응용 프로그램에 대하여 기본 제공되는 이벤트 보고서와 성능 모니터링을 철저히 분석할 수 있는 포괄적인 도구 세트입니다. Operations Manager는 원격 컴퓨터에서 지능형 에이전트를 사용하여 이벤트 및 성능 데이터를 한 위치에 수집, 저장 및 보고할 수 있습니다. 이렇게 수집된 정보는 관리자가 중앙에서 검토할 수 있습니다.

핵심 Operations Manager 관리 팩은 시스템, 응용 프로그램 및 보안 이벤트 로그에 나타나는 이벤트를 모아서 그 결과를 중앙 이벤트 저장소에서 집계합니다.

참고:Operations Manager는 SQL 데이터베이스에 정보를 저장하고 보관된 데이터를 검색 및 분석하는 여러 방법을 제공합니다. 관리자는 Operations Manager 관리자 콘솔, 웹 콘솔 또는 Operations Manager 보고서를 사용하여 데이터를 검토, 인쇄 또는 게시할 수 있습니다. 각 보기에는 보관된 데이터의 분석을 위해 미리 정의된 보기가 있으며 사용자 정의 보기 및 보고서도 정의할 수 있습니다.

타사의 이벤트 로그 컬렉션 솔루션

이벤트 로그의 집중식 관리 수집 및 검사를 지원하는 타사 제품이 몇 가지 있습니다. 타사 제품을 평가할 때 다음 기능을 확인하십시오.

• 모든 Windows 2000 로그에 대한 지원응용 프로그램 로그, 보안 및 시스템 로그 외에 DNS 서버, 디렉터리 서비스 및 파일 복제 서비스 로그에 대한 지원도 제공해야 합니다.
• 데이터베이스 백 엔드 사용도구를 사용하여 여러 서버 간의 이전 이벤트 로그 항목에 대해 이벤트의 추세 분석과 연관성을 검사할 수 있는 데이터베이스 구조에 이벤트 로그를 저장할 수 있어야 합니다.
• 검색 및 보고서 기능도구를 사용하여 제공된 기준에 따라 특정 이벤트를 검색할 수 있어야 합니다. 결과가 읽을 수 있게 표시되어야 합니다.

다음은 이벤트 컬렉션 기능을 제공하는 타사 제품입니다.

• Event Log Monitor–TNT Software
• Event Archiver–Dorian Software Creations
• LogCaster–RippleTech

능동적 감지 방법

능동적 침입 감지 시스템은 응용 프로그램 계층에서 들어오는 네트워크 소통량을 분석하여 잘 알려진 공격 방법이나 의심스러운 응용 프로그램 계층 페이로드를 찾습니다. 의심스러운 패킷이 수신되면 침입 감지 시스템이 패킷을 버리고 로그 파일에 항목을 기록합니다. 심각한 공격이 감지될 때 관리자에게 경고하는 침입 감지 시스템도 있습니다.

URLScan을 사용하여 HTTP 액세스 검사

조직에서 웹 사이트를 호스팅할 경우 서버 중 일부는 들어오는 HTTP 소통량을 수신합니다. 그러나 들어오는 소통량이 모두 적절한 것은 아닙니다. UrlScan은 들어오는 HTTP 패킷을 분석하는 ISAPI 필터로서, 의심스러운 소통량을 거부할 수 있습니다.

UrlScan은 선택한 IIS 서비스 기능에 대한 HTTP 요청을 필터링 및 거부하여 공격으로부터 서버를 보호합니다. 기본적으로 UrlScan은 그래픽을 포함하여 정적 HTML 파일에 대한 요청만 받아 들이도록 구성됩니다. 다음과 같은 종류의 요청은 거부합니다.

• CGI (.exe) 페이지
• WebDAV
• FrontPage Server Extensions
• 인덱스 서버
• 인터넷 인쇄
• 서버 쪽 포함 사항

UrlScan은 네트워크의 IIS 서버에 ISAPI 필터를 설치하여 종점 침입 감지 시스템으로 구현하거나 네트워크 주변의 ISA 서버에 UrlScan ISAPI 필터를 설치하여 네트워크 침입 감지 시스템으로 구현할 수 있습니다. ISA 서버를 방화벽으로 사용할 경우에는 두 솔루션을 결합해야 합니다. 네트워크 주변의 경우 네트워크로 들어오는 불필요한 일반 소통량을 모두 차단하십시오. 종점 IIS 서버에서는 웹 서버에 제공한 콘텐트의 형식에 따라 특정 규칙 집합을 구현할 수 있습니다.

UrlScan은 %WinDir%\system32\inetsrv\Urlscan 폴더에 있는 UrlScan.ini 파일을 사용하여 구성됩니다. 이 파일에는 여러 섹션이 있습니다.

[Options] 섹션은 IIS 서버가 유효한 웹 요청과 유효하지 않은 웹 요청을 처리하는 방법을 정의합니다. 정의할 수 있는 옵션은 다음과 같습니다.

• UseAllowVerbs허용되는 값은 0 또는 1입니다. 기본값인 1로 설정할 경우 UrlScan은 UrlScan.ini의 AllowVerbs 섹션을 읽고 명시적으로 나열되지 않은 HTTP 동사가 포함된 요청을 거부합니다. AllowVerbs 섹션은 대/소문자를 구분합니다. 0으로 설정되면 UrlScan은 UrlScan.ini의 DenyVerbs 섹션을 읽고 나열된 HTTP 동사가 포함된 요청을 거부합니다. DenyVerbs 섹션은 대/소문자를 구분하지 않습니다.
• UseAllowExtensions허용되는 값은 0 또는 1입니다. 1로 설정할 경우 UrlScan은 UrlScan.ini의 AllowExtensions 섹션을 읽고 URL과 관련된 파일 확장명이 명시적으로 나열되지 않은 요청을 거부합니다. 기본값인 0으로 설정되면 UrlScan은 UrlScan.ini의 DenyExtensions 섹션을 읽고 요청과 관련된 파일 확장명이 나열된 요청을 거부합니다. AllowExtensions과 DenyExtensions 섹션은 모두 대/소문자를 구분하지 않습니다.
• NormalizeUrlBeforeScan허용되는 값은 0 또는 1입니다. 기본값인 1로 설정할 경우 UrlScan은 먼저 IIS가 디코딩하고 표준화한 다음에 요청 URL을 모두 분석합니다. 0으로 설정되면 UrlScan은 클라이언트가 보낸 원시 URL을 모두 분석합니다. URL 분석에 대해 잘 알고 있는 고급 관리자만 이 옵션을 0으로 설정해야 합니다. 그렇지 않으면 IIS 서버가 URL 확장명의 정확한 분석을 무시하는 정형화(canonicalization) 공격에 노출될 수 있습니다.
• VerifyNormalization허용되는 값은 0 또는 1입니다. 기본값인 1로 설정할 경우 UrlScan은 URL의 표준화를 확인합니다. 이 동작은 URL에 이중 인코딩된 문자열이 들어 있을 때 정형화 공격을 방어합니다. 예를 들어, "%252e" 문자열은 이중 인코딩된 '.' 문자로, "%25"는 '%' 문자로 디코딩됩니다. "%252e"의 첫 번째 디코딩은 결국 "%2e"가 되고 두 번째에 '.'로 디코딩될 수 있습니다. 0으로 설정되면 이 확인이 수행되지 않습니다.
• AllowHighBitCharacters허용되는 값은 0 또는 1입니다. 1로 설정할 경우 UrlScan은 URL에 있는 바이트를 허용합니다. 기본값인 0으로 설정되면 UrlScan은 URL에 ASCII 문자 집합 이외의 문자가 포함된 요청을 거부합니다. 이 기능은 유니코드 또는 UTF-8 기반 공격을 방어할 수 있지만 ASCII가 아닌 코드 페이지를 사용하는 IIS 서버에 대한 정당한 요청을 거부하기도 합니다.
• AllowDotInPath허용되는 값은 0 또는 1입니다. 기본값인 0으로 설정할 경우 UrlScan은 점(.) 문자 인스턴스가 여러 개인 요청을 거부합니다. 1로 설정되면 UrlScan은 이 테스트를 수행하지 않습니다. UrlScan은 아직 IIS가 URL을 분석하지 않은 수준에서 작동하기 때문에 어떤 경우에도 점 문자가 확장명을 나타내는지 또는 URL의 디렉터리 경로나 파일 이름의 일부인지를 판단할 수 없습니다. 확장명을 분석하기 위해 UrlScan은 항상 확장명이 URL의 일부라고 가정합니다. 이 때 URL은 문자열의 마지막 점 뒤에서 시작하고 점이나 문자열 끝 뒤의 첫 번째로 오는 물음표나 슬래시 문자로 끝납니다. AllowDotInPath를 0으로 설정하면 공격자가 경로 정보를 사용해서 요청의 진짜 확장명(예: "/path/TrueURL.asp/BogusPart.htm")을 숨길 경우에 방어할 수 있습니다.

  참고:AllowDotInPath를 0으로 설정하면 UrlScan이 디렉터리 이름에 점이 포함된 요청도 거부할 수 있습니다.

• RemoveServerHeader허용되는 값은 0 또는 1입니다. 1로 설정할 경우 UrlScan은 모든 응답에서 서버 헤더를 제거합니다. 기본값인 0으로 설정하면 UrlScan은 이 동작을 수행하지 않습니다. 이 기능은 UrlScan이 IIS 4.0 이상에 설치되어 있어야 사용할 수 있습니다.
• EnableLogging허용되는 값은 0 또는 1입니다. 기본값인 1로 설정할 경우 UrlScan은 해당 동작을 UrlScan.dll과 같은 디렉터리에 만들어지는 UrlScan.log 파일에 해당 동작을 로깅합니다. 0으로 설정하면 로깅이 수행되지 않습니다.
• PerProcessLogging허용되는 값은 0 또는 1입니다. 1로 설정할 경우 UrlScan은 UrlScan.dll을 호스팅하는 IIS 프로세스의 프로세스 ID를 로그 파일 이름(예: UrlScan.1234.log)에 추가합니다. 이 기능은 여러 프로세스에서 동시에 필터를 호스팅할 수 있는 IIS 버전에 유용합니다. 기본값인 0으로 설정하면 UrlScan.log가 로그 파일이 됩니다.
• AlternateServerName허용되는 값은 문자열이며 기본값은 빈 문자열입니다. 이 옵션의 값이 설정되고(빈 문자열이 아님) RemoveServerHeader가 0으로 설정할 경우 IIS는 모든 응답의 기본 헤더를 이 문자열로 바꿉니다. RemoveServerHeader가 1로 설정되면 AlternateServerName에 의미가 없습니다. 이 기능은 UrlScan이 IIS 4.0 이상에 설치되어 있어야 사용할 수 있습니다.
• AllowLateScanning허용되는 값은 0 또는 1입니다. 1로 설정할 경우 UrlScan은 낮은 우선 순위 필터로 자동 등록됩니다. 그렇게 되면 UrlScan이 분석을 수행하기 전에 다른 필터가 URL을 수정할 수 있습니다. 이 스위치 외에도 UrlScan은 필터 목록에서 서버의 MMC ISAPI 필터 속성 시트의 높은 우선 순위 필터보다 낮은 위치에 있어야 합니다. 기본값인 0으로 설정되면 UrlScan은 높은 우선 순위 필터로 실행됩니다. Front Page Server Extensions에서는 이 설정이 1이어야 하고 UrlScan은 필터 로드 순서 목록에서 낮은 쪽(가장 낮은 경우가 좋음)에 있어야 합니다.
• PerDayLogging허용되는 값은 0 또는 1입니다. 기본값인 1로 설정할 경우 UrlScan은 매일 새 로그 파일을 만들고 로그 파일 이름에 날짜를 추가합니다(예: UrlScan.101501.log). PerDayLogging=1과 PerProcessLogging=1이 모두 설정되면 로그 파일 이름에 날짜와 프로세스 ID가 포함됩니다(예: UrlScan.101501.123.log). PerDayLogging을 사용하면 해당 날짜에 첫 번째 로그 항목이 기록될 때 오늘 날짜에 대한 로그가 만들어지고 이전 날짜의 로그는 닫힙니다. UrlScan 동작이 발생하지 않는 날에 대해서는 로그가 만들어지지 않습니다. 이 값을 0으로 설정하면 UrlScan은 UrlScan.log파일을 엽니다. PerProcessLogging=1인 경우에는 UrlScan.xxx.log(xxx는 프로세스 ID) 파일이 열립니다.
• RejectResponseUrl허용되는 값은 문자열입니다. 기본값은 /입니다. 이 문자열은 /path/file_name.ext 형식의 URL입니다. UrlScan이 요청을 거부할 경우 UrlScan은 분석할 요청에 대하여 웹 사이트의 로컬이 될 지정된 URL을 실행합니다. 지정된 URL은 거부된 URL과 같은 확장명(예: .asp)을 가질 수 있습니다.
• UseFastPathReject허용되는 값은 0 또는 1입니다. 1로 설정할 경우 UrlScan은 RejectResponseUrl을 무시하며, 요청을 무시할 경우에는 클라이언트로 짧은 404 응답을 반환합니다. 이 옵션은 RejectResponseUrl을 모두 처리하는 것보다 빠르지만 이 옵션이 사용되면 IIS가 사용자 정의 404 응답을 반환하거나 요청의 여러 부분을 IIS 로그에 기록할 수 없습니다. UrlScan 로그 파일에는 거부된 요청에 대한 모든 정보가 그대로 들어 있습니다. 기본값은 UseFastPathReject를 사용하지 않는 것입니다.

[AllowVerbs] 섹션에는 HTTP 동사(방법) 목록이 있습니다. UseAllowVerbs가 [Options] 섹션에서 1로 설정할 경우 UrlScan은 여기에 명시적으로 나열하지 않은 동사가 포함된 요청을 거부합니다. 이 섹션의 항목은 대/소문자를 구분합니다.

[DenyVerbs] 섹션에는 HTTP 동사(메서드)의 목록이 있습니다. UseAllowVerbs가 [Options] 섹션에서 0으로 설정할 경우 UrlScan은 여기에 나열된 동사가 포함된 요청을 거부합니다. 이 섹션의 항목은 대/소문자를 구분하지 않습니다.

[DenyHeaders] 섹션에는 받은 요청에 포함된 경우 거부될 요청 헤더의 목록이 있습니다. 이 섹션의 항목은 대/소문자를 구분하지 않습니다.

[AllowExtensions] 섹션에는 파일 확장명 목록이 있습니다. UseAllowExtensions이 [Options] 섹션에서 1로 설정될 경우 여기에 명시적으로 나열되지 않은 확장명을 가진 URL이 포함된 모든 요청이 거부됩니다. 이 섹션의 항목은 대/소문자를 구분하지 않습니다.

참고:뒤에 따르는 문자 없이 점만 사용하여 빈 확장명을 추가하면 확장명 없는 요청(예: 기본 페이지나 디렉터리 목록에 대한 요청)을 지정할 수 있습니다.

[DenyExtensions] 섹션에는 파일 확장명 목록이 있습니다. UseAllowExtensions이 [Options] 섹션에서 0으로 설정되면 여기에 나열된 확장명을 가진 URL이 포함된 모든 요청이 거부됩니다. 이 섹션의 항목은 대/소문자를 구분하지 않습니다.

참고:UrlScan.ini 파일을 변경할 경우에는 ISA PROXY3 서비스를 다시 시작하여 ISAPI 필터를 다시 로드해야 합니다.

ISA 서버에서 UrlScan을 사용하여 네트워크 스캔

UrlScan을 네트워크 주변의 ISA 서버에 배포할 경우 웹 서버에 필요한 모든 소통량이 ISA 서버의 뒤를 통과할 수 있도록 UrlScan.ini를 설정해야 합니다. 이렇게 하려면 UrlScan.ini 파일을 수동으로 구성해야 합니다.

UrlScan.ini 설정을 ISA 서버에 정의할 경우에는 1단계로 ISA 서버에 구성된 모든 웹 게시 규칙을 문서화해야 합니다. 이러한 규칙은 ISA 서버를 통과하는 HTTP와 HTTPS 소통량을 정확히 정의합니다.

모든 웹 소통량이 식별되면 UrlScan.ini 파일의 구성을 사용할 수 있도록 웹 소통량의 윤곽을 파악해야 합니다. 설정을 정의할 때는 주변의 침입 감지가 필요한 모든 소통량이 통과되도록 허용해야 합니다. 두 웹 서버의 보안 구성 사이에 충돌이 있으면 네트워크 주변에 최소한의 제한적인 설정을 구축해야 합니다. 예를 들어, ISA 서버가 보호하는 웹 서버가 두 개이고 한 웹 서버는 ASP 기반 웹 사이트를 호스팅하고 두 번째 웹 서버는 정적 콘텐트만 호스팅할 경우 ISA 서버에 구현한 UrlScan은 ASP와 관련된 소통량을 두 웹 서버로 모두 전달할 수 있어야 합니다. UrlScan을 웹 서버에 구현하면 정적 콘텐트를 호스팅하는 웹 서버의 소통량을 잠글 수 있습니다.

IIS에서 UrlScan을 사용하여 종점 검색

개별 웹 서버의 요구 사항에 맞게 특정 UrlScan.ini 설정을 정의할 수 있습니다.

URLScan은 대부분의 공격이 비정상적인 요청을 이용한다는 공통적인 특징을 갖기 때문에 웹 서버를 보호하는 데 유용합니다. 예를 들어, 비정상적인 동작을 요청하는 요청은 매우 길거나, 대체 문자 집합을 사용하여 인코딩되거나, 정당한 요청에서 거의 볼 수 없는 문자 배열을 포함하고 있을 수 있습니다. 비정상적인 모든 요청의 필터링을 통해 URLScan은 서버에 요청을 연결해서 손상되는 일이 없도록 합니다.

URLScan은 매우 유연합니다. 기본 규칙 집합은 IIS에 영향을 미치는 실제로 잘 알려진 보안상의 취약점으로부터 서버를 완전히 보호하고 아직 검색되지 않은 추가 공격 방법에 대해서도 보호할 수 있습니다. 도구의 동작을 특정 서버의 요구에 맞게 사용자 정의하기 위해 기본 규칙을 수정하고 새 규칙을 추가할 수 있습니다. 기본 규칙 집합 외에, UrlScan.ini ISAPI 필터를 설치하는 동안 IIS LockDown 마법사에서 다음 구성도 선택할 수 있습니다.

• Small Business Server 2000
• Exchange Server 5.5(Outlook Web Access)
• Exchange Server 2000(OWA, PF Management, IM, SMTP, NNTP)
• SharePoint Portal Server
• FrontPage Server Extensions(SharePoint Team Services)
• BizTalk Server 2000
• Commerce Server 2000
• 프록시 서버
• 정적 웹 서버
• 동적 웹 서버(ASP 사용)
• 기타(위에 나열한 어떠한 역할과도 일치하지 않는 서버)
• IIS가 필요하지 않은 서버

미리 정의된 템플릿 중 하나를 선택하면 미리 정의된 UrlScan.ini 파일이 가장 적합한 설정으로 배포됩니다. 정해진 UrlScan.ini 파일을 받는 것 외에 최신 Microsoft 기술 자료 문서에서 특정 구성에 대해 Urlscan.ini 파일에 필요한 조정이 있는지 검색해야 합니다.

특정 UrlScan 구성 권장 사항

특정 환경에서 UrlScan을 사용할 때 권장되는 구성 설정을 제공하는 여러 기술 자료 문서가 있습니다. UrlScan 구성 설정을 조사할 때 반드시 다음 문서를 검토하십시오.

ISA 서버의 침입 감지 기능

ISA 서버의 특징은 네트워크에 공격이 시도되는 때를 감지하여 미리 구성된 동작이나 경고로 응답할 수 있는 통합 침입 감지 시스템입니다. 원하지 않는 침입을 감지하기 위해 ISA 서버는 네트워크 소통량과 로그 항목을 잘 알려진 공격 방법과 비교합니다. 의심이 가는 활동이 있으면 경고가 트리거되고 ISA 서버가 일련의 동작을 실행하도록 합니다. 프로그램 실행, 전자 메일 메시지 보내기, Windows 이벤트 로그에 이벤트 로깅, ISA 서버 서비스 중지 및 시작 또는 이와 같은 동작을 결합한 조치들이 가능합니다.

침입 감지를 사용하면 다음 공격에 대비해 경고를 구성할 수 있습니다:

• 모든 포트 검색공격자가 대상 컴퓨터나 네트워크에 열려 있는 포트를 알아내기 위해 사용하는 방법입니다. 침입 감지 엔진은 포트에 연결 시도를 계속 감지하다가 시도 횟수가 관리자 구성 임계값을 초과하면 경고를 보냅니다. 잘 알려진 포트(1-2048)에서만 포트 검색을 감지하도록 ISA 서버를 구성할 수도 있습니다.
• IP 절반 검색(IP Half Scan)이 공격은 모든 포트 검색과 유사하지만 TCP 통신이 3단계 프로세스라는 사실을 이용합니다. IP 절반 검색은 감지를 피하기 위해 TCP 3방향 핸드셰이크(three-way handshake)의 세 번째 패킷을 보내지 않습니다.
• 랜드 어택(Land Attack)대상 주소와 포트의 주소 및 포트 번호와 일치하는 거짓 원본 IP 주소와 포트 번호를 갖는 패킷을 컴퓨터로 보냅니다. 스푸핑된 패킷 때문에 대상 컴퓨터에서 루프가 시작되고, 결국에는 손상됩니다.
• 죽음의 핑(Ping of Death)엄청난 양의 ICMP 에코 요청(핑) 패킷을 한 대의 컴퓨터로 보내는 형태의 공격입니다. 대상 컴퓨터가 모든 패킷에 응답하려고 하면서 버퍼 오버플로가 발생하고, 결국 컴퓨터가 손상됩니다.
• UDP 폭탄(UDP Bomb)특정 필드의 잘못된 값 때문에 생성된 UDP 패킷이 수신되면서 일부 오래된 운영 체제가 손상됩니다. 대상 컴퓨터가 손상되면 대개 원인을 판단하기 어렵습니다.
• Windows 대역폭 파괴(Windows Out-of-Band)WinNuke라고도 하며 Windows 네트워크를 사용할 수 없게 만드는 서비스 거부 공격입니다. 공격이 성공하면 네트워크 연결이 끊기거나 취약한 컴퓨터가 손상됩니다.

추가 침입 감지 기능은 ISA 서버 타사 파트너에서 구하거나 ISA 서버 소프트웨어 개발 키트(SDK)에 있는 응용 프로그램 필터 인터페이스를 사용하여 만들 수 있습니다. 자세한 내용은 이 장 뒷부분에 있는 "추가 정보" 절을 참조하십시오.

참고:침입 시도 경고는 인터넷 보안의 ISA 서버 관리 콘솔과 Acceleration Server\Servers 및 Arrays\\Monitoring\Alerts 폴더에서 확인하십시오.

타사의 침입 감지 솔루션

네트워크 및 종점 침입 감지 시스템용 타사 솔루션이 있습니다. 이러한 타사 솔루션은 HTTP 이외의 프로토콜에 대한 지원뿐 아니라 잘 알려진 네트워크 컴퓨터 공격에 대한 스캔도 제공합니다.

침입 감지 시스템이 식별해야 하는 일반적인 공격 유형은 다음과 같습니다.

• 정찰(Reconnaisance) 공격이 공격은 침입자가 취약점을 찾기 위해 네트워크를 계속 탐색할 때 발생합니다. 핑 제거(ping sweep), DNS 영역 전송, 전자 메일 탐색, 포트 검색, 취약한 스크립트 및 예제 페이지를 찾기 위한 웹 사이트 콘텐트 다운로드 등의 공격이 포함됩니다.
• 이용(Exploit) 공격이 공격은 침입자가 숨겨진 기능이나 버그를 이용해서 시스템에 액세스할 때 발생합니다. 공격 지점은 흔히 이전 이용 공격에 의해 식별됩니다.
• 서비스 거부(DoS) 공격이 공격은 침입자가 네트워크 연결, CPU, 디스크 하위 시스템 등의 리소스를 오버로드하여 컴퓨터에서 실행되는 서비스를 손상시키려고 할 때 발생합니다. 침입자의 의도는 정보를 얻으려는 것이 아니라 컴퓨터를 사용할 수 없게 만드는 것입니다.

좋은 침입 감지 시스템은 3가지 유형의 공격을 식별할 수 있어야 합니다. 공격을 식별하는 데 다음 두 가지 방법을 사용할 수 있습니다.

• 변칙 감지네트워크에 적용된 컴퓨터의 기준에 따라 기준에서 벗어난 것은 침입 시도를 의미하는 것으로 식별합니다. 예를 들어, 작업 로드가 적은 시간대에 로그온 시도가 증가했다면 이를 통하여 피해를 입을 컴퓨터를 식별할 수 있습니다. 변칙 감지의 장점은 공격이 어떻게 발생하는지 정확히 알지 못하더라도 공격을 식별할 수 있다는 점입니다.
• 서명 인식잘 알려진 공격 패턴을 기반으로 공격을 식별합니다. 예를 들어, 대부분의 웹 서버 공격은 쉽게 식별할 수 있는 일반적인 공격 패턴을 사용합니다. 침입 감지 시스템은 들어오는 응용 프로그램 소통량을 데이터베이스의 서명 문자열과 비교하여 이러한 공격을 식별할 수 있습니다. 이러한 방식의 침입 감지 시스템은 새로운 서명의 공격을 식별하기 위해 서명 데이터베이스를 자주 업데이트해야 한다는 단점이 있습니다.

다음은 테스트하고 구축하는 데 사용할 수 있는 몇 가지 타사 제품입니다.

• BlackIce Defender
• CyberCop Scanner
• ICEpac Security Suite
• Cisco Secure IDS
• eTrust Intrusion Detection
• Snort
• Tripwire
• Foundstone Attacker

취약점 평가

수동 및 능동 침입 감지를 수행하는 것 외에 정기적인 취약점 평가도 필요합니다. 취약점 평가는 네트워크에 대한 공격을 시뮬레이션하고 공격자에게 노출될 수 있는 취약점을 검색하는 것입니다.

정기적으로 평가를 수행하면 공격자보다 먼저 취약점을 찾아서 네트워크의 약한 부분을 보완함으로써 취약점을 보호할 수 있습니다.

취약점 평가 도구를 선택할 때는 다음 사항을 고려하여 조사합니다.

• 데이터베이스 업데이트 메커니즘취약점에 대한 서명의 자동 업데이트 방법을 제공하여 단기간에 만료되지 않도록 해야 합니다.
• 허위 경고 최소화조직에서 보안과 관련되지 않은 이벤트를 조사하는 데 시간을 허비하지 않도록 허위 경고를 필터링해야 합니다.
• 결과를 데이터베이스에 저장하는 기능경향 분석을 수행하고 계속해서 보안의 변경 내용을 검색할 수 있도록 검색 결과를 보관할 수 있어야 합니다.
• 발견된 취약점에 대한 솔루션 제공취약점이 발견되면 문제를 해결하거나 취약점 보호 작업을 수행하는 방법에 관한 문서를 제공해야 합니다.

Windows 2000 네트워크에 대한 취약점 평가를 수행하는 데 사용할 수 있는 몇 가지 타사 도구는 다음과 같습니다.

• Symantec NetRecon 3.5
• BindView Security Advisor
• eEye Digital Security. Retina Network Security Scanner
• Internet Security Systems (ISS) Internet Scanner
• Network Associates CyberCop

또는 취약점 평가를 수행하는 타사 컨설팅 서비스를 이용하는 것이 더 좋을 수도 있습니다. 타사 서비스를 이용하면 사용자 네트워크에 대한 기존 지식이 전혀 없이 외부 공격자와 동일한 출발선에서 작업한다는 점에서 유리합니다. 평가 팀이 중립성을 유지한다는 전제 하에 이러한 외부 평가로부터 유용한 정보를 얻을 기회를 자주 가질 수 있습니다.

요약

감사 및 침입 감지는 사용자 환경의 효과적인 방어에 있어 중요한 부분입니다. 위험 관리 프로세스의 일환으로 감사 및 침입 감지가 사용자 환경에 얼마나 적합한지 판단해야 합니다. 여러 프로토콜에 대한 침입 감지를 위해 타사 도구를 고려해볼 수 있습니다.

추가 정보

• 외부 시간 서버:

  ntp2.usno.navy.mil 및 tock.usno.navy.mil

• ISA 서버 파트너 정보
• ISA 서버 솔루션 개발자 키트(SDK)
• Writing Secure Code, Michael Howard 및 David LeBlanc, MS Press, ISBN:0735615888