How can I defend against a DRDoS exploiting NTP server on an ESXi host?

Recently, we had some problems with one of our ESXi servers, caused by the NTP Server DRDoS Amplification Attack using ntpdc.

How do I configure the NTP server on ESXi to not be exposed to this DDoS attack?

Or, if I switch off the service, will that have any effect on my VMs?

Solution 1:

The answer can be found in this blog post. All you need to do is disable the "monlist" command, which by the way was removed in ntpd 4.2.7 (our ESXi 5.1.0u2 servers are running 4.2.6p2).

1. Access your server's console, either by enabling the local console or SSH.
2. Edit /etc/ntp.conf by adding noquery to the first restrict line.
3. Restart the NTP service with /etc/init.d/ntpd restart.

4. Verify that the monlist command has been disabled:

   ntpdc -c monlist 1.2.3.4

Solution 2:

The question is not answerable - and you may not like the answers that can be given.

2 scenarios, you fail to mention any detail to filter out:

1 - you were used to amplify. In this case I wonder why the ESXi host was accessible from the internet. It should not be. It should not have a public IP. I do not run ESX but maintain a number of Hyper-V servers for customers and man, you would not find ANY of them on the internt. They live in an internal network, all access is done via VPN to that internal gateway. Yes, servers may have public IP addresses - virtual servers - but never the hosts. No need to. ALl traffic they ned from the internet goes through the firewall (via NAT), so they are protected. I consider this professional baseline in security.

2 - you were targetted. In this case - no way. That is like saying "what do I chane on my house so that people do not send me tons of packages I never ordered". by the time the traffic hits the ESX host it already overloads your bandwidth. BUt again, why is the host at all on the internet?

Solution 3:

How do I configure the NTP server on ESXi to not be exposed to this DDoS attack?

At the moment, you can't, really. The ntpd in ESXi isn't really configurable (at least in a VMware-supported fashion), so your options are really on or off.

Presumably, VMware will release a patch or update sometime soon to address the issue, (I don't see one that says it addresses the issue right now), and you could apply that when it comes out, but that won't help right now.

You could manually update your ESXi host to a newer ntpd client that isn't vulnerable (ESXi is "just" a customized Linux distro, after all), but I wouldn't do that and risk being in an unsupported configuration with VMware.

Of course, as you suggest in your question, you can also prevent the attack by turning the service off (for the time being).

Or, if I switch off the service, will that have any effect on my VMs?

That entirely depends on how your guest operating systems are configured for ntp. If they're configured to synchronize time with the host system, they'll start to lose time sync (the more time they spend at idle CPU usage, the worse time drift you'll see).

If they're configured to get time from a different ntp source, they won't have problems... unless, of course, they're also running vulnerable ntp clients, in which case, they'll probably be getting the DRDoS attack instead of the host.

If you're currently configuring your virtual guest OSes to get time from their host servers, now might be a good time to consider a different approach, which would depend entirely on your use case. Running Windows domains makes this easy - the PDC emulator gets ntp time from a reliable (external) ntp source, all other Domain Controllers get their time from the PDC emulator, and all clients get their time from their local Domain Controller. Of course, your use case may well be different or more complicated.