Date: Fri, 21 Mar 2014 17:07:00 -0700 From: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org> Subject: Re: NTP security hole CVE-2013-5211? Message-ID: <52999.1395446820@server1.tristatelogic.com> In-Reply-To: <8F3083F1-3A20-4FEC-9969-F9968D87569E@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <8F3083F1-3A20-4FEC-9969-F9968D87569E@FreeBSD.org>, Remko Lodder <remko@FreeBSD.org> wrote: >Rest assured that you are already doing a great step in at >least filtering your machines and as you demonstrate you are active on >the internet to get the information you need to do it properly. Well, one tries. But it is clear that I could have done better. >A question that pops my mind: Do you think we (security people) needed >to be more verbose about why this might have been a good idea? This what? >or could we have >done a better job in reasoning why stateful has it=92s advantages? I can only speak for myself. For me personally, because I already had a fair amount of knowledge about IP protocols generally (e.g. TCP & UDP), even before I encountered this one specific (ntp) problem, it was not at all difficult to understand... once I was told that the FreeBSD ntpd always originates its queries from 123... why stateful firewall rules would be spectacularly helpful, at least within this one specific context. So my personal answer is "No, there is no need for anyone to write more than is already readily available on the net to explain why stateful rules can sometimes be a very exacting, scalple-like solution for certain problems, like, in particular, this one. And my own ipfw rules set _does_ now include a stateful rule for NTP traffic. I am pleased to say it seems to be working perfectly so far. >Let me offer my apologies, I did not want to make you feel ignorant >or anything. No no! Don't worry. I did that all by myself. I *was* in fact ignorant of a number of things at the outset of this recent unfortunate exploitation episode, in particular (a) that ntpd originates outbound queries from port 123 and also (b) how to actually make use of the stateful features of ipfw. But thanks to the kind help I've received here I am no longer ignorant of these things. (Ignorance is only a cause for minimal shame. Actual stupidity is a rather less excusable sin... one which I hope I am only rarely guilty of.) >What I meant is that everyone should filter on their machines, or if >possible >even ahead of their machines at the gateways. Stopping traffic you do >not want >should occur at the border so that it never ever reaches the machines it >is not >supposed to reach. Of course! When I spoke earlier, and with rather sweeping generalities, about "FreeBSD-based devices" I was thinking about some of the several home entertainment gadgets that I've acquired recently (even though probably all of those are actually running some flavor of Linux). At least a couple of those need to know what time it is. I have been quite deliberate in keeping all of those new gadgets well and truly behind my Linksys E2000 (and thus NAT) which I believe is protecting them from essentially all outside hostilities. My server however is a different matter. It's direct-connected to the net, via my ISP. So it needs to protect itself, without expecting any help from any other boxes. And until this whole recent NTP ruckus, I belived that I had it set up properly to do exactly that, and perfectly. Well, as the old saying goes, "Close only counts in horse-shoes and atom bombs." >Ofcourse the software should be well protected as well... Yes. When it comes to security, I, for one, am very much a "belt and suspenders" kind of guy. So I now have _both_ a stateful firewall rule for my NTP traffic _and_ also I've added "disable monitor" to my ntp.conf file. That ought to do it, I think. Regards, rfg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52999.1395446820>