위조된 응답으로 경쟁에서 이기기
공격자
진짜 응답과 경쟁
위조된 응답
먼저 도착
리졸버 캐시
공유하는 모두에게 오염됨
DNS 스푸핑과 캐시 포이즈닝: 실무 개요
DNS는 원래 응답이 실제로 응답했다고 주장하는 네임서버에서 왔는지 검증할 방법 없이 설계되었습니다. 이 허점이 스푸핑을 가능하게 합니다. DNS 질의를 가로채거나 응답 경쟁에서 앞설 수 있는 위치의 공격자는 피해자를 공격자가 고른 주소로 보내는 위조 응답을 되돌려 보낼 수 있으며, 정상 사이트를 사칭하는 악성 서버로 트래픽을 우회시키는 데 자주 쓰입니다.
캐시 포이즈닝: 같은 발상을 대규모로
캐시 포이즈닝은 같은 위조 응답 발상을 단일 피해자가 아니라 공유 리졸버를 겨냥해 적용합니다. 공격자가 널리 쓰이는 재귀 리졸버의 캐시에 위조된 응답을 끼워 넣는 데 성공하면, 그 리졸버를 이용하는 모든 사용자가 만료될 때까지 오염된 응답을 받게 됩니다. 한 번의 위조 성공이 같은 리졸버를 쓰는 모든 사람에 대한 공격으로 이어지며, 개별 질의를 하나하나 가로챌 필요도 없습니다.
최신 DNS는 이를 어떻게 방어하나요
| 방어 수단 | 막아 주는 것 | 보편적으로 배포되었나요? |
|---|---|---|
| 소스 포트 / 질의 ID 무작위화 | 진짜 응답이 도착하기 전에 위조 응답을 추측해 맞히는 것 | 예, 2008년 이후 표준 |
| DNSSEC | 권한 서버를 사칭하는 위조 응답 | 아니요. 인터넷 전반에서 부분적으로만 도입됨 |
| DNS-over-HTTPS / DNS-over-TLS | 질의 자체에 대한 경로상 가로채기 | 늘고 있지만 모든 곳에서 기본값은 아님 |
이 방어책 중 어느 것도 보편적으로 배포되지는 않았으며, 특히 DNSSEC는 인터넷을 구성하는 도메인 전반에서 여전히 부분적으로만 도입되어 있습니다. DNSSEC가 적용되지 않는 경우에도, 잘 운영되고 보안을 중시하는 공개 리졸버를 사용하고, 예상 밖이거나 의심스러운 확인 결과는 독립적인 두 번째 리졸버에서 다시 확인하는 것이 현실적인 예방책입니다.
이 문제를 보는 시각을 바꾼 버그
캐시 포이즈닝은 2008년에 더 이상 이론적인 우려에 그치지 않게 되었습니다. 보안 연구원 댄 카민스키(Dan Kaminsky)가 당시 사용되던 거의 모든 DNS 리졸버에 영향을 주는 근본적인 결함을 공개했기 때문입니다. 공격자가 추측해야 하는 트랜잭션 ID와 소스 포트의 경우의 수가 충분히 작아서, 빠른 연결에서 몇 초 만에 무차별 대입이 가능했고, 단일 레코드가 아니라 도메인 전체에 대해 리졸버의 캐시를 오염시킬 수 있었습니다. 이 공개로 모든 주요 DNS 소프트웨어 공급업체가 이례적으로 조율된 동시 패치를 배포했고, 소스 포트 무작위화는 거의 하룻밤 사이에 표준이 되었으며, 위에 나열한 방어책이 현재의 형태로 존재하게 된 큰 이유가 되었습니다.
해결책이 20년 되었는데도 DNSSEC 도입이 더딘 이유
DNSSEC는 포트 무작위화만으로는 해결할 수 없는 근본적인 신뢰 문제를 훨씬 완전하게 해결합니다. 추측을 더 어렵게 만드는 것이 아니라 암호학적 증명이기 때문입니다. 도입이 느린 것은 그 가치에 대한 의구심보다 운영의 복잡성 때문입니다. 존에 올바르게 서명하고, 검증이 깨지지 않도록 일정에 맞춰 키를 교체하며, 루트에서 특정 도메인까지 신뢰 사슬을 온전히 유지하는 일은 서명되지 않은 A 레코드를 추가하는 것보다 훨씬 까다롭습니다. 이 과정에서 실수가 하나만 생겨도 이 시리즈의 다른 글에서 다룬 SERVFAIL 장애가 정확히 발생하며, 이는 DNS 전문 인력이 없는 소규모 도메인 운영자에게 그 자체로 도입을 망설이게 하는 요인입니다. “이론상 해결됨”과 “실제로 모든 곳에 배포됨” 사이의 격차는 보안 인프라 전반에서 흔하며, DNSSEC가 그 분명한 사례입니다.
도메인의 공개 DNS 주소를 확인해야 하나요? Domain IP Lookup 도구를 사용해 보세요.
관련 글
공개 주소 공간과 사설 주소 공간
공개 IP
192.0.2.10
전역에서 고유, 어디서나 라우팅 가능
사설 대역
공개 인터넷에서는 라우팅 불가
사설 IP 대역이 공개적으로 확인되어서는 안 되는 이유
10.0.0.0/8, 192.168.0.0/16과 그 이웃 대역은 전 세계에서 고유하지 않도록 만들어졌습니다. 이것이 DNS에서 왜 중요한지 설명합니다.
SSRF는 서버를 의도치 않은 프록시로 만듭니다
공격자
요청 URL 조작
취약한 서버
SSRF에 속아 가져옴
169.254.169.254
메타데이터 엔드포인트
자격 증명
공격자에게 반환
클라우드 메타데이터 엔드포인트, 숨은 공격 표면
라우팅되지 않을 것처럼 보이는 IP 주소 하나가 클라우드 인스턴스의 자격 증명과 설정으로 이어지며, SSRF의 단골 표적이 됩니다.
같은 주소를 쓰는 네 가지 방법
SSRF 공격 설명: DNS는 어떻게 악용될까
서버 측 요청 위조(SSRF)는 서버가 속아서 확인하고 요청해 버린, 평범해 보이는 도메인 이름 하나에서 시작되는 경우가 많습니다.