Intamplarea face ca in Berlin, azi e prima zi dintr-o saptamana dedicata comemorarii istoriei acestui oras. CheckPoint Charlie, Zidul Berlinului, Reichstag-ul…peste tot sunt afise si postere cu date din vremea lui Hitler si pana in 1989.

[Show as slideshow]

123►

Chiar la coltul hotelului este un restaurant minunat. Tot ce pot spune la ora asta este ca au un Pinot Noir Rose ex-ce-lent

[Show as slideshow]

===========================================================================

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

Dupa o seara intreaga de discutat, am reusit sa-l intreb de ce in Global Properties for Manual NAT Rules mai exista bifa de “Translate Destination on client side” – atata vreme cat oricum asta e default si asa se face cel mai bine si “cel mai mereu”.

Cum nu a stiut…I got pupic.

Problema cu acest concurs este insa urmatoarea: de cand ma joc cu CheckPointu’, si tiranul functioneaza ca un Security Policy: what is not explicitly permitted is implicitly dropped. Deci trebe sa gasesc multe chestii pe care nu le stie Asta la omul care probabil stie CheckPoint cel mai bine in tara asta

Hard times ahead

Oameni de tot felul, de la VP, CEO si Purchase Managers pana la preferatii mei: Network Engineers, Product/Project Managers, Sys Admins, Security Consultants si mai ales Pen Test Specialists. Lumea s-a minunat de solutiile companiei noastre, mai ales ca multi nu stiau de existenta noastra ca si companie. Si mi-a placut ca am avut si eu ocazia sa prezint plugin-ul de VoIP unui nenea care stia VoIP la modul serios. De la astia are valoare feedback-ul si se pare ca facem o treaba foarte buna. Acum, mnah, sper sa si cumpere !

Alte chestii, mai marii in ITSec au cam fost prezenti. Sophos au avut un stand super misto, Qualys a bagat muzica si bautura si s-a strans lumea, WebSense au avut stand misto, RSA -ul cam slabuti, Intel-ul s-a bagat la cutie intr-un stand mic, prezentand doar ceva foarte vag despre solutia lor de Cloud.

Uitai taman de CheckPoint. Am vazut si eu DashBoard-ul de la R75 – cik au per user policy rules prin integrarea cu AD

Unii vizitatori veneau cu CV-ul si intrebau daca nu avem job-uri libere. Altii doar cascau gura. A fost faina ideea vecinilor nostri de stand, al caror nume nu mi-l amintesc spre rusinea mea: au venit toti in tricouri galbene pana peste fund, cu desene cu chiloti pe ele; mesajul era:

Passwords&Underwear: 1. Do not borrow them, 2. Do not expose them, 3. Change them frequently

- sau ceva pe-acolo, dar au fost funny tare

Din pacate, am uitat acasa camera foto, dar sper sa apara ceva poze de la colegi, in curand

In afara de asta (dar mi se tot confirma zi de zi), am feedback-ul constant ca evreii astia, cel putin cei din IT, sunt si foarte destepti si foarte bine facuti si au mare grija de ei. Firma in care am fost e plina de geeks, dar vorbesc cu ei in pauza de masa, sunt super funny, culti, simpatici si arata super bine. Femeile in schimb sunt …plinute. Eu nu pricep cum de se poate asta. Astia sunt toti cu fitness-ul, cu mountain bike-ul, cu alergatul, cu artele martiale, iar femeile/fetele sunt super plinute. Sau..hm..poate asa le place lor. Nu zic nici 40kg si pitzi, da’ nici 70kg la 1.60 inaltime. Acum ca am rezolvat cu dilemele existentiale despre ce nu ma priveste pe mine din cultura altor popoare…sa revenim la chestii mai interesante.

In seara asta am reusit sa ies la “un suc” cu o amica din Tel Aviv, romanca, mutata aici de vreun an jumate. Asa am avut si eu ocazia sa bag ceva specific lor. Se numeste sahlab (ei il citesc cam ca “sahlep”) si e un fel de desert cu gust de nuca de cocos si apa de trandafiri si cu un gust fin de scortisoara, cu consistenta de gris cu lapte, dar ceva mai moale, se serveste cald, cu croncanele si diverse alte chestii in el. L-am mancat cu lingurita si a fost GENIAL. Abia am reusit sa termin (la astia toate portiile sunt foarte mari ! ) si cred ca am contorizat vreo 2000 de calorii , eh, lasa ca dupa cat am facut foame in State, acum primesc recompensa cu mancare super buna si dulciuri si mai si.

Poza la sahleb asta:

In rest, se pare ca Tel Aviv-ul e un oras super civilizat si sigur, in care te poti plimba lejer noaptea fara teama ca te ataca cineva, cum ar fi in Ferentari (si eu si amica mea am locuit ceva timp in Ferentari, deci stiu ce zice ). Bine, ce dume au ei cu vecinii e partea a doua, dar in rest lumea e super misto, sunt foarte civilizati, draguti si destepti si au cea mai misto vreme din lume. Daca nu ar fi chestia cu vecinii, aici mi-as dori sa ma mut.

Si ca second line, azi am cunoscut un nenea super smecher. Pentru cei care mai sunt cu calculatoarele, e vorba de nenea care a facut capul calendar celor de la Microsoft pe tema problemei cu StuxNet, anume Tomer Teller. Care aflu acum ca are si nush ce patent pe security. Omul e tare si colegul meu mi l-a prezentat si m-a sfatuit sa fac bine sa ma port frumos ca nu se stie niciodata, pana la urma, inca mai folosesc Windows

Eu sunt happy. Sper sa tin legatura cu lumea, ca astia majoritatea sunt super doxa si am ce invata de la ei

- hotel super curat, angajati super misto, foarte politicosi si atenti; oricum, e foarte curat peste tot pe-aici

- maniaci cu “reset to defaults”: imi asez oglinda din baie cum vreau, imi pun lucrurile aiurea, cand revin seara in camera totul e reset la defaults, totul e super aranjat si dichisit, ma enerveaza pana si pe mine atata ordine

- de dulciuri nici nu mai are sens sa comentez

- cafeaua e foarte naspa, cam pe oriunde pe unde am fost pe-aici au un fel de cafea facuta la ibric, dar fac ceva naspa, ca nu le iese buna deloc – sau poate nu am eu gustul cum trebuie; mi-e dor de mers la Starbucks cu tiranul

- trebe musai sa ies sa fac poze prin jur; au 2 parcuri mari in apropiere si cik 15 minute cu masina pana la mare

- maine au inchis peste tot la hotel, in termeni de : nu mic-dejun, nu gustari in business lounge, nu restaurant deschis pentru cina; eu nu pricep cum in zi de “sarbatoare” oamenii fac foamea; sau poate doar eu o sa fac foamea :-s

- israelienii ma enerveaza oficial: sunt prea tari la capitolul IT retelistica, retele mobile, radio, securitate, securitate pe retele mobile, telefonie, etc etc etc; tipul cu care lucrez eu a fost in CheckPoint si in Cisco; I am like: ^:)^ ^:)^ ^:)^

- mi-e frica sa nu-mi scape de draci vreo injuratura urata in romana, ca foarte multi inteleg limba romana; cei care au rude din Romania se straduiesc sa-si ia cetatenie romana, ca sa poate sa isi trimita kinderii la scoli in Europa si/sau eventual sa o taie si ei acolo; ei zic ca orice evreu are un “Plan B” – intotdeauna .   ?

- mi s-a oferit, mai in gluma, mai in serios, un post pe wireless

- inapoi in tara sper sa-mi iasa faza cu cersitul de bani pe la companiile mari; m-au sunat unii (nu zic care, inca), dispusi sa ma sponsorizeze cu doctoratul; sa vedem si ce vor la schimb; nu prea as vrea sa plec din firma de acum, macar aici invat tehnologie ca lumea

- mi-e foarte ciudat ca nu pricep bob din ce scriu/vorbesc oamenii astia; daca mai ajung pe-aici inca o data, ma apuc de invatat ebraica; ma rog, majoritatea celor cu care am eu de-a face sunt rusi, de capul lor; deci, cand nu le iese pe ebraica, o dau pe rusa; apoi pe engleza, apoi pe rusa, apoi iar pe ebraica; ceea ce e bine, constat ca termenilor IT tot pe engleza le zic; in Franta sa fi fost, atunci sa vezi distractie; v-am spus ca-s foarte tari la tehnologie?

- fac dulciuri foarte bune

Later Edit:

DA, si astia de la hotel baga muzica super misto. In afara rarelor cazuri cand baga muzica de-a lor, la micul dejun, cina si in business lounge se asculta jazz, rock classic, muzica frantuzeasca din anii 80.

Azi la micul dejun au pus niste preferati de-ai mei mai vechi: Staind – It’s been a while.

[youtube]http://www.youtube.com/watch?v=wVC1iBVnKJk[/youtube]

Iar colegii de la firma baga metale

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:

# 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 ). Cisco on 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

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

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…

So, once you have installed NGX R65 (of course, I only  had a trial version), define a main interface, generate a self-signed certificate for the UTM, and allow GUI clients to administer the device via SmartDashboard:

1. Open SmartDashboard > Network Objects > CheckPoint > double-click the name you gave to the current UTM (mine is CKP-R65) > General Properties > check the VPN box under “Check Point Products”

still on CKP-R65- > under Topology tab, Edit the networks there as to identify as “This network” the main IP address, the one you bound to the RSA, and put the secondary one (of course, you’ve defined a secondary one) as “External”

still on CKP-R65- > under VPN tab, Add “Remote Access” to the upper Area, stating that “This module participates in the following VPN Communities”

still on CKP-R65- > under Remote Access > under Office Mode I have checked the “Do not offer Office Mode” option

Hit OK, then go to Menu > Policy > Install Database… and install it on the UTM.

2. In the main Dashboard window > Network Objects > right-click on Networks > Create new network, give it a name and then configure it. This shall be the Remote-Access pool for Office Mode (which we won’t do, cuz we don’t get till there with pluto)

3. In the main Dashboard window > (fifth tab) Users > right-click Users Group, create a new group, then right-click on Users and create a new user, assigning it to the previously created Remote-Access group

4. Now would be a good moment to save everything on the UTM > Install Policies.

5 – version 1. What I’ve done next is to create a new (external) CA (which is a 2003 Server CA I had at hand), enroll the CheckPoint to this CA and try to create a user certificate for my CheckPoint user. I thought of exporting this user certificate on my Strongswan and authenticate it to the gateway. Unfortunately, I’ve seen no way of indicating to which CA the user certificate gets enrolled – the user certificate I have created from the user page always got enrolled to the CheckPoint’s self-signed CA – not exactly what I had in mind

5 – version 2. I have done some more reading on the Internet, and found a procedure of actually exporting the CheckPoint’s self-signed cert from the UTM, to a p12 file. God-like! I have exported the CKP-R65′s certificate, then put it under the …/ipsec.d/cacerts directory on debian. This way, it seems that strongswan passes the authentication stage – still not hybrid, but still authentication

[Show as slideshow]

My Strongswan machine has an IP address (20.0.0.2) and tries to do Remote-Access to the CheckPoint. The Strongswan config looks like this:

having ipsec.secrets:

: RSA /usr/local/etc/ipsec.d/private/user1_key.pem “password”

Now, the solution may seem simple, BUUUT:

a. CheckPoint does not want to use its DNS name as Identification Payload for IKEv1 for the Remote-Access scenarios

b. Also, the certificate cannot be generated for external networks, so there has to be 10.205.17.251.

c. ALSO, although not recommended for security purposes, even if I configure Strongswan to identify the DUT per its 10.205.17.251 IP address, still I get the INVALID_KEY_INFORMATION error.

*** Now, should any one of you nice readers have solved this scenario and actually get a CheckPoint device to work with another solution (not necessarily open-source), please have mercy on my poor soul and let me know

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

[youtube]http://www.youtube.com/watch?v=GZSbIwE_BKM&feature=related[/youtube]

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