Top human fails to avoid

Victor_MR · ‎2019-03-01

Hi all,

It's a long time since I've thinking in this topic. After years working with Check Point products, inside and outside Check Point, I see repeatedly the same several mistakes. I'm aware that this topic is not very 'corporate', but I still think it would be good to compile a list of typical fails when deploying or managing Check Point devices, in order for people to be careful with not falling into the same ones!

I'm specially referring to mistakes that are basic, easy to avoid, but with usually very bad consequences. Another TOP list So here you are several epic fails deserving of the following gif:

Don't try this at home!

(without any specific order):

Deploying a new VSX Gateway and forget to change the number of CoreXL instances per VS.

This is typical from people who doesn't know VSX. If you're migrating to VSX, or just deploying a new cluster, and you're also using some Software Blades, each VS will need enough CPU power to process the traffic. Of course, it will depend on the amount of traffic, level of inspection and amount of accelerated traffic.

This fail is also curious because during the maintenance window everything usually works, but the next morning, when the load of traffic is high, everything goes wrong.

Deploying a new VSX Gateway and forget to change the default limit of the maximum concurrent connections.

Pretty similar to the previous fail, this time affecting to the amount of the concurrent connections a VS can manage. Remember that you need to specify these kind of things for telling the VS the amount of resources it has.

Threat Prevention policy with a "Any Any ... Any" inspecting everything.

This is something that is difficult to do with many other firewalls, where you have to manually assign a profile per access control rule. Think in an environment with a thousand of rules for instance.

However, we have an access control policy and a threat prevention policy, allowing to easy separately manage these two different things. The drawback is that someone may just enable the Threat Prevention Blades (IPS, AV, AB, TE, TX) to all the traffic, regardless if it makes sense or not.

Have in mind that a Security Gateway may be located in the datacenter network, internal access network, external perimeter, front-end, cloud... everything in one place, a combination of them... Think in your main traffic flows and how you want to protect them. Then, you can build a simple Threat Prevention policy, enabling the Blades that it makes sense to enable in each one and, of course, you don't need to go over each of your access control rules to do it

To be continued...

PhoneBoy · ‎2019-03-01

Maybe a list of anti-best practices?

Mark_Mitchell · ‎2019-03-02

From an operational point of view...running kernel debugs outside of a maintenance window.

Maarten_Sjouw · ‎2019-03-02

Doing exactly what TAC asks you to do while debugging.

When you need to check on a specific problem on a highly loaded gateway and the only time you can do some troubleshooting is during business hours and TAC asks you to run 'fw monitor -o debug.pcap' and you just type it in without any filtering. A sure thing to get your gateway to it's knees.

Regards, Maarten