In message <[email protected]>, Brett Glass <[email protected]> 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. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"