Increasing Performance and Use Cases for separate IPS Profiles

[jens_kirch]

Hi all,

I am currently working on an optimization of our IPS configuration.

We started with IPS in Version R77, so every Firewall Gateway got its own IPS profile. For reducing false postitives or disabling IPS on irrelevant network traffic, so far, we have defined Exceptions either for a single protection or for the hole IPS blade (if necessary).

After the update to R80, we got the recommendation to use different profiles in separate Threat Prevention Rules within a firewall gateway to increase performance (especially of the gateway, but also for the application and the correspondent network traffic).

My first thought was, that it would be useful to build an IPS Profile based on the used protocol. For example to create a specific IPS profile for e.g. incoming SSL traffic with a small amount of relevant protections, which I use in a separate Threat Prevention Rules.

After reading Secure Knowledge sk95193: ATRG IPS, I am not sure, if this is a method to increase performance effectively.

Quote: "The Context Management Infrastructure (CMI) is the "brain" of the IPS. It coordinates different components, decides which protections should run on a certain packet, decides the final action to be performed on the packet and issues an event log (.....) CMI is a way to connect and manage parsers and protections. Since they are separated, protections can be added in updates, while performance does not depend on the number of active protections."

In my opinion, it seems that an separate profile for e.g. SSL or other known protocols (HTTP, SMTP,..) isn't an appropriate way to decrease cpu usage, because the amount of protection isn't relevant. Is this the right conclusion?

So for me, what would be a use case for separate IPS profiles? Just for activate additional blades like ABOT or Threat Emulation? What is an effective method to increase performance of a firewall gateway with IPS instead, without diabling IPS for a specific communication.

Best regards
Jens

[PhoneBoy]

You are basically correct.
Really, the main performance hit in IPS is the blade being on.
However, there are some signatures that do require more CPU than others (particularly anything with a Performance Impact of High or Critical).
If these protections are being tripped, this can cause a noticeable performance impact.

Therefore, there might be some incremental performance gains and/or a reduction in false positives by further tuning the signatures active for a given Protected Scope.
Also, yes, you can decide to run different blades on different protected scope as well, which again, may give you some incremental performance gains in some situations.

[Kim_Moberg]

Now that you use r80 I can recommend you to take a look st Tailored Safe Profile which is described in the sk164812.

performance wise you are moving from detect to prevent. The firewall will not spend more necessary cpu to run Detection mode and it will reduce while ips are in prevent.

i have only had possible experience with it.

[Timothy_Hall]

This is covered in the third edition of my book and my IPS Immersion Video Series; basically I recommend using different IPS-enabled profiles taking into consideration the network speeds and trust levels involved.  Examples:

1) IPS Profile for traffic to/from the Internet - High Level of Enforcement and High Impact, but performance impact is muted by limited Internet bandwidth (at least compared to LAN speeds).

2) IPS Profile for traffic to/from DMZs & Internal Networks - Medium Level of Enforcement and Medium Impact; potentially use a special "null" IPS profile for known trusted high-speed traffic (like backups or perhaps replications) or use the fast_accel SecureXL feature for this purpose.

3) IPS Profile for Internal to Internal networks - Lower Level of enforcement with low/medium impact due to the LAN speeds involved, especially if 10 Gbps or faster.

Obviously in any profile it is desirable to limit the use of IPS protections with a Performance Impact rating of "Critical" (and to a lesser degree "High") as much as possible especially in IPS Profile #3 above, as they will strongly impact the acceleration level of the inspected traffic.  In general the Performance Impact rating of an IPS protection indicates the following acceleration levels:

- Protections with a “Very Low” or “Low” Performance Impact are processed 100% in the Accelerated Path (SXL)
- Protections with a “Medium” Performance Impact are processed at least 90% in the PSLXL Path
- Protections with a “High” Performance Impact appear to be processed about 50% in the PSLXL Path and about 50% in the CPASXL Path (Note that all imported SNORT IPS signatures are automatically assigned this ranking and are therefore ineligible for handling in the Accelerated Path)
- Protections with a “Critical” Performance Impact are processed 100% in the CPASXL and Firewall Paths (F2F)

Finally, leaving an IPS protection set in Detect mode causes much more overhead in the Firewall than setting it to Inactive or even Prevent; a flagrantly bad example is an IPS protection set to Detect with logging for it disabled.  Fortunately there have been some great tools introduced recently to assist with getting IPS protections out of Detect mode in a streamlined, automated fashion.

[Libor_Kovar]

Tim, could you pls name or elaborate the "great tools introduced recently to assist with getting IPS protections out of Detect mode" ? Is it inyour new book ?

[PhoneBoy]

Believe he's talking about TailoredSafe.
https://community.checkpoint.com/t5/IPS-Anti-Virus-Anti-Bot-Anti/Moving-from-Detect-to-Prevent-TechT...