Who rated this post

@EngineerActo, I understand your frustration and we (in R&D) are doing a deep learning process to see how this access can be managed better, and will then find a way to incorporate improvements into the product.

First, it's important to emphasize that the most important step is to install the HF or JHF that fixes the vulnerability. That is the most effective way to be protected.

Following that, I also understand the motivation in having more control over who can access the gateway's portals (even after patching). I want to share a bit more info and a configuration suggestion that may do what you are looking for.

It will help to understand a bit how implied rules work. Implied rules are meant to simplify configuration and help avoid situations where customers drop basic networking access that is needed for the gateway to function properly. For example, we don't want admins to have to explicitly allow Management access to push policy to the gateway, and we don't want them to get locked out if they accidentally block such access.
Implied rules can be embedded in different places in the policy. “Before drop” means that they are applied before the first drop rule. “Before last” means that they are applied just before the cleanup rule, but if the admin defined conflicting rules, those rules will be applied before those implied rules.

The implied rules that open access to the portals are defined by default as “Before drop”, which means that any explicit blocking (such as geo-fencing) in your policy will not take effect. The reasoning was that many customers define an explicit “stealth rule” for their gateway, blocking any external access to it. Without the implied rule before the policy, many wouldn’t understand why the portals that they activated aren’t working.

We actually encountered this challenge when we released Playblocks. We have a very effective playbook that fully blocks IPs of machines that attempted high-confidence IPS attacks. We saw that our blocking was very effective for access attempts into the network, but the attackers could still access the portals of the gateways. Changing the default of the implied rules could cause unexpected network changes, so we worked with the gateway R&D team to create an opt-in variable that allows customers to move the portals' implied rule to “Before last”. This keeps open access before the cleanup rule, but if those customers have a stealth rule, they need an additional rule to open access to the portals from desired networks.

Bottom line: here is the SK that moves the portals’ implied rules to “Before last”, which will make your explicit drop rules effective. You activate an environment variable on your management and it will apply to all gateways. Note that it was originally released as a hotfix, but after was integrated to Jumbo (JHF) and its been out for a while.
https://support.checkpoint.com/results/sk/sk180808

Once activated, your geo-fencing rules will take effect. Remember to explicitly open access to the portals if you have any block rules (beyond cleanup) that may block legitimate access to the portals.

I also want to relate to @the_rock's suggestion to limit external https access to the portals via https://support.checkpoint.com/results/sk/sk105740. It's not a bad measure, but AFAIK it's not hermetic as it only applies to port 443, while port 80 may still be accessed.