Implied rules and hardening against attacks

[Hugo_vd_Kooij]

Where do we stand as a community in regard to implied rules?

While I understand it is very convinient to have them enabled. The major issue we have is that there is not much one can control in this regard and several of the latest CVE issues I have seen can't be mitigated in full if you rely on implied rules.

Also audits in the past always forced us to disable them as too much information was exposed during pentesting. So it is very easy to fingerprint a Check Point firewall.

It seems Check Point is very, very reluctant to disable them or give a better control on them.

For me this is at the moment the biggest issue we see in terms of exposure management. I am almost forced to put some sort of ACL or firewall before my firewall. 

In my experience some of the implied rules can be tough to setup with manual rules. As you may need 3 rules and some tweeks for some very specific traffic.

So in my view the middle ground could be to make the implied rules a sort of layer where you can choose to disable or enable the rules and not actually change them.

I can live with a guideline where I need to sort out my manual rules on my own if I disable any of the implied rules. But it will allow me to do so selectively as was sort of implied in at least one of the recent SKs in regard to a high risk CVE issue. (that information is propably gone by now from the SK.

But this is where as a community we can send a message of how we want our firewalls to work for us. So by all means .... comment on this.

[Alex-]

Given these rules can be visualised, having them in a special layer on top and bottom of production rules instead of checkboxes in the Global Properties would indeed be a welcome improvement.

[toblun]

Second this.

[Shyyyy]

Yeah I agree,
I think implied rules should only exist on the management port nothing else. that way we can avoid the risks you stated here.

[PhoneBoy]

I suspect we will or already are reviewing how Implied Rules are handled in light of the recent CVEs.
Given how deep some of these are in the code, it will probably have to be addressed as part of a major release.

[ccsjnw]

I echo everything that has been said above. It would be extremely useful to see (and have full control) over the implied rules in the standard policy view.

Having a feature where an administrator can simply disable specific implied rules would be very welcome - when an implied rule is disabled by the administrator, just pop up a warning message stating that the administrator will need to create their own appropriate rule. Job done - this doesn’t need to be complicated.

Please can CheckPoint ensure that Geo Blocking rules are applied *first*. We need this for all inbound connections including Remote Access VPN clients trying to establish a connection with a Security Gateway.

Country specific Geo blocking is now *mandated* by some government authorities in the Arabian Gulf region, and it is very painful to do this manually. This has been asked for many times, and there’s always been arguments against this, but customers need this functionality to comply with local in-country restrictions.

[PhoneBoy]

You can handle geo blocking by using the DoS mitigation tools similar to: https://community.checkpoint.com/t5/Firewall-Security-Management/Block-VPN-Traffic-by-Country/m-p/17...
These are applied before implied rules.

[ccsjnw]

Need the option of doing it the other way around, not disabling on a country by country basis. And this needs to be possible within the SmartConsole policy view - we shouldn't have to be doing this within Gaia.

Use case: Block inbound Remote Access VPNs from *everywhere*, with the following exceptions: allow all addresses in a specific Gulf country and allow 4 specific addresses in the UK.

[D_TK]

I tried a little test today on one cluster in my attempts to get all implied rules turned off.  It was close, but had to revert.   Very simple design,  On prem (publicly addressed) management/logging running r82.10 and (9) clusters all running r82 or r81.20.  I disabled all implied rules, and created these very clear and simple 4 rules at the top of the policy for the test cluster.  Note that the "any" services was going to be set granularly after a few days of logging:

Rule 1:  Management -> test cluster VIP/ both public real IPs: any services

Rule 2: test cluster VIP/both public real IPs -> Management: any services

Rule 3: all gateways/VIPs <-> all gateways/VIPs: any services.  This is for all VPNs

Rule 4: test cluster VIP/both public real IPs -> Internet : any services.  This for DNS/ntp/threat updates....

Pushed policy to the test cluster and all was good for about 30 minutes.  Saw traffic matching the rules as planned, all looked good, and then all tunnels to/from this cluster went down.  vpn tu showed no phase 1.  couldn't find anything salient in logs.

Enabled only "accept control connections - first" and tunnels immediately came back.  I would think this would have all be covered by the rule 3 i created.  

Any ideas would be greatly appreciated.