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’ve strived to implement the crankiest drafts that ever appeared from IETF. Running this on the company I work for, interop even with this device worked well (so buy Ixia products if  you want IPsec testing ), but trying to make it work with Strongswan I’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…

Read the rest of this entry »

Tags: checkpoint, cisco, clavister, DPD, HybridInitRSA, IETF draft, IKEv1, ipsec, mode-config, NAT-T, netscreen, NGX R65, office mode, PKI, Remote-Access, sonicwall, stoke, techie, X.509, xauth

Everybody loves IPsec. It does a lot of cool stuff protecting our traffic from one side to another, it is fairly easy to understand the general concept, but quite difficult to actually implement in real-life, mostly because a lot of vendors have their own idea of usability and each one has its own idea of actually implementing those numerous standards. Some of them decide to implement drafts (see Cisco, see CheckPoint) and some of them implement their own “drafts” – which makes things even more interesting.

Some other vendors decide to overcome the entire negotiation fuss and use predefined keys for the IPsec traffic, bypassing all the IKE negotiation and using manual keying. Here we have Cisco, Juniper, Sonicwall or our lovely Linux solutions.

In order to manually configure IPsec, the admin alters the SAD (Security Association Database) and SPD(Security Policy Database) databases of the device/kernel. The SAD contains specific traffic transformations, like the encryption/authentication algorithms, while the SPD indicates the traffic selectors/proxy-ids for the traffic that is to be transformed by the stuff described in SAD and indexed by an SPI.

An SAD entry would include:

• Dest IP address
• Ipsec proto (SA or ESP)
• SPI (cookie)
• Sequnce counter
• Seq O/F flag
• anti-replay window info
• AH type and info
• ESP type and info
• Lifetime info
• tunnel/transport mode flags
• PATH MTU info

An SPD entry would contain:

• pointer to active SAs
• Selector fields

***Let’s take a simple site-to-site tunnel mode case, where the security gateways are 2001::1 (local gateway) and 2001::2 (remote gateway) and the subnet behind the local gateway is 2002::/112 and the one behind the remote gateway is 2003::/112. As you can imagine, I want to encrypt traffic between 2002::/112 and 2003::/112 with aes-cbc, let’s say and authenticate it with hmac-md5.

In order to configure manual keying on linux, we need to have:

- xfrm modules in ze kernel:

xfrm4_mode_transport     1792  0

- and a small script that instructs the kernel on how to populate those two databases:

ip xfrm state add src 2001:0::2 dst 2001:0::1 proto esp spi 0×1000 enc “cbc(aes)”  0x12345678abcdef12f4f71dbccd2c1b07bce4e63b4c315414  auth “hmac(md5)” 0x012345abd9abcdeff1e0d3c2b5a4909a

ip xfrm state add src 2001:0::1 dst 2001:0::2 proto esp spi 0×2000 enc “cbc(aes)” 0xf4f71123452c1b07bce4e63b4c31541d12345678abcdef12  auth “hmac(md5)” 0x912345abd9abcdeff1e0d3c2b5a49080

ip xfrm policy add dir in src 2003::/112 dst 2002::/112 tmpl src 2001:0::2 dst 2001:0::1 proto esp mode tunnel

ip xfrm policy add dir out src 2002::/112 dst 2003::/112 tmpl src 2001:0::1 dst 2001:0::2 proto esp mode tunnel

ip xfrm policy add dir fwd src 2003::/112 dst 2002::/112 tmpl src 2001:0::2 dst 2001:0::1 proto esp mode tunnel

Tags: ipsec, linux, manual key, netscreen, sad, spd, techie

Cred ca de la CheckPoint mi se trage…si de la al lui “smart”dashboard:

Tot raul spre bine, am re-inceput sa ascult Slayer!

Oppression is the holy law
In God I distrust
In time His monuments will fall
Like ashes to dust
Is war and greed the masters plan?
The bible’s where it all began
Its propaganda sells despair
And spreads the virus everywhere

Religion is hate
Religion is fear
Religion is war
Religion is rape
Religion’s obscure
Religion’s a whore

Tags: muzica

Este vorba despre CheckPoint, care se “lauda” ca suporta Aggressive Mode. Eh, cand dau in el cu aggressive mode, face cale intoarsa si anunta glorios ca aggressive mode nu e compatibil cu IKE – adica, una din modalitatile de a face IKEv1 (proasta, cu probleme mari de securitate, dar, totusi, prezentata de RFC2408) se pare ca nu suporta IKE =))

Come on, people!!! Si ma gandesc ca oamenii _chiar_ cumpara crap-urile astea.

Tags: draci, passion, techie

better than CheckPoint – I mean

Cel putin Cisco NU ARE ZECE MII de BUTOANE! Cum are CheckPoint-ul – 10000 de butoane, care pe unde, ca sa obtii un cacat de remote-access, trebuie sa setezi stuff prin cel putin 3 locuri, nu neaparat cele mai legate intre ele, ca sa nu mai zic de intuitive.

Pui interfete, faci politici, creezi grupuri de useri si….tadaaaam – poate ai fi vrut, in marea ta prostie de user inocent si docil sa creezi si USERI!!!! AAARRRSSSHHHHH Vrei Useri, adminule? Du-te si da acatiste! Nu avem useri! Desi meniul contextul de creat useri este disponibil, daca dai click pe el, nothing happens. Of course, nici mesaje de eroare nu sunt.

De ce dracu ar vrea un adminitrator sa creeze utilizatori dupa ce a creat un grup pentru utilizatori????? Se pare ca cei de la CheckPoint considera aceasta dorinta drept exagerata. Si nu, nici manualul celor de la Syngress nu e facut la modul “Hai sa-l ajutam pe  boul de admin sa priceapa de ce are available un meniu pe care daca da click nu se intampla nimic”

Saga continua. Pe zi ce trece incep sa cred ca monsieur e un erou din benzile desenate, de s-a putut juca cu aceasta jiganie certata cu intuitivitatea si adanc infratita cu un nepot al lui Bill Gates, care are schizofrenie si crede ca ideea de butoane din Geam este prea simplista si angelica si a pus in loc un miliard de butoane si butonashe si butonele taman bune de exasperat o fiinta angelica obisnuita sa editeze rapid un fisier ASCII si sa dea restart la un demon!!!

Tags: draci, techie

Astazi s-a produs inevitabilul: a trebuit sa invat sa configurez IPsec pe CheckPoint.

Concluzia: it SUCKS!

Un GUI incalcit cu foaaaarte multe optiuni puse neintuitiv (dupa parerea mea de om care a mai configurat si NetScreen, Cisco, Sonicwall, Clavister si Stoke) – si foarte multe chestii proprietare.

Interesant e ca suporta niste feature-uri pe care le vad rar de tot, cum ar fi autentificare asimetrica sau hybrid XAuth sau lipsa unui model clar (afaik at the moment) de configurare al Identification type-ului, ceea ce mi-a placut la nebunie, dar mi-a pus probleme de interop cu alte device-uri. – probleme pe care inca nu le-am rezolvat in totalitate.

Una peste alta, daca nu era monsieur sa ma salveze, ma manca CheckPoint-ul mare si rau.

Tags: checkpoint, draci, passion, techie