Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Victor_MR
Employee Employee
Employee

Top human fails to avoid

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 Smiley Happy So here you are several epic fails deserving of the following gif:

Resultado de imagen de orson welles 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 Smiley Happy

To be continued... Smiley Happy

5 Replies
PhoneBoy
Admin
Admin

Maybe a list of anti-best practices? Smiley Happy

Mark_Mitchell
Advisor

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

Maarten_Sjouw
Champion
Champion

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
0 Kudos
HeikoAnkenbrand
Champion Champion
Champion

Hi Victor,

You're talking to me from the sele:-)

Most problems are caused by configuration errors or default settings that are not adjusted.

You can also find more information about the topics ans performance tuning  here:

R80.x Security Gateway Architecture (Logical Packet Flow) 

R80.x Security Gateway Architecture (Content Inspection) 

Performance Tuning R80.20 Administration Guide

Performance Tuning R80.10 (Part of Check Point Infinity) 

➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips
0 Kudos
HeikoAnkenbrand
Champion Champion
Champion

Danny had also wrote an article about the top 10 config mistakes:

Check Point configuration mistakes - Top 10 

Maybe we can write an article in the Check Point for Beginners section, which describes the typical issues.

➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips
0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events