Skip to main content
gmanea
Staff
gmanea
Staff
November 2, 2021

Technical Tip: IPS Sequence of Inspection and How to Exempt/Override Individual IPS Signatures

  • November 2, 2021
  • 0 replies
  • 13049 views

Description

 

This article describes the order in which IPS will assess the Signature and Filter rules specified in the sensor configuration, as well as how to exempt individual signatures so that different actions are taken compared to the Filters
 
Scope
 
FortiGate, IPS.
 
Solution
 
As a primer, IPS sensors will populate with a list of signatures based on the filters/signature rules applied by the administrator. The general expectation is for administrators to tune IPS sensors so that they only carry signatures that are relevant to the traffic being inspected, but it is common to see IPS sensors configured with a broader set of signatures (i.e. load more than required to start with, then reduce at a later time). For example, the 'default' (aka 'g-default' on VDOM-enabled FortiGates) IPS sensor is configured with a single filter-based entry that loads all signatures that are rated with a Severity of Medium, High, or Critical.
 
One problem that can occur in these broader setups is false-positives, where known-good traffic is accidentally matching an existing IPS signature. Another common scenario is where traffic matches a signature that has a default action of Allow and the administrator would prefer to override the action to Block instead. In these cases, it can be necessary to exempt this IPS signature such that a different action is taken.
 
Notes before starting:
  • It is not possible to change the underlying default action for a given signature (e.g. system-wide change), but it is possible to override that action within each IPS sensor configuration.
  • The 'default' or 'g-default' profiles cannot be modified, so the recommendation is to clone these defaults to a new IPS sensor or create a brand new sensor profile instead.
  • Available actions for IPS filter/signature rules include Allow (aka Pass), Monitor, Block, Reset, Default and Quarantine. See the following KB article for more information: Technical Tip: IPS profile actions and corresponding actions in logs.
Exempting an IPS Signature
In the following example scenario, a new IPS sensor named 'IPS_Test' has been created, and the plan is to override the action taken for the Eicar.Virus.Test.File IPS signature. For demonstration purposes, a Filter-based rule has been added to include all signatures with a Severity level of Information (i.e. relatively low-impact signatures) and to apply the Default action specified per-signature.
 
01 IPS Sensor.png

 

Within the list of IPS signatures that have Information-level Severity, the Eicar.Virus.Test.File can be found. Note that the default action is Pass:

02 IPS Sensor Filtered Signature List.png
 
With the current IPS configuration, traffic matching the Eicar.Virus.Test.File (such as downloading test files from the EICAR organization, see https://www.eicar.org/download-anti-malware-testfile) will be allowed through by IPS inspection without being logged due to the default Pass/Allow action.
 
To override/exempt this signature from being included in the broader Filter-based rule (e.g. so that the signature action can be changed to Monitor or Block instead), it is necessary to create a new entry in the IPS sensor. Here, a new Signature-based rule is added to pick the Eicar.Virus.Test.File signature and override its Action to Block instead of Pass.
 
03 IPS Sensor Eicar Signature - Edit.png
 
Both rules are now visible in the IPS sensor. Note how the newly-added Signature rule was added to the bottom of the table:
 
04 IPS Sensor.png

 

At this point, the Eicar.Virus.Test.File is actually present twice in the IPS sensor: once in the original Information Severity filter rule (with the default action of Pass), and a second time in the signature-based rule with the Block action.

 

In general, IPS rules within a sensor are assessed from top to bottom, with the first matching rule being chosen once the IPS Engine has identified a matching signature (i.e. very similar to how Firewall Policies are assessed). The order of IPS rules can also be adjusted in a very similar way to Firewall Policies (i.e. drag and reorder in the GUI or use the move <id> [before | after] <id> command in the CLI), so it is very important that administrators check the order of these IPS rules.

 

In the above example, the Severity Filter-based rule (which has a default Pass/Allow action for Eicar.Virus.Test.File) was placed above the Signature-based rule for Eicar.Virus.Test.File. Because of this, traffic matching this signature will be allowed through the FortiGate without an IPS event log being generated. In order to override this behavior and apply the desired Block action, the order of the rules must be changed so that the Eicar.Virus.Test.File Signature-based rule is placed above the Filter-based rule:

 

05 IPS Sensor reordered.png

 

The following are some additional recommendations for further tuning IPS sensors/matching rules:

  • As noted above, IPS rules are assessed top to bottom. Once traffic has been identified as matching a given signature AND once that signature has been matched to a rule in the IPS sensor, the action specified by that rule is taken and no further rules are assessed.
    • In the above example, traffic matching Eicar.Virus.Test.File rule would match the specific Signature rule (since it was moved to the top), and a Block action is taken. The Severity Information rule below is skipped at this point.
  • It is a good idea to reorder rules such that the most-likely matching filters/signatures are placed near the top of the list. This can help reduce the amount of time spent on IPS assessment, which can speed up decision making while also reducing CPU usage.
  • Additionally, it is best practice to be selective about the signatures being added to IPS sensors, as the FortiGate must load those signatures into memory. This means that adding more signatures to the sensor (e.g. due to broad filters or adding many individual signatures) will result in an increase in memory/RAM usage.
  • In the event of false-positive matches (e.g. known-good traffic triggering a signature), it can be a good idea to override the signature and apply the Monitor action. This allows traffic to pass through while also generating an IPS log entry for later review.
 
Note:
The IPS filtering and selection of signatures differs between the FortiOS versions. The above example was taken in FortiOS 7.4, though it is consistent with FortiOS 6.2 and later. FortiOS 6.0 and prior versions have a slightly different IPS selection sequence and behavior.

 

Related Articles:

Technical Note: Exempting IP addresses from IPS sensor scanning

Technical Tip: How to Configure the FortiGate to Block an IPS Attack and change the default IPS action

Technical Tip: Exempting specific subnet or IP from all IPS signatures or specific IPS signature from GUI

    Terms & ConditionsAccessibility statement