Once Bug #1531 is resolved, ntpd's support for ntpdc's monlist operation should be stubbed to return an error. One reason is the protocol is inherently fragile and not portable, depending on being able to queue many UDP packets received in a burst. Another is it cannot be secured as ntpq's mrulist can, because backwards compatibility would be broken, at which point there's no reason to maintain it with mrulist providing better access to the same functionality. On the other hand, ntpdc should retain its monlist implementation for some time so that a newer ntpdc can manage diverse remote ntpd versions before and after the addition of mrulist and removal of monlist. -- Patrikas Kugrinas -------------- 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.7 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 match 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. 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.