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
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?
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:
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.
Proxy er ett produkt som har eksistert lenge i IT-verdenen, og historisk så var jobben til de første løsningene:
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:
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.
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.
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.
Utfordringen er at de fleste proxy løsninger lytter kun på porter relatert til web-trafikk som tradisjonelt er:
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.
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:
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.
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.
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.
Det er også en økt kostnad ved å vedlikeholde en proxy løsning.
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?
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.
*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