Secure ntp.conf against DDoS abuse


#1

Is there anything missing in my ntp.conf so ntpd can be used to DDoS?
Right now I got this:

restrict default kod nomodify notrap nopeer noquery
disable monitor

Because just a few days ago I almost killed my co-lo’s router with a
900 Mbit/s DDoS against some cn IPs. Example data from tcpdump that I got from
co-lo:

10:45:42.150376 IP myip.123 > 121.40.75.145.55699: NTPv2, Reserved, length 440
10:45:42.100010 IP myip.123 > 116.31.125.15.24292: NTPv2, Reserved, length 440

Right now ntp is blocked until I find the source of this problem.


#2

What I have here is:

restrict default limited nomodify notrap nopeer noquery
restrict -6 default limited nomodify notrap nopeer noquery

You don’t seem to have “limited” in your configuration, which is the key. I also don’t bother sending KoD packets (the kod keyword) at all.

I also have “discard average 5 minimum 1” in my own config. Quoting:

[quote]average — specifies the minimum average packet spacing to be permitted, it accepts an argument in log2 seconds. The default value is 3 (2^3 equates to 8 seconds).

minimum — specifies the minimum packet spacing to be permitted, it accepts an argument in log2 seconds. The default value is 1 (2^1 equates to 2 seconds).
[/quote]
2^5 is 32.

I also drop all UDP traffic that originates from some IP’s port 53 (DNS) to my server’s port 123 (NTP). I find it unlikely that any such traffic would be legit. I do this with ip(6)tables.


#3

Did you also have 900 Mbps inbound traffic? Nothing especially bad should happen with that restrict rule.

Some such traffic will be legitimate. Some NAT gateways use any port at random, including double-digit ones.


#4

No doubt, but this is about probabilities. When you drop or limit any kind of NTP traffic, it is always possible that someone’s legit traffic will also get dropped. If you want to be 100% certain that all legit requests get answered, don’t limit any traffic. However, that may also lead to your NTP server being used in a DDoS. So it’s a compromise.

By your logic (port chosen randomly), packets from source ports 53 and 54 (which is apparently “xns-ch, XNS Clearinghouse”) should occur approximately as often, right? On one of my servers, I received 402 packets from port 53 and 14 packets from port 54 in an hour. This gives me the impression that for many (but not all) of those packets originating from port 53, the port wasn’t chosen randomly.

Edit: For full disclosure, the server received around 500k requests during that hour, so around 0.1% of requests got dropped due to that rule. I can live with this.


#5

At least on the versions of ntp I use, you must specify “kod” in order to use “limited”.


#6

It should be the other way around.

  • If you only set kod: Nothing happens. It’s ignored. There is no rate limiting.
  • If you only set limited: Rate limiting is enabled. Excessive queries will be dropped, but KoD replies will not be sent.
  • If you set both kod and limited: KoD and rate limiting are enabled. Sometimes excessive queries will be silently dropped, sometimes KoD replies will be sent.

#7

Thanks, I have added “limited” now. I also choose to not send KoD and removed “kod”.


#8

I dont know but I find it unlikely. Well, something bad did happend anyway.


#9

A new problem appeared, monitor cant be disabled when I use limited.
ntpd says: “monitor cannot be disabled with limited restrict”

Does that mean its vuln to monlist DDoS or will limited take care of
that problem?

Right now I got this cfg:

restrict default limited nomodify notrap nopeer noquery
restrict -6 default limited nomodify notrap nopeer noquery
disable monitor

restrict 127.0.0.1
restrict -6 ::1


#10

You’re safe. noquery in the restrict options means your server won’t answer to such queries.


#11

Ah yes - I had them the wrong way around.