Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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.

CAUTION:

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:

  1. 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.
  2. Push the policy to the IDP Series lab device.
  3. From the attacker computer, reproduce the attack that targets the victim computer.
  4. 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:

  1. In the Object Manager, select Attack Objects > IDP Objects.
  2. Click the Custom Attacks tab.
  3. Click the + icon to display the Custom Attack dialog box.
  4. Configure attack object settings. Table 1 provides guidelines for completing the settings.
    Table 1: Custom Attack Dialog Box: General Tab Settings

    Setting

    Description

    Name

    The name displayed in the UI.

    Tip:

    Include the protocol the attack uses as part of the attack name.

    Description

    (Optional) Information about the attack. Although a description is optional when you create a new attack object, it can help you remember important information about the attack. For examples, view the attack descriptions for predefined attacks.

    Severity

    Info, Warning, Minor, Major, or Critical. Critical attacks are attempts to crash your server or gain control of your network.

    • Critical—Contains attack objects matching exploits that attempt to evade detection, cause a network device to crash, or gain system-level privileges.

    • Info—Contains attack objects matching normal, harmless traffic containing URLs, DNS lookup failures, SNMP public community strings, and peer-to-peer (P2P) parameters. You can use informational attack objects to obtain information about your network.

    • Major—Contains attack objects matching exploits that attempt to disrupt a service, gain user-level access to a network device, or activate a Trojan horse previously loaded on a device.

    • Minor—Contains attack objects matching exploits that detect reconnaissance efforts attempting to access vital information through directory traversal or information leaks.

    • Warning—Contains attack objects matching exploits that attempt to obtain noncritical information or scan a network with a scanning tool.

    Informational attacks are the least dangerous and typically are used by network administrators to discover holes in their own security system.

    Category

    A predefined or new category. Use this category to group the attack objects. Within each category, attack objects are grouped by severity. For example: FTP, TROJAN, SNMP.

    Keywords

    Unique identifiers that can be used to search and sort log records. Keywords should related to the attack and the attack object.

    Recommended

    Indicates that this attack object is among your highest-risk set of attack objects. Later, when you add this attack object to dynamic groups, you can specify whether to include only recommended attack objects.

    • Yes—Adds predefined attacks recommended by Juniper Networks to the dynamic group.

    • No—Specifies non-recommended attack objects in the dynamic attack group.

       

    Detection Performance

    Specify this filter to filter out slow-performing attack objects. You can use this filter to only select the appropriate attacks based on performance impacts.

    Select an option:

    • High—Add a high performance impact attack object that is vulnerable to an attack. The performance impact of signatures is high7 to high9, where the application identification is slow.

    • Medium—Add a medium performance impact attack object that is vulnerable to an attack. The performance impact of signatures is medium4 to medium6, where the application identification is normal.

    • Low—Add a low performance impact attack object that is vulnerable to an attack. The performance impact of signatures is low1 to low3, where the application identification is faster.

    • Unknown—Set all attack objects to unknown by default. As you fine-tune IPS to your network traffic, you can change this setting to help you track performance impact. The performance impact of signatures is 0 = unknown, where the application identification is also unknown.

  5. Click the General tab.
  6. Under Attack Versions, click the + icon to display the New Attack wizard.
  7. On the Target Platform and Type page, select a device platform and attack type. Table 2 describes the attack types.
    Table 2: Attack Object Types

    Type

    Description

    Signature

    Uses a stateful attack signature (a pattern that always exists within a specific section of the attack) to detect known attacks.

    Stateful signature attack objects also include the protocol or service used to perpetrate the attack and the context in which the attack occurs.

    If you know the exact attack signature, the protocol, and the attack context used for a known attack, select this option.

    Compound Attack

    Detects attacks that use multiple methods to exploit a vulnerability. This object combines multiple signatures or protocol anomalies into a single attack object, forcing traffic to match all combined signatures or 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 must place before the IDP engine identifies traffic as an attack.

    If you need to detect an attack that uses several benign activities to attack your network, or if you want to enforce a specific sequence of events to occur before the attack is considered malicious, select this option.

  8. Select Signature and click Next.
  9. On the Custom Attack – General Properties page, configure other settings. Table 3 provides guidelines for completing the settings.
    Table 3: Custom Attack – General Properties

    Property

    Description

    Signature Details

    Binding

    Service–If you were able to determine the service through your research, select Service. Later in the wizard, you can specify a service context.

    IP–If you are not sure of the service but you know IP details, select IP and specify a protocol type number.

    TCP, UDP, or ICMP–If you do not know the service context but you know protocol details, select the protocol.

    For TCP and UDP protocol types, specify the port ranges.

    RPC–If you are detecting threats over remote procedure call (RPC) protocol, select this option and specify the program ID.

    RPC 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.

    Enable

    Time binding attributes track how many times a signature is repeated. By configuring the scope and count of an attack, you can detect a sequence of the same attacks over a period of time (one minute) across sessions. This method is useful for detecting brute force attacks that attempt to guess authentication credentials or overwhelm system capacity to handle data.

    Service

    Specify the service that the attack uses to enter your network. You can select the specific service used to perpetrate the attack as the service binding.

    For example, suppose you select the DISCARD service. Discard protocol is an Application Layer protocol where TCP/9, UDP/9 describes the process for discarding TCP or UDP data sent to port 9.

    Time Scope

    Select the scope within which the count occurs:

    • Source IP–Detects the signature in traffic from the source IP address for the specified number of times, regardless of the destination IP address.

    • Destination IP–Detects the signature in traffic from the destination IP address for the specified number of times, regardless of the source IP address.

    • Peer–Detects the signature in traffic between source and destination IP addresses of the sessions for the specified number of times.

    Time Count

    Specify 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.

    The range is from 0 through 4,294,967,295.

    Match Assurance

    Specify this filter to track attack objects based on the frequency that the attack produces a false positive on your network.

    Select an option:

    • High—Provides information on the frequently tracked false positive occurrences.

    • Medium—Provides information on the occasionally tracked false positive occurrences.

    • Low—Provides information on the rarely tracked false positive occurrences.

    Performance Impact

    Specify this filter to filter out slow-performing attack objects. You can use this filter to only select the appropriate attacks based on performance impacts.

    Select an option:

    • High—Add a high performance impact attack object that is vulnerable to an attack. The performance impact of signatures is high7 to high9, where the application identification is slow.

    • Medium—Add a medium performance impact attack object that is vulnerable to an attack. The performance impact of signatures is medium4 to medium6, where the application identification is normal.

    • Low—Add a low performance impact attack object that is vulnerable to an attack. The performance impact of signatures is low1 to low3, where the application identification is faster.

    • Unknown—Set all attack objects to unknown by default. As you fine-tune IPS to your network traffic, you can change this setting to help you track performance impact. The performance impact of signatures is 0 = unknown, where the application identification is also unknown.

    Scope

    Specify if the attack is matched within a session or across transactions in a session:

    • session—Allows multiple matches for the object within the same session.

    • transaction—Matches the object across multiple transactions that occur within the same session.

    Click Next.

  10. On the Custom Attack – Attack Pattern page, configure pattern settings. Table 4 provides guidelines for completing the settings.
    Table 4: Custom Attack – Attack Pattern

    Setting

    Description

    Pattern

    A DFA expression. The following rows summarize DFA syntax conventions. For detailed information, consult a standard source on programming with regular expressions.

     

    \B.0.1..00\B

    Bit-level matching for binary protocols. The length of the bitmask must be in multiples of 8.

    The first \B denotes the start of the bitmask. The last \B denotes the end of the bitmask.

    The decimal (.) indicates the bit can be either 0 or 1.

    A 0 or 1 indicates the bit at that position must be 0, or must be 1.

    \0 <octal_number>

    For a direct binary match.

    \X<hexadecimal-number>\X

    For a direct binary match.

    \[<character-set>\]

    For case-insensitive matches.

    .

    To match any symbol.

    *

    To match 0 or more symbols.

    +

    To match 1 or more symbols.

    ?

    To match 0 or 1 symbol.

    ()

    Grouping of expressions.

    |

    Alternation. Typically used with ().

    Example: The following expression matches dog or cat: (dog | cat).

    []

    Character class. Any explicit value within the bracket at the position matches.

    Example: [Dd]ay matches Day and day.

    [<start>-<end>]

    Character range. Any value within the range (denoted with a hyphen). You can mix character class and a hexadecimal range.

    Example: [AaBbCcDdEeFf0-9].

    [^<start>-<end>]

    Negation of character range.

    Example: [^Dd]ay matches Hay and ray, but not Day or day.

    Note:

    To negate an entire signature pattern, select the Negate option under the pattern text box.

    \u<string>\u

    Unicode insensitive matches.

    \s

    Whitespace.

     

    \

    Use a backslash to escape special characters so that they are matched and not processed as regular expression operators.

    Character Escaped

    *

    \*

    (

    \(

    )

    \)

    .

    \.

    +

    \+

    \

    \\

    [

    \0133

    ]

    \0135

    Note:

    Because the combination of the backslash and the open and close square brackets are used in the case-insensitive expression, you must use the backslash with the octal code for the bracket characters.

    Negate

    Negates the attack pattern.

    Regex

    Enter a regular expression to define rules to match malicious or unwanted behavior over the network.

    For example: For the syntax \[hello\], the expected pattern is hello, which is case sensitive.

    The example matches can be: hElLo, HEllO, and heLLO.

    Context

    Binds pattern matching to a context.

    For known services, such as HTTP, select the service in the first box, and select the HTTP context you discovered with scio ccap, such as HTTP POST Parsed Param, in the second box.

    If you were unable to discover the context, select Other in the first box, and select one of the following contexts in the second box:

    • Packet–Detects the pattern in any packet.

    • First Packet–Inspects only the first packet of a stream. When the flow direction is set to any, the detector engine checks the first packet of both the server-to-client (STC) and client-to-server (CTS) flows. Less processing means greater performance. If you know that the pattern appears in the first packet of a session, select First Packet.

    • First Data Packet–Inspection ends after the first packet of a stream. Select this option to detect the attack in only the first data packet of a stream. If you know that the pattern appears in the first data packet of a stream, select First Data Packet.

    • Stream 256–Reassembles packets and searches for a pattern match within the first 256 bytes of a traffic stream. Stream 256 is often the best choice for non-UDP attacks. When the flow direction is set to any, the detector engine checks the first 256 bytes of both the STC and CTS flows. If you know that the pattern will appear in the first 256 bytes of a session, select Stream 256.

    • Stream 8K–Like Stream 256 except reassembles packets and searches for a pattern match within the first 8192 bytes of a traffic stream.

    • Stream 1K–Like Stream 256 except reassembles packets and searches for a pattern match within the first 1024 bytes of a traffic stream.

    • Line–Detects a pattern within a specific line. Use this context for line-oriented applications or protocols (such as FTP).

    • Stream–Reassembles packets and extracts the data to search for a pattern match. However, the IDP engine does not recognize packet boundaries for stream contexts, so data for multiple packets is combined. Select this option only when no other context option contains the attack.

    Note:

    If you select a line, stream, or service context, you do not configure match criteria for IP settings and protocol header fields.

    Direction

    Select the direction in which to detect the pattern:

    • Client to Server–Detects the pattern only in client-to-server traffic.

    • Server to Client–Detects the pattern only in server-to-client traffic.

    • Any–Detects the pattern in either direction.

    The session initiator is considered the client, even if that source IP is a server.

    Add Anomaly

    Anomaly

    Select an option to detect abnormal or ambiguous messages within a connection according to the set of rules for the particular protocol being used.

    Protocol anomaly detection works by finding deviations from protocol standards, most often defined by RFCs and common RFC extensions.

    Direction

    Specify the connection direction of the attack:

    • 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.

    Using a single direction (instead of Any) improves performance, reduces false positives, and increases detection accuracy.

    Click Next.

  11. If you have selected a line, stream, stream 256, or service context, do not configure match criteria for IP settings and protocol header fields. Click Finish.

    If you are using a packet context, you can refine matching by adding criteria for IP flags and packet headers, as described in the following tables.

    Tip:

    If you are unsure of the IP flags and IP fields you want to match, leave all fields blank. If no values are set, the IDP engine attempts to match the signature for all header contents.

    On the Custom Attack – IPv4 settings and header matches page, configure pattern settings. Table 5 provides guidelines for completing the settings.

    Table 5: Custom Attack – IPv4 Settings and Header Matches Page

    Setting

    Description

    Checksum Validate

    Validate checksum field against calculated checksum.

    Type of Service

    Service type. Common service types are:

    • 0000 Default

    • 0001 Minimize Cost

    • 0002 Maximize Reliability

    • 0003 Maximize Throughput

    • 0004 Minimize Delay

    • 0005 Maximize Security

    IP Flags

    IP Flag bits.

    IHL

    Internet header length in words.

    Total Length

    Total Length of IP datagram.

    ID

    Unique value used by the destination system to reassemble a fragmented packet.

    Time-to-live

    Time-to-live (TTL) value of the packet. This value represents the number of routers the packet can pass through. Each router that processes the packet decrements the TTL by 1; when the TTL reaches 0, the packet is discarded.

    Protocol

    Protocol used in the attack.

    Source

    IP address of the attacking device.

    Destination

    IP address of the attack target.

    On the Custom Attack – IPv6 settings and header matches page, configure pattern settings. Table 6 provides guidelines for completing the settings.

    Table 6: Custom Attack – IPv6 Settings and Header Matches Page

    Setting

    Description

    Destination

    IP address of the attack target.

    Extension Header

    Define the IPv6 extension header for the intrusion detection service (IDS).

    Flow Label

    Enable IPv6 packet flow labels.

    Hop Limit

    Specifies the maximum number of hops that the router can use in router advertisements and all IPv6 packets.

    Next Header

    Identifies the type of Internet Protocol for the header that immediately follows the IPv6 header.

    Payload Length

    Specifies the length of the IPv6 packet payload, or contents, expressed in octets.

    Source

    Identifies the host device, or interface on a node, that generated the IPv6 packet.

    Traffic Class

    Allows source nodes or routers to identify different classes (or priorities for quality of service) for IPv6 packets. (This field replaces the IPv4 Type of Service field.)

    On the Custom Attack – TCP packet header page, configure pattern settings. Table 7 provides guidelines for completing the settings.

    Table 7: Custom Attack Object: TCP Packet Header Fields

    Setting

    Description

    Source Port

    Port number on the attacking device.

    Destination Port

    Port number of the attack target.

    Sequence Number

    Sequence number of the packet. This number identifies the location of the data in relation to the entire data sequence.

    ACK Number

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

    Header Length

    Number of bytes in the TCP header.

    Window Size

    Number of bytes in the TCP window size.

    Data Length

    Number of bytes in the data payload. For SYN, ACK, and FIN packets, this field should be empty.

    Urgent Pointer

    Data in the packet is urgent; the URG flag must be set to activate this field.

    MSS

    Enable and specify the TCP maximum segment size.

    Reserved

    Specify the three reserved bits in the TCP header field.

    TCP Flags

    TCP header flags. Specify that IDP looks for a pattern match whether or not the TCP flag is set.

    Window Scale

    Specify the scale factor that the session of the attack will use.

    On the Custom Attack – UDP header page, configure pattern settings. Table 8 provides guidelines for completing the settings.

    Table 8: Custom Attack Object: UDP Header Fields

    Setting

    Description

    Checksum Validate

    Validate checksum field against calculated checksum.

    Source Port

    Port number on the attacking device.

    Destination Port

    Port number of the attack target.

    Data Length

    Number of bytes in the data payload.

    On the Custom Attack – ICMP packet header page, configure pattern settings. Table 9 provides guidelines for completing the settings.

    Table 9: Custom Attack Object: ICMP Packet Header Fields

    Setting

    Description

    Checksum Validate

    Validate checksum field against calculated checksum.

    ICMP Type

    Primary code that identifies the function of the request or reply.

    ICMP Code

    Secondary code that identifies the function of the request or reply within a given type.

    Sequence Number

    Sequence number of the packet. This number identifies the location of the request/reply in relation to the entire sequence.

    ICMP ID

    Identification number, which is a unique value used by the destination system to associate requests and replies.

    Data length

    Number of bytes in the data payload.

  12. Click Finish.

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 the FTP:USER group. It detects attempts to log in to an FTP server using the root account.

  • HTTP:HOTMAIL:FILE-UPLOAD—Belongs to the HTTP:HOTMAIL group. It detects files attached to e-mails sent via the Web-based e-mail service Hotmail.

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:

Table 10: Predefined Attack Object Groups

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.

Note:

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

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.

Note:

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

  • any—Specify any if 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 the Any service 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.

Note:

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.

Table 12: Sample Formats for Protocols

Protocol Name

Protocol Number

Description

ICMP

<Port>ICMP</Port>

Specify the protocol name.

IP

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

Specify the Network Layer protocol number.

RPC

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

Specify the RPC program number.

TCP or UDP

  • <Port>TCP </Port>

  • <Port>TCP/port </Port>

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

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

  • <Port>UDP</Port>

  • <Port>UDP/10</Port>

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

Time Bindings

Use time bindings to configure the time attributes for the 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 address ip-a but different destination addresses ip-b and ip-c. Then the number of matches for ip-a increments to 2. 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 address ip-b but different source addresses ip-a and ip-c. Then the number of matches for ip-b increments to 2. Suppose the threshold value or count is also set to 2, 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 to 1, 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:

Note:

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

Attack Context

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

  • first-data-packet—Specify this context to detect the attack in only the first data packet.

  • first-packet—Specify this context to detect the attack in only the first packet of a stream. When the flow direction for the attack object is set to any, the device checks the first packet of both the server-to-client and the client-to-server flows. If you know that the attack signature appears in the first packet of a session, choosing first packet instead of packet reduces the amount of traffic the device needs to monitor, which improves performance.

  • packet—Specify this context to match the attack pattern within a packet. When you select this option, you must also specify the service binding to define the service header options . Although not required, specifying these additional parameters improves the accuracy of the attack object and thereby improves performance.

  • line—Specify this context to detect a pattern match within a specific line within your network traffic.

  • normalized-stream—Specify this context to detect the attack in an entire normalized stream. The normalized stream is one of the multiple ways of sending information. In this stream the information in the packet is normalized before a match is performed. Suppose www.yahoo.com/sports is the same as www.yahoo.com/s%70orts. The normalized form to represent both of these URLs might be www.yahoo.com/sports. Choose normalized stream instead of stream, unless you want to detect some pattern in its exact form. For example, if you want to detect the exact pattern www.yahoo.com/s%70orts, then select stream.

  • normalized-stream256—Specify this context to detect the attack in only the first 256 bytes of a normalized stream.

  • normalized-stream1k—Specify this context to detect the attack in only the first 1024 bytes of a normalized stream.

  • normalized-stream-8k—Specify this context to detect the attack in only the first 8192 bytes of a normalized stream.

  • stream—Specify this context to reassemble packets and extract the data to search for a pattern match. However, the device cannot recognize packet boundaries for stream contexts, so data for multiple packets is combined. Specify this option only when no other context option contains the attack.

  • stream256—Specify this context to reassemble packets and search for a pattern match within the first 256 bytes of a traffic stream. When the flow direction is set to any, the device checks the first 256 bytes of both the server-to-client and client-to-server flows. If you know that the attack signature will appear in the first 256 bytes of a session, choosing stream256 instead of stream reduces the amount of traffic that the device must monitor and cache, thereby improving performance.

  • stream1k—Specify this context to reassemble packets and search for a pattern match within the first 1024 bytes of a traffic stream. When the flow direction is set to any, the device checks the first 1024 bytes of both the server-to-client and client-to-server flows. If you know that the attack signature will appear in the first 1024 bytes of a session, choosing stream1024 instead of stream reduces the amount of traffic that the device must monitor and cache, thereby improving performance.

  • stream8k—Specify this context to reassemble packets and search for a pattern match within the first 8192 bytes of a traffic stream. When the flow direction is set to any, the device checks the first 8192 bytes of both the server-to-client and client-to-server flows. If you know that the attack signature will appear in the first 8192 bytes of a session, choosing stream8192 instead of stream reduces the amount of traffic that the device must monitor and cache, thereby improving performance.

Attack Direction

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

  • Client to server (detects the attack only in client-to-server traffic)

  • Server to client (detects the attack only in server-to-client traffic)

  • Any (detects the attack in either direction)

Attack Pattern

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

Note:

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

Protocol-Specific Parameters

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

Note:

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

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

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

Table 13: IP Protocol Fields and Flags

Field

Description

Type of Service

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

  • 0000 Default

  • 0001 Minimize Cost

  • 0002 Maximize Reliability

  • 0003 Maximize Throughput

  • 0004 Minimize Delay

  • 0005 Maximize Security

Total Length

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

ID

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

Time to Live

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

Protocol

Specify a value for the protocol used.

Source

Enter the source address of the attacking device.

Destination

Enter the destination address of the attack target.

Reserved Bit

This bit is not used.

More Fragments

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

Don’t Fragment

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

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

Table 14: TCP Header Fields and Flags

Field

Description

Source Port

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

Destination Port

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

Sequence Number

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

ACK Number

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

Header Length

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

Data Length

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

Window Size

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

Urgent Pointer

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

URG

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

ACK

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

PSH

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

RST

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

SYN

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

FIN

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

R1

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

R2

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

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

Table 15: UDP Header Fields and Flags

Field

Description

Source Port

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

Destination Port

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

Data Length

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

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

Table 16: ICMP Header Fields and Flags

Field

Description

ICMP Type

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

ICMP Code

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

Sequence Number

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

ICMP ID

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

Data Length

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

Sample Signature Attack Definition

The following is a sample signature attack definition:

Attack Properties (Protocol Anomaly Attacks)

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

Note:

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

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

Attack Direction

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

  • 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.

Sample Protocol Anomaly Attack Definition

The following is a sample protocol anomaly attack definition:

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:

Note:

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

Member Index

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

Note:

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

Sample Compound Attack Definition

The following is a sample compound attack definition:

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:

  1. Configure general attack object properties and reference information as described for signature attack objects.

    On the Target Platform and Type page, select a target platform, select Compound Attack, and click Next.

  2. On the Custom Attack – General Properties page, configure the settings described in Table 17.
    Table 17: Custom Attack – General Properties

    Property

    Description

    Time Binding

    Same guidelines as for signature attack objects.

    Click Next.

  3. On the Compound Members page, specify compound attack parameters and add members. Table 18 provides guidelines for completing the settings.
    Table 18: Compound Attack Parameters

    Setting

    Description

    Scope

    Specify if the attack is matched within a session or across transactions in a session. Select one of the following:

    • Session–Allows multiple matches for the object within the same session.

    • Transaction–Matches the object across multiple transactions that occur within the same session.

    Reset

    Enable this option to generate a new log each time an attack is detected within the same session. If this option is not selected, then the attack is logged only once per session.

    Boolean Expression

    Enter a Boolean expression of attack members used to identify the way attack members should be matched. Type a Boolean expression using the following Boolean operators:

    • 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–If both member name patterns match, and if they appear in the same order as in the Boolean expression, the expression matches.

    For example, the Boolean expression (s1 OAND s2) OR (s1 OAND s3)) AND (s4 AND s5) would match an attack that contains s1 followed by either s2 or s3, and that also contains s4 and s5 in any location.

    Add member

    Click the + icon, select Signature or Protocol Anomaly, and complete the configuration details.

    For signature members, specify the same contextual information as you do for a signature attack object.

    For protocol anomaly members, select from a list of predefined protocol anomalies.

    Best Practice:

    Example of the naming convention for members are: m01, m02, m03, and so on. It is recommend to use this same naming convention.

    Order

    Enable this option 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 order, the compound attack object still must match all members, but the pattern or protocol anomalies can appear in the attack in any order.

    A compound attack object detects attacks that use multiple methods to exploit a vulnerability.

    Protocol Binding

    Protocol binding over which attack will be detected.

  4. Click Finish.

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

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.

Table 19: HTTP Service Contexts

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.

  • http-get-url-parsed-param

  • http-post-url-parsed-param

  • http-head-url-parsed-param

  • http-get-url-parsed-param-parsed

  • http-post-url-parsed-param-parsed

  • http-head-url-parsed-param-parsed

Use a combination of the following contexts:

  • http-request-method

  • http-url-parsed

  • http-variable-parsed

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.

Table 20: HTTP Service Contexts: HTML Text

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.

Table 21: HTTP Service Contexts: Request Methods Before Update

Signature Before Update

Scope

Context

http-get-url-parsed-param

Pattern

\[/viper/vegaspalms/\].*

Table 22: HTTP Service Contexts: Request Methods After Update

Compound Signature After Update

m01

m02

Scope

Transaction

 

Context

http-request-method

http-url-parsed

Pattern

\[GET\]

\[/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.

Table 23: HTTP Service Contexts: URL Strings and Variables Before Update

Signature Before Update

Scope

Context

http-get-url-param-parsed-param

Pattern

\[/cvs/index[0-9]?\.php\?option=com_content&do_pdf=1&id=1\]

Table 24: HTTP Service Contexts: URL Strings and Variables After Update

Compound Signature After Update

 

m01

m02

m03

m04

Scope

Transaction

     

Context

http-url-parsed

http-variable-parsed

http-variable-parsed

http-variable-parsed

Pattern

\[/cvs/index[0-9]?\.php\]

\[option=com_content\]

\[do_pdf=1\]

\[id=1\]

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.

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:

  1. Create an IDP policy.

  2. Associate a rulebase with the policy.

  3. Add rules to the rulebase.

  4. Define the match criteria for the rule.

  5. Specify an application set name to match the rule criteria.

  6. Specify the match attack object and name for the attack object.

  7. Specify an action for the rule.

  8. Specify notification or logging options for the rule.

  9. Activate the IDP policy.

  10. Specify a name for the custom attack.

  11. Set the severity for the custom attack.

  12. Set the attack type and the application name for the custom attack.

  13. Set the scope and the order in which the attack is defined.

  14. Specify a name for the first member of the chain attack object.

  15. Set the context, pattern, and direction for the first member of the chain attack object.

  16. Specify a name for the second member of the chain attack object.

  17. Set the context, pattern, and direction for the second member of the chain attack object.

  18. Specify a name for the third member of the chain attack object.

  19. Specify an attack-type and direction for the third member of the chain attack object.

  20. Specify the trace options and trace file information for the IDP services.

  21. Specify the events and other information which needs to be included in the trace output.

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.

If you are done configuring the device, enter commit from configuration mode.

Note:

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.

Note:

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

Enter the show security idp attack table command to pass attack traffic and then verify that the attacks are getting detected or not.

Note:

The command will display the output only when attacks are detected.

user@host> show security idp attack table

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.

Note:

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.

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:

  1. Create an IDP policy.

  2. Associate a rulebase with the policy.

  3. Add rules to the rulebase.

  4. Define the match criteria for the rule.

  5. Specify an application set name to match the rule criteria.

  6. Specify a match for the custom attack group.

  7. Specify a match for the dynamic attack group.

  8. Specify an action for the rule.

  9. Specify notification or logging options for the rule.

  10. Activate the IDP policy.

  11. Specify a name for the custom attack.

  12. Set the severity for the custom attack.

  13. Set the attack type and context for the attack.

  14. Specify a pattern for the attack.

  15. Specify a direction for the attack.

  16. Specify a name for the custom attack group.

  17. Specify a list of attacks or attack groups that belongs to the custom attack group.

  18. Specify a name for the first dynamic attack group.

  19. Configure a filter and set a category value for the filter.

  20. Specify a name for the second dynamic attack group.

  21. Configure a filter for the second dynamic attack group and set the direction and its values for this field.

  22. Specify the trace options and trace file information for the IDP services.

  23. Specify the events and other information that needs to be included in the trace output.

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.

If you are done configuring the device, enter commit from configuration mode.

Note:

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.

Note:

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

Enter the show security idp attack table command to pass attack traffic and then verify that the attacks are getting detected or not.

Note:

The command will display the output only when attacks are detected.

user@host> show security idp attack table

Custom Attack Object DFA Expressions

Table 25 provides examples of syntax for matching an attack pattern.

Table 25: Example: Custom Attack Object Regular Expressions

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.

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:

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.

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:

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:

  1. Reproduce the attack to determine the attack context, direction, and pattern. Ideally, use scio ccap and Wireshark concurrently so you have to run the attack only once.
  2. Discover the following elements of the attack signature:
    • Service. You know from the CVE advisory that the attack uses the HTTP protocol. Review the packet capture to confirm the protocol.

    • Context. Use scio ccap to determine whether you can match a particular service context. In this example, the signature pattern occurs in the service context HTTP URL Parsed.

    • Pattern. You know from the advisory that the attack occurs using an exploited GET method in the HTTP protocol. Select the frame that contains the GET method to view details for that section of the packet. You can quickly identify the signature pattern as examples/servlet/AUX.

    • Direction. Locate the source IP that initiated the session. Because this attack uses TCP, you can use the Follow TCP Stream option in Wireshark to quickly discover the source IP that initiated the session. The attack direction is client-to-server.

  3. Create an attack object to match the attack signature. This example uses the following regular expression to match the signature:

    In this expression:

    • The dot star combination (.*) indicates a wildcard match.

    • The /examples/servlet/ section is taken directly from the packet capture.

    • The parentheses ( ) indicate a group of items, and the pipe character (|) indicates OR. These characters are often used together to indicate that an attack must include one item from the group. In this example, the attack must contain the word aux, lpt1, con, or prn after the string /examples/servlet/.

      Notice that this example uses a group. The packet capture displays the signature pattern as /examples/servlet/AUX. AUX is a Windows device. You have good reason to be on guard for attempts to exploit LPT1, CON, and PRN devices.

  4. Test the attack object.

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:

  1. 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.

  2. Configure the service for which you want to configure the test condition.

  3. Configure the test condition (specifying the protocol name is not required).

  4. If you are done configuring the device, enter commit from 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:

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:

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:

  1. Reproduce the attack to determine the attack context, direction, and pattern. Ideally, use scio ccap and Wireshark concurrently so you have to run the attack only once.
  2. Discover the elements of the attack signature:
    • Service. You know from the CERT advisory that the attack uses the XDMCP protocol. Review the packet capture in Wireshark to confirm the protocol.

    • Context. Use scio ccap to determine whether you can match a particular service context. In this example, the XMCP service contexts are not supported by the IDP system, and the output of scio ccap is blank. You must specify the packet context for the attack.

    • Pattern. Using your knowledge of the XDMCP protocol, you identify that the attack uses a non-NUL character (hexadecimal code 00 1b) to specify the connection type, which is invalid (the NUL character represents the Internet connection type in XDMCP). To anchor the non-NUL character in a signature pattern, include some of the preceding bytes as part of the pattern. For this example, you choose to anchor the non-NUL character with the version number (hexadecimal code 00 01) and the request options code (hexadecimal code 00 07). The full attack pattern is 00 01 00 07 followed by five characters of any type, followed by a sixth character and either a non-NUL character (as shown above with 00 1b) or a non-NUL character and another character.

    • Direction. Locate the source IP that initiated the session. In this example, you cannot determine the attack direction.

  3. Create an attack object to match the attack signature. Use the following regular expression to match the signature:

    In this expression:

    • The \x expression indicates a hexadecimal value.

    • The numbers 00 01 00 07 in the XDMP protocol represent the version number (hexadecimal code 00 01 and the request options code (hexadecimal code 00 07).

    • The five periods (.....) indicate five characters of any kind.

    • The parentheses ( ) indicates a group of items, and the pipe character (|) indicates OR. These characters are often used together to indicate that an attack must include one item from the group.

    • The opening and closing brackets combined with a caret [^ indicates negation.

    • The backslash combined with a zero (\0) indicates an octal code number.

    • The 00 characters are hexadecimal code for a NUL character. In this example, the attack must contain a non-NUL character, either preceded or followed by another character ([^\000] or [^\000]).

    • The dot star combination (.*) indicates a wildcard match. When used at the end of an expression, the wildcard indicates that anything can follow the specified expression.

  4. Test the attack object.

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:

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:

  1. Reproduce the attack to determine the attack context, direction, and pattern. Ideally, use scio ccap and Wireshark concurrently so you have to run the attack only once.
  2. Discover the elements of the attack signature:
    • Service. You know from the CERT advisory that the attack uses ICMP, for which the IDP OS does not support service contexts. Review the packet capture to confirm the protocol as ICMP.

    • Context. Use scio ccap to determine whether we can match a particular service context. In this example, the ICMP service contexts are not supported by the IDP system, and the output of scio ccap is blank. You must specify the first packet context for the attack.

    • Pattern. Select the first frame listed in Wireshark and review the information in the second section. Because you know that ICMP packets should not contain data, you investigate the 64 byte data payload. You can easily see the irregular payload is multiple “AA” characters, which is probably code attempting to overflow a buffer. Because this pattern is unusual in the context of an ICMP packet, select it as your signature.

    • Direction. Locate the source IP that initiated the session. In this example, you cannot determine the attack direction.

  3. Create an attack object to match the attack signature. In this example, we use the following regular expression to match the signature:

    In this expression:

    • The \X expression indicates that a hexadecimal value is to follow.

    • The dot star combination (.*) indicates a wildcard match. When used at the end of an expression, the wildcard indicates that anything can follow the specified expression.

  4. Test the attack object.

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:

The following proof-of-concept example is also provided:

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:

  1. Reproduce the attack to determine the attack context, direction, and pattern. Ideally, use scio ccap and Wireshark concurrently so you only have to run the attack only once.
  2. Discover the elements of the attack signature:
    • Service. You know from the BugTraq advisory that the attack uses the HTTP protocol. Review the packet capture and locate the HTTP protocol usage.

    • Context. Use scio ccap to determine whether you can match a particular service context. In this example, the service context is HTTP URL Parsed.

    • Pattern. You quickly identify the signature pattern POST /_vti_bin/_vti_aut/fp30reg.dll within the HTTP service.

      However, because this pattern might trigger false positives, you also determine a second signature pattern to ensure that your rule detects only the attack. In this case, the second signature (noted in the BugTraq advisory) is Transfer-Encoding: chunked.

    • Direction. Locate the source IP that initiated the session. In this example, the attack direction for both signature patterns is client-to-server.

  3. Create an attack object to match the attack signature. Use the following regular expression to match the first signature:

    In this expression:

    • The opening bracket (\[) indicates the beginning of a case-insensitive match for all characters until the closing bracket appears.

    • The pattern /_vti_bin/_vti_aut/fp30reg is a direct character match.

    • The backslash combined with the period (\.) indicates that the period is escaped (the period appears in the pattern).

    • The closing bracket (\]) indicates the end of a case-insensitive match.

    • The period combined with the asterisk character (.*) indicates that one or more characters must appear.

  4. Add a second signature. Use the following regular expression to match the second signature:

    In this expression:

    • The opening bracket (\[) indicates the beginning of a case-insensitive match for all characters until the closing bracket appears.

    • The pattern Transfer-Encoding: is a direct character match.

    • The plus sign (+) indicates that a space character must appear one or more times within the pattern.

    • The pattern chunked is a direct character match.

    • The closing bracket (\]) indicates the end of a case-insensitive match.

  5. Test the attack object.

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:

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.

Reference: Custom Attack Object Protocol Numbers

Table 26 protocol numbers used in the IDP system.

Table 26: IDP Attack Objects: Protocol Numbers

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.

Table 27: ASCII Reference: Nonprintable 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

Table 28: ASCII Reference: Printable Characters

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:

  1. View the list of protocols that have tunable parameters.

  2. Configure tunable parameters for the FTP protocol.

  3. If you are done configuring the device, commit the configuration.

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:

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:

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.

Note:

Enabling decompression will result in a reduction in performance on your device.

Configuration

Procedure

Step-by-Step Procedure

To configure IDP content decompression:

  1. Enable the detector.

    Note:

    To disable the detector, set the tunable‑value to 0.

  2. If necessary, modify the maximum memory in kilobytes.

  3. If necessary, configure the maximum decompression ratio.

  4. If you are done configuring the device, commit the configuration.

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-port and maximum-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-offset

  • max-offset

  • min-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.

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 source and the count as 10. When scope is source, 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.

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:

  1. Specify a name for the attack.

  2. Specify common properties for the attack.

  3. Specify the attack type and context.

  4. Specify the attack direction and the shellcode flag.

  5. Set the protocol and its fields.

  6. Specify the protocol binding and ports.

  7. Specify the direction.

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.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying the Configuration

Purpose

Verify that the signature-based attack object was created.

Action

From operational mode, enter the show security idp status command.

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 peer and count as 2 to 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.

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:

  1. Specify a name for the attack.

  2. Specify common properties for the attack.

  3. Specify the attack type and test condition.

  4. Specify other properties for the anomaly attack.

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.

If you are done configuring the device, enter commit from configuration mode.

Verification

To confirm that the configuration is working properly, perform this task:

Verifying the Configuration

Purpose

Verify that the protocol anomaly-based attack object was created.

Action

From operational mode, enter the show security idp status command.

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:

  1. Enable IDP in a security policy.

  2. 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.

  3. Configure IDP custom signatures. See Understanding IDP Signature-Based Attacks and Example: Configuring IDP Signature-Based Attacks topics.

  4. 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.

Release History Table
Release
Description
18.4R1
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.
15.1X49-D140
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.