Over the last few years there’s been a significant increase of a specific amplified Distributed Reflection Denial of Service attacks. In addition to Internet Protocol address spoofing these attacks mostly exploit old and unprotected internet services that enable unauthenticated (connectionless) clients to receive bigger responses hence amplifying the traffic. Perhaps the most common examples are open DNS resolvers and public unauthenticated SNMP servers that became instrumental in large targeted DDoS attacks.
As global networks continue to grow and become more complex risks are greatly increasing. By disabling and/or restricting unnecessary and potentially unsafe functionality of such services system administrators can help to eliminate these inherent vulnerabilities in their networks and thus contribute to global network security. In LITNET we recently observed a very interesting NTP attack following the mentioned pattern during which enormous amounts of data was being sent from our stratum 1/2 NTP servers:
Date flow start Duration Proto Src IP Addr:Port Dst IP Addr:Port Flags Tos Packets Bytes 2013-10-21 08:21:17.630 147.610 UDP X.X.X.X:123 -> Y.Y.Y.Y:25565 ...... 0 2.4 M 1.1 G 2013-10-21 08:21:17.630 147.600 UDP Y.Y.Y.Y:25565 -> X.X.X.X:123 ...... 128 24100 867600
There seems to be very little relevant information on this amplification+reflection NTP attack type in the internet. After a little research it turned out that it was utilizing ‘monlist’ query which is a built-in monitoring function providing a history of recent NTP clients. During the attack huge amounts of small spoofed 8-byte UDP packets are sent to the vulnerable (or rather “open”) NTP server in which it responds with a proper DoS. Currently the best available solution is to update to NTP 4.2.7p26 for which the support of ‘monlist’ query has been removed in favor of new safe ‘mrunlist’ function which uses a nonce value ensuring that received IP address matches the actual requester. After upgrading our NTP servers the attacks stopped. Even though it’s a tiny little function of NTP it effectively enabled attacker to exploit our server. Therefore if you happen to manage a public NTP server this update is highly recommended.
By executing commands below you can test if your local NTP server is vulnerable:
ntpq -c rv
ntpdc -c sysinfo
ntpdc -n -c monlist
It can also be checked using nmap’s NSE script ntp-monlist:
nmap -sU -pU:123 -Pn -n --script=ntp-monlist ntp.server.com
If update is not possible at the moment another workaround is to completely disable status queries by adding these lines to /etc/ntp.conf (configuration can be extended to restrict these features per network segment):
restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery
Such attacks are usually intensified by using many vulnerable servers at the same time. These servers can be thought of as passive botnet members since attacker can passively gather large lists of them. More importantly apart from NTP which is a well-known protocol there’s an open question about many exposed proprietary protocols that are not so popular but could be vulnerable to this particular attack type.
more information: