Date: Fri, 21 Mar 2014 23:27:01 +1100 From: Mark Andrews <marka@isc.org> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: freebsd-security@freebsd.org Subject: Re: URGENT? (was: Re: NTP security hole CVE-2013-5211?) Message-ID: <20140321122701.AC6D411A9DE6@rock.dv.isc.org> In-Reply-To: Your message of "Thu, 20 Mar 2014 13:41:06 -0700." <45158.1395348066@server1.tristatelogic.com> References: <45158.1395348066@server1.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <45158.1395348066@server1.tristatelogic.com>, "Ronald F. Guilmette" writes: > > In message <201403202028.OAA01351@mail.lariat.net>, > Brett Glass <brett@lariat.org> wrote: > > >... > >And the need to do so is becoming more urgent. Just over the past 24 hours, > >I am seeing attempted attacks on our servers in which the forged packets > >have source port 123. Obviously, they're counting on users having "secured" > >their systems with firewall rules that this will bypass. > >... > >And, as you state above, outbound queries should use randomized ephemeral > >source ports as with DNS. This involves a patch to the ntpd that's shipped > >with FreeBSD, because it is currently compiled to use source port 123. > > I'm no expert, but I'll go out on a limb here anyway and say that the choice > to make NTP outbound queries always use source port 123 is, as far as I can > see, really really ill-advised. Did we learn nothing from all of the bruhaha > a couple of years ago about DNS amplification attacks and the ways that > were finally settled on to effectively thwart them (most specifically the > randomization of query source ports)? Well for DNS the source port randomisation was to prevent cache poisoning so no *you* didn't learn anything from port randomisation in DNS. For time you want to reduce the variabilty in code paths taken as much as posible so no you don't want to be opening up a new socket every time. Now if you are not running as a server or peer you can use a different port but that prevents local tools reaching ntpd to find out how ntpd is doing. NTP does have the ability to work out which commands it will accept and from whom. This stops NTP being used as a amplifier. The built in configuration has already been changed to make this the default behaviour. Now one can change the code to drop the negative packet but that also stops you tell legitimate NTP clients to stop using you. Reflection really isn't a big help and as has been seen in the DNS stopping the ability to be used as a amplifier does stop lead to you being removed from the lists of reflectors. This is no immediate but it does happen. > I dearly hope that someone on this list who does in fact have commit privs > will jump on this Right Away. I'm not persuaded that running a perfectly > configured ipfw... statefully, no less... should be an absolute prerequsite > for running any Internet-connected FreeBSD-based device that simply wishes > to always know the correct time. You can run a stateless firewall with on a NTP client and it is no longer a reflector which can be directed at any ip address in the world if you care to. > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140321122701.AC6D411A9DE6>