Category: Check Point

Check Point R77.30 management interface crypto hardening (WebUI and SSH Cipher change)

July 10, 2018 / / 0 Comments

By default the management interfaces (WebUI/SSH) of a Check Point firewall are using crypto settings that are not that great (MD5 and SSLv3, etc are enabled), but fortunately it is possible to change them.

SSH daemon is configured like in a normal Linux Distribution by just editing the /etc/ssh/sshd_config, Check Point in its support site also recommends you also modify the ssh client configuration located in /etc/ssh/ssh_config.  Basically in order to change the encryption algorithms available when connecting to the firewall using ssh add the following lines to the aforementioned configuration files using the vi command in Expert mode:

Ciphers aes256-ctr,aes256-cbc,aes128-ctr,aes192-ctr,aes128-cbc,aes192-cbc
MACs hmac-sha1

After modifying the config file restart the SSH server using the following command:

 service sshd restart

If everything is fine then your connection survives and if for some strange reason your ssh connectivity breaks and you can’t log back in you can undo the previous changes by using the terminal access that you can get in the WebUI.

Now that the SSHD settings have been changed, lets start changing the Cipher suites available for HTTPS used for WebUI. Just connect to command line using SSH and do the following in Expert mode.

  1. Backup the current file /web/templates/httpd-ssl.conf.templ: 
    [Expert@HostName:0]# cp /web/templates/httpd-ssl.conf.templ /web/templates/httpd-ssl.conf.templ_ORIGINAL
  2. Edit the current /web/templates/httpd-ssl.conf.templ file: 
    [Expert@HostName:0]# vi /web/templates/httpd-ssl.conf.templ
  3.  Find the line containing the SSLCipherSuite parameter and change the values behind it for example to ECDHE-RSA-AES256-SHA384:AES256-SHA256:!ADH:!EXP:RSA:+HIGH:+MEDIUM:!MD5:!LOW:!NULL:!SSLv2:!SSLv3:!eNULL:!aNULL:!RC4
  4. Close the editor by using :wq!  , the ‘!’ in the end will override the fact that the file has read only permissions.
  5. Update the current configuration of HTTPD daemon based on the modified configuration template: 
    [Expert@HostName:0]# /bin/template_xlate : /web/templates/httpd-ssl.conf.templ /web/conf/extra/httpd-ssl.conf < /config/active
  6. To activate the configuration changes restart the HTTPD daemon by using the “tellpm” command: 
    [Expert@HostName:0]# tellpm process:httpd2

[Expert@HostName:0]# tellpm process:httpd2 t

To find out what you actually want to use as the SSLCipherSuite value you can use the cpopenssl to see what algorithms will be available with which value. Example:

[Expert@HostName:0]# cpopenssl ciphers -v 'ECDHE-RSA-AES256-SHA384:AES256-SHA256:!ADH:!EXP:RSA:+HIGH:+MEDIUM:!MD5:!LOW:!NULL:!SSLv2:!eNULL:!aNULL:!RC4' | sort -k1

Expected output:

AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1

Policy Based Routing resulting in no ARP replies from gateway

June 28, 2018 / / 0 Comments

One might think that when applying Policy Based Routing it will not affect ARP (Address Resolution Protocol) because they are considered to be things working on different layers. PBR clearly should affect only Layer 3 routing decisions and ARP is running somewhere below layer 3.. There are many nice discussions on the internet whether ARP is a Layer2 or Layer3 protocol and some people tend to say its Layer 2,5.

As it turns out PBR can affect ARP. If you for example wish to re-route every packet originating from the 192.168.1.0/24 network and make a policy route stating that everything from source net of 192.168.1.0/24 be routed to lets say to the GW 172.16.1.1 with out specifying any port or protocol. What will happen is that, ARP requests that use broadcast work, but unicast ARP requests won’t get replies any more – at least from Check Point firewalls. So you would need to either make 2 rules stating that it would affect TCP and UDP only based on your needs or follow Check Point supports guide lines: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk84480

Insane amount of IKE SA’s on a SMB device caused by DPD and errors in logs

June 24, 2018 / / 0 Comments

It seems that Check Point 1400 series SMB devices don’t handle Dead Peer Detection (DPD) that well when suddenly an external partner decides to enable it on a 3rd party firewall. Namely what happens is that you end up with tens of thousands of IKE SA’s on your little Check Point box and “Traffic Selector Unacceptable” errors in your logs.

Although in my case it didn’t cause any problems besides me being unable to see the output of the “VPN TU” command , since the IKE SA’s of the DPD flooded my console and the Embedded Gaia VPN TU utility decided not to show me it’s entire output and even crashed a few times. Ended up calling the other side and telling them to disable DPD. Hope they fix DPD support in some newer software release…

CheckPoint to Amazon AWS VPN connection issue

April 30, 2018 / / 2 Comments

When trying to create a VPN tunnel between a CheckPoint firewall and Amazon managed VPN service I happened upon a unpleasant surprise.

Namely when using stronger crypto methods than defined by default in the guides by CheckPoint or Amazon you will run in to an issue, that the CheckPoint device will start dropping traffic after Phase2 key exchanges for a ~5 minute time period. To be more exact the traffic from Amazon to the hosts/networks behind the CheckPoint GW will start failing and connections started from behind the CheckPoint device will continue working as before. Namely Amazon VPN service refreshes it’s keys 5 minutes before the lifetime set in the VPN properties and CheckPoint close to 30 seconds. It actually wouldn’t be a problem if Amazon would use the same parameters as were used to initially establish the tunnel, but it doesn’t. It will actually use DH group 2 to initiate key exchange after which the CheckPoint device will start dropping the traffic coming in from the Amazon service with the following error:

encryption failure: Packet was decrypted with methods which are different from the methods according to the security policy - Gateway and Peer use different DH groups

After talking to both CheckPoint and Amazon support, I can say that the only thing you can do to remedy this is actually setting the DH group to 2  for PFS.

Although Amazon in its documentation(here) states it supports a bunch of different DH groups, and yet it defaults to DH group 2 when initiating the connection it self. To be honest, to me it seems a bit strange that the AWS VPN actually mirrors the encryption/integrity settings of the previous negotiation, but doesn’t remember the PFS settings and defaults to DH group 2. When talking to support services the only thing that AWS support suggested was to force the CheckPoint device to exchange keys before the AWS service does. Unfortunately you cannot do that according to Check Point support services, as there is no such setting available and that timer is around 30s+- some random number of seconds prior to the end of the life time set in the VPN properties.

 

 

Network security policy installation failure fix

April 13, 2018 / / 0 Comments

Some times your network policy installations on Check Point devices might fail.  For me it happened after updating a gateway cluster to the “latest and greatest R77” version. I was unable to push the policy and I was getting the “/opt/CPSFWR77CMP-R77/conf/policy-name.pf”, line 912700: ERROR: target <fw-name> is prohibited” error message.

In order to see what is actually causing the error you will need to log in to the management server via SSH. Go in to “expert mode” and look at what is on the line that the error message is pointing at.

So basically, to fix the issue in my case/work around, I did the following:

  1. Logged in to the security management server in expert mode
  2. Opened up the policy file from the place it was complaining about with the less command. (Hints on how to go to a specific line can be found stackoverflow topic here)
  3. In my case on that specific line I saw a list of DPD(dead peer detection for IPSec VPN) peers which hinted that I should try and disable DPD
  4. Logged in to the management server using smart dashboard, removed permanent tunnel ticks on VPN’s relating to the GW cluster with the issue and tried installing the policy.
  5. Policy successfully installed..

After that I reported the bug to Check Point support and they confirmed the issue..

Enabling DPD on VPN instead of tunnel_test on R77 gateway

March 23, 2018 / / 0 Comments

To keep VPN tunnels alive Check Point uses by default it’s proprietary tunnel_test protocol. In order to get it working with 3rd party vendors it isn’t enough to have the partner device set as an “Interoperable device” and set the tunnel keep alive method on your gateway object as DPD. You also need to set the peer gateway’s tunnel keep alive method as DPD, because by default it is still set to tunnel_test.

To change the keep alive methods you need to do the following as described on Check Point’s website here:

  1. In GuiDBedit, go to Network Objects > network_objects > <gateway> > VPN > tunnel_keepalive_method.
  2. For the Value, select a permanent tunnel mode.
  3. Save.
  4. Install policy on the gateways.

Check Point IPS signature updates through URL filtering blade with HTTPS inspection enabled

March 7, 2018 / / 0 Comments

According to Check Point’s documentation you should let your SMS and Smart Dashboard clients get access to the internet freely without actually intercepting the traffic it self. There might be some cases where you wouldn’t like that idea too much and might still want to inspect it to restrict HTTPS connectivity of those hosts. After a bit of messing about, I managed to get IPS signature update through URL filtering working.

Basically when you try and update IPS signatures or have your Smart Dashboard try and connect to Check Point via URL filtering it will fail with errors relating to the certificates. In other words if you have followed the regular Check Point guidelines on setting up “App control/URL filter” and set the system to trust your gateway’s Certificate Authority, it will still fail. The reason behind it being the fact that Smart Dashboard client uses it’s own trust list not the system wide certificate store. The trust list file is located in “C:\Program Files (x86)\CheckPoint\SmartConsole\R77.30\PROGRAM\ca-bundle.crt” and when you add your own gateway’s CA certificate there after you have already started Smart Dashboard it will work until you restart Smart Dashboard. As I found out that file is actually being downloaded off the SMS every time Smart Dashboard starts up.

Fortunately the filename on the SMS is actually the same as it is in the SmartDashboard folder so when running the standard linux find command you see that there are quite a few instances of it:

/opt/CPsuite-R77/fw1/bin/ca-bundle.crt
/opt/CPinfo-10/bin/data/ca-bundle.crt
/opt/CPcvpn-R77/var/ssl/ca-bundle.crt
/opt/CPcvpn-R77/template/var/ssl/ca-bundle.crt
/opt/CPshrd-R77/database/downloads/CA_BUNDLE/1.0/1.0/ca-bundle.crt
/var/opt/CPsuite-R77/fw1/conf/SMC_Files/asm/ca-bundle.crt
/var/opt/CPshrd-R77/conf/ca-bundle.crt

Now make a backup of /var/opt/CPsuite-R77/fw1/conf/SMC_Files/asm/ca-bundle.crt and /var/opt/CPshrd-R77/conf/ca-bundle.crt files and your gateway’s CA certificate in PEM format to the end. After doing that restart Smart Dashboard and check if the ca-bundle file has your CA certificate in it and if communication to Check Point actually works.

Just as a reminder, the URL’s that need to be enabled for IPS signature to work can be found on CP support site here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk112635

CheckPoint VPN with failed connection not showing up in SmartView Tracker

March 7, 2018 / / 0 Comments

Scenario description

You might have an old existing VPN with some partner which to a gateway that is not under your control. That peer gateway used to be also a CheckPoint device but get’s exchanged for some other 3rd party vendor firewall with out prior notification. When the peer gateway gets changed, the key exchange seems to work, but connection’s fail and nothing seems to be showing up in SmartView tracker although connection logging is on.

Finding out what is happening and trying to fix it

After seeing no traffic in SmartView tracker, you log in to the gateway and might look at tcpdump to see if there is actually any traffic coming from the peer gateway. After seeing there is actual traffic coming you should try a few kernel level debug commands on VPN to get some info on whats happening. For example run “fw ctl zdebug -m VPN all” and you might see something like this in the output:

 [cpu_1];[fw4_0];fw_log_drop_conn: Packet <dir 1, 192.168.200.100:0 -> 172.32.200.100:0 IPP 50>, dropped by do_inbound, Reason: decryption failed

Well this still isn’t saying too much, but at least is giving a hint. Next lets take a look at the secure XL debug, maybe it gives some more info. To get the output prepare the debug first by using the following commands:

[Expert@HostName:0]# fw ctl debug 0
[Expert@HostName:0]# fw ctl debug -buf 32000
[Expert@HostName:0]# sim dbg -m vpn all
[Expert@HostName:0]# sim dbg -m mgr + vpn
Now start the debug:
fw ctl kdebug -T -f > /tmp/debug.txt

Let it run for a bit and close it with ctrl+c. Go through the log file, you might find something like this:

;11Jul2017 13:14:57.017362;[cpu_1];[SIM-xxxx]vpn_ipsec_decrypt: Packet does not match block size (xx xx xx);

;11Jul2017 13:14:57.017362;[cpu_1];[SIM-xxxx]vpn_decrypt: IPSEC decryption failed;

Well this is odd. You contact the peer gateway’s technical contact asking if have they changed anything lately and find out that they changed their firewalls..

Fixing the issue

To remedy the issue create a new gateway object that is of the “Interoperable Device” type and has all the same settings/parameters as the previous the peer gateway object that was with the “Check Point gateway” type. Change the peer GW object in the VPN community to the newly created “Interoperable device” and install policy. And the traffic starts flowing again.

As it seems Check Point is handling VPN tunnels differently between Check Point devices and Interoperable devices.

R77 database revision control unspecified error

February 1, 2018 / / 0 Comments

It is always a good idea to have database revision control on just in case. But keep in mind that the comment field in it doesn’t support all sorts of characters. As it turns out using commas (“,”) inside comments are illegal and ends up with the revision creation failing and SmartDashboard client giving you an “unspecified error” message. Just remove the comma or any other “strange symbol” from it and it works fine. In other words remember to keep the comments short and simple, with out special characters..

CheckPoint Gaia embedded sic reset

January 29, 2018 / / 0 Comments

If you happen to have a CheckPoint 1400 series firewall hooked up to your central management and for some reason need to reset the sic communication between the firewall and management then this command will help (it’s not the same as in the full blown Gaia OS):

set sic_init password Y0urS!cPassw0rd