IPS blocks traffic even if the traffic is blocked by Access Policy

[Hllrdm]

We found in the logs that our traffic is blocked twice by Access Policy and by IPS.
We have a rule configured in the Access Policy (one of the first), blocking by Geo Protection. We see that the Access policy is blocking the connection and we see that drop in the logs.
But we also see that the same connection is blocked by IPS policies, although by Access rule the connection is already blocked.
Is this Check Point behavior correct? If it's not the correct behavior, is there any information on how we can configure the correct rules or settings?
If I'm not mistaken, if the traffic is blocked at the Access Policy level, then it should not be inspected by the IPS blade?
Is there a sk or a manual that describes why this happens?

[Timothy_Hall]

If you are using Geo Policy located under Shared Polices, and not R80.20+ Geo Updatable Objects this is expected behavior.  The Geo Policy check is performed right after anti-spoofing enforcement and prior to any Access Control policy layers.  

Prior to version R80, the geo enforcement mechanism was called Geo Protection and was simply another protection/signature of the Threat Prevention IPS blade.  However in R80 Geo Protection was moved out of the IPS blade into the Access Control policy and renamed Geo Policy.  However in some logs you'll still see references to the IPS blade (and sometimes the old term Geo Protection) even though Geo Policy has nothing to do with the IPS blade in R80+.  So it can look a little confusing as generally Access Control is always enforced prior to any Threat Prevention inspection.

Note that there are also some other Threat Prevention reputation checks that can potentially drop traffic prior to any Access Control policy checking/enforcement, see here:

Are IoC feeds processed before Access Control policy

Geo Policy was deprecated in R81 (although it is still supported) and you should use Geo Updatable Objects instead going forward.

[Hllrdm]

We are working on the R81 version.
And we use the object mechanism on the Access control policy. Is it correct that the mechanism handles both IPS and Access Contol (Geo Protection)?

That is, we see two drops of the same traffic by FW blade (Geo protection, objects specified in the Access Control rule) and by IPS blade.

[Timothy_Hall]

When you say "object mechanism" I assume you are referring to Geo Updatable Objects referenced directly in your Access Policy Rules.  If so, this has nothing to do with Geo Policy or Threat Prevention, the country objects are simply dynamic lists of IP address that is updated by Check Point.

If you see a country-based drop referencing "Geo Protection" or the IPS blade, that is the separate Geo Policy under Shared Policies; this is enforced prior to any other rules so if you see a country-based IPS/Geo Protection drop that is Geo Policy, and you will not see a another drop against an explicit rule in your Access Control policy with Geo Updatable Objects for that same traffic.  If however the traffic is initially allowed by Geo Policy it can still get dropped by an Access Control rule with a Geo Updatable Object in it, and that will look like a regular Access Policy log and not reference IPS.

[Hllrdm]

“When you say "object mechanism" I assume you are referring to Geo Updatable Objects referenced directly in your Access Policy Rules. If so, this has nothing to do with Geo Policy or Threat Prevention, the country objects are simply dynamic lists of IP address that is updated by Check Point”

Yes, you are most likely right. I expressed myself incorrectly. In the logs, we see a blocking by IP addresses by the FW blade, but at the same time we see another blocking by these addresses of the IPS blade. Is this behavior correct? Shouldn't the traffic be ruled out with FW and not reach the IPS check?

[Timothy_Hall]

Geo Policy drops are actually a Firewall blade/Access Control drop, any references to IPS/Geo Protection you may see in the logs for this are incorrect and left over from when Geo Policy was a part of the IPS blade in R77.30 and called Geo Protection.

In most cases yes Access Control (including the Firewall blade) is always applied prior to Threat Prevention (which includes IPS), but there are some limited exceptions to this described below that are not directly relevant to your situation:

https://community.checkpoint.com/t5/Security-Gateways/Are-IoC-feeds-processed-before-Access-Control-...

[Hllrdm]

That is, I understand correctly that this is the correct behavior, that Firewall policies drop traffic and after that Ips also drops this traffic (2 drop logs for one traffic in the logs)? Is there sk where it is described that this is correct?

[Timothy_Hall]

I think we might be talking past each other, can you please provide redacted log cards for the two entries you are seeing?  There should just be one log for that kind of drop.

[Hllrdm]

For example, here we see the logging of the same SRC and DST at about the same time, but it is done by IPS and FW blades. The FW policy is described above, as you wrote it's IP address objects.

[Timothy_Hall]

Those look like two completely separate events to me. 

The first one is a definitely Geo Policy drop based on IP address.  The second one is matching an IPS signature and assuming the connection was TCP-oriented (you have the protocol redacted) there is simply no way the second event is related to the first, as an IPS signature like that can't trigger until data begins to flow inside the connection after the TCP 3-way handshake is complete.  The handshake wouldn't be able to complete if Geo Policy dropped the first packet of the connection.  Also note that if you look under the "Matched Rules" tab of the second screenshot it will almost certainly show a rule(s) in your Access Control policy which can't be reached unless the traffic was not blocked by Geo Policy in the first place.

Unfortunately I'll need to see the log cards without any redaction to assist further, if you want to PM them to me I can take a look.  I need to see screenshots of the full log cards and all their tabs (matched rules, etc).  But I'm already 99% sure these two logs are not directly related.

[Hllrdm]

I will send you the logs in private messages a little later. You also write that IPS cannot work if a TCP connection is not established. But we use the IPS blade to block all connections in the first rule (Geo Protection). Should the TCP connection work, and hence the IPS blade, if we have already blocked any connection with the first FW rule?

[Timothy_Hall]

What I said was *that signature* can only trigger if data is flowing in a TCP connection after it is established, unless somehow that signature could be transmitted in a single UDP packet which doesn't require a 3-day handshake. 

The TCP connection will not work at all if this first packet is blocked by Geo Policy, same applies to UDP datagrams.  If a packet is dropped by Geo Policy, to my knowledge no Threat Prevention will be applied to it thus no IPS signature logs even if there was an actual attack in the payload of that UDP datagram.  No need as we are dropping it anyway...