DNS DDoS 공격이 발생했다

Adapted from Lori MacVittie's "F5 Friday: So That DNS DDoS Thing Happened"

다른 모든 퍼블릭 서비스와 마찬가지로 DNS 역시 취약하다. 이 말은 DNS 자체가 취약성을 가지고 있다는 말이 아니라 이 서비스의 목적과 성격으로 인해 공중에게 공개되고 공중이 접근할 수 있어야 한다는 의미에서 취약하다는 뜻이다. 어떤 디지털 액세스 방법에서든 내 자신과 내 서비스의 위치를 찾아내는 방법을 제공하기 위한 것이 DNS의 존재의미이기 때문에 DNS는 액세스 컨트롤 또는 다른 전통적인 보안 메카니즘 뒤에 숨어있을 수 없다.

따라서 전세계적으로 발생하고 있고 그 피해가 매우 큰 DDoS 공격의 주된 대상으로 DNS가 뉴스에 등장한다고 해서 놀랄만한 일은 아니다.

그렇기는 하지만 이미 널리 보도된 바와 같이 이런 공격에 필요한 기술적 투자가 매우 적은데 반해 그 피해의 크기와 결과는 놀랍기 그지없다. 초당 30Mbps 인터넷 접속 라인을 가진 친구 약 30명만 있으면 이런 공격을 충분히 모방할 수 있다. 많은 수의 프로토콜에 내재된 요청(request) 트래픽 크기 대 응답(response) 트래픽 크기의 불균형으로 인해, 이런 유형의 공격들은 공격하는 측에서는 큰 노력을 들이지 않고도 원하는 결과를 얻을 수 있다는 점을 보안 분야에 어느 정도 종사해온 사람이라면 누구나 알고 있고, DNS 역시 이러한 프로토콜 중 하나이다.

보안 분류학적으로는 이런 공격들을 “증폭 (amplification)” 공격이라 부른다. 이들은 새롭게 등장한 것이 아니고 (신뢰성이 없는 IP를 대신하여 네트워크의 IP 상태 및 에러 정보를 전달해주는 프로토콜인) ICMP (Internet Control Message Protocol)를 이용한 ‘스머프 공격 (Smurf 공격)’이 1990년대에 처음 나타났고, 브로드캐스트 애드레스 (broadcast address)를 이용해 피해를 입혔다. DNS 증폭 역시 질의(query)들은 사이즈가 작고 응답(response)들은 사이즈가 크다는 동일한 전제 때문에 작동한다. ICMP와 DNS 증폭 공격 둘 모두는 UDP를 사용하기 때문에 공격자의 측면에서 보면 매우 효과적인데, UDP에서는 핸드쉐이크 (handshake - 상호간에 수신하는 신호를 하나씩 확인해 가면서 제어를 진행해가는 방법)를 요구하지 않으며, 요청을 하는 IP 주소가 다른 요청을 한 IP 주소와 같은 주소인지를 전혀 확인하지 않기 때문이다. 따라서 TCP처럼 연결지향적인 프로토콜의 경우보다 훨씬 더 적은 노력으로 스푸핑 (spoofing)을 하기에 안성맞춤이다.

이 공격에서 요청 트래픽의 크기와 응답 트래픽의 크기 간에 불균형이 어느 정도 심한지 이해하기 위해, 요청 내용이 “dig ANY ripe.net @ <OpenDNSResolverIP> +edns0=0 +bufsize=4096”였다고 할 경우 이 요청 트래픽의 크기는 불과 36바이트에 지나지 않는데 반해, 보통 이에 대한 응답에 소요되는 트래픽 사이즈는 요청 트래픽의 100배인 3킬로 바이트에 달한다. 미국의 클라우드 서비스 업체인 CloudFare에 대한 DNS DDoS 공격에는 약 30,000 개의 DNS 리졸버가 공격에 이용되어, 각각 2.5Mbps의 트래픽을 공격대상에게 전송했다. 이 공격이 환상적이면서도 다른 공격들과 다른 점은 타켓이 된 서버에게 엄청난 양의 DNS (질의가 아닌) 응답이 전송되었고 이 응답 중 어떤 것도 이 서버가 질의 또는 요청한 적이 없다는 것이다.

문제는 DNS이고, DNS는 누구나 사용할 수 있도록 열려있다는 것이다. 응답을 제한시키는 것은 의도와는 다르게, 표면상으로는, 적법한 클라이언트 리졸버를 막는 것이 되므로 자체적으로 서비스 거부 (DoS)를 초래하는 셈이 되고, 이것은 받아들일 수 없는 방법이다. 핸드쉐이킹의 이점을 이용해서 공격시도를 감지하고 막아내기 위해 요청/질의들을 TCP로 전환하는 것도 물론 한 방법이 되겠지만, 이 경우 심각한 성능저하를 감수해야만 한다. F5의 BIG-IP DNS 솔루션들은 이런 반대급부가 발생하지 않도록 최적화되어 있지만, 대부분의 DNS 인프라는 그렇지 못하고 따라서 많은 이용자들이 이미 ‘너무 느리다’고 인식하고 있는 과정을 더욱 느리게 만들 것이며, 특히 모바일 디바이스를 통해 인터넷을 검색하는 사용자들에게는 더 그렇게 느껴질 것이다.

따라서 우리는 UDP를 사용하지 않을 수 없고, 이로 인해 당연히 공격을 받게 된다. 하지만 그렇다고 그냥 주저앉아 당해야 한다는 말은 아니다. 이런 유형의 공격에서 자신을 방어하고 아직까지는 어둠 속에 숨어 있는 또 다른 형태의 공격에서도 우리를 방어할 수 있는 방법이 있다.

1. 유효하지 않은 질의 요청들을 퇴출시킨다 (그리고 응답들도 검사한다)

클라이언트가 보내는 질의들이 DNS 서버들이 답을 하고 싶고 할 수 있는 질의들임을 검증하는 것이 중요하다. DNS 방화벽이나 기타 보안 제품들을 사용해서, DNS 질의들을 검증하고 DNS 서버가 응답하도록 구성된 DNS 질의들에만 응답을 하도록 만들 수 있다. 끊임없이 진화하는 인터넷의 속성으로 인해 현재는 사용되지 않는 수많은 특징들이 DNS 프로토콜이 디자인 되었을 당시에 이 프로토콜에 포함되었다. 여기에는 다양한 DNS 질의 형태들, 플래그들, 그리고 기타 세팅들이 포함된다. DNS 요청에 어떤 종류의 파라미터들이 표시될 수 있고, 이것들이 어떻게 조작될 수 있는지 알게 된다면 놀랄 것이다. 한 예로, DNS type 17=RP는 이 레코드에 대한 책임이 있는 사람을 말한다. 또한 이런 필드들 중 많은 것에 악성 데이터를 넣어서 DNS 커뮤니케이션을 망가뜨리는 방법들이 있다. DNS 방화벽은 이런 DNS 질의들을 검사해서 DNS 표준을 준수하지 않는 요청들과 DNS 서버가 대응하도록 구성되지 않은 요청들을 제외시킬 수 있다.

하지만 위에서 예로 들은 공격에서 증명되었듯이 주의해서 지켜봐야 할 것이 질의만은 아니고, 응답에도 주의를 기울여야 한다. F5의 DNS 방화벽은 응답들에 대해 스테이트풀 인스펙션 (stateful inspection – 상태 기반 검사) 기능이 포함되어 있는데, 이것은 요청하지 않은 DNS 응답들은 즉각적으로 버려짐을 의미한다. 이 기능이 대역폭에 오는 부하를 줄여주지는 못하겠지만, 서버들이 불필요한 응답들을 처리하느라고 허덕거리는 것은 방지해준다.

F5’s DNS Services includes industry-leading DNS Firewall services

2. 충분한 용량을 확보한다

탄력적이고 항상 가용한 DNS 인프라를 유지하는 데는 DNS 질의를 처리할 수 있는 용량에 대한 고려가 필수적이다. 대부분의 조직들은 이 점을 잘 인식하고 있으며, DNS의 가용성과 확장성을 확보하는 솔루션들을 채택하고 있다. 종종 이런 솔루션들은 단지 DNS 로드밸런싱 솔루션들을 캐시하는 것일 뿐인데, 이 역시 무작위의 알 수 없는 호스트 이름을 사용한 공격에 대한 취약성을 비롯해 위험성을 내포하고 있다. DNS 캐시 솔루션은 오직 권한이 있는 소스로부터 돌아오는 응답들만 캐시할 뿐이기에 호스트 네임이 알려지지 않은 응답들의 경우에는 응답을 보낸 서버에 질의해야 한다. 질의의 갯수가 엄청날 경우에는, DNS 캐시 용량에 상관 없이 응답을 보낸 서버에 과부하가 걸리게 된다.

 (F5 BIG-IP 글로벌 트래픽 매니저의 한 부분인) F5 DNS Express와 같은 고성능의, 권위 있는, 인-메모리 (in-memory) DNS 서버는 트래픽을 보낸 출처 서버에 과부하가 걸리는 것을 방지한다.

3. 하이재킹 (HIJACKING)에 대한 방어

하이재킹과 유해 데이터 삽입에 대한 DNS의 취약성은 매우 실제적이다. 2008년에 Evgeniy Polyakov라는 연구자는 패치가 되어 10 시간이 채 지나지 않은 코드를 실행하는 DNS 서버에 유해 데이터를 삽입하는 것이 가능함을 증명했다. 이것은 DNS의 유효성과 건전성에 궁극적으로 의존하는 오늘날의 인터넷 중심 세상에서는 절대로 용납될 수 없는 것이다. 이런 취약점과 DNS 정보의 건전성을 해치는 다른 취약점들에 대한 최선의 솔루션은 DNSSEC이다. DNSSEC는 DNS 프로토콜이 처음부터 가지고 있던 개방적이고 신뢰받아야 하는 성질을 특별히 교정하기 위해 도입되었다. DNS 답이 훼손되지 않았고 이 응답이 신뢰할 수 있는 DNS 서버로부터 온 것임을 증명할 수 있는 키를 이용해 DNS 질의와 응답들에 서명이 이루어진다.

F5의 BIG-IP 글로벌 트래픽 매니저(F5 BIG-IP Global Traffic Manager - GTM)는 DNSSEC를 지원할 뿐 아니라, 글로벌 서버 로드밸런싱 테크닉들을 위배하지 않으면서 이 작업을 수행한다.

의도하지 않은 상태에서 자신도 모르는 사이 오픈 리졸버를 가동하지 않도록 확실히 하는 것이 일반적인 법칙이다. 결론은 ICSA 인증을 취득했고, 오픈 리졸버로 작동하지 않는 더 강력한 솔루션을 이용해 DNS를 구현해야 한다는 것이며, 이를 위해서는 F5가 최고의 선택이라는 것이다.