DNS의 주요 보안 취약점

DNS는 대부분의 네트워크에서 기본적으로 사용되는 핵심 서비스이다. 사용자가 입력한 도메인 이름을 IP 주소로 변환해 주기 때문에 DNS가 잘못된 정보를 전달하거나 공격자에게 악용되면 정상적인 서비스가 공격자의 시스템으로 연결되거나, 내부 정보가 노출되거나, DDoS와 데이터 유출의 통로가 될 수 있다.

이번 글에서는 클라우드의 Private DNS나 관리형 DNS 서비스로 넘어가기 전에, 고전적인 DNS 환경에서 자주 언급되는 주요 보안 취약점과 각각의 대응 방법을 정리해 본다.

1. DNS Cache Poisoning

DNS Resolver는 매번 Authoritative DNS에 질의하지 않도록 조회 결과를 일정 시간 캐시에 저장한다. Cache Poisoning은 공격자가 위조된 DNS 응답을 Resolver의 캐시에 저장하도록 만들어 이후 사용자가 잘못된 IP 주소를 전달받게 하는 공격이다.

예를 들어 정상적인 www.example.com이 192.0.2.10을 가리키는데 공격자가 Resolver의 캐시를 조작해 203.0.113.50을 저장하게 만들었다면, 이후 동일한 Resolver를 사용하는 사용자는 공격자가 지정한 서버로 연결될 수 있다.

공격자가 위조 DNS 응답을 Resolver 캐시에 삽입해 사용자를 가짜 서버로 유도하는 DNS Cache Poisoning 구조
위조된 DNS 응답이 Resolver 캐시에 저장되면 사용자가 공격자의 서버로 연결될 수 있다.

대응 방법

  • DNSSEC 검증을 사용해 DNS 응답의 출처와 무결성을 확인한다.
  • Resolver 소프트웨어와 운영체제를 최신 상태로 유지한다.
  • DNS Transaction ID와 Source Port를 충분히 무작위화하는 최신 Resolver를 사용한다.
  • 불필요한 외부 사용자가 Resolver에 접근하지 못하도록 접근 범위를 제한한다.

DNSSEC는 DNS 통신을 암호화하는 기능은 아니다. DNS 레코드가 신뢰할 수 있는 출처에서 왔고 전송 중 변조되지 않았는지를 검증하는 기술로 이해하는 것이 정확한다.

2. DNS Zone Transfer 노출

Authoritative DNS 서버 사이에서는 Zone 정보를 동기화하기 위해 AXFR 또는 IXFR 방식의 Zone Transfer를 사용할 수 있다. 문제는 Zone Transfer가 필요하지 않은 시스템이나 사용자에게까지 허용되어 있을 때이다.

공격자가 Zone Transfer에 성공하면 web01, db01, vpn, mail, admin처럼 서비스 이름과 호스트 정보를 한꺼번에 수집할 수 있다. 직접적인 시스템 침해가 아니더라도 공격 대상 식별과 내부 구조 파악에 상당히 유용한 정보가 된다.

대응 방법

  • Zone Transfer는 실제 Secondary DNS 서버의 IP 주소에만 허용한다.
  • DNS 서버 ACL을 이용해 AXFR/IXFR 요청 출발지를 제한한다.
  • 가능한 환경에서는 TSIG를 사용해 Zone Transfer 요청을 인증한다.
  • 외부에서 내부 DNS 서버의 TCP 53 포트에 불필요하게 접근할 수 없는지 확인한다.

3. Open Resolver와 DNS Amplification

Recursive DNS Resolver가 인터넷 전체에서 재귀 질의를 받아주도록 구성되어 있으면 Open Resolver가 된다. Open Resolver 자체가 곧 침해를 의미하는 것은 아니지만, 공격자가 이를 DNS Amplification DDoS에 악용할 수 있다는 점이 문제이다.

공격자는 DNS 질의의 Source IP를 피해자의 IP로 위조한 뒤 비교적 작은 DNS 요청을 여러 Resolver에 전송한다. Resolver가 더 큰 DNS 응답을 피해자에게 보내면 공격 트래픽이 증폭된다. 이런 공격은 UDP 기반 DNS가 출발지 위조에 취약한 특성을 이용한다.

공격자가 여러 Open Resolver에 작은 위조 요청을 보내 큰 DNS 응답을 피해 서버로 집중시키는 DNS Amplification 구조
작은 위조 요청이 여러 Open Resolver를 거치며 큰 응답 트래픽으로 증폭된다.

대응 방법

  • Recursive DNS는 사내망, 관리망 등 필요한 네트워크에서만 사용할 수 있도록 제한한다.
  • Authoritative DNS와 Recursive Resolver 역할을 가능하면 분리한다.
  • Response Rate Limiting(RRL)을 적용해 비정상적인 반복 응답을 줄이다.
  • 네트워크 구간에서는 Source IP Spoofing을 방지하는 ingress/egress filtering을 적용한다.

4. DNS Spoofing

DNS Spoofing은 공격자가 정상 DNS 서버보다 먼저 위조된 응답을 전달하거나 네트워크 중간에서 DNS 응답을 변조해 사용자를 잘못된 목적지로 보내는 공격을 의미한다. Cache Poisoning이 Resolver의 캐시 자체를 오염시키는 공격이라면, Spoofing은 특정 DNS 질의와 응답 과정에서 가짜 응답을 전달하는 개념까지 넓게 포함한다.

특히 신뢰하기 어려운 무선 네트워크나 내부 네트워크가 침해된 환경에서는 평문 DNS 트래픽이 공격 대상이 될 수 있다.

대응 방법

  • DNSSEC Validation을 적용해 위조된 DNS 데이터의 수용 가능성을 낮춘다.
  • 클라이언트와 Resolver 사이의 보호가 필요한 경우 DoT 또는 DoH 같은 암호화 DNS를 검토한다.
  • 사내 환경에서는 승인된 DNS Resolver만 사용하도록 네트워크 정책을 구성한다.
  • ARP Spoofing, Rogue DHCP 등 DNS 서버 주소를 공격자 시스템으로 바꾸는 네트워크 공격도 함께 통제한다.

기업 환경에서는 DoH나 DoT를 무조건 허용하는 것이 답은 아니다. 사용자가 임의의 외부 DNS Resolver를 이용하게 되면 오히려 사내 DNS 필터링과 로깅을 우회할 수 있으므로, 승인된 Resolver를 통한 암호화 DNS 사용이 중요한다.

5. DNS Tunneling

DNS는 일반적인 서버 환경에서도 외부 통신을 위해 허용되는 경우가 많다. 공격자는 이 특성을 이용해 데이터를 Subdomain 영역에 인코딩하고 DNS 질의 형태로 외부의 공격자 DNS 서버까지 전달할 수 있다. 이를 DNS Tunneling이라고 한다.

내부 감염 서버가 DNS 질의에 데이터를 숨겨 승인 Resolver를 거쳐 외부 공격자 DNS 서버로 전송하는 구조
DNS 질의에 데이터를 숨기면 방화벽과 Resolver를 거쳐 외부로 유출될 수 있다.
encoded-data.attacker.example

DNS Tunneling은 데이터 유출뿐 아니라 악성코드의 Command & Control 통신에도 사용될 수 있다. 따라서 DNS 서버 자체의 취약점이라기보다는 DNS 프로토콜을 우회 통신 채널로 악용하는 공격에 가깝다.

대응 방법

  • 서버와 사용자 단말이 승인된 내부 DNS Resolver만 사용하도록 제한한다.
  • 외부로 직접 나가는 UDP/TCP 53 통신을 차단하고 필요한 Resolver에서만 허용한다.
  • DoT 853과 외부 DoH 사용도 보안 정책에 포함해 우회 경로를 관리한다.
  • DNS Query Logging을 활성화하고 비정상적으로 긴 도메인, 높은 질의 빈도, 랜덤한 문자열 형태의 Subdomain을 모니터링한다.
  • DNS Firewall, RPZ 또는 보안 DNS 서비스를 이용해 알려진 악성 도메인을 차단한다.

마치며

DNS는 오래된 프로토콜이지만 지금도 거의 모든 시스템의 통신 시작점에 있다. 그래서 DNS 보안은 단순히 DNS 서버에 취약점이 있는지만 확인하는 것으로 끝나지 않는다. 누가 Resolver를 사용할 수 있는지, DNS 정보가 외부로 얼마나 노출되는지, 응답의 신뢰성을 어떻게 확인하는지, DNS 트래픽을 이용한 우회 통신을 탐지할 수 있는지까지 함께 봐야 한다.