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).

Classic rulebase enforcement, isn't it obsolete?

In one of my previous posts I have been writing about stateful inspection patent. Just to remind you, it was filed in 1994. Since then, not much has changed.

Traffic inspection principles used by Check Point today are more than 20 years old. Twenty years! Now try to imagine how networks and security have changed during this time.

Granted, there are new principles in networking security: intrusion prevention, application control, AVI, web filtering, you name it.

But all of them are sitting on top of the same logic of policy rulebase enforcement that was originally invented two decades back. Other FW vendors are also sticking to the same principle: rule by rule traffic match till a security decision is being made.

Why is it a problem? Performance.

Repeating full match of IP addresses for source and destination and protocol definitions takes time and effort. It is hard to accept a connection and even harder to drop. (for more details on the "drop" part, watch one of my video nuggets about it).

Firewall vendors have made an effort to improve the situation by offloading simple security decisions to another device, such as acceleration cards or trying to fully utilise the potentials for multi-CPU machines (SecureXL and CoreXL).

And it helped to some extent. Nevertheless, the bare logic of traffic inspection through a rulebase is an issue.

If your traffic is going to be accepted on rule 101, for every new connection FW will still be going through previous hundred rules trying to find a match. Acceleration with templates helps to bend this for similar connections between the same source and destination, but for the very first connection, even with acceleration, one has to read through 100 rules to find the final match.

Can some other logic be applied here to accelerate a new security decision through a firewall policy? The answer is yes.

Stay tuned.

Video Nuggets: Troubleshooting series dilemma

I was about to start working on troubleshooting series as part of Video Nuggets project, and then a thought hit me.

Should I do it now, when R80 is just around the corner?

R80 will bring significant changes in every part of Check Point infrastructure: GUI, management server, gateway. Some fundamental changes are to come, including rulebase match logic.

Do you really need R7x materials today? Would it make sense to do "classic" troubleshooting now and then amend series to cover R80 changes?

Please let me know what you think.

vsx_util downgrade saves the day

I have had rather bad case of VSX upgrade the last night. Jumping from R65.10 to R77.10 led to disaster on one of two clusters. Once the newly installed cluster member is reconfigured, it comes from boot and then freezes to the point both ssh and console sessions are no longer allowing to log in.

Since we were doing two clusters in one shot (never again, I have noted to myself), rolling back to the pre-upgrade MDS backup would mean losing all the progress done on the second successfully upgraded cluster.

Luckily enough, I have managed to do vsx_util downgrade for the faulty cluster only, saving us at least 4 hours of additional work Saturday night.

This option, vsx_util downgrade, is one of the hidden and unsupported features of Check Point. According to my sources, it works fine for most of the cases, but can also backfire badly.

I cannot recommend it to use, but you may want to know it is there, just in case. I hope Check Point made it official one day.

Firewall Basics: the final part

I have published the last nugget in the Firewall Basics series.

On this point we have enough background to start discussing optimisation, troubleshooting and best practices.

Thank you for your interest and for your support.

Who is making 1100 appliances?

In August I was looking into manufacturers of Check Point 61K and 41K chassis and blades.

It is time to look on SMB appliances.

In 2014 Check Point has introduces 600/1100 series that came to replace SofaWare SMB appliances also know as VPN-1 Edge or Safe@Home & Safe@Office.

The whole love-hate story of Check Point and SofaWare is dramatic by itself, with several law suits and final out of court settlement. But I just want to look into hardware here.

There is no doubt that HW for 600 and 1100 series is manufactured in Taiwan by Sercomm.

Here is one of SMB business routers from Sercomm:

You can compare these pictures and specs with Check Point 1100 series. 

Stateful Inspection, who invented it, really?

In my first Check Point video nugget one of the questions is about inventors of Stateful Inspection.

I thought it was a simple one. Surprisingly, I have received some unexpected answers. Most of them were about Nir Zuk being the actual inventor. That made me thinking, what if I myself was mistaken, and the guy actually did that? So I have started researching this.

Here are some results.

I was actually right. Patent rights to Stateful Inspection belong to Check Point and Gil Shwed, according to US patent 5,606,668. The patent application was filed in 1993.

So, what about Nir then?

Well, here it is quite interesting. Nir Zuk does not hesitate crediting himself for developing Stateful Inspection.

Here is the quote from Palo Alto web site: "Nir was... a principal engineer at Check Point Software Technologies, and was one of the developers of stateful inspection technology."

It is very accurate, isn't it? "One of the developers..." Of course he was, he worked with Check Point from 1994 till 1999. He could not possible invent it, considering half a year gap between filing the patent application and his start in Check Point.

Should not confuse us much, right? It must be something else.

In Nir's interview to IT World in April 2010 when talking about his Check Point years he says:  "We invented a technology called stateful inspection, on which all network security technology today is based." This is a bigger statement, but again, if by "we" he means "we, Check Point", there is probably nothing wrong there.

The article itself is peculiar. There he also claims he single-handedly developed Floodgate product in 1999 and then was practically pushed out of the company by Israeli developers for doing so. I will not comment on that, as we are discussing Stateful Inspection topic only.

There is one more article from 2008 published by InformationWeek. The title is very promising: "Who invented the firewall".

Believe it or not, the very first sentence credits Nir Zuk. It says: "Nir Zuk says he developed the technology used in all firewalls today." The article is brilliant, it its own way.

The author, Kelly J. Higgins is apparently not fluent with FW technical terms. I would not blame her much, although her attempt to crack the case does not deserve full marks, in my humble opinion. She quotes one of the experts in the article though, saying: "Zuk was the father of the stateful firewall product at Check Point…"

Funny, Check Point is only mentioned in the article if if referenced to Nir Zuk. Here is another example: "Meanwhile, Zuk, who helped build Check Point's firewall technology, isn't shy about taking credit for the first commercial firewall."

If I would read this without any background, it would be clear to me: Nir does it all. He is the father, developer, inventor and, finally, helper. All praise Nir.

Well, the whole story is a very good example of bold PR (If you have ever seen Palo Alto marketing presentation, you know what I am referring to) and inaccurate journalism.

Nir Zuk was one of the developers, all right. The rest is just noise on the channel.

If you have spotted anything inaccurate this, please let me know. It might be possible (although unlikely) I am still missing some parts of this puzzle.  

Firewall Basics: Part two - the nugget is live

Hi again.

I have just uploaded the second nugget from the Firewall Basics series. Check it out.

The trivia question in this one is a bit trickier. I will be waiting your answers till 11.10.2015.

I have received a lot of requests and suggesting for future series. It will take me some time to address most of them. Thanks a lot for your support, interest and understanding.

I have also received some negative marks on youtube. That is okay, my work is not perfect. But it would help if you could specify what particularly you did not like. This kind of feedback will help me to do a better job the next time.

Thanks and see you soon.

The very first nugget is published

Hi all, I have just uploaded the first nugget: "FW basics: Part one" to my youtube channel.

In FW basics series we are talking about fw principles and fundamental concepts: fw kernel placement, stateful inspection, kernel tables, enforcement principles, components of Check Point security systems.

Once the foundation is set, we will talk about troubleshooting in particular. It does not seem to be feasible to replace in class troubleshooting course by these video fragments, but my goal is to provide clear and simple explanation of the things that would help one to understand Check Point environment better. With such understanding troubleshooting becomes easier and less stressful.

I hope you like the video. Please send me your answers for trivia before the next nugget is published.

Thanks for your comments and support.

Introducing Check Point video nuggets

Hi all!

I have decided to start a new project on Youtube: Check Point Video Nuggets.

I am going to take some bits and pieces out of my custom courses: 

• Troubleshooting, 
• Optimisation and 
• Best Practices, 

and to convert them into short videos explaining different aspects of firewalling with Check Point.

The crude video below is the start.

If you are interested in something particular, if you have any suggestion or want to support the project, please contact me here or via email (in the video).

Thank you for watching. Stay tuned.

High End Check Point appliances, digging further

In my previous post I have asked you about origin of Check Point 61K and 41K chassis. Before continuing this discussion please let me explain why I am digging into this.

The main reason is that Check Point does not provide enough information about the hardware specs of the appliances. Customers apparently should be happy just with security power indicator. Basically Check Point tells us: trust our sizing tool, we will present you with the right box for your throughput and particular combination of your security features.

This does not work 100%, there are always issues with border customer cases, wrongly assessed requirements and missed functionality.

Treating appliances as black boxes does not help to built the trust. How do we know if the box is powerful as announced? With high-end boxes there are even more bottleneck that with regular appliances. Thus more questions.

The second reason is about my personal preferences. As an engineer I like taking things apart to see what is inside. Design and capabilities: these are the points I want to be sure about.

If you seem this too much, it is okay, you can stop reading here and get back to your own toys. If you are with me, I want to share some of the findings.

------- read below this line if you are still interested -------

In the comments of the previous post someone has put a link to ASIS, a company with less than 200 employees, according to its LinkedIn profile. The company has two addresses in Israel and USA. US address apparently belongs to a small sales office.

According to my anonymous reader,  this company is producing the chassis for Check Point. Indeed, their Perform 140 and Perform 60 chassis look very similar to 61K and 41K, without SSM and SGM blades.

Now, what about the blades?

I did not find anything that would look like SGM or SSM on Asis web site.

So far I am assuming Check Point is using Advantech MIC-5333 or MIC-5332 ATCA modules as SGM blades.

Unfortunately, I did not found the Switch modules (SSM) on Advantech site. Advantech only lists a single Switch Module for ATCA, ATCA-9112, which looks a bit different than the switch blades used on 61K or 41K.

Strangely, on marketing photos of Advantech ATCAs that I have already cited in the previous post, switch modules look exactly as Check Point ones, except for the colour, although it is listed as ATCA-9112. Could be that these marketing photos were done with older modification of the blade. So far I continue searching for the definitive proof.

If you have any further information to share, please do so. On my side, I will keep you posted about news for the matter.

Who is making Check Point High End chassis?

The full name of Check Point includes Software Technologies in the title. It hints that Check Point does not produce its own appliances. And who does for that matter?

One question is bothering me for years now: who is making Check Point 61K and 41K chassis? I have never got a straight answer on it from CP itself, not even a hint.

But just for sake of argument, take a look onto Advantech Advanced TCA boxes:

Do they look almost like 61000 and 41000 from Check Point to you?

Granted, it is not 100% match. The smaller chassis even have 41K composition up side down. Could it be that Advantech is producing custom HW for Check Point? Or could it be that Check Point uses just some of the components such as frames and fan blocks, but the blades are done somewhere else?

I wish I know the answer to this.

What do you think? What do you know?

Renaming global objects cause CMA migration to fail

I have recently discovered rather unfortunate situation with Multi-Domain Security Management servers. If you have ever renamed any of the global objects in the global policies, you cannot migrate CMAs anymore.

This sounds strange, but it is the fact. With R77.x cma_migrate script will fail on the target machine if at least one of the global objects was ever renamed.

Check Point has a rather vague SK article about it, and the only proposed solution is to request a hotfix. Mind this article is only referring to R77.10 version, although the issue is present on R77.20 and potentially on R77.30.

It seems cma_migrate is running re-upgrade verifications and fails if gdb_rename table is not empty.

I can only guess if it was done intentionally or not, but there is a history of other issues with renaming global objects on MDSM.

For example, with R75.40 it was impossible to rename a global object, unless a particular system variable was changed (SK82380). One more know issue was about upgrading R76 MDS to R77.10 
(SK98793).

Considering all above, the only recommendation is: do not rename global objects to avoid any of the described issues.

Check Point release map for R7x

In case you ever wanted to have a summary of Check Point recent releases, dependencies, brief "what's new" info and further links, Check Point release map document is what you are looking for. On its 8 pages you will have it all, including links for more details, upgrade maps and backward compatibility maps' links.

Of course, you need a User Center account to download this doc. 

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.