Can I lock myself out completely?

[EHammann]

Dear community,

we have a Checkpoint firewall R77.30 (will upgrade to R80.30 soon).

Supposed, the very first line of the ruleset is "deny any any".

Does that mean I am completely locked out forever, or is access from SmartDashboard to the management and policy installation from there to the inspection gateways still possible?

Thanks,

Ernst

[Tal_Paz-Fridman]

Hi

You are not completely locked out. There are special Implied Rules that allow communication between Check Point objects.

You can read more about it here:

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[_Val_]

This depends on the status of your implied rules and your specific security system configuration.

If you are using distributed configuration (MGMT and GW are different machines), installing Any-Any-Drop will not break MGMT2GW communications, with intact implied rules. SSH, WebUI and other means to access that particular GW will be broken though.

If you are using a Stand Alone config, meaning both MGMT and GW functions belong to the same machine, then yes, you will lose SmartConsole access as well.

[Maarten_Sjouw]

The implied rules will only be active when the Global rules have not been changed.
When you have completely locked yourself out, you can only unlock this by going in through the console and type 'fw unloadlocal' to recover the access.

[mdjmcnally]

For this to happen then would have to have a 1 Line Policy, and the Global Implied Rules turned off that allow the Management/Gateway connections.

If Line 1 is Any, Any, Any, Deny

Line 2 is Source, Dest, Services, Accept

Line 3 is

Then policy verification fails as Line 1 would hide all the other lines.

Providing you have the Default Implied Rules active allowing Control Connections, CPRID etc then your Management Server can install policy to the Gateway

[PhoneBoy]

Regardless of the ruleset you should be able to access the gateway via the serial console and unload the security policy with fwm unloadlocal.

[Tal_Paz-Fridman]

Small correction - should be fw unloadlocal

[Timothy_Hall]

There are two other ways to lock yourself out, thus requiring a fw unloadlocal to recover, as these are checked before even the implied rules:

1) Antispoofing topology mistake that blocks traffic from the subnet where the SMS is located.

2) Adding a SAM rule from the SmartView Monitor or fw sam command that blocks traffic from the subnet where the SMS is located.

For situation #1 antispoofing enforcement can be disabled in the fly without incurring a full outage, by running the following commands on R80.30 Jumbo HFA Take 71 or later:

fw ctl set int fw_antispoofing_enabled 0
fw ctl set int sim_anti_spoofing_enabled 0 -a

This capability may have been backported into a Jumbo HFA of R80.20 at some point, not sure.