I was working on getting Data Filtering to block specific DNS requests with no resolution.
So, I am creating a Custom Application for DNS with a Pattern matching, which is partially working.
Under Objects/Applications/("Added applications, DNS DDOS, DNS DDOS1, OUR DNS").
Configuration: Category = "general-internet", Subcategory = "internet-utility", Technology = "client-server", Parent App = "dns" Risk = "3"
Signatures, Added first two (OR condition) with the following:
Context = "dns-req-section", Pattern = "ddostheinter.net" (Not sure if it is parsing the ".net" portion of this string)
Context = "dns-req-section", Pattern = "directedat.asia" (again not sure of the parsing after the period)
Set to a Security rule, and it blocks these specific DNS requests to our firewall.
So, I am attempting to set up to only ALLOW legitimate requests for OUR public services (OUR DNS), and having issues.
Context = "dns-req-section", Pattern = "ab.cdefgh.ij.us", returns error (I have obscured our legitimate DNS domain)
"-> signature -> DNS -> and-condition -> And Condition 2 ->
or-condition -> Or Condition 1 -> operator -> pattern-match
-> pattern 'ab.cdefgh.ij.us' is invalid. pattern must be at least 7
I have also tried several iterations, including:
'.*(ab.cdefgh.ij.us)' - returns same error as above.
'ab\.cdefgh\.ij\.us' - No error, but applying to a Security Rule, it does NOT match any traffic on this rule, although it (this DNS traffic) IS allowed in another Security Rule further down...
'.*(ab\.cdefgh\.ij\.us)' - same as above, no error, but not matching Rule.
Well, I THOUGHT it was all working, but still having issues. I believe the answer is in using the HEX Strings, but the format is giving me fits!
As long as the Pattern Matching hits for the ENTIRE DNS Request, it seems to work, (I put in --- .*\x 69 73 63 03 6f 72 67 \x ---) for "isc.org", which is EXACTLY 7 bytes, and it is now blocking these requests (Another DDOS URL).)
So, I am trying to set up a Pattern Matching for a PORTION of a string inside a DNS request, but the rule fails to match the traffic. (per packet captures).
Obfuscated, but if I put in patterns to match these:
it.really.is.nt 69 74 02 72 65 61 6c 6c 79 02 69 73 02 6e 74
IT.REALLY.IS.NT 49 54 02 52 45 41 4c 4c 59 02 49 53 02 4e 54
I get matching hits on DNS requests that include ONLY that exact string, anything that prepends or appends to this does NOT hit this rule. (ie: www.it.really.is.nt, or MX1.it.really.is.nt)
A couple of options I have tried (only showing the lower-case attempts, but had the upper-case also, under two Custom Applications, and two Security Rules):
\x 69 74 02 72 65 61 6c 6c 79 02 69 73 02 6e 74 \x
.*\x 69 74 02 72 65 61 6c 6c 79 02 69 73 02 6e 74 \x
.*(\x 69 74 02 72 65 61 6c 6c 79 02 69 73 02 6e 74 \x)
.*( \x 69 74 02 72 65 61 6c 6c 79 02 69 73 02 6e 74 \x )
I also tried to shorten this to just the "really.is" portion, upper and lowercase, with the same type of results (exact string match, any "extra" characters in the DNS request do not hit the rule).
After I clear out my two other open Tech support cases, I am going to open a case for this issue. I am getting WAY too frustrated waiting for the 10-minute "commit" 20-30 times per day!
EDIT: Another question: WHAT are valid HEX strings for a "period"? I have seen 02, 03, and 06 in my captures,
Message was edited by: Russel Smith
Just wanted to close the loop on this "issue", the RegEx strings that were suggested above DO WORK, I found via Tech Support that the DEFAULT Program will Over-Ride the Custom Programs, even if the Security Rules are set correctly.
Example: We were blocking Custom DNS RegEx strings for DDOS blocking, and allowing all other DNS (Worked great)
We changed our Security Rules to ALLOW only OUR DNS, then set the DNS rule (default program) to block further down, and it blocked ALL DNS requests. This is due to the APPLICATION inspection taking place BEFORE the Security Rule processing, and with DNS (default) being blocked, it NEVER looked at the Custom DNS applications, and also ignored all the DNS security rules..... Seems kind of a broken thought/engineering process to me...
Our fix (via tech support): Created the Custom Application to ALLOW OUR DNS, then created ANOTHER Custom Application that will match for ALL DNS requests . (Regex that looked for this information: "identifying the two bytes for number of Questions, Answers, Authority, and first byte of Additional RRs" (\x 00 01 00 00 00 00 00 \x). We then allowed our DNS Custom Application, and blocked this new Generic DNS custom application, and at the bottom of our Security Rules allow the default DNS application. (This is now getting zero hits).
Thanks for all the assistance with this...
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!