Creating a Compound Attack Object (NSM Procedure)

Use compound attack objects in cases where:

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

    Table 46: Custom Attack – General Properties



    False Positives

    Service Binding

    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 47 provides guidelines for completing the settings.

    Table 47: Compound Attack Parameters




    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.


    Enable to detect multiple occurrences of the attack object in the same session. Disable to log multiple occurrences as one.

    Boolean Expression

    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: Our signature team uses the following naming convention for members: m01, m02, m03, and so on. We recommend you use this same naming convention.

    Context Check

    Use this constraint to require the matching context be of a specified byte length to be a hit:

    • Constraint–Select length.
    • Comparison operator–Select =, !, >, or <.
    • Operand–Select a byte length.

    Example: You can use the context check constraint as a tuning device to limit processing for harmless traffic. For example, if you know that a certain class of attack, like a buffer overflow attack, always has an unusually large byte length in a given context, you can use this constraint to ignore contexts of normal length. If you set the FTP username context length requirement to be > 18, you see signature hits only when the FTP username context is longer than 18 bytes.

    You can specify multiple constraints. For example, if you add a < 25 constraint to the previous example, you see hits only when the username context is between 18 and 25 bytes.

    Match within same context

    Use this constraint to require selected signature members to be found in the same context instance (in any order). You can select up to 32 signature members.

    Protocol anomaly members are not selectable and are not a component of this constraint.

    Example: You design a compound attack with service context ftp-filename, and you enable this restraint. The pattern for member 1 is test; the pattern for member 2 is hello. A user opens an FTP session and requests files test.txt and hello.txt. Each file transfer occurs in its own context, not within the same context instance, so the FTP session does not trigger this attack object. Instead, consider what happens when the user requests a file named test-hello.txt. In this case, both members are found in a single context instance, so the FTP session is a match.

    Within Bytes Constraint

    Note: IDP OS Release 5.1 does not support the within bytes constraint for compound attack objects.

    Within Packets Constraint

    Use this constraint to require that the pattern be found completely within a packet range of a stream:

    • Lower limit–Specify the beginning of the range.
    • Upper limit–Specify the end of the range.
    • Member–Select one or two members. You cannot configure a relationship for more than two members.

      If you set a packet constraint for one member, the program logic counts packets beginning with the start-of-stream. The member must be found completely within the packet range indicated.

      If you select two members and apply a packet constraint to them, the program logic counts the first match as packet 0. If you specify a range of 1-2 with member 1 and member 2, the second pattern must occur within one or two packets from the packet containing the first match. Specifying 0-1 requires the pattern to appear in the same packet or within one packet from the first match. Order does not matter unless you use an Boolean ordered AND to specify the order in which the patterns must appear.

    Inspection for this object terminates when the range limit has been reached.

  4. Click Finish.

Note: For more information on custom attack objects references and examples, see IDP Series Custom Attack Object Reference and Examples Guide.

Related Documentation