One Management database parameter you never want to change

If you ever pushed Check Point policy, you know there is a verification process preceding compilation and installation stages.

Security Management Server needs to check rulebase and objects integrity before compilation. Sometimes, when you make an error in the rulebase, you will have a verification message about it. Most errors are about shadowing rules and broken rulebase logics.

However, there is a parameter in your Management Database that defines whether or not such verification even takes place. Yes, that's right, you can disable policy verification.

Important note: disabling policy verification is extremely dangerous. It may lead to a severe security breach or to a serious business continuity accident. I sincerely discourage you to change the parameter on any of your production security systems.

So, after the warning, let's take a look. There is a SecureKnowledge article sk31104 explaining the parameter in question. It is called "fw_light_verify". One can only access it through GUIDBEdit tool. I do not want to elaborate how the parameter works, SK article does it perfectly.

One might ask, why does it even exist? The answer is simple: there are some scenarios where controlled use of such parameter actually can help resolving issues. For example, when running vsx_util upgrade in a very complex environment, there can be a very rare case of process being stuck. the reason is that the tool eventually recompiles all VSX related policies on all Security Domains. If some of the policies are too big, and there are too many objects, verification takes too much time and times out, causing upgrade process to fail in the middle. There is an SK article describing this scenario: sk108693.


Final note: I have tried changing the parameter in the lab, and indeed it allows you to install some weird policies, for example, with the first ANY-ANY-DROP rule and more elaborate rules afterwards. I hope you understand the implications here. Never use this in production unless advised by your Check Point support engineer. 


--------------------
To support Check Point Video Nuggets project send your donations to https://www.paypal.me/cpvideonuggets

To support this blog simply subscribe to Indeni tech news via this link.

Using Capsule Docs app on Mac

I am forced to use Check Point Capsule Docs application on my Mac the last couple of days, and to be honest, I do not like it.

User experience with it is below Mac standards. Vertical scrollbar only appears when scrolling and then disappears. Horizontal scrollbar never appears at all. Zoom only works with dual finger gesture on a touchpad. Never even try using your mouse. Zoom is not mentioned in the menu or in any other place in the application.

If you happen to mistype your password or email address, the app caches the credentials anyway and block your access. You can re-login through Preferences menu, but this step is not quite obvious.

However, the most annoying this is about those ugly gray fields on the sides of documents that cannot be removed ever and appear even in the full screen mode.

I have expressed my dislike of Check Point applications for Mac in the past. It is a personal thing, of course, but I want to tell this again:

Check Point Mac apps are below Apple user experience standards.  I wish it was done better. How hard can it be?

Update: Check Point has reacted promptly on this post, see the reply in the comments.


--------------------
To support Check Point Video Nuggets project send your donations to https://www.paypal.me/cpvideonuggets

To support this blog simply subscribe to Indeni tech news via this link.

Central licensing and contracts on 61/41K with VSX

If you are using 61/41 chassis with VSX, make sure you understand caveats and pitfalls when applying central licensing.

Before I explain the issue in hands, let me remind you a couple of facts about the environment.

1. Central license can only be applied from a Management Server, usually with SmartUpdate. You will fail to put it locally on the machine with "cplic..." command
2. 61/41 appliances have multiple SGMs (Security Gateway Modules) running as a single logical GW from MGMT perspective. To do so, you have to configure so-called Security Group and populate it with SGMs.

Now, here is the catch. You can only apply central license successfully from SmartUpdate if there is a single SGM in the security group.

With multiple SGMs in the Security Group SmartCenter will only apply a new license to SMO (Single Management Object) i.e. the first SGM in the Security Group. All other SGMs will fail to get a license.

This does not make any issue if you never change your license. But if you do, prepare to inconsistencies.

The only workaround I have found is to use a local license and apply it on the chassis with CLI commands. Just in case you have a different way, please let me know.

One more thing is to apply contract file. It has to be applied on the GW locally with "cplic contract..." command. The pitfall is you need to distribute the contract file onto all SGMs in the Security Group before running CLI command. To copy files to all SGMs, use asg_cp2blades... command, as described in the admin manual.


--------------------
To support Check Point Video Nuggets project send your donations to https://www.paypal.me/cpvideonuggets

To support this blog simply subscribe to Indeni tech news via this link.

R80 is not expected to make a dent, business analysts say

Cleveland Research Company (CRC) released a new security market research. The report is not available publicly but can be purchased at CRC web site.

R80 is mentioned there several times. In a nutshell, business research analysts are not impressed with R80 capabilities and do not expect a significant difference on Check Point market status after its being released.

Here are several quotes.

R80 not expected to be catalyst until 2017
R80 should be neutral or slightly positive for growth, if it is positive, great.

It seems Check Point should be more active and self explaining in highlighting the novelties and advantages of R80.


--------------------
To support Check Point Video Nuggets project send your donations to https://www.paypal.me/cpvideonuggets

To support this blog simply subscribe to Indeni tech news via this link.

R80 is announced. What does it mean?

Check Point has issued a press release yesterday saying R80 "will be available this March". What does it mean, really?

Here are some questions and answers for the matter.

Q. Is it on time?
A. R80 is expected to be out since 2014. at CPX 2013 the company was mentioning a new version to be released after R77. Check Point delayed R80 for at least a couple of years.

Q. Why it is delayed?
A. R80 introduces completely new infrastructure of Check Point firewalls and management. It requires huge amount of work and testing to ensure flawless transition from previous versions. This work cannot be rushed. Quality and stability of security systems cannot be compromised. The company is apparently taking as much time as required to make sure the product is good, before releasing it publicly.

Q. What is in the release?
A. The announcement is talking about new management only. Corresponding gateway part is expected later this year as R80.10 release (allegedly)

Q. What is new in this release?
A. Management infrastructure and administrative tools are completely re-built. Expect quite different user experience with the new single SmartConsole application. Management architecture is now using an actual database, not a set of text files, as before. It is no longer limited for a single administrative session even within one SmartCenter. Multiple administrators will be able to make parallel changes.

Q. What are the expectations concerning R80 gateway release?
A. It is not clear at this point. CPX demos hint that R80 gateway will allow a new form of policy enforcement, so-called Unified Policy, where security administrators will be able to enforce not just traffic filtering, but also other security blade policies by creating rules sub-rules with different security settings.

Q. Why MGMT and GW parts are not released together, as usual?
A. These kind of revolutionary approach to firewalling requires substantial change of GW architecture and even more tests and validation that MGMT part. Hence the separation.

Q. Why Check Point changes architecture needs to be changed in the first place.
A. Latest rapid changes in security and threats landscapes require different architecture to deal with both performance and functionality changes. It is only natural to go for a new architecture to address both challenges.

Q. Should I upgrade to R80 management right after it is publicly available?
A. This is not a simple "yes" or "no" question. In general, some caution is advised when upgrading to a new release. You need to see if it has something valuable for you and then assess the risks. Lab tests and trials are must when moving between the main releases. Run R80 in the lab first, then decide.

Q. I am working with Check Point products for years. Is my experience still relevant for R80?
A. As already mentioned above, R80 introduces new experience and new architecture. Some learning curve is expected, but it should not be absolutely alien to any person working with other Check point products. It still has intuitive user interface, just different from what you are used to today.

Q. What should I do to prepare for R80 release for myself and my company? How can I learn the product?
A. Firstly, get on public EA and run it in the lab before it is released. Read documentation (yes, it is still mandatory). If you need any additional help, just know there should be new set of CCSA/CCSE courses for R80 later this year. I also hope there will be some books written about R80.


-------
To support Check Point Video Nuggets project send your donations to https://www.paypal.me/cpvideonuggets

To support this blog simply subscribe to Indeni tech news via this link.

VSX deployment on High-End chassis. Part 3. Changing chassis ID

This is the third and last part of the topic started in the couple of previous posts.

When deploying 61/41K chassis as a cluster, you get a pair of devices marked as Chassis 1 and Chassis 2. The numbers are not just voluntary marks. They are used to generate and sustain quite complex system of internal addressing and communications: provisioning, sync, clustering, Security Groups management, and so on.

There are multiple SKs describing different architectural aspects of the system and its internal addressing.

By default, chassis 1 is active, and chassis 2 is standby. Although you can change that, it is custom to keep chassis #1 in the main Data Center, while putting #2 to your secondary one. But what if the logistics people made a mistake, and the chassis were swapped, leaving you with chassis 1 in the secondary Data Center?

The solution is standard, you just need to change the chassis ID numbering. The appropriate procedure is described in the Admin Guide (page 181 for R76.30SP version of the document). If you catch the error soon enough and if there is no security setup on the chassis yet, the procedure works like a charm.

However if you already have VSX deployed and provisioned, the story is not so simple anymore. The mentioned Admin Guide omits something quite important: unique role of SMO in a Security Group.

I have described this role in my first post for the matter. In combination with the internal addressing as function of the chassis IDs, the process becomes a bit peculiar.

Chassis ID change requires "hacking" into CMM config files and changing ID parameter on both ends. Chassis ID is used to form internal addressing. Each element of the chassis has a unique IP address based on it logical position and chassis ID. So you have to disconnect the chassis to cease intercommunication for a while, change ID numbers, rebooting each and every blade in the system and reconnecting the environment.

The catch is about Security Group addressing. As mentioned, the very first SGM added to the group becomes SMO. Other SGMs use SMO internal IP address to pull the config from it.

The main issue with changing chassis ID while having Security Group with non-default settings is about SMO swapping the place. Indeed, when addressed by IP, SMO is changing logical place from one physical chassis to another one, after ID change. In a particular scenario when you start the new chassis 1 first, its first SMO after the first boot tries to pull SMO config and fails. The reason of the failure is about that SGM trying to access another one by an IP address that belongs to itself after the change.

As the result, all other SGMs are also failing to pull config os Security Group, leading to total collapse of the chassis clustering. If you already have some traffic running through your system, that is inacceptable.

To avoid such situation, there are some actions to be done:

1. Mind chassis ID from the beginning of deployment. It is quite easy to change IDs if nothing is configured yet.
2. If you have Security Group and/or VSX setup on the system, plan for some downtime. The solution is to dissolve a Security Group and reconfigure it after the ID change. 

Good luck with your 61/41K system. The solution is actually quite nice, although complex.


-------
To support this blog and Check Point Video Nuggets project send your donations to https://www.paypal.me/cpvideonuggets

VSX deployment on High-End chassis. Part 2. Control connections and VSX provisioning

In my previous post I have explained why one needs just a single SGM in the Security Group while defining VSX object.

The second pitfall is about control connections during provisioning. When converting GW to VSX, management server pushes an automatically compiled policy to the GW before and after conversion. Users have some limited options to add to that policy, mostly about HTTPS, SSH and SNMP connectivity to the gateway. Control connections are not explicitly mentioned.

It is assumed that control connections are allowed by Global Policy settings in the implied rules. On the field this assumption does not really work. If a customer disabled control connections, the auto-generated VSX policy will cut of provisioning after the first push.

It would be very unwise to try unloading policy on the gateway. In this case it will be converted to VSX, rebooted, and then the same auto-compiled policy will be pushed again, cutting VSX GW out of MGMT server the second time, now for good.

In any case you will be stuck in the middle of provisioning, with VSX object created on the MGMT side, with SGM side provisioning either not started or only partially completed.

If that would be R77 VSX environment, you should be able to run reset_gw command, described in SK101690. Unfortunately, 61/41K VSX deployment is using R76.x0 SP versions, where this command is not available.

In this particular situation you will have to re-image your SMO SGM again. If so, do not forget to reapply Jumbo hotfix package after installing the main version.

So, the bottomline here is: before starting VSX provisioning in general, and especially when dealing with 61/41K chassis, make sure you re-enable, even temporarily, control connections, before starting VSX object creation.

I can only imagine why Check Point assumes that control connections are always enabled by default, especially in case of complex security systems where it is mostly not the case. I hope in the future releases Check Point will be able to take this issue into consideration and will at least add a warning to VSX wizard or, better, allow administrators to modify default VSX object policy to some extend.

Some additional info about 41/61K deployment to follow.



-------
To support this blog and Check Point Video Nuggets project send your donations to https://www.paypal.me/cpvideonuggets