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.. )
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.
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.
*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