
NTP Patches Flaws That Enable DDoS - okket
https://threatpost.com/ntp-patches-flaws-that-enable-ddos/118470/
======
imglorp
It's worth pointing out that the NTPsec project is working hard on reducing
the attack surface of NTP classic. At some point there will be few or no
reasons to run NTP.

[http://esr.ibiblio.org/?p=7167](http://esr.ibiblio.org/?p=7167)

[https://www.ntpsec.org](https://www.ntpsec.org)

~~~
jlgaddis
Personally, I'm looking forward to phk's Ntimed (currently funded by the Linux
Foundation).

~~~
technion
Are you sure the project is still active? The README talks about first
releases happening "soonish", but it's been over a year since the repo saw any
activity.

[https://github.com/bsdphk/Ntimed](https://github.com/bsdphk/Ntimed)

------
jlgaddis
Unrelated to NTP, but I (network engineer at an ISP) have also recently
observed a few DDoS attacks using the "rpcbind/portmapper" service being used
for amplification as well.

The first time I saw this was fairly recently but I've seen a few more
instances since then, which may be an indication that this will become more
widely used in the future.

Ensure that you've disabled unnecessary services and put a (default deny)
firewall in front of your servers, for fuck's sake!

~~~
zyztem
Oh, FFS! BCP38 is 16 year old today.

Please ensure that packets with spoofed source can not leave your network.

~~~
kkirsche
While possible for customer networks you cannot do this for transit as you
don't know the source address.

~~~
NickNameNick
you can still drop packets with invalid sources - private address ranges.
reserved addresses, etc

------
ryuuchin
I've been under the impression for a while now that unless you needed the
super accurate timekeeping that ntpd provides (most don't) you're better off
just using openntpd which should exist in most distro's repo's[1]. It's
basically just "good enough" for everybody who doesn't need sub ms accurate
time keeping.

[1]
[https://packages.debian.org/sid/openntpd](https://packages.debian.org/sid/openntpd)

~~~
beagle3
If you do need sub-ms accurate time keeping, then "just" running ntpd is not
enough. You need to have a low-jitter connection to at least one stratum 1
server (if you don't know you have one, you don't), or a local clock.
Otherwise, ntp doesn't give you more precision over openntpd -- only faster
convergence after you've lost contact with servers for a few days.

If you don't know _exactly_ why you need ntpd, the default should be openntpd.

------
Thaxll
Is it too costly to check the source IP of UDP packets exiting ISPs networks?

~~~
jauer
Not really...

On the low end (small ISPs with zero or a handful of downstream ASes), people
aren't aware or are too lazy to implement egress ACLs. Complicating this: A
surprising number of small ISPs and telcos don't actually staff for internet
routing skills (e.g. can work with BGP & have heard of a BCP). They'll bring
on a consultant to "turn up my new circuit" and move on. If the first
consultant sets up egress ACLs and they get a new netblock chances are the
next consultant will just remove the ACL instead of updating it...

Medium to large ISPs: IRRs are supposed to solve this but implementation is
spotty / OMG scripting changes on routers / etc.
[http://www.irr.net/docs/list.html](http://www.irr.net/docs/list.html)

High end: I've heard that some providers have so many customers landing on a
given aggregation router that the ACLs from IRRs end up too large for the
router.

Cogent's approach is to require a LOA for the subnets that you are announcing
and filter out everything else. This seems reasonable, though it gets annoying
when you have a downstream AS that has downstream ASes (BUT that's fairly
uncommon).

I use egress ACLs that allow my RIR-issued and downstream customer blocs and
drop everything else. I have a friend that runs a slightly larger ISP (5x more
downstream ASes) that does automation with IRRs.

------
jedisct1
Chrony is a good alternative:
[https://chrony.tuxfamily.org/](https://chrony.tuxfamily.org/)

