Attack Objects and Object Groups for IDP Policies
This topic covers IDP attack objects and groups. Learn to create, modify, and use them to protect networks from various threats and vulnerabilities. Ensure robust security measures.
Attack objects, application signatures objects, and service objects are used in defining IDP policy rules. As a response to new vulnerabilities, Juniper Networks periodically provides a file containing attack database updates on the Juniper website. You can download this file to protect your network from new threats. These attack objects and groups are designed to detect known attack patterns and protocol anomalies within the network traffic. You can configure attack objects and groups as match conditions in IDP policy rules.
Address Known and Unknown Vulnerabilities
Known Vulnerabilities
The Internet security community documents known vulnerabilities. Several security organizations, security analysts, and security forums comprise the Internet security community. The security community continually discovers and analyzes new attacks and exchanges this information over the Internet. In this way, they can quickly locate, identify, and truly understand an attack.
Some security advisories include the actual attack code. You can use the attack information and the attack code to capture packet information and service contexts. You can use this information to create a custom signature attack object.
Unfortunately, most advisories do not post the attack code with the attack description. If you cannot obtain the attack code, read the advisory carefully and try to reconstruct the basics of the attack packet. Always isolate code from unknown sources.
Table 1 active in the security community serve as valuable resources for finding attack information.
| Resource | Description |
|---|---|
| NVD | National Vulnerability Database (http://nvd.nist.gov). The U.S. government repository of vulnerability management data represented using the Security Content Automation Protocol (SCAP). |
| SANS | SysAdmin, Audit, Network, Security Institute (www.sans.org). An information security research, certification, and education organization that provides security alerts. Also hosts the Internet Storm Center (ISC) at http://www.incidents.org. |
| CVE | Common Vulnerabilities and Exposures (http://cve.mitre.org). A standardized list of vulnerabilities and other information security exposures. |
| BugTraq (http://securityfocus.com/archive/1) | A moderated mailing list hosted by Security Focus that discusses and announces computer security vulnerabilities. |
| CERT coordination center (http://www.cert.org) | A federally funded security alert organization that provides security advisories. |
| Packet Storm Security (http://packetstormsecurity.nl) | A nonprofit organization of security professionals that provides security information by way of security news, advisories, forums, and attack code. |
| Metasploit (http://www.metasploit.com) | Metasploit provides useful information for performing penetration testing, IDS signature development, and exploit research. |
| FrSIRT | French Security Incident Response Team (http://www.frsirt.com). FrSIRT is an independent security research organization providing security advisories and real-time vulnerability alerting and notification services. |
| ISS | Internet Security Systems (http://www.iss.net). An Internet security company that provides alerts and Internet threat levels. |
Unknown Vulnerabilities
The Internet security community does not document some vulnerabilities in advisories; these are called as unknown vulnerabilities. In these cases, the IDP Series Profiler, firewall, or IDP security event logs generated in your production environment alert you to suspicious activity and abnormal traffic. In your production environment, you will use packet logging tools to capture packets and service context information that you can later analyze and experiment with in your lab.
Test a Custom Attack Object
We recommend the following workflow to test a custom attack object. Note that the following procedure consists of general steps and is intended for expert users who are familiar with these tasks.
To test a custom attack object:
- Create a new security policy and new IDP rulebase rule that includes only the custom attack object to be tested. Enable logging and packet logging.
- Push the policy to the IDP Series lab device.
- From the attacker computer, reproduce the attack that targets the victim computer.
- Use the Security Director Log Viewer to see whether the traffic generated logs as expected.
If your test fails, review the attack advisory, the protocol RFC, and the attack code or packet captures to identify additional information that can help you fine-tune your settings. The most frequent issue that requires tuning is the syntax of the DFA expression.
Predefined IDP Attack Objects and Object Groups
The security package for Intrusion Detection and Prevention (IDP) contains a database of predefined IDP attack objects and IDP attack object groups that you can use in IDP policies to match traffic against known and unknown attacks. Juniper Networks updates the predefined attack objects and groups on a regular basis with newly discovered attack patterns.
Updates to the attack object database can include:
New descriptions or severities for existing attack objects
New attack objects
Deletion of obsolete attack objects
Predefined Attack Objects
Predefined attack objects are listed in an alphabetical order. These attack objects have unique names that help you identify the attack. The first part of the name indicates the group to which the attack object belongs. For example:
FTP:USER:ROOT—Belongs to theFTP:USERgroup. It detects attempts to log in to an FTP server using therootaccount.HTTP:HOTMAIL:FILE-UPLOAD—Belongs to theHTTP:HOTMAILgroup. It detects files attached to e-mails sent via the Web-based e-mail serviceHotmail.
Predefined Attack Object Groups
The predefined attack groups list displays the attack objects in the categories described below. A set of recommended attack objects that Juniper Networks considers to be serious threats are also available in this list. The recommended attack objects are organized into the following categories:
Attack Object Group |
Description |
|---|---|
Attack Type |
Groups attack objects by type (anomaly or signature). Within each type, attack objects are grouped by severity. |
Category |
Groups attack objects by predefined categories. Within each category, attack objects are grouped by severity. |
Operating System |
Groups attack objects by the operating system to which they apply: BSD, Linux, Solaris, or Windows. Within each operating system, attack objects are grouped by services and severity. |
Severity |
Groups attack objects by the severity assigned to the attack. IDP has five severity levels: Critical, Major, Minor, Warning, Info. Within each severity, attack objects are grouped by category. |
Web Services |
Groups attack objects by common Web services. These services are grouped by severity levels—Warning, Critical, Major, Minor, Info. |
Miscellaneous |
Groups attack objects by performance level. Attack objects affecting IDP performance over a certain level are grouped under this category. |
Response |
Groups attack objects in traffic flowing in the server to client direction. |
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, specify a unique name and additional information. Include a general description and keyword to make it easier to locate and maintain.
Certain properties in the attack object definitions are common to all types of attacks. Such properties can be 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.
The IDP feature is enabled by default, no license is required. Custom attacks and custom attack groups in IDP policies can also be configured and installed even when a valid license and signature database are not installed on the device.
- Attack Name
- Severity
- Service and Application Bindings
- Protocol and Port Bindings
- Time Bindings
- Attack Properties (Signature Attacks)
- Attack Properties (Protocol Anomaly Attacks)
- Attack Properties (Compound or Chain Attacks)
Attack Name
Specify an alphanumeric name for the object. You might want to include the protocol the attack uses in the attack name.
The maximum number of characters allowed for a custom attack object name is 60. You can validate
the statement using the set security idp custom-attack command.
Severity
Severity specifies the brutality of the attack on your network. Severity categories, in order of increasing brutality, are info, warning, minor, major, critical. 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.
Specify either the service or the protocol binding in a custom attack. If you specify both, the service binding takes precedence.
any—Specifyanyif you are unsure of the correct service and want to match the signature in all services. Because some attacks use multiple services to attack your network, you might want to select theAnyservice binding to detect the attack regardless of which service the attack chooses for a connection.service—Most attacks use a specific service to attack your network. You can select the specific service used to perpetrate the attack as the service binding.For list of services, service bindings ,and contexts see Understanding IDP Custom Attack Objects Service Contexts
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.
Specify either the service or the protocol binding in a custom attack. If you specify both, the service binding takes precedence.
IP—You can specify any of the supported network layer protocols using protocol numbers. Table 3 lists protocol numbers for different protocols.
Table 3: Supported Protocols and Protocol Numbers Protocol Name
Protocol Number
IGMP
2
IP-IP
4
EGP
8
PUP
12
TP
29
IPV6
41
ROUTING
43
FRAGMENT
44
RSVP
46
GRE
47
ESP
50
AH
51
ICMPV6
58
NONE
59
DSTOPTS
60
MTP
92
ENCAP
98
PIM
103
COMP
108
RAW
255
ICMP, TCP, and UDP—Attacks that do not use a specific service might use specific ports to attack your network. Some TCP and UDP attacks use standard ports to enter your network and establish a connection.
RPC—The RPC protocol is used by distributed processing applications to handle interaction between processes remotely. When a client makes a remote procedure call to an RPC server, the server replies with a remote program; each remote program uses a different program number. To detect attacks that use RPC, configure the service binding as RPC and specify the RPC program ID.
Table 4 displays sample formats for key protocols.
Protocol Name |
Protocol Number |
Description |
|---|---|---|
ICMP |
|
Specify the protocol name. |
IP |
|
Specify the Network Layer protocol number. |
RPC |
|
Specify the RPC program number. |
TCP or UDP |
|
Specifying the port is optional for TCP and UDP protocols. For example, you can specify any of the following:
|
Time Bindings
Use time bindings to configure the time attributes for the time binding 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 across sessions.
You can configure the maximum time interval between any two instances of a time binding custom
attack and the range for the maximum time interval is 0 minutes and 0 seconds to 60
minutes and 0 seconds. Earlier, the maximum time interval between any two instances of a
time binding attack is 60 seconds, for the attack trigger count to reach the count
configured in the time binding. The interval
interval-value statement is introduced at the
[edit security idp custom-attack attack-name
time-binding] hierarchy to configure a custom time-binding.
Scope
Specify the scope within which the count of an attack occurs:
Source—Specify this option to detect attacks from the source address for the specified number of times, regardless of the destination address. This means that for a given attack, a threshold value is maintained for each attack from the source address. The destination address is ignored. For example, anomalies are detected from two different pairs (
ip-a,ip-b) and (ip-a,ip-c) that have the same source addressip-abut different destination addressesip-bandip-c. Then the number of matches forip-aincrements to2. Suppose the threshold value or count is also set to 2, then the signature triggers the attack event.Destination—Specify this option to detect attacks sent to the destination address for the specified number of times, regardless of the source address. This means that for a given attack, a threshold value is maintained for each attack from the destination address. The source address is ignored. For example, if anomalies are detected from two different pairs (
ip-a,ip-b) and (ip-c,ip-b) that have the same destination addressip-bbut different source addressesip-aandip-c. Then the number of matches forip-bincrements to2. Suppose the threshold value or count is also set to2, then the signature triggers the attack event.Peer—Specify this option to detect attacks between source and destination IP addresses of the sessions for the specified number of times. This means that the threshold value is applicable for a pair of source and destination addresses. Suppose anomalies are detected from two different source and destination pairs (
ip-a,ip-b) and (ip-a,ip-c). Then the number of matches for each pair is set to1, even though both pairs have a common source address.
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 user defined duration (configured using the interval option), after which the cycle repeats.
Interval
Interval specifies the maximum time interval between any two instances of a time-binding custom attack. The range for the time interval is 0 seconds through 1 hour and the default value is 60 seconds.
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:
Attack context, flow type, and direction are mandatory fields for the signature attack definition.
- Attack Context
- Attack Direction
- Attack Pattern
- Protocol-Specific Parameters
- Sample 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:
| Contexts | Description |
|---|---|
first-data-packet |
Specify this context to detect the attack in only the first data packet. |
first-packet |
Specify this context to detect the attack in only the first packet of a
stream. When the flow direction for the attack object is set to
any, the device checks the first packet of both the
server-to-client and the client-to-server flows. If you know that the attack
signature appears in the first packet of a session, choosing first
packet instead of packet reduces the amount of
traffic the device needs to monitor, which improves performance. |
packet |
Specify this context to match the attack pattern within a packet. When you select this option, you must also specify the service binding to define the service header options . Although not required, specifying these additional parameters improves the accuracy of the attack object and thereby improves performance. |
line |
Specify this context to detect a pattern match within a specific line within your network traffic. |
normalized-stream |
Specify this context to detect the attack in an entire normalized
stream. The normalized stream is one of the multiple ways of sending
information. In this stream the information in the packet is normalized
before a match is performed. Suppose www.yahoo.com/sports
is the same as www.yahoo.com/s%70orts. The normalized form
to represent both of these URLs might be
www.yahoo.com/sports. Choose normalized
stream instead of stream, unless you want to
detect some pattern in its exact form. For example, if you want to detect
the exact pattern www.yahoo.com/s%70orts, then select
stream. |
normalized-stream256 |
Specify this context to detect the attack in only the first 256 bytes of a normalized stream. |
normalized-stream1k |
Specify this context to detect the attack in only the first 1024 bytes of a normalized stream. |
normalized-stream-8k |
Specify this context to detect the attack in only the first 8192 bytes of a normalized stream. |
stream |
Specify this context to reassemble packets and extract the data to search for a pattern match. However, the device cannot recognize packet boundaries for stream contexts, so data for multiple packets is combined. Specify this option only when no other context option contains the attack. |
stream256 |
Specify this context to reassemble packets and search for a pattern
match within the first 256 bytes of a traffic stream. When the flow
direction is set to any, the device checks the first 256
bytes of both the server-to-client and client-to-server flows. If you know
that the attack signature will appear in the first 256 bytes of a session,
choosing stream256 instead of stream
reduces the amount of traffic that the device must monitor and cache,
thereby improving performance. |
stream1k |
Specify this context to reassemble packets and search for a pattern
match within the first 1024 bytes of a traffic stream. When the flow
direction is set to any, the device checks the first 1024
bytes of both the server-to-client and client-to-server flows. If you know
that the attack signature will appear in the first 1024 bytes of a session,
choosing stream1024 instead of stream
reduces the amount of traffic that the device must monitor and cache,
thereby improving performance. |
stream8k |
Specify this context to reassemble packets and search for a pattern
match within the first 8192 bytes of a traffic stream. When the flow
direction is set to any, the device checks the first 8192
bytes of both the server-to-client and client-to-server flows. If you know
that the attack signature will appear in the first 8192 bytes of a session,
choosing stream8192 instead of stream
reduces the amount of traffic that the device must monitor and cache,
thereby improving performance. |
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.
Client to server (detects the attack only in client-to-server traffic)
Server to client (detects the attack only in server-to-client traffic)
Any (detects the attack in either direction)
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. The system considers the attack as matched when the pattern defined in the attack does not match the specified, negated pattern.
IDP supports pattern negation only for packet, line, and application-based contexts, 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.
You can define header parameters 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 6 displays fields and flags that you can set for attacks that use the IP protocol.
Field |
Description |
|---|---|
Type of Service |
Specify a value for the service type. Common service types are:
|
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 |
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 ( |
Don’t Fragment |
When set ( |
Table 7 displays packet header fields and flags that you can set for attacks that use the TCP protocol.
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 8 displays packet header fields and flags that you can set for attacks that use the UDP protocol.
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 9 displays packet header fields and flags that you can set for attacks that use the ICMP protocol.
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><</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.
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:
Client to server (detects the attack only in client-to-server traffic)
Server to client (detects the attack only in server-to-client traffic)
Any (detects the attack in either direction)
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 protocol anomalies into a single attack object. This forces 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:
Specify session to allow multiple matches for the object within the same session.
Specify transaction to match the object across multiple transactions that occur within the same 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)
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:
or—If either of the member name patterns match, the expression matches.and—If both of the member name patterns match, the expression matches. It does not matter which order the members appear in.oand (ordered and)—If both of the member name patterns match, and if they appear in the same order as specified in the Boolean expression, the expression matches.
Suppose you have created five signature members, labeled 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)
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>
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>
Create a Compound Attack Object
Use compound attack objects in cases where:
-
Attacks use multiple methods to exploit a vulnerability and, inspected independently, the individual contexts appear benign.
-
Matching multiple contexts reduces false positives.
-
Coupling a signature with a protocol anomaly reduces false positives.
You select signature attack objects or predefined anomalies as “members” of the compound object, and you use Boolean expressions to specify matching logic.
See Also
Modify Custom Attack Objects Due to Changes Introduced in Signature Update
This topic describes changes to some service contexts generated by the HTTP protocol decoder. Beginning with Signature Update #1972, the HTTP protocol decoder no longer generates some contexts. If your IDP security policy includes custom signatures that use the contexts that have been removed, you must modify your attack object definitions as described below to avoid policy compilation errors.
- Reference: Removed Contexts
- Example: Replace Context for Patterns Appearing in HTML Text
- Example: Replace Contexts for Patterns Appearing in URLs
Reference: Removed Contexts
To improve performance, the HTTP protocol decoder no longer generates the contexts listed in the first column of Table 10. Review this table for guidelines on replacing the contexts in custom attack objects.
Removed |
Replace With |
Guideline |
|---|---|---|
http-text-html-body |
http-text-html |
Change signatures that use context http-text-html-body to http-text-html. You do not need to make changes to the signature pattern or other properties. |
|
Use a combination of the following contexts:
|
Use a compound signature with a Boolean AND to break the signature pattern into multiple pieces. Ensure the Scope field is set to Transaction. Using the http-request-method context is optional. You use the http-request-method context to bind detection to http GET or POST or HEAD transactions. For GET method, we use the pattern \[GET\] (case insensitive GET). Use http-request-method only if the results you logged previously matching on Request Method are worth preserving. If not, omit it to improve performance. If you use http-request-method, order it first in the compound chain. Use the http-url-parsed context to match an attack signature identifiable in the URL. Use this context to match a pattern in the URL that appears before variable parameters—the part of the URL before the question mark (?). Use one or more http-variable-parsed contexts to match the URL variable parameters—the part of the URL after the question mark (?), normally separated by ampersands (&). |
Example: Replace Context for Patterns Appearing in HTML Text
Each context generated by the HTTP detector engine has a performance cost. Contexts http-text-html and http-text-html-body serve the same purpose. Reducing the number of contexts improves performance.
Table 11 shows the properties of a signature before Update #1972 and the signature after. This is a simple change. You change only the context. You do not need to change the pattern or other properties.
Before Update |
After Update |
|
|---|---|---|
Context |
http-text-html-body |
http-text-html |
Pattern |
.*<span></span>.* |
.*<span></span>.* |
Example: Replace Contexts for Patterns Appearing in URLs
This section has two parts:
Signatures that Match Request Methods
When modifying custom attack objects that previously matched request methods GET, POST, or HEAD, consider whether matches against these request method patterns were effective for you. Keep in mind, each context generated has a performance cost. If request method is not essential to your results, take this opportunity to recast your signature without it.
Table 12 and Table 13 show the properties of a signature before Update #1972 and the compound signature after. This example preserves an interest in request method.
Signature Before Update |
|
|---|---|
Scope |
– |
Context |
http-get-url-parsed-param |
Pattern |
\[/viper/vegaspalms/\].* |
Compound Signature After Update |
||
|---|---|---|
m01 |
m02 |
|
Scope |
Transaction |
|
Context |
http-request-method |
http-url-parsed |
Pattern |
|
\[/viper/vegaspalms/\].* |
Signatures that Match URL Strings and URL Variables
In general, breaking a single pattern into multiple contexts could positively or negatively impact performance. You need to test your changes to understand performance impact before deploying the attack objects in a production network. The example shown in Table 14 and Table 15 breaks URL matching into multiple contexts. Our security team has tested performance for the recommendations described here.
Signature Before Update |
|
|---|---|
Scope |
– |
Context |
http-get-url-param-parsed-param |
Pattern |
|
Compound Signature After Update |
||||
|---|---|---|---|---|
m01 |
m02 |
m03 |
m04 |
|
Scope |
Transaction |
|||
Context |
http-url-parsed |
http-variable-parsed |
http-variable-parsed |
http-variable-parsed |
Pattern |
|
|
|
|
See Also
Example: Configure Compound or Chain Attacks
This example shows how to configure compound or chain attacks for specific match criteria. A compound or chain attack object can be configured to detect attacks that use multiple methods to exploit a vulnerability.
Requirements
Before you begin, the SRX Series firewall must support and enable IDP.
Overview
A compound or a chain attack object can combine the signatures and anomalies to form a single attack object. A single attack object can contain:
Two or more signatures
Two or more anomalies
A combination of signatures and anomalies
Compound or chain attack objects combine multiple signatures and 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. Security policies use these objects to reduce false positives and increase detection accuracy. It enables you to be specific about the events that need to occur before IDP identifies traffic as an attack.
Configuration
Procedure
CLI Quick Configuration
To quickly configure this example, copy the
following commands, paste them into a text file, remove any line breaks,
change any details necessary to match your network configuration,
and then copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration
mode.
set security idp idp-policy idpengine rulebase-ips rule 1 match from-zone any set security idp idp-policy idpengine rulebase-ips rule 1 match source-address any set security idp idp-policy idpengine rulebase-ips rule 1 match to-zone any set security idp idp-policy idpengine rulebase-ips rule 1 match destination-address any set security idp idp-policy idpengine rulebase-ips rule 1 match application default set security idp idp-policy idpengine rulebase-ips rule 1 match attacks custom-attacks ftpchain set security idp idp-policy idpengine rulebase-ips rule 1 then action no-action set security idp idp-policy idpengine rulebase-ips rule 1 then notification log-attacks set security idp active-policy idpengine set security idp custom-attack ftpchain severity info set security idp custom-attack ftpchain attack-type chain protocol-binding application ftp set security idp custom-attack ftpchain attack-type chain scope session set security idp custom-attack ftpchain attack-type chain order set security idp custom-attack ftpchain attack-type chain member m1 attack-type signature context ftp-banner set security idp custom-attack ftpchain attack-type chain member m1 attack-type signature pattern .*vsFTPd.* set security idp custom-attack ftpchain attack-type chain member m1 attack-type signature direction server-to-client set security idp custom-attack ftpchain attack-type chain member m2 attack-type signature context ftp-username set security idp custom-attack ftpchain attack-type chain member m2 attack-type signature pattern .*root.* set security idp custom-attack ftpchain attack-type chain member m2 attack-type signature direction client-to-server set security idp custom-attack ftpchain attack-type chain member m3 attack-type anomaly test LOGIN_FAILED set security idp custom-attack ftpchain attack-type chain member m3 attack-type anomaly direction any set security idp traceoptions file idpd set security idp traceoptions flag all
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure compound or chain attacks for specific match criteria:
Create an IDP policy.
[edit] user@host# set security idp idp-policy idpengine
Associate a rulebase with the policy.
[edit security idp idp-policy idpengine] user@host# edit rulebase-ips
Add rules to the rulebase.
[edit security idp idp-policy idpengine rulebase-ips] user@host# edit rule 1
Define the match criteria for the rule.
[edit security idp idp-policy idpengine rulebase-ips rule 1] user@host# set match from-zone any user@host# set match source-address any user@host# set match to-zone any user@host# set match destination-address any
Specify an application set name to match the rule criteria.
[edit security idp idp-policy idpengine rulebase-ips rule 1] user@host# set match application default
Specify the match attack object and name for the attack object.
[edit security idp idp-policy idpengine rulebase-ips rule 1] user@host# set match attacks custom-attacks ftpchain
Specify an action for the rule.
[edit security idp idp-policy idpengine rulebase-ips rule 1] user@host# set then action no-action
Specify notification or logging options for the rule.
[edit security idp idp-policy idpengine rulebase-ips rule 1] user@host# set then notification log-attacks
Activate the IDP policy.
[edit] user@host# set security idp active-policy idpengine
Specify a name for the custom attack.
[edit security idp] user@host# set custom-attack ftpchain
Set the severity for the custom attack.
[edit security idp custom-attack ftpchain] user@host# set severity info
Set the attack type and the application name for the custom attack.
[edit security idp custom-attack ftpchain] user@host# set attack-type chain protocol-binding application ftp
Set the scope and the order in which the attack is defined.
[edit security idp custom-attack ftpchain attack-type chain] user@host# set scope session user@host# set order
Specify a name for the first member of the chain attack object.
[edit security idp custom-attack ftpchain attack-type chain] user@host# set member m1
Set the context, pattern, and direction for the first member of the chain attack object.
[edit security idp custom-attack ftpchain attack-type chain member m1] user@host# set attack-type signature context ftp-banner user@host# set attack-type signature pattern .*vsFTPd.* user@host# set attack-type signature direction server-to-client
Specify a name for the second member of the chain attack object.
[edit security idp custom-attack ftpchain attack-type chain] user@host# set member m2
Set the context, pattern, and direction for the second member of the chain attack object.
[edit security idp custom-attack ftpchain attack-type chain member m2] user@host# set attack-type signature context ftp-username user@host# set attack-type signature pattern .*root.* user@host# set attack-type signature direction client-to-server
Specify a name for the third member of the chain attack object.
[edit security idp custom-attack ftpchain attack-type chain] user@host# set member m3
Specify an attack-type and direction for the third member of the chain attack object.
[edit security idp custom-attack ftpchain attack-type chain member m3] user@host# set attack-type anomaly direction any
Specify the trace options and trace file information for the IDP services.
[edit] user@host# set security idp traceoptions file idpd
Specify the events and other information which needs to be included in the trace output.
[edit] user@host# set security idp traceoptions flag all
Results
From configuration mode, confirm your configuration
by entering the show security idp command. If the output
does not display the intended configuration, repeat the configuration
instructions in this example to correct it.
[edit]
user@host# show security idp
idp-policy idpengine {
rulebase-ips {
rule 1 {
match {
from-zone any;
source-address any;
to-zone any;
destination-address any;
application default;
attacks {
custom-attacks ftpchain;
}
}
then {
action {
no-action;
}
notification {
log-attacks;
}
}
}
}
}
active-policy idpengine;
custom-attack ftpchain {
severity info;
attack-type {
chain {
protocol-binding {
application ftp;
}
scope session;
order;
member m1 {
attack-type {
signature {
context ftp-banner;
pattern .*vsFTPd.*;
direction server-to-client;
}
}
}
member m2 {
attack-type {
signature {
context ftp-username;
pattern .*root.*;
direction client-to-server;
}
}
}
member m3 {
attack-type {
anomaly {
test LOGIN_FAILED;
direction any;
}
}
}
}
}
}
traceoptions {
file idpd;
flag all;
}
If you are done configuring the device, enter commit from configuration mode.
When you enter commit in configuration mode, the
configuration is internally verified and then committed. If there are any
errors, commit will fail and the errors will be reported.
Verification
To confirm that the chain attack configuration is working properly, perform this task:
Verify the Configuration
Purpose
Verify that the chain attack configuration is correct.
Action
From operational mode, enter the show security
idp policy-commit-status command to check the policy compilation
or load status.
The output of the show security idp policy-commit-status
command is dynamic, hence there is no single output for this command.
Verify that the attacks are getting detected as per the configuration,
pass traffic through the device to trigger an attack match. For example,
enter the show security idp status command to check whether
the policy is loaded or not.
user@host> show security idp status
IDP policy[/var/db/idpd/bins/test.bin.gz.v] and detector[/var/db/idpd/sec-repository/installed-detector/libidp-detector.so.tgz.v] loaded successfully. The loaded policy size is:785 Bytes
Enter the show security idp attack table command
to pass attack traffic and then verify that the attacks are getting
detected or not.
The command will display the output only when attacks are detected.
user@host> show security idp attack
table
IDP attack statistics: Attack name #Hits FTP:USER:ROOT 1
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
interval
interval-value statement is introduced at the
[edit security idp custom-attack attack-name
time-binding] hierarchy to configure a custom
time-binding.