From owner-freebsd-security@FreeBSD.ORG Sat Mar 22 08:34:53 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 97BBCC0D for ; Sat, 22 Mar 2014 08:34:53 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EAE9925B for ; Sat, 22 Mar 2014 08:34:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s2M8YmDq088694; Sat, 22 Mar 2014 19:34:49 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 22 Mar 2014 19:34:48 +1100 (EST) From: Ian Smith To: "Ronald F. Guilmette" Subject: Re: URGENT? (was: Re: NTP security hole CVE-2013-5211?) In-Reply-To: <51546.1395432085@server1.tristatelogic.com> Message-ID: <20140322182402.Q83569@sola.nimnet.asn.au> References: <51546.1395432085@server1.tristatelogic.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 08:34:53 -0000 On Fri, 21 Mar 2014 13:01:25 -0700, Ronald F. Guilmette wrote: > In message <20140322000445.C31989@sola.nimnet.asn.au>, > Ian Smith wrote: > > >As assorted experts have suggested, you need a stateful rule. It's > >really not that hard; if you _only_ needed to protect ntp on udp: > > > > kldload ipfw && add 65000 allow ip from any to any # load null fw > > ipfw add allow udp from me to any ntp out xmit $outsideif keep-state > > ipfw add deny udp from any to me ntp in recv $outsideif > > > >Done. Perfectly configured for this one purpose, statefully no less .. > > Sounds great to me! However I've never really used any of the stateful > ipfw stuff, so I'm venturing out into what, for me, are unfamiliar waters. So I gathered from earlier posts, which is why I thought to spell it out - as did Julian more succinctly, I see - as not being too scary :) > So I hope you'll be kind and entertain a question or two, to help me > understand exactly what I'm supposed to do. > > I've just skimmed over the page here: > > https://www.freebsd.org/doc/handbook/firewalls-ipfw.html > > and my questions are based on the tutorial information I've found there. Firstly, that's the one page in the handbook (that I know of) that needs completely nuking. It contains many factual errors as well as weird notions, and will only tend to mislead you; consult ipfw(8) and prosper. I'd say refer to the examples in rc.firewall but it too is in disrepair. > First question: In addition to what you have written above, may I safely > assume that I also need an additional rule, somewhere early in my entire > (numbered) list of rules, that just simply says "check-state"? In that specific ruleset - for one specific purpose, remember - no. In general yes; in a ruleset containing other rules, check-state should be placed where you want packets tested against all active dynamic rules. ipfw checks and acts upon state at the first check-state OR keep-state rule encountered - which is why it was refundant in the example above. > Second question: In the example text given just about half-way down on > the web page cited above, within part of a big block of example rules I > see this: > > # Allow outbound NTP > $cmd 00260 allow tcp from any to any 37 out via $pif setup keep-state time 37/tcp timserver time 37/udp timserver I know nothing about that protocol; it's not NTP anyway, but is yet another great example of why that handbook page should be avoided. Thanks to Mark for explaining that NTP only works over UDP, so .. [..] > Last question: Assuming that my local ntpd is strictly and only using > UDP for all communication, would something like the following be a proper > set of additions to my current ipfw rules? > > add 00101 check-state > add 00500 pass udp from 123 to any 123 out via $pif keep-state > > If not, what should I use instead? Sure. You don't need to specify 123 as source port, in case Brett gets his wish for NTP to change to random source ports - good luck with that! - or if this were a router for a local LAN where clients - I notice OS/X boxes regularly - do use a random high source port for NTP queries. cheers, Ian