[IT 알아보기]/보안 이슈

최신 DDoS 공격 트렌트가 된 NTP 증폭 공격

이호스트ICT 2014. 5. 9. 13:51

운영 조직내, 취약한 NTP 서버가 있는지 확인하기 위한 3가지 방안

 

모든 영역에 트렌드가 있듯이 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서버가 없는지 확인해 보는 것이 좋다.

 

출처: 데일리시큐