벤더 기고 | 신종 DDoS 기법 ‘넌센스 네임’ 공격 대처법

네임 서버(Name Server)를 대상으로 하는 새로운 종류의 DDoS(Distributed Denial of Service) 공격이 등장했다. 명칭은 "넌센스 네임(Nonsense Name)" 공격이라고 부를 만한 것이다. 인포블록스(Infoblox)의 일부 고객들이 피해를 입기는 했지만, 언제나 그렇듯 그들이 실제로 공격 대상이었는지 여부는 불확실하다.

"넌센스 네임" DDoS 공격은 이렇게 이뤄진다.

- 공격자가 공격 구역(Zone)을 선택한다. 예를 들어 foo.example 이라고 하자.

- 공격자가 제어하는 봇넷(Botnet)이 해당 구역에서 asdfghjk.foo.example 및 zxcvbnm.foo.example 등 터무니 없는 라벨이 적용된 무작위 도메인명(Domain Name)을 생성한다.

- 봇은 이런 도메인명에 대하여 반복 네임 서버로 무수히 많은 쿼리를 전송한다.

- 그 결과, 반복 네임 서버는 해당 도메인명에 해당하는 foo.example 의 권한 네임 서버(authoritative name server)로 쿼리를 전송한다.

- 권한 네임 서버는 요청한 도메인명이 존재하지 않는다는 응답을 전송한다 (DNS 업계에서는 이를 NSDOMAIN 응답이라 부른다).

- 반복 네임 서버(recursive name servers)는 해당 응답을 오리지널 쿼리 전송자와 연계시키고 도메인명 부재를 캐시(Cache) 처리한다.

- 이런 작업이 반복된다.

공격자가 충분히 빠른 속도로 쿼리를 생성할 수 있다면 전체 쿼리 속도가 foo.example 네임 서버를 능가하게 된다. 이 때, 재미있는 일이 일어난다:

- 봇은 생성된 도메인명에 대하여 반복 네임 서버로 계속해서 쿼리를 전송한다.

- 권한 네임 서버가 응답을 멈추면서 반복 네임 서버가 각 쿼리를 처리하는데 더 오랜 시간이 소요된다. BIND 네임 서버의 경우, 네임 서버는 포기하기 전에 30 초 동안 기다렸다가 (응답하지 않은) 수십 개의 쿼리를 전송할 수 있다.

- 이 때문에 반복 네임 서버의 반복 쿼리 슬롯이 꽉 차게 되고 추가적인 반복 쿼리를 거부하게 되어, 결국 멀쩡한 쿼리도 거부하게 된다.

이렇게 되면, BIND 네임 서버는 다음과 같은 메시지를 syslog 로 전송한다:

Jan 21 14:44:00 ns1 named[4242]: client 192.168.0.1#1110: no more recursive clients: quota reached

이 때, 네임 서버는 추가적인 반복 쿼리를 거부하여 클라이언트에 대한 서비스를 거부하게 된다.

대상은 누구일까?
대부분의 경우에 권한 네임 서버(본 예에서는 foo.example)를 운용하는 조직이 대상이 될 것으로 보인다. 예를 들어, 공격에서 우리가 목격한 일부 도메인명은 중국 도박 사이트에서 사용하고 있었다. (누군가 돈을 크게 잃은 사람이 복수를 하려고 했던 것일까?)

하지만 관련된 반복 네임 서버도 공격 중 부수적인 피해를 입게 된다. 그것들도 대상이었다고 볼 수 있을까?

우리는 몇 가지 증거를 발견했다. 고객들에 대한 공격에 관련된 구역 중 일부가 공격 후 1 - 2일 만에 알 수 없는 이유로 사라졌으며, 이는 실제로 이것들을 사용하지 않고 있었다는 증거로 볼 수 있다 (사실 아마도 "도메인 시험(Domain Testing)" 시스템에 등록되어 있었을 것이다).

공격자는 의도적으로 이런 구역을 느리거나 응답이 없는 네임 서버로 등록하여 해당 구역에서 도메인명 해결에 가능한 오랜 시간이 소요되도록 할 수 있었다.

물론, 대상에 상관 없이 공격 이면의 메커니즘은 동일하다.

완화법
일반적으로 앞서 syslog 메시지에서 확인했듯이 반복 네임 서버에서 반복 쿼리 슬롯이 부족하기 시작하면 넌센스 네임 공격을 알아차리게 된다. 이런 메시지를 통해 슬롯 부족으로 인해 접속이 거부된 쿼리의 IP 주소를 알 수 있다.

우선, 해당 메시지의 IP 주소가 네임 서버에서 처리해야 하는 주소인지 확인해야 한다. 그렇지 않은 경우, 네임 서버에 간단히 접속 관리 목록을 구성하여 쿼리를 승인된 쿼리로 한정할 수 있다. 악성 쿼리가 정상 IP 주소로부터 유입된다면 분명 다른 메커니즘을 이용해야 한다.

일단, BIND 의 편리한 RPZ(Response Policy Zones) 기능을 이용해 네임 서버가 해당 문제 구역을 위한 쿼리를 전송하지 않도록 임시 조치를 취할 수 있다. 네임 서버가 foo.example 도메인명을 찾지 않도록 하는 RPZ 규칙이 가장 단순한 해결책이 될 수 있다:


또한 qname-wait-recurse 라는 옵션을 no로 설정해야 하나 (이 옵션에 대한 자세한 설명은 여기를 클릭한다). 그러면 네임 서버가 foo.example 네임 서버를 쿼리 처리하지 않고 foo.example 에서 NXDOMAIN 이 있는 도메인명에 대한 쿼리에만 응답하게 된다.

반복 네임 서버에 아직 BIND 9.10(해당 옵션을 지원하는 최초의 BIND 버전) 이 적용되지 않았거나 BIND를 전혀 운용하지 않는다면 빈 foo.example 구역을 임시로 구성하여 네임 서버가 잘못된 네임 서버에서 데이터를 찾지 않도록 할 수 있다. 구역 데이터 파일은 최소화될 수 있다:

@ IN SOA ns1 root 2015010700 1h 15m 30d 10m

IN NS ns1

해당 구역에서 반복 네임 서버에 권한을 설정하라. 그러면 foo.example 도메인명에 대한 대부분의 쿼리에 NXDOMAIN 으로 응답하게 된다 (foo.example 의 SOA 또는 NS 기록에 대한 쿼리 제외).

RPZ 규칙 또는 구역 설정은 임시조치라는 사실을 기억해야 한다. 공격이 끝난 후, 이것들을 제거하여 해당 구역 내에서 도메인을 다시 해결할 수 있어야 한다.

BIND 네임 서버를 개발한 ISC(Internet Systems Consortium)에서도 fetches-per-server 와 fetches-per-zone 등 2 가지 새로운 설정 옵션을 도입하여 이 문제를 더욱 예리하게 해결할 수 있는 새로운 메커니즘을 개발하고 있다.

Fetches-per-server 는 단일 권한 네임 서버에 대하여 반복 네임 서버가 가질 수 있는 동시 쿼리의 수를 제한한다. 부여된 한계는 실제로 동적이며 권한 네임 서버를 쿼리 처리할 때 경험한 타임아웃(Timeout)에 기초하여 하향 조정된다. Fetches-per-zone은 단일 구역에 대하여 반복 네임 서버가 가질 수 있는 동시 쿼리의 수를 제한한다.

이 두 기능을 이용해 관리자는 BIND 네임 서버가 우연이든 아니든 넌센스 네임 DDoS 공격에 피해를 입을 가능성을 낮출 수 있을 것이다.

* Cricket Liu 는 인포블록스 최고 인프라스트럭처 책임자다. ciokr@idg.co.kr