In message <201403201719.LAA29320 at mail.lariat.net>, Brett Glass <brett at lariat.net> wrote:>At 09:56 PM 3/17/2014, Ronald F. Guilmette wrote: > >>(It was explained to me at the time that NTP operates a bit like DNS... >>with which I am more familiar... i.e. that all outbound requests originate >>on high numbered ports, well and truly away from all low numbered ports, >>including, in particular, 123. I am just re-verifying that my understanding >>in this regard is correct, and that my current blanket firewall rule is >>fine as it stands.) > >Different implementations do different things in this regard. Alas, newer >versions of ntpd seem to use UDP port 123 as the originating port when >synchronizing with outside servers while older versions did it right and >used high, ephemeral ports. This means that stateful firewalling is >required for security, and even with it spoofing is still possible if the >attacker can guess which servers you query. (The ones in the default FreeBSD >ntp.conf file are likely to work most of the time.) > >We should definitely patch the ntpd that's shipped with FreeBSD to issue >queries on randomly chosen ephemeral ports...I agree entirely with every part of that statement except one. In the immortal words of the Lone Ranger's trusted sidekick (Tonto)... "What do you mean WE kimo sabe?" I personally don't have commit privledges for any part of FreeBSD. Other than that, yes, all outbound NTP queries really should be sent out on high numbered ports, well and truly away from 123. (And also, the outbound port number should be well and truly randomized, I should think. If it's good for the goose, i.e. DNS, then it's probably good for the gander too.) Humm... Uh oh! Oh s**t! When I woke up one day and found all of my bandwidth gone... as a result of being & abused as an NTP reflector... I had rather blithely assumed that the solution that someone offered to me at that time, i.e. just simply blocking all inbound UDP to port 123, was the "right" answer. (It sure did give me my bandwidth back!) It never occured to me... until now... to go back after I made that firewall change and check to see if my local ntpd was still properly able to receive time from any of the servers it was querying. Now that I'm looking at it, it appears that maybe it isn't. If true, that is quite obviously a major bummer. I have a little clock/thermometer thingy in the other room that allegedly picks up and displays the NIST time signal that is broadcast from Colorado. Checking now, I see that the time on my server is slightly more than three full minutes off, relative to that clock/thermometer thingy. (Yikes!) Here is what I am seeing now in response to an ntpdc "peers" query. I am not really all that familiar with this stuff, so if anybody else here can tell me if this looks messed up or not, I'd sure appreciate it. remote local st poll reach delay offset disp =======================================================================nist.netservice 69.62.255.118 16 1024 0 0.00000 0.000000 3.99217 =rook.slash31.co 69.62.255.118 16 1024 0 0.00000 0.000000 3.99217 =96.44.142.5 69.62.255.118 16 1024 0 0.00000 0.000000 3.99217 Of course, if this *is* messed up, then I guess that I'll have to remove my firewall rule, and diddle my /etc/ntp.conf file at the same time, in order to make sure that the Evil Ones don't come back and use & abuse me again. And if _that_ is true, then it certainly does underscore the need for changes to the default /etc/ntp.conf file that has been distributed with FreeBSD.
Hi-- On Mar 20, 2014, at 12:33 PM, Ronald F. Guilmette <rfg at tristatelogic.com> wrote:> Here is what I am seeing now in response to an ntpdc "peers" query. I am > not really all that familiar with this stuff, so if anybody else here can > tell me if this looks messed up or not, I'd sure appreciate it. > > > remote local st poll reach delay offset disp > ======================================================================> =nist.netservice 69.62.255.118 16 1024 0 0.00000 0.000000 3.99217 > =rook.slash31.co 69.62.255.118 16 1024 0 0.00000 0.000000 3.99217 > =96.44.142.5 69.62.255.118 16 1024 0 0.00000 0.000000 3.99217Reachability score of 0 means you've blocked the communications.> Of course, if this *is* messed up, then I guess that I'll have to remove > my firewall rule, and diddle my /etc/ntp.conf file at the same time, in > order to make sure that the Evil Ones don't come back and use & abuse me > again.OK, although you're making this more complicated than it needs to be. If you don't want to provide NTP service to the outside world, leave your existing deny rule in place but add permit rules to allow UDP traffic to and from the NTP servers which you want to sync time from. Regards, -- -Chuck
In message <742A1A10-15BF-433A-8693-CA2DD1DE0501 at mac.com>, Charles Swiger <cswiger at mac.com> wrote:>> Of course, if this *is* messed up, then I guess that I'll have to remove >> my firewall rule, and diddle my /etc/ntp.conf file at the same time, in >> order to make sure that the Evil Ones don't come back and use & abuse me >> again. > >OK, although you're making this more complicated than it needs to be. > >If you don't want to provide NTP service to the outside world, leave your exis >ting >deny rule in place but add permit rules to allow UDP traffic to and from the >NTP servers which you want to sync time from.OK, but I wonder what the best way to do that is. Here are some lines from my /etc/ntp.conf file that would seem to be relevant: server 0.freebsd.pool.ntp.org iburst server 1.freebsd.pool.ntp.org iburst server 2.freebsd.pool.ntp.org iburst Is it possible that the three host names given in these lines may possibly become associated with various *different* IPv4 addresses, over time? I would guess so, else why use host names, rather than fixed IPv4 dotted quad addresses? I may be wrong, but as far as I know, ipfw rules need to be written with fixed IPv4 addresses (or fixed CIDRs). So what happens if I hard-code the IPv4 addresses associated with the above three host names into my ipfw rule set, and then, sometime later on, the relevant NTP servers get relocated to new addresses within the IPv4 address space?
At 01:33 PM 3/20/2014, Ronald F. Guilmette wrote:>I agree entirely with every part of that statement except one. > >In the immortal words of the Lone Ranger's trusted sidekick (Tonto)... >"What do you mean WE kimo sabe?" > >I personally don't have commit privledges for any part of FreeBSD. > >Other than that, yes, all outbound NTP queries really should be sent out >on high numbered ports, well and truly away from 123. (And also, the >outbound port number should be well and truly randomized, I should think. >If it's good for the goose, i.e. DNS, then it's probably good for the >gander too.)Well, I'm afraid that I do not have a commit bit either (I've been sending contributions of code and patches to those who do), so all I can do is suggest that the community do it. Hence the "we." 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.>Of course, if this *is* messed up, then I guess that I'll have to remove >my firewall rule, and diddle my /etc/ntp.conf file at the same time, in >order to make sure that the Evil Ones don't come back and use & abuse me >again.IMHO, you should diddle /etc/ntp.conf as I mentioned in my earlier message AND use stateful firewall rules (IPFW works fine for this) to ensure that you only accept incoming NTP packets which are answers to your own queries. 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. (Back in the days of FreeBSD 5.x and 6.x, it used ephemeral source ports, but not now.) --Brett Glass