Check Point announces End of Sales for IP Appliances

Check Point will discontinue sales of the remaining IP appliances by the end of year 2013. That concludes the long and somewhat dramatic history of Nokia Security Appliances Business which was sold to Check Point almost 5 years ago.

Check Point customers may finally concentrate on a single appliance line, with GAIA as the main choice of OS.

With all its ups and downs, IPSO was quite interesting OS. For starters, it is based on BSD kernel while SPLAT and GAIA are based on RH Linux. In my personal opinion, GAIA still has some distance to cover before being as good as IPSO in terms of stability and features.

Anyhow, yet another page of network security history is about to be closed.

VSX provisioning bypass actually works on R75.40VS

In my previous post I have said VSX bypass debug commands do not work. I was wrong.
The trick works perfectly on R75.40VS Management, both SmartCenter and MDM.

Nevertheless, the weird part is that it only works if one types the commands manually and not by copy / paste. I guess it was only about some weird corruption when pasted from the buffer.

I am sorry for being wrong before and for all time spent on this topic by David Bar, Shahar Solomon, Eran Ashkenazi and other Check Point engineers. I appreciate the assistance.

VSX provisioning bypass trick does not seem to work on R75.40VS MGMT

WRONG, THIS WORKS. PLEASE SEE MY NEXT POST

I am doing lab trials for all kind of management and enforcement side upgrades for my customers, especially for ones usen VSX and MDM. As part of the MGMT sanity checklist, there are VSX provisioning checks to be sure there is no corruption of VSX objects and topology scripts.

Before R75.40VS there was a way to bypass actual connections to VSX clusters in case you are checking MGMT side only.

To do so, once would put the following set of debug commands in the Main CMA context on MDS machine:

fw debug fwm on TDERROR_ALL_VSXM_DBG_SKIP_PING=INFO 
fw debug fwm on TDERROR_ALL_VSXM_DBG_SKIP_INSTALL=INFO
fw debug fwm on TDERROR_ALL_VSXM_DBG_SKIP_PULL_SIC=INFO 


Once done, you could simulate topology changes for Virtual Systems to be sure scripts are properly handled. MGMT would generate a script without trying to connect to VSX cluster members and/or executing it on VSX cluster members.

Well, not anymore. With R75.40VS this trick is no longer working. It is even more interesting, just because it seems Check Point specialists are not aware of that. I have asked around and even opened a support call to get an answer.

I will keep you posted about the outcome.

R70 is out of support, VSX R65 is about to

I am not sure if you follow Check Point support lifetime details, but there are two things you need to know:

1. R70 versions are out of support from March 2013
2. VSX R65 will be out of support in May 2013

Take care and plan your upgrades as soon as you can. There is a hint for those who cannot do this in time: Check Point can extend support for half a year by request. Call you local contacts, it is not yet too late.

Removing traces of old versions - new scripts from Check Point

The most annoying disadvantage of upgrade in place is about having old traces in the file system. Basically, each upgrade leaves old product directories, so with every step you have less and less disk space available.

Removing old files manually is not exactly safe, so many prefer advanced upgrade.

The good news is it is no longer the best option. Check Point has two scripts, for MDM and for regular installations, that should clean your system after the upgrade.

Refer to SK91060 for regular systems and to SK65330 for MDM systems. According to the SK, the latter script is already integrated into R75.50 and R76 MDM installation packages.

With these tools one can upgrade in place and still have optimal disk space available quite close to a clean installation.

Finally, Check Point!

Could not push policy from R75.40VS to R67.10 VSX

A customer of mine could not install policy to a Virtual System on R76.10 VSX cluster after upgrading MDM servers to R75.40VS.

Policy verification was failing with multiple errors (some data removed):

INTERNAL ERROR in execval: optimization disabled: displacement too large
INTERNAL ERROR in execval: optimization disabled: displacement too large
ERROR: Table or domain are not allowed here
ERROR: table '<'quota_table'>' has no predefined format
ERROR: table '<'quota_table'>' has no predefined format
Compilation failed.
Operation ended with errors.

The messages look quite scary, but no worries.  The key here is quota_table.

In fact it is an old error from 2007, related to Network Quota being enabled in IPS profile. Disabling Network Quota fixes the issue. Check Point has SK32549 for that.

Although it is something known for long, I am wondering why it has been surfaced only after MGMT part being upgraded. 

Please let me know if you encountered this issue as well.

Check Point Security Report 2013 reveals scary picture

If you did not look into 2013 Security report done by Check Point, it is probably a good time to do so.
The document reveals quite disturbing figures: above 60% of networks are infected with bots. About the same amount of "protected" networks is open for P2P. More than half of organisations have DLP accidents. And so far, and so on.