DNS Amplification Attack

noc_soc — Wed, 17 Jul 2013 09:51:21 GMT

http://dnsamplificationattacks.blogspot.com.es/

http://dnsamplificationattacks.blogspot.nl/2013/05/nl-188954825-as57172.html,

In relation to this attack, which is performed a high volume of requests against the DNS, it detects PaloAlto under the signatures:

DNS Queries ANY TWO Brute-force Attack
Microsoft SMTP Service and Exchange Routing Engine Buffer Overflow Vulnerability
This signature function through which we have modified thresholds.
Yet we see that the size of requests is usually greater than 4000 bytes. So we are trying to create a rule that detects UDP requests to port 53 to a size greater than 4000 bytes to lock.

But we do not see how you can create a similar rule or at least detected by the packet size.

Is there any way to create a similar rule.

thanks
Sorry for the google translation

Re: DNS Amplification Attack

UhMayYeah — Wed, 17 Jul 2013 12:04:36 GMT

I don't think we can create a Rule or App based on packet-size.

Have you applied Vulnerability and Anti-spyware profiles to the rule for content inspection..

Are you positive about DNS requests greater than 4kbytes using UDP and not TCP ,as any DNS packet over 512 B should use TCP.

Re: DNS Amplification Attack

mikand — Wed, 17 Jul 2013 22:36:38 GMT

Nowadays you have EDNS which will bypass the old "use TCP if response is larger than 512 bytes".

This is handy when more and more DNS traffic uses DNSSEC which in many cases will result in a response which is larger than 512 bytes. Without EDNS the flow would be:

* Send query

* Get a nack in return (or whatever its called in DNS world)

* Send syn

* Get synack

* Send ack

* Send query again

* Get response >512 bytes in return

* Send finack

* Get ack

* Get finack

* Send ack

Compared to (with EDNS):

* Send query (with EDNS where you inform that you accept UDP at 1280 bytes or smaller (or whatever size you accept)).

* Get response >512 bytes in return

The new "safe" sort of standard is 1280 bytes (which is also the lowest MTU a IPv6 link is forced to support).

That is if you are using bind you can use something like this in your dns-servers:

edns-udp-size 1280;

max-udp-size 1280;

But this will of course be a problem during DDoS specially when the udp can be easily spoofed (since no handshake takes place and there are too many ISPs out there who doesnt properly filter client connections regarding srcip's being used).

The problem is that the attacker spoofs the srcip but now adds a EDNS header informing the dns-server which is being bounced at that the (faked) srcip accepts a 4096 bytes reply (or whatever). Since MTU is often 1500 bytes on the internet this UDP response will of course be over several packets but the point here is that some large query is being performed (for example containing DNSSEC information) which will incorrectly flood the victim (the faked srcip).

Some sources:

http://tools.ietf.org/html/draft-andrews-dnsext-udp-fragmentation-01

If the IPv6 stack does not support IPV6_USE_MIN_MTU, then steps

should be taken to prevent PMTUD occuring. These include, but are

not limited to, setting the MTU of the interface the packets are

being sent over to the minimum IPv6 MTU (1280 bytes), or restricing

DNS/UDP packets to no more than 1280 bytes including IPv6 headers.

http://www.ietf.org/rfc/rfc2671.txt

4.5.1.

Note that a 512-octet UDP payload requires a 576-octet IP

reassembly buffer. Choosing 1280 on an Ethernet connected

requestor would be reasonable. The consequence of choosing too

large a value may be an ICMP message from an intermediate

gateway, or even a silent drop of the response message.

http://tools.ietf.org/html/draft-ietf-dnsind-udp-size-02

1280 bytes of DNS data is chosen as the new default to provide a

generous allowance for IP headers and still be within the highly

prevalent approximately Ethernet size or larger MTU and buffering

generally available today.

An IPv6 server should enable fragmentation on UDP replies. While

fragmentation will not be frequent if the above guidelines are

followed, it may occur on occasion. In principle, IPv6 headers and

options could be huge, resulting in a very large UDP packet even

though the DNS payload is limited, but this should not occur in

practice.

Also take a look at Cisco ASA 5500 Series Configuration Guide using ASDM, 6.3 - Configuring Dynamic DNS [Cisco Adaptive Security Device Manager] - Cisco Systems which summarizes which dns-server supports which size by default.

Regarding if the threat profiles in PA can look at packetsize aswell I have no clue (at least I failed to locate such in the manuals) - but if you for example choose 1280 bytes as max udp-size for incoming dns packets then make sure that your resolvers are setup according to above edns-udp-size and max-udp-size.

topic DNS Amplification Attack in General Topics

DNS Amplification Attack

Re: DNS Amplification Attack

Re: DNS Amplification Attack