모든 영역에 트렌드가 있듯이 DDoS 공격에도 유행하는 트렌드가 있는데, 가장 최신의 트렌드라면 전통적인 좀비PC를 활용하지 않고 프로토콜의 특성을 악용해, IDC내 서버를 활용하는 amplification(증폭) 공격이라고 할 수 있다.
가장 전통적인 증폭 공격이라면 공격자가 소스IP를 victim의 IP로 위조하여 증폭하려는 네트워크의 broadcast 주소에 icmp request를 요청하면, 이에 대해 broadcast 내 모든 디바이스들이 해당 IP로 icmp echo reply로 응답하는 그러나 지금은 역사속에 사라진 smurf 공격으로 거슬러 올라갈 수 있다.
이후, UDP 기반의 공격으로는 2013년 spamhaus에 대한 300Gbps의 공격으로 이슈화가 된 DNS(53/udp) 증폭 공격을 시작으로 default community string인 public을 사용하는 snmp(161/udp)에 대량의 응답을 요청하는 snmp 증폭 공격이 잠시 유행한 적이 있었고, 최근에는 ntp(123/udp) 증폭 공격이 큰 이슈가 되고 있다.
물론 증폭 공격의 특징은 소스IP를 Victim인 것처럼 위조해야 하므로 소스IP 위조가 가능한 ICMP나 UDP가 활용될 수 밖에 없을 것이다. 여기에서는 최근 이슈가 되고 있는 NTP 증폭 공격에 대해 좀 더 살펴보도록 하자.
<NTP 증폭 공격 원리 Diagram>
데일리시큐 기사 및 여러 기술 문서에서 언급된 바와 같이 문제가 된 ntp의 취약성은 해당 ntp 서버에 최근 ntp질의에 응답을 했던 목록을 보여주는 monlist 기능때문이다.
먼저, ntp.conf 에 아래와 같이 간단한 설정만 한 후 ntp를 가동해 보도록 하자.
--------- ntp.conf ---------
server pool.ntp.org
driftfile /etc/ntp/drift
-----------------------------
이후 아래와 같이 원격에서 ntpdc 명령어를 이용하여 해당 서버에 질의를 해 보도록 하자.
# ntpdc -n -c monlist 192.168.34.85
remote address port local address count m ver code avgint lstint
===============================================================================
10.1.198.173 45579 192.168.34.85 1 7 2 0 0 0
107.22.163.51 123 192.168.34.85 692692147 7 2 0 0 0
59.46.172.253 123 192.168.34.85 34988639 7 2 0 0 0
222.146.205.218 123 192.168.34.85 26669143 7 2 0 0 0
210.173.160.87 123 192.168.34.85 48709 4 4 0 1464 6
173.217.36.243 80 192.168.34.85 274 7 2 0 0 393
173.25.188.13 80 192.168.34.85 9110 7 2 0 0 580
69.138.111.24 3074 192.168.34.85 281 7 2 0 0 580
107.2.112.102 80 192.168.34.85 552 7 2 0 0 806
70.209.7.172 50557 192.168.34.85 136 7 2 0 0 879
68.13.254.149 50557 192.168.34.85 14 7 2 0 1 880
98.110.44.46 80 192.168.34.85 109 7 2 0 0 896
173.35.167.91 80 192.168.34.85 4892 7 2 0 0 1158
50.172.46.211 80 192.168.34.85 65 7 2 0 0 1349
177.106.157.89 80 192.168.34.85 1852 7 2 0 0 1416
151.224.225.219 50557 192.168.34.85 709 7 2 0 1 1486
72.229.135.22 80 192.168.34.85 263 7 2 0 0 1630
37.187.52.240 80 192.168.34.85 3616 7 2 0 0 1728
.............. 중략 ..............
참고] 소스 포트가 123/udp인 것도 있지만 80/udp인 것도 적지 않음을 알 수 있다.
이때의 패킷을 tcpdump로 캡처해 보면 아래와 같다.
12:30:04.830324 IP 10.1.198.173.44948 > 192.168.34.85.123: NTPv2, Reserved, length 192
12:30:04.830337 IP 192.168.34.85.123 > 10.1.198.173.44948: NTPv2, Reserved, length 440
12:30:04.830344 IP 192.168.34.85.123 > 10.1.198.173.44948: NTPv2, Reserved, length 440
12:30:04.830351 IP 192.168.34.85.123 > 10.1.198.173.44948: NTPv2, Reserved, length 440
12:30:04.830367 IP 192.168.34.85.123 > 10.1.198.173.44948: NTPv2, Reserved, length 440
12:30:04.830371 IP 192.168.34.85.123 > 10.1.198.173.44948: NTPv2, Reserved, length 440
12:30:04.830379 IP 192.168.34.85.123 > 10.1.198.173.44948: NTPv2, Reserved, length 440
12:30:04.830387 IP 192.168.34.85.123 > 10.1.198.173.44948: NTPv2, Reserved, length 440
12:30:04.830395 IP 192.168.34.85.123 > 10.1.198.173.44948: NTPv2, Reserved, length 440
12:30:04.830406 IP 192.168.34.85.123 > 10.1.198.173.44948: NTPv2, Reserved, length 440
12:30:04.830412 IP 192.168.34.85.123 > 10.1.198.173.44948: NTPv2, Reserved, length 440
... 이하 중략
여기에서 문제는, ntp의 monlist가 기본적으로 600개의 최근 질의/응답 목록을 보여 주기 때문에 단 몇십~몇백 바이트의 한 질의 패킷에 440byte씩 쪼개어져 결국 약 x20배의 증폭이 되어 4,000 byte 이상의 응답 패킷을 생성하게 된다는 것이다. 그리고, 짧은 시간에 많은 질의를 하게 되면 결국 다음과 같이 한 서버에 수백 Mbps 이상의 공격 트래픽이 유발될 수 있음을 확인할 수 있다.
[ 수백Mbps의 ntp 응답 트래픽이 유발된 예]
사실 이 monlist 기능은 일반적인 ntp 운영시 굳이 필요한 기능이 아니기 때문에 해제하면 되는데, 이 기능을 뺀 최신 버전으로 ntp를 업그레이드 하거나 또는 ntp.conf 에서 아래와 같이 noquery 옵션만 추가해 주면 간단히 해결이 된다.
----------- ntp.conf ----------
restrict default noquery
server pool.ntp.org
driftfile /etc/ntp/drift
---------------------------------
혹자는 ntpd 를 운영시 굳이 서버가 아닌 클라이언트로 사용한다면 123/udp를 listen하지 않아도 되지 않을까 생각할 수 있지만 ntpd의 구조상 서버의 역할이든 클라이언트의 역할이든 반드시 123/udp를 listen하여야 한다. 따라서, ntp 패키지 업데이트도 불가능하고, 이 설정을 추가하는 것도 어렵다면, iptables등의 방화벽등을 통해 123/udp 대한 ACL 설정을 하여 꼭 필요한 소스IP에 대해서만 응답하도록 설정할 수도 있을 것이다. 또는 123/udp를 리슨하는 ntpd 대신 ntpdate 명령어를 cron 을 통해 동기화할 경우 특정 포트를 리슨하지 않기 때문에 ntpd의 대안으로 생각해 볼 수도 있다.
자신이 운영하는 조직 또는 네트워크 대역에서 이에 취약한 ntp 서버가 있는지를 확인하려면 다음의 3가지 방법으로 확인할 수 있다.
1) ntpdc 명령어로 확인해 보는 방법
아래와 같이 질의시 timeout이 나면 정상적인 것이다.
# ntpdc -n -c monlist pool.ntp.org
maths.kaist.ac.kr: timed out, nothing received
***Request timed out
2) nmap 명령어로 확인해 보는 방법
최신 버전의 nmap에서는 nse script를 제공하고 있는데, 이를 활용하여 아래와 같이 질의해 볼 수 있다.
아래 서버의 경우 monlist에 대해 응답하고 있는 것을 알 수 있다.
# nmap -sU -pU:123 -Pn -n --script=ntp-monlist 192.168.34.85
Starting Nmap 6.40 ( http://nmap.org ) at 2014-01-29 12:05 KST
Nmap scan report for 192.168.34.85
Host is up (0.32s latency).
PORT STATE SERVICE
123/udp open ntp
| ntp-monlist:
| Target is synchronised with 210.173.160.87
| Public Servers (1)
| 210.173.160.87
| Other Associations (185)
| 10.1.198.173 (You?) seen 6 times. last tx was unicast v2 mode 7
| 222.146.205.218 seen 26721423 times. last tx was unicast v2 mode 7
| 107.22.163.51 seen 692940790 times. last tx was unicast v2 mode 7
| 59.46.172.253 seen 35057211 times. last tx was unicast v2 mode 7
| 127.0.0.1 seen 2 times. last tx was unicast v2 mode 6
| 173.217.36.243 seen 274 times. last tx was unicast v2 mode 7
| 173.25.188.13 seen 9110 times. last tx was unicast v2 mode 7
| 69.138.111.24 seen 281 times. last tx was unicast v2 mode 7
| 107.2.112.102 seen 552 times. last tx was unicast v2 mode 7
중략...
3) http://openntpproject.org/ 로 확인하는 방법
http://openntpproject.org/ 에서는 특정 IP 를 입력하면 해당 IP 대역(/22이하)에서 오픈되어 있는 ntp 서버 목록을 보여주고 있다. 따라서, 자신이 운영하고 있는 대역에 취약한 ntp서버가 없는지 확인해 보는 것이 좋다.
관련기사: dailysecu.com/news_view.php?article_id=5959
[글. 홍석범 씨디네트웍스 시스템 UNIT 부장 / antihong@gmail.com]
