Is it possible to add a rule to a gateway while the management server is down?

[wagnerch]

Hi,

is it possible to add urgent rules into a firewall gateway while the CP-management server is not available?
(mgmt down - eg. maybe because of any huge VMware-, network-, storage issue, etc.)

I know that there is such a possibility for other vendor products like eg..Barracuda (there called "Emergency Override"), but I do not know if there is any similar solution for Checkpoint products.

Of course deploying the CP-management with two bare-metal hw-appliances as HA-pair reduces the risk for a longer downtime, but having also the possibility to add temporary rules directly to any gateway would help for some more failure recovery situations.

Regards,

Chris

[_Val_]

Yes and no.

Let's start with NO. Although there is a way of adding some rules at the top of the policy with CLI "fw sam" commands, you do not want to do that for many reasons. Most important ones are: SAM rules are not easily visible on your management, they are always the first rules before the policy package, and if handled without enough care, they may be extremely disruptive.

Now, YES. Look into sk112061, for CLI section, since you want to do them directly on your FW. Mind, in the cluster, you have to add them twice, on per member basic.

[Yuri_Slobodyany]

Always wondered if it is possible to CLI create <policy>.pf files on the gateway (after all it is a text file of PF script commands) and fool the gateway into loading it as current policy 🙂 ?

[_Val_]

Nope, that will not work.

There is another hack, changing default policy settings and then force GW to recompile it and apply instead of one installed before. On top, if you want traffic to be forwarded, IP forwarding should be enabled (it is off with default policy). i have seen that working, and I do urge you not even to try doing that 🙂 

[cjthuys]

It would appear this no longer works. 

I tried doing this using the example below and whilst I can see in the logs that the connection was using the sam the default deny for my inline layer still rejected the connection.

I assume this may be due to the action being notify. there is no accept available.

Any thoughts?

fw sam_policy add -u -t 120 -a i -l r -n "temp vc access" ip -s 10.0.92.19 -d 10.0.74.130 -p 443 -r 6

[PhoneBoy]

SAM rules are not meant to "accept" traffic only alert on and block.

[cjthuys]

That's what I thought also. However this old thread suggest that it is possible in an emergency. I was just wondering if it is no longer possible or is the sample I gave above just wrong?
I tried on a gateway using r81.10 Take 79

[PhoneBoy]

Existing mechanisms like SAM or fwaccel dos can only block traffic before the access rulebase.
Any “allow” rules configured there are still evaluated against the access policy you’ve configured.

The functionality requested here (ability to configure an access policy rule independently of central management) is on the roadmap.

[Yuri_Slobodyany]

The short answer is No. 

The long answer, as @_Val_  detailed in his answer is SAM rule, BUT ... those are designed to only block traffic to/from malicious destinations/sources.  Just simple "block traffic to this IP" kind. Which means you cannot create fully fledged Security/IPS/AppControl/URL filtering/etc rules that would allow some traffic. And my guess it is what you meant by "emergency rule". 

Once, dunno R85 (?), there is a fully capable API on Gateways may be we will be able to circumvent SMS management for emergency cases, until then ...

[_Val_]

I would not build any expectations on API capabilities. Gaia API are for OS parameters, not policy. And Management API needs just that, the management 🙂

[Bob_Zimmerman]

Of note: it has been recommended for at least 15 years that the management server not be behind a firewall it manages. It is extremely easy to get yourself into a situation where your firewall policy doesn't let you get through it to the management server to fix a problem.

[_Val_]

I second this notion 🙂

[Yuri_Slobodyany]

I can understand your intention, but for many readers of this post it sounds like you recommend design in Case B in picture attached , not sure it would be a good idea 😊

Do NOT use Case B design

[_Val_]

That's no what he said. Of course exposing MGMT server to external access is a bad idea. It has to be in a fully secured zone. The notion is, access to it should not fully depend of FWs that MGMT server controls.

[the_rock]

You can use below example:

https://sc1.checkpoint.com/documents/latest/APIs/index.html#cli/add-access-rule~v1.5%20

You can also refer to below post:

https://community.checkpoint.com/t5/API-CLI-Discussion/How-to-add-access-rule-using-CLI-in-r80-30/td...

But, as @Bob_Zimmerman said, thats 100% logical reason why you should never have mgmt behind the fw it manages.

Andy

[wagnerch]

Guys, thank you for all your feedback.

I understand that there should be no firewall between firewall management and its gateways.

But what if a customer would have many gateways all over the world at different locations?
Then I would need a separate mgmt system on every site to avoid having a firewall (or any other problem) between the gateways and the management?
This sounds expensive and also difficult to administrate (object/rule duplications, etc.)?

For the vendor Barracuda this guideline is not necessary and there is no chicken/egg-issue (if you are prepared for Emergency Override).
You can configure all rules (with all functions like nat/ips) temporary also directly on each Barracuda gateway (with Emergency Override).
This means that you can connect to each gateway directly with your administrative GUI client.
After the mgmt is available again you can add the changes to the central mgmt system and sync the new configuration back to the gateways.
In my opinion this is a big advantage and the firewall adminstrators can sleep better when having such a fallback solution 😉

Would be great if Checkpoint would implement a similar solution in future (eg. with SmartConsole web client).

[_Val_]

Then I would need a separate mgmt system on every site to avoid having a firewall (or any other problem) between the gateways and the management?

Not true. 

[Scott_Paisley]

The Checkpoint solution is to have an Active management server and a Standby management server. If they are geographically dispersed, your International gateways should be able to reach at least one of them at all times.

[Tomer_Noy]

Can you provide info on what kind of emergency you need to handle?

Another option that may be simpler (but will only handle specific cases) is to use dynamic objects. You can prepare a few placeholder rules in your policy that have dynamic objects in their Source/Destination. In usual cases the dynamic objects would be empty.

When you have an emergency and want to activate one of those rules, you can use the local gateway cli to set values into those dynamic objects.

https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_CLI_ReferenceGuide/Topics-CL... 

For example, if you have a premade rule for SSH access from outside (with SSH in the service column), in case of emergency fill in the desired source and destination.
You can do more advanced stuff with inline layers and dynamic objects in the entry rule into the layer.

I wouldn't recommend keeping such rules populated and active in your day-to-day, since indeed it can make it difficult to understand from the Management UI exactly what is allowed and what is blocked. However, it can be useful for dynamic or emergency cases.

[wagnerch]

Hello Tomer_Noy,

my idea was also to prepare objects and rules. My guess were DNS-based objects which I configure or change within the internal dns management in case of any problems, but dynamic objects are more flexible in some scenarios.

Of course I like a central fw management and also the vendor Barracuda uses a centralized management in normal conditions.

But in case of any big infrastructure failure (eg. blade server / vmware / SAN storage / network) there is a risk that the fw management (specially virtualized ones) cannot be used to implement additional rules to troubleshoot/fix any huge, urgent problem.
(sample: add a temporary rule for allowing internal engineers to get external technical support when the internal proxy-serverfarm which is used for Internet access is also impacted by the actual problem)

In my opinion not every failure scenario (chicken/egg) can be pre-thought and completely avoided (also think about human failures torpedoing your well-thought high-availability and disaster recovery plans).
And or course the fw-change has to be done very fast, so that the impacted customer services can be recovered as fast as possible (think of thousands of users who cannot do their job).
(the fw-change process should not impact additional still functioning services)

So I will consider to implement dynamic object-based place holder rules. Thanks for that hint.

Regards,
Chris

[Wolfgang]

@wagnerch I would prefer using Management-HA in such a case. If so many enduser are affected and you're need is to have an always on firewall management you can setup these secondary mangement at another location. If the first one is failing or not available you can change any rules with the secondary with the same tools and processes like on the first.

see How to Configure Management HA 

[Wolfgang]

Hello @wagnerch 

the concept how Check Point manage the gateways requires a managementserver. This has a lot of advantages regarding managing every device alone. Having a firewall between the managementserver and a remote gateway is a normal use case.
Managementserver in your central location protected by central gateway and remote gateway is reachable via internet in a remote location. The central gateway is the firewall between your management and remote gateway.
Thousand of installations here are using this design without problems. If you use the implied rules connections between management and gateways are always allowed and if you use the default settings you can't override these with you rulebase. If it is important for you, you have to implement redundancy for the central gateway and the management. Availability of the management is a main key to manage a Check Point environment. With management-HA you can deploy a secondary management at a local or another location.
For a large environment I would prefer to keep an eye on redundancy rather then adding rules direct on gateways.

If you don't want to use a management on premise you can go on with management in the cloud. Check Point has such solution and with this there is no firewall between your management and your gateways (if they are connected to the internet).