Create a Post
Showing results for 
Search instead for 
Did you mean: 

HowTo: React on Check Point Information Disclosure

Every now and then auditors reviewing and penetrating Check Point firewalls are often criticizing a http web portal being accessible on tcp-port 18264 of the firewall's external interface providing a so called Internal_CA for download.
Don't be fooled, this is not the Internal CA Management Tool, which runs on tcp-port 18265 on your SmartCenter once you enabled it. See:

What's it then?

Your Check Point Firewall just allows obtaining CRLs via an HTTP request on ICA port 18264/tcp.
See: sk32682, sk99076

Check Point writes:

Is this a vulnerability? No. All CAs have to do this.
This is a security feature, not a security problem. Without publishing the CRL, you lose security.

Auditors also like to criticize port 264 TCP being open disclosing the firewall's hostname and ICA name.

This can simply be verified on your own with the one-liner below (replace x.x.x.x with the IP of your Check Point).

printf '\x51\x00\x00\x00\x00\x00\x00\x21\x00\x00\x00\x0bsecuremote\x00' | nc -q 1 x.x.x.x 264 | grep -a CN | cut -c 2-

Check Point considers this public information (sk69360).

Also read this interesting thread about the hostname disclosure.

You can still improve security!

Option 1: Exclude FW1_ica_services on port 18264 (sk35292) from the implied rules and explicitly define a rule allowing access to this port from specific IP addresses. This only works if RemoteAccess VPN users don't connect from dynamic IPs.

Option 2: Detect and prevent port scans via IPS and/or SmartEvent.

Option 3: Block known scanners, such as, and others. Check Point has an IPS protection for this.

4 Replies

Hi Danny,

This is great information. Recently we have faced this issue for one of our client.

In Pen test, it was flagged with issue 18265 port ICA services.

0 Kudos

Great post. not sure if this is the correct area but I have a tricky question from our PCI DSS ASV process. They now have to check against OWASP and have detected 2 security misconfiguration items on our CP firewall running R77.30

1) This application does not enable X-XSS-Protection - X-XSS-Protection header missing on :18264

2) This application does not set X-Content-Type-Options - X-Content-Type-Options header missing on :18264

They say the JavaScript on this port is very 'dated' to be polite. The ASV advises remediation could be either:

a) Enable HTTP Strict Transport Security

b) Enable the following headers:

  • X-Frame-Options or Content-Security-Policy with the frame-ancestors directive.
  • X-XSS-Protection
  • X-Content-Type-Options

for both 1 and 2 above.

We will be upgrading this R77.30 to R88.20 in September, but in the mean time we are wondering if there are any configuration options variable to resolve this issue.





0 Kudos


The site in question is for downloading the CA certificate and path or for downloading the CRL for correct certificate behavior. While Check Point always strives to improve security and will look into adding the missing security headers, I would like to explain why it is not a vulnerability not having them in this case:

X-XSS-Protection: this one is to block XSS sent in the request to the site. Not relevant since there are no parameters sent on request to this site that can be the source of the XSS attack, and the default by the browsers is to enable anyway.


X-Content-Type-Options: this is so that you don’t load a file of one type as another (i.e. loading plain-text as JavaScript). Not relevant since we only load our own local files and not some arbitrary file that may be misconfigured.


Best regards,



Thanks, @Ethan_Schorer 

0 Kudos