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.
name='more'>
How to check if your NTP-server is vulnerable for such an attack?
Type the command in Unix CLI:
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:
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):
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:
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].
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.
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:
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
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
