Understanding Custom Attack Objects

You can create custom attack objects to detect new attacks or customize predefined attack objects to meet the unique needs of your network.

To configure a custom attack object, you specify a unique name for it and then specify additional information, such as a general description and keywords, which can make it easier for you to locate and maintain the attack object.

Certain properties in the attack object definitions are common to all types of attacks, such as attack name, description, severity level, service or application binding, time binding, recommended action, and protocol or port binding. Some fields are specific to an attack type and are available only for that specific attack definition.

This topic includes the following sections:

Attack Name

Specify an alphanumeric name for the object. You might want to include the protocol the attack uses in the attack name.

Severity

Specifies the brutality of the attack on your network. Severity categories, in order of increasing brutality, are info, warning, minor, major, critical (see Understanding IDP Rule Notifications). Critical attacks are the most dangerous—typically these attacks attempt to crash your server or gain control of your network. Informational attacks are the least dangerous, and typically are used by network administrators to discover holes in their own security systems.

Service and Application Bindings

The service or application binding field specifies the service that the attack uses to enter your network.

Note: Specify either the service or the protocol binding in a custom attack. In case you specify both, the service binding takes precedence.

Protocol and Port Bindings

Protocol or port bindings allow you to specify the protocol that an attack uses to enter your network. You can specify the name of the network protocol, or the protocol number.

Note: Specify either the service or the protocol binding in a custom attack. In case you specify both, the service binding takes precedence.

Table 50 displays sample formats for key protocols.

Table 50: Sample Formats for Protocols

Protocol Name

Protocol Number

Description

ICMP

<Port>ICMP</Port>

Specify the protocol name.

IP

<Port>IP/protocol-number</Port>

Specify the Network Layer protocol number.

RPC

<Port>RPC/program-number</Port>

Specify the RPC program number.

TCP or UDP

  • <Port>TCP </Port>
  • <Port>TCP/port </Port>
  • <Port>TCP/minport-maxport </Port>

Specifying the port is optional for TCP and UDP protocols. For example, you can specify either of the following:

  • <Port>UDP</Port>
  • <Port>UDP/10</Port>
  • <Port>UDP/10-100</Port>

Time Bindings

Use time bindings to configure the time attributes for the custom attack object. Time attributes control how the attack object identifies attacks that repeat for a certain number of times. By configuring the scope and count of an attack, you can detect a sequence of the same attacks over a period of time (one minute) across sessions.

Scope

Specify the scope within which the count of an attack occurs:

Count

Count or threshold value specifies the number of times that the attack object must detect an attack within the specified scope before the device considers the attack object to match the attack. If you bind the attack object to multiple ports and the attack object detects that attack on different ports, each attack on each port is counted as a separate occurrence. For example, when the attack object detects an attack on TCP/80 and then on TCP/8080, the count is two.

Once the count match is reached, each attack that matches the criteria causes the attack count to increase by one. This count cycle lasts for a duration of 60 seconds, after which the cycle repeats.

Attack Properties (Signature Attacks)

Signature attack objects use a stateful attack signature (a pattern that always exists within a specific section of the attack) to detect known attacks. They also include the protocol or service used to perpetrate the attack and the context in which the attack occurs. The following properties are specific to signature attacks, and you can configure them when configuring signature attack:

Note: Attack context, flow type, and direction are mandatory fields for the signature attack definition.

Attack Context

An attack context defines the location of the signature. If you know the service and the specific service context, specify that service and then specify the appropriate service contexts. If you know the service, but are unsure of the specific service context, specify one of the following general contexts:

Attack Direction

You can specify the connection direction of the attack. Using a single direction (instead of Any) improves performance, reduces false positives, and increases detection accuracy.

Attack Pattern

Attack patterns are signatures of the attacks you want to detect. A signature is a pattern that always exists within an attack; if the attack is present, so is the signature. To create the attack pattern, you must first analyze the attack to detect a pattern (such as a segment of code, a URL, or a value in a packet header), then create a syntactical expression that represents that pattern. You can also negate a pattern. Negating a pattern means that the attack is considered matched if the pattern defined in the attack does not match the specified pattern.

Note: Pattern negation is supported for packet, line, and application based contexts only and not for stream and normalized stream contexts.

Protocol-Specific Parameters

Specifies certain values and options existing within packet headers. These parameters are different for different protocols. In a custom attack definition, you can specify fields for only one of the following protocols—TCP, UDP, or ICMP. Although, you can define IP protocol fields with TCP or UDP in a custom attack definition.

Note: Header parameters can be defined only for attack objects that use a packet or first packet context. If you specified a line, stream, stream 256, or a service context you cannot specify header parameters.

If you are unsure of the options or flag settings for the malicious packet, leave all fields blank and Intrusion Detection and Prevention (IDP) attempts to match the signature for all header contents.

Table 51 displays fields and flags that you can set for attacks that use the IP protocol.

Table 51: IP Protocol Fields and Flags

Field

Description

Type of Service

Specify a value for the service type. Common service types are:

  • 0000 Default
  • 0001 Minimize Cost
  • 0002 Maximize Reliability
  • 0003 Maximize Throughput
  • 0004 Minimize Delay
  • 0005 Maximize Security

Total Length

Specify a value for the number of bytes in the packet, including all header fields and the data payload.

ID

Specify a value for the unique value used by the destination system to reassemble a fragmented packet.

Time to Live

Specify an integer value in the range of 0–255 for the time-to-live (TTL) value of the packet. This value represents the number of devices the packet can traverse. Each router that processes the packet decrements the TTL by 1; when the TTL reaches 0, the packet is discarded.

Protocol

Specify a value for the protocol used.

Source

Enter the source address of the attacking device.

Destination

Enter the destination address of the attack target.

Reserved Bit

This bit is not used.

More Fragments

When set (1), this option indicates that the packet contains more fragments. When unset (0), it indicates that no more fragments remain.

Don’t Fragment

When set (1), this option indicates that the packet cannot be fragmented for transmission.

Table 52 displays packet header fields and flags that you can set for attacks that use the TCP protocol.

Table 52: TCP Header Fields and Flags

Field

Description

Source Port

Specify a value for the port number on the attacking device.

Destination Port

Specify a value for the port number of the attack target.

Sequence Number

Specify a value for the sequence number of the packet. This number identifies the location of the data in relation to the entire data sequence.

ACK Number

Specify a value for the ACK number of the packet. This number identifies the next sequence number; the ACK flag must be set to activate this field.

Header Length

Specify a value for the number of bytes in the TCP header.

Data Length

Specify a value for the number of bytes in the data payload. For SYN, ACK, and FIN packets, this field should be empty.

Window Size

Specify a value for the number of bytes in the TCP window size.

Urgent Pointer

Specify a value for the urgent pointer. The value indicates that the data in the packet is urgent; the URG flag must be set to activate this field.

URG

When set, the urgent flag indicates that the packet data is urgent.

ACK

When set, the acknowledgment flag acknowledges receipt of a packet.

PSH

When set, the push flag indicates that the receiver should push all data in the current sequence to the destination application (identified by the port number) without waiting for the remaining packets in the sequence.

RST

When set, the reset flag resets the TCP connection, discarding all packets in an existing sequence.

SYN

When set, the SYN flag indicates a request for a new session.

FIN

When set, the final flag indicates that the packet transfer is complete and the connection can be closed.

R1

This reserved bit (1 of 2) is not used.

R2

This reserved bit (2 of 2) is not used.

Table 53 displays packet header fields and flags that you can set for attacks that use the UDP protocol.

Table 53: UDP Header Fields and Flags

Field

Description

Source Port

Specify a value for the port number on the attacking device.

Destination Port

Specify a value for the port number of the attack target.

Data Length

Specify a value for the number of bytes in the data payload.

Table 54 displays packet header fields and flags that you can set for attacks that use the ICMP protocol.

Table 54: ICMP Header Fields and Flags

Field

Description

ICMP Type

Specify a value for the primary code that identifies the function of the request or reply packet.

ICMP Code

Specify a value for the secondary code that identifies the function of the request or reply packet within a given type.

Sequence Number

Specify a value for the sequence number of the packet. This number identifies the location of the request or reply packet in relation to the entire sequence.

ICMP ID

Specify a value for the identification number. The identification number is a unique value used by the destination system to associate request and reply packets.

Data Length

Specify a value for the number of bytes in the data payload.

Sample Signature Attack Definition

The following is a sample signature attack definition:

<Entry>
<Name>sample-sig</Name>
<Severity>Major</Severity>
<Attacks><Attack>
<TimeBinding><Count>2</Count>
<Scope>dst</Scope></TimeBinding>
<Application>FTP</Application>
<Type>signature</Type>
<Context>packet</Context>
<Negate>true</Negate>
<Flow>Control</Flow>
<Direction>any</Direction>
<Headers><Protocol><Name>ip</Name>
<Field><Name>ttl</Name>
<Match>==</Match><Value>128</Value></Field>
</Protocol><Name>tcp</Name>
<Field><Name><Match>&lt;</Match>
<value>1500</Value>
</Field></Protocol></Headers>
</Attack></Attacks>
</Entry>

Attack Properties (Protocol Anomaly Attacks)

A protocol anomaly attack object detects unknown or sophisticated attacks that violate protocol specifications (RFCs and common RFC extensions). You cannot create new protocol anomalies, but you can configure a new attack object that controls how your device handles a predefined protocol anomaly when detected.

Note: The service or application binding is a mandatory field for protocol anomaly attacks.

The following properties are specific to protocol anomaly attacks. Both attack direction and test condition are mandatory fields for configuring anomaly attack definitions.

Attack Direction

Attack direction allows you to specify the connection direction of an attack. Using a single direction (instead of Any) improves performance, reduces false positives, and increases detection accuracy:

Test Condition

Test condition is a condition to be matched for an anomaly attack. Juniper Networks supports certain predefined test conditions. In the following example, the condition is a message that is too long. If the size of the message is longer than the preconfigured value for this test condition, the attack is matched.

<Attacks>
<Attack>
<Type>anomaly</Type>
...
<Test>MESSAGE_TOO_LONG</Test>
<Value>yes</Value>
...
</Attack>
</Attacks>

Sample Protocol Anomaly Attack Definition

The following is a sample protocol anomaly attack definition:

<Entry>
<Name>sample-anomaly</Name>
<Severity>Info</Severity>
<Attacks><Attack>
<TimeBinding><Count>2</Count>
<Scope>peer</Scope></TimeBinding>
<Application>TCP</Application>
<Type>anomaly</Type>
<Test>OPTIONS_UNSUPPORTED</Test>
<Direction>any</Direction>
</Attack></Attacks>
</Entry>

Attack Properties (Compound or Chain Attacks)

A compound or chain attack object detects attacks that use multiple methods to exploit a vulnerability. This object combines multiple signatures and/or protocol anomalies into a single attack object, forcing traffic to match a pattern of combined signatures and anomalies within the compound attack object before traffic is identified as an attack. By combining and even specifying the order in which signatures or anomalies must match, you can be very specific about the events that need to take place before the device identifies traffic as an attack.

You must specify a minimum of 2 members (attacks) in a compound attack. You can specify up to 32 members in compound attack. Members can be either signature or anomaly attacks.

The following properties are specific to compound attacks:

Scope

Scope allows you to specify if the attack is matched within a session or across transactions in a session. If the specified service supports multiple transactions within a single session, you can also specify whether the match should occur over a single session or can be made across multiple transactions within a session:

Order

Use ordered match to create a compound attack object that must match each member signature or protocol anomaly in the order you specify. If you do not specify an ordered match, the compound attack object still must match all members, but the attack pattern or protocol anomalies can appear in the attack in random order.

Reset

Specifies that a new log is generated each time an attack is detected within the same session. If this field is set to no then the attack is logged only once for a session.

Expression (Boolean expression)

Using the boolean expression field disables the ordered match function. The boolean expression field makes use of the member name or member index properties. The following three boolean operators are supported along with parenthesis, which helps determine precedence:

Suppose you have created six signature members, labelled s1-s5. Suppose you know that the attack always contains the pattern s1, followed by either s2 or s3. You also know that the attack always contains s4 and s5, but their positions in the attack can vary. In this case, you might create the following boolean expression: ((s1 oand s2) or (s1 oand s3)) and (s4 and s5)

Note: You can either define an ordered match or an expression (not both) in a custom attack definition.

Member Index

Member Index is specified in chain attacks to identify a member (attack) uniquely. In the following example, member index is used to identify the members m01 and m02 in the defined expression:

<Expression>m02 AND m01</Expression>
<Order>no</Order>
<Reset>no</Reset>
<ScopeOption/>
<Members>
<Attack>
<Member>m01</Member>
<Type>Signature</Type>
...
<Pattern><!CDATA[.*/getlatestversion]]></Pattern>
<Regex/>
</Attack>
<Attack><Member>m02</Member>
<Type>Signature</Type>
...
<Pattern><!CDATA[\[Skype\'.*]]></Pattern>
<Regex/>
</Attack>
<Attack>

Note: When defining the expression, you must specify the member index for all members.

Sample Compound Attack Definition

The following is a sample compound attack definition:

<Entry>
<Name>sample-chain</Name>
<Severity>Critical</Severity>
<Attacks><Attack>
<Application>HTTP</Application>
<Type>Chain</Type>
<Order>yes</Order>
<Reset>yes</Reset>
<Members><Attack>
<Type>Signature</Type>
<Context>packet</Context>
<Pattern><![CDATA[Unknown[]></Pattern>
<Flow>Control</Flow>
<Direction>cts</Direction>
</Attack><Attack>
<Type>anomaly</Type>
<Test>CHUNK_LENGTH_OVERFLOW</Test>
<Direction>any</Direction>
</Attack></Members>
</Attack></Attacks>
</Entry>

Related Topics

Copyright© 1999-2010 Juniper Networks, Inc. All rights reserved.