Difference between revisions of "Check Point Firewall-1"

From royhills
Jump to: navigation, search
(→‎Version History)
 
(No difference)

Latest revision as of 09:11, 27 October 2013

Platform Notes

CheckPoint Firewall-1 runs on a number of different platforms, including:

  • Windows
  • Solaris
  • IPSO (Nokia)
  • Redhat Linux
  • Secure Platform (a Check Point Linux distro)

The IKE behaviour is the same regardless of the platform (including the Nokia, which is sometimes considered a different system), but the IP stack characteristics such as IP TTL, IP ID pattern and DF flag will vary depending on the underlying operating system.

CheckPoint's IPsec implementation supports both site-to-site and remote access VPNs.

Version History

The Firewall-1 versioning can be rather confusing because CheckPoint have changed the version numbering several times through the product's history. The table below shows the version history since version 3.0, and notes the major changes to the VPN functionality.

Version Release Date Notes
3.0b 1997 Manual IPsec, SKIP and FWZ encryption schemes only. No IKE support
4.0 1998 IKE encryption scheme introduced, known as ISAKMP in the user interface. No Vendor ID
4.1 2000 CheckPoint Vendor ID added. IKE encryption scheme name changed from ISAKMP to IKE
NG Jun 2001 Manual IPsec and SKIP encryption methods discontinued. AES support added
NG FP1 Nov 2001 Simplified VPN policies introduced
NG FP2 Apr 2002 FWZ encryption method discontinued, only IKE remains. Unauthenticated topology download discontinued
NG FP3 Aug 2002
NG AI R54 Jun 2003 IKE DoS protection introduced
NG AI R55 Nov 2003
NGX R60 Aug 2005 SecureClient NAT-T support added. Timestamp added to CheckPoint Vendor ID
NGX R61 Mar 2006
NGX R62 Nov 2006
NGX R65 Mar 2007
R70 Feb 2009
R71 Apr 2010 IKEv2 support added
R72 Mar 2010
R73 Dec 2010
R75 Jan 2011
R76 May 2013
R77 Aug 2013

You are unlikely to come across anything earlier than NGX in practice.

Backoff Patterns

Firewall-1 v4.0

Firewall-1 v4.0 has the backoff pattern: 

0, 3, 3, 3, 3, 6, 6, 6, 6, 6, 6, 6

Below is an example from Firewall-1 v4.0 SP1 running on Windows NT 4.0. This uses aggressive mode with PSK authentication and a valid username: 

$ ike-scan -M -A --id=test --showbackoff 172.16.3.2
172.16.3.2      Aggressive Mode Handshake returned
        HDR=(CKY-R=b5014bb50dc5a181)
        SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        KeyExchange(128 bytes)
        Nonce(16 bytes)
        ID(Type=ID_IPV4_ADDR, Value=172.16.3.2)
        Hash(20 bytes)

IKE Backoff Patterns:

IP Address      No.     Recv time               Delta Time
172.16.3.2      1       1166715329.190249       0.000000
172.16.3.2      2       1166715332.222134       3.031885
172.16.3.2      3       1166715335.199433       2.977299
172.16.3.2      4       1166715338.222417       3.022984
172.16.3.2      5       1166715341.180079       2.957662
172.16.3.2      6       1166715347.223699       6.043620
172.16.3.2      7       1166715353.185970       5.962271
172.16.3.2      8       1166715359.243473       6.057503
172.16.3.2      9       1166715365.235595       5.992122
172.16.3.2      10      1166715371.263534       6.027939
172.16.3.2      11      1166715377.241506       5.977972
172.16.3.2      12      1166715383.281081       6.039575
172.16.3.2      Implementation guess: Firewall-1 4.0

Firewall-1 v4.1 and Later

Firewall-1 v4.1, NG and NGX has the backoff pattern: 

0, 2, 2, 2, 2, 2, 2, 4, 4, 4, 4, 4

Below is an example from NGX R60 running on Secure Platform. We need to use --auth=3 to specify RSA signature authentication to get a response from this system because recent versions of Firewall-1 do not support pre-shared key authentication. 

$ ike-scan --auth=3 --showbackoff -M 172.16.2.2
Starting ike-scan 1.8.4 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=a0bd270627f4267d)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d456da1a80000000018000000 (Firewall-1 NGX)

IKE Backoff Patterns:

IP Address      No.     Recv time               Delta Time
172.16.2.2      1       1164806997.393873       0.000000
172.16.2.2      2       1164806999.402661       2.008788
172.16.2.2      3       1164807001.402768       2.000107
172.16.2.2      4       1164807003.402999       2.000231
172.16.2.2      5       1164807005.403191       2.000192
172.16.2.2      6       1164807007.412215       2.009024
172.16.2.2      7       1164807009.412454       2.000239
172.16.2.2      8       1164807013.412537       4.000083
172.16.2.2      9       1164807017.412650       4.000113
172.16.2.2      10      1164807021.421858       4.009208
172.16.2.2      11      1164807025.422004       4.000146
172.16.2.2      12      1164807029.422159       4.000155
172.16.2.2      Implementation guess: Firewall-1 4.1/NG/NGX

Here is an example from Firewall-1 4.1 running on Windows NT 4.0, which shows the same backoff pattern. This example is from December 2002 and uses a very old version of ike-scan, which has a simpler output format than recent versions: 

$ ike-scan -o 172.16.2.2
172.16.2.2      IKE Handshake returned (1 transforms)

IP Address      No.     Recv time               Delta Time
172.16.2.2      1       1039013450.829636       0.000000
172.16.2.2      2       1039013452.826968       1.997332
172.16.2.2      3       1039013454.829521       2.002553
172.16.2.2      4       1039013456.832470       2.002949
172.16.2.2      5       1039013458.835027       2.002557
172.16.2.2      6       1039013460.837986       2.002959
172.16.2.2      7       1039013462.840563       2.002577
172.16.2.2      8       1039013466.846062       4.005499
172.16.2.2      9       1039013470.851587       4.005525
172.16.2.2      10      1039013474.857104       4.005517
172.16.2.2      11      1039013478.862615       4.005511
172.16.2.2      12      1039013482.868112       4.005497

Vendor IDs

Firewall-1 version 4.1 and later will return a CheckPoint-specific Vendor ID, the CheckPoint VID, which identifies the system as a Checkpoint system and also provides information about which version it is running. An example CheckPoint VID is: 

f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138a000000000000000018800000

This CheckPoint VID is 40 bytes in length. The first 20 bytes are always f4ed19e0c114eb516faaac0ee37daf2807b4381f, and the last 20 bytes contain details about the version and configuration. It is suspected that the first 20 bytes are an SHA1 hash of something.

The 2nd 20 bytes (bytes 21 to 40) of the Vendor ID payload consist of five 4-byte integers in network (big endian) byte order. The 4-byte integer at byte positions 25 to 28 inclusive contains the Firewall-1 version number.

Firewall-1 NGX R60 returns non-zero data in the "timestamp" field, whereas this is always zero for 4.1 and NG. This allows us to distinguish NGX from NG. This timestamp shows the current time on the target firewall in seconds since Jan 1st 1970.

The table below summarises the structure of the CheckPoint vendor ID:

Byte Position Example Data Meaning
1 to 20 f4ed19e0c114eb516faaac0ee37daf2807b4381f Checkpoint Vendor ID
21 to 24 00000001 Product (1=Firewall, 2=client)
25 to 28 0000138a Encoded version (see below)
29 to 32 00000000 Timestamp (NGX only)
33 to 36 00000000 Reserved (always zero)
37 to 40 18800000 Features

The table below shows how the encoded version and timestamp identify the Firewall-1 software version:

Hex Version Decimal Version Timestamp Firewall-1 Version Notes
N/A N/A N/A 4.0 Firewall-1 v4.0 doesn't return any VendorID
0002 2 Zero 4.1 This is 4.1 base install (no service pack)
0003 3 Zero 4.1 SP1
0fa2 4002 Zero 4.1 SP2 to SP6 4.1 SP2 to SP6 inclusive return the same version
1388 5000 Zero NG This is NG base install (no service pack)
1389 5001 Zero NG FP1
138a 5002 Zero NG FP2
138b 5003 Zero NG FP3
138c 5004 Zero NG AI R54
138d 5005 Zero NG AI R55
138e 5006 Zero NG AI R56 SecureClient only
138d 5005 Non-Zero NGX R60 NGX has non-zero timestamp

See the checkpoint VID fingerprinting advisory for more information about this vendor id.

NG AI R54 Vendor ID example

For v4.1, NG and NG AI, you need to send a vendor ID starting with f4ed19e0c114eb516faaac0ee37daf2807b4381f in the probe packet for the Firewall-1 system to respond with its Vendor ID. It doesn't seem to matter what data, if any, follows this initial 20 bytes. 

$ ike-scan -v -M 172.16.2.2 --vendor=f4ed19e0c114eb516faaac0ee37daf2807b4381f
Starting ike-scan 1.8 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
172.16.2.2      Main Mode Handshake returned
SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138c000000000000000018a00000 (Firewall-1 NG AI
 R54)

NGX R60 Vendor ID examples

Note that NGX will return a CheckPoint vendor ID regardless of whether we send the CheckPoint VID in the probe packet. However, it will not return a CheckPoint Vendor ID if we send any Vendor ID that it does not support.

NGX also supports NAT Traversal as detailed in 3947, and will return the NAT-T Vendor ID if it is supplied by the initiator.

The examples below show the three different vendor ID behaviours that have been observed on NGX R60: first with no vendor ID which results in the CheckPoint vendor ID being returned, then with the NAT-T vendor ID which causes both CheckPoint and NAT-T vendor IDs to be included in the response, and finally with an unsupported vendor ID which cause no vendor IDs to be returned. 

$ ike-scan --auth=3 -M 172.16.2.2
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=901fa68a32a85d13)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d456dab180000000018000000 (Firewall-1 NGX)

$ ike-scan --vendor=4a131c81070358455c5728f20e95452f -M --auth=3 172.16.2.2
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=d16602f27fd18ed2)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=4a131c81070358455c5728f20e95452f (RFC 3947 NAT-T)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d45882a390000000018000000 (Firewall-1 NGX)

$ ike-scan --vendor=deadbeef -M --auth=3 172.16.2.2
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=df6c81419025e70e)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)

Note: there is more work to do here. I suspect that the vendor ID handling machanism is not fully understood.

Authentication Methods

Early versions of CheckPoint Firewall-1 used pre-shared key (PSK) authentication for remote access. Hybrid mode was introduced in version 4.1, and became the default remote access authentication method in NG FP1. PSK authentication was used together with IKE aggressive mode, whereas Hybrid Mode uses IKE Main Mode, which is more secure. Support for PSK authentication was discontinued in NG FP1.

Hybrid mode is defined in the IETF draft Hybrid Authentication Mode for IKE. This draft was written by CheckPoint, and I have not observed hybrid authentication on non-CheckPoint systems. Hybrid mode uses the authentication method number 64221, so a CheckPoint system offering Remote Access will normally respond to ike-scan --auth=64221.

CheckPoint systems also support the standard RSA signature authentication method for remote access, with authentication method number 3. However this is never used by the CheckPoint remote access VPN client, which always uses hybrid authentication.

Below are examples of a CheckPoint Firewall-1 NGX R60 system responding to Main Mode with Hybrid and RSA authentication methods. 

$ ike-scan -M --auth=64221 172.16.2.2
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=93863e6a1b8ac562)
        SA=(Enc=3DES Hash=SHA1 Auth=Hybrid Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d45c315c80000000018000000 (Firewall-1 NGX)

$ ike-scan -M --auth=3 172.16.2.2
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=a4757e741e0b7715)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d45c315fb0000000018000000 (Firewall-1 NGX)

ISAKMP SA Lifetime

CheckPoint Firewall-1 allows any value for both the lifetime in seconds and the lifetime in kilobytes (called lifesize by ike-scan). It will accept any values including no value at all, very low values like 1, and very high values like 0xffffffffffffffff (a 64-bit value representing 2^64-1 or 18,446,744,073,709,551,615). Whatever is specified will be returned in the response proposal.

The examples below show how NGX R60 responds to various different ISAKMP SA lifetime parameters. 

$ ike-scan --lifetime=none --trans=5,2,3,2 -M 172.16.2.2
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=6b550b67694c7209)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d4585973f0000000018000000 (Firewall-1 NGX)

$ ike-scan --lifetime=1 --trans=5,2,3,2 -M 172.16.2.2
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=badca1d656741603)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00000001)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d458597830000000018000000 (Firewall-1 NGX)

$ ike-scan --lifetime=0xffffffffffffffff --trans=5,2,3,2 -M 172.16.2.2
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=bf86305f8b4e8475)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(8)=0xffffffffffffffff)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d458597ab0000000018000000 (Firewall-1 NGX)

$ ike-scan --lifetime=none --lifesize=1 --trans=5,2,3,2 -M 172.16.2.2
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=9d8e11a4f95108ea)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Kilobytes LifeDuration(4)=0x00000001)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d458598380000000018000000 (Firewall-1 NGX)

$ ike-scan --lifetime=none --lifesize=0xffffffffffffffff --trans=5,2,3,2 -M 172.16.2.2
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=ef47623d415096e7)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Kilobytes LifeDuration(8)=0xffffffffffffffff)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d458598660000000018000000 (Firewall-1 NGX)

$ ike-scan --lifetime=0xffffffffffffffff --lifesize=0xffffffffffffffff --trans=5,2,3,2 -M 172.16.2.2
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=9eb6d5a533850f64)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(8)=0xffffffffffffffff LifeType=Kilobytes LifeDuration(8)=0xffffffffffffffff)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d458599f40000000018000000 (Firewall-1 NGX)

Transform Attribute Ordering and Rewriting

CheckPoint Firewall-1 will always return the transform attributes in exactly the same order that they are supplied by the initiator, and will never rewrite a variable length attribute as a basic attribute as permitted by RFC 2409.

The examples below show this behaviour on NGX R60.

In this example the transform is Enc=3DES,Hash=SHA1,Auth=RSA_Sig,Group=2. This is the natural transform attribute ordering, as it follows the order in which the attributes are numbered. 

$ ike-scan -M --trans="(1=5,2=2,3=3,4=2)" 172.16.2.2
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=8d93bab964a7e9c5)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d45882d460000000018000000 (Firewall-1 NGX)

In this example the same transform attributes are specified in the reverse order. 

$ ike-scan -M --trans="(4=2,3=3,2=2,1=5)" 172.16.2.2
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=85937e63d7634fdd)
        SA=(Group=2:modp1024 Auth=RSA_Sig Hash=SHA1 Enc=3DES)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d45882d5a0000000018000000 (Firewall-1 NGX)

In this example we add a lifetime of 28,800 seconds (LifeType=Seconds, LifeDuration=28800). Because we specify the value in decimal, it is added as a basic attribute. 

$ ike-scan -M --trans="(1=5,2=2,3=3,4=2,11=1,12=28800)" 172.16.2.2
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=5dde8838df428cbf)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration=28800)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d45882e3b0000000018000000 (Firewall-1 NGX)

In this example we add the same lifetime, but this time as a variable length attribute with a length of four bytes. 

$ ike-scan -M --trans="(1=5,2=2,3=3,4=2,11=1,12=0x00007080)" 172.16.2.2
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=d81530065cb06038)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d45882e8b0000000018000000 (Firewall-1 NGX)

In this example, we specify each attribute twice. 

$ ike-scan -M --trans="(1=5,2=2,3=3,4=2,1=5,2=2,3=3,4=2)" 172.16.2.2
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=8cf2e3b830e53bcd)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d458a79eb0000000018000000 (Firewall-1 NGX)

Here is the same thing but with the variable key length AES encryption algorithm and associated key length attribute. 

$ ike-scan -M --trans="(1=7,14=256,2=2,3=3,4=2,1=7,14=256,2=2,3=3,4=2)" 172.16.2.2
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=57b2f6f4c8d06e02)
        SA=(Enc=AES KeyLength=256 Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 Enc=AES KeyLength=256 Hash=SHA1 Auth=RSA_Sig Group=2:modp1024)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d45cf53fd0000000018000000 (Firewall-1 NGX)

Aggressive Mode

CheckPoint Firewall-1 versions NG FP1 and later do not enable aggressive mode by default, as they use Hybrid mode for remote access connections. Version 4.0, 4.1 and NG base do support aggressive mode by default, but these old versions are very rare now.

Although it is possible to enable aggressive mode on current versions, it is unusual for anyone to do this because there is normally no need to do so. This means that you are unlikely to meet a CheckPoint system that supports aggressive mode.

CheckPoint accepts the default ID type of 3 (ID_USER_FQDN) in aggressive mode, so there is no need to explicitly specify this with --idtype.

Here is an example showing CheckPoint NG AI R54 with aggressive mode. The firewall was specifically configured to respond to aggressive mode for this example. Note that we need to specify a valid VPN user to get an aggressive mode reply, in this case the user is "test". 

$ ike-scan -A -n test -M --vendor=f4ed19e0c114eb516faaac0ee37daf2807b4381f 172.16.2.2
172.16.2.2	Aggressive Mode Handshake returned
	SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
	KeyExchange(128 bytes)
	Nonce(20 bytes)
	ID(Type=ID_IPV4_ADDR, Value=172.16.2.2)
	VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138c000000000000000018800000 (Firewall-1 NG AI R54)
	Hash(20 bytes)

Response to Noncompliant and Malformed Packets

CheckPoint Firewall-1 generally responds to IKE packets that it doesn't support by sending an informational packet containg a Notify payload. This includes just about everything from unsupported attributes to malformed packets. CheckPoint uses the largest set of Notify messages of any implementation that I've tested.

The examples below are all from Firewall-1 NGX R60.

No Acceptable Transforms

$ ike-scan -M --trans=1,1,1,1 172.16.2.2
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2      Notify message 14 (NO-PROPOSAL-CHOSEN)
        HDR=(CKY-R=0000000000000000, msgid=df9d0374)

Bad IKE version

$ ike-scan -M --headerver=0x30 172.16.2.2
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2      Notify message 5 (INVALID-MAJOR-VERSION)
        HDR=(CKY-R=0000000000000000, msgid=7ba290e8)

$ ike-scan -M --headerver=0x15 172.16.2.2
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2      Notify message 6 (INVALID-MINOR-VERSION)
        HDR=(CKY-R=0000000000000000, msgid=1ff69096)

Invalid DOI

$ ike-scan -M --doi=2 172.16.2.2
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2      Notify message 2 (DOI-NOT-SUPPORTED)
        HDR=(CKY-R=0000000000000000, msgid=4c2bff15)

Invalid Situation

$ ike-scan -M  --situation=2 172.16.2.2
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2      Notify message 3 (SITUATION-NOT-SUPPORTED)
        HDR=(CKY-R=0000000000000000, msgid=6bb2a2d1)

Invalid Initiator Cookie

$ ike-scan -M --cookie=0000000000000000 172.16.2.2
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2      Notify message 4 (INVALID-COOKIE)
        HDR=(CKY-R=0000000000000000, msgid=6a649f8f)

Invalid Flags

$ ike-scan -M --hdrflags=255 172.16.2.2
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2      Notify message 8 (INVALID-FLAGS)
        HDR=(CKY-R=0000000000000000, msgid=d6bcfe13)

Invalid Protocol

$ ike-scan -M --protocol=2 172.16.2.2
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2      Notify message 10 (INVALID-PROTOCOL-ID)
        HDR=(CKY-R=0000000000000000, msgid=064ba4b6)

Invalid SPI

$ ike-scan -M --spisize=32 172.16.2.2
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2      Notify message 11 (INVALID-SPI)
        HDR=(CKY-R=0000000000000000, msgid=2a958c8c)

Non-Zero Reserved Fields

$ ike-scan -M --mbz=255 172.16.2.2
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2      Notify message 16 (PAYLOAD-MALFORMED)
        HDR=(CKY-R=0000000000000000, msgid=e880e3c6)

NAT Traversal

Firewall-1 NGX R60 and later support RFC 3947 NAT Traversal by default.

Below is an example showing NGX R60 responding to a Main Mode request in NAT Traversal format: 

$ ike-scan --nat-t --auth=3 -M 172.16.2.2
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=a513e2ff27e0f4e1)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d45bc9cce0000000018000000 (Firewall-1 NGX)

And here is the tcpdump output showing the packets. Note that NAT Traversal uses UDP port 4500: 

11:17:41.960593 IP 192.168.124.6.4500 > 172.16.2.2.4500: UDP, length: 340
11:17:41.971344 IP 172.16.2.2.4500 > 192.168.124.6.4500: UDP, length: 132

NGX R60 does not send the NAT Traversal vendor ID by default, but it will send it if the peer does. It will respond to the NAT traversal vendor ID in either normal or NAT Traversal mode. Below is an example showing NGX R60 responding to a NAT Traversal format request with the NAT Traversal vendor ID 

$ ike-scan --nat-t --auth=3 -M --vendor=4a131c81070358455c5728f20e95452f 172.16.2.2
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=8755112a3a7c62a8)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=4a131c81070358455c5728f20e95452f (RFC 3947 NAT-T)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d45bc9ee10000000018000000 (Firewall-1 NGX)

IVEv2

CheckPoint Firewall-1 supports IKEv2 from R71, which was released in April 2010. Previous versions only supported IKEv1.

Remote Access VPN Client

CheckPoint SecureClient NGX R60 login screen

CheckPoint Firewall-1 uses a proprietary VPN client calles SecuRemote or SecureClient, which can be downloaded from the CheckPoint website.

It is not possible to use this client with other remote access products because the topology definition is downloaded from the VPN Server (firewall) using a proprietary protocol, and also SecuRemote/SecureClient only supports the Hybrid authentication method, which is only present on CheckPoint VPN servers.

It may be possible to use other IPsec remote access VPN clients with CheckPoint, but I've never seen this done.

SecureClient NGX R60 uses IKE Main Mode and offers the following six transforms in order:

No. Encryption Hash Authentication DH Group Lifetime (Seconds)
1 AES/256 SHA1 Hybrid 2 (MODP 1024) 28,800
2 AES/256 MD5 Hybrid 2 (MODP 1024) 28,800
3 3DES SHA1 Hybrid 2 (MODP 1024) 28,800
4 3DES MD5 Hybrid 2 (MODP 1024) 28,800
5 DES SHA1 Hybrid 2(MODP 1024) 28,800
6 DES MD5 Hybrid 2 (MODP 1024) 28,800

These VPN client transform settings are not changeable by the user.

Other Interesting Behaviour

Zero responder cookies in notify messages

When a CheckPoint system responds with an informational exchange containing a notify message, indicating an error condition, it always sets the responder cookie to zero. It is one of the few systems that I have observed with this behaviour, others being strongSwan.

It is probably using the responder cookie from the peer's packet, which will always be zero in normal circumstances.

Here is an example from NGX R60. Note that it also includes a message ID, which is not normally used for the first packet exchange during Phase-1. This message ID is different for each response. 

$ ike-scan --trans=1,1,1,1 -M 172.16.2.2
172.16.2.2      Notify message 14 (NO-PROPOSAL-CHOSEN)
        HDR=(CKY-R=0000000000000000, msgid=9340f9a4)

Here is an example from Firewall-1 4.0 SP1 (1998 vintage). This example uses aggressive mode with PSK authentication, and also illustrates the user enumeration vulnerability that existed back then: 

$ ike-scan -M -A --id=bill 172.16.3.2
172.16.3.2      Notify message 9101 (Firewall-1) Message="User bill unknown.\000"
        HDR=(CKY-R=0000000000000000)

There are additional examples in the malformed packet section.

IKE over TCP

Firewall-1 supports IKE over TCP using port 500, although it is not enabled by default.

The protocol is raw IKE over TCP, with the contents of the TCP segment being the same as the UDP datagram contents for IKE over UDP. ike-scan supports this raw IKE over TCP with the --tcp=1 option.

Firewall-1 is the only system that has been observed to use this raw IKE over TCP, so if you see it then it's probably a CheckPoint system. Cisco VPN Concentrators also support IKE over TCP, but they use a different encapsulation method.

The example below shows an NGX R60 firewall responding to IKE over TCP: 

$ ike-scan --auth=3 --tcp=1 -M 172.16.2.2
Starting ike-scan 1.8.5 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=ef806e803d0293d0)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d458560bc0000000018000000 (Firewall-1 NGX)

Encryption Algorithm Key Length

CheckPoint Firewall-1 will accept any encryption algorithm key length, even for ciphers with a fixed key length. The firewall will include the same key length in its response proposal.

The example below shows a request for Triple-Des (encryption algorithm #5) with an absurd key length of 27: 

$ ike-scan --trans=5/27,2,3,2 -M 172.16.2.2
Starting ike-scan 1.8.5 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=cc9049f364c35bf3)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 KeyLength=27 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d4585628f0000000018000000 (Firewall-1 NGX)

DoS Protection

Firewall-1 NGX IKE default DoS protection settings

Recent versions of Firewall-1 have puzzles DoS protection enabled by default for remote access VPN. This is based on Puzzles: A Cryptographic Countermeasure Against Connection Depletion Attacks.

When the VPN server is under heavy load, it requires the client to solve a mathematical puzzle before being allowed to connect. The CheckPoint remote access VPN client is able to solve the puzzle, so remote access users can continue to connect even if an attacker is launching a resource exhaustion DoS attack.

The example below shows how ike-scan can be used to provoke the puzzles behaviour. In this example we use the simple perl script print "172.16.2.2\n" x 1000 to output one thousand copies of the target IP address, and we pipe this to ike-scan which reads its target list from standard input using the -f - option. The other options are -r 1, which specifies that only a single attampt should be made for each target (no retries), and --trans=5,2,3,2, which specifies an acceptable transform.

At first the Firewall responds normally, but eventually the high rate of requests causes it to go into DoS protection mode and it starts responding with a notify message containing the test Server under heavy load followed by some binary data. 

$ perl -e 'print "172.16.2.2\n" x 1000' | ike-scan -M -r 1 --trans=5,2,3,2 -f -
Starting ike-scan 1.8.5 with 1000 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=e899761fd6741a17)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d458a84230000000018000000 (Firewall-1 NGX)
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=0385f57893ebd814)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d458a84230000000018000000 (Firewall-1 NGX)
172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=0690b79a637527bb)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d458a84230000000018000000 (Firewall-1 NGX)

The firewall continues to respond normally until the number of IKE slots used rises above 70%, then we see the following: 

172.16.2.2      Main Mode Handshake returned
        HDR=(CKY-R=ce0b378f5b144e46)
        SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
        VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d458a84250000000018000000 (Firewall-1 NGX)
172.16.2.2      Notify message 9110 (Firewall-1) Message="Server under heavy load.
        \000\000\000\000\000\000\000\000\257D\220\323\212\220W\202k\023\270\331\307\210\2529\023"
        HDR=(CKY-R=80a0b55b5e500000, msgid=a13325e7)
172.16.2.2      Notify message 9110 (Firewall-1) Message="Server under heavy load.
        \000\000\000\000\000\000\000\0006\352\313Kt\225Am\335,!\2520D\310\340\023"
        HDR=(CKY-R=4fb29c823ef80000, msgid=a1e7d366)
172.16.2.2      Notify message 9110 (Firewall-1) Message="Server under heavy load.
        \000\000\000\000\000\000\000\000\335\\\223*\236N\362\220\004\310\214\343\n\177\266\361\023"
        HDR=(CKY-R=afb4fc13ff500000, msgid=b2f5242a)
172.16.2.2      Notify message 9110 (Firewall-1) Message="Server under heavy load.
        \000\000\000\000\000\000\000\000\276a+\220\310\025\220\316\274Y\360\360\nA\333\253\023"
        HDR=(CKY-R=105cda7412c00000, msgid=2b834f5b)

See this page for details of how the CheckPoint puzzles DoS protection implementation.

Default Configuration

Remote Access IKE Phase-1 Attributes

CheckPoint Firewall-1 NGX R60 Global Remote Access IKE Phase-1 Properties
CheckPoint Firewall-1 NGX R60 Global Remote Access IKE Phase-1 Authentication

NGX R60 supports the following transform attributes for remote access IKE Phase-1 by default:

Encryption DES, Triple-DES, AES-256
Hash MD5, SHA1
Authentication RSA Signature, Hybrid
DH Group 2

It is surprising that single DES is still supported by default because the CheckPoint VPN client, SecureClient, has supported strong cryptography for IKE Phase-1 since at least 4.1. The screenshot on the right shows the default settings in the GUI interface.

Discovered Vulnerabilities

Release Date Vulnerability Details
Sep 2002 Remote Access Username Enumeration
Jan 2004 Vendor ID Fingerprinting
Retrieved from ‘http://www.royhills.co.uk/wiki/index.php?title=Check_Point_Firewall-1&oldid=3075’