Выбрать язык


Выбрать язык | Show only


Русский | English


вторник, 27 декабря 2016 г.

Protect You and Others from DDoS. Make Your Network "Cleaner" Part 2. NTP Amplification


This article was published in the June 2016 issue of the "System Administrator" journal (Russian). Original text is also available in Russian.


If you want to make a contribution to the wold-wide cyberspace security and DDoS-protection it is not necessary to buy expensive equipment or service. Any Internet-faced server admin may participate in such a noble action with no additional money but time and knowledge investment only.

In the previous article DNS protocol and it's usage in DDoS were examined. Let's continue to analyze attacks type "amplification".

NTP amplification
NTP response size must be much more that the request's one to make an ability to use a server for DDoS-attacks. NTP is UDP-based protocol as DNS one, so IP spoofing is a root cause but unlike DNS, NTP amlification is possible because of ntpd service vulnerability. Only REQ_MON_GETLIST and  REQ_MON_GETLIST_1 requests cause such an effect. They were designed for NTP clients accounting by server administrator. According to CVE-2013-5211 this feature was recognized as a bug with known vulnerability fix in the ntpd version 4.2.7p26 and later. In spite of more than 2 years after fix publication there are lot of IP addresses in the Internet with vulnerable ntpd server.
How to check if your NTP-server is vulnerable for such an attack?
Type the command in Unix CLI:

# ntpd –version

If your server is out of date, it is vulnerable and shows the version:

ntpd 4.2.6p5

Control check for responses to MON_GETLIST or MON_GETLIST_1 requests is done by command:

ntpdc -c monlist <server-address>

typed on the server or in client CLI.
The vulnerable ntpd responses with similar output:

remote address          port local address      count m ver rstr avgint  lstint
===============================================================================
xx.xxx.12.217            123 192.168.10.128         6 4 4    1d0      9      44
xx.xxx.132.250           123 192.168.10.128         6 4 4    1d0      9      45
xxxx.yyyyy.ru            123 192.168.10.128         6 4 4    1d0      9      46
xx.xxx.205.75            123 192.168.10.128         6 4 4    1d0      9      47
xxxx.xxxxxxxx.ru         123 192.168.10.128         1 4 4    1d0     51      51
xxxx.yyyyyyyy.ru         123 192.168.10.128         1 4 4    1d0     52      52
xxxx.zzzzzzzz.ru         123 192.168.10.128         1 4 4    1d0     53      53
<skipped>

And if you run tcpdump you can see that it is enough only one UDP-packet (spoofing is possible) to receive a large response:

13:31:13.403225 IP 192.168.10.129.38131 > 192.168.10.128.ntp: NTPv2, Reserved, length 192
13:31:13.440938 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.441190 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.441624 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.441894 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.443563 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.443952 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.444270 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.444621 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.444894 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.445510 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.446094 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.446267 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.446861 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.447352 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440
13:31:13.447620 IP 192.168.10.128.ntp > 192.168.10.129.38131: NTPv2, Reserved, length 440

Let's try to calculate amplification factor for such an attack with the packets' quantity described above. 
Tcpdump shows only payload bytes, so add 42 header bytes to each packet (request and response):
14 - Ethernet;
20 - IP
8 - UDP.

One can see that one request with 

192+42=234bytes

vulnerable server responses with 15 packets with

440+42=482 bytes

so the total volume is

482х15=7230bytes

So, the amplification factor is:

7230/234 = 30,9

Let's analyze a response packet on Pic.1 



Pic. 1. NTP-response.

It is clear that each response with 482 bytes size contains 6 addresses from the monlist list. 
The command

ntpdc -c monlist <server-address>

may return up to 600 addresses. The math says that NTP-server may return up to 100 482-bytes responses for one 234-bytes request. So, amplification factor may reach:

482х100/234=206

It is easy to calculate how many requests must generate somebody with a victim spoofed address to make an attack with 1 Gbps speed. 
In the first we must convert bytes to bits:
234 bytes (request) = 234х8 = 1872 bits;
482 bytes (response) = 482х8 = 3856 bits;
1 gigabit = 1024х1024х1024 = 1 073 741 824bits

To flood 1 Gbps attacker needs to generate:
1 073 741 824 / 3 856 = 278 460 pps

One vulnerable server may return up to 100 responses for 1 request, so attacker must provide:
278 460 / 100 = 2784,6

spoofed requests per second. It is not very much in the Internet scale.

So, attacker must use such techniques for NTP Amp DDoS:
  • IP-address spoofing with change to victim one.
  • Search and actualize vulnerable NTP-servers list.
  • MONLIST requests generation.
  • High requests rate from zombie-PCs.

How to protect NTP-server?

Unix

ntpd.conf
The most right way to eliminate DDoS-usage of your server is ntpd upgrade to version 4.2.7p26 or later. But if it is not possible in your case you may disable REQ_MON_GETLIST and  REQ_MON_GETLIST_1 processing with one line in the config file:

disable monitor

with ntpd restart. Then NTP-server will reply for such requests with answer:

:~$ ntpdc -c monlist 192.168.10.128
***Server reports data not found

NTP is not unused service because it synchronizes system time with external servers and its' removing may affect another services functioning. So if you want to protect ntpd you must add to the config file strings:

# If NTP-server serves clients' requests - allow time request but not change.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

# Trusted IP-addresses
restrict 127.0.0.1
restrict 192.51.100.1
restrict 192.51.100.2
restrict 192.51.100.3

IPv6
If you don't use IPv6 it must be disabled with string in /etc/sysctl.conf:

net.ipv6.conf.all.disable_ipv6 = 1
and type the command:

sudo sysctl -p /etc/sysctl.conf

iptables

As a case with DNS you may filter with iptables NTP-requests containing MON_GETLIST or MON_GETLIST_1. Pic.2 shows such packet dump.



Рис. 2. "Malicious" NTP-request packet dump.

One can see that byte №45 contains hexadecimal sequence 0x2a. It identifies NTP-request with MON_GETLIST_1 command.

Let's compose iptables commands set to:
- permit NTP-requests sourced from 192.0.2.0/24

iptables -v -A INPUT -s 192.0.2.0/24 -m state --state NEW -p udp --dport 123 -j ACCEPT

- have an ability to synchronize with upstream NTP-servers 192.51.100.1-3

iptables -v -A OUTPUT -m iprange --dst-range 192.51.100.1-192.51.100.3 -m state --state NEW -p udp --dport 123 -j ACCEPT

- block all requests to the server with MON_GETLIST_1

iptables -v -A INPUT -p udp --dport 123 -m string --from 44 --to 46 --algo bm --hex-string '|2A|' -j DROP

Cisco

Vulnerability affects Cisco devices too. So let's analyze how to protect networks devices from usage in DDoS-attacks NTP amplification.
Cisco Systems affected products list according to CVE-2013-5211 is shown in [1]. So let's try to describe vendor recommended points for device diagnostics and hardening [2].
Based on Cisco information it's IOS versions starting from 12.4(15)XZ, 12.4(20)MR, 12.4(20)T, 12.4(20)YA, 12.4(22)GC1, 12.4(22)MD, 12.4(22)YB, 12.4(22)YD, 12.4(22)YE and 15.0(1)M in each branch are not vulnerable because of NTPv4 usage.
NTP version may be checked with command:

ios_router# show subsys name ntp

Non-vulnerable version will show:

Name                               Class       Version
ntp                                Protocol    4.000.000

But even if software is not vulnerable it is wise to protect it additionally because even Cisco Systems points that you may reach 100% defense in the case of NTP disable only.
So you need to configure your Cisco IOS device.
Create blocking ACL.

ios_router(config)# ip access-list standard DENY
ios_router(config-std-nacl)# deny any

Apply it in th edirection to the device as NTP-server:

ios_router(config)#ntp access-group query-only DENY
ios_router(config)#ntp access-group serve DENY

If your router acts as NTP-server for legal clients from the network 192.0.2.0/24 your ACL will look like:

ios_router(config)#ip access-list standard PERMIT_NTP_CLIENTS
ios_router(config-std-nacl)#permit 192.0.2.0 0.0.0.255
ios_router(config-std-nacl)#deny any

and your Cisco device will be used for time sync for clients only:

ios_router(config)#ntp access-group serve-only PERMIT_NTP_CLIENTS

You may permit NTP-requests from your device to upstream NTP-servers adding them to trusted list:

ios_router(config-std-nacl)#permit 198.51.100.1
ios_router(config-std-nacl)#permit 198.51.100.2
ios_router(config-std-nacl)#permit 198.51.100.3
ios_router(config-std-nacl)#deny any

and then apply it with command:

ios_router(config)#ntp access-group peer PERMIT_NTP_PEER

So Cisco router will be protected from illegal requests, it will also have an ability to synchronize with upper server and act as NTP-server for clients.

uRPF-check

According to BCP38 and RFC2827 recommendations for IP spoofing prevention your router's edge L3-interface terminating clients' subnet must be configured for source address verification with route table:

CE(config-if)# ip verify unicast source reachable-via rx

Conclusion

The article describes settings which doesn't protect your infrastructure in the case of DDoS directly but they make it impossible to use your resources for DDoS attacks to other networks.
So, one can decrease quantity of DDoS-attacks type amplification and eliminate his infrastructure participation in such malicious activity with some actions which doesn't need additional money: 
  • NTP-server upgrade to version 4.2.7p26 or later
  • IPv6 and another unused services disable 
  • Patch management.
    Vulnerabilities management
  • NTPD secure configuration to restrict MON_GETLIST and MON_GETLIST_1 requests processing
  • Iptables rules usage to filter NTP-packets with 0x2a value in byte 45
  • uRPF-checks usage on the network edge
If each Internet-faced service admin and network engineer apply all the recommendations the digital world become cleaner.


1.      Cisco Network Time Protocol Distributed Reflective Denial of Service Vulnerability https://tools.cisco.com/security/center/content/CiscoSecurityNotice/CVE-2013-5211
2.      Cisco IOS Software NTP Control Mode 7 vulnerability CSCtd75033 https://bst.cloudapps.cisco.com/bugsearch/bug/CSCtd75033



Комментариев нет:

Отправить комментарий