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...

[MartinZ]

Tim, if I can add to this - we see the same behavior and it is confusing. As I understand it the Geo Policy used to be part of the IPS blade. We changed to the updatable objects in the policy rules, so now the Geo Blocking is happening in the access rules. As I understand it the IPS blade comes first. Is that true? If it is that might explain the original question.

When I look at the cyber attack view, I see IPS hits on countries we have blocked in the access policy. The normal expectation would be that a geo blocked IP would not make it to the IPS, but if IPS is still coming first (where geo blocking used to be) then this would be expected behavior.

If this is wrong, then I am seeing the same pattern as Hllrdm.

If this is right (expected behavior because IPS comes first), it is adding a lot of unnecessary noise. If true, is there a good way to change that behavior? I assume even if we layer the access policies it wouldn't matter if IPS is coming first.

[Chris_Atkinson]

Is the destination of the traffic the gateway itself for a service such as HTTPS or other traffic?

[MartinZ]

Yes on both for the ones I just checked. 

[Timothy_Hall]

Geo Policy did used to be part of the IPS blade, but the Geo Policy function has always been applied prior to the Access Control policy around the same time as anti-spoofing enforcement.  So seeing Geo Policy drops before the Access Control policy (where you are using Geo updatable objects) is expected behavior.

Apparently there are also IP address-based reputation drops that can happen prior to the Access Control policy due to the AV/ABOT blades.  When I asked why this was done the answer was if the firewall knows that it is going to drop a packet based only on an IP address, might as well drop it early before we expend the additional overhead of evaluating the Access Control and Threat Prevention policies for it.

[MartinZ]

Thank you for the response. I am expecting to see what you describe:

"So seeing Geo Policy drops before the Access Control policy (where you are using Geo updatable objects) is expected behavior."

"If the firewall knows that it is going to drop a packet based only on an IP address, might as well drop it early"

But as I noted:

"When I look at the cyber attack view, I see IPS hits on countries we have blocked in the access policy. The normal expectation would be that a geo blocked IP would not make it to the IPS"

Looking further based on @Chris_Atkinson question, most everything I can see getting through is targeting the gateways. So is that the connection happening to get the IP address for locating it? Still, why does it go through IPS?

I also see a lot of port scans from blocked countries.

[Timothy_Hall]

There are implied rules that will permit traffic on various ports to the interface IP addresses of the firewall to assist in the operation of VPNs and other features.   These implied rules will permit the traffic prior to your Geo Object blocks in the Access Control policy.  At that point since the traffic has cleared Access Control it can now hit IPS and Threat Prevention.  Usually this is garbage probe and scan traffic that happened to randomly hit the interface address of your firewall.

When you were using legacy Geo Policy to block the countries, the block would occur well before the Access Control policy implied rules (it is right around the time of the antispoofing check), which is why the packets wouldn't make it to IPS/Threat Prevention to be logged that way. 

Depending on the port number(s) being allowed to the firewall interfaces in the implied rules you *may* be able to close those ports without breaking something, but this is highly dependent on what features you are using especially Remote Access VPN/Mobile Access Blade. Here are some examples: sk165937: How to disable the connection to Security Gateway on TCP Port 80 and on TCP Port 443 & sk132712: Vulnerability scan shows ports 18231 and 264 open under LISTEN mode when using TLS1.0 and ... & sk100647: Check Point response to common false positives scanning results

But I would strongly advise against unchecking anything on the Global Properties...Firewall Implied Rules screen as that is very likely to break stuff in ways that can be difficult to recover.

[MartinZ]

I agree on not changing any global properties. So it does appear traffic going to the gateways and ports scans are not being Geo-blocked. I'm not sure why that is, but it seems wrong. I know the IP/certificate is out there for VPN connections but I'm also not sure why I wouldn't want that to be Geo-blocked like everything else. Must be some architecture reason/issue.

[Chris_Atkinson · Accepted solution]

This is expected behavior, an additional resource to reference in addition to those supplied by Tim above is sk105740.

[MartinZ]

There is an important piece in that SK:

"A new feature which ignors the “before last” implied rules is available. A kernel parameter: fw_ignore_before_drop_rules controls the Security Gateway's behavior."

Value	Description
0	Feature is disabled. Default value.
1	Feature is enabled. Implied rules do not take affect for port 443. Connections have to be allowed in the rulebase.