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.