Dynamic Blocklist – For å stoppe TOR Noder!

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:

blogg_dynamic_01

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:

blogg_dynamic_02

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:

blogg_dynamic_03

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

blogg_dynamic_04

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.

blogg_dynamic_05

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!

 

 

Posted in Uncategorized | Leave a comment

IPSec VPN Guide med Loopback interface

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:

blogg_ipsec_loop_01

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.

blogg_ipsec_loop_02

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: 

blogg_ipsec_loop_03

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:

blogg_ipsec_loop_04

Lykke til!

Posted in Uncategorized | Leave a comment

IPSec VPN Guide

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.

blogg_ipsec_01

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

Steg 2: 

blogg_ipsec_02

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:

blogg_ipsec_03

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:

blogg_ipsec_04

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.

blogg_ipsec_05

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:

blogg_ipsec_09

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:

blogg_ipsec_06

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.

blogg_ipsec_07

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:

blogg_ipsec_08

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:

blogg_ipsec_10

(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!

 

 

Posted in Uncategorized | Leave a comment

Live fra ett hotellrom i Amsterdam..

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!

Posted in Uncategorized | 1 Comment

Quick and Dirty

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?”.

blogg_acc_risk_factor

ACC Risk Factor i Arrow sin LAB

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.

Posted in Uncategorized | Leave a comment

Oppsett av GlobalProtect for hjemmebruk!

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.

blogg_gp_17

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!

blogg_gp_16

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

blogg_gp_14

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”.

blogg_gp_10

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.

blogg_gp_11

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

blogg_gp_2

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.

blogg_gp_3

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

blogg_gp_4

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.

blogg_gp_5

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.

blogg_gp_6

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

blogg_gp_7

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

blogg_gp_8

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.

blogg_gp_9

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

blogg_gp_12

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

FW-Policy

blogg_gp_13

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:

blogg_gp_15

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

blogg_gp_18

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:

blogg_gp_19

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

 

 

Posted in Uncategorized | Leave a comment

BlackHat Europe – Presentasjoner

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?

Posted in Uncategorized | Leave a comment

Webinar om Paloalto + Splunk!

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

Posted in Uncategorized | Leave a comment

Traps versjon 3.3 lansert!

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
Posted in Uncategorized | Leave a comment

Cryptowall rapport

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

Posted in Uncategorized | Leave a comment