VSX deployment on High-End chassis. Part 1. SMO and VSX provisioning

After being exposed to a couple of VSX deployments with 41000 chassis, I have to share with you some important points.

Deployment of 61000 or 41000 based firewalls is quite different from the regular Gaia appliances. The CPU blades called SGMs (Security Gateway Module) are acting as a single gateway. They load-share the traffic, they have a single GW configuration, including topology, IP addresses and even SIC. To achieve that, you need that, you need to define so-called Security Group and populate it with SGM blades. The first SGM added to the group becomes SMO - Single Management Object. It will perform SIC communications with Management and will maintain later on control connections on behalf of the Security Group. If it fails, another SGM takes over the function of SMO, maintaining logical GW functionality intact. It will take me just a moment to explain, why mentioning SMO is so important while talking about.

If you are deploying 61/41K as a regular GW without virtualization, there are virtually no pitfalls. That is not exactly the case with VSX.

The main VSX object provisioning can only be properly done if you have just a single SGM in the Security Group. Although this requirement is mentioned in the Administration guide, you can easily miss it. It is also not clear at the first sight, why this is so important.

If you ever deployed VSX on a regular appliance or or an open server with R75 and up, the process is quite complex. MGMT server pushes a provisioning scripts to the GW just after establishing SIC, forcing GW machine to reboot and come up as VSX GW.

The situation with 61/41K is not different, except that on those chassis it is a group of SGMs. Each SGM is in fact a Gaia machine.

So imagine we have a couple of SGMs in the security group before starting VSX provisioning. It is only SMO talking to your management server and then rebooting after establishing SIC. The second SGM blade will not do so, but will assume a role of SMO, considering the first blade in fault. The last known configuration pulled from the original SMO does not have any mentioning of VSX. On this point the provisioning will fail.

There are also some other potential issues with VSX provisioning. I will address them in a separate post.


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

Next phase of Check Point Video Nuggets series needs your support

Hi all!

You may have seen already the first series of videos in the Check Point Video Nuggets series. Up to date these short videos were viewed almost more than 2200 times.

I received lots and lots of your emails with praise, criticism, suggestions and questions. That you all very much for your support.

In some of your emails you have asked about the promised Troubleshooting series. I am still planning to do those, but it is clear I cannot produce them at the same pace as before. They require much more work and preparations.

For the previous nuggets it was taking me about three days to compile 3 minute video. It will take even more for troubleshooting, as the material is more advanced and requires lots of preparations.

I am also not exactly happy with the quality of the video materials I am able to produce today. I am learning on the way, but it is not only lack of skills. It is also about tools.

I need better mikes and sound processor, a decent 4K camera, good video editing software and lots of disk space for storage of the materials. Some of that I have purchased already, but that is not enough.

My budget estimation for the tools as around $5000. It is materials only, my efforts are still free of charge. I was trying to find an interested partner who would support the project financially, but it did not work out, and least not yet. I have even considered starting a crowd financing project on one of the well-known sites that would allow funds to be released even if the goal was not achieved.

Any kind of support, although minimum, will help the cause. If you like the series and want to see continuation, please consider donating via Paypal.me:

https://www.paypal.me/cpvideonuggets

UPDATE: some people tell me that paypal.me is not available in some countries. If this is the case for you and you still want to make a donation, please use regular paypal money transfer with the following email: cpvideonuggets(at)gmail.com

Thanks a lot,
yours truly...

Check Point promises an interesting year

I have just returned from Check Point Sales Kick-Off event in Barcelona. Although most of the news we have heard there will be public later on, one thing is clear: year 2016 will be quite exciting for Check Point partners and customers.

Some big things are just around the corner, and R80 is only one of them. New mobile security solution is fantastic. Software-defined-anything is moving forward quite fast. Security policy logics are about to change. More products and solutions, more power.

I also expect lots of work around learning new tools and products. Check Point is working on new CCSA for R80, and more advanced courses are to follow later.

If you want to catch the wave, do not hesitate to sign into R80 public EA. More feedback we could provide to Check Point better will be the product.

CP vs PAN: mud fight

In case you have missed that, there is an ongoing mud fight on LinkedIn between celebrated Check Point and Palo Alto guys.

It all started from a video on YouTube called "666 ways to bypass Palo Alto Networks in 6 minutes". Video's author's pseudonym is "netsecvulns". It is unclear if the author is related to Check Point in any way.

The video is no longer available, but around three weeks ago it was referenced by Kellman Meghu, the author of Kill-HUP blog, in his now very popular LinkedIn post.

The video was about multiple successful evasion techniques being demonstrated through PAN FW with a basic security policy in place. The idea itself is quite old and was mentioned by SANS three years ago and later by NSS.

At once several PAN sales engineers jumped into the ring to fight it back. Check Point is misleading customers, they said. PAN device was not configured properly, they said. Show us the same test for Check Point, they asked.

Kellman obliged and provided an old video by Moti Sagey demonstrating Evader tool being unable to pass Check Point IPS with "any-any-accept" rule. The funniest part is that video was posted more than half a year ago, way before "666 ways..."

Since three weeks Kellman's post has more than 130 comments. PAN guys were unable to provide any technical counter-argument.

According to them, market knows best. I guess they are referring to growth factor of PAN, because in absolute figures Check Point is still way ahead.

I am not sure when the argument stops and some real work begins. In his latest open letter to PAN Moti Sagey mentions PAN is actually trying to make an effort to fix the issue in hands.

In that post Moti also writes: "I contacted “netsecvulns,” who understands the seriousness of this vulnerability and how it can easily be exploited.  NetsecVulns, showing professional courtesy to Palo Alto Networks and in the responsible interest of the security of PAN clientele , has make the video private until January 11th."

I guess we need to wait two more weeks to see how this fascinating story ends.

Check Point distributive License file is still referring to SecurePlatform

As you may know, some of Check Point code is subject of  GPL and LGPL agreements. While trying to figure out which particular part arethose, I have found that the actual license file is still referring to SecurePlatform and not Gaia.

See for yourself, quoted form the License.txt file at the root of R77.30 installation image:

"For portions of SecurePlatform that are covered by open licenses, such as
the GNU General Public License or GNU Lesser General Public License, the 
source code is available upon request.  Requests for source code can be sent 
via email to gpl-source@checkpoint.com."

All other Gaia distributes, R80 public EA included, have the same issue.

2200 appliance: what is "factory defaults" hole for?

If you have ever seen the 2200 box, it has a small hole on the right from side marked "factory defaults".

What is interesting, it does not work. It should not, in fact. If you open the manual, the only available available options to revert to a default configuration are about Gaia tools: CLI or WebUI.

The hole is not mentioned in the manual once, and not even elaborated in the pictures there.

There is a button behind the switch, and it can be pressed with a paper clip. It clicks, it does not make any difference.

Considering Check Point uses its own color scheme on the generic appliance. So I am wondering, if the reset hole is not working, why not removing the inscription?

If you know an answer, please share.

R80 is about to be released, kinda...

Just to remind you, Check Point has announced R80 back in 2014. Two years after, the new revolutionary version is not yet out.

Nevertheless there are signs that it is quite close to a release. Check Point has announced a controlled access R80 Early Availability program for management server only.

According to some sources, Check Point is planning to release management version of R80 separately and then later compliment it with R80 enforcement release.

The program seems to be available for Check Point partners only. You may try to get access to it via this direct link (prepare your UC credentials in advance).