Signature Based IPS Policies and Detection

Understanding IDP Policy Rule Bases

A rulebase is an ordered set of rules that use a specific detection method to identify and prevent attacks.

Rules are instructions that guide detection mechanisms. They specify which part of the network traffic the IDP system should examine to find attacks. A matched rule indicates the detection of an attack in the network traffic, which then triggers the action for that specific rule. The IDP system performs the specified action and protects the network from that attack.

Each rulebase can contain multiple rules. The administrator determine the sequence in which rules are applied to network traffic by placing them in the desired order. Each rulebase in the IDP system uses specific detection methods to identify and prevent attacks. Junos OS supports two types of rulebases—intrusion prevention system (IPS) rulebase and exempt rulebase.

Understanding IDP Policy Rules

Each instruction in an Intrusion Detection and Prevention (IDP) policy is called a rule. Rules are created in rulebases.

Rulebases are a set of rules that combine to define an IDP policy. Rules provide context to detection mechanisms by specifying which part of the network traffic the IDP system should look in, to find attacks. When a rule is matched, it means that an attack has been detected in the network traffic, triggering the action for that rule. The IDP system performs the specified action and protects the network from that attack.

The following sections explain the components that make up IDP policy rules.

• Understanding IDP Rule Match Conditions
• Understanding IDP Rule Objects

Table 1: Service Objects

Item	Name
Any	Allows IDP to match all Transport Layer protocols.
TCP	Specifies a TCP port or a port range to match network services for specified TCP ports. The administrator can specify junos-tcp-any to match services for all TCP ports.
UDP	Specifies a UDP port or a port range to match network services for specified UDP ports. The administrator can specify junos-udp-any to match services for all UDP ports.
ICMP	Specifies a type and code that is a part of an ICMP packet. The administrator can specify junos-icmp-all to match all ICMP services.
default	Allows IDP to match default and automatically detected protocols to the applications implied in the attack objects.

Attack Objects

IDP attack objects represent known and unknown attacks. IDP includes a predefined attack object database that is periodically updated by Juniper Networks. Attack objects are specified in rules to identify malicious activity. Each attack is defined as an attack object, which represents a known pattern of attack. Whenever this known pattern of attack is encountered in the monitored network traffic, the attack object is matched. The three main types of attack objects are described in Table 2.

Table 2: IDP Attack Objects

Attack Objects

Description

Signature Attack Objects

Signature attack objects detect known attacks using stateful attack signatures. An attack signature is a pattern that always exists within an attack; if the attack is present, so is the attack signature. With stateful signatures, IDP can look for the specific protocol or service used to perpetrate the attack, the direction and flow of the attack, and the context in which the attack occurs. Stateful signatures produce few false positives because the context of the attack is defined, eliminating huge sections of network traffic in which the attack would not occur.

Understanding IDP Rule Actions

Actions specify the actions the administrator want IDP to take when the monitored traffic matches the attack objects specified in the rules.

Table 3 shows the actions the administrator can specify for IDP rules:

Table 3: IDP Rule Actions

Term	Definition
No Action	No action is taken. Use this action when the administrator only want to generate logs for some traffic.
Drop Connection	Drops all packets associated with the connection, preventing traffic for the connection from reaching its destination. Use this action to drop connections for traffic that is not prone to spoofing.
Close Client	Closes the connection and sends an RST packet to the client but not to the server.

IPS Event Log Generation

IPS event log generation often happens in bursts and can generate a large volume of messages during an attack. To manage the volume of log messages, the TOE supports log suppression. Multiple instances of the same log occurring from the same or similar sessions over the same period of time. IPS log suppression is enabled by default and can be customized based on the following configurable attributes:

- Source/destination addresses,

- Number of log occurrences after which log suppression begins,

- Maximum number of logs that log suppression can operate on, and

- Time after which suppressed logs are reported.

Suppressed logs are reported as single log entries containing the count of occurrences.

IDP Log Suppression Attributes

Log suppression ensures that minimal numbers of logs are generated for the same event or attack that occurs multiple times. Log suppression is enabled by default. The administrator can configure certain log suppression attributes to suppress logs according to the needs. When configuring log suppression, keep in mind that log suppression can negatively impact sensor performance if the administrator set the reporting interval too high.

The administrator can configure the following log suppression attributes:

• Include destination addresses while performing log suppression—The administrator can choose to combine log records for events with a matching source address. By default, the IDP sensor does not consider destination when matching events for log suppression.

• Number of log occurrences after which log suppression begins—The administrator can specify the number of instances that a specific event must occur before log suppression begins. By default, log suppression begins after the first occurrence.

• Maximum number of logs that log suppression can operate on—When log suppression is enabled, Intrusion Detection and Prevention (IDP) must cache log records so that it can identify when multiple occurrences of the same event occur. The administrator can specify how many log records are tracked simultaneously by IDP. By default, the maximum number of log records that IDP can operate on is 16,384.

• Time after which suppressed logs are reported—When log suppression is enabled, IDP maintains a count of occurrences of the same event. After the specified number of seconds have passed, IDP writes a single log entry containing the count of occurrences. By default, IDP reports suppressed logs after 5 seconds.

Syntax

Hierarchy Level

Custom Attack Properties

Table 4: Custom Attack Properties

Property	Description
severity	Info, Warning, Minor, Major, or Critical. Critical attacks are attempts to crash the server or gain control of the network Critical—Contains attack objects matching exploits that attempt to evade detection, cause a network device to crash, or gain system-level privileges. Info—Contains attack objects matching normal, harmless traffic containing URLs, DNS lookup failures, SNMP public community strings, and peer-to-peer (P2P) parameters. One can use informational attack objects to obtain information about the network. Major—Contains attack objects matching exploits that attempt to disrupt a service, gain user-level access to a network device, or activate a Trojan horse previously loaded on a device. Minor—Contains attack objects matching exploits that detect reconnaissance efforts attempting to access vital information through directory traversal or information leaks. Warning—Contains attack objects matching exploits that attempt to obtain noncritical information or scan a network with a scanning tool. Informational attacks are the least dangerous and typically are used by network administrators to discover holes in their own security system.
attack-type signature	Uses a stateful attack signature (a pattern that always exists within a specific section of the attack) to detect known attacks. Stateful signature attack objects also include the protocol or service used to perpetrate the attack and the context in which the attack occurs. If one knows the exact attack signature, the protocol, and the attack context used for a known attack, select this option.
Pattern	A DFA expression. The following rows summarize DFA syntax conventions. For detailed information, consult a standard source on programming with regular expressions.
	\B.0.1..00\B	Bit-level matching for binary protocols. The length of the bitmask must be in multiples of 8. The first \B denotes the start of the bitmask. The last \B denotes the end of the bitmask. The decimal (.) indicates the bit can be either 0 or 1. A 0 or 1 indicates the bit at that position must be 0, or must be 1.
	\0 <octal_number>	For a direct binary match.
	\X<hexadecimal-number>\X	For a direct binary match.
	\[<character-set>\]	For case-insensitive matches.
	.	To match any symbol.
	*	To match 0 or more symbols.
	+	To match 1 or more symbols.
	?	To match 0 or 1 symbol.
	()	Grouping of expressions.
	|	Alternation. Typically used with (). Example: The following expression matches dog or cat: (dog | cat).
	[]	Character class. Any explicit value within the bracket at the position matches. Example: [Dd]ay matches Day and day.
	[<start>-<end>]	Character range. Any value within the range (denoted with a hyphen). The Security Administrator can mix character class and a hexadecimal range. Example: [AaBbCcDdEeFf0-9].
	[^<start>-<end>]	Negation of character range. Example: [^Dd]ay matches Hay and ray, but not Day or day. Note: To negate an entire signature pattern, select the Negate option under the pattern text box.
	\u<string>\u	Unicode insensitive matches.
	\s	Whitespace.
	\	Use a backslash to escape special characters so that they are matched and not processed as regular expression operators.
		Character	Escaped
		*	\*
		(	\(
		)	\)
		.	\.
		+	\+
		\	\\
		[	\0133
		]	\0135
		Note: Because the combination of the backslash and the open and close square brackets are used in the case-insensitive expression, the Security Administrator must use the backslash with the octal code for the bracket characters.
context	Binds pattern matching to a context. Packet–Detects the pattern in any packet. Stream–Reassembles packets and extracts the data to search for a pattern match. However, the IDP engine does not recognize packet boundaries for stream contexts, so data for multiple packets is combined. Select this option only when no other context option contains the attack.
direction	directionSelect the direction in which to detect the pattern: Client to Server–Detects the pattern only in client-to-server traffic. Server to Client–Detects the pattern only in server-to-client traffic. Any–Detects the pattern in either direction. The session initiator is considered the client, even if that source IP is a server.

Configuring Mandatory Reject Rules for Invalid Fragments and Fragmented IP Packets

This topic describes how to configure mandatory reject rules for invalid fragments and fragmented IP packets that cannot be reassembled.

Before the administrator begin, log in with the root account on a Junos OS device running Junos OS Release 23.4R1 and edit the configuration.

Note:

The administrator can enter the configuration commands in any order and commit all the commands at once.

To configure mandatory reject rules:

1. Specify the flow configuration to forcefully reassemble the IP fragments.

   To configure string-based rule for multiple non-fragmented packets:

Configuration Examples

Configuring rules that use packet payload string based detection field to match specific strings in URLs:

Configuring rules that use packet payload string-based detection field for ICMPv4/ICMPv6:

Configuring rules that use packet payload string-based detection field for FTP:

Configuring rules that use packet payload string-based detection field for HTTP:

Configuring rules that use packet payload string-based detection field for zip file webpage:

Configuring rules that use packet payload string-based detection field for SMTP:

Configuring rules that use packet payload string-based detection field for string SECURITY in a UDP packet:

Configuring rules that use packet payload string-based detection field for IPv4 - Version:

Configuring rules that use packet payload string-based detection field for IPv4 - Header Length:

Configuring rules that use packet payload string-based detection field for IPv4 - Packet Length:

Configuring rules that use packet payload string-based detection field for IPv4 - ID:

Configuring rules that use packet payload string-based detection field for IPv4 - IP Flags:

Configuring rules that use packet payload string-based detection field for IPv4 - Fragment Offset:

Configuring rules that use packet payload string-based detection field for IPv4 - Time to Live (TTL):

Configuring rules that use packet payload string-based detection field for IPv4 - Protocol:

Configuring rules that use packet payload string-based detection field for IPv4 - Header Checksum:

Configuring rules that use packet payload string-based detection field for IPv4 - Source Address:

Configuring rules that use packet payload string-based detection field for IPv4 - Destination Address:

Configuring rules that use packet payload string-based detection field for IPv4 - IP Options:

Configuring rules that use packet payload string-based detection field for IPv6 - Version:

Configuring rules that use packet payload string-based detection field for IPv6 - Payload Length:

Configuring rules that use packet payload string-based detection field for IPv6 - Next Header:

Configuring rules that use packet payload string-based detection field for IPv6 - Hop Limit:

Configuring rules that use packet payload string-based detection field for IPv6 - Source Address:

Configuring rules that use packet payload string-based detection field for IPv6 - Destination Address:

Configuring rules that use packet payload string-based detection field for IPv6 - Routing Header:

Configuring rules that use packet payload string-based detection field for IPv6 - Traffic Class:

Configuring rules that use packet payload string-based detection field for IPv6 - Flow Label:

Configuring rules that use packet payload string-based detection field for ICMP - Type:

Configuring rules that use packet payload string-based detection field for ICMP - Code:

Configuring rules that use packet payload string-based detection field for ICMP - Header Checksum:

Configuring rules that use packet payload string-based detection field for ICMP - Header fields:

Configuring rules that use packet payload string-based detection field for ICMPv6 – Type:

Configuring rules that use packet payload string-based detection field for ICMPv6 – Code:

Configuring rules that use packet payload string-based detection field for ICMPv6 – Header Checksum:

Configuring rules that use packet payload string-based detection field for TCP – Source Port:

Configuring rules that use packet payload string-based detection field for TCP – Destination Port:

Configuring rules that use packet payload string-based detection field for TCP – Sequence Number:

Configuring rules that use packet payload string-based detection field for TCP – Acknowledgement Number:

Configuring rules that use packet payload string-based detection field for TCP – Offset:

Configuring rules that use packet payload string-based detection field for TCP – Reserved:

Configuring rules that use packet payload string-based detection field for TCP – TCP Flags:

Configuring rules that use packet payload string-based detection field for TCP – Window:

Configuring rules that use packet payload string-based detection field for TCP – Checksum:

Configuring rules that use packet payload string-based detection field for TCP – Urgent Pointer:

Configuring rules that use packet payload string-based detection field for TCP – Options:

Configuring rules that use packet payload string-based detection field for UDP – Source Port:

Configuring rules that use packet payload string-based detection field for UDP – Destination Port:

Configuring rules that use packet payload string-based detection field for UDP – Length:

Configuring rules that use packet payload string-based detection field for UDP – Checksum: