IPS Custom Signatures

Traffic Analysis Method	Cisco IPS Inspection Engines
Packet header matching	Atomic
Packet content matching	Atomic
Stateful content matching	String
Protocol decoding	Service
Rate analysis	Flood
Traffic correlation	Sweep
Event correlation	Meta

Creating Custom Signature Guidelines:




Step 1. Identify what the network attack or exploit is going to look like. This means getting a sample or a description of the network traffic that will be generated by this attack.

Step 2. Create a custom signature that is looking for the exact traffic pattern or network traffic that is being generated by this attack.

Step 3. Test the signature in a nonproduction network environment, to verify that this signature actually works and matches on the malicious traffic it is intended to match on.

Step 4. Implement the tested signature in a production environment, but do not use the aggressive actions that are available such as deny attacker. The purpose here is to identify any false positives that might arise before we start denying innocent traffic. If the false positives do arise, we would want to tune the signatures that we’ve created until the false positives, and/or false negatives, are eradicated.

Step 5. After we know that the signature is working and that false positives and false
negatives are not occurring, we can then assign the appropriate action to the
signature as an IPS response, such as deny attacker.


   Selecting Criteria to Match

■ Specific information that would be found in the protocol headers.
■ Data patterns, found virtually anywhere in the packet or session.
■ Thresholds and counters that can be used across multiple packets.
■ Correlation to detect complex attacks, such as three individual signatures firing off within a short time frame, could represent one custom signature to indicate that the attack is under way. The meta engine would be used for a signature like this.


   Regular Expressions

Regular expressions are a way to communicate or describe patterns inside a packet, and
are quite often used when creating application layer rules for payload matching.
The benefit of using a regular expression is that it is an efficient way to describe a string of
text or patterns that can have many variations. If we did not use regular expressions, we might
have to create dozens of signatures to match a single string of text, based on its containing uppercase
or lowercase characters, spaces, and so on. By using regular expressions, we can use
special characters to represent variables inside the string of text that we were looking for.

Symbol	Meaning
?	Repeat 0 or 1 times
*	Repeat 0 or more times
+	Repeat 1 or more times
{x}	Repeat exactly x times
period (.)	Any one character except \n or \t
[abc]	Any character listed
[^abc]	Any character not listed
[a-z]	Any character listed inclusively in range
|	OR of two regular expressions
\	This allows specifying a character that would otherwise be interpreted as special. It means take the next character literally, and that the next character should not be thought of as being any type of metacharacter.

Examples:

To Match	Regular Expression
Hacker or hacker	[Hh]acker
Either hot or cold	hot|cold
Hacker using any case	[hH][aA][cC][kK][eE][rR]
Either hot or cold using any case	[hH][oO][tT]|[cC][oO][lL][dD]
Variations of bananas, banananas, banananananas	Ba(na)+s
moon or soon	(m|s)oon
Cisco or Francisco or csco	[Cc]?sco

There are three ways of creating this signature:
■ Using the signature wizard and the specific engine to use.
■ Using the signature wizard and not specifying the specific engine.
■ Creating the new signature from scratch, without using any wizard.


Each of these methods includes configuration of the same general elements:
■ The name and number of the signature
■ The matching criteria that this signature will use or the matching network traffic
■ The Signature Fidelity Rating and Attack Severity Rating
■ Optionally the event counts (how many times to see the match) before triggering the signature match and summarization settings