미국의 DDoS 대응 서비스 업체인 prolexic은 지난 5월 30일 한 금융회사의 서비스 플랫폼에 167Gbps의 DDoS공격이 발생해 대응했다고 밝혔다. 이는, 지난 3월 19일 spamhaus에 대한 120Gbps에 대한 공격 이후 공격의 규모가 점점 커지고 있다는 것을 보여주는 것이며 특히 두 공격 모두 리졸빙(resolving) 이 허용된 DNS 서버를 활용한 이른바 DNS reflection(증폭) DDoS 공격(DrDos)이라는 것에 주목할 필요가 있다.
공격자 입장에서 이러한 공격은 아래와 같은 여러가지 장점이 있어 지속적으로 악용될 것으로 생각되므로 철저하게 준비하여야 할 필요가 있을 것이다. 이에 FAQ 형식으로 이러한 공격에 대해 살펴보도록 하자.
-왜 DNS DrDOS 공격이 위험한가?
1) 공격이 매우 쉽다. 단지 한 줄의 dig 명령어만으로도 바로 공격이 가능하기 때문이다.
2) 즉시 공격할 수 있다. 굳이 힘들게 좀비를 만들 필요가 없다. 인터넷상에 공개되어 있는 Open된 resolving DNS가 즉시 사용 가능한 고성능 좀비가 되기 때문이다.
3) 공격IP를 위조할 수 있다. 공격이 성공하기 위해서는 공격IP를 victim의 IP로 설정하여야 하기 때문에 공격자의 IP를 노출하지 않아도 된다.
4) 공격이 효율적이다. 패킷 1개로 100배의 증폭을 할 수 있고, 최대 수백Gbps의 공격 트래픽을 생성할 수 있으므로 공격자 입장에서 매우 효율적이다.
-실제 공격의 타깃은 DNS가 대상인가?
spamhaus의 경우 DNS 서버에 대한 공격이었지만, 공격의 타겟(victim)은 DNS일 수도 있고 웹서버 또는 특정 서비스등 다양할 수 있다.
만약 victim의 대상이 UDP 서비스가 아니라면 상위ISP의 도움을 받아 ACL로 차단할 수 있겠지만, 스트리밍 서비스나 DNS와 같이 UDP서비스라면 ACL로 대응에 어려움이 있을 수 있다.
-만약의 DrDOS 공격이 발생하면 기술적으로 어떻게 방어하여야 하는가?
기본적으로 DNS는 UDP를 사용하므로 이 형태의 공격 역시 UDP 트래픽이다. 따라서, http와 같이 웹서비스라면 상단에서 ACL로 UDP를 차단해도 당장 도움이 될 수 있다.
그러나 DNS와 같이 UDP 서비스를 하고 있다면 protocol 기반의 ACL을 적용할 수 없는 문제가 있다. 따라서 이러한 경우, 다음의 방법을 활용할 수 있다.
1) 포트기반의 ACL로 차단적용
대응의 입장에서는, 공격 트래픽이 DNS 서버에서의 응답패킷이므로 소스포트는 53, 목적지 포트는 53 또는 1024 이후의 랜덤포트가 된다. 따라서, 소스포트가 53/udp인 inbound 트래픽을 차단하는 ACL을 적용하면 대응할 수 있을 것이다.
2) 공격IP는 resolving이 허용된 DNS 서버에서 지속적인 공격 트래픽이 유발되므로 ratelimit를 적용하여, 한 소스IP에서의 inbound 트래픽을 제한하도록 한다.
3) 수십~수백Gbps의 충분한 대역폭이 없다면 KISA의 대피소 서비스를 활용하거나 Anycast등의 대응이 가능한 Cloud 기반의 서비스를 이용할 수 있다.
-공격의 도구로 활용되고 있는 리졸빙이 허용된 DNS서버는 어느정도 있는가?
정확한 숫자는 알 수 없다. 다만 지난 3월 spamhaus에대한 120Gbps의 공격에 활용된 DNS서버의 수는 3만여개인 것으로 알려져 있다.
일부 프로젝트에서는 15만개인 것으로 밝히고 있지만 아래의 프로젝트에 따르면 실제 그 숫자는 훨씬 많은 것임을 짐작할 수 있다.
물리적으로는 1대이지만, 여러 IP를 alias로사용하는 경우도 있을 수 있으므로 실제 서버 숫자는 이 보다는 다소 적겠지만 매우 많은 수의 open된 리졸빙 서버가 있다는 것을 알 수 있다.
http://openresolverproject.org/breakdown.html
-이러한 공격을 줄이기 위해 대응 진영에서는 어떠한 움직임이 있는가?
http://openresolverproject.org/ 가 가장 대표적인 움직임이라고 할 수 있다. 이 프로젝트를 통해 공격의 증폭 용도로 사용되고 있는 open된 리졸빙 DNS서버 정보를 각 ISP나 네트워크의 담당자에게 알려주어 fix 하도록 하고 있다.
각 네트워크 담당자는 아래의 주소를 통해 해당 AS 주소(XXXX)내에 어떤 서버들이 resolving 이 허용되어 있는지 확인할 수 있다.
http://openresolverproject.org/searchby-asn.cgi?search_asn=XXXX
또한 위조된 IP문제를 해결하기 위해 udp 질의시에 tcp로 재전송하도록 하여 정상적인 질의만 처리하도록 하는 패치가 공유되고 있지만, 실제 적용에 어려움이 있는 것이 현실이다.
만약 개별 서버에 대한 open 리졸빙 여부를 확인하려면, 다음과 같이 nmap으로 간단히 체크할 수도 있는데 아래 서버의 경우 리졸빙이 허용(open)된 것을 알 수 있다.
# wget https://svn.nmap.org/nmap/scripts/dns-recursion.nse
# nmap -sU -p 53 -sV -P0 --script "dns-recursion" xx.xxx.xx.xx
Starting Nmap 5.21 ( http://nmap.org ) at 2013-06-02 19:05 KST
NSE: Script Scanning completed.
Nmap scan report for xxx.xxx.xx.xxx (xx.xxx.xx.xx)
Host is up (0.00019s latency).
PORT STATE SERVICE VERSION
53/udp open domain ISC BIND (Fake version: 9.3.6-P1-RedHat-9.3.6-4.P1.el5)
|_dns-recursion: Recursion appears to be enabled
-공격자의 입장에서 이러한 형태의 증폭 공격은 DNS뿐 아니라 다른 프로토콜이나 다른 서비스를 활용할 수도 있는가?
물론이다. 가장 대표적인 것이 증폭 공격의 원조라 할 수 있는 ICMP 기반의 스머프(smurf) 공격이다. 이 공격은 Broadcast 주소로 icmp request 패킷을 보내면 해당 네트워크내에 있는 모든 장비들이 해당 소스IP로 icmp 응답패킷을 보내는것인데, 최근에는 대부분의 네트워크에서 directed broadcast에 대해 응답하지 않으므로 이 공격은 더 이상 유효한 공격이 아니다.tcp의 경우 3 way handshake를 통해 소스 IP 검증을 하게 되므로 현실적으로 공격이 성공하기 어렵다. udp의 경우 DNS외에 snmp 및 ntp 증폭 공격이 악용될 수 있는 가능성이 있다고 할 수 있다.
즉 같은 원리로 소스IP를 victim IP로 위조하여 특정 서버나 장비에 snmp나 ntp 질의를 하여 해당 소스IP로 응답패킷이 전달되도록 하는 것으로 역시 수십 byte의 요청 패킷으로 수백 byte의 응답 패킷을 생성할 수 있다. 그러나, DNS와 달리 ACL이 걸려있거나 인증으로 제한된 경우가 많아 공격 성공율 측면에서는 다소 비효율적이라고 할 수 있다.
[글. 홍석범 씨디네트웍스 시스템팀 팀장 / antihong@gmail.com]
