[Pool] Odd surge in traffic today

Dave Hart hart at ntp.org
Sat Dec 10 14:59:23 UTC 2011

On Sat, Dec 10, 2011 at 12:40, Kiss Gábor <kissg at niif.hu> wrote:
>> It happened again today. This time I had tcpdump running and captured the
>> traffic: http://tursas.miuku.net/tmp/ntp.tursas.2.tcpdump.gz
>> 13:26:19.545411 IP > tursas.miuku.net.ntp: NTPv2, Reserved,
>> length 160
>> 13:26:19.545452 IP tursas.miuku.net.ntp > NTPv2, Reserved,
>> length 488
>> 13:26:19.545461 IP tursas.miuku.net.ntp > NTPv2, Reserved,
>> length 488
>> 13:26:19.545466 IP tursas.miuku.net.ntp > NTPv2, Reserved,
>> length 488
>> ...
> Confirmed:
> 13:37:32.761089 IP > service1-eth3.debrecen.hpc.niif.hu.ntp: NTPv2, Reserved, length 160
> 13:37:32.781662 IP > service1-eth3.debrecen.hpc.niif.hu.ntp: NTPv2, Reserved, length 160

There is only one avenue I'm aware of that can result in 10x (or 20x,
but not 80x) amplification from ntpd: mode 7 monlist requests are a
solitary unauthenticated packet with a spoofable source address, which
result in a series of near-maximum-size (for mode 7) responses
containing the client addresses and stats displayed by ntpdc -c
monlist.  A kind soul alerted us to the risk a couple of years ago,
triggering the removal of monlist functionality from ntpd and its
replacement by a source-address-validating alternative, ntpq -c

One mitigation option for the monlist amplification abuse is
illustrated by the two pool members quoted above.  The first allows
ntpdc & ntpq queries from the public, which I value and praise in
general.  The second server does not, likely due to a "restrict
default noquery ..." configuration, and as a result avoided sending
many packets to, likely a forged source address
meaning the monlist requests originated elsewhere via a network path
failing to validate source addresses in the access layer, enabling

Another mitigation option is to take the dive into ntp-dev.  By
default, recent 4.2.7 ntpd defaults to ignoring all mode 7 requests,
unless "enable mode7" is added to ntp.conf.  In 4.2.7p26, the monlist
support code in ntpd was removed due to amplification risk, so that
even with "enable mode7" monlist queries are ignored.  ntpq -c mrulist
provides a more capable and flexible replacement that requires
requests carry evidence of ability to receive traffic sent to the
claimed source address, making blind reflection + amplification
attacks impossible.

While you are looking at your NTP server configuration, please
consider enabling rate limiting and kod by including both keywords
"limited kod" in your restrict default configuration.  This makes a
NTP server much less powerful as a reflection vector, picking on a
single remote address at less than a packet per second.  See also the
"discard average" and "discard minimum" options to fine-tune rate

Thanks for your attention to this problem,
Dave Hart

More information about the pool mailing list