Check Point support plans - quick guide

One of the most challenging things about Check Point is not about technical issues. It is about understanding support processes, getting the right attention and choosing the right support program for one's cause.

I have compiled a short guide to help you in understanding and navigating the support plans and SLAs. Unfortunately this guide is cannot be put into a blog post. Nevertheless you are welcome to read it on my google drive. Here it is.

If any question, comment or correction, do not hesitate to comment down below.

Indeni calls for technical authors with expertise in Check Point, F5 and PAN

Indeni never stops to amaze me, guys.

They always do something nobody though about. First, in-depth preemptive monitoring of your critical security and networking infrastructure. I was covering this in some of my previous posts, if you remember.

Now it is something else, simple and yet amazing. Here we go:

Indeni will pay you for technical articles about Check Point, F5 and Palo Alto.

Yes that's right, you can write and article and get paid up to $200 per piece. That is no joke, just go by this link and see for yourself.

I wonder if I should just repost most of my blog there. Okay, that part was a joke :-)

Now seriously, if you have something to tell the community, today you also have an opportunity to make some money out of it.

Anyhow, if you are just curious about the company itself and about what they are up to, feel free to sign up for updates and news any time by this link.

And good luck with your new technical writing careers.

Curious story of VSX Management bundle

Once upon a time there was something called VSX Management Bundle for multi-domain management servers.

Licenses with SKU like CPPR-VSX-CMA-CX were allowing people to manage X Virtual System on any kind of Provider-1. The beauty of these license was all about flexibility. It only defines how many VSs one could manage. It does not limit you to particular number of Management Security Domains (CMAs in old terms) and/or number of security gateways per domain, as long as you only manage Virtual Systems and not physical firewalls.

Even more interesting, this bundle was able to extend the original amount of CMAs in the container with Provider-1 NGX licenses.

Let be me more specific. Say, you have MDS with a container for 10 CMAs. Normally, with physical GWs you would not be able run more than 10 CMAs. But after adding CPPR-VSX-CMA-C25 licenses to MDS one could spin out up to 25 CMAs for VSX management. It was also possible to manage multiple VSs from the same CMA. The only thing that mattered was the total amount of managed Virtual Systems and nothing else.

This is all history now. If you look into Software Blades price list, there is still something there called VSX Domain Blade: CPSB-DMNVSX. It allows you to run a CMA that could manage a single Virtual System.

At first glance, this sounds quite similar to the old NGX bundle model. Now you just need to purchase a bunch of VSX blades to run as many VSs as you want.

Well, not exactly. The main limitation for the new VSX blade is that it allows your Domain Management Server to manage just a single Virtual System. Just one. And it is not additive. You could not add two of those blades to the same CMA to manage a couple of VSs.

So if you want two or more VSs in the same domain, You have to jump to 10 GWs domain (CPSB-DMN1000). Why 10? Because as Check Point counts as GWs physical nodes, with 2 Virtual Systems in a cluster your count spikes to 4 GWs to manage.

CPSB-DMN1000 is 5 times more expensive than CPSB-DMNVSX.

I do miss NGX VSX management bundle. It is a great blow that flexible and inexpensive bundles are no longer available.

Categories for Check Point URL filtering

If you are planning to start working with Application Control and URL Filtering functionality on Check Point firewalls, one of the main challenges is architect the organisational policy. You need to know what are the categories you can use and understand what they mean.

In other words, you need the list of categories and explanation for it. Surprisingly, on the product page for URL filtering there is no such link. No worries, it is still available here.

First quarter results: Check Point growth is still slow

Cleveland Research has released financial analysis for the main security vendors, following reported Q1 results.

There is also prognosis for the rest of 2015, see in the table below.

Revs ($000s)	2013	2014	1Q15
Checkpoint	$1,394	$1,496	$373
Y/Y	3.80%	7.30%	9.00%
Palo Alto*	$483	$739	$234
Y/Y	49.20%	53.00%	55.30%
Fireeye	$162	$425	$125
Y/Y	93.90%	163.40%	69.50%
Fortinet	$615	$770	212.9
Y/Y	15.30%	25.20%	26.10%
Juniper	$564	$464	$93
Y/Y	-16.20%	-17.80%	-30.80%

*PANW report one month off calendar Q

As you can see, Check Point market share remains the largest among the FW vendors, with the slowest growth.

Interestingly, Check Point maintains the highest gross and operating margins (87.7% and 58.7% respectively). In comparison, Fortinet's margings are 70.7% and 16.4%, Juniper's are 61.3% and 21.9%. Gross margin for FireEye is 62.7%, operation margin is unknown.

Some could say, Check Point "high price, low cost" policy works out for its margins just fine but does not help its market to grow faster.

Latest Chrome versions breaks SNX, workaround available

Google has dropped support for Netscape Plug-in API in the latest versions of Crome browser. In case you are using Java-based SNX as part of your SSL VPN, and Chrome is the default browser, SNX will no longer work for you.

As a workaround, you have to re-enable NPAPI in the browser. More details are available in SK106021.

It is unclear if Check Point has any plans to change SNX to resolve this issue completely in the future releases.

Availability issue with Identity Awareness portal open to Internet

A customer of mine was experiencing intermittent availability issues with an Identity Awareness authentication web portal some time ago.

Troubleshooting revealed that the portal was accessible from Internet (by design, it is for external users), and it was going down if someone was running some sort of a vulnerability scan agains it. Eventually the attacker was exhausting all available SSL session on the portal, and legitimate users were unable to authenticate. In the regular IA logs one could see lots of redirection entries and just a few login attempts.

Check Point has a SecureKnowledge article describing similar symptoms: SK85040. Unfortunately this solution is not applicable to the described case for several reasons reasons:

• - IA and not UserCheck was affected (the solution is vague on this subject, but the actual shown commands are for UC case and could not be applied to AI one)
• - SW versions in the solution are two old
• - It is only related to physical environment, and in my case the problem was on VSX with a couple of Virtual Systems with AI enabled.

The main idea here is that, according to the solution, SSL sessions are two long in case of the attack, and an attacher eventually uses all capacity of httpd daemon serving the portal. Thus no legitimate connections can be made anymore. In addition, the mentioned solution proposed to increase amount of HTTPS server instances allowed to run.

The challenge was to find appropriate configuration files and to make relevant changes.

Check Point multiportal runs multiple web server processes for each of the features: Identity Awareness, UserCheck, DLP, etc. The actual internal architecture terms are a bit confusing. If it is Identity Awareness that is in trouble, multiportal tool (mpclient) refers to it as nac.

While researching the issue, I have found that configuration files that would have to be edited are located in /opt/CPNacPortal/CTX/CTX000YY/conf/, where YY is the VSID of the particular Virtual System.

The mentioned SK is talking about changing httpd.conf and php.ini files. As I have said, the solution is outdated. In R77 there are several *.conf files: httpd.conf and httpd_nac.conf. The latter is one that should be changed, but apparently Check Point has done that already: amount of server instances defined there is even higher than one mentioned in the SK article.

So the only thing to do was to change php.ini file to decrease longevity of SSL sessions through the portal.

Once it is done, one has to restart the portal web server. To do so, one has to be in the VS environment and to use mcplient tool:

vsenv YY
mpclient stop nac
mplient start nac

If you are going to do so, make sure you save the original version of your php.ini file aside, just in case.