From owner-freebsd-security@FreeBSD.ORG Fri Mar 21 12:27:20 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 78B94562 for ; Fri, 21 Mar 2014 12:27:20 +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 14F7E1E1 for ; Fri, 21 Mar 2014 12:27:20 +0000 (UTC) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id B69142383C8; Fri, 21 Mar 2014 12:27:01 +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 6BD70160068; Fri, 21 Mar 2014 12:28:07 +0000 (UTC) Received: from rock.dv.isc.org (dsl092-002-166.sfo1.dsl.speakeasy.net [66.92.2.166]) by zmx1.isc.org (Postfix) with ESMTPSA id 4F378160067; Fri, 21 Mar 2014 12:28:07 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id AC6D411A9DE6; Fri, 21 Mar 2014 23:27:01 +1100 (EST) To: "Ronald F. Guilmette" From: Mark Andrews References: <45158.1395348066@server1.tristatelogic.com> Subject: Re: URGENT? (was: Re: NTP security hole CVE-2013-5211?) In-reply-to: Your message of "Thu, 20 Mar 2014 13:41:06 -0700." <45158.1395348066@server1.tristatelogic.com> Date: Fri, 21 Mar 2014 23:27:01 +1100 Message-Id: <20140321122701.AC6D411A9DE6@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: Fri, 21 Mar 2014 12:27:20 -0000 In message <45158.1395348066@server1.tristatelogic.com>, "Ronald F. Guilmette" writes: > > In message <201403202028.OAA01351@mail.lariat.net>, > Brett Glass 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