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:
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.
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.
