How do you optimize IPS effectively?

[Ilmo_Anttonen]

I've had a couple of gigs lately where I help clients migrate from R77.30 to R80.10 and I've taken interest in how to help them optimize the IPS while we're at it. Most installations I've encountered have the Recommended profile with a couple of exceptions for 2-3 services. Those already running R80+ have the Optimized profile with the same. Other than that it's all left the way it was out of the box. The optimized profile really does help improve performance! But, that's not why you have the IPS blade enabled.

I don't have much experience tuning the IPS since before, but now I really want to do something about all these out-of-the-box configurations left running.

When I look at an organizations IPS config I ask them what OS/Applications etc. they are running. I ask them how frequently they patch every individual OS/Application, and if there are any applications they cannot upgrade (read java) somewhere. Then I uncheck all the services that aren't present and all definitions/CVE that are older than 3 years for the present services.

This is something I just thought up myself. This approach could be crap for all I know, I just did something that felt feasible. If you patch your stuff, 3 year old bugs should not be a problem as long as you don't use software that is no longer supported. Right? Maybe 3 years is too short or too long, you tell me. Maybe that's only applicable to some software. Once again, what do you think?

That is the time-saving quick shave approach. But what should I do if I want to go more granular? Where do you guys look to stay updated? I mean, if you have 10 applications and OS's, no problem. But with large organizations it's a pain. Hence the quick shave.

Couldn't find a post like this so here I am. Hopefully others have this question as well.

/ Ilmo

[G_W_Albrecht]

I would refer you to the following document: R80.10 IPS Best Practices Guide!

In R77.30, it was the best not to change much, but use the recommended or optimized profile rather as-it-is, as changes there could have a very bit influence on performance. Also, one should rather use Prevent than Detect in Protections after the first IPS testing/deployment phase, as both will use the same ressources but only prevent will be helpfull in protecting.

[Ilmo_Anttonen]

Hi Günther and thanks for the input. I've read the IPS Best practices document before creating the OP. It does not answer my question in any greater detail. The guide basically says - Set anything that is not a false positive to prevent, regardless of if it did or didn't generate log during the test phase. Maybe that is good enough for most. I rather have protections on by active decision.

I'm also curious about if the IPS updates disable inactual protections? If not, that's another thing that needs manual handling. Unless you have a powerful enough system to not care if you have unnecessary protections.

[G_W_Albrecht]

Then you also did study sk95193 ATRG: IPS already (besides the Threat Prevention Administration Guide R80.10) ? To have protections configured as on only manually is the most tedious workload i can imagine at all 😞 But if this decision comes out of decades of your practical IPS experience and troubleshooting, i am surely not the person to suggest anything other...

[Ilmo_Anttonen]

Oh! I did forget to read the ATRG, thanks for reminding me. I'm sure there will be a bunch of good lessons to be learned. I don't have decades of practical IPS experience, like I said in the OP. I simply described what I see as an issue, how I go about it and asked you guys to let me know how you do and what your personal experiences are. I believe there is not one config to rule all scenarios and these best practice guides usually just point you in the general direction. There is certainly not much inspiration to be found. Advice from experienced people is worth so much more.

[Vladimir]

If we are talking about IPS in R80++, than I would like to point out that the most interesting feature in its current implementation is the ability to define "Protected Scopes" and apply customized protection Profiles to those.

I.e.:

1. Clone the "Optimized" profile a few times and name those for the scopes they are protecting (IIS, Apache, SQL, etc..)

2. Delete or disable or irrelevant protections in each cloned profile

3. Add more rules in the Threat Prevention policy with scopes aligned with corresponding profiles

Regards,

Vladimir 

[Ilmo_Anttonen]

Thank you, that looks like a neat way to keep track and trim down the policies. Does it affect performance to run several policies vs. just using a single one?

[Vladimir]

It really shouldn't. If anything, application of targeted subset of protections based on target should minimize the utilization.

[Tomer_Sole]

I would suggest integrating the IPS Tags within your profile, to disable all protections that are tagged with unneeded OS's/protocols/products. The best practices guide discusses that at the "extending the IPS configuration" section (pages 14-15).

At page 15, the guide also discusses creating separated IPS profiles for different needs at the organization so that could be a recommendation as well.

[Ilmo_Anttonen]

Thank you Tomer,

I see that I missed the part about separated IPS profiles. Vlad also gave a useful example of this in the post above. I like this approach. I've been using the tags to do the initial trims of the profile.

[Daniel_Kavan]

>4 years later...  Are you still doing this as a strategy?   My ISSO just asked if its worth the performance boost to turn off defenses older than 3 years (knowing we patch regularly).

[George_Ellis]

Zombie Thread alert 😉

My approach is to create global IPS signature policies that align with the environment.  I have a data center, corporate internet, customer service center, vpn, and extranet signature groups. 

Clone Optimized.  Then go into the clone as remove all signatures that have nothing to do with your environment.  All of the consumer router/modems such as D-Link are not in the environment, so all get to inactive.  Now you have a core for your company.

Now look at the environments.  In a Data Center, there should be no users.  So anything phishing or user centric gets removed.  Everything like that.  All the server centric and ddos protections are on that apply.  If you don't have MySql, remove those (things like that).

In a customer service center, that will be an internet access area with PCI considerations (credit cards in use).  So it gets protects above what the corporate internet would use.  It 'may' have a limited use of some servers in PCI zones.  So phishing / malware types would be in play because of the human interaction.

Corp is focused on humans at keyboards and internet.  Hardly any server or DDOS attacks expected.

VPN - least populated.  Clients should be protected at their side.  Prevent / Detect against worms and self-replicating malware.  Watch for rooted client traffic (leap frog style methods).

Your mileage will very.  This is done in globals so we can create 4 policies, managed in on spot and consistant to every domain (instead of managing multiple policies in multiple domains).

[George_Ellis]

PS - Data Centers have URLF enabled.  Uncatergorized blocked, and only a few categories allowed such as financial things, computer stuff, business centric categories.  Block all the rest as one layer of many to stop exfiltration or malware at the https level.  No one should be surfing in the data center block.  White listing may be required.