From owner-freebsd-security@FreeBSD.ORG Sat Mar 22 00:24:27 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 841194B2 for ; Sat, 22 Mar 2014 00:24:27 +0000 (UTC) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1EB7A814 for ; Sat, 22 Mar 2014 00:24:27 +0000 (UTC) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id AC20C238411; Sat, 22 Mar 2014 00:24:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id ACE60160066; Sat, 22 Mar 2014 00:25:13 +0000 (UTC) Received: from rock.dv.isc.org (unknown [216.9.110.14]) by zmx1.isc.org (Postfix) with ESMTPSA id A922D16005B; Sat, 22 Mar 2014 00:25:13 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A27F311AF3F5; Sat, 22 Mar 2014 11:24:06 +1100 (EST) To: "Ronald F. Guilmette" From: Mark Andrews References: <51444.1395430476@server1.tristatelogic.com> Subject: Re: URGENT? (was: Re: NTP security hole CVE-2013-5211?) In-reply-to: Your message of "Fri, 21 Mar 2014 12:34:36 -0700." <51444.1395430476@server1.tristatelogic.com> Date: Sat, 22 Mar 2014 11:24:06 +1100 Message-Id: <20140322002406.A27F311AF3F5@rock.dv.isc.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mx.ams1.isc.org Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 00:24:27 -0000 In message <51444.1395430476@server1.tristatelogic.com>, "Ronald F. Guilmette" writes: > > In message <20140321122701.AC6D411A9DE6@rock.dv.isc.org>, > Mark Andrews 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