1. Biblioteca
  2. DNS
  3. DNS 보안

Atualizado há 1 mês

공격자가 DNS 서버에 60바이트짜리 질문을 보냅니다. 서버는 4,000바이트짜리 답변을 보냅니다—하지만 공격자에게 보내지 않습니다. 완전히 다른 누군가에게. 아무것도 요청하지 않은 사람에게.

이것을 수천 개의 서버, 수백만 건의 쿼리로 곱하면 DNS 증폭이 됩니다: 적은 대역폭을 압도적인 홍수로 바꾸는 방법. 공격자는 속삭이고, 피해자는 비명 속에 익사합니다.

증폭의 원리

DNS 증폭은 DNS가 작동하는 방식의 두 가지 특성을 악용합니다.

첫째, 비대칭성입니다. DNS 쿼리는 작지만, 응답은 매우 클 수 있습니다. 도메인의 TXT 레코드—SPF 정책, DKIM 키, 도메인 인증 문자열—를 요청하면 보낸 것보다 50~100배 많은 데이터를 돌려받을 수 있습니다.

둘째, 맹목적인 신뢰입니다. DNS는 전통적으로 UDP로 실행되는데, UDP는 실제로 누가 요청하는지 검증하지 않습니다. 쿼리가 도착하면 서버는 출발지 IP 주소를 보고 그것을 믿습니다. 그 주소가 위조—피해자의 주소로 스푸핑—되어 있다면, 서버는 충실하게 큰 응답을 피해자에게 보냅니다.

공격자는 응답을 볼 필요가 없습니다. 그럴 필요도 없죠. 도움을 주려는 서버들을 통해 자신의 대역폭을 피해자의 문제로 전환했고, 그것도 여러 배로 증폭해서 말이죠.

오픈 리졸버: 자기도 모르게 무기가 된 것들

공격에는 누구의 쿼리에도 응답하려는 DNS 서버가 필요합니다. 이를 오픈 재귀 리졸버라고 합니다.

일부는 의도적으로 존재합니다—Google의 8.8.8.8이나 Cloudflare의 1.1.1.1 같은 공개 DNS 서비스가 그것입니다. 하지만 수십만 개 이상이 우연히 존재합니다: 기본 설정을 그대로 둔 가정용 라우터, 한 번도 잠근 적 없는 기업 DNS 서버, 데이터 센터에서 여전히 조용히 돌아가고 있는 잊혀진 인프라.

리졸버는 도움을 주려 합니다. 질문을 받으면 답변을 보냅니다. 자신의 친절함이 무기로 이용되고 있다는 것을, "질문자"가 거짓이고 "답변"이 무기라는 것을 알 방법이 없습니다.

이러한 분산된 특성 때문에 공격을 원점에서 차단하는 것은 거의 불가능합니다. 차단해야 할 단일 서버도, 연락해야 할 단일 조직도 없습니다. 증폭에 쓰이는 서버들은 전 세계에 흩어져 있고, 수천 개의 서로 다른 주체가 소유하고 있으며, 대부분은 자신이 공격에 가담하고 있다는 사실조차 모릅니다.

DNS가 특히 취약한 이유

UDP가 핵심 문제입니다. TCP는 데이터가 흐르기 전에 핸드셰이크를 요구해서—자신이 주장하는 주소에서 실제로 응답을 받을 수 있음을 증명하게 하지만—UDP는 그냥 보냅니다. 서버는 출발지 주소가 실제인지 확인할 방법이 없습니다.

DNS가 만들어졌을 때는 이것이 합리적이었습니다. 인터넷은 더 작고, 더 신뢰할 수 있었으며, TCP의 오버헤드는 단순한 조회에는 불필요해 보였습니다. 하지만 그 신뢰 모델은 악의적인 행위자 앞에서 살아남지 못합니다.

DNS는 설계상 가용성을 최대화합니다. 리졸버가 어디서든 쿼리에 응답하는 이유는 그것이 시스템을 원활하게 작동시키기 때문입니다. 접근을 제한하려면 명시적인 설정이 필요한데, 많은 운영자들이 그냥 넘어갑니다—혹은 자신의 서버가 외부에 노출되어 있다는 사실을 알지 못합니다.

현대 공격의 규모

2024년 10월, Cloudflare는 5.6 Tbps DDoS 공격을 차단했습니다—당시 역대 최대 규모였습니다. 2025년 중반에는 그 기록이 7.3 Tbps로 경신되었습니다. 1 Tbps를 초과하는 공격이 이제 매일 발생합니다.

이 규모에서는 서버를 공격하는 것이 아닙니다. 회선을 공격하는 것입니다. 피해자의 인터넷 연결 자체가 병목이 되어, 정상적인 요청이 뚫고 들어올 수 없을 만큼 트래픽으로 포화됩니다.

경제적으로는 공격자에게 터무니없이 유리합니다. 수백 달러만 내면 흡수하는 데 수백만 달러가 드는 트래픽을 만들 수 있는 봇넷을 빌릴 수 있습니다. 이런 공격들은 금융 기관, 주요 인터넷 서비스, 핵심 인프라를 마비시켰습니다. 협박, 경쟁자 방해, 국가 차원의 작전에 사용됩니다.

2024년 DNS 증폭은 모든 증폭 공격 트래픽의 55%를 차지했습니다—공격자들이 다른 프로토콜로 다각화하면서 2023년 88%에서 감소했지만, 여전히 지배적인 공격 벡터입니다.

방어 방법

가장 근본적인 방어는 피해자 측이 아니라 출발지에서 이루어집니다. BCP38, 즉 인그레스 필터링이라고도 불리는 이것은 인터넷 서비스 제공업체가 고객으로부터 오는 트래픽이 정당한 출발지 주소를 갖고 있는지 확인하도록 요구합니다. 자신이 소유하지 않은 IP에서 보내는 것처럼 위장하면, ISP가 해당 패킷을 삭제합니다.

모든 ISP가 BCP38을 구현한다면, 증폭 공격은 사실상 사라질 것입니다. 스푸핑된 쿼리가 리졸버에 도달하지 못할 테니까요. 하지만 도입은 여전히 불완전합니다—스푸핑된 트래픽의 통과를 허용하는 네트워크가 너무 많습니다.

리졸버는 응답 속도 제한(RRL)으로 스스로를 방어할 수 있습니다. 서버가 동일한 출발지에서 온 것으로 보이는 동일한 레코드에 대한 수백 건의 쿼리를 감지하면, 응답을 제한합니다. 리졸버가 패턴을 인식하면서 공격자는 효과가 점점 줄어들게 됩니다.

피해자는 흡수와 분산으로 방어합니다. 트래픽 스크러빙 서비스는 공격 트래픽이 대상에 도달하기 전에 걸러냅니다. 애니캐스트 라우팅은 들어오는 트래픽을 여러 지역에 분산시켜 단일 회선이 포화되지 않도록 합니다. 대규모 대역폭 과잉 프로비저닝은 여유분을 제공합니다—하지만 작정한 공격자를 흡수할 만큼 충분한 용량을 경제적으로 구매할 수는 없습니다.

프로토콜 개선도 주변부에서 도움이 됩니다. DNS 쿠키를 통해 리졸버는 응답을 실제로 받을 수 있는 출발지에서 쿼리가 왔는지 확인할 수 있습니다. DNS over HTTPS와 DNS over TLS는 TCP의 연결 요구사항을 도입해 스푸핑을 더 어렵게 만듭니다. 하지만 이러한 변화는 천천히 확산되고 있으며, 레거시 UDP 기반 DNS는 수년간 계속 존재할 것입니다.

조직이 해야 할 일

자체 인프라부터 시작하세요. DNS 서버를 운영한다면, 오픈 리졸버가 아닌지 확인하세요—재귀 쿼리를 인가된 클라이언트에게만 제한하세요. 도메인 레코드를 게시하는 권위 네임서버는 절대로 재귀를 제공해서는 안 됩니다.

네트워크에 이그레스 필터링을 구현하세요. 시스템이 스푸핑된 출발지 주소로 트래픽을 보내지 못하게 하세요. 당신이 표적이 아닐 수 있지만, 모르는 사이에 다른 사람에 대한 공격에 가담할 수 있습니다.

비정상적인 DNS 트래픽 패턴을 모니터링하세요. 특히 낯선 레코드에 대한 쿼리가 갑자기 급증한다면, 인프라가 탐지되거나 무기화되고 있다는 신호일 수 있습니다.

필요하기 전에 ISP 및 DDoS 완화 서비스 제공업체와 관계를 구축하세요. 공격이 시작되면, 확립된 채널과 사전에 협의된 대응 계획이 필요합니다. 처음으로 연락을 취할 시간이 없습니다.

복원력을 위한 DNS 아키텍처를 설계하세요: 애니캐스트 분산, 지리적 이중화, 충분한 용량. 목표는 공격을 막는 것이 아니라—정상적인 트래픽이 계속 흐르는 동안 공격을 견뎌내는 것입니다.

DNS 증폭 공격에 관한 자주 묻는 질문

DNS 서버가 스푸핑된 쿼리를 무시할 수 없는 이유는 무엇인가요?

어떤 쿼리가 스푸핑되었는지 알 수 없습니다. UDP로 전송된 DNS 쿼리는 출발지 주소가 있는 패킷에 불과합니다—서버는 모든 정상적인 쿼리를 느리게 만들 오버헤드를 추가하지 않고서는 발신자가 실제로 그 주소에 존재하는지 확인할 방법이 없습니다. 이것이 BCP38이 중요한 이유입니다: DNS 서버에 도달하기 전에 네트워크 수준에서 스푸핑된 패킷을 차단합니다.

공격자는 어떻게 사용할 오픈 리졸버를 찾나요?

인터넷을 스캔합니다. 도구를 사용해 수백만 개의 IP 주소를 탐색하여 임의의 출발지에서 오는 DNS 쿼리에 응답하는 서버를 찾습니다. 이러한 스캔은 실행하기 쉽고, 결과는 종종 공유되거나 판매됩니다. 언제든지 수십만 개의 오픈 리졸버가 존재합니다.

DNSSEC가 증폭 공격을 막을 수 있나요?

아니요—DNSSEC는 오히려 상황을 악화시킵니다. DNSSEC는 DNS 응답에 암호화 서명을 추가해 응답을 더 크게 만듭니다. 이는 증폭 배율을 높입니다. DNSSEC는 다른 문제(응답의 신뢰성)를 해결하며, 증폭 취약점을 해결하지 않습니다.

증폭과 반사의 차이는 무엇인가요?

반사는 우회 전송입니다—요청하지 않은 피해자에게 응답을 보내는 것. 증폭은 트래픽을 배로 불려내는 것—입력한 것보다 더 많은 트래픽을 끌어내는 것. DNS 증폭 공격은 둘 다 사용합니다: 피해자에게 응답을 반사하고, 쿼리/응답 비대칭을 통해 트래픽 볼륨을 증폭시킵니다.

출처

Esta página foi útil?

😔
🤨
😃