[Lug-bg] [Fwd: Re: [Pool] Odd surge in traffic today]

[Vasil Kolev <vasil@xxxxxxxxxx>]

Наскоро разни хора са започнали да използват NTP сървъри за усилватели
на атаки. Attach-нал съм писмо от mail list-а за pool.ntp.org. Вътре има
идея какво може да се направи да се спре тоя тип атака.
-- 
Regards,
Vasil Kolev

--- Begin Message ---

• Subject: Re: [Pool] Odd surge in traffic today
• From: Dave Hart <hart@xxxxxxx>
• Date: Sat, 10 Dec 2011 14:59:23 +0000
• Cc: "pool@xxxxxxxxxxxxx" <pool@xxxxxxxxxxxxx>
• Delivered-to: vasil@xxxxxxxxxxxxxxxx
• Delivered-to: pool@xxxxxxxxxxxxx

On Sat, Dec 10, 2011 at 12:40, Kiss Gábor <kissg@xxxxxxx> 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 27.50.2.183.http > tursas.miuku.net.ntp: NTPv2, Reserved,
>> length 160
>> 13:26:19.545452 IP tursas.miuku.net.ntp > 27.50.2.183.http: NTPv2, Reserved,
>> length 488
>> 13:26:19.545461 IP tursas.miuku.net.ntp > 27.50.2.183.http: NTPv2, Reserved,
>> length 488
>> 13:26:19.545466 IP tursas.miuku.net.ntp > 27.50.2.183.http: NTPv2, Reserved,
>> length 488
>> ...
>
> Confirmed:
>
> 13:37:32.761089 IP 27.50.2.183.http > service1-eth3.debrecen.hpc.niif.hu.ntp: NTPv2, Reserved, length 160
> 13:37:32.781662 IP 27.50.2.183.http > 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
mrulist.

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 27.50.2.183:123, 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
reflection.

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
limits.

Thanks for your attention to this problem,
Dave Hart
_______________________________________________
pool mailing list
pool@xxxxxxxxxxxxx
http://lists.ntp.org/listinfo/pool

--- End Message ---

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Lug-bg mailing list
Lug-bg@xxxxxxxxxxxxxxxxxx
http://linux-bulgaria.org/mailman/listinfo/lug-bg