Home / server / Questions / 786621
In Process
Jeff Atwood
Asked: 2016-06-28 21:28:25 +0800 CST

Dealing with NTP reflection attacks in IPTables

  • 772

We're dealing with an NTP reflection / amplification attack at our colocated servers. This question is specific to responding to NTP reflection attacks, and not directed at DDoS in general.

Here's the traffic:

router network traffic graph

It's churning a bit of CPU on our router:

router CPU usage graph

Unfortunately it is not big enough to cause our upstream provider to blackhole the traffic, which means it's passing through to us.

We've used the following rule to block the NTP traffic, which originates on port 123:

-p udp --sport 123 -j DROP

This is the first rule in IPTables.

I searched a lot, and I can't find very much information on how to use IPTables to mitigate a NTP reflection attack. And some of the information out there seems flat out incorrect. Is this IPTables rule correct? Is there anything else we can add, or do, to mitigate a NTP reflection / amplification attack other than contact our upstream network provider?

Also: since these attackers must be using networks that

  • allow spoofing of IP address in packets
  • have unpatched, circa 2010 NTP code

is there any global clearinghouse we can report these IP addresses to, so that they get fixed to stop allowing spoofed packets, and patch their NTP servers?

ddos ntp

3 Answers

  1. Essentially, you're outta luck if the DDoS attack manages to fill whatever pipe you have to the Internet (which is the purpose of any UDP reflection attack -- to fill the pipe). If your upstream link can take 1Gbps of traffic, and there's (say) 2Gbps of traffic total to go down the link, then half of it is going to be dropped by the router or switch that's putting the packets down the link. The attacker doesn't care that half of their attack traffic gets dropped, but your customers do: 50% packet loss in a TCP connection is going to do terrible, terrible things to the performance and reliability of those connections.

    There are only two three ways to stop a volumetric DDoS attack:

    1. Have a big enough pipe that the attack traffic doesn't fill it.
    2. Stop the attack packets before they go down the pipe.
    3. Shift to a different IP address that isn't under NTP reflection attack.

    Blocking them in iptables won't do squat, because by then the attack traffic has already squeezed out the legit traffic and caused it to be dropped on the floor, so the attacker has won. Since you (presumably) don't control the upstream router or switch that is forwarding the attack traffic, yes, you'll have to get in touch with your upstream network provider and have them do something to stop the attack traffic from reaching your network link, whether that be

    • block all traffic on the attack port (not something most ISPs are willing to do on their colo customer access routers, for $REASONS)

    • filter out the source IP addresses of the attack (more plausible, with S/RTBH, but not something that every provider already has available)

    • worst case, blackhole the destination IP address

    Note that blackholing the IP only works if you've got other IP addresses that can continue operating -- if your provider blackholes your only IP address, the attacker has succeeded because you're off the Internet, which is what they were trying to achieve in the first place.

    • 21

  2. I will assume you have a pipe to your ISP which terminates on your own router/firewall. Then behind that router/firewall you have your own machines. The ISP won't block the traffic so you have to deal with it yourself. You want to block the traffic at the router/firewall to stop it hitting the machines behind it while minimising load on the router/firewall.

    Your rule looks right for dropping anything that came from a ntp server on the standard port. Remember if you actually use ntp you may need to poke holes in your firewall rules

    If your firewall uses connection tracking (most do) then you may want to use the "raw" table to drop the packets before they reach the connection tracking machinary.

    iptables -t raw -A PREROUTING -p udp --sport 123 -j DROP

    • 5

  3. It looks like we can report the IPs for NTP abuse (and hopefully, NTP patching) to

    http://openntpproject.org/

    As for reporting networks that allow spoofed IPs, I can't find much:

    Our measurements show that spoofing is still prevalent among approximately 25% of the autonomous systems and netblocks we survey. More importantly, a single entry point for spoofed traffic provides attackers a means to send spoofed traffic to the entire Internet. ISPs can employ filtering [RFC2827] to ensure their outbound traffic is not spoofed.

    Perhaps the only method is to contact the ISP directly?

    • 1