Date: Thu, 20 Mar 2014 12:33:03 -0700 From: "Ronald F. Guilmette" <rfg@tristatelogic.com> To: freebsd-security@freebsd.org Subject: Re: NTP security hole CVE-2013-5211? Message-ID: <44680.1395343983@server1.tristatelogic.com> In-Reply-To: <201403201719.LAA29320@mail.lariat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <201403201719.LAA29320@mail.lariat.net>,
Brett Glass <brett@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44680.1395343983>