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?
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
Creating the Patterns
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.
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!
You're welcome, glad it worked for you!
In case you need it, the pattern I'm using is broken down like so.
\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
\x02 72 75 00 00 01 00 01\x
02 - Indicates the TLD is 2 bytes
72 75 - ru
You've got the rest.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!