보안 DNS: DNSSEC 및 HTTPS를 통한 DNS(DoH)

Domain Name System (DNS)은 사람이 읽을 수 있는 도메인 이름을 IP 주소로 변환합니다. 1980년대에 설계된 DNS는 보안 기능 없이 구축되었으며, 쿼리와 응답은 인증 없이 UDP/TCP 포트 53을 통해 평문으로 이동합니다. 이로 인해 두 가지 주요 취약점이 발생합니다. DNS 캐시 포이즈닝(위조된 DNS 응답을 주입하여 사용자를 악성 서버로 리디렉션)과 DNS 도청(사용자가 어떤 도메인을 쿼리하는지 관찰하여 검색 활동을 파악)입니다. 이 문제를 해결하는 두 가지 표준은 위조를 방지하는 DNSSEC와 도청을 방지하는 DNS over HTTPS (DoH)입니다.

DNS 캐시 포이즈닝(Kaminsky 공격)은 DNS 프로토콜에 인증이 없다는 점을 악용합니다. Resolver는 권한 있는 DNS 서버에 쿼리를 보내고 TTL 기간 동안 응답을 캐시합니다. 트랜잭션 ID(16비트이며 예측 가능)와 소스 포트를 추측할 수 있는 공격자는 위조된 응답을 보낼 수 있습니다. 소스 포트는 RFC 5452 이후 추가 엔트로피로 사용됩니다. Resolver가 이 응답을 캐시하면 해당 Resolver를 쿼리하는 모든 사용자가 공격자의 서버로 리디렉션됩니다. 캐시가 오염되면 사용자가 올바른 도메인을 입력했더라도 가짜 서버로 연결됩니다. DNSSEC는 DNS 응답에 디지털 서명을 추가하여 이를 방지합니다.

DNSSEC는 DNS 레코드에 암호화 서명을 추가하여 Resolver가 응답이 올바른 영역 권한 기관에서 왔으며 변조되지 않았는지 확인할 수 있게 합니다. DNSSEC에는 새로운 레코드 유형이 도입됩니다. RRSIG(리소스 레코드 서명, 레코드 집합에 대한 실제 서명), DNSKEY(서명을 확인하는 데 사용되는 공개 키), DS(위임 서명자, 상위 영역과 하위 영역의 키 연결), NSEC/NSEC3(인증된 존재 부인, 이름이 존재하지 않음을 증명)입니다. DNSSEC는 ICANN이 서명한 루트 영역에서 TLD 및 권한 있는 영역으로 이어지는 신뢰 체인을 생성합니다.

DNSSEC는 두 가지 유형의 서명 키를 사용합니다. Zone Signing Key (ZSK)는 개별 DNS 레코드 집합(RRSIG)에 서명하며 운영상의 유연성을 위해 자주(매월 또는 분기마다) 교체합니다. Key Signing Key (KSK)는 DNSKEY 레코드 집합에 서명하여 해당 영역의 신뢰 앵커를 제공합니다. KSK가 변경될 때마다 상위 영역을 새 DS 레코드로 업데이트해야 하므로 조정이 필요한 만큼, KSK는 더 드물게(매년) 교체합니다. KSK는 ZSK를 확인하고 ZSK는 데이터에 서명합니다. 이 2계층 구조는 빈번한 ZSK 교체를 통한 보안과 드문 KSK 교체를 통한 운영 부담 감소 사이의 균형을 맞춥니다.

DNSSEC에는 중요한 제한 사항이 있습니다. DNS 쿼리를 암호화하지 않습니다. 무결성을 위해 응답에 서명할 뿐입니다. 따라서 도청자는 모든 DNS 쿼리를 볼 수 있지만 응답을 위조할 수는 없습니다. 영역 열거: 존재하지 않음을 증명하는 NSEC 레코드를 사용하면 공격자가 영역을 순회하여 그 안의 모든 도메인 이름을 열거할 수 있습니다. NSEC3는 해시된 이름을 사용해 이를 완화하지만 완벽하지는 않습니다. 운영 복잡성: 키 관리, 서명 만료, 상위 영역과의 조정으로 인해 상당한 운영 부담이 발생합니다. DNSSEC 도입도 아직 완전하지 않습니다. 많은 TLD와 등록 기관이 이를 지원하지만, 아직 배포하지 않은 조직도 많습니다.

HTTPS를 통한 DNS(DoH)는 HTTPS(RFC 8484) 내부에서 DNS queries를 암호화하여 네트워크 감시자가 query 내용을 볼 수 없게 합니다. queries는 표준 HTTPS URL에서 DoH를 지원하는 resolver로 전송되므로 DNS traffic이 다른 HTTPS traffic과 구분되지 않습니다. 이를 통해 ISP, 고용주, 그리고 경로상 공격자가 사용자가 어떤 도메인을 query하는지 확인하지 못하게 하며, DNSSEC이 해결하지 못하는 privacy gap을 보완합니다. 그러나 DoH를 사용하면 신뢰 대상이 네트워크의 DNS resolver에서 DoH provider로 이동합니다(일반적으로 Google 8.8.8.8, Cloudflare 1.1.1.1 또는 조직 자체의 DoH resolver). 현재 대부분의 주요 browser는 DoH를 기본적으로 지원합니다.

TLS를 통한 DNS(DoT)(RFC 7858)는 HTTPS를 통해 tunneling하는 대신 전용 TCP port 853에서 TLS를 사용하여 DNS queries를 암호화합니다. DoT는 도청자가 query 내용을 볼 수 없게 하는 등 DoH와 동일한 privacy benefits를 제공하지만, 네트워크 관리자가 식별하고 차단하기는 더 쉽습니다(port 853과 port 443의 차이). 이는 양날의 검입니다. DoT는 노출되어 있어 enterprise Firewall이 차단할 수 있는 반면, DoH는 일반 HTTPS traffic에 영향을 주지 않고 차단하기가 더 어렵습니다. Stub resolver(OS 수준)는 DoT를 더 흔히 사용하고, browser는 DoH를 더 흔히 사용합니다.

Encrypted DNS는 DNS 기반 filtering과 sinkhole에 의존하는 enterprise environment에 challenge를 일으킵니다. browser가 external DoH resolver를 사용하면 internal DNS control이 우회됩니다. Enterprise 대응책은 다음과 같습니다. internal DoH/DoT resolver(Cisco Umbrella, DoH를 사용하는 Pi-hole)를 deploy하고 모든 device가 이를 사용하도록 configure합니다. external DoH resolver IP(Google 8.8.8.8, Cloudflare 1.1.1.1)를 Firewall에서 port 443 기준으로 block합니다. 관리되는 endpoint에서는 Group Policy를 사용해 browser 수준의 DoH를 disable합니다. 또한 port 853의 DNS-over-TLS를 가로채는 transparent proxy rule을 적용합니다. 목표는 Encrypted DNS를 완전히 차단하지 않으면서 모든 DNS를 control되는 resolver로 route하는 것입니다.

완전한 DNS security strategy는 여러 control을 결합합니다. DNSSEC은 authoritative zone의 DNS record에 KSK/ZSK key pair를 사용한 cryptographic signature를 추가하여 해당 domain의 cache poisoning을 방지합니다. DNS 기반 filtering(Cisco Umbrella, Cloudflare Gateway)은 resolver 수준에서 malicious domain을 block합니다. control되는 resolver로의 DoH/DoT는 filtering visibility를 잃지 않으면서 query privacy를 제공합니다. DNS logging을 SIEM으로 전송하면 threat hunting을 위해 모든 query를 수집할 수 있습니다. DNS log는 C2 traffic, DNS tunneling을 통한 data exfiltration, malware의 domain generation algorithm(DGA) activity를 드러냅니다. DNS telemetry는 현재 이용 가능한 security data source 중 가장 가치가 높은 것 중 하나입니다.

DNS tunneling은 DNS queries와 responses 내부에 data를 encode하여 data를 exfiltrate하거나 다른 outbound traffic이 차단된 network를 통해 C2 channel을 구축합니다. iodine, DNScat, dnscat2와 같은 tool은 subdomain label(예: EXFILTRATEDDATA.evil.com) 또는 TXT record에 payload를 encode합니다. Detection 방법은 다음과 같습니다. 비정상적으로 긴 DNS query name(>100자), 단일 host에서 발생하는 높은 query volume, 존재하지 않는 상위 domain에 대한 query, 비정상적인 record type(TXT, NULL), 그리고 domain label의 entropy analysis(encode된 data는 높은 Shannon entropy를 가짐)입니다. DNS security analytics platform은 tunneling pattern을 자동으로 flag합니다.

DNS Response Policy Zones(RPZ)를 사용하면 DNS resolver가 DNS response에 local override policy를 적용할 수 있습니다. 즉, global DNS infrastructure를 수정하지 않고 resolver 수준에 local sinkhole을 만들 수 있습니다. client가 알려진 malicious domain을 query하면 RPZ policy는 NXDOMAIN, sinkhole IP로의 redirect 또는 passthrough response를 반환합니다. RPZ feed는 threat intelligence provider(Spamhaus, SURBL)에서 제공되며 BIND 또는 Unbound resolver로 직접 import할 수 있습니다. RPZ는 client-side configuration 없이 network의 모든 device에 DNS layer에서 filtering을 적용하므로 강력한 defensive tool입니다.

이 lesson에서 다룬 CompTIA Security+(SY0-701) concept을 얼마나 이해했는지 확인해 보십시오.

이 lesson에서는 다음을 배웠습니다. DNSSEC은 KSK/ZSK key pair를 사용해 DNS record에 cryptographic signature를 추가하여 cache poisoning을 방지하지만 query를 암호화하지는 않습니다. HTTPS를 통한 DNS(DoH)는 HTTPS 내부에서 DNS query를 암호화하여 도청을 방지하지만 enterprise filtering 우회 risk를 만듭니다. DNS tunneling은 DNS query에 data를 encode하며 query length, volume, entropy analysis를 통해 detection할 수 있습니다. 다음 lesson에서는 IPsec, VPN protocol, remote access security를 살펴봅니다.