MERK: Husk å lage en policy som tillater UDP 500 / 4500 mot ytre interface på brannmur for å få opp tunnelen.

Hjemme på min PA-200 har jeg DHCP på WAN interfacet, det gjør det litt verre når jeg skal sette opp IPSec på min side mot LABen på kontoret.

Men det lar seg løse med loopback, og her er hvordan:

Steg 1:

Lag ett loopback interface, velg VR og en sone. Jeg brukte trust her, for å holde det enkelt. I produksjonsmiljø vil jeg absolutt skille ut VPN trafikk i en egen sone.

Gi den en IP, her igjen bruker jeg bare en RFC1918 adresse, det er fordi jeg kun har en offentlig IP med mitt Get abonnement. ( 🙁 )

Steg 2: 

Lage en NAT regel som gjør at loopback interfacet blir nåbart fra internett på de riktige portene. Jeg laget en ny service som inneholder UDP 500 og 4500 som er nødvendig for IPSec.

Utgående trafikk blir tatt av min generelle NAT regel for utgående trafikk. Det kan hende dere må lage en spesifikk for deres miljø.

Etter at det ble gjort så fikk vi følgende resultat på IPSec tunnelen:

Lykke til!

Rask guide for hvordan man setter opp en Site 2 Site VPN med Palo Alto.

Her har jeg brukt 2 stk Palo Altoer, men det bør være ganske forklarende for hvordan man gjør det med andre løsninger. Hvis ikke så er det bare å ta kontakt, så hjelper jeg deg!

Steg 1:

Lage en egen Sone for VPN-trafikken, slik at man kan lage egen policy for trafikken.

Her har jeg bare kalt den “IPSec-VPN”.

Steg 2: 

Laget ett tunnel interface som VPN-trafikken skal gå igjennom. Her kan man kun differansiere på tallet etter tunnel. Her har jeg bare tatt “2” siden det var ledig. Mange velger ofte nest siste oktett i nettet som skal deles for å ha kontroll.

Velg hvilken VR den skal knyttes til, og hvilken Sone. Her bruker jeg Sonen jeg laget i Steg 1. Da vil all trafikk som treffer VR “Default” fra dette interfacet bli klassifisert som “IPSec-VPN”.

Steg 3:

Nå Som vi har laget sonen og interfacet, så må vi definere kryptografien som skal brukes ved IKE-forhandlingene. (Phase 1 IPSEC)

DH Group gir følgende valg:

• DH Group 1: 768-bit group
• DH Group 2: 1024-bit group
• DH Group 5: 1536-bit group
• DH Group 14: 2048-bit group
• DH Group 19: 256-bit elliptic curve group
• DH Group 20: 384-bit elliptic curve group

Encryption gir følgende valg:

• 3DES
• AES-128-CBC
• AES-192-CBC
• AES-256-CBC

Authentication gir følgende valg:

• MD5 (Utdatert, ikke bruk!)
• SHA1
• SHA256
• SHA384
• SHA512

Merk at man kan definere flere valg i hver seksjon, Palo Alto vil da prøve fra toppen og nedover helt til den finner en som fungerer mot motparten.
Her har jeg kun definert 1 i hvert felt siden jeg har kontroll på begge endepunktene.

Steg 4:

Når vi har definert kryptografien som skal brukes ved IKE så må vi opprette Gatewayen som skal svare eller sende ut forhandlingene.
Dette må være ett interface som er nåbart fra internett, og kan også være ett loopback interface. Du definerer dette under “Interface” og “Local IP Address”.

Peer IP Address er som navnet tilsier, adressen til motparten.

På Authentication bruker jeg “Pre-Shared Key” som man blir enig med på forhånd med motparten.

Under Advanced Options så definerer du profilen vi laget i Steg 3.
Her har du også ett par andre opsjoner som kan være aktuelle for deg og ditt oppsett. Trykk på (?) i hjørnet om du er i tvil på hva noen av disse gjør.

Steg 5:

Nå som vi er ferdig med å definere opp IKE(Phase 1 IPSec) så må vi definere opp IPSec tunnelen.
Først må vi definere kryptografien om brukes for selve tunnelen.

IPSec Protocol gir følgende valg:

• ESP
• AH

MERK: Bruker man ESP er det strengt tatt ikke nødvendig å velge noe på authentication.

DH Group gir følgende valg:

• NO-PFS (No perfect forward secrecy)
• DH Group 1: 768-bit group
• DH Group 2: 1024-bit group
• DH Group 5: 1536-bit group
• DH Group 14: 2048-bit group
• DH Group 19: 256-bit elliptic curve group
• DH Group 20: 384-bit elliptic curve group

Encryption gir følgende valg:

• 3DES
• AES-128-CBC
• AES-192-CBC
• AES-256-CBC
• AES-128-CCM
• AES-128-GCM
• AES-256-GCM
• NULL

Authentication gir følgende valg:

• MD5
• none
• SHA1
• SHA256
• SHA384
• SHA512

Så da er det bare å velge det man har blitt enig med motparten, og lagre profilen.

Steg 6:

Deretter må vi sette samme alt vi har definert tidligere.

Her definerer vi bare opp alt vi har laget i de tidligere stegene.
Om man ønsker å ha en Tunnel monitor aktiv, så må man definere en IP adresse under tunnel interfacet, som kan brukes til å sende ICMP pakker. Dette er også en god måte å sikre at tunnelen alltid er oppe.

Proxy IDs kan brukes mot andre leverandører som f.eks bruke Policy Based VPN, kontra Route based VPN som Palo Alto Networks bruker. Du kan lese mer her: https://live.paloaltonetworks.com/t5/Learning-Articles/Proxy-ID-for-VPNs-Between-Palo-Alto-Networks-and-Firewalls-with/ta-p/54859

Steg 7:

Som sagt så er Palo Alto Networks route basert, så derfor må vi lage en route som peker mot tunnel interfacet og nettet du skal ha tilgang til på andre siden av tunnelen.

På Next Hop velger du “None” som betyr at pakkene bare blir kastet over også får motparten ta seg av routingen.

Trykk OK og “Commit”.

Om alt er konfigurert riktig på motparten vil du få fine grønne lys i denne oversikten her:

(Min blir grønn i morgen når jeg får konfigurert opp hjemmeboksen min.. 🙂 )

 

Gratulerer, du har nå opprettet en IPSec Site 2 Site tunnel!

 

 

Målet mitt med å bytte jobb til Arrow var å få kunne jobbe mer med Palo Alto Networks, og deres løsninger.
Og en av mine første mål er å bli instruktør, slik at jeg kan spre de glade budskap videre i Norge!

På veien til det målet må jeg gjennomføre 201 og 205 kurset som går ut på oppsett og drift av Palo Alto Networks PAN-OS.
Derfor er jeg denne uken i Amsterdam på Partner trening i hovedkontoret for Palo Alto Networks i EMEA.

Det var her i samtale med de andre som deltar på kurset at det gikk opp for meg.
At jeg aldri hadde tenkt på hvorfor jeg ble så overbevist av Palo Alto Networks sine løsninger.

Så hvorfor ble jeg det? Hvorfor valgte jeg å bytte jobb fra ett sted jeg trivdes kjempegodt? Kun for ett produkt?

Men når jeg fikk tenkt meg om, så var det ikke så rart..
Jeg har de siste 3,5 årene jobbet med diverse løsninger for nettverk sikkerhet, og ofte var det “best of breed” innenfor områder som proxy, apt-deteksjon, antivirus, url-filter, brannmur og SSL-dekryptering.
Om man har 3-4 av disse i løsningene i nettverket så oppnår man ett godt nivå av sikkerhet, men det gir også noen problemer:

• Policy for nettverket blir spredt over flere løsninger fra forskjellige leverandører
• En GUI for brannmur, en GUI for APT-deteksjon, en GUI for proxy osv osv..
• Vanskelig å feilsøke
• Krever flere ansatte \ Mye opplæring for å kunne vedlikeholde løsningene
• Forskjellige support-rutiner når noe går galt. Noen må holde kontroll på dette.
• Oppdateringer av alle løsningene, som ofte sklir ut og man kjører usikre versjoner.
• Ingen utveksling av informasjon mellom løsningene
• Ingen god måte å få ett komplett overblikk av nettverket

Det jeg savnet var en løsning som kunne gi meg ett totaloverblikk over nettverket, uten at jeg måtte hoppe mellom 3-4 eller 5 forskjellige GUIer..

En liten periode trodde jeg dette var Checkpoint, som lovet brannmur, antivirus, IPS, URL-filter, Proxy, application-control, Anti-bot ++++. Dette virket jo fantastisk!
Men så begynner man å jobbe med produktet, og det hele rakner etter en stund.

• Ingen felles policy enda alt er i samme løsning. Man ender med å hoppe mellom “Blades” og definere forskjellige policyer
• Trenger egen management applikasjon for å gjøre endringer på policy, mens nettverk defineres på Web-GUI. Fragmentert administrasjon.
• Ingen rød tråd i hvordan “blades” konfigureres eller settes opp. Ett godt eksempel er Mobile Access blade som mangler enkel søk funksjon for hoster, som fører til at man må bla igjennom lange lister. Og slike forskjeller er det igjennom hele management applikasjonen..
• Ingen mulighet å bygge en firewall policy basert på applikasjoner og porter. Dette gjøres i 2 forskjellige policyer. (Vet at R80 kommer, men det er fortsatt avhengig av application blade)
• IPS-funksjonalitet som er satt opp som standard for å gi mest mulig ytelse fremfor beskyttelse. Til og med “Recommended Profiles” deaktiverer IPS-signaturer som krever for mye ytelse…
• Ytelse.. alle som har jobbet eller jobber med checkpoint har angst når det kommer til dette. Checkpoint slår seg på brystet med vanvittige ytelsestall med kun FW aktivert, men så fort man slår på noe mer så går dette tallet rett i bakken. Aktiverer man f.eks IPS så ser man som oftest 90% ytelsestap, da er det ikke så mye rom for å aktivere Application Control, SmartEvent, Mobile Access, Anti-Bot med mer..
• Og når en checkpoint boks sliter med ytelse, så går dette også utover administrasjon. Ingenting er som å pushe policy på en boks med 90% CPU.. Kaffen venter!
• Ikke spesialisert hardware. Kjører på x86 CPU som gjør at eneste måten for å oppnå høyere ytelse er høyere kjernefrekvens og flere kjerner.
• Oppgradering.. aldri enkelt med Checkpoint. Som oftest løste vi det med å slette alt og reinstallere da det bød på mindre problemer.
• Doktorgraden man må ha for å skjønne Checkpoint lisensiering

Og det er sikkert mer, som dere skjønner er jeg ikke så glad i Checkpoint. Når jeg som tekniker bruker mer tid på å komme meg rundt problemer, enn å faktisk sikre nettverket så blirt det fort sånn..

Så kom Palo Alto Networks på banen, jeg hadde hørt om dem, men enda ikke hatt mulighet til å jobbe med dem. Det endret seg i slutten av 2014.
Jeg var skeptisk, og tenkte at dette var samme visa som Checkpoint, masse lovnader i en powerpoint, der vi alle kan være best. For så finne alle feilene og problemene i praktisk bruk.

Men, det første som møtte meg var ett utrolig bra Web-GUI som ga meg alt jeg var ute etter.

• En policy for hele nettverket (User-ID, App-ID, Content-ID med mer i en og samme policy!)
• Lag 7 Inspeksjon innebygget! (Kan ikke deaktiveres!)
• FPGA for å skanne trafikken i en Singel-Pass
• Control-Plane for administrasjon, er separert fra Data-Plane som tar seg av trafikken. Dette sikrer at boksen fortsatt føles rask enda man har høy load.
• Enkle ytelsestall og forholde seg til. 2Gbit\s med kun Applikasjonskontroll, 1Gbit\s med Threat Prevention pakken. Enkelt å planlegge rundt.
• Gir full synlighet i nettverket. Endelig ser man applikasjoner, og ikke bare porter.
• Wildfire som stopper ukjente trussler, med kun 15 minutter oppdateringsfrekvens fra skyen
• Pluss masse masse mer…

Nå er vi i slutten av 2015, og jeg sitter på ett hotellrom i Amsterdam. Kun fordi jeg er like frelst, og jeg gleder meg til fortsettelsen!

Alle som ser ett Palo Alto GUI for første gang, biter seg alltid fast i denne.. “Hva er det? Er ikke det høyt? Den er jo oppe på det røde?”.

Så hva betyr den egentlig?

Palo Alto Networks klassifiserer applikasjoner fra 1(lav) til 5(høy) i risiko, og det eneste ACC Risk Factor viser er snittet av alle applikasjonene som går over nettverket ditt de siste 60 minuttene.

Så om man logger på klokken 04:00 om natten så vil de ofte se mye lavere ut, da det da går svært lite klient-trafikk over nettverket.