Date: Sat, 22 Mar 2014 19:34:48 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> 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: <20140322182402.Q83569@sola.nimnet.asn.au> In-Reply-To: <51546.1395432085@server1.tristatelogic.com> References: <51546.1395432085@server1.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 21 Mar 2014 13:01:25 -0700, Ronald F. Guilmette wrote: > In message <20140322000445.C31989@sola.nimnet.asn.au>, > Ian Smith <smithi@nimnet.asn.au> 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 <localip> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140322182402.Q83569>