StoneBlog.stonesoft.com

Talking about Fingerprint Patterns (signatures) in our IPS, there are some “rule of thumbs” to respect to avoid having the FP eating resources on the sensor.

Computational model used by StoneGate IPS Sensor to render fingerprints is DFA.

Understanding how the regular expressions in IPS fingerprints affect the DFA used in matching is a bit difficult and is usually based on vague guidelines like “don’t use .* in the middle of a regular expression”.
Rendering the resulting DFA might provide more insight into how things work, and also produces pretty pictures
Here’s a sample rendering of the group DFA “TNS TCP Client Stream”:

Green nodes are normal states, red nodes matching states. The lines represent possible state changes depending on input bytes.

Did you like it? Here’s some more:

Simple regular expression:

(?x) .*abcdefgh| .*12345678

Simple regexp with a .* in the middle (not recommended):

(?x)
.*abcdefgh.*ijklmop|
.*12345678

Regexp with two .* sequences

(?x)
.*abcdefgh.*ijklmop|
.*12345678.*90x11x12x13x14x15

Same with variables instead of .*’s:

(?x)
.*abcdefgh(?{a=1,ignore})|
.*12345678(?{b=1,ignore})|
.*ijklmnop(?{a==1})|
.*90x11x12x13x14x15(?{b==1})

The last two regular expressions do the same thing, but the with 33 nodes in the DFA using variables versus 89 nodes in the .* version.

The .* version also grows quite fast with additional regexp branches unlike the flat DFA with variables.

written by RoarinPenguin - 1,018 views \\ tags: DFA, fingerprint, IPS, regular expression

This quick note allows you to:

• Define the following fingerprint situations that matches to ALL other URLs but the listed ones.
• Add new inspection rule which defines which IP addresses group are allowed to access to defined URLs. All other combinations are terminated.

Note! Variable names must be unigue in each fingerprint that are matched in a same context!

E.g. ‘whitelisted_url_1′, ‘whitelisted_url_2′

1. Create one situation, called whitelist1, structured as follows:
   Context: HTTP Client Stream
   RegExp:
   (?x)
   .*Host:(?>[^\n]*yle.fi(?{whitelisted_url_1=1,ignore}))|
   .*Host:(?>[^\n]*mtv3.fi(?{whitelisted_url_1=1,ignore}))|
   .*Host:(?>[^\n]*hs.fi(?{whitelisted_url_1=1,ignore}))|
   .*Host:(?>[^\n]*cnn.com(?{whitelisted_url_1=1,ignore}))|
   .*Host:(?>[^\n]*bbc.com(?{whitelisted_url_1=1,ignore}))|
   .*\n\n(?{whitelisted_url_1==0})|
   .*\r\n\r\n(?{whitelisted_url_1==0})
2. Create another situation, called whitelist2, structured as follows:
   Context: HTTP Client Stream
   RegExp:
   (?x)
   .*Host:(?>[^\n]*sampo.fi(?{whitelisted_url_2=1,ignore}))|
   .*Host:(?>[^\n]*op.fi(?{whitelisted_url_2=1,ignore}))|
   .*Host:(?>[^\n]*norndea.fi(?{whitelisted_url_2=1,ignore}))|
   .*Host:(?>[^\n]*stonesoft.com(?{whitelisted_url_2=1,ignore}))|
   .*\n\n(?{whitelisted_url_2==0})|
   .*\r\n\r\n(?{whitelisted_url_2==0})
3. Create two groups of machines, called Group1 and Group2.
4. Create an Access rule (and if needed a NAT rule for FW) to allow HTTP with deep inspection ON for both groups Group1 and Group2.
5. Create two separate inspection rules as follows:
   Situation     Source     Dest     Protocol     Action
   whitelist1    Group1       ANY     ANY           Terminate
   whitelist2    Group2       ANY     ANY           Terminate
6. Install policy

written by RoarinPenguin - 1,219 views \\ tags: fingerprint, regular expression, URL filtering

This document exploits the power within StoneGate IPS Fingerprinting RegExp to allow “Fingerprint-based anomaly detection”.

This is somewhat different from regular IDS/IPS devices, since they normally try to detect something defined as a fingerprint, while this document instructs to do the exact contrary: in case we know what to expect as “normality”, we ask that everything deviating from that is reported as “anomalous”… and all this using Fingerprinting to allow maximum flexibility.

For additional references about StoneGate IPS Fingerprinting language, you can consult StoneGate IPS Reference Guide available on our public website.

Suppose we have a case where application payload is structured as follows:

• First 8 bytes mixed data we’re not interested in inspecting
• Byte number 9 device type
• 10th to 17th byte device identity
• 18-19th bytes mixed data we’re not interested in inspecting

Definition of normality

We need to check that first 8 bytes contain some sort of data.
We know that device type we’re interested in is a Terminal, and this is defined by the numeric decimal value 6 of 9th byte.
We know that device identity allowed to communicate is defined by numeric ID 90008888 (decimal values).
Packet is 19th bytes in length.
The above statement defines the normality, and need is to alert on everything which is deviating by normality.
Solution is to structure the sensor fingerprint as follows:

---------------------------------------------------------------------

(?x)

# check the identity for Terminal ==> 6

.{8}6

# or if the identity is not the desired

90008888(?{legitimate=1,ignore})|

.{19}(?{legitimate==0})

---------------------------------------------------------------------

Fingerprint Structure Explanation

At the beginning of fingerprint we use (?x) to tell to fingerprint processor not to consider text after # sign nor linefeeds or space in the matching process.

This allows usage of comments in fingerprint structure, empowering readability.

Without comments, the fingeprint above would be:

.{8}690008888(?{legitimate=1,ignore})|.{19}(?{legitimate==0})

We start fingerprint asking to check first 8 bytes for whatever content.
The dot (.) checks any content (including null characters) and the following number in curly braces tells to repeat the previous action n times (thus for the first 8 bytes).
After the curly braces we put the content to be checked in either decimal (6) or hexadecimal (\x06) notation.
Then we follow with the string to check from 10th to 17th byte.
If we find a match, we set a variable (we called this legitimate) to 1.
Then we use a special extension with keyword ignore.
The effect is that if it finds a match it does not trigger any response until another valid match is found.

Then comes the magic!
Using an OR condition (| sign) we insert a new matching pattern to check that in first 19 bytes there is some sort of content (this will always match if packet is proper).

This latter condition will match only if value of legitimate variable is 0, which is in contrast with first part of the fingerprint.
The final effect is that fingerprint as a whole will match if and only if:
1. First 8 bytes are containing any value
2. String from 9th to 17th byte is different from 690008888 (because value of legitimate remains 0)
3. First 19 bytes of payload are existing and are containing whatever value

Three lines above define the deviation from the normality we defined, causing the fingerprint to match and a proper action (alert, drop, reset, blacklist, etc.) to be taken.

written by RoarinPenguin - 699 views \\ tags: anomaly detection, fingerprint, IPS, regular expression