
Vulnerable NTP Servers Closing Down - philip1209
http://blog.cloudflare.com/good-news-vulnerable-ntp-servers-closing-down
======
nknighthb
If you'd like to minimize the number of (non-amplified) packets your
previously-vulnerable server is spitting out, there's a simple firewall rule:
Block requests to port 123 from source port 80.

Heck if I know why, but something like 2/3rds of the attack packets coming in
have a source port of 80, which no sane NTP client would be using.

This plus a per-ip 15-packets-in-20-seconds rule almost eliminates remaining
illicit traffic.

~~~
codexon
They have it set to port 80 because they are attacking a service at port 80.

If there is a service listening there it will cause the packet buffers to
overflow if the server doesn't drain it fast enough long before you flood
their bandwidth capacity.

They could easily attack other ports.

~~~
nknighthb
1) UDP port 80 is not widely used. NTP packets directed at port 80 will not
affect webservers, which use TCP port 80.

2) There are way too many different IPs being attacked on 80 for this to be a
targeted attack on a particular odd deployment.

~~~
pixl97
Is this just a side effect of a common script/tool being used?, or I wonder if
enough firewall rules do stupid things like "Allow 80 Both (tcp|udp)" that it
was an effective means of increasing the efficacy of the attack?

~~~
nknighthb
I'm sure it's some common script/tool/service, but there's either something
entirely non-obvious going on, or the person responsible just doesn't know
what they're doing. Not unusual for scriptkiddies.

Big-boy firewalls I'm familiar with don't have a single command for doing such
a thing, since it won't match their state machine (being obvious nonsense),
and the people managing them are generally unlikely to set the weird multiple
rules necessary to get such a behavior.

Consumer GUIs sometimes make such rules easy for the clueless to create, but
not many NTP servers are going to be behind such rules. Gaining access to that
handful of servers will be a net loss because of the relative ease with which
your packets can be filtered by even slightly clueful upstreams.

Against DDoS targets, you have a similar issue. Targets will generally be
servers on some sort of professional link that isn't heavily filtered by the
provider (and if it were, again, this is an unlikely set of rules for a pro to
create), so the packets will at least make it to the "end-user" equipment
before hitting a firewall with such an odd rule, at which point you're already
hitting the target's actual bottleneck (their uplink).

------
kevinbowman
Warning: the graph shown doesn't start the y-axis at 0. Had me briefly
wondering if the problem had been eradicated and reoccurred.

~~~
mh-
and the x-axis represents the future..? dates in March 2014

~~~
eastdakota
Our mistake. Should be February. We're fixing and adding in data from the last
couple days.

~~~
mh-
:) thanks for sharing the data

