[ntp:hackers] i think it's time to review ntp's default acl's

todd glassey todd.glassey at worldnet.att.net
Thu Mar 23 17:19:28 UTC 2006


I have proposed to PKIX that a mergence of Syslog, NTP and DNS into the same
executable needs to happen - and this would be 'the Event Audit and History
Protocol' - I also suggest that the same would be a powerful addition here.

Todd Glassey
----- Original Message ----- 
From: "Paul Vixie" <paul at vix.com>
To: <hackers at ntp.isc.org>
Sent: Thursday, March 23, 2006 9:10 AM
Subject: [ntp:hackers] i think it's time to review ntp's default acl's


> isc is under significant pressure from the world community to change the
> default in BIND to be "do not answer queries from off-LAN sources", due
> to the now widespread use of DNS as a reflector/amplifier of
spoofed-source
> DDoS attacks.  now, we know that the spoofability of sources is the real
> problem, and that changing the default ACL's is at best a band-aid, but we
> (isc) are going to make a change like this as of BIND9 9.4.0 (due R.S.N.)
>
> since ntp is also udp-based, i think it's time to review ntp's default
ACL.
> (net-snmp already has this default, as does samba and every other
UDP-based
> service for which a UNIX-style implementation is available in open
source.)
>
> please note that amplification, meaning a server responds with a much
larger
> packet than the request, is only gravy in the meal known as DDoS.  the
meat
> and potatoes of it is reflection.  therefore in BIND9 9.4.0, we'll not
only
> change the default ACL, but we'll rate-limit our REFUSED responses.  this
> will manifest as "line loss" to query sources who fall outside the ACL,
but
> is a necessary evil in order to attenuate rather than reflect (or
amplify).
>
> can someone who knows ntpd's defaults say whether off-LAN queries will or
> will not be answered by default?
>
> can someone who knows NTP say whether a normal response is larger than a
> normal query, and whether an error response is larger than a normal query,
> and whether there is any response at all to a malformed query?
>
> can someone who runs this software in production comment on the
advisability
> of rate-limiting error-responses (if there are any), simulating "line
loss"?
>
> i'm embarrassed to be asking these questions.  we're talking about putting
> bandaids on a sucking chest wound when we know the patient's going to die
> anyway.  but there it is.
> _______________________________________________
> hackers mailing list
> hackers at support.ntp.org
> https://support.ntp.org/mailman/listinfo/hackers



More information about the hackers mailing list