Posts Tagged ‘checkpoint’

Check Point R77

Posted: September 20, 2013 in technical
Tags: , , ,

Yes, 77, nice number – I said.

Besides that, though:

New Threat Emulation Software Blade
New Check Point Compliance Blade
HyperSPECT Technology
Gaia Operating System Enhancements
Enhanced Gaia Software Updates
Enhanced Identity Awareness
Enhanced Endpoint Security
Note: Endpoint Security E80.50 clients will be available only by end of September 2013.
– Full Disk Encryption
– Endpoint Security Client – General
– Anti-Malware
– Firewall
– Media Encryption & Port Protection
Security Gateway Virtual Edition
Enhanced VSX
Enhanced SAM Card Support
Mobile Access

full list at the CKP UserCenter

CheckPoint_R77

Advertisements

I believe this is how it works, at least partially. Could not find this information anywhere online, only got partial responses, that don’t actually cover all the cases. Not to mention, all the aspects on where exactly in the FW engines the NAT actually happens:

===========================================================================
Automatic NAT: 
- Static NAT
> 2 NAT rules are automatically created:
>> A source translation where translates the source between the original and
 the NAT address.
>> A destination translation where translates the destination between the
NAT and the original address.
> creates proxy ARP
 -- Translate on Client Side ON
> translates on Inbound, after VM, before routing, on interface I
> don't need anymore routes
-- Translate on Client Side OFF
> translates on Outbound, after routing, after VM, on interface O
> add route from public IP to private IP

- Hide NAT (as this is also "automatic" only works with public IP from FW interface)
> creates proxy ARP
 -- Translate on Client Side ON
> translates on Inbound, after VM, before routing, on interface I
> no more routes needed

 -- Translate on Client Side OFF
> translates on Outbound, after routing, after VM, on interface O
> no more routes needed
 ===========================================================================
Manual NAT:
- Static NAT
 -- Translate on Client Side ON
> add ARP entries to the FW for all hiding IPs
> no additional routes needed
> translates on Inbound, after VM, before routing, on interface I

 -- Translate on Client Side OFF
> add ARP entries to the FW for all hiding IPs
  --- Hiding IP in same subnet as FW external Interface
> add route from public IP to private IP
  --- Hiding IP in different subnet as FW external Interface
> add route from public IP to private IP: next hop: private IP

- Hide NAT
 -- Translate on Client Side ON
  --- Hiding IP in same subnet as FW external Interface
> no ARP changes needed
> no additional routes needed
> translates on Inbound, after VM, before routing, on interface I

  --- Hiding IP in different subnet as FW external Interface
> add ARP entry to the FW for the hiding IP
> translates on Inbound, after VM, before routing, on interface I
> routes ? 

 -- Translate on Client Side OFF
  --- Hiding IP in same subnet as FW external Interface
> add route from public IP to private IP
> translates on Outbound, after routing, after VM, on interface O

  --- Hiding IP in different subnet as FW external Interface
> add route from public IP to private IP: next hop: private IP
> translates on Outbound, after routing, after VM, on interface O
===========================================================================
CopyRight: CheckPoint
===========================================================================
Do Manual NAT when:
- Instances where remote networks only allow specifci IP addresses
- Situations where translation is desired for some services, and not others
- Environments where more granular control of address translation in VPN tunnels is needed
- Enterprises where address translation rule base must be manipulated
- When Port Address Translation is required
- Environments where granular control of address translation between internal networks is required
- When a range of IP addresses, rather than a network, will be translated

It occurred to me today…how ’bout trying an IPcomp scenario? Of course, looking at RFC 3173, I was very excited about running a test and actually viewing Next Header / Protocol = 108, as the IETF guys say.

Basically, the “Compression” part of this IPsec traffic is negotiated just as  any other protocol: AH, ESP, EAP…via IKE, or manually configured on a device. Now…as I’ve got to devices….good question: _what_ device could I use if I want IPsec IPCompression?

Look at this: http://www.vpnc.org/vpnc-ipsec-features-chart.html. Scroll down to “Features (HTML table). The vendors that actually implement this, as per VPN Consortium (and for some of them I could tell you from direct experience), are CheckPoint, Cisco, McAfee, SafeNet, StoneSF and TeamF1. A bit disappointed that I didn’t have the opportunity of working on all of these devices, I am redirecting my attention to what I do have: a big, shiny and fluffy Debian, with Strongswan installed and xfrm module also on.

So, lets get down to business. I have taken the simplest scenario I could think of at the moment, a transport mode scenario, having as Initiator 192.168.0.10 and as Responder 192.168.0.1. These two hosts negotiate 3des-md5-dh2 algorithms, doing PSK authentication. No PFS, no other kinky stuff. Just basic IKEv2 negotiation. The Strongswan config is as simple as possible.

*Note 1 : on strongswan.org people say that IKEv2 does not support compression – I have run a test with IKEv2 and compression and it works very well 🙂 But, in order to humor the strongswan guys, I have used IKEv1 in the following scenario

*Note 2 : in order to actually _see_ the encapsulated packets, I have used ESP-NULL Encryption for data encapsulation. Yes, I could have used a NetCocoon analyzer, but that – in the next episode 😛

So: IKEv1, Transport mode, Main Mode, Null Encryption, ESP only, IP Comp:

config setup
plutostart=yes
charonstart=no
plutodebug=all
crlcheckinterval=180
strictcrlpolicy=no
# Add connections here.
conn %default
keyingtries=1
keyexchange=ikev1
authby=secret
mobike=no
pfs=no
type=transport
compress=yes
auto=start
ike=3des-md5-modp1024
esp=null-md5
leftfirewall=yes
rekey=yes
conn network1
left=192.168.0.1
right=192.168.0.10
# ipsec status
000 “network1”: 192.168.0.1[192.168.0.1]…192.168.0.10[192.168.0.10]; erouted; eroute owner: #3
000 “network1”:   newest ISAKMP SA: #2; newest IPsec SA: #3;
000
000 #3: “network1” STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 2488s; newest IPSEC; eroute owner
000 #3: “network1” esp.525b0b48@192.168.0.10 (0 bytes) esp.5511d8c2@192.168.0.1 (0 bytes) comp.1169@192.168.0.10 comp.527e@192.168.0.1; transport
000 #2: “network1” STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 2488s; newest ISAKMP
000

Yes, it worked.

Now…I am not sure what exact compression algorithms this Strongswan daemon has, but I can tell you for sure it uses at least DEFLATE(  RFC 2394 ). Ciscoon the other hand, uses only LZS (RFC 2395 ) – as far as I have seen – to be updated if anybody else tested it versus DEFLATE.
The process of actually obtaining this cute ESP packets is the following:
a. get the Data from the upper layers of the TCP stack – doh, we need data
b. compress the Data above using the chosen algorithm – you will notice the CPI – Compression Parameter Index – which has well know identifiers for the well known compression algorithms
c. set the Next Header value of the IPComp header to the layer 4 protocol (in this case, TCP)
d. encapsulate everything in ESP, put on the corresponding SPI, set the Next Header value of the ESP header to 108 (0x6c)
e. wrap it up in IP and… we are all set

— You can admire the ESP of IKEv1 in the screenshot attached
ipcomp

Now, what happens differently with IKEv2? I was telling you before the on Strongswan, IKEv2 and AH is a no-no for the moment, ESP with null encryption does a weird thinggie that vmp was so kind to point it out for me (while I was feeling actually quite happy about myself being able to do an IPComp test via IKEv1).
The thing is that, unlike the (correct) way of doing IPComp in IKEv1 (see the aboe a. to e. steps), IKEv2 implementation of Strongswan does a weird thing:
a. get the Data ..blah-blah
b. compress the Data with whatever compression algorithm and put on the IPComp header with CPI value and all
* c. put on another IP header (the internal one, in case of a tunnel mode scenario)
d. put on the ESP header
e. wrap everything up

— Unfortunately, you CANNOT admire the ESP of IKEV2 in a screenshot, because my current wireshark has no idea on how to do decompression of this type of packet. Once it does, I will update 🙂

Recently I’ve had the opportunity of playing a bit with a CheckPoint UTM NGX R65 – ze mighty solution from the CheckPoint guys. Ignoring the obvious impediments (Romanian posts) I had when configuring the device from GUI, it left me a nice impression.

These guys are not quite the interop gurus ever, but they strive to implement the crankiest drafts that ever appeared from IETF. Running this on my own, the interop even with this device worked well, but trying to make it work with StrongswanI’ve got into big trouble.

Why? Well, let’s take a look at the most common IPsec – IKEv1 implementations. They usually pick one/more of the following standards:

– RFC 2407

– RFC 2408

– RFC 2409

– RFC 3706 – should you like DPD – Dead Peer Detection

– RFC 3947 and RFC 3948 for NAT-T

mode-cfg-02 draft – for the most common Mode-Configuration operations (perfectly inter-operable by Cisco, Juniper’s ScreenOS, Strongswan, Sonicwall, Stoke and Clavister) – as you may have guessed, NO, NOT with CheckPoint

draft-beaulieu-ike-xauth-02 – for xAuth authentication of clients – inter-operable on Cisco, NetScreen, Stoke and Sonicwall (not sure about Clavister – haven’t tried it yet) – and, yes, not on CheckPoint

As a nice old guy would say: “Security through obscurity” , not quite my favorite idea of _security_. Still, a good to follow idea for CheckPoint. Why? Because, even though they implement the RFC 2407, 2408 and 2409, they have decided not to implement the most common xAuth draft (presented above), feeling that symmetrical authentication is just too lame, so they have implemented draft-zegman-ike-hybrid-auth-01, which defines how to do uni-directional independent authentication on the remote-access scenarios – procedure enforced by the CheckPoint VPN Client (only, if you ask me, though I haven’t tried too many others).

Once you bypass this authentication procedure, configuring the UTM to authenticate the clients using X.509 certificates, you end up in yet another dead-end: the so-called Office-Mode, which is the CheckPoint way of saying “Mode-Configuration”, with a significant difference: the actual packet exchange is not standard. We have tried, me and my programmer fellows (by the way: thanks for enduring this by my side), to “reverse-engineer” this mighty exchange, but even with the CheckPoint debug and hacking into our friend pluto, we didn’t manage to get it right.

I have talked to a tech-support guy from CKP, a very nice person, still incapable of saying anything about their solution without first asking for permission from his PM/Management/whatever. So, up until today, I haven’t been able to pull this through. This is why the things I’m going to describe below are only ALMOST CheckPoint IPsec…

(more…)