WildFire i EU!

Palo Alto Networks har nå lansert WildFire i Europa! Datasenteret står i Amsterdam og gir oss i Norge følgende fordeler:

  • Mindre latency og høyere hastighet
  • De som håndterer data og drift er ansatt i ett eget selskap opprettet i EU, og de kommer alle fra EU land.
  • Kundedata forlater aldri EU, og er derfor underlagt EU sin lovgivning
  • Gratis å bytte til EU tjenesten

Så det er bare å bytte over!

Steg 1:

wf1

Logg på brannmuren gå deretter til Device -> Setup -> Wildfire. Trykk på konfigurasjons hjulet.

Steg 2:

wf2

Endre URL fra wildfire.paloaltonetworks.com til eu.wildfire.paloaltonetworks.com. Trykk OK.

Steg 3:

Commit. Du er nå tilknyttet skyen i EU!

 

NB! Alt av rapporter kommer nå også på https://eu.wildfire.paloaltonetworks.com, gamle rapporter blir liggende på gammel URL.

Posted in Uncategorized | Leave a comment

File Blocking – Bruker du det fortsatt ikke?

Jeg hadde ett innlegg om File Blocking i PAN-OS i fjor, som du kan lese her.

Kort oppsummert så ville jeg vise styrken til funksjonen da, nå vil jeg vise styrken til plattformen!

fb1

Vi logger inn på brannmuren, og hoppe til “Objects->File Blocking”, trykker Add for å lage en ny profil.

fb2

Eksemplet mitt er enkelt, men her kan man legge inn det man ønsker å blokkere fra de litt mer usikre sidene ute på internett.
For de som også lurer så dekker begrepet “PE” eller Portable Executable følgende filtyper:  exe, dll, com, scr, ocx, cpl, sys, drv, tlb.

For en fullstendig oversikt over alt som kan blokkeres se her.

Trykk OK for å lagre profilen. Neste steg er å definere en regel.

fb5

Her ser du en regel der vi tillater all trafikk, men med File Blocking profilen definert. Det betyr at vi her blokkerer alle PE filer til og fra internett. Bra for sikkerheten, men det vil nok ikke fungere i praksis. Hva kan vi da gjøre?

fb4

Innenfor sikkerhet så handler det mye om å scanne, detektere og rapportere, men det er vel så viktig å minske angreps flaten.

Og om det ikke lar seg gjøre å blokkere alle PE filer til og fra internett, så kan vi iallefall stoppe de som kommer fra de mindre sikre URL kategoriene. Kategorien “unknown” er mitt eksempel da dette er en av de litt mer usikre kategoriene som mange tillater, da alle nye domener og sub-domener havner her før de blir kategorisert for første gang.
De mer ondsinnede kategoriene er forhåpentligvis allerede satt til block, så da er det ikke nødvendig å inkludere dem i denne regelen.

Andre URL-kategorier som dere bør vurdere å gjøre det samme om de ikke er blokkert er:

  • dynamic-dns
  • hacking
  • insufficient-content
  • parked
  • not-resolved

Så med noen enkle steg, så har vi blokkerte nedlasting av PE filer fra ukjente\ikke kategoriserte sider, og alt dette fikk i plass i en enkel regel..

Samtidig har vi hevet terskelen for angriperne, og mange vil bare hoppe til neste mål så fort de møter motstand. Tid er penger for dem også!

Posted in Uncategorized | Leave a comment

MineMeld – Office365

Ja, det heter faktisk MineMeld. (Trodde lenge selv at det var MindMeld!)

MineMeld er ett gratis verktøy fra Palo Alto Networks, som er utviklet ene og alene for å gjøre hverdagen deres enklere!
Kort fortalt så er dette en lettvekts server basert på Ubuntu som korrelerer data fra forskjellige eksterne lister, for så gjøre dem om til ett format vi kan levere til Palo Alto Networks brannmuren via External Dynamic List(EDL). External Dynamic List er en 7.1 funksjon, så kjører man 7.0 og tidligere, så er det kun støtte for IP-lister.

Eksempler for lister vi kan korrelere data fra:

  • Azure Cloud-IP
  • Office 365 IP\URL
  • RansomwareTracker som inneholder informasjon om IP\URL som er med i kampanjer
  • SpamHouse som har data om IP\URL som er innblandet i SPAM aktivitet

Pluss mange mange fler, men i dette innlegget skal jeg fokusere på noe jeg vet mange trenger, nemlig en komplett oversikt over alle IPer og URLer som brukes for Office365!

Først må vi installere serveren, og jeg viser her hvordan man gjør det med en *.ova fil for VMware. Du kan få tak i denne på følgende url: https://s3-eu-west-1.amazonaws.com/minemeld-dist/0_9/minemeld-vm-0.9.5.ova

bm1

Etter den er lastet ned, så er det bare å åpne den i VMware, jeg bruker VMware Workstation 11.

bm2

Her ser dere standard oppsett, jeg har valgt å øke fra 1024 til 2048mb RAM, det gir vesentlig bedre ytelse på web-gui.

bm4

Start minemeld, og vent ca 4-6 minutter før du beskjeden om at minemeld har startet korrekt. Du kan dermed logge inn med følgende informasjon:

Username: ubuntu

Password: rsplizardspock

Det er ikke nødvendig å logge inn i shellet egentlig, men jeg visste ikke IPen..

(For de som ikke skjønner passordet så er det “Rock, Scissors, Paper, Lizard, Spock” som er en variant som ble mest kjent etter å ha vært med i en Big Bang Theory episode.)

bm5

En enkel ifconfig senere så vet jeg at web-serveren lytter på https://192.168.1.170.

bm6

Vi kan nå logge inn på web-gui med følgende passord:

Username: admin

Password: minemeld

bm7

Du vil da bli presentert med følgende Dashboard, her ser vi at standard oppsett i .ova filen inneholder noe konfigurasjon allerede. La oss se nærmere på det.

bm9

Her ser vi en grafisk presentasjon av oppsettet, og enkelt forklart fungerer det slik:

Grønne sirkler representerer det vi kaller for “Miners”, dette er de som henter data fra ulike kilder på internett.

Røde sirkler representerer “engines” som korrelerer data fra Miners basert på om det er IPv4, IPv6 eller URL.

Gule sirkler representerer “Lists” som blir generert på kriterier vi setter, i eksemplet over har vi 3 stk, der innholdet er High Confidence, Medium Confidence og Low Confidence.
Dette gir oss mulighet til å blokkere High Confidence, mens vi kan ha alert på Medium og Low for å se om det er noe trafikk mot disse IPene. Dette gir oss kontroll, og mulighet til å reagere om vi ser noe merkelig.

bm10

Som nevnt tidligere, så har vi mulighet til å hente informasjon fra svært mange aktører. Jeg anbefaler dermed at første stopp er å gå til “Config” og deretter trykke på knappen som heter “browse prototypes”. Det er ikke så rent lite vi kan gjøre.. og dette er gratis!

bm11

Siden eksemplet her baserer seg på Office365, så kjørte jeg ett raskt søk på Office365, vi får da opp 17 treff! Dette er lister med IPer og URLer som Microsoft vedlikeholder, som vi kan nå dra direkte inn til brannmuren via EDL. Dette gir oss mulighet til å lage regler for trafikk, og SSL dekryptering basert på denne informasjonen. Noe som er svært nyttig! Ingenting er kjedeligere enn å manuelt vedlikeholde slike lister.

bm13

Vi går tilbake til “Config” og trykker nå på plusstegnet for å lage en ny Node basert på en prototype.

bm14

Først må man gi den ett navn, her har jeg bare brukt “O365_<innhold>” som standard, dette er helt opptil dere. Så velger man hvilken prototype denne Noden skal bruke, og man kan da velge mellom de 3 vi gikk igjennom i sted. “Miner”, “Engine” og “List”. Vi starter med å lage en Miner, basert på office365.O365. Du ser beskrivelsen på bildet.

bm15

Vi velger ikke noe på INPUT, men aktiverer OUTPUT. Enkelt forklart så er INPUT andre Noder, og Mineren skal ikke hente data fra andre Noder, men direkte fra Microsoft. OUTPUT betyr at Noden skal tillate at andre Noder henter data, noe som vi trenger i neste steg. Trykk OK for å lagre noden.

bm16

Lag en ny Node, og denne gangen skal vi lage en “Engine” som faktisk korrelerer dataene. Vi gir den ett passende navn, og deretter definerer en Prototype som samsvarer med dataene vi skal korrelere. Her lager vi en Engine som henter ut og leser IPv4 adresser. Under INPUT definerer vi Mineren vi nettopp satt opp, og OUTPUT setter vi til Enabled. Trykk OK for å lagre.

bm17

Vi lager enda en ny Node, denne gangen skal det bli en “List” som inneholder de prosesserte dataene fra Engine noden. Vi gir den ett navn som tidligere, og velger en Prototype som henter ut de dataene vi ønsker. I dette tilfellet bruker vi “feedHCGreen” som står for High Confidence Share Level Green, denne bruker vi siden alle dataene fra Microsoft er 100% korrekt og offentlig tilgjengelig. INPUT er Engine Noden vi har laget, og OUTPUT er disabled, siden vi ikke skal dele data videre med noen andre Noder. Trykk OK for å lagre.

bm18

Ute i “Config” menyen har vi en “Commit” knapp, trykk på denne og vent i ca 2-3 minutter før alle endringene har trådt i kraft.

bm19

Trykk deretter på en av de nodene vi har laget, og velg  nederste meny på venstre side, du vil da se den grafiske representasjonen av det vi har laget.

Her ser vi 0365_portal_and_identity Miner, O365_engine_IPv4 henter data og korrelerer det, før 0365_IPv4_list kompilerer sin liste.

Mer at Det grå feltet representerer mengden med data som kommuniseres mellom nodene, her ser vi at det går mindre mellom listen vår og engine, enn fra miner til engine.

bm19_1

Ser vi på statistikken til Enginen vår så ser vi at ca halvparten av inneholdet fra Mineren vår blir ignorert. Ett raskt kikk i loggen viser at dette er IPv6 og URL data. Dette blir avvist siden vår Engine ser kun etter IPv4 adresser. Så da blir neste steg..

bm20

Og lage enda en ny Node! Vi starter med en ny “Engine” som skjønner URL. Gi den ett navn og velg riktig Prototype. Velg Mineren fra tidligere på INPUT og aktiver OUTPUT. Tykk OK.

bm21

Deretter lager vi en ny liste, dette må vi gjøre fordi Palo Alto Networks ikke støtter både URL og IPer i samme liste per idag over EDL. Velg den nye engine for URL på INPUT og deaktiver OUTPUT. Trykk ok og lagre.

bm23

Også har “me juksa lite!”, jeg har her lagt til enda flere Minere, dette må gjøres for å sikre at man faktisk får alle URLer og IPer tilhørende Office 365. Dette var de jeg måtte legge til for mitt miljø, om man bruker mange funksjoner i Office 365 så kan det hende at man må legge til alle 17 som finnes. Det kan være lurt å lese beskrivelsen i Prototyp listen.

Men her kan dere se nå at vi har flere Minere som leverer data til 2 stk Engines, som igjen korrelerer dataene slik at vi sitter igjen med 2 lister som vi kan bruke på brannmuren. En for URL og en for IP. Vi kan også legge til IPv6 om det er behov for det også.

bm22

Slik ser min konfigurasjon ut nå, om man vil legge til flere INPUTS for en Engine, så trykker man bare på området jeg har ringet rundt.

bm_35

Slik ser mitt Dashboard ut etter denne konfigurasjonen, her ser vi at det er endring i data hele tiden, noe som er en god indikator på at alt fungerer slik det skal.

Nå mangler vi bare å få dataene inn til Palo Alto Networks brannmuren.

bm24

Første steg da er å trykke på listene vi har laget for å finne ut URL vi må bruke for EDL import.

bm25

En  rask sjekk viser at vi får tilgang og at det er data listen. Vi hopper da over til brannmuren.

bm26

Vi hopper til “Objects->External Dynamic Lists”, og trykker “Add”.

bm27

Vi legger inn URL og velger de forskjellige innstillingene. Viktig og få “Type” riktig. Her kan vi velge mellom IP, Domain og URL. Jeg velger å sjekke listen hver time, da jeg antar at det ikke skjer så ofte endringer fra Microsoft sin side.

Trykk “Test Source URL” for å sjekke om brannmuren når MineMeld, om det går bra, så kan man trykke OK. Legg til URL listen på tilsvarende måte.

bm28

Da sitter vi med følgende lister i brannmuren, kjør en commit!

bm31bm32

Når commiten er ferdig, så kan det være fornuftig å sjekke om listene faktisk fungerer. Dette kan ikke gjøres via GUI, så da må vi inn på CLI.

Kjør følgende kommando> request system external-list show type ip|url name <navn på listen> for å få opp innholdet. Du ser at det fungerte fint for meg. Du får også informasjon om listene er i bruk via “Referenced” feltet.

bm30

bm29

Vi vet nå at listene har data, så da kan vi bruke det i regler! Hva med å ha en regel som gjør at kun kjente brukere kan bruke tillatte applikasjoner mot kjente Office 365 destinasjoner? Det kan vi  nå gjøre!
Eller kanskje bruke PBF til å sende all trafikk mot O365 tjenester via en dedikert link? Det kan vi gjøre!

bm34

Eller kanskje lage en Decryption regel for å dekryptere trafikken? Eller kanskje du ønsker å unnta for dekryptering? Valget er ditt, men vi har nå iallefall den informasjonen vi trenger for få det til!

bm33

En rask kikk i loggene viser at trafikken treffer også! Happy days!

Kort oppsummert så er det fornuftig å ta en titt på MineMeld, det er ett kraftig verktøy som kan gjøre mye moro! Jeg vil følge opp med flere eksempler senere, men har hatt flere som har hatt spørsmål rundt Office 365.

Ressurser:

Live! MineMeld – Masse flere eksempler, og mye nyttig informasjon!

Posted in Uncategorized | Tagged , , | Leave a comment

CLI Tips!

Raskt tips for dere som bruker console på Palo Alto Networks sine bokser!

Om dere ikke har gjort det så bør dere kjøre følgende kommandoer for å slippe at tekst overskriver hverandre og blir uleselig:

> set cli terminal height 500

> set cli terminal width 500

Nå vil dere oppdage at det er veldig mye lettere å lese tekst!

Settings ellers for best mulig opplevelse:

Bits per sec    :  9600

Data bits       :     8

Parity          :  none

Stop bits       :     1

Flow control    :  none
Posted in Uncategorized | Leave a comment

I de blindes rike er den enøyde konge

Sikkerhet.

Sikkerhet kan defineres som en tilstand; fravær av uønskede hendelser eller frihet fra fare og frykt.  Denne tilstanden er imidlertid ikke statisk, men påvirkes av endringer i faktorer som trussel og farer, sårbarhet og verdi. – Definisjon fra Store Norske Leksikon

Det er nøkkelordet som driver meg i mitt arbeid. Mitt mål er å gi kunden frihet fra fare, og for å få til det må man implementere løsninger som gir full visibilitet i nettverket.

Og med full visibilitet mener jeg at man kan se alle applikasjoner over alle porter. Hva hjelper det om man har dyre proxyer eller IPS\IDS løsninger når de kun kan inspisere ett utvalg av standard-porter?

security-camera-fails-2

Da blir det som bildet illustrerer, at hendelser kan skje ubemerket utenfor «synsfeltet» for de løsningene man kanskje allerede har i nettverket sitt.

Og det er her vi kommer tilbake til overskriften for denne blogg-posten.

Veldig mange bedrifter mener de allerede har gode nok løsninger og rutiner for å håndtere IT-sikkerhet.

De har ofte den klassiske oppskriften med:

  • Generisk AV-klient fra en kjent leverandør
  • Proxy for klient-trafikk ut mot internett, uten SSL-terminering i de fleste tilfeller
  • Noen ganger en IDS eller IPS
  • Generisk brannmur som opererer på port-nivå

Problemet? Med unntak av AV-klienten så forholder alle løsningene seg til porter.
Om trafikken ikke treffer noen av disse portene som er «overvåket» så er man blind i hva innholdet faktisk er i pakkene. Er det legitim trafikk? Eller var det designet på produktet som skulle redde fortjenesten de neste 10 årene som forsvant til Kina over SSL på port 999?

Noen vil argumentere at med god kontroll på den ytre brannmuren så kan man stenge for utgående trafikk over rare porter. Men hva om man bruker kjente porter som er åpne? Vil brannmuren stoppe SSL over port 21? Vil den stoppe DNS over port 443? Eller enda enklere, kan man inspisere SSL overhode?

Og tilbake sitter man igjen med en bedrift som er strålende fornøyd, for utfra deres logger så er alt helt strålende i nettverket. Ingenting er galt.

Det er ikke da lett og overbevise dem om at de må investere i ett nytt produkt som faktisk gir dem hele bildet. De tror allerede at de har det.

Dette endrer seg selvfølgelig alltid etter en Proof-of-Concept, når de faktisk ser det fulle bildet. Den blinde har plutselig fått laseroperasjon og kan endelig se på begge øyne!

Og i de fleste tilfeller er ikke bildet så pent som de hadde ønsket. BitTorrent, TOR-nettverk, SSL over ustandard porter, C&C trafikk fra gamle servere med mer.

Men det vi kan se, kan vi også stoppe.

Det er først nå vi kan snakke om frihet fra fare.

 

 

 

Posted in Uncategorized | Leave a comment

Palo Alto Networks vs Tradisjonell Proxy

Intro

Proxy er ett produkt som har eksistert lenge i IT-verdenen, og historisk så var jobben til de første løsningene:

  • Fungere som ekstern gateway for interne maskiner i ett bedriftsnettverk. (Som vi løser med NAT i dag)
  • Regulere tilkoblinger via URL-filter og/eller IP-filter
  • Cache for å spare båndbredde (Relevant når vi hadde ADSL på 1000+ brukere.. )
    blogg_proxy_034

Illustrasjon hentet fra BlueCoat

Som illustrasjonen viser så var en av de største fordelene med proxy at man kunne spare båndbredde og samle alle klientene bak en IP-adresse mot internett. Dette var helt nødvendig når flere 100 om ikke flere 1000 brukere delte internettlinjer på 3-10Mbits. Om alle skulle da ha en «fersk» kopi av vg.no klokken 08:00 hver morgen så ville hele linjen knelt.

Dette gjorde proxy til en nødvendighet for større bedrifter og organisasjoner.

Over tid så utviklet leverandørene av proxy til å tilby flere funksjoner som:

  • Anti-virus skanning av filer
    • Noen hadde «on-box» mens mange leverte via ICAP
  • URL-Filter
  • Applikasjonsfilter
  • Stream-splitting
  • Bruker-identifikasjon

Dette gjorde at proxy utviklet seg fra å være en nettverksenhet til og bli en sikkerhetsløsning som kunne filtrere bort skadevare å uønskede websider \ applikasjoner fra internett-trafikken.

Dette fikk stor suksess i markedet, for brannmurer var fortsatt bare port-baserte i de fleste tilfeller, ved hjelp fra proxy fikk man endelig noe innsyn i web-trafikken.

Utfordringer med tradisjonell proxy

Den største styrken til en proxy løsning, er også en av de største problemene.

Enten om man bruker eksplisitt proxy* eller transparent proxy** så er tanken at proxyen utgir seg å være serveren ovenfor klienten som sender spørringen.

blogg_proxy_03.png
Illustrasjon hentet fra Cisco

Som illustrasjonen viser så oppretter en proxyen 2 stk separate tilkoblinger, en mot klienten og en annen mot serveren som klienten spurt om tilgang til.
Dette gjorde at man fikk mulighet til å skanne, endre og blokkere trafikk før den ble sendt videre ut på internett.

Porter

Utfordringen er at de fleste proxy løsninger lytter kun på porter relatert til web-trafikk som tradisjonelt er:

  • 21 (FTP)
  • 80 (WEB)
  • 443 (SSL)
  • 8080 (Eksplisitt Proxy)

Dette gir ikke full visibilitet over nettverkstrafikken, særlig nå som applikasjoner ofte bruker «port-hopping» for å finne en vei ut av nettverket. Skype er en av mange eksempler som finner seg en port som fungerer, om så den porten er 80, 443 eller 5050.

De fleste proxyer kan heller ikke per i dag identifisere en applikasjon om den kommer over en «non-standard» port.
Som bringer oss til neste problem.

Applikasjoner

Flere proxyer støtter i dag applikasjonskontroll, og i mange tilfeller fungerer dette tilfredsstillende.

Problemet er at databasen over kjente applikasjoner ofte er liten, og omfatter sjeldent noe annet enn applikasjoner relatert til streaming, sosial media eller filoverføring.

Årsaken til dette er at det krever mye arbeid for å undersøke hvordan hver enkelt applikasjon fungerer i kommunikasjon mellom klient <-> server. Hvilke porter brukes? Er alt TCP? Er noe UDP? Går det ICMP kontroll meldinger? Sertifikat? SSL? Headere?

Dette kan ta alt fra uker til måneder og utarbeide, som igjen har ført til at de fleste leverandører har små databaser med applikasjoner.

Som fører oss til:

Web 2.0

Applikasjoner er ikke lengere Word, Excel, Kabal og PowerPoint eller andre programmer som kjører lokalt på arbeidsstasjonen til brukeren.

Applikasjoner er nå også Facebook Messenger, Google Apps, SalesForce og resten av løsningene vi kjører via web-browseren.

Flere og flere applikasjoner lever nå i skyen under paraplyen «Software as a Service (SaaS)», dette er dynamisk levende web-løsninger som oppdateres med nytt innhold flere ganger i minuttet.

Resultatet er at tradisjonelle proxy leverandører ikke klarer å kategorisere eller oppdatere applikasjonene sine fort nok, som fører til driftsforstyrrelser som igjen fører til unntak og dermed unntak fra sikkerhet.

Ytelse

Det kreves en del prosesseringskraft å håndtere AV-skanning, URL-filter, Applikasjonskontroll og SSL-dekryptering, særlig når man vet at en proxy må opprettholde 2 helt separate tilkoblinger mot klient og server.

Dette sammen med latencyen en proxy medfører gjør at man ofte kun sender klient-trafikk igjennom, og ikke annen «kritisk» trafikk man ikke vil risikere skal få problemer når proxyen er overbelastet.

Management

Det er også en utfordring og spre sikkerhet over flere løsninger, om man allerede har en «NGFW» i nettverket sitt, så virker det mot sin hensikt og flytte noe av sikkerheten over i en annen løsning.
Dette gjør at man mister kontekst på trafikken, og kan føre til at sikkerheten blir forringet.

Kostnader

Det er også en økt kostnad ved å vedlikeholde en proxy løsning.

  • Hardware-kost (3-5år mellom hver gang man bytter)
  • Årlig lisenskost for løsningen
  • Årlig vedlikehold for løsningen
  • Intern driftskostnad
    • Kurs
    • Sertifisering
    • Nedetid for oppgradering

Konklusjon

En tradisjonell proxy var svaret vi hadde for 20 år siden når behovet for internett i bedrifter og organisasjoner kom.

Det løste alle problemene vi hadde på den tiden, og med årene utviklet man proxyen til å bli en viktig komponent i nettverket for sikkerhet ved bruk av AV-skanning og avanserte URL-filtre.

Nå har landskapet endret seg, internett er ikke lenger en samling av statiske bilder og tekst, men er nå levende med facebook, twitter, linkedin, instagram og haugevis med andre integrasjoner på kryss og tvers av alle sider.

Går du på www.vg.no klokken 10:00, så er innholdet allerede endret 10:01.

Caching er dermed helt utelukket, noe som er helt greit når de fleste bedrifter og organisasjoner har 100mbit, om ikke 1Gbit linjer.

Da sitter man igjen med en løsning som kan skanne etter virus og blokkere tilgang basert på URL-kategorier.
Hvilken annen løsning kan gjøre det?

Palo Alto Networks

Løsningen til Palo Alto Networks som ofte bare blir kalt «Next Generation FireWall (NGFW)» sin store styrke er at den klassifiserer applikasjoner uansett hvilken port trafikken kommer inn på. ***

Så om f.eks DropBox bruker port 3000, 27 eller 443 så klarer Palo Alto og klassifisere applikasjonen riktig.
Om man da har blokkert DropBox så vil trafikken bli droppet, og brukeren vil ikke få brukt applikasjonen.

Dette hadde ikke vært tilfellet ved bruk av proxy i kombinasjon med portbasert brannmur som identifiserer applikasjoner etter hvilken port de bruker. Applikasjonen ville da fungert, og man kunne potensielt lekket viktig dato ut til DropBox.

Om man dermed kombinerer Palo Alto sin applikasjonskontroll som inneholder over 2000 applikasjoner, med Threat Prevention****, PAN-DB URL-filter, Content-ID,Wildfire(Advanced Malware Detection) og User-ID så har man en plattform som leverer full synlighet, sporbarhet og sikkerhet for web-trafikken i nettverket deres.

Man kan da bygge en policy som rundt de applikasjonene og URL-kategoriene man ønsker i nettverket sitt. Man slipper å måtte forholde seg til 2 eller flere løsninger for å løse ett problem som Palo Alto Networks er designet fra grunnen opp til å løse.

blogg_proxy_02blogg_proxy_01

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

*Eksplisitt proxy
 Explicit proxy deployments require an IT organization to configure the web browsers on every laptop and workstation in their enterprise to ensure that web traffic is pointed to the proxy appliance or security device. Many enterprises deploy proxy auto-configuration (PAC) files using manual methods, system policies enforced by Microsoft Global Policy Object (GPO), or via web proxy auto-discovery (WPAD) protocol. However a misconfigured WPAD file could allow an attacker to redirect a user’s machine toward a malicious configuration file, while too restrictive of a GPO can result in an increase of IT trouble tickets submitted by frustrated users. Organizations face additional challenges when they don’t own or control an endpoint, like mobile devices, which can be used to bypass corporate proxy policies.
** Transparent proxy 
 Implicit, or transparent proxy deployments add complexity, latency, and include additional equipment to manage, all for a partial view of traffic on the network. Implicit proxies typically involve IT organizations that reconfigure their switches and routers to use Web Cache Communication Protocol (WCCP) for steering web traffic directly to the proxy appliance. Many proxy appliances pass off certain inspection tasks, e.g. AV scanning, via Internet Content Adaptation Protocol (ICAP) to an additional, separate appliance. Not only does this add to the complexity, it becomes yet another tool that requires another management console. The entire process impacts performance while the proxy device takes time to forward traffic to the AV scanning appliance and holds the connection open awaiting a response on whether to allow or deny that traffic
*** https://www.paloaltonetworks.com/products/technologies/app-id.html
**** https://www.paloaltonetworks.com/solutions/initiative/threat-prevention.html
Posted in Uncategorized | Leave a comment

Crypto-ransomware

«Alle» har sett, fått eller hørt om noen som har fått en eller annen form av Crypto-ransomware.
Historien er som regel lik, en klient ble infisert, denne klienten hadde tilgang til filserveren som igjen resulterte i mengder på mengder med ubrukelige krypterte filer.

f-this
( Fra IT-sjefen sitt kontor når han får beskjeden )

For de fleste så resulterer det i full heksejakt på den infiserte klienten, før man kjører en full restore fra backup.
Noen velger også å betale, som oftest fordi de ikke har backup eller tenker det er raskere enn å kjøre en full restore.

Og det gir oss ett problem. Angriperne får betalt, og de får betalt godt.

Det er faktisk så god butikk at de kommer med egen kundeservice som i mange tilfeller er bedre enn det man får fra legitime tjenester. For så lenge de leverer det de lover ved betaling, så vil vi fortsette å betale. De er faktisk avhengig av den tiltroen. For hadde vi visst at de ikke åpnet, hadde vi aldri betalt.
Og siden vi betaler så får de mer penger til å utvikle crypto-ransomwaren enda mer, det er som enhver annen bedrift. Går det i pluss så fortsetter man. Dette er en sirkel vi ikke ser slutten på før de faktisk ikke tjener særlig penger lengre.

Mange jeg har pratet med har resignert, og tenkt at dette er noe de må leve med. Ingen av de tradisjonelle løsningene de har klarer å stoppe alle mutasjonene.

shm1
( Følelsen med enda en dag med cryptolocker )

Den tankegangen fører som oftest til investering i enda bedre backupløsninger, som gjør at de enda raskere kan rulle tilbake når den infiserte klienten har blitt tatt hånd om.

Men vi snakker fortsatt om nedetid, og får mange mange av dem i måneden så kan det bli dyrt.

Jeg mener også det er en veldig passiv tankegang, det blir litt som om vi skal legge ned Politet og heller investere pengene i helsevesenet fordi vi ikke kan stoppe alt av voldskriminalitet.

Ja, vi må ha gode løsninger for backup, men vi må ikke bare tenke retroaktivt. Vi må også være proaktive og prøve å stoppe angrepet før det skjer.

Hvordan gjør vi så det?

Vel, som vi har allerede vært inne på, så er det klientene som blir infisert.
Gjerne via e-post kampanjer som er pakket pent inn med kjente norske merkenavn, der Posten kampanjen er det mest kjente. Alle har ett forhold til posten, og mange av oss venter pakker.
Da er det ikke så rart at denne kampanjen traff bredt, og førte til at svært mange IT-avdelinger måtte bruke en del overtidstimer på å rydde opp.

svindel-posten+advarer+mot+nye+virus+i+e-post
( Eksemplet er på engelsk, men det kom også versjoner på Norsk )

Hadde derimot klientene vært beskyttet godt nok, så hadde det meste blitt stoppet før det fikk gjort noen skade.

Min anbefaling er at man tar en titt på det som kalles «AMD» til bedriftens klienter og servere.
«AMD» står enkelt nok for «Advanced Malware Detection», og er løsninger for å se på oppførsel av programvare fremfor av-signaturer som ofte ikke klarer å holde følge med den raske utviklingen.

Slike «AMD» løsninger ser fort at noe ikke er helt på stell når PDFen du fikk på e-post prøver å gi seg flere rettigheter, laster ned filer, oppretter SSH tuneller eller mer.
traps-pdf

Palo Alto Networks har en løsning for dette som heter TRAPS:

Med Traps eller en annen AMD løsning på klientene dine er man mye bedre rustet til å stoppe Crypto-ransomware, og andre zero-day sårbarheter. Tiden er over der man må la seg bli infisert for deretter rydde opp, nå er tiden å bekjempe dem før de får gjort skade!

Så kan man gå på jobb og føle seg slik:

victory

Lykke til!

Posted in Uncategorized | Leave a comment

Zone Protection

Zone Protection er en viktig bit i puslespillet for å få ett godt oppsett på brannmuren. Men jeg ser ofte at dette blir glemt, noe jeg håper jeg kan endre på med denne blogg-posten!
Så hvor legger vi på Zone Protection? Jo, under Zones:

blogg_zone_prot_01

Dette er hentet fra min LAB som kjører 7.1 Beta, men det ser tilnærmet helt likt ut på 7.0.
Du ser hvor du velger profilen her. Profilen gjelder for innkommende trafikk, og ikke utgående. Derfor har vi en “External” profil på Untrust som står mot internett.

Men før vi kan legge den til her må vi lage en Zone Protection profile. Det gjør du under Network -> Network Profiles -> Zone Protection

blogg_zone_prot_02

Trykk “Add” og du får opp følgende skjermbilde:

blogg_zone_prot_03

Første valget er “Flood Protection” som beskytter deg mot akkurat den sier. Flooding av pakker. Her er info hentet fra SANS sitt dokument vedrørende “Best practice” på en Palo Alto Networks:

Recommendation:

The Alert, Activate, and Maximum settings for SYN Flood Protection depend highly on

the environment and device used. Traffic analysis should be performed on the specific

environment and firewall to determine accurate thresholds.

As a rough ballpark for most environments, an Activate value of 50% of the firewall’s

maximum “New sessions per second”/CPS is a conservative setting. The following is a list of

new sessions per second maximum for each platform:

PA-200 = 1,000 CPS

PA-500 = 7,500 CPS

PA-2000 series = 15,000 CPS

PA-3000 series = 50,000 CPS

PA-5000 series = 120,000 CPS

PA-7050 = 720,000 CPS

Les mer i dokumentet som du finner her: SANS Whitepaper Palo Alto

 

blogg_zone_prot_04

Så har vi “Reconnaissance Protection”, som kan være lurt å ha på Zonen som står mot internett. Sett på alert i første omgang, men så kan du vurdere å sette til Block eller Block-IP om du ser mye aktivitet fra enkelte hoster.

blogg_zone_prot_05

Siste fanen er “Packet Based Attack Protection” som har flere underfaner igjen. Den første ser vi er “IP Drop”.
Det første valget her er nok godt kjent for mange, som beskytter Zonen fra spoofete IP addresser.

Her er ett utsnitt fra hjelp (?) i høyre hjørne:

blogg_zone_prot_08

Denne typen info finner du under alle fanene, jeg tok med denne da denne er den viktigste fanen. (Merk IP Drop og TCP Drop er samme fane i 7.0).

blogg_zone_prot_06

Under “TCP Drop” har vi ett par viktige valg når det kommer til asynkron ruting. Standard verdiene for Non-SYN TCP og Asymmetric Path er “global” som betyr at den henter info fra det som er satt i CLI. Men om man har en Zone som man trenger å tillate asynkron ruting, så kan man gjøre det via denne funksjonen. På denne måten trenger du ikke å gjøre om dette for hele brannmuren via CLI.

blogg_zone_prot_07

Her bør man iallefall ha på “ICMP Large Packet”, slik at ingen sender ut masse data med hjelp fra ICMP 🙂

De siste fanene er selvforklarende om man jobber med IPv6.

MERK: Du vil ikke få logger fra Zone Protection så lenge trafikken blir stoppet\tillatt av default intra\inter-zone regler, da disse ikke logger!

Posted in Uncategorized | Leave a comment

Segmentering – Hva kan man gjøre?

Det høres enkelt ut i prinsipp, man bare skiller enhetene i nettverket fra hverandre og kun tillater trafikk som tilhører applikasjonene man trenger.

For eksempel så trenger ikke klientene til de ansatte full tilgang SQL-serveren på alle porter? Trenger de tilgang til den i det hele tatt egentlig? For det er jo web-applikasjonen på web-serveren som faktisk henter data derfra?

Og den nye fine printeren som har alle de kule funksjonene, er det så lurt at den står i samme nettverk som klientene dine? Den kjører jo Windows Embedded, og du har vel ikke akkurat kontroll på patch-nivået på den?

Eller enda verre, hva med kaffe-maskinen som du har koblet i nettverket slik at den kan si ifra automatisk når den trenger service til leverandøren? Hvordan gjør den det? Mest sannsynlig ett UNIX-basert OS. Vet du sikkerheten på den? «Admin/kaffe123» er ikke sikkerhet på toppnivå. Og tror du ikke den kan kjøre en FTP server?

Som sagt, tanken er enkel, men ikke alltid så lett å følge opp i prinsipp.

Ofte blir nye løsninger og enheter innført uten mye tanke på sikkerhet, men at «dette må vi bare ha nå!». Over lang tid ender man opp med uoversiktlige nettverk, der man ikke har full kontroll på hva som prater med hva.

Når man da skal begynne å ta tak i problemet, så kan det ofte bli ett veldig omfattende prosjekt.
Det er ikke alltid så lett å bare endre IP på en haug med servere eller printere, ikke alt av tjenester bruker DNS som oppslag.

Så hvor starter man? Etter min mening er den beste strategien å starte med det viktigste i nettverket, og jobbe seg nedover.

For mange vil det være database serverne, det er de som ofte har sensitiv informasjon som man absolutt ikke vil se ute på internett i en ZIP fil.

Og det er her en av de største styrkene til Palo Alto Networks ligger!

Ett vanlig flatt nettverk som mange mange bedrifter i det norske land har:

blogg_segmentering_001

Dette er en angripers drøm, ett helt flatt nett der man ikke har noen barrierer, og der man ikke har noen barrierer har man heller ikke noe visibiltet. Noe som igjen betyr at angriperen kan være i nettverket nesten så lenge han ønsker.
Noe må gjøres! Men hva kan man gjøre uten å måtte endre hele nettet? Hva kan man gjøre NÅ?

blogg_segmentering_002

Man kan innføre en Palo Alto Networks brannmur inn i nettverket, og sette den opp på Lag 2, man kan da si at all trafikk som kommer inn eller ut fra ethernet1/2 er Servere, ethernet1/3 er klienter og ethernet1/4 er Printere.

På den måten har man raskt laget soner, som man igjen kan legge regler på. Uten og faktisk endre en eneste IP-adresse i nettverket.
Styrken som jeg vil komme frem til er at Palo Alto Networks støtter Lag 2, Lag 3, Virtual-Wire og TAP om hverandre, dette gjør det mulig å beskytte hele nettverket ditt med de metodene du trenger.

Så kan segmentere videre når man har anledning for nedetid, og prosjektplanen er spikret.

Lykke til 🙂

Posted in Uncategorized | Leave a comment

Endelig var jeg instruktør!

Mitt første mål når jeg startet i Arrow ECS var at jeg skulle bli instruktør på Palo Alto Networks sine produkter.
Det har jeg jobbet målrettet mot i 4 måneder, og det hele ble avsluttet med en tur til Amsterdam fra 18-20 januar for det Palo Alto Networks kaller for “ICW” (Instructor Certification Workshop).

Palo Alto Networks har endret kurset etter de ansatte en ny sjef for opplæring som heter David Day, som kommer fra VMware. Det er nå mye mer krevende, og noe man absolutt ikke skal ta lett på.
Palo Alto Networks sin innstilling er at instruktørene som jobber rundt i verden representerer dem, og må dermed holde den absolutt høyeste kvalitet. (Slik som produktet deres gjør.. 🙂 )

For å si det mildt ble det 3 harde dager, hvor vi ble testet og korrigert på alt som har med det å være instruktør.
Øyekonktakt, bevegelser, “fillerwords” (hummm, aaahh etc), whiteboard bruk, eksempler fra virkeligheten, og sist men ikke minst spørsmål fra studentene.
Her fikk vi høre at man kan høre det meste. En av favrittene mine var “So what happened with IPv5? Why the jump to IPv6?”.

Gleden var dermed stor når jeg fikk beskjed om at jeg stod, og jeg nå er klar til å lære bort 201 og 205 kursene til Palo Alto Networks!
Jeg gleder meg veldig, og tror det blir en morsom opplevelse for alle parter som kommer på ett kurs hos meg!

Håper å se deg snart, på ett kurs på Palo Alto Networks hos Arrow!

Posted in Uncategorized | Leave a comment