strategies to mitigate DNS amplification attacks in ISP network

Mark Andrews marka at isc.org
Wed Dec 2 00:39:38 UTC 2015


Deploy DNS COOKIES.  This allows legitimate UDP traffic to be
identified and treated differently to spoofed traffic by providing
the equivalent to a TCP handshake but over UDP.

This is currently in IETF last call but the code points are assigned
and implementations are available.  Ask your nameserver vendor for
this today.  Ask your OS vendor for support.

https://tools.ietf.org/html/draft-ietf-dnsop-cookies-07

Mark

In message <DM3PR0601MB2011982419777A0C7960842FF90F0 at DM3PR0601MB2011.namprd06.p
rod.outlook.com>, Michael Hare writes:
> Martin-
> 
> I represent a statewide educational network running Juniper gear that is a qu
> asi-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 d
> st port unreserved bytes > 1400
> 3) on ingress, queuing fragments to high packet loss priority [you better und
> erstand 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 al
> lows 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-Respons
> e-
> > > 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



More information about the NANOG mailing list