ON THIS PAGE
Understanding Our Approach to Addressing Known and Unknown Vulnerabilities
Understanding Predefined IDP Attack Objects and Object Groups
Modifying Custom Attack Objects Due to Changes Introduced in Signature Update
Example: Configuring Attack Groups with Dynamic Attack Groups and Custom Attack Groups
Example: Compound Signature to Detect Exploitation of an HTTP Vulnerability
Example: Using Time Binding Parameters to Detect a Brute Force Attack
Attack Objects and Object Groups for IDP Policies
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.
For more information, see the following topics:
Understanding Our Approach to Addressing Known and Unknown Vulnerabilities
This topic includes the following sections:
Known Vulnerabilities
Known vulnerabilities are those documented within the Internet security community. The Internet security community comprises several security organizations, security analysts, and security forums. 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.
Remember to isolate code acquired from unknown sources.
The following organizations are active in the security community and are a good resource for locating attack information:
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
Unknown vulnerabilities are those that have not been documented in Internet security community advisories. 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.
Testing 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.
Creating a Signature Attack Object
A signature attack object is a pattern you want the system to detect. You use a DFA expression to represent the pattern. All of the other signature properties you can set (such as service or protocol context, direction, and other constraints) are provided so you can optimize performance of the system in detecting the pattern and eliminate false positives. In general, you want to tune settings of a signature attack object so that the system looks for it in every context where it might occur and in no other context.
To configure a signature attack object:
Understanding 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
This topic includes the following sections:
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. |
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.
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.
This topic includes the following sections:
- 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.
Starting with
Junos OS Release 15.1X49-D140, 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
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. In case 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. In case you specify both, the service binding takes precedence.
IP—You can specify any of the supported network layer protocols using protocol numbers. Table 11 lists protocol numbers for different protocols.
Table 11: 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 remote procedure call (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 12 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.
Starting in Junos OS
Release 18.4R1, 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. In Junos OS releases prior to 18.4R1, 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:
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 toany, 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, choosingfirst packetinstead ofpacketreduces 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. Supposewww.yahoo.com/sportsis the same aswww.yahoo.com/s%70orts. The normalized form to represent both of these URLs might bewww.yahoo.com/sports. Choosenormalized streaminstead ofstream, unless you want to detect some pattern in its exact form. For example, if you want to detect the exact patternwww.yahoo.com/s%70orts, then selectstream.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 toany, 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, choosingstream256instead ofstreamreduces 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 toany, 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, choosingstream1024instead ofstreamreduces 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 toany, 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, choosingstream8192instead ofstreamreduces 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. Negating a pattern means that the attack is considered matched if the pattern defined in the attack does not match the specified pattern.
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.
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 13 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 14 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 15 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 16 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/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:
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)
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:
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, 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)
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>
Creating 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.
To configure a compound attack object:
See Also
Modifying 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. This topic includes the following information:
- Reference: Removed Contexts
- Example: Replacing the Context for Patterns Appearing in HTML Text
- Example: Replacing the 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 19. 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: Replacing the 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 20 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: Replacing the 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 21 and Table 22 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 23 and Table 24 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: Configuring 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, IDP must be supported and enabled on the device.
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/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. These objects are also used to reduce false positives and to 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:
Verifying 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
Example: Configuring Attack Groups with Dynamic Attack Groups and Custom Attack Groups
This example shows how to configure attack groups with dynamic attack groups and custom attack groups in an IDP policy to protect an FTP or Telnet server.
Requirements
Before you begin, install the security package on the device only if one of the following statements is true:
Dynamic attack groups are configured.
Custom attack groups contain predefined attacks or attack groups.
If custom attack groups contain only custom attacks, the security package license is not required and the security package need not be installed on the device. To install the security package, you need an IDP security package license.
Overview
IDP contains a large number of predefined attack objects. To manage and organize IDP policies, attack objects can be grouped. An attack object group can contain two or more types of attack objects. The attack groups are classified as follows:
Dynamic attack group—Contains attack objects based on certain matching criteria. During a signature update, dynamic group membership is automatically updated based on the matching criteria for that group. For example, you can dynamically group the attacks related to a specific application using the dynamic attack group filters.
Custom attack group—Contains a list of attacks that are specified in the attack definition. A custom attack group can also contain specific predefined attacks, custom attacks, predefined attack groups, or dynamic attack groups. A custom attack group is static in nature as the attacks are specified in the group. Therefore, the attack group do not change when the security database is updated. The members can be predefined attacks or predefined attack groups from the signature database or other custom attacks and dynamic attack groups.
In this example we configure an attack group in an IDP policy to protect an FTP or Telnet server against custom and dynamic attacks.
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-attack-groups cust-group set security idp idp-policy idpengine rulebase-ips rule 1 match attacks dynamic-attack-groups dyn2 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 customftp severity info set security idp custom-attack customftp attack-type signature context ftp-username set security idp custom-attack customftp attack-type signature pattern .*guest.* set security idp custom-attack customftp attack-type signature direction client-to-server set security idp custom-attack-group cust-group group-members customftp set security idp custom-attack-group cust-group group-members ICMP:INFO:TIMESTAMP set security idp custom-attack-group cust-group group-members "TELNET - Major" set security idp custom-attack-group cust-group group-members dyn1 set security idp dynamic-attack-group dyn1 filters category values TROJAN set security idp dynamic-attack-group dyn2 filters direction expression and set security idp dynamic-attack-group dyn2 filters direction values server-to-client set security idp dynamic-attack-group dyn2 filters direction values client-to-server set security idp dynamic-attack-group dyn2 filters age-of-attack less-than value 7 set security idp dynamic-attack-group dyn2 filters vulnerability-type values Injection set security idp dynamic-attack-group dyn2 filters vendor Microsoft set security idp dynamic-attack-group dyn2 filters cvss-score less-than value 7 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 attack groups with dynamic attack groups and custom attack groups:
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# set rulebase-ips
Add rules to the rulebase.
[edit security idp idp-policy idpengine rulebase-ips] user@host# set 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 a match for the custom attack group.
[edit security idp idp-policy idpengine rulebase-ips rule 1] user@host# set match attacks custom-attack-groups cust-group
Specify a match for the dynamic attack group.
[edit security idp idp-policy idpengine rulebase-ips rule 1] user@host# set match attacks dynamic-attack-groups dyn2
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 customftp
Set the severity for the custom attack.
[edit security idp custom-attack customftp] user@host# set severity info
Set the attack type and context for the attack.
[edit security idp custom-attack customftp] user@host# set attack-type signature context ftp-username
Specify a pattern for the attack.
[edit security idp custom-attack customftp] user@host# set attack-type signature pattern .*guest.*
Specify a direction for the attack.
[edit security idp custom-attack customftp] user@host# set attack-type signature direction client-to-server
Specify a name for the custom attack group.
[edit security idp] user@host# set custom-attack-group cust-group
Specify a list of attacks or attack groups that belongs to the custom attack group.
[edit security idp custom-attack-group cust-group] user@host# set group-members customftp user@host# set group-members ICMP:INFO:TIMESTAMP user@host# set group-members "TELNET - Major" user@host# set group-members dyn1
Specify a name for the first dynamic attack group.
[edit security idp] user@host# set dynamic-attack-group dyn1
Configure a filter and set a category value for the filter.
[edit security idp dynamic-attack-group dyn1 ] user@host# set filters category values TROJAN
Specify a name for the second dynamic attack group.
[edit security idp] user@host# set dynamic-attack-group dyn2
Configure a filter for the second dynamic attack group and set the direction and its values for this field.
[edit security idp dynamic-attack-group dyn2 ] user@host# set filters direction expression and user@host# set filters direction values server-to-client user@host# set filters direction values client-to-server user@host# set filters age-of-attack less-than value 7 user@host# set filters cvss-score less-than value 7 user@host# set filters file-type MPEG user@host# set filters vendor Microsoft user@host# set filters vulnerability-type values Injection
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 that 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-attack-groups cust-group;
dynamic-attack-groups dyn2;
}
}
then {
action {
no-action;
}
notification {
log-attacks;
}
}
}
}
}
active-policy idpengine;
custom-attack customftp {
severity info;
attack-type {
signature {
context ftp-username;
pattern .*guest.*;
direction client-to-server;
}
}
}
custom-attack-group cust-group {
group-members [ customftp ICMP:INFO:TIMESTAMP "TELNET - Major" dyn1 ];
}
dynamic-attack-group dyn1 {
filters {
category {
values TROJAN;
}
}
}
dynamic-attack-group dyn2 {
filters {
direction {
expression and;
values [ server-to-client client-to-server ];
}
age-of-attack less-than
{
value 7;
}
vulnerability-type
{
values Injection;
}
vendor Microsoft;
cvss-score less-than
{
value 7;
}
}
}
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
Verifying the Configuration
Purpose
Verify that the 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 which will 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
Custom Attack Object DFA Expressions
Table 25 provides examples of syntax for matching an attack pattern.
Example Syntax |
Description |
Example Matches |
|---|---|---|
Hello..\B.0.1..00\B...world |
There are two aspects to matching: Must match the bitmask pattern: \B.0.0.1..00\B Must match the number of bytes (signified by .) before and after the bitmask pattern. |
Matches: Hello..\B.0.11100\B...worldHello..\B.0.10000\B...world Does not match: Hello.\B.0.1..00\B.worldHello..\B.0.1..11\B...world |
\X01 86 A5 00 00\X |
Pattern with the five specified bytes verbatim. |
01 86 A5 00 00 |
(hello|world) |
Pattern with hello or world occurring once. |
hello world |
(hello|world)+ |
Pattern with hello or world occurring one or more times. |
helloworld worldhello hellohello |
\[hello\] |
Pattern hello, case insensitive. |
hElLo HEllO heLLO |
\uHello\u |
Pattern hello, Unicode insensitive. |
hello 68656c6c6f |
hello\sworld |
Pattern hello world, the two words separated by a whitespace. |
hello world |
[c-e]a(d|t) |
Pattern with the first letter of c, d, or e; the middle letter a; and ending in d or t. |
cat dad eat |
[^c-d]a(d|t) |
Pattern that begins a letter other than c, d, or e; have the second letter a; and end in d or t. |
fad zad |
a*b+c |
Pattern with any number of a characters (including zero); followed by one or more b characters; followed by a c character. |
bc abc aaaabbbbc |
T[Kk] |
Pattern that begins with an uppercase T, followed by a case-insensitive k. |
TK Tk |
([Tt])k |
Pattern that begins with a case-insensitive t, followed by a lowercase k. |
Tk Tk |
Sea[In] |
Pattern that begins with Sea, followed by a lowercase l, m, or n. |
Seal Seam Sean |
([B-D])at |
Pattern that begins with an uppercase B, C, or D, followed by a lowercase at. |
Bat Cat Dat |
\0133\[hello\]\0135 |
Pattern that begins with an opening bracket, followed by case-insensitive hello, ending with a closing bracket. This expression uses the \0 expression to signify that the following expression is an octal code, then the octal code for the opening bracket (133) or the closing bracket (135) follows. |
[hello] [HeLLo] |
Example: Using Pattern Negation
You can use pattern negation to exclude a pattern known to be safe and to match all else.
For example, suppose you are designing an attack object to inspect traffic to an FTP server. You know that account username and passwords are well maintained to ensure that only authorized users can access internal resources. However, as networks grow and new components are added, user accounts can proliferate, thereby increasing network access to specific components. In this example, you have an FTP server on your internal network that has multiple user accounts enabled. To improve security, you want to restrict access to the FTP administrator.
You create an attack object for the FTP service, ftp-username context, and pattern admin; and you select the Negate check box. The result is an attack object that can flag login attempts by users other than admin. You can use this attack object in a rule that logs or drops matching traffic.
See Also
Example: Matching File Extensions
In this example, you want to detect Microsoft Windows metafiles, which use the extensions .emf (Windows Enhanced Metafiles) and .wmf (Microsoft Windows Metafile).
To match either of these file types, use a simple DFA expression:
.*\.\[w|emf\]
In this expression:
The period combined with the asterisk (.*) indicates that one or more characters must appear (wildcard match).
The backslash combined with the period character (\.) indicates that the period character is escaped (the period appears in the pattern).
The parentheses at the beginning and end of the expression ( ) indicate a group. The pipe character between the e and the w (e|w) indicates an OR relationship between the characters. For this expression, e or w must appear in the pattern to match this expression; only one must be present.
The opening bracket (\[) indicates the beginning of a case-insensitive match for all characters until the closing bracket (\]) appears.
The closing bracket (\]) indicates the ending of a case-insensitive match.
See Also
Example: Apache Tomcat Denial-of-Service Attacks
In this example, we assume you have a Web Server running Apache Tomcat. Your security administrator notifies you that a vulnerability has just been announced for Apache Tomcat, and you decide to create a custom attack object to protect your network until you can schedule downtime to patch the server.
The CVE advisory for the vulnerability (http://nvd.nist.gov/nvd.cfm?cvename=CAN-2002-0682) contains the following quotation:
A cross-site scripting vulnerability in Apache Tomcat 4.0.3 allows remote attackers to execute script as other web users via script in a URL with the /servlet/ mapping, which does not filter the script when an exception is thrown by the servlet.
From this information, you know that the attack uses HTTP. Now you must locate the attack code. The advisory also includes references that link to more information about the attack. Unfortunately, none of the referenced Web pages contain exploit code. After searching the Web using the information you learned from the CVE advisory, you locate some exploit code at http://packetstormsecurity.nl/0210-exploits/neuter.c. Copy the script and move it to the attacker computer in your test lab.
To develop this attack object:
See Also
Listing IDP Test Conditions for a Specific Protocol
When configuring IDP custom attacks, you can specify list test conditions for a specific protocol. To list test conditions for ICMP:
List supported test conditions for ICMP and choose the one you want to configure. The supported test conditions are available in the CLI at the
[edit security idp custom-attack test1 attack-type anomaly]hierarchy level.user@host#set test icmp? Possible completions: <test> Protocol anomaly condition to be checked ADDRESSMASK_REQUEST DIFF_CHECKSUM_IN_RESEND DIFF_CHECKSUM_IN_RESPONSE DIFF_LENGTH_IN_RESEND
Configure the service for which you want to configure the test condition.
user@host# set service ICMP
Configure the test condition (specifying the protocol name is not required).
user@host# set test ADDRESSMASK_REQUEST
If you are done configuring the device, enter
commitfrom configuration mode.
Understanding IDP Protocol Decoders
Protocol decoders are used by Intrusion Detection and Prevention (IDP) to check protocol integrity and protocol contextual information by looking for anomalies and ensuring that RFC standards are met. An anomaly can be any part of a protocol, such as the header, message body, or other individual fields that deviate from RFC standards for that protocol. For example, in the case of SMTP, if SMTP MAIL TO precedes SMTP HELO, that is an anomaly in the SMTP protocol.
When protocol contextual information is available, protocol decoders check for attacks within those contexts. For example, for SMTP, if an e-mail is sent to user@company.com, user@company.com is the contextual information and SMTP MAIL TO is the context. By using protocol contextual data, rather than the entire packet, for attack detection, protocol decoders improve overall performance and accuracy.
If there is a policy configured with a rule that matches the protocol decoder check for SMTP, the rule triggers and the appropriate action is taken.
The IDP module ships with a preconfigured set of protocol decoders. These protocol decoders have default settings for various protocol-specific contextual checks they perform. You can use these defaults or you can tune them to meet your site’s specific needs. To display the list of available protocol decoders, enter the following command:
user@host # show security idp sensor-configuration detector protocol-name ?
For a more detailed view of the current set of protocol decoders and their default context values, you can view thedetector-capabilities.xml file located in the /ar/db/idpd/sec-download folder on the device. When you download a new security package, you also receive this file which lists current protocols and default decoder context values.
Example: UNIX CDE/dtlogin Vulnerability
In this example, your network includes several user workstations and servers running UNIX. Many UNIX operating systems use the Common Desktop Environment (CDE) as a graphical user interface. Your security administrator notifies you of a new vulnerability in the dtlogin process for CDE (the dtlogin process handles a GUI login process to CDE).
The CERT advisory for the vulnerability (http://www.kb.cert.org/vuls/id/179804) contains the following information:
...The dtlogin program contains a "double-free" vulnerability that can be triggered by a specially crafted X Display Manager Control Protocol (XDMCP) packet... Block XDMCP traffic (177/udp) from untrusted networks such as the Internet...
From this information, you know that the attack uses XDMCP protocol packet, and runs on UDP/177. Now you must locate the attack code. The advisory also includes references that link to more information about the attack. One reference, http://lists.immunitysec.com/pipermail/dailydave/2004-March/000402.html, indicates that the person who first reported the attack has also written a script that replicates the attack. Obtain the script and move it to the attacker computer in your test lab.
To develop this attack object:
See Also
Example: Detecting a Worm
Worms and Trojans often bypass firewalls and other traditional security measures to enter a network. In this example, you create a custom attack object to detect the Blaster worm on your network.
The CERT advisory (http://www.cert.org/advisories/CA-2003-20.html) for the Blaster worm gives the following information:
The W32/Blaster worm exploits a vulnerability in Microsoft's DCOM RPC interface...”
From this information, you know that the attack uses DCOM exploit, a previously identified security hole. Now you must locate the attack code. The advisory also includes references that link to more information about the attack. Unfortunately, none of the referenced Web pages contain exploit code. After searching the Web using the information you learned from the CERT advisory, you locate exploit code on PacketStorm (http://packetstormsecurity.com/0307-exploits/dcom.c).
To develop this attack object:
See Also
Example: Compound Signature to Detect Exploitation of an HTTP Vulnerability
Some attacks are crafted to appear benign when viewed at a packet-by-packet level. For these attacks, you can create a compound signature that detects multiple signature patterns in multiple contexts (service, nonservice, or both).
In this example, you have a Web server that uses Microsoft FrontPage Server extensions. Your security administrator notifies you of a new buffer overflow vulnerability in the FrontPage Server extensions.
The BugTraq advisory for the vulnerability (http://www.securityfocus.com/bid/9007/discussion/) contains the following information:
Microsoft FrontPage Server Extensions are prone to a remotely exploitable buffer overrun vulnerability ... It is possible to trigger this condition with a chunked-encoded HTTP POST request...
The following proof-of-concept example is also provided:
POST /_vti_bin/_vti_aut/fp30reg.dll HTTP/1.1 Transfer-Encoding: chunked PostLength PostData 0
Additionally, a link to the compiled exploit is included.
From this information, you know that the attack uses the HTTP protocol and that at least part of the attack uses the POST method. Use the link to the compiled exploit to obtain the script, and move it to the attacker computer in your test lab.
To develop this attack object:
See Also
Example: Using Time Binding Parameters to Detect a Brute Force Attack
The time binding constraint requires the pattern to occur a certain number of times within a minute in order for the traffic to be considered a match.
You can use the time binding parameter along with the signature to detect signs of a brute force attack. A user changing her password is a harmless event, and is normally seen occasionally on the network. However, thousands of password changes in a minute is suspicious.
In a brute force attack, the attacker attempts to break through system defenses using sheer force, typically by overwhelming the destination server capacity or by repeated, trial-and-error attempts to match authentication credentials. In a brute force login attack, the attackers first gather a list of usernames and a password dictionary. Next, the attacker uses a tool that enters the first password in dictionary for the first user in the list, then tries every password for every user until it gets a match. If the attacker tries every combination of usernames and passwords, they always succeed. However, brute force attacks often fail because the password dictionary is typically limited (does not contain all possible passwords) and the attack tool does not perform permutations on the password (such as reversing letters or changing case).
In this example, you create a signature attack object that detects an excessive number of password changes for users authenticated via HTTP (a Web-based application).
First, you configure an attack pattern:
.*/\[changepassword\.cgi\]
In this expression:
The dot star combination (.*) indicates a wildcard match.
The backslash before a character indicates that the character represents a regular expression and must be escaped. In this case, the character is an opening bracket. The backslash is also used in this expression before the file extension marker (the dot) and before the closing bracket.
The name of the cgi script that is used to change user passwords is included, as well as the cgi extension.
For context, select HTTP-URL-PARSED from the list because you are attempting to detect password changes that occur for Web-based applications. The changepassword.cgi script, when used, appears as part of the URL, but you need to tell the IDP Series device to parse the URL in order to find the name.
Next, you configure time binding.
In these settings:
Scope is set to Peer so the attack pattern can match the event regardless of source or destination.
Count is set to high number (to 1000) to avoid false positives. This value means that the changepassword.cgi script must appear in a URL 1000 times before the attack object is matched.
See Also
Reference: Custom Attack Object Protocol Numbers
Table 26 protocol numbers used in the IDP system.
Protocol Name |
Protocol Number |
|---|---|
HOPOPT |
0 |
ICMP |
1 |
IGMP |
2 |
GGP |
3 |
IPIP |
4 |
ST |
5 |
TCP |
6 |
CBT |
7 |
EGP |
8 |
IGP |
9 |
BBN-RCC-MON |
10 |
NVP-II |
11 |
PUP |
12 |
ARGUS |
13 |
EMCON |
14 |
XNET |
15 |
CHAOS |
16 |
UDP |
17 |
MUX |
18 |
DCN-MEAS |
19 |
HMP |
20 |
PRM |
21 |
XND-IDP |
22 |
TRUNK-1 |
23 |
TRUNK-2 |
24 |
LEAF-1 |
25 |
LEAF-2 |
26 |
RDP |
27 |
IRTP |
28 |
ISO-TP4 |
29 |
NETBLT |
30 |
MFE-NSP |
31 |
MERIT-INP |
32 |
SEP |
33 |
3PC |
34 |
IDPR |
35 |
XTP |
36 |
DDP |
37 |
TP_PLUS_PLUS |
39 |
IL |
40 |
IPV6 |
41 |
SDRP |
42 |
IPV6-ROUTING |
43 |
IDV6-FRAGMENT |
44 |
IDRP |
45 |
RSVP |
46 |
GRE |
47 |
MHRP |
48 |
BNA |
49 |
ESP |
50 |
AH |
51 |
I-NLSP |
52 |
SWIPE |
53 |
NARP |
54 |
MOBILE |
55 |
TLSP |
56 |
SKIP |
57 |
IPV6-ICMP |
58 |
IPV6-NONXT |
59 |
IPV6-OPTS |
60 |
AHIP |
61 |
CFTP |
62 |
ALNP |
63 |
SAT-EXPAK |
64 |
KRYPTOLAN |
65 |
RVD |
66 |
IPPC |
67 |
ADFSP |
68 |
SAT-MON |
69 |
VISA |
70 |
IPCV |
71 |
CPNX |
72 |
CPHB |
73 |
WSN |
74 |
PVP |
75 |
BR-SAT-MON |
76 |
SUN-ND |
77 |
WB-MON |
78 |
WB-EXPAK |
79 |
ISO-IP |
80 |
VMTP |
81 |
SECURE-VMTP |
82 |
VINES |
83 |
TTP |
84 |
NSFNET-IBP |
85 |
DGP |
86 |
TCF |
87 |
EIGRP |
88 |
OSPFIGP |
89 |
SPRITE-RPC |
90 |
LARP |
91 |
MTP |
92 |
AX_25 |
93 |
IPIP |
94 |
MICP |
95 |
SCC-SP |
96 |
ETHERIP |
97 |
ENCAP |
98 |
APES |
99 |
GMTP |
100 |
IFMP |
101 |
PNNI |
102 |
PIM |
103 |
ARIS |
104 |
SCPS |
105 |
QNX |
106 |
A/N |
107 |
IPCOMP |
108 |
SNP |
109 |
COMPAT-PEER |
110 |
IPZ-IN-IP |
111 |
VRRP |
112 |
PGM |
113 |
HOP-O |
114 |
L2TP |
115 |
DDX |
116 |
IATP |
117 |
STP |
118 |
SRP |
119 |
UTI |
120 |
SMP |
121 |
SSM |
122 |
PTP |
123 |
ISIS |
124 |
FIRE |
125 |
CRTP |
126 |
CRUDP |
127 |
SSCOPMCE |
128 |
IPLT |
129 |
SPS |
130 |
PIPE |
131 |
SCTP |
132 |
FC |
133 |
RSVP-E2E-IGNORE |
134 |
n/a |
|
n/a |
|
n/a |
|
RESERVED |
255 |
Reference: Nonprintable and Printable ASCII Characters
The following tables provide details on ASCII representation of nonprintable and printable characters.
Dec |
Hex |
Oct |
Char |
Comment |
|---|---|---|---|---|
0 |
0 |
000 |
NUL |
Null |
1 |
1 |
001 |
SOH |
Start of Heading |
2 |
2 |
002 |
STX |
Start of Text |
3 |
3 |
003 |
ETX |
End of Text |
4 |
4 |
004 |
EOT |
End of Transmission |
5 |
5 |
005 |
ENQ |
Enquiry |
6 |
6 |
006 |
ACK |
Acknowledge |
7 |
7 |
007 |
BEL |
Bell |
8 |
8 |
010 |
BS |
Backspace |
9 |
9 |
011 |
TAB |
Horizontal Tab |
10 |
A |
012 |
LF |
Line Feed |
11 |
B |
013 |
VT |
Vertical Tab |
12 |
C |
014 |
FF |
Form Feed |
13 |
D |
015 |
CR |
Carriage Return |
14 |
E |
016 |
SO |
Shift Out |
15 |
F |
017 |
SI |
Shift In |
16 |
10 |
020 |
DLE |
Data Link Escape |
17 |
11 |
021 |
DC1 |
Device Control 1 |
18 |
12 |
022 |
DC2 |
Device Control 2 |
19 |
13 |
023 |
DC3 |
Device Control 3 |
20 |
14 |
024 |
DC4 |
Device Control 4 |
21 |
15 |
025 |
NAK |
Negative Acknowledgement |
22 |
16 |
026 |
SYN |
Synchronous Idle |
23 |
17 |
027 |
ETB |
End of Transmission Block |
24 |
18 |
030 |
CAN |
Cancel |
25 |
19 |
031 |
EM |
End of Medium |
26 |
1A |
032 |
SUB |
Substitute |
27 |
1B |
033 |
ESC |
Escape |
28 |
1C |
034 |
FS |
File Separator |
29 |
1D |
035 |
GS |
Group Separator |
30 |
1E |
036 |
RS |
Record Separator |
31 |
1F |
037 |
US |
Unit Separator |
Dec |
Hex |
Oct |
Char |
|---|---|---|---|
32 |
20 |
040 |
Space |
33 |
21 |
041 |
! |
34 |
22 |
042 |
|
35 |
23 |
043 |
# |
36 |
24 |
044 |
$ |
37 |
25 |
045 |
% |
38 |
26 |
046 |
& |
39 |
27 |
047 |
|
40 |
28 |
050 |
( |
41 |
29 |
051 |
) |
42 |
2A |
052 |
* |
43 |
2B |
053 |
+ |
44 |
2C |
054 |
, |
45 |
2D |
055 |
- |
46 |
2E |
056 |
. |
47 |
2F |
057 |
/ |
48 |
30 |
060 |
0 |
49 |
31 |
061 |
1 |
50 |
32 |
062 |
2 |
51 |
33 |
063 |
3 |
52 |
34 |
064 |
4 |
53 |
35 |
065 |
5 |
54 |
36 |
066 |
6 |
55 |
37 |
067 |
7 |
56 |
38 |
070 |
8 |
57 |
39 |
071 |
9 |
58 |
3A |
072 |
: |
59 |
3B |
073 |
; |
60 |
3C |
074 |
< |
61 |
3D |
075 |
= |
62 |
3E |
076 |
> |
63 |
3F |
077 |
? |
64 |
40 |
100 |
@ |
65 |
41 |
101 |
A |
66 |
42 |
102 |
B |
67 |
43 |
103 |
C |
68 |
44 |
104 |
D |
69 |
45 |
105 |
E |
70 |
46 |
106 |
F |
71 |
47 |
107 |
G |
72 |
48 |
110 |
H |
73 |
49 |
111 |
I |
74 |
4A |
112 |
J |
75 |
4B |
113 |
K |
76 |
4C |
114 |
L |
77 |
4D |
115 |
M |
78 |
4E |
116 |
N |
79 |
4F |
117 |
O |
80 |
50 |
120 |
P |
81 |
51 |
121 |
Q |
82 |
52 |
122 |
R |
83 |
53 |
123 |
S |
'84 |
54 |
124 |
T |
85 |
55 |
125 |
U |
86 |
56 |
126 |
V |
87 |
57 |
127 |
W |
88 |
58 |
130 |
X |
89 |
59 |
131 |
Y |
90 |
5A |
132 |
Z |
91 |
5B |
133 |
[ |
92 |
5C |
134 |
\ |
93 |
5D |
135 |
] |
94 |
5E |
136 |
^ |
95 |
5F |
137 |
_ |
96 |
60 |
140 |
` |
97 |
61 |
141 |
a |
98 |
62 |
142 |
b |
99 |
63 |
143 |
c |
100 |
64 |
144 |
d |
101 |
65 |
145 |
e |
102 |
66 |
146 |
f |
103 |
67 |
147 |
g |
104 |
68 |
150 |
h |
105 |
69 |
151 |
I |
106 |
6A |
152 |
j |
107 |
6B |
153 |
k |
108 |
6C |
154 |
l |
109 |
6D |
155 |
m |
110 |
6E |
156 |
n |
111 |
6F |
157 |
o |
112 |
70 |
160 |
p |
113 |
71 |
161 |
q |
114 |
72 |
162 |
r |
115 |
73 |
163 |
s |
116 |
74 |
164 |
t |
117 |
75 |
165 |
u |
118 |
76 |
166 |
v |
119 |
77 |
167 |
w |
120 |
78 |
170 |
x |
121 |
79 |
171 |
y |
122 |
7A |
172 |
z |
123 |
7B |
173 |
{ |
124 |
7C |
174 |
| |
125 |
7D |
175 |
} |
126 |
7E |
176 |
~ |
127 |
7F |
177 |
DEL |
128 |
80 |
200 |
Ç |
129 |
81 |
201 |
ü |
130 |
82 |
202 |
é |
131 |
83 |
203 |
â |
132 |
84 |
204 |
ä |
133 |
85 |
205 |
à |
134 |
86 |
206 |
å |
135 |
87 |
207 |
ç |
136 |
88 |
210 |
ê |
137 |
89 |
211 |
ë |
138 |
8A |
212 |
è |
139 |
8B |
213 |
ï |
140 |
8C |
214 |
î |
141 |
8D |
215 |
ì |
142 |
8E |
216 |
Ä |
143 |
8F |
217 |
Å |
144 |
90 |
220 |
É |
145 |
91 |
221 |
æ |
146 |
92 |
222 |
Æ |
147 |
93 |
223 |
ô |
148 |
94 |
224 |
ö |
149 |
95 |
225 |
ò |
150 |
96 |
226 |
û |
151 |
97 |
227 |
ù |
152 |
98 |
230 |
ÿ |
153 |
99 |
231 |
Ö |
154 |
9A |
232 |
Ü |
155 |
9B |
233 |
¢ |
156 |
9C |
234 |
£ |
157 |
9D |
235 |
¥ |
158 |
9E |
236 |
P |
159 |
9F |
237 |
ƒ |
160 |
A0 |
240 |
á |
161 |
A1 |
241 |
í |
162 |
A2 |
242 |
ó |
163 |
A3 |
243 |
ú |
164 |
A4 |
244 |
ñ |
165 |
A5 |
245 |
Ñ |
166 |
A6 |
246 |
ª |
167 |
A7 |
247 |
º |
168 |
A8 |
250 |
¿ |
169 |
A9 |
251 |
¬ |
170 |
AA |
252 |
|
171 |
AB |
253 |
½ |
172 |
AC |
254 |
¼ |
173 |
AD |
255 |
¡ |
174 |
AE |
256 |
" |
175 |
AF |
257 |
" |
176 |
B0 |
260 |
¦ |
177 |
B1 |
262 |
¦ |
178 |
B2 |
262 |
¦ |
179 |
B3 |
263 |
¦ |
180 |
B4 |
264 |
¦ |
181 |
B5 |
265 |
¦ |
182 |
B6 |
266 |
¦ |
183 |
B7 |
267 |
+ |
184 |
B8 |
270 |
+ |
185 |
B9 |
271 |
¦ |
186 |
BA |
272 |
¦ |
187 |
BB |
273 |
+ |
188 |
BC |
274 |
+ |
189 |
BD |
275 |
+ |
190 |
BE |
276 |
+ |
191 |
BF |
277 |
+ |
192 |
C0 |
300 |
+ |
193 |
C1 |
301 |
- |
194 |
C2 |
302 |
- |
195 |
C3 |
303 |
+ |
196 |
C4 |
304 |
- |
197 |
C5 |
305 |
+ |
198 |
C6 |
306 |
¦ |
199 |
C7 |
307 |
¦ |
200 |
C8 |
310 |
+ |
201 |
C9 |
311 |
+ |
202 |
CA |
312 |
- |
203 |
CB |
313 |
- |
204 |
CC |
314 |
¦ |
205 |
CD |
315 |
- |
206 |
CE |
316 |
+ |
207 |
CF |
317 |
- |
208 |
D0 |
320 |
- |
209 |
D1 |
321 |
- |
210 |
D2 |
322 |
- |
211 |
D3 |
323 |
+ |
212 |
D4 |
324 |
+ |
213 |
D5 |
325 |
+ |
214 |
D6 |
326 |
+ |
215 |
D7 |
327 |
+ |
216 |
D8 |
330 |
+ |
217 |
D9 |
331 |
+ |
218 |
DA |
332 |
+ |
219 |
DB |
333 |
¦ |
220 |
DC |
334 |
_ |
221 |
DD |
335 |
¦ |
222 |
DE |
336 |
¦ |
223 |
DF |
337 |
¯ |
224 |
E0 |
340 |
a |
225 |
E1 |
341 |
ß |
226 |
E2 |
342 |
G |
227 |
E3 |
343 |
p |
228 |
E4 |
344 |
S |
229 |
E5 |
345 |
s |
230 |
E6 |
346 |
µ |
231 |
E7 |
347 |
t |
232 |
E8 |
350 |
F |
233 |
E9 |
351 |
T |
234 |
EA |
352 |
O |
235 |
EB |
353 |
d |
236 |
EC |
354 |
8 |
237 |
ED |
355 |
f |
238 |
EE |
356 |
e |
239 |
EF |
357 |
n |
240 |
F0 |
360 |
= |
241 |
F1 |
361 |
+/- |
242 |
F2 |
362 |
= |
243 |
F3 |
363 |
= |
244 |
F4 |
364 |
( |
245 |
F5 |
365 |
) |
246 |
F6 |
366 |
÷ |
247 |
F7 |
367 |
˜ |
248 |
F8 |
370 |
° |
249 |
F9 |
371 |
﹒ |
250 |
FA |
372 |
﹒ |
251 |
FB |
373 |
v |
252 |
FC |
374 |
n |
253 |
FD |
375 |
² |
254 |
FE |
376 |
¦ |
255 |
FF |
377 |
|
Example: Configuring IDP Protocol Decoders
This example shows how to configure IDP protocol decoder tunables.
Requirements
Before you begin, review the IDP protocol decoders feature. See Understanding IDP Protocol Decoders.
Overview
The Junos IDP module ships with a set of preconfigured protocol decoders. These protocol decoders have default settings for various protocol-specific contextual checks that they perform. You can use the default settings or tune them to meet your site's specific needs. This example shows you how to tune the protocol decoder for FTP.
Configuration
Procedure
Step-by-Step Procedure
To configure IDP protocol decoder tunables:
View the list of protocols that have tunable parameters.
[edit] user@host# edit security idp sensor-configuration detector protocol-name FTP
Configure tunable parameters for the FTP protocol.
[edit security idp sensor-configuration-detector protocol-name FTP] user@host# set tunable-name sc_ftp_failed_logins tunable-value 4 user@host# set tunable-name sc_ftp_failed_flags tunable value 1 user@host# set tunable-name sc_ftp_line_length tunable-value 1024 user@host# set tunable-name sc_ftp_password_length tunable-value 64 user@host# set tunable-name sc_ftp_sitestring_length tunable-value 512 user@host# set tunable-name sc_ftp_username_length tunable-value 32
If you are done configuring the device, commit the configuration.
[edit] user@host# commit
Verification
To verify the configuration is working properly,
enter the show security idp status command.
Understanding Multiple IDP Detector Support
When a new security package is received, it contains attack definitions and a detector. In any given version of a security package, the attack definitions correspond to the capabilities of the included detector. When policy aging is disabled on the device (see the reset-on-policy statement for policy aging commands), only one policy is in effect at any given time. But if policy aging is enabled and there is a policy update, the existing policy is not unloaded when the new policy is loaded. Therefore, both policies can be in effect on the device. In this case, all existing sessions will continue to be inspected by existing policies and new sessions are inspected with new policies. Once all the existing sessions using the older policy have terminated or expired, the older policy is then unloaded.
When a policy is loaded, it is also associated with a detector. If the new policy being loaded has an associated detector that matches the detector already in use by the existing policy, the new detector is not loaded and both policies use a single associated detector. But if the new detector does not match the current detector, the new detector is loaded along with the new policy. In this case, each loaded policy will then use its own associated detector for attack detection.
Note that a maximum of two detectors can be loaded at any given time. If two detectors are already loaded (by two or more policies), and loading a new policy requires also loading a new detector, then at least one of the loaded detectors must be unloaded before the new detector can be loaded. Before a detector is unloaded, all policies that use the corresponding detector are unloaded as well.
You can view the current policy and corresponding detector version by entering the following command:
user@host> show security idp status
Starting in Junos OS Release 18.4R1, when a new IDP policy is loaded, the existing sessions are inspected using the newly loaded policy and the existing sessions not ignored for IDP processing. The IDP inspection continues for context-based attacks created by the detector after a new IDP policy is loaded, with an exception that the new policy that is loaded with the new detector.
Understanding Content Decompression
In application protocols like HTTP, the content could be compressed and then transmitted over the network. The patterns will not match the compressed content, because the signature patterns are written to match the unencoded traffic data. In this case IDP detection is evaded. To avoid IDP detection evasion on the HTTP compressed content, an IDP submodule has been added that decompresses the protocol content. The signature pattern matching is done on the decompressed content.
To display the status of all IPS counter values, enter the following command:
user@host> show security idp counters ips
Some attacks are introduced through compressed content. When
the content is decompressed, it can inflate to a very large size taking
up valuable system resources resulting in denial of service. This
type of attack can be recognized by the ratio of decompressed data
size to compressed data size. The content-decompress-ratio-over-limit
counter identifies the number of incidents where this ratio has been
exceeded. The default ratio is considered consistent with a typical
environment. In some cases, however, this ratio might need to be adjusted
by resetting the content-decompress-ratio-over-limit value.
Keep in mind, however, that a higher ratio lessens the chance of detecting
this type of attack.
The content-decompress-memory-over-limit counter identifies
the number of incidents where the amount of decompressed data exceeded
the allocated memory. The default memory allocation provides 33 KB
per session for an average number of sessions requiring decompression
at the same time. To determine if this value is consistent with your
environment, analyze values from decompression-related counters and
the total number of IDP sessions traversing the device, and estimate
the number of sessions requiring decompression at the same time. Assuming
that each of these sessions requires 33 KB of memory for decompression,
compare your estimated needs to the default value. If necessary, you
can adjust the memory allocation by resetting the content-decompression-max-memory-kb value. Note that because content decompression requires a significant
allocation of memory, system performance will be impacted by increasing
the maximum memory allocation for decompression.
Example: Configuring IDP Content Decompression
This example shows how to configure IDP content decompression.
Requirements
Before you begin, review the IDP content decompression feature. See Understanding Content Decompression
Overview
The decompression feature is disabled by default. In this example, you enable the detector, configure the maximum memory to 50,000 kilobytes, and configure a maximum decompression ratio of 16:1.
Enabling decompression will result in a reduction in performance on your device.
Configuration
Procedure
Step-by-Step Procedure
To configure IDP content decompression:
Enable the detector.
[edit] user@host# set security idp sensor‑configuration detector protocol‑name HTTP tunable‑name sc_http_compress_inflating tunable‑value 1
Note:To disable the detector, set the
tunable‑valueto 0.If necessary, modify the maximum memory in kilobytes.
[edit security idp] user@host# set sensor-configuration ips content-decompression-max-memory-kb 50000
If necessary, configure the maximum decompression ratio.
[edit security idp] user@host# set sensor-configuration ips content-decompression-max-ratio 16
If you are done configuring the device, commit the configuration.
[edit] user@host# commit
Verification
To verify the configuration is working properly,
enter the show security idp status ips command. The content-decompress
counters provide statistics on decompression processing.
Understanding IDP Signature-Based Attacks
To configure a custom attack object, you specify a unique name for it and then specify additional information, 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, severity level, service or application binding, time binding, and protocol or port binding. Some fields are specific to an attack type and are available only for that specific attack definition.
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, attack direction, attack pattern, and protocol-specific parameters (TCP, UDP, ICMP, or IP header fields).
When configuring signature-based attacks, keep the following in mind:
Attack context and direction are mandatory fields for the signature attack definition.
Pattern negation is supported for packet, line, and application-based contexts only and not for stream and normalized stream contexts.
When configuring the protocol-specific parameters, you can specify fields for only one of the following protocols—IP, TCP, UDP, or ICMP.
When configuring a protocol binding, you can specify only one of the following—IP, ICMP, TCP, UDP, RPC or applications.
IP—Protocol number is a mandatory field.
TCP and UDP—You can specify either a single port (
minimum-port) or a port range (minimum-portandmaximum-port). If you do not specify a port, the default value is taken (0-65535).RPC—Program number is a mandatory field.
Starting in Junos OS Release 19.1R1, you can configure signature-based attacks by using Hyperscan extended parameters. By setting optimal values for the Hyperscan extended parameters, you can enhance the attack pattern matching process significantly.
To configure the extended parameters, include the optional-parameters option at the [edit security idp custom-attack attack-name attack-type signature] hierarchy level.
You can configure the following parameters under the optional-parameters option:
min-offsetmax-offsetmin-length
Brief working principle of Hyperscan API – Hyperscan is a software regular expression matching engine designed to deliver high performance and flexibility. When a signature with a pattern is configured as part of an IDP policy, the pattern is identified as a regular expression. On the Routing Engine, Hyperscan takes this regular expression as an input and compiles it to form a database which is pushed to the Packet Forwarding Engine. When a packet enters the Packet Forwarding Engine, the data in the packet is inspected to determine if it is matching the regular expression using the database.
If an IDP policy is configured with a set of signatures, deterministic finite automaton (DFA) groups are formed. Patterns of all the signatures in the DFA groups are passed to Hyperscan to form a single database, which can be used to check all the attacks in the packet at a time. Since a single database is used instead of a separate database for each attack, the pattern matching process is efficient.
When a signature is configured with the extended parameters, Hyperscan API forms the database by taking the configured parameters into consideration. The pattern matching process occurs on the Packet Forwarding Engine with this new database. These parameters allow the set of matches produced by a pattern to be constrained at compile time rather than relying on the application to process unwanted matches at runtime.
See Also
Example: Configuring IDP Signature-Based Attacks
This example shows how to create a signature-based attack object.
Requirements
Before you begin, configure network interfaces.
Overview
In this example, you create a signature attack called sig1 and assign it the following properties:
Recommended action (drop packet)—Drops a matching packet before it can reach its destination but does not close the connection.
Time binding—Specifies the scope as
sourceand the count as10. When scope issource, all attacks from the same source are counted, and when the number of attacks reaches the specified count (10), the attack is logged. In this example, every tenth attack from the same source is logged.Attack context (packet)—Matches the attack pattern within a packet.
Attack direction (any)—Detects the attack in both directions—client-to-server and server-to-client traffic.
Protocol (TCP)—Specifies the TTL value of 128.
Shellcode (Intel)—Sets the flag to detect shellcode for Intel platforms.
Protocol binding—Specifies the TCP protocol and ports 50 through 100.
Once you have configured a signature-based attack object, you specify the attack as match criteria in an IDP policy rule. See Example: Defining Rules for an IDP IPS RuleBase.
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 custom-attack sig1 severity major set security idp custom-attack sig1 recommended-action drop-packet set security idp custom-attack sig1 time-binding scope source count 10 set security idp custom-attack sig1 attack-type signature context packet set security idp custom-attack sig1 attack-type signature shellcode intel set security idp custom-attack sig1 attack-type signature protocol ip ttl value 128 match equal set security idp custom-attack sig1 attack-type signature protocol-binding tcp minimum-port 50 maximum-port 100 set security idp custom-attack sig1 attack-type signature direction any
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 create a signature-based attack object:
Specify a name for the attack.
[edit] user@host# edit security idp custom-attack sig1
Specify common properties for the attack.
[edit security idp custom-attack sig1] user@host# set severity major user@host# set recommended-action drop-packet user@host# set time-binding scope source count 10
Specify the attack type and context.
[edit security idp custom-attack sig1] user@host# set attack-type signature context packet
Specify the attack direction and the shellcode flag.
[edit security idp custom-attack sig1] user@host# set attack-type signature shellcode intel
Set the protocol and its fields.
[edit security idp custom-attack sig1] user@host# set attack-type signature protocol ip ttl value 128 match equal
Specify the protocol binding and ports.
[edit security idp custom-attack sig1] user@host# set attack-type signature protocol-binding tcp minimum-port 50 maximum-port 100
Specify the direction.
[edit security idp custom-attack sig1] user@host# set attack-type signature direction any
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
custom-attack sig1 {
recommended-action drop-packet;
severity major;
time-binding {
count 10;
scope source;
}
attack-type {
signature {
protocol-binding {
tcp {
minimum-port 50 maximum-port 100;
}
}
context packet;
direction any;
shellcode intel;
protocol {
ip {
ttl {
match equal;
value 128;
}
}
}
}
}
}
If you are done configuring the device, enter commit from configuration mode.
Understanding IDP Protocol Anomaly-Based 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 following properties are specific to protocol anomaly attacks:
Attack direction
Test condition
When configuring protocol anomaly-based attacks, keep the following in mind:
The service or application binding is a mandatory field for protocol anomaly attacks. Besides the supported applications, services also include IP, TCP, UDP, ICMP, and RPC.
The attack direction and test condition properties are mandatory fields for configuring anomaly attack definitions.
Example: Configuring IDP Protocol Anomaly-Based Attacks
This example shows how to create a protocol anomaly-based attack object.
Requirements
Before you begin, configure network interfaces.
Overview
In this example, you create a protocol anomaly attack called anomaly1 and assign it the following properties:
Time binding—Specifies the scope as
peerand count as2to detect anomalies between source and destination IP addresses of the sessions for the specified number of times.Severity (info)—Provides information about any attack that matches the conditions.
Attack direction (any)—Detects the attack in both directions—client-to-server and server-to-client traffic.
Service (TCP)—Matches attacks using the TCP service.
Test condition (OPTIONS_UNSUPPORTED)—Matches certain predefined test conditions. In this example, the condition is to match if the attack includes unsupported options.
Shellcode (sparc)—Sets the flag to detect shellcode for Sparc platforms.
Once you have configured the protocol anomaly-based attack object, you specify the attack as match criteria in an IDP policy rule. See Example: Defining Rules for an IDP IPS RuleBase.
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 custom-attack anomaly1 severity info set security idp custom-attack anomaly1 time-binding scope peer count 2 set security idp custom-attack anomaly1 attack-type anomaly test OPTIONS_UNSUPPORTED set security idp custom-attack sa set security idp custom-attack sa attack-type anomaly service TCP set security idp custom-attack sa attack-type anomaly direction any set security idp custom-attack sa attack-type anomaly shellcode sparc
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 create a protocol anomaly-based attack object:
Specify a name for the attack.
[edit] user@host# edit security idp custom-attack anomaly1
Specify common properties for the attack.
[edit security idp custom-attack anomaly1] user@host# set severity info user@host# set time-binding scope peer count 2
Specify the attack type and test condition.
[edit security idp custom-attack anomaly1] user@host# set attack-type anomaly test OPTIONS_UNSUPPORTED
Specify other properties for the anomaly attack.
[edit security idp custom-attack anomaly1] user@host# set attack-type anomaly service TCP user@host# set attack-type anomaly direction any user@host# attack-type anomaly shellcode sparc
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
custom-attack anomaly1 {
severity info;
time-binding {
count 2;
scope peer;
}
attack-type {
anomaly {
test OPTIONS_UNSUPPORTED;
service TCP;
direction any;
shellcode sparc;
}
}
}
If you are done configuring the device, enter commit from configuration mode.
IDP Policy Configuration Overview
The Junos OS Intrusion Detection and Prevention (IDP) policy enables you to selectively enforce various attack detection and prevention techniques on network traffic passing through an IDP-enabled device. It allows you to define policy rules to match a section of traffic based on a zone, network, and application, and then take active or passive preventive actions on that traffic.
An IDP policy defines how your device handles the network traffic. It allows you to enforce various attack detection and prevention techniques on traffic traversing your network.
A policy is made up of rule bases, and each rule base contains a set of rules. You define rule parameters, such as traffic match conditions, action, and logging requirements, then add the rules to rule bases. After you create an IDP policy by adding rules in one or more rule bases, you can select that policy to be the active policy on your device.
To configure the IDP policy perform the following steps:
Enable IDP in a security policy.
Configure IDP policy rules, IDP rule bases, and IDP rule actions. See Example: Inserting a Rule in the IDP Rulebase , Example: Defining Rules for an IDP IPS RuleBase, and Example: Configuring and Applying Rewrite Rules on a Security Device topics.
Configure IDP custom signatures. See Understanding IDP Signature-Based Attacks and Example: Configuring IDP Signature-Based Attacks topics.
Update the IDP signature database. See Updating the IDP Signature Database Overview.
IPv6 Covert Channels Overview
A covert channel is an attack technique that allows communication of information by transferring objects through existing information channels in an unauthorized or illicit manner . With the help of covert channels, an attacker can carry out malicious activity in a network.
Starting in Junos OS Release 19.1R1, covert channels identification and mitigation for IPv6 extension headers is supported on Intrusion Detection and Prevention (IDP). It is the transfer of information that violates the existing security systems. The security package for IDP contains a database of predefined IDP attack objects for covert channel that you can use in IDP policies to match traffic against attacks.
As part of this support, you can detect and flag IPv6 extension
headers anomalies, which can establish covert channels and take action
specified in the policy. The covert channel attacks are displayed
in the Show security idp attack table with the other attacks.
interval interval-value statement is introduced at the [edit security idp custom-attack attack-name time-binding] hierarchy to configure
a custom time-binding.set security idp custom-attack command.