< Home

Configuring Signatures

This section describes how to configure intrusion prevention signatures. A signature contains the features of a network intrusion. The device compares the received data flow with intrusion prevention signatures. If the data flow content matches a signature, the data flow contains threats.

Viewing a Predefined Signature

Predefined signatures cannot be modified. However, you can extract the detected intrusion features by viewing the signature content to facilitate follow-up configurations.

  • View information about all predefined signatures.

    display ips-signature pre-defined [ associated ] [ application { application-name | all } | category { category-name | all } | os { all | android | ios | unix-like | windows | other } * | protocol { protocol-name | all } | severity { information | low | medium | high } * | state { disabled | enabled | retired } | target { server | client | both } ] *

  • View information about a specific predefined signature.

    display ips-signature ips-signature-id

Configuring the State of Predefined Signatures

The state of a predefined signature can be enabled, disabled, and deprecated. For enabled or disabled predefined signatures, you can change their state in batches or individually. Deprecated predefined signatures are ineffective and their state cannot be changed. They are displayed in the IPS signature database for only for checking signature history.

Only the public system supports configuration for the state of predefined signatures.

After the state of a predefined signature is changed, run engine configuration commit to commit the change to apply it.

  • In the system view, sets the state of all predefined signatures to Enable.

    ips signature-state enabled

  • In the system view, sets the state of all predefined signatures to Disable.

    ips signature-state disabled

  • In the system view, set the status of a specific predefined signature.

    ips signature-state signature-id signature-id { enabled | disabled }

Configuring the Actions of Predefined Signatures

Each predefined signature has a default action, namely, allow, alert, or block. To change the action of a single predefined signature or the actions of all predefined signatures, perform the following operations:

You can configure actions for predefined signatures only on the root system.

After the action of a predefined signature is changed, run engine configuration commit to commit the change so that the change takes effect.

  • In the system view, change the actions of all predefined signatures.

    ips signature-action alert

    This command can set the actions of all predefined signatures to alert, not allow or block. To set the actions of all predefined signatures to allow, run the ips signature-state disabled command.

  • In the system view, change the action of a single predefined signature.

    ips signature-action signature-id signature-id { allow | alert | block }

Modifying the Predefined Associated Signature

By default, the FW provides predefined associated signatures. The display ips-signature pre-defined associated command displays supported predefined associated signatures.

If the check items of a predefined associated signature cannot meet requirements, you can modify the check items.

You can modify predefined associated signatures only on the root system.

  1. In the system view, configure a predefined associated signature.

    ips associated pre-defined signature-id signature-id { threshold threshold-value | interval interval-value | block-time block-time | correlateby { source | destination | source-destination } } *

  2. Commit the configuration in the system view.

    engine configuration commit

    After a predefined associated signature is modified, the configuration takes effect only after being committed. To save time, you can submit the configuration after all predefined associated signature operations are complete.

Configuring a User-Defined Signature

Each user-defined signature contains a maximum of four rules. Each rule can be configured with only one check item. When a packet matches the check item in a rule, the rule is matched. In addition, multiple rules do not affect each other. As long as a packet matches at least one rule in a signature, the packet matches the signature, regardless of the sequence.

Traffic Processing Flow shows how the device processes matched packets.

  1. In the system view, create a user-defined signature.

    ips signature-id signature-id

  2. Optional: Configure a name for the user-defined signature.

    name name

  3. Optional: Configure a description for the user-defined signature.

    description description

  4. Configure the basic features of the user-defined signature.

    Item

    Command

    Configure a detection target for the user-defined signature.

    target { both | client | server }

    Configure a protocol for the user-defined signature.

    protocol protocol-name

    Configure a severity for the user-defined signature.

    severity { high | medium | low | information }

    Configure an action for the user-defined signature.

    action { alert | block | allow }

  5. Create a rule for the user-defined signature.

    rule name name

  6. Set parameters for the user-defined signature rule.

    Item

    Command

    Check Item

    Configure check items for the user-defined signature rule.

    condition value text

    The IPS third-generation engine syntax is used to configure the check items of user-defined signatures. The IPS third-generation engine syntax greatly improves the processing efficiency while maintaining the detection accuracy of existing syntax. It is also compatible with common signature rules in the industry for better openness. For details about the IPS third-generation engine syntax, see IPS Third-Generation Engine Syntax.

    Advanced Information

    Configure the source IP address in the user-defined signature rule.

    source-ip { [ ipv4 ] start-ipv4-address [ end-ipv4-address | ipv4-mask-length ] | ipv6 start-ipv6-address [ end-ipv6-address | prefix-length ] | any }

    Configure the source port in the user-defined signature rule.

    source-port { start-port end-port | any }

    Configure the destination IP address in the user-defined signature rule.

    destination-ip { [ ipv4 ] start-ipv4-address [ end-ipv4-address | ipv4-mask-length ] | ipv6 start-ipv6-address [ end-ipv6-address | prefix-length ] | any }

    Configure the destination port in the user-defined signature rule.

    destination-port { start-port end-port | any }

  7. Commit the configuration in the system view.

    engine configuration commit

    After a user-defined signature is created or modified, the configuration takes effect only after being committed. To save time, you can submit the configuration after all user-defined signature operations are complete.

Configuring a User-Defined Associated Signature

Only one rule can be configured for a user-defined associated signature. Only one check item can be configured in the rule.

If a user-defined signature is configured as an associated signature, you must remove the association relationship of the signature before deleting the user-defined signature. Only enabled predefined signatures can be configured as associated signatures.

  1. In the system view, create a user-defined associated signature.

    ips signature-id signature-id

  2. Optional: Configure a name for the user-defined associated signature.

    name name

  3. Optional: Configure a description for the user-defined associated signature.

    description description

  4. Create a rule for the user-defined signature.

    rule name name

  5. Configure a check item for the user-defined associated signature.

    condition associated signature-id signature-id [ threshold threshold-value | interval interval-value | block-time block-time | correlateby { source | destination | source-destination } ] *

  6. Configure the basic features of the user-defined associated signature in the user-defined associated signature view.

    Item

    Command

    Configure a severity for the user-defined associated signature.

    severity { high | medium | low | information }

    Configure an action for the user-defined associated signature.

    action { alert | block | allow }

  7. Commit the configuration in the system view.

    engine configuration commit

    After a user-defined associated signature is created or modified, the configuration takes effect only after being committed. To save time, you can submit the configuration after all user-defined associated signature operations are complete.

IPS Third-Generation Engine Syntax

The IPS third-generation engine syntax consists of the basic packet information part and the part to be detected. Basic packet information is represented by the flow field. The part to be detected can use the content field for feature string matching or use the pcre field for regular expression matching. The fields are described as follows:
  • flow

    The flow field can be used to specify the detection direction and scope.

    For example, flow: from_server, session; indicates that the request from the server is detected and the detection scope is session.

  • content

    The content field is used to specify the feature string to be detected.

    For example, content: "helloworld"; nocase; offset: 100; depth: 20; indicates that a maximum of 20 bytes can be matched from the 100th byte of the TCP/UDP payload. In this range, the helloworld feature string is matched in case-insensitive mode.

  • pcre

    The pcre field uses the regular expression to detect the feature string of a packet. The format is pcre:"/<regex>/[options][extend]";, where <regex> indicates the regular expression string, [options] indicates the additional item, and [extend] indicates the extended syntax.

    For example, pcre: "/alert\(.*\)/iAG"; indicates matching a character string that starts with alert( and ends with ) from the beginning of the data in case-insensitive mode and that the greedy mode is used. (i indicates case-insensitive, A indicates matching the character string from the beginning of the data, and G indicates that the greedy mode is used.)

The following is an example of the syntax rule of the IPS third-generation engine: flow: from_client, message; pkt_data; content:"/index.html"; http_uri; fast_pattern; content:"test"; nocase; http_user_agent; urilen:>512; pcre:" /id=[0-9]{5,10}/Ui";. It can be interpreted as follows:
  • flow: from_client, message; indicates that the request sent from the client is detected and the detection scope is message.
  • pkt_data; indicates that the detected content is traffic.
  • content:"/index.html"; http_uri; fast_pattern; indicates that the URI field in the HTTP header matches the /index.html feature string. fast_pattern is used to modify a content feature string, indicating that the feature string has the most obvious threat characteristics and is preferentially matched during pre-filtering.
  • content:"test"; nocase; http_user_agent; indicates that the User-Agent content in the HTTP header matches the test feature string in case-insensitive mode.
  • urilen:>512; indicates that the signature rule can be matched only when the length of the URI is greater than 512 bytes.
  • pcre:" /id=[0-9]{5,10}/Ui"; checks whether the URI field matches the pcre rule using regular expression matching in case-insensitive mode. U indicates the URI field and i indicates case-insensitive.
If all the preceding conditions are met, the packet matches the signature rule.

The preceding describes only the basic content of the IPS third-generation engine syntax and gives simple examples. For details about the syntax description, supported syntax, fields, and the meaning of each field, see the Online Syntax Manual.

Feeding Back Matched Signatures in the IPS Signature Database

After you enable the function of feeding back matched signatures in the IPS signature database, the device feeds back the matched IPS signatures to the data feedback server for statistics collection. The statistics assist the signature database provider in analyzing the validity of existing signatures, based on which the provider then analyzes and deletes invalid signatures.

  1. Set the interval for feeding back matched signatures in the IPS signature database.

    feedback interval interval-time

    The default interval for feeding back matched signatures in the IPS signature database is 1 hour.

  2. Enable the function of feeding back matched signatures in the IPS signature database.

    feedback type engine-statistics enable

    By default, the function of feeding back matched signatures in the IPS signature database is enabled.

Copyright © Huawei Technologies Co., Ltd.
Copyright © Huawei Technologies Co., Ltd.
< Previous topic Next topic >