DNSSEC 적용 시 응답 패킷의 크기 비대화에 따른 단편화 공격 대응 기술

DNSSEC로 라벨링된 패킷이 취약한 서버를 향해 이동하며 날카로운 디지털 파편으로 산산조각 나는 모습으로, 보안 프로토콜 무결성 위협을 상징적으로 묘사합니다.

DNSSEC 응답 패킷 단편화 공격의 핵심 위협 진단

DNSSEC(Domain Name System Security Extensions)를 적용한 네임서버 운영 중, 예상치 못한 서비스 장애나 특정 클라이언트의 이름 해석 실패가 발생한다면 단편화 공격(Fragmentation Attack)을 의심해야 합니다. 구형 시스템일수록 소프트웨어 충돌보다 하드웨어 노후화가 원인일 확률이 높지만, DNSSEC 환경에서는 보안 프로토콜 자체의 특성이 새로운 취약점으로 작용합니다, 증상은 명확합니다. 긴 EDNS0 버퍼(예: 4096바이트)를 선언한 재귀 리졸버(Recursive Resolver)는 정상 응답을 받는 반면, 전통적인 512바이트 UDP 패킷 제한을 고수하는 구형 클라이언트나 중간 장비는 SERVFAIL 또는 시간 초과(Timeout) 오류를 반복적으로 경험합니다. 이는 공격자가 의도적으로 거대한 DNSSEC 응답(RRSig 레코드 다수 포함)을 생성하여 전송 경로 상의 취약한 노드에서 패킷 재조립에 실패하게 만드는 전형적인 공격 패턴입니다.

DNSSEC 응답 크기 증가와 단편화 메커니즘의 이해

단편화 공격의 근본 원인은 DNSSEC의 동작 방식에 있습니다, 기존 dns 응답에 디지털 서명(rrsig), 공개 키(dnskey), 위임 서명자(ds) 레코드 등이 추가되면서 응답 패킷의 크기가 비약적으로 증가합니다. 예를 들어, RSA-SHA256 등의 알고리즘을 사용하는 RRSig 레코드는 하나당 수백 바이트에 이릅니다. 여러 리소스 레코드 세트(RRset)에 서명이 필요할 경우, 응답 크기가 1500바이트(일반적인 이더넷 MTU)를 초과하는 것은 흔한 일입니다.

이러한 큰 패킷은 IP 계층에서 단편화(Fragmentation)되어 전송됩니다. 문제는 보안 상의 이유로 많은 네트워크 장비(방화벽, IPS)나 최신 운영체제가 IP 단편화 패킷의 재조립(Reassembly)을 제한하거나, 아예 차단하는 정책을 적용한다는 점입니다. 공격자는 이 점을 악용하여, 목표 도메인에 다수의 RRSig 레코드를 포함하도록 조작된 거대한 응답을 유도하고, 이 패킷이 단편화되어 특정 네트워크 구간에서 버려지도록 합니다. 결과적으로, 최종 클라이언트는 완전한 응답을 받지 못해 서비스 불능 상태에 빠집니다. 이 공격은 네임서버 자체를 다운시키지 않으며, 특정 피해자 그룹에게만 선택적으로 서비스 거부(DoS)를 유발하기 때문에 탐지가 더욱 어렵습니다.

대응 방법 1: 프로토콜 계층 최적화 및 기본 방어선 구축

가장 실용적이고 즉시 적용 가능한 방법은 네트워크와 프로토콜 설정을 조정하여 단편화 발생 자체를 최소화하거나, 발생하더라도 정상적으로 처리할 수 있는 환경을 조성하는 것입니다. 지금 당장 작동하는 해결책이 가장 훌륭한 기술적 자산입니다.

먼저, 권위 서버(Authoritative Server)와 재귀 리졸버 측에서 다음과 같은 설정을 검토 및 적용해야 합니다.

EDNS0 버퍼 사이즈 신중 조정

EDNS0(Extension Mechanisms for DNS)은 UDP 응답 크기를 협상하는 메커니즘입니다. 버퍼 사이즈를 크게 설정하면 TCP 폴백(Fallback)이 빨리 발생하여 단편화를 회피할 수 있지만, 과도하게 크면 오히려 공격 표면을 넓힐 수 있습니다.

권위 서버(BIND9 기준) 설정: options 절에서 edns-udp-size 값을 1232바이트로 제한하는 것이 현장에서 검증된 방법입니다. 이 크기는 대부분의 네트워크에서 단편화 없이 전달될 수 있는 실용적인 최대 크기입니다,
```
options {
    edns-udp-size 1232;
    max-udp-size 1232;
};
```
재귀 리졸버(unbound 기준) 설정: server: 섹션에서 다음과 같이 설정하여 업스트림으로 보내는 쿼리의 버퍼 크기를 제한합니다.
```
server:
    edns-buffer-size: 1232
    max-udp-size: 1232
```

TCP 전송 적극 활용 유도

단편화 문제의 근본적인 해결책은 UDP를 벗어나는 것입니다. 앞서 언급한 dNS는 응답이 512바이트를 초과하거나 단편화를 지원하지 않을 경우 TCP 포트 53으로 재시도하도록 프로토콜에 명시되어 있습니다.

TCP 응답 허용 보장: 모든 네임서버(권위/재귀)가 TCP 53번 포트를 통해 정상적으로 응답할 수 있도록 방화벽 규칙을 확인하십시오. 구형 장비에서는 TCP 연결에 대한 상태 검사(Stateful Inspection)가 제한적일 수 있어 예외 정책이 필요합니다.
재귀 리졸버의 TCP 폴백 정책: Unbound의 경우 tcp-upstream: yes 설정을 활성화하여 UDP 실패 시 TCP로 빠르게 전환하도록 유도합니다.

대응 방법 2: 네트워크 인프라 보안 강화 및 필터링

시스템 설정 최적화만으로는 공격 트래픽 자체를 걸러내지 못합니다. 네트워크 경계에서 비정상적인 단편화 패킷을 식별하고 차단하는 능동적인 방어 계층을 추가해야 합니다.

주의사항: 네트워크 장비 설정 변경은 즉시 통신 장애로 이어질 수 있습니다. 변경 작업 전 반드시 운영 장비가 아닌 환경에서 테스트를 수행하고, 변경 시간대와 롤백 계획을 수립해야 합니다. 모든 설정 전에 현재 구성의 백업은 필수입니다.

주요 네트워크 장비에서 적용할 수 있는 정책은 다음과 같습니다.

세션 테이블 타임아웃 조정: 방화벽이나 라우터의 IP 단편화 재조립 세션 타임아웃 시간을 DNSSEC 대용량 응답이 완전히 전달되기에 충분한 수준(기본값보다 길게, 예: 30초)으로 설정합니다. 동시에, 비정상적으로 많은 단편화 세션을 생성하는 단일 소스를 차단하는 정책을 추가합니다.
비정상 단편화 패킷 필터링: 첫 번째 단편(Offset=0)이 아닌 패킷만 단독으로 유입되는 경우를 공격 시그니처로 간주하여 차단할 수 있습니다. Cisco ASA 방화벽의 경우 fragment chain 관련 명령어로 이를 제어할 수 있습니다.
DDoS 방어 장비 활용: 클라우드 기반 DDoS 방어 서비스나 온프레미스 장비의 “DNS 프로토콜 보호” 기능 내에서 “DNS 단편화 공격(Fragmented DNS Attack)” 차단 룰셋을 활성화합니다. 이는 주로 짧은 시간 내에 동일 목적지로 향하는 다수의 단편화 패킷을 탐지합니다.

대응 방법 3: DNSSEC 운영 정책의 근본적 재검토

설정과 네트워크 조치가 일시적인 대응책이라면, DNSSEC 서명 정책을 최적화하는 것은 근본적인 문제 완화책입니다. 응답 크기를 줄이는 것이 핵심 목표입니다.

알고리즘 현대화: RSA-SHA256(키 길이 2048비트)보다 응답 크기가 작은 타원 곡선 암호(ECC) 알고리즘인 ECDSA P-256 with SHA256으로 전환을 검토하십시오. 동일한 보안 강도를 유지하면서 RRSig 레코드 크기를 약 60% 가량 줄일 수 있습니다. 최신 BIND나 PowerDNS는 해당 알고리즘을 지원합니다. 변경 시, 새 DNSKEY를 게시하고 DS 레코드를 레지스트리에 업데이트하는 롤오버(Rollover) 절차를 안전하게 따라야 합니다.
NSEC3 대신 NSEC 사용 고려: 영역 거부(Zone Denial)를 증명하기 위해 NSEC3를 사용 중이라면, 이로 인해 추가적인 해시 레코드로 응답 크기가 커질 수 있습니다. 스크립트 공격(Zone Enumeration)이 주요 위협이 아닌 경우, 더 간단하고 응답 크기가 작은 NSEC로의 전환을 검토할 수 있습니다. 이는 도메인 구조와 보안 요구사항에 따른 신중한 판단이 필요합니다.
영역 최소화(Zone Minimization) 적용: 재귀 리졸버에서 영역 최소화 기능을 활성화하면, 필요한 최소한의 질의만 권위 서버에 전송하게 됩니다. 이는 불필요하게 큰 응답을 유발할 수 있는 추가 질의를 줄이는 간접적 효과가 있습니다, unbound에서는 qname-minimisation: yes 로 설정합니다.

동일 문제 재발 방지를 위한 시스템 최적화 체크리스트

단편화 공격은 한 번 방어했다고 해서 영구히 안전한 것이 아닙니다. 새로운 도메인, 변경된 서명 정책, 네트워크 경로 변화에 따라 언제든 재발할 수 있습니다. 다음 체크리스트를 정기적으로 점검하여 시스템을 강화하십시오.

모니터링 구축: 네임서버 로그에서 반복적인 SERVFAIL 오류와 TCP 폴백 빈도를 모니터링합니다. SNMP나 NetFlow를 통해 UDP 단편화 패킷 카운트가 비정상적으로 증가하는지 관찰합니다.
정기적 취약성 평가: dig 명령어를 사용해 자체 도메인에 대한 대용량 응답 시뮬레이션을 수행합니다, dig +dnssec +bufsize=4096 +ignore example.com any 와 같은 명령으로 응답 크기를 측정하고, +tcp 옵션 없이 udp만으로 응답을 받아보는 테스트를 주기적으로 실행합니다.
네트워크 경로 검증: 다양한 지역(특히 해외)에서의 이름 해석 성공 여부를 확인하는 외부 모니터링 서비스를 활용합니다. 특정 지역에서만 지속적인 실패가 발생한다면, 해당 구간의 네트워크 장비에 단편화 필터링 문제가 있을 수 있습니다.
소프트웨어 지속적 업데이트: BIND, Unbound, PowerDNS 등의 DNS 소프트웨어는 지속적으로 단편화 처리 및 DNSSEC 효율성과 관련된 개선이 이루어집니다. 안정적인 최신 버전을 유지하는 것이 장기적 보안과 안정성에 필수적입니다.

전문가 팁: 예측 기반 대응 전략 가장 효과적인 방어는 공격이 발생하기 전에 취약점을 제거하는 것입니다. 프로덕션 환경에 변경사항(예: 새로운 알고리즘 도입, 버퍼 크기 조정)을 적용하기 전, 스테이징(Staging) 환경에서 철저한 부하 테스트를 수행하십시오. dnsperf나 resperf와 같은 도구를 이용해 대용량 DNSSEC 응답을 생성하는 트래픽을 시뮬레이션하고, 시스템(네임서버, 방화벽, 로드 밸런서)의 응답 처리 성공률과 TCP 전환률을 측정하십시오. 이를 통해 실제 장애 발생 시점이 아닌, 계획된 시간에 최적의 설정값을 찾아 적용할 수 있습니다. 게다가. 앞서 언급한 dnssec 서명 키 롤오버 주기를 엄격히 관리하고, 롤오버 기간 중 예상되는 응답 크기 증가에 대비한 네트워크 정책 임시 조정 계획을 수립해 두는 것이 운영의 안정성을 확보합니다.