sk113479 | Why are packets being allowed that are not in policy?

[B_P]

We see in the firewall logs for an inbound port 22/sftp connection being allowed through -- at least the first packet is (two of them actually, each one a second apart). Not only is it allowed through the firewall, but our host-based firewall on the windows server detected the connection as well. The problem: we don't allow this ip/port combo through the firewall.

In the firewall log we see "Connection terminated before the Security Gateway was able to make a decision: Insufficient data passed" and a reference to sk113479. But the question is -- why is even one packet getting through when there's nothing even related to this type of connection?

I understand that if the firewall sees a possible match it might do this, but I don't see how that would be the case with our policy and especially with the limited inbound connections we have. As much as I love seeing packets coming from a VPN server on the other side of the world being let through into our network, is there a way to prevent it?

Gateway is running R81.10.

[Chris_Atkinson]

Do you have the protocol signatures option enabled? e.g.

Reviewing the issue with TAC might also be appropriate in terms of the level of detail you're happy to share.

[B_P]

There are two firewall rules related to the public IP I'm seeing this activity on. One is a custom TCP port and the other does not have "Protocol Signature" enabled. Do we know if it is where "Protocol Signature" is enabled on any service in any rule in the policy then it behaves this or does it also have to be related to the IP's involved?

[PhoneBoy]

Most likely the rules that "potentially match" are not specific enough or include things that invoke App Control.
Can we see ALL the "potential match" rules in your rulebase for this traffic?

[B_P]

I'm surprised with our current multi-layer rulebase, it's not enough logical separation to avoid this. I'm not seeing anything that would be a "potential match" until you get down into sub-layers that would have filtered out this traffic simply from the child's parent layer.

My rule base is essentially:

1 Source: Internet IPs (New Layer)

  - 1.1 Allow rules

2 Source: Internal IPs (New Layer)

  - 2.1 Allow rules

So what you're saying is that because I have "potential matches" on the 2.1 rules for something coming from the internet (because source may be blank on those or destination is an application like Facebook) then it's going to allow traffic from the internet like it was in the 1.1 layer?. That seems pretty wild to me.

What if I took all the inbound internet rules and put them in their own ordered Access Control layer like what was done for GEO IP? Would that be enough of a logical separation for the engine to not evaluate other stuff in the main layer?

[PhoneBoy]

Rules with "Any" service shouldn't cause this, it's rules that involve App Control/URL Filtering services.
We would need to see the exact rules involved (including the top-level rules leading to nested layers) in order to assist.
This might be better done through the TAC: https://help.checkpoint.com or possibly your Check Point SE.

[B_P]

Just a follow-up, we duplicated out our Source Internet rules to its own ordered layer without App & URL filtering enabled on it and it started blocking traffic normally. "Duplicated" because we still had to leave the rules in the final ordered layer to Allow acceptable traffic.

🚩 CPNotEnoughDataForRuleMatch does not mean only a few packets were let through for traffic identification.............. For example with FTP (Protocol Signature not checked), full authentication with the service can happen before the gateway steps in and blocks it like it should. We saw '230 Login OK' packets being sent back and the gateway was logging a block.............

It also advertises to the public that you have publicly reachable services even though the firewall is set to whitelist source IPs.

[PhoneBoy]

This speaks to the services used in the relevant rules.

In a Firewall only layer, the only valid services are ones that can be matched on the first packet (TCP/UDP services).
If you use App Control/URLF services, those services may require multiple packets to match (or not).
Note that the service FTP is a "simple" service, even though it has an INSPECT handler associated.

[B_P]

Yeah -- so if anyone publishes services out to the Internet and their firewall policy has App Control/URLF enabled -- they are susceptible to attacks from the general public regardless if they have a source restriction defined or not.

[PhoneBoy]

It depends on the construction of the policy.

[B_P]

Can you expand on that?

[PhoneBoy]

It comes down to the exact “services” or “applications” that are used in the relevant rules involving the same source and destination.
This is relevant due to the column-based matching used to evaluate the rulebase: https://community.checkpoint.com/t5/Management/Unified-Policy-Column-based-Rule-Matching/td-p/9888
A service like SSH or https will match on the first packet.
A “service” like Gmail cannot be identified on the first packet and will require several packets to be permitted before a final decision is made.

Order of the rules matters as well.