nanog mailing list archives

RE: strategies to mitigate DNS amplification attacks in ISP network


From: Michael Hare <michael.hare () wisc edu>
Date: Tue, 01 Dec 2015 17:23:01 +0000

Martin-

I represent a statewide educational network running Juniper gear that is a quasi-enterprise.  I think efforts depend on 
size and type of network.  We are testing an approach that involves;

1) whitelisting known local resolvers, well behaved cloud DNS resolvers. 
2) on ingress, policing non-conforming traffic that matches UDP src port 53 dst port unreserved bytes > 1400
3) on ingress, queuing fragments to high packet loss priority [you better understand how fragments are used in your 
network before doing this]
4) If you have Juniper gear look into prefix-action
5) RTBH if required

This obviously doesn't work on the core of the internet.

Other good tips: 
* strengthen [anycast] your local DNS resolvers and consider a scheme that allows you to change their outgoing address 
on the fly.
* push [some] of your external authoritative DNS to the cloud.

-Michael

-----Original Message-----
From: NANOG [mailto:nanog-bounces () nanog org] On Behalf Of Martin T
Sent: Tuesday, December 01, 2015 11:00 AM
To: nanog () nanog org
Subject: strategies to mitigate DNS amplification attacks in ISP network

Hi,

as around 40% of ASNs allow at least partial IPv4 address spoofing in
their network(http://spoofer.csail.mit.edu/summary.php) and there are
around 30 million open-resolvers(http://openresolverproject.org/) in
the Internet, then DNS amplification traffic is daily occasion for
ISPs. This in probably mainly because RPF checks and DNS
RRL(https://kb.isc.org/article/AA-01000/0/A-Quick-Introduction-to-Response-
Rate-Limiting.html)
are not ubiquitously implemented, recursive requests without any ACLs
in DNS servers are often allowed, it requires little effort from
attackers point of view and is effective attack method. Unfortunately,
there seems to be very limited number of countermeasures for ISPs. Few
which I can think of:

1) higher capacity backbone links - I'm not sure if this can be
considered a mitigation method, but at least it can help to affect
smaller amount of customers if traffic volumes are not very high


2) rate-limit incoming DNS traffic flows on peering and uplink ports -
here I mean something similar to iptables "recent"
module(http://www.netfilter.org/documentation/HOWTO/netfilter-
extensions-
HOWTO-3.html#ss3.16)
which allows certain number of certain type of packets in a configured
time-slot per IP. However, such functionality is probably not common
on edge or backbone routers.


Tracking the packet state does definitely not work because state table
should be synchronized between all the routers in the network and
again, this requires Internet-routers to have stateful firewall
functionality. In addition, one also needs to allow new DNS
connections from Internet to its network.
If one simply polices incoming DNS traffic on uplink and peering
ports(for example if baseline DNS traffic is 5Mbps, then policer is
set to 50Mbps), then legitimate customers DNS traffic is also affected
in case of actual attack occurs and policer starts to drop DNS
traffic, i.e. policer has no way to distinguish between the legitimate
and non-legitimate incoming DNS traffic.


Am I wrong in some points? What are the common practices to mitigate
DNS amplification attacks in ISP network?


thanks,
Martin


Current thread: