Dynamic Blocklist er en kul funksjon i Palo Alto Networks, det gir deg muligheten å hente ut info fra andre tjenester som kan gi ekstra verdi til løsningen.

Du finner funksjonen her:

Her kan du legge til flere lister, i denne skal jeg fokusere på hvordan du legger inn en liste fra http://panwdbl.appspot.com/ , da spesifikt listen som blokkerer TOR Noder. Du kan legge inn flere lister om du ønsker det i ditt oppsett.

Steg 1:

Trykk på “Add” og legg inn listen, jeg har valgt “Daily” på repeat, som betyr at listen vil oppdatere hver dag klokken 00:00. Dette kan endres til 5 min, Hourly, Daily, Weekly og Monthly.
I dette tilfellet er daglig bra nok.

Når du har trykket på OK så er listen laget, og den vil bli hentet ned så fort du har kjørt en commit på konfigurasjonen.

Steg 2:

Lage en regel for å blokkere trafikken, dette bør være enkelt for de fleste.

På source legger du sonen som er internett, for meg er det “Untrust_L3”, og under Source address legger du inn listen du lagde i steg 1.

Resten setter du til Any, utenom Destination hvor du velger de sonene du vil beskytte med denne regelen.

Sist er å sette Deny på action, og legge regelen så høyt du kan i regelsettet.

Commit, og du er beskyttet mot angrep fra TOR Exit noder.

PS: Mitt GUI ser annerledes ut siden jeg kjører PANOS Nagoya 7.1 Beta.

Håper også alle får ett godt PANÅR!

 

 

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.

Her er en rask guide på hvordan man kan konfigurere opp GlobalProtect på nettlinjer med dynamisk IP, jeg har satt opp dette for å koble meg på nettet mitt hjemme for å administrere … trafikk på internett.. (Vi holder oss til det).

Det første valget jeg tok var at jeg ikke ville sette en fast IP på interfacet mot internett, da jeg har Get hjemme og de er notorisk ustabile, og jeg får da ofte ny IP.
Valget ble da å bruke loopback interface for GlobalProtect portal og Gateway, vi kan da bruke statiske IPer og eneste vi må endre når vi får ny IP er “External Gateway” som vi kommer til senere.

Steg 1:

Opprette loopback og tunnel interface for GlobalProtect Gateway og Portal.

Mitt ble “loopback.1” og jeg satt en RFC1918 adresse der. Dette blir IPen vi bruker både for Portal og Gateway.

NB! Husk og lag en Managment profil for Interfacet som tillater HTTPS!

Så må vi opprette ett “tunnel” interface som blir interfacet der VPN-trafikken kommer ifra.

Jeg kalte mitt bare for “tunnel.1” enkelt og greit. Security Zone er viktig å tenke igjennom også, dette definerer hvilken policy VPN klientene skal få. I mitt tilfelle assignet jeg den til “trust” sonen som er mitt interne nettverk.
Anbefalingen min er å opprette en egen VPN-sone som man kan ha kontroll på, men dette var ett raskt oppsett for å vise hvordan det gjøres.

Steg 2:

Opprettelse av sertifikater

Først oppretter du ett Selvsignert ROOT CA ved å gå på “Device – Certificates – Generate”.

Jeg pleier å sette IPen til MGMT i Common Name feltet, krysser så av for “Certificate Authority” og trykker Generate. (Hva du gjør med Bits og digest er opptil deg).

Deretter trykker du på “Generate” igjen for å lage ett sub-sertifikat til ROOT CA.

Her har jeg kalt sertifikatet for “IPSEC Sertifikat” for å ha kontroll på hva det skal brukes til, under “Common Name” legger du inn IPen til utside interfacet.
Det viktigste er å velge ROOT CA under “Signed by” og deretter trykk “Generate”.

Gratulerer, du har nå laget en gyldig sertifikat kjede!

Steg 3:

Konfigurere GlobalProtect Portal

Under Network Settings ser du at vi har valgt loopback interfacet og Ipen vi laget tidligere. Vi har også valgt ett SSL sertifikat (Ignorer at det er ett annet enn jeg lagde som eksempel..) som blir det sertifikatet som presenteres til klienten når vi kobler oss mot Portalen for autentisering.

Authentication definerer opp hvordan brukere skal koble seg opp, jeg har laget en rask Auth-profil som jeg ikke dekker i denne guiden. Min bruker lokal database for brukernavn og passord, men man kan bruke LDAP, RADIUS med mer for autentisering. Jeg valgte og heller ikke kreve sertifikat fra klienten, da jeg ønsker å koble meg på fra mange forskjellige klienter.

Appearance handler om ut seende på login siden, her har jeg gått fullstendig standard.

Under “Client Configuration” kan man lage forskjellige konfigurasjoner for brukere.. Jeg har kun laget en da jeg kun har min egen bruker å tenke på.

Man kan definere opp om brukere skal få bruke SSO(Må være medlem av ett domene for at det skal fungere), og hvordan VPN-klienten skal oppføre seg. Jeg har valgt “on-demand” slik at jeg kan koble av og på slik jeg vil.
Resten av funksjonene her er selvforklarende.

Under Gateways definerer man opp Internal og External Gateways. Siden vi kun skal bruke VPN på maskiner utenfor nettverket vårt, så definerer jeg kun opp en External Gateway her. Hele poenget med denne funksjonen er at Portalen skal ha kontroll på alle mulige VPN endepunkt, og kan sende deg til den som gir best respons og ytelse. Men når vi kun har 1 portal og 1 gateway så blir det seende slik ut.

Under Agent kan vi konfigurere opp hva som er lov og ikke lov å gjøre med VPN-klienten, jeg har gitt meg selv alle tilganger, men her kan man leke litt med innstillingene. Det er også støtte for andre VPN-klienter.

Steg 4:

Konfigurere GlobalProtect Gateway

Vi velger akkurat de samme innstillingene som vi gjorde på GlobalProtect Portal, da kjører både Portal og Gatewayen på samme ip.

Under Client Configuration velger vi hvordan klienten skal kommunisere med GlobalProtect gatewayen. Her velger vi da tunnel interfacet vi laget tidligere ellers lot jeg innstillingene stå som standard.

Under Network Settings definerer vi opp DNS, WINS og IP-Pool for VPN-klientene. Vi definerer også opp Access Route for VPN-klientene, jeg ønsket at all trafikk skal gå via VPN og har da satt 0.0.0.0/0 for å oppnå dette. Om man f.eks kun ønsker tilgang til en filserver hjemme og, resten skal gå over lokal breakout så definerer man f.eks bare opp 192.168.1.0/24 her. Da vil alt annet gå ut lokalt.

Når du nå trykker OK så har vi en fullverdig konfigurasjon for GlobalProtect. Men siden dette er knyttet opp mot ett internt interface, så må vi gjøre noe med Policy!

Steg 5:

NAT-policy

Her har vi min NAT regel for å gi tilgang til GlobalProtect Portal og GW.

FW-Policy

Her har vi min FW regel for å tillatte globalprotect trafikk over https.

Kjør en Commit, og gå deretter mot din eksterne IP over HTTPS og få følgende vindu:

Logg inn og du får muligheten til å laste ned klienten

Last ned den som passer til ditt OS og installer klienten.

I klienten taster man brukernavn og passord som man har definert opp og får opp følgende vindu om alt har gått bra:

Du er nå ferdig og kan nyte tilgangen til ditt private nettverk! 🙂

 

 

Jeg fikk ikke vært på BlackHat i år, men nå har det sluppet mange av presentasjonene som var der.

Anbefaler alle å ta en titt, da det er mye spennende lesning for oss som er interessert!

Samling av BlackHat presentasjoner

Jeg synes disse var særlig spennende:

What got us here, won’t get us there! – Diskuterer måten vi jobber på nå ikke vil fungere i fremtiden.. (Helt enig! )

How to manipulate oil stocks – Hvordan man kan manipulere olje aksjer!

Oppsummert så er det nok mennesker der ute som tester sikkerheten til verdens bedrifter på en daglig basis.. tør du å havne på en BlackHat presentasjon neste år?

Det kommer ett webinar om hvordan Paloalto og Splunk sammen kan gi deg en sikrere IT hverdag!

Anbefaler alle å bli med på webinaret, det kan ikke bli annet enn bra når 2 ledende teknologier i sine markeder samarbeider!

Påmelding finner du her: Webinar Paloalto + Splunk

Paloalto sin løsning for endepunkt har nå kommet i versjon 3.3!

Og listen med nye funksjoner og endringer er lang!

Du finner den her: Release Notes Traps 3.3

Kort oppsummert er de største nyhetene dette:

• Windows 10 support (32/64 bit)
• FIPS Sertifisert på alle OS unntatt XP og Server 2003
• Direkte rapportering i Traps av falske positive, med e-post rapport tilbake
• Mer granulær policy
• Bedre støtte for VDI løsninger
• Bedre rapportering til brukeren når blokkering skjer

Jeg anbefaler alle å lese igjennom rapporten som har kommet fra “Cyber threat Alliance” der Palo Alto Networks med Unit 42 er medlem.

I korte trekk har Cryptowall gjort stor skade, og dette vil mest sannsynlig føre til bedre kampanjer med bedre infrastruktur for å hente inn enda større beløp.
De har nå funnet ut at det er mer effektivt å skade data, enn å stjele dem. Viktigheten for å introdusere gode sikkerhetsmekanismer er nå enda større!

Link til rapport finner du: HER