Client Authentication on VSX with SSL support

If you ever want to enable Client Authentication on VSX with SSL support, here are some tips for you.

First, read carefully SK37001 and How-To-Install-3rd-party-SSL-Certificate.pdf document from Check Point support site.

You will have to modify cpauthd.conf in order to enable SSL-based client authentication. Mind in VSX environment you can do it either globally (for all Virtual System at once) or per VS. The last on is the recommended way. The file is located in $FWDIR/CTX/CTX00xxx/conf/ folder, where xxx is VS ID.

Change file configuration as marked in underlined bold bellow:
---

        :clauth_port (259) 
    :clauth_http_port (443)       << change listening port 
    :clauth_http_ssl (1)          << enable SSL 
    :clauth_http_wap (0) 
    :clauth_http_nickname (Your certificate Nickname) << put third party certificate
        

---
Mind you will have to prepare a third party certificate to use. Some CAs, such as Verisign do not accept default Check Point CSR. You will have to increase the key size to at least 2048. To do that go to Global properties / SmartDashboard Customization / Advanced Configuration and change host_certs_key_size parameter to the required number.

Do not forget to install the certificate on VS as described in "How to" document.

All mentioned changes will be in effect after reboot of your VSX boxes.

Software Blade training sessions in my ATC

I am happy to announce that Check Point is providing two training session in Dimension Data's ATC in Lausanne: 13.02 to 15.02 and 15.02 to 17.02.


Quoting the official Check Point announce:


Training is delivered using our new, cutting-edge Training Blades and includes:

• In-depth study of Check Point Application Control, Identity Awareness, URL Filtering, DLP and IPS Software Blades
• Hands-on lab exercises based on real life scenarios and support cases
• Exams that extend your Check Point certification by another year

You are welcome to attend, it is only $200 for two and a half days of training and exams!

Some aspects of HHTPS inspection

There is a nice review of different SSL inspection aspects and (potentially) issues made my Kishin Fatnani over here.

Take a look, it is quite interesting.

Found through LinkedIn

upgrade_export fails if MGMT interface is down

Just a short note.

I have come across a weird issue. When you are trying to export your Management server configuration with migrate export (or upgrade_export, if you like doing it old fashion way), you have to make sure your machine is actually on the network. Trying to do this when it is disconnected will lead to the script failure.

I do not remember this kind of issue when working with R65, but it is definitely a case with R7X. Corresponding SK is sk63126.


Error message to look in the migrate log: Failed to get machine's IP address

Appliance Selection Tool never made it out of Beta?

Remember Appliance Selection tool, guys?

It was announced Beta in September, and then disappeared. The link is dead now. The idea was to let you size appliances according to your traffic requirements. It was quite interesting when it was announced. When coming out as Beta, it looked good, at least beta good. And it was promised to be officially released in Q4 2011.

There are some traces of it on Check Point site. For example, it is mentioned in Security Power description. But nothing is out yet.

Too bad, my sales would love it. I would love it.

Would you?

Gartner puts Check Point to Leaders' quadrant in 2011

Gartner has positioned Check Point in the Leader’s quadrant in the Enterprise Network Firewalls Magic Quadrant. Check Point gets the highest ability to execute mark way ahead of the other vendors.

Only two companies, Palo Alto and Check Point, made the Leaders' quadrant this year. Most of the competitors are now in Challengers' area.

Palo Alto, according to Gartner, still has the best technology vision. Nevertheless it is bellow Check Point, Fortinet, Ciso and Juniper when it comes to ability to execute.

Based on CHKP press release.

Enforcing PC identity with Endpoint Connect client

One of the common challenges one can face concerning Remote Access VPN is necessity to enforce identity of end point client.  In other words, sometimes it is necessary to deny VPN access from non-corporate PCs.

It comes naturally if Microsoft Remote Access is in use, because there you could check the machine certificate. With Check Point clients, such as SecureClient or Endpoint Connect that is not so straight forward. Although you can make thorough compliance checks with SCV scripts, you cannot use machine certificates directly.

Of course, there is a way to create a script or a binary that would check certificate and report to SCV, but this is a complex task.

There is a simpler way to work the machine identity through SCV process. RegMonitor is part of SCV functionality. It allows you checking various parameter in the registry for existence and values. So if we could find a unique key entry or a string value in registry, then SVC would be able to decide whether an endpoint machine is part of the corporate domain or not.

If you look onto "Software\Microsoft\Windows\CurrentVersion\Group Policy\GroupMembership" entries in Windows Registry, you will see a number of groups defined for users. Each one of them has a unique SID. At least one group is common for all domain users. It means at least one of the group SID entries will be the same through the domain. Spoofing this entry is possible, but also not easy, as it can make non-domain PC unusable after default group SID changed.

SID group entries are also version independent. They will be the same for all domain users from XP to Windows 7.

A simple SVC RegMonitor script would give you a fair indication of an endpoint being a managed PC. It will work on both SecureClient and Enpoint Connect client.

This way is not ideal, but quite a good one, in my humble opinion.