Drop a certain type of inbound DNS query

[jgardner]

We have a MS DNS server that handles some (very few) reverse PTR records...  We consistently see people trying to use this server for reflection attacks - whereby they perform a recursive forward lookup for the same domain over and over (likely spoofing the source IP to try and flood their target); our DNS server dutifully respond with a list of the root-hint servers (but we have since removed all root-hint servers from this server), or now a failed query response.  Because this is a MS DNS server, we are limited on how to handle these forward lookup requests.  We have recursion disabled, no forward lookup zones...  But we are still responding for the (probably spoofed) requestor.

We have implemented DoS protections to discard based one source and max concurrent session count, but would like to drop this unwanted traffic altogether.

My dilemma: Is there a way with the PAN to construct a rule that would drop DNS *forward* lookup queries from any source?  All we care about are the reverse PTR queries, and would be happy to never let any forward lookups reach our DMZd DNS server.

I'm new to Palo Alto, so I don't know if this is or isn't possible, but it seems it should be a simple task to peek inside that UDP traffic to drop anything with the targeted UDP DNS query type of type A.  Any PAN ninjas out there who can help me with this?

[lwheelock]

My first thought here is to create a custom vulnerability object using a pattern-match on the query. Then make the default action to drop the packet and apply the vulnerability object to a rule (through a new profile or non-default profile). However, custom vulnerability objects using pattern-matching require 7 fixed bytes of data. For example, a DNS query for record type A class IN only contains 4 bytes (0x00010001) in the "dns-req-section" context. So we have a problem, we don't have enough data to pattern-match against for specific record type.

Question: Can we use bytes immediately before or after the data we care about to help us out? Maybe. The A record request would typically not contain additional RRs (at least none we can reliably pattern match) so after the query, there is no data to match on. We could match on data before the type A class IN, but then we have to know what the actual query would be (ie. the host, subs, domain, and tld.) There is a compromise if you wouldn't be opposed to some tedium. Within the custom vulnerability object you can create multiple signatures, each that include just the common TLDs (com, org, gov, info).

There is a fairly detailed write-up of creating custom threat signatures and I'll also provide an example: Creating Custom Threat Signatures

Creating the Object

1. On the device or Panorama go to 'Objects' -> 'Vulnerability' under custom objects. Click 'Add'
2. Give it a Threat ID, Name, Comment etc. I'd just be sure to make the severity 'high' or greater and select 'Drop Packets' as the default action.
3. Click on the Signatures tab. Standard is what you want.
4. Click Add to add a new signature

Creating the Patterns

1. You'll want it to be 'Transaction' based and the order shouldn't matter since I'd create 'OR' conditions for different TLDs
2. Add Or Condition (for .com A record queries)
   1. Operator - pattern-match
   2. Context - dns-req-section
   3. Pattern - \x03636f6d0000010001\x
3. Repeat step 2 for other TLDs you want to include. Make sure they are 'Or' conditions and not 'And' or it'll never trigger.

This is a 9 byte pattern and if you only care about PTR records making it passed, this shouldn't trigger on false positives. Anyone else using this might want to put it in 'alert' mode and enable packet capture to make sure it doesn't trigger. You should be able to create multiple 'OR' conditions for the .org .info .gov etc domains in the same object. I didn't test that though. My splunk guy gets mad when I shovel a bunch of new logs into the indexer without telling him

Hope this achieves what you want.

[jgardner]

Thanks!  This looks promising...  as I'm trying to understand the pattern, what should the pattern be for a .ru domain query?

[jgardner]

Just wanted to follow up to let you know this worked for the problem I am experiencing.  At this time, the offensive queries are for the same FQDN, so we were able to make a custom vulnerability addressing that FQDN and drop it - worked like a charm. 

Although, it would be nice to be able to drop all Type A queries...  but as you mentioned, this doesn't seem possible.

Thanks again for your help!

[lwheelock]

You're welcome, glad it worked for you!

In case you need it, the pattern I'm using is broken down like so.

.com

\x03 63 6f 6d 00 00 01 00 01\x

03 - Indicates the TLD is 3 bytes

63 6f 6d - com

00 - end of host query

00 01 - A record

00 01 - class IN

.ru

\x02 72 75 00 00 01 00 01\x

02 - Indicates the TLD is 2 bytes

72 75 - ru

You've got the rest.