nmap -sU -pU:123 -Pn -n --script=ntp-monlist serverIP
nmap -sU -pU:123 -Pn -n --script=ntp-monlist serverIP
Make that “all server IPs” if on different subnets, address families, ...
4) Please prevent packet spoofing where possible on your network. This
will limit the impact of spoofed NTP or DNS (amongst others) packets from
impacting the broader community.
BCP38! I am always surprised when people need crypto if they fail the simple things.
5) Some vendors don’t have an easy way to alter the ntp configuration, or
have not or won’t be updating NTP, you may need to use ACLs, firewall
filters, or other methods to block this traffic. I’ve heard of many
routers being used in attacks impacting the CPU usage.Take a moment and see if your devices respond to the following
query/queries:ntpdc -n -c monlist 10.0.0.1
ntpdc -n -c loopinfo 10.0.0.1
ntpdc -n -c iostats 10.0.0.1
And no matter if you use the above nmap or these instructions to check, also check your IPv6 addresses!
You need 'restrict -6 default ignore' lines or similar as well, not just a restrict default ignore.
Saying that BCP38 is solution to the reflection attacks is not unlike 5 year
old wishing nothing but world peace for christmas, endearing, but it's not
going to change anything.
BCP38 is completely unrealistic, many access networks are on autopilot, many
don't have HW support for BCP38, one port configured has low-benefit, only
that machine can stop attacking (but whole world).
near term, reducing attack surface is practical to reduce impact (not a
solution, just damage control)
near term, transit providers who do BGP prefix-list, could use same
prefix-list for ACL, segmenting spoofing domains. It's very high pay-off,
couple ports configured, whole downstream branch isolated into its own
spoofing domain, able to just attack targets inside same domain.
mid term, transport area in IETF. DNS, NTP, SNMP, chargen et.al. could
trivially change to QUIC/MinimaLT or compared, getting same 0 RTT penalty as
UDP without reflection potential.
That does *not* make it an unworthy goal, nor should it stop people
from encouraging it's implementation.
- - ferg (co-author of BCP38)
- --
Paul Ferguson
PGP Public Key ID: 0x54DC85B2
> BCP38! I am always surprised when people need crypto if they fail the
simple things.Saying that BCP38 is solution to the reflection attacks is not unlike 5
year
old wishing nothing but world peace for christmas, endearing, but it's not
going to change anything.
BCP38 is completely unrealistic, many access networks are on autopilot,
many
don't have HW support for BCP38, one port configured has low-benefit, only
that machine can stop attacking (but whole world).near term, reducing attack surface is practical to reduce impact (not a
solution, just damage control)
BCP38 (even if not fully deployed) is the only viable form of reducing the
attack surface. Other ideas can never reach enough adoption to have any
impact (they need to be ~100% deployed before any improvement is seen).
As an example, let's imagine you successfully close 99% of the open DNS
recursive resolvers, dropping the number of available reflectors from 28M
down to 280k. Has that achieved anything? No, the attacks will be just as
large. Or even if you do get to 100%, you haven't done anything about the
authoritative servers. Or the other protocols, like NTP, Chargen, etc.
near term, transit providers who do BGP prefix-list, could use same
prefix-list for ACL, segmenting spoofing domains. It's very high pay-off,
couple ports configured, whole downstream branch isolated into its own
spoofing domain, able to just attack targets inside same domain.
I see this as a form of BCP38, but imposed on networks by their transit
providers, rather than done voluntarily. It would be great if it could
work, but I have doubts due to asymmetric routing announcements intended
for traffic shaping.
mid term, transport area in IETF. DNS, NTP, SNMP, chargen et.al. could
trivially change to QUIC/MinimaLT or compared, getting same 0 RTT penalty
as
UDP without reflection potential.
I'd expect that to take 20 years or more. Even if new standards are
defined, the old servers will only be removed when they physically fail.
My crazy proposal: get international agreement that sending spoofed packets
is illegal, then trace their sources. Tracing the sources just requires
transit providers (or other large networks) to collect and analyze netflow,
but that may end up being as infeasible as changing the global legal
system. 
Damian
I see this as a form of BCP38, but imposed on networks by their transit
providers, rather than done voluntarily. It would be great if it could
work, but I have doubts due to asymmetric routing announcements intended
for traffic shaping.
Yes, I should have specified 'BCP38 in access networks' as being completely
unrealistic.
(We do BCP38 on all ports and verify programmatically, but I know it's not at
all practical solution globally for access).
ACL in transit port is completely harmless, no announcements are needed for
traffic to be accepted. There are very modest amount of transit ports globally
and each port will create segmentation to the spoofing domains having
immediate, significant effect on benefits of spoofed attacks.
RPF obviously is non-starter for reasons you stated.
I'd expect that to take 20 years or more. Even if new standards are
defined, the old servers will only be removed when they physically fail.
It would have to be carried over UDP initially and that support probably would
have to live for 20 years. But new-l4-over-udp version could be deployable
rapidly.
I'm very optimistic that if we'd have useful L4 for DNS, significant portion
of relevant DNS servers could be upgraded rapidly to support it. We may be
able to use existing data for this, how many servers went from DNS source port
to random source port to add entropy to reduce poisoning attack chance?
Good portion of end users are running w7, w8, osx updating itself
automatically, so end-user support could come automatically and not require
action from users. phones, tablets etc have short upgrade cycles anyhow.
Native-udp port could then be policed heavily, making reflected attacks
pay-off poor and motivates rest of the users to take actions needed for new
l4.
My crazy proposal: get international agreement that sending spoofed packets
Agreed, crazy.
I wouldn't say trivial, but QUIC and MinimaLT are hopefully the future.
The near future, I hope!
For now I'd just like to mention that OpenNTPD, from the OpenBSD
project, is immune to the kind of large NTP amplification attacks now
being discussed. It's certainly a good fit for some
organizations/setups.
Nicolai
BCP38 will only ever get implemented if governments and ruling 'net bodies force deployment. There's otherwise very little benefit seen by the access network providers, since the targets are other orgs and the attacks are happening in a different backyard.
Anti-spoofing is eminently practical for most types of access network topologies using even slightly modern equipment; uRPF, ACLs, cable IP source verify, DHCP Snooping (which works just fine with fixed-address hosts), PACLs/VACLs, et. al. are some of the more prevalent mechanisms available.
In point of fact, anti-spoofing is most useful and most practical at the access-network edge, or as close to it as possible.
We must disagree on definition of practical. Maybe if I'd reword it realistic
we might be closer.
It is not going to happen, the most suspect places are places where it's going
to be most difficult to get, either fully on autopilot with no technical
personnel capable or having the power to make the change or ghetto gear with
no capability for it.
The longer we endorse fantasy the longer it'll take to promote practical
solutions. There is nothing near consensus that IP transit should or even can
be ACLd, but it's really simple and I'm happy to volunteer my time with any
network wishing to implement it.
Very modest amount of ports will produce significant reduction in spoofing
pay-off.
That may well be the case, unfortunately; my point was that at or near the access edge is the most *technically* and *topologically* feasible place to implement antispoofing mechanisms, as you indicated in your reply.
Oh, yes, it'd obviously be trivial to change DNS to use a different
transport. This is shown by the massive success of getting EDNS0
universally deployed in under 10 years. Right?
A
pretty easy to believe that quic would be helpful right? especially if
you were interested in:
1) keeping resource utilization down/same on dns servers
2) rtt and latency impacts of extra rtt on upper layer protocols
3) the Xmillions of embedded devices that end users rely upon for
dns in their homes
seems totally feasible.
-chris
Perhaps the problem with EDNS0 is exactly its backward compatibility. A
parallel protocol adopted by the usual suspects of authoritative and
recursive names servers that at some point becomes required for query
volumes larger than x qps could account for most of name resolution on the
planet in much less than 10 years.
Rubens
pretty easy to believe that quic would be helpful right?
Yes. It's also pretty easy to believe that ditching DNS completely in
favour of something without 8 billion warts would be helpful.
seems totally feasible.
Certainly, it would be possible to standardize it. Whether it would
be "trivial" to get it deployed is quite a different matter. The
evidence to date is that there is a very, very long tail in any change
having to do with the DNS. We are still, to this day, fighting with
sysadmins who are convinced that firewall rules on TCP/53 are
perfectly reasonable, even though DNS _always_ used TCP.
People who believe there are going to be easy fixes to the issues
coming from DNS are deluding themselves.
A
I totally agree... I was actually joking in my last note 
sorry for
not adding the ":)" as requisite in email.
So... what other options are there to solve the larger problem of:
"Some service is running on a public host, and it can be used to
attack a third party"
where in all of these cases the third party is someone who's address
has been spoofed in the src-address of a packet.
-chris
I totally agree... I was actually joking in my last note
not adding the ":)" as requisite in email.
I'm sorry my humour is now so impaired from reading 1net and other
such things that I didn't figure it out!
So... what other options are there to solve the larger problem […]
If I knew, I'd run out an implement it rather than talk about it!
A
>
> I totally agree... I was actually joking in my last note
> not adding the ":)" as requisite in email.I'm sorry my humour is now so impaired from reading 1net and other
such things that I didn't figure it out!> So... what other options are there to solve the larger problem […]
If I knew, I'd run out an implement it rather than talk about it!
A
Well. These reflection attacks have something in common. The big ones
(chargen, dns, ntp) are all IPv4 UDP. And these are all *very* big.
I hate to throw the baby out with the bathwater, but in my network, IPv4
UDP is overstaying it's welcome. Just like IPv4 ICMP in 2001 - 2003, its
fate is nearly certain.
I hope QUIC does not stay on UDP, as it may find itself cut off at the
legs.
CB
I won't speak about the other protocols, but I encourage you to turn
off DNS using UDP over IPv4 in your network and report back to us all
on how that works out. You may not be able to do it by email,
however.
Best regards,
A
> I hate to throw the baby out with the bathwater, but in my network, IPv4
> UDP is overstaying it's welcome. Just like IPv4 ICMP in 2001 - 2003,
its
> fate is nearly certain.
I won't speak about the other protocols, but I encourage you to turn
off DNS using UDP over IPv4 in your network and report back to us all
on how that works out. You may not be able to do it by email,
however.
I white listed google and facebooks auth servers, so its cool.
CB