strategies to mitigate DNS amplification attacks in ISP network

Michael Hare michael.hare at wisc.edu
Tue Dec 1 17:23:01 UTC 2015


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 at nanog.org] On Behalf Of Martin T
> > Sent: Tuesday, December 01, 2015 11:00 AM
> > To: nanog at 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



More information about the NANOG mailing list