Friday, May 29, 2015

Availability issue with Identity Awareness portal open to Internet

A customer of mine was experiencing intermittent availability issues with an Identity Awareness authentication web portal some time ago.

Troubleshooting revealed that the portal was accessible from Internet (by design, it is for external users), and it was going down if someone was running some sort of a vulnerability scan agains it. Eventually the attacker was exhausting all available SSL session on the portal, and legitimate users were unable to authenticate. In the regular IA logs one could see lots of redirection entries and just a few login attempts.

Check Point has a SecureKnowledge article describing similar symptoms: SK85040. Unfortunately this solution is not applicable to the described case for several reasons reasons:

  • - IA and not UserCheck was affected (the solution is vague on this subject, but the actual shown commands are for UC case and could not be applied to AI one)
  • - SW versions in the solution are two old
  • - It is only related to physical environment, and in my case the problem was on VSX with a couple of Virtual Systems with AI enabled.

The main idea here is that, according to the solution, SSL sessions are two long in case of the attack, and an attacher eventually uses all capacity of httpd daemon serving the portal. Thus no legitimate connections can be made anymore. In addition, the mentioned solution proposed to increase amount of HTTPS server instances allowed to run.

The challenge was to find appropriate configuration files and to make relevant changes.

Check Point multiportal runs multiple web server processes for each of the features: Identity Awareness, UserCheck, DLP, etc. The actual internal architecture terms are a bit confusing. If it is Identity Awareness that is in trouble, multiportal tool (mpclient) refers to it as nac.

While researching the issue, I have found that configuration files that would have to be edited are located in /opt/CPNacPortal/CTX/CTX000YY/conf/, where YY is the VSID of the particular Virtual System.

The mentioned SK is talking about changing httpd.conf and php.ini files. As I have said, the solution is outdated. In R77 there are several *.conf files: httpd.conf and httpd_nac.conf. The latter is one that should be changed, but apparently Check Point has done that already: amount of server instances defined there is even higher than one mentioned in the SK article.

So the only thing to do was to change php.ini file to decrease longevity of SSL sessions through the portal.

Once it is done, one has to restart the portal web server. To do so, one has to be in the VS environment and to use mcplient tool:

vsenv YY
mpclient stop nac
mplient start nac

If you are going to do so, make sure you save the original version of your php.ini file aside, just in case.

Thursday, May 28, 2015

CPX 2015 presentations are now available

Check Point has posted some of the latest CPX presentation on the UserCenter portal. The materials are obviously incomplete: road map and some key sessions are kept in secret. And of course, to access the list of materials, you have to have a UserCenter account.

Some of materials are quite valuable, such as R80 overview or the set "Future of..." slides for Threat Prevention, Capsule and Forensics

Among sponsors presentations I have found something interesting: Indeni. Indeni were not present in Europe but were among US list of sponsors. I have posted about this company in the past. They are having a unique position on the market, as no other vendor is taking preventive monitoring seriously.

Although Indeni's CPX booklet is interesting by itself, I would advise you to get to Indeni web site and register there for the updates, in case you want to see how they approach health checks of security and networking devices made by Cisco, Check Point, PAN, F5 and others.

By the way, Indeni was paying for CPUG member's beers both in Amsterdam and Washington this year. They are the cool guys.