amuck-landowner

NTP - the new DDOS amplifier

wlanboy

Content Contributer
We all know about DNS amplification attacks (open relays) but now time servers are used to DDOS hosts too.

The Network Time Protocol is used to synchronize computers across the world against centralized servers to within a fraction of a second of coordinated universal time (UTC).

It uses the port 123 on UDP.

NTP is susceptible to main-in-the-middle attacks - just spoof the source.

NTP amplification attacks work quite simple. Ask for the latest clients and get back about 600 ip addresses of the latest connections:


ntpdc -n -c monlist <ip of ntp server>

The request packet is 234 bytes long. A busy server with the maximum of 600 addresses would send 100 packets (6 addresses per packet) for a total of over 48kb - that's a 200x amplifier.

NTP from version 4.2.7 on does not have the command "monlist".

If you don't have access to this version you can disable monlist:


nano /etc/ntp.conf

and add following line:


disable monitor

Another solution would be the NTP Autokey Authentication.

And there is allready a project scanning for open NTP servers: OpenNTPproject.org.
 

texteditor

Premium Buffalo-based Hosting
Some clown has been using this technique over the past 2-3 weeks to pummel the hell out of some larger torrent trackers and allegedly Riot/Steam/EA, and it's getting old
 

Magiobiwan

Insert Witty Statement Here
Verified Provider
Perhaps we (in general) should first take care of the NTP issue, then after that take care of anything ELSE with large amplification? DNS is mostly taken care of. NTP is just now getting big. What's next?
 

Francisco

Company Lube
Verified Provider
We've been seeing a lot of this.

I had to make adjustments in both of our DC's to address this the other week.

Francisco
 

maounique

Active Member
Fortunately there are not enough NTP servers out there and such an abuse WILL get noticed since most are run by professionals. There are far fewer than DNSes which are in each crappy hosting panel on the market as well as in many templates. 

It will certainly be easier to contain this outbreak.
 

kaniini

Beware the bunny-rabbit!
Verified Provider
Perhaps we (in general) should first take care of the NTP issue, then after that take care of anything ELSE with large amplification? DNS is mostly taken care of. NTP is just now getting big. What's next?
Anything which uses UDP in an unauthenticated manner is vulnerable to reflection attacks.
 

wlanboy

Content Contributer
Perhaps we (in general) should first take care of the NTP issue, then after that take care of anything ELSE with large amplification?
Hopefully everyone will take a look at his/her own subnets.

Fortunately there are not enough NTP servers out there and such an abuse WILL get noticed since most are run by professionals.
I thought that too. But look at the numbers at OpenNTPProject.

Not the official Pool numbers.

There is a nmap script available that lists all ips that can be used for an attack - if you do not trust OpenNTPProject.

But every vps provider should run that on his hosts.
 

Kris

New Member
We've been suggesting the following, after seeing attacks on the same /24 subnet (scanning networks)

We now scan nightly and send out instructions on how to close your open NTP server or DNS resolver should you have one, a lot of PBX distributions come with NTP open by default.

Start by editing : /etc/ntp.conf with your preferred text editor. 

Next, add the following line to to /etc/ntp.conf to restrict access and ignore inbound requests:


restrict default ignore

You can now restart the ntp daemon by issuing the following command:

/etc/init.d/ntpd restart

Quick Edit: Check if your server is open by running the following command:


ntpq -pn IP

If the server replies at all with a list of IPs / a line that contains 'jitter', it's open. It should time out, not respond, etc. 

Cheers, should save people some BW and network quality 
 
Last edited by a moderator:

peterw

New Member
Perhaps we (in general) should first take care of the NTP issue, then after that take care of anything ELSE with large amplification? DNS is mostly taken care of. NTP is just now getting big. What's next?
Anything which uses UDP in an unauthenticated manner is vulnerable to reflection attacks.
SNMP (used) DNS (used) NTP (used).

Not used: RADIUS “access request” with “access reject” response. Don't read about the "chargen" IDENT service either.
 

kaniini

Beware the bunny-rabbit!
Verified Provider
SNMP (used) DNS (used) NTP (used).

Not used: RADIUS “access request” with “access reject” response. Don't read about the "chargen" IDENT service either.
Shh... just because the kiddies haven't discovered RADIUS yet doesn't mean they're not going to. ;)

I see chargen flooding all the time.  It was enough of a problem that we set an ACL on our edge network in Dallas to block it there.

Edit: Additional thought -- really, we should ditch both TCP and UDP and just switch everything to SCTP already.  SCTP offers both stream and message-oriented networking, and thusly could replace all TCP and UDP applications with minimal effort.  Not to mention the other advantages, like decoupling sessions from the IP layer (so you can switch from wifi to 3G and not have a connection drop)...
 
Last edited by a moderator:

Francisco

Company Lube
Verified Provider

maounique

Active Member
Neah, DNS ampliffication attacks were 300 gbps and NTP "benefits" from having many servers publicly listed while the open  resolvers in every crappy hosting panel out there are hard to come by without scans.

It is also easy to solve, the NTP servers have listed contact addresses in many cases.

This will likely pass very fast, they will be fixed in a couple of weeks.

We are still fixing open recursive resolvers in our network, people put them up every day :(
 

marlencrabapple

New Member
I'm still dreading the day I have to deal with a regular DDOS attack. I can't even imagine having to figure out how to deal with something on this scale.
 

FLDataTeK

New Member
Verified Provider
I came across this script the other day to scan for open resolvers on your OpenVZ nodes.  It works pretty good.


#!/bin/bash
echo "Simple script to scan all OpenVZ containers for open DNS resolvers"
echo "For web-based testing use http://openresolver.com"
for ip in `vzlist -H | awk '{print $4}'`;
do
OUT=$(dig +short +tries=1 +time=2 test.openresolver.com TXT @$ip | grep open-resolver-detected)
if [ -z "$OUT" ]; then
echo "$ip is not an open resolver"
else
echo "$ip IS an open resolver!"
fi
done

Hopefully it will help someone out.
 
Top
amuck-landowner