URGENT? (was: Re: NTP security hole CVE-2013-5211?)

[Ian Smith]

On Fri, 21 Mar 2014 13:01:25 -0700, Ronald F. Guilmette wrote:
 > In message <20140322000445.C31989 at sola.nimnet.asn.au>, 
 > Ian Smith <smithi at 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