팔로우 Windows DNS 서버는 이벤트 뷰어에 세 곳, 그리고 선택적으로 텍스트 파일에 로그를 기록합니다:
- Microsoft → Windows → DNS-Server → Audit: 존 및 레코드 변경. 현재 Windows Server에서는 기본 활성화됨.
- Microsoft → Windows → DNS-Server → Analytical: 모든 쿼리와 응답. 기본적으로 비활성화되어 있으며 분석 로그를 표시하면 나타납니다.
- DNS 서버, 응용 프로그램 및 서비스 로그 하에: 서비스 수준 이벤트 예를 들어 시작, 정지 및 존 로드 오류.
- The 디버그 로그, DNS 관리자에서 활성화하여 일반적으로 C:WindowsSystem32dnsdns.log에 저장되는 텍스트 파일입니다.
핵심 내보내기는 권한 상승 명령 프롬프트에서의 한 줄입니다:
wevtutil epl "Microsoft-Windows-DNSServer/Audit" C:logsdns_audit.evtx
네트워크의 거의 모든 것이 DNS 쿼리를 실행하며, 악성 소프트웨어도 포함됩니다. 쿼리 로그는 DNS 터널링, 도메인 생성 알고리즘, 알려진 유해 도메인에 대한 호출을 노출합니다. 감사 로그는 누군가 조용히 레코드를 변경하는 것을 노출합니다. Prime Core는 {N}개의 탐지 규칙을 DNS 데이터에 제공하며, 이는 {M}개의 MITRE ATT&CK 기법에 매핑됩니다. 이 중 DNS 명령 및 제어(T1071.004)와 도메인 생성 알고리즘(T1568.002)이 포함됩니다.
시작하기 전에
쿼리 로깅이 아마도 활성화되지 않았습니다. 분석 채널은 기본적으로 비활성화되어 있습니다. 이미 발생한 무언가를 조사하고 있다면 서버의 쿼리 로그는 없을 가능성이 높습니다. 클라이언트 측(Sysmon 이벤트 22 또는 DNS 클라이언트 로그), 방화벽 또는 프록시 로그, 네트워크 센서가 옵션입니다. 지금 활성화하면 앞으로 도움이 됩니다.
쿼리 로깅을 켜기 (미래를 위해). 이벤트 뷰어에서 보기 → 분석 및 디버그 로그 표시를 선택한 다음, 오른쪽 클릭 분석 DNS-Server 하에서 선택한 다음 로그 활성화를 선택하십시오. 또는 명령줄에서:
wevtutil sl "Microsoft-Windows-DNSServer/Analytical" /e:true
Microsoft는 오버헤드를 적당하다고 설명하지만, 매우 바쁜 리졸버에서는 켜기 전에 테스트하십시오.
DNS 서버나 DNS를 실행하는 도메인 컨트롤러에서 권한 상승 프롬프트가 필요합니다.
로그 내보내기
:: 레코드 및 존 변경
wevtutil epl "Microsoft-Windows-DNSServer/Audit" C:logsdns_audit.evtx
:: 서비스 수준 이벤트
wevtutil epl "DNS Server" C:logsdns_server.evtx
:: 쿼리 및 응답 (분석이 활성화된 경우에만)
wevtutil epl "Microsoft-Windows-DNSServer/Analytical" C:logsdns_analytical.evtx
분석 채널은 일반 로그와 다르게 작동합니다. 이벤트 뷰어는 이벤트를 표시하기 전에 로그를 비활성화하라는 요청을 할 수 있습니다. PowerShell의 Get-WinEvent는 -Oldest로만 읽습니다.
디버그 로그 는 일반 텍스트로, DNS 관리자 → 서버 속성 → 디버그 로깅에서 구성됩니다. 패킷을 상세하게 기록하며, 크기 제한에 도달하면 이전 항목을 덮어씁니다. 그대로 복사: copy C:WindowsSystem32dnsdns.log C:logs.
찾아볼 것
| 신호 | 의미할 수 있는 것 |
|---|---|
| 쿼리에서 매우 길고 무작위로 보이는 서브도메인 | DNS 터널링, 쿼리 이름에서 데이터 밀수 |
| 하나의 클라이언트에서 많은 실패한 조회(NXDOMAIN) 생성 | 생성된 도메인을 순환하는 악성 소프트웨어 |
| 한 호스트에서 많은 양의 TXT 쿼리 | 터널링 또는 명령 및 제어 |
| 변경 윈도우 외부에서 생성, 삭제 또는 변경된 레코드의 감사지 이벤트 | 레코드 하이재킹, 예: 새로운 wpad 레코드 |
| DNS 서버 서비스에 의해 로드된 플러그인 DLL | DnsAdmins 그룹을 악용하여 SYSTEM으로 코드 실행 |
LogTotal에 업로드하고 검토
LogTotal은 EVTX를 네이티브하게 읽습니다. 먼저 알아야 할 한 가지: LogTotal은 아직 EVTX 파일을 정화하지 않습니다. DNS 로그는 내부 호스트 이름과 클라이언트 IP를 포함합니다. 업로드를 원본 파일을 넘기는 것으로 처리하십시오: 테스트 서버에 괜찮습니다; 프로덕션의 경우 데이터를 다루는 사람에게 먼저 동의를 얻으십시오.
오늘 날 정화가 필요하다면, 먼저 JSON으로 변환하십시오: evtx_dump -o jsonl dns_audit.evtx > dns_audit.jsonl.
- 업로드. 열기 logtotal.com 에 파일을 드롭하십시오.
- 검토.
문제가 발생할 때
| 증상 | 가능한 원인 | Fix |
|---|---|---|
| 이벤트 뷰어에 분석 채널 없음 | 분석 로그는 기본적으로 숨겨져 있음 | 보기 → 분석 및 디버그 로그 표시 |
| 분석 채널이 비어 있음 | 한번도 활성화된 적 없음 | 활성화하십시오; 그 전에는 기록 없음 |
| 분석 로그에서 Get-WinEvent 오류 | 분석 로그는 -Oldest가 필요함 | -Oldest 추가 |
| 감사 채널이 없음 | 업데이트가 없는 이전 Windows Server | OS 버전 확인; 디버그 로그 사용 |
| 디버그 로그가 짧은 시간만 포함함 | 크기 제한에서 스스로 덮어썼음 | 제한을 올리거나 다른 곳으로 로그 전송 |
FAQ
서버 로그 또는 클라이언트 로그?
DNS 서버는 어떤 클라이언트 IP가 요청했는지 알려줍니다. 클라이언트만이 어떤 프로세스가 요청했는지 알려줍니다. 이것이 엔드포인트에서 Sysmon 이벤트 22가 서버 로그를 훌륭하게 보완하는 이유입니다.
디버그 로그가 분석 채널보다 나은가?
디버그 로그는 더 많은 패킷 세부사항을 포함하지만 비용이 많이 들고 스스로를 덮어씁니다. 대부분의 조사에서는 분석 채널이 더 나은 기본 옵션입니다.
