Date: Sat, 22 Mar 2014 11:24:06 +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: <20140322002406.A27F311AF3F5@rock.dv.isc.org> In-Reply-To: Your message of "Fri, 21 Mar 2014 12:34:36 -0700." <51444.1395430476@server1.tristatelogic.com> References: <51444.1395430476@server1.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <51444.1395430476@server1.tristatelogic.com>, "Ronald F. Guilmette" writes: > > In message <20140321122701.AC6D411A9DE6@rock.dv.isc.org>, > Mark Andrews <marka@isc.org> wrote: > > >In message <45158.1395348066@server1.tristatelogic.com>, "Ronald F. Guilmett > e" > >writes: > >> I'm no expert, but I'll go out on a limb here anyway and say that the choi > ce > >> to make NTP outbound queries always use source port 123 is, as far as I ca > n > >> see, really really ill-advised. Did we learn nothing from all of the bruh > aha > >> 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. > > OK. You're right. I stand corrected and retract my earlier ill-considered > comment. > > >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. > > Perhaps you and I could debate this specific argument at greater length > off-list. For the moment I'll just say that, for me at least, it doesn't > seem like a terribly compelling argument. (Obviously, and as I'm sure you > well know, BIND has made this work for some time now, and doesn't seem > particularly the worse for it.) When you are trying to keep and serve accurate time it is very much a argument. Opening new sockets is expensive for BIND. It significantly affects the number of recursive requests a server can make. It requires lots of extra management. > >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. > > There is no other way via which local tools could communicate with a local > ntpd?? > > I may be mis-remembering, but isn't there a sort-of (entirely separate) > control port for BIND that is implemented via a local UNIX domain socket? > > >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. > > OK, please bear with me...I just want to verify... > > I have just added the following single line to the end of my /etc/ntp.conf > file: > > disable monitor > > That's all there is to it? > > >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. > > Could you elaborate please? > > I -believe- that I understand what you just said, but I'd like to be 100% > sure that I did. > > > Regards, > rfg > _______________________________________________ > 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?20140322002406.A27F311AF3F5>