방송사 및 은행권 전산망 장애로 시끄러웠던 지난 3월 20일을 전후로 해외에서는 spamhaus.org에 대한 대규모 DDoS 공격이 큰 이슈가 되었다. 뉴욕타임즈 등 뉴스에 보도된 바에 따르면, spamhaus측에서 cyberbunker라는 호스팅업체를 스패머로 등록하면서cyberbunker측에서 발송하는 메일이 스팸으로 분류되자, 업체는 보복성 공격을 하기 시작하였는데, 3월 18일 10Gbps로부터 시작해 3월 22일에는 100Gbps가 넘는 대규모 공격이 발생하였다고 밝혔다. 일부에서는 공격양이 300Gbps에 이르러 일부 다른 서비스에 영향이 있었다고 알려져 있지만 정확히 확인된 바는 없으며 공식적으로는 최대 120Gbps로 알려져 있다.
한편, cyberbunker의 대변인은 방송과의 인터뷰를 통해 금번 공격은 자신의 회사에서 이루어진 것이 아니며 그 동안 spamhaus의 독단적인 정책에 항의하는 stophaus.com의 멤버들이 공격한 것이라고 주장하였다.
금번 공격과 관련, 대응을 한 CDN업체인 Cloudflare는 anycast 기반으로 공격 트래픽을 분산함으로써 대규모의 트래픽을 대응할 수 있었다고 언급하며 자세한 공격 방식을 언급하였다. 이번 공격은 Distributed Amplified(분산증폭) DNS 공격으로, 지난 2012년 3월 Anonymous가 root DNS에 대한 공격을 통해 전세계 인터넷을 마비시키겠다고 공언했던 방식과 동일한 공격 형태이다.
관련 기사 참고 :: http://www.dailysecu.com/news_view.php?article_id=1752
Distributed Amplified(분산증폭) DNS 공격의 원리
공격 방식은 아주 간단하였다. 공격자들은 spamhaus.org의 서버 IP 주소를 소스로 spoofing 하여 전세계 resolving 이 허용된 DNS 서버로 아래의 질의를 수행하였다.
$ dig @x.x.x.x ripe.net any edns=0 +bufsize=4096
;; Query time: 23 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Thu Mar 28 21:10:23 2013
;; MSG SIZE rcvd: 2758
여기에서 x.x.x.x는 8.8.8.8과 같은 resolving이 허용된 DNS 서버를 의미한다. 그렇게 되면, 질의를 받은 DNS 서버는 ripe.net DNS로부터 응답 패킷을 받고, 이를 요청했던 소스ip로 응답 패킷을 전달하게 되는데, 여기에서 소스ip는 spamhaus.org의 서버 IP로 위조되었으므로 모든 응답 패킷은 결국 spamhaus.org 서버로 전송하게 되는 것이다. 또한 edns0는 원래 udp DNS 패킷 제한크기(RFC 1035)인 512byte(8진수)보다 큰 패킷 전송을 이용할 수 있도록 하는 것으로 RFC2671에 정의되어 있다.
위에서 보는 바와 같이 약 30byte의 요청에 약 3,000byte의 응답패킷이 생성되었으므로 약 100배 가까운 증폭(amplification) 이 발생한 것을 알 수 있는데, 금번 공격에 악용된 Open resolving DNS 서버는 역 3만여개인 것으로 알려져 있다. 현재 전세계에 Open Resolving DNS는 약 15만여개 인 것으로 알려져 있으니 극단적으로 이번 공격보다 5배 이상의 공격도 가능하다는 계산이 된다.
Distributed Amplified(분산증폭) DNS 공격이 발생하지 않도록 하려면?
이러한 형태의 공격이 발생하지 않도록 하려면, 두가지가 진행되어야 한다.
첫째, 공격자는 victim의 IP인 것처럼 소스IP를 위조(spoofing)하여 질의를 수행하는 것이므로 네트워크망 사업자/관리자는 uRPF등 egress filtering 을 통해 위조된 IP가 외부 네트워크로 전달되지 않도록 하여야 한다.
두번째, DNS 서버 관리자는 꼭 필요하지 않다면 아래와 같이 recursion을 차단하거나 최소한 특정 IP 대역에서만 서비스되도록 제한 설정하여야 한다.
options {
recursion no;
};
이외 이러한 분산증폭 DNS공격을 받을 경우, 공격 트래픽의 소스 port는 53/udp 이므로 백본에서 ACL을 이용하여 이러한 종류의 트래픽을 차단하는 것도 효율적인 대응방안이 될 수 있을 것이다. 또한 금번 대응과 같이 anycast 또는 CDN등을 통해 분산대응하는 것도 효율적인 방안이 될 수 있을 것이다.
[글. 씨디네트웍스 홍석범 부장 / antihong@gmail.com]
