[Dnsmasq-discuss] strategies to mitigate DNS amplification attacks in ISP network

Lonnie Abelbeck lists at lonnie.abelbeck.com
Wed Dec 2 15:41:32 GMT 2015


Doesn't DNSCrypt https://dnscrypt.org solve the same problem ?

Lonnie


On Dec 2, 2015, at 3:21 AM, Dave Taht <dave.taht at gmail.com> wrote:

> DNS cookies look kind of interesting...
> 
> 
> ---------- Forwarded message ----------
> From: Mark Andrews <marka at isc.org>
> Date: Wed, Dec 2, 2015 at 1:39 AM
> Subject: Re: strategies to mitigate DNS amplification attacks in ISP network
> To: Michael Hare <michael.hare at wisc.edu>
> Cc: "nanog at nanog.org" <nanog at nanog.org>
> 
> 
> 
> 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
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
> 




More information about the Dnsmasq-discuss mailing list