NTP security hole CVE-2013-5211?

[Remko Lodder]

On 21 Mar 2014, at 20:20, Ronald F. Guilmette <rfg at tristatelogic.com> wrote:

> 
> In message <AD479A36-993D-442A-AA07-AB52D8198624 at FreeBSD.org>, 
> Remko Lodder <remko at FreeBSD.org> wrote:
> 
>> Reading the mails from this thread leads me to believe that there is no
>> stateful firewall concept in place?
> 
> I am not the poster to whom you were responding (info at rit.lt), however
> speaking only for myself I will confess that yes, in my case at least,
> although I have used ipfw for many years, I have never (until now) found
> any compelling need to either understand or make use of any of ipfw's
> stateful capabilities.

Hi Ronald,

That is ‘fine’ ofcourse but makes you vulnerable to the ‘crap’ that is hitting
your doorway now. 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. That is already
way better then a lot of other people.

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? or could we have
done a better job in reasoning why stateful has it’s advantages?

> 
>> In my believing it is so that if you do not filter traffic, you are
>> making a deliberate choice to let everyone smack your service(s).
> 
> I personally *do* most certainly filter traffic, and have done, since
> I first connected *any* machine of mine to the Internet.  I can assure
> yoy that I never made any deliberate choice to let everyone smack me
> around.  Nontheless, that clearly did happen, eventually, when evil-doers
> decided, relatively recently, to use & abuse me as an NTP reflector, but
> my participation in this was not in any sense deliberate on my part, and
> arose strictly out of ignorance, for which I am suitably humbled and
> apologetic.

Let me offer my apologies, I did not want to make you feel ignorant or anything.

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.

People do make a living in ‘pestering’ you and I (and many others) and now
smacking your NTP server(s) is gaining them something, or they wouldn’t just
do it.

My best advice in this case might be that only allowing in the networks you
want to have in on your NTP server (Stateful) prevents people that you do not
want to have their in the first place. Only letting out the traffic you want
(also stateful) prevents bogus replies because they most likely are caught at
the firewall already.

Ofcourse the software should be well protected as well, and secteam@ did his
best to offer the best solution possible. Though as mentioned by Brett for
example we just cannot force the update of ntpd.conf on user machines because
every admin could have legitimate reasons for having a configuration in place
they decided to have. It’s risky to change those things and especially enforce
them on running machines. Most of his ideas were in the advisory already
except for the ‘disable monitor’ part, which might be reason to discuss
whether that makes sense or not.

Thank you,

Remko

> 
> 
> Regards,
> rfg
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"

-- 

/"\   Best regards,                      | remko at FreeBSD.org
\ /   Remko Lodder                       | remko at EFnet
 X    http://www.evilcoder.org/          |
/ \   ASCII Ribbon Campaign              | Against HTML Mail and News

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20140321/5aef3495/attachment.sig>