RegEx for specific DNS strings

[ktm530russ]

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.

Working strings:

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
bytes"

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.

[gwesson]

Regular expressions can not be used without a basic 7-byte string first. The period is a wildcard character in a regex, so it is seeing only 2 characters then a regex value.

For your first example, you could use:

ab\.cdefgh\.ij\.us (technically you only need the first 7 bytes, or ab\.cdef to satisfy the requirement, but it will be a much broader match)

That should allow it to work similarly to your first two working domains.

Hope this helps,

Greg

[NGS_SOC]

welcome in the 7 bytes world 🙂

gwesson has right your pattern should works fine with   

Pattern = "ddostheinter\.net"

Pattern = "directedat\.asia"

[ktm530russ]

I am assuming the patterns for the Malware blocking are working, as the period (.) would be found as a wildcard, so the original string would still be read correctly for these, even though the "period/wildcard" could be any character.

As for our DNS domain string, I think there may be an issue with the way I set up the Custom Application, or the Security rule, as one of the configuration attempts (and I do NOT remember which one), was hitting this rule for our inbound WEB traffic requests. I am somewhat confused as this rule was cloned from the MalWare rule, and only the text of the RegEx string was changed. (and traffic allowed on the Security Rule.)

The Custom Application is set up as follows:

Category = "general-internet", Subcategory = "internet-utility", Technology = "client-server", Parent App = "dns" Risk = "3"

Signature = Condition = "OR condition 1", Operator = "pattern-match", Context = "dns-req-section", Pattern = "ab\.cdefgh.ij.us" (This is the latest iteration I am trying, I don't really care about the "period/wildcard" issues near the end of the string at this time...)

I also tried changing the Context to "unknown-req-tcp-payload" and "unknown-req-udp-payload" with no change of status.

I have our Security rule set up for ANY request to EITHER of our two DNS servers, for ANY traffic, with the Custom Application for above.

(again, this Security rule was cloned from the Malware Security rule, then modified for the string and allowing traffic)

Any other suggestions?

[ktm530russ]

I am convinced that ANY pattern matching that includes any wildcards before the 7 character minimum limit does NOT work, even with a valid pattern. I would appreciate ANYONE testing to confirm this.

Set up a Custom Application that mirrors DNS, then add a pattern matching for a specific DNS pattern with few leading characters ("fs.fed.us" maybe?) apply a Security Rule with this application, then run a DNS query to your DNS servers for this domain.

I believe that even with a valid application pattern, and security rule, it will NOT get any hits on the rule... then change that pattern to one that has more than 7 leading characters before any wildcard/periods, it will probably work.

Both of our blocking pattern matches work, because they have over 7 characters before the first "wildcard" period, but our third rule that requires the literal backslash has NEVER worked (I believe that the one random working web DNS request was a misconfiguration elsewhere).

[gwesson]

That is correct. You must have a non-pattern string of 7 characters before the interpreted characters. The exceptions are patterns that are not wildcards or can be interpreted as greedy/lazy. An example of a pattern that is ok is:

[Pp]aloalto

This, though it uses an interpreted string to specify upper or lower case, it is not a broad greedy/lazy repetition or wildcard. You can also do:

.*aloalto.*

Though it starts with .* (0 to infinity characters), you still have a 7-character string as the match. You can NOT use:

Pal.*alto

That has a wildcard in the center of it, and even though there are 7 characters there is not a 7-character string in the match. That's why using "ab.cdefgh.ij.us" fails. It is only 2 characters before an interpreted character. Using "ab\.cdefgh\.ij\.us" works fine because the periods are escaped and are not interpreted.

I am surprised that the 3rd pattern does not work as long as it is properly escaped. If you have an example (even obfuscated) of that, I'd like to see it.

Hope this helps,

Greg

[ktm530russ]

These are some of the iterations that I have tried:

xx.123456.aa.us (fails check, less than 7 characters in Pattern)
xx\.123456.aa.us (creates custom application, but Security Rule never gets a hit)
xx\.123456\.aa\.us (same as above)
xx\.123456\.aa.us (same as above)

.*(xx.123456.aa.us)  (Fails check)
.*(xx\.123456.aa.us) (creates application, Security Rule never hits.)
.*(xx\.123456\.aa\.us) (same as above)
.*(xx\.123456\.aa.us) (same as above)

Any ideas on other ways to try this? Would [Aa][Bb] be interpreted as 2 or 4 characters?

[tmyzw]

Hi,

You can use binary pattern match to detect DNS query because you already experienced that exact character without wildcard is too short to meet PA's requirement which is 7 bytes.

To detect "123456.aa.us", the signature would be like this.

"\x 31 32 33 34 35 36 02 61 61 02 75 73 \x"

Thanks,

Takahiro

[ktm530russ]

I put in the string as shown above, (but with OUR DNS binaries) but it again did not have any hits on the Security Rule. I modified it to include:

.*("\x 31 32 33 34 35 36 02 61 61 02 75 73 \x") and I am getting some weird random hits on the rule (see below). I believe they may be DNS requests on non-standard ports.(I don't have a packet capture of these hits). Still no hits on "real" DNS requests.

I did note on the captures I have been taking that the first "period" (xx.123456)  actually shows up as 06 instead of 02 in the "Bytes" window of WireShark.

I have tried the pattern with both options and no change.

Running a commit at this time, (I really hate waiting 5-10 minutes for every commit!) removing the beginning string section, and the ".*()" encapsulation,  so it will start with "123456" (and hopefully ignore the "xx." portion).

Still using "dns" as the parent application, and "dns-req-section" for the pattern match string Context.

Also added Service "application-default" on the Security rule to force DNS requests to use port 53 (tcp/udp) Maybe too much at once?....

[ktm530russ]

Color me blind, I guess I was getting to close to the issue. (staring at the computer screen for 10 hours doesn't help.)

The Hex string DID work.... AFTER I removed the double-quotations from around the string attempts...

Thank you very much Greg and Takahiro ! 

[ktm530russ]

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

[ktm530russ · Accepted solution]

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...

[craymond]

Thanks for posting the resolution and explanation. I think this will come in very handy.

[ITsince93]

I need to do this for mail.google.com, and for gmail.com... if someone could point me to a resource for converting those FQDNs...  Thanks in advance.