From owner-freebsd-security@FreeBSD.ORG Fri Mar 21 19:34:41 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FC45F9B for ; Fri, 21 Mar 2014 19:34:41 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 3B52090D for ; Fri, 21 Mar 2014 19:34:40 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 1167C3ADFA for ; Fri, 21 Mar 2014 12:34:36 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-security@freebsd.org Subject: Re: URGENT? (was: Re: NTP security hole CVE-2013-5211?) In-Reply-To: <20140321122701.AC6D411A9DE6@rock.dv.isc.org> Date: Fri, 21 Mar 2014 12:34:36 -0700 Message-ID: <51444.1395430476@server1.tristatelogic.com> 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: Fri, 21 Mar 2014 19:34:41 -0000 In message <20140321122701.AC6D411A9DE6@rock.dv.isc.org>, Mark Andrews wrote: >In message <45158.1395348066@server1.tristatelogic.com>, "Ronald F. Guilmette" >writes: >> 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. 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.) >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