- CheckMates
- :
- Products
- :
- Quantum
- :
- Threat Prevention
- :
- IPS confusion
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IPS confusion
Hello,
Is somebody able to clear up some confusion over how IPS works please?
Customer has IPS enabled, using the "Recommended_Profile".
The policy is set to prevent most stuff.
When I look at the list of protections, under the "Recommended_Protection" column, the vast majority of protections are set to Prevent, either natively or from manual override. There are a small bunch set to detect, and a small bunch as Inactive.
When I go to Logs & Monitor > General Overview, I see this:
Notice that the pie chart shows 94% as Detect, and only 6% at Prevent.
Notice also that the "Critical Attacks Allowed by Policy" box shows (I think?) that a number of critical severity attacks have been allowed to happen.
Now let's take one of them as an example... "SQL Servers UNION Query-based SQL Injection" has apparently been allowed to happen. But if I check the actual protection, it is set to Prevent. This is correct according to the policy as it matches all of the performance, severity and confidence criteria to be automatically set to Prevent.
So what's going on?
Why does the General Overview page seem to be so wildly different and wrong compared to what is configured in the policy? Why for example does it report that SQL UNION attack as being allowed according to the policy, when the actual policy states it is set to Prevent? And why is the pie chart showing do much Detect when in reality very few protections are set in Detect mode?
I presume there's an easy explanation that I'm not aware of?
Thanks,
Matt
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quick update on the issue. I had a very helpful remote session with @Alon_Alapi and he found the problem... There was an exception for Any Any Detect. I can't explain how that got there, but at least that likely explains the discrepancy between the protection settings and the Overview pie chart. We got to this via the Rule ID link in the log card.
In this case, it's Exception rule E-1.7 below (which has now been deleted).
Lesson - check for IPS exceptions!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are the gateways in question R77.x?
Have you looked at the actual log entries generated by these protections?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Look in IPS logs it will show all Prevent/Detect, SECURITY POLICY-->Threat Prevention--> IPS--> Logs.
The pic you posted showing threat prevension report, it could be because you recently change the CVE to prevent, and it's display the detect before the change applied. but in IPS Logs you will see if still in detect or prevent.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please provide the full log card for the "SQL Servers UNION Query-based SQL Injection" attack. It is difficult to say what is happening otherwise, it could be an exception, that signature could be in staging mode, the IPS properties on the gateway are set to "Detect Only" instead of "According to Threat Prevention Policy", or you have some other signature falsing constantly that is set to Detect and it is skewing the pie chart.
CET (Europe) Timezone Course Scheduled for July 1-2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Matt,
I am a group manager in R&D responsible of Access and Threat Prevention management.
I would like to follow up on this, can you please email me to: alonal@checkpoint.com so we can continue this offline?
Thank you,
Alon Alapi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quick update on the issue. I had a very helpful remote session with @Alon_Alapi and he found the problem... There was an exception for Any Any Detect. I can't explain how that got there, but at least that likely explains the discrepancy between the protection settings and the Overview pie chart. We got to this via the Rule ID link in the log card.
In this case, it's Exception rule E-1.7 below (which has now been deleted).
Lesson - check for IPS exceptions!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Following on from my recent IPS query, I have another similar one... I've noticed for one customer in the log General view, the pie chart again shows mostly "Detect" with only a little bit of "Prevent". The table next to it shows a number of critical attacks allowed by the policy.
So the first thing I checked is the Exceptions.
There are a couple. Rule 6 in the screenshot below is the basis of my question. I have a /24 network object in the "Protected Scope" box, and Source is Any.
What will this rule do?
How is "Protected Scope" different to "Source"?
Will rule 6 only apply to traffic from/to the specified /24 network?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Protected Scope basically takes the place of two rules:
1. Source "Protected Scope" Destination "Any"
2. Source "Any" Destination "Protected Scope"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Another way to look at "Protected Scope" is that when an object like a network is placed there, any traffic going into or out of that network will match the rule regardless of which way the connection was originally initiated.
CET (Europe) Timezone Course Scheduled for July 1-2
