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.