Brannmurer og andre grensevakter

Mesteparten av teknologien som brukes på Internett kan standardiseres. Bortsett fra i innovasjonsfasen, vil det være ønskelig å standardisere måten vi kommuniserer på over Internett. Derved kan vi oppnå samvirke (interoperabilitet) mellom programvare og utstyr fra ulike produsenter. Suksessen til ulike applikasjoner for eksempel, vil jo øke med antallet som bruker denne. Har man få å kommunisere med, blir det ikke så interessant å bruke en applikasjon.

Den økende sikkerhetstrusselen på Internett har ført til stadig tiltagende bruk av brannmurer. Ifølge nettleksikonet Wikipedia er en brannmur utstyr (hardware) eller program (software) som i en nettverkssammenheng forhindrer visse typer kommunikasjon basert på en sikkerhetspolicy. Brannmuren gir en kontrollert tilknytning av en maskin eller et nettverk.

Dette er vel og bra, men forsøker man å sammenligne ulike brannmurløsninger basert på leverandørenes dokumentasjon, er det nærmest umulig å jevnføre disse. Informasjonen (eller kanskje vi heller kan kalle det reklamen) er så gjennomsyret av leverandørspesifikk terminologi, at det også for fagfolk blir vanskelig å forstå beskrivelsene som gis.

Vi skal i denne temapresentasjonen prøve å gi et oversiktsbilde av dagens ulike brannmurløsninger. Vi skal først gi en generell definisjon av ulike typer brannmurer, vi skal se litt på et forsøk på å standardisere virkemåten til moderne brannmurer, og vi skal gå litt i dybden på forskjellige måter for å få IP-telefoni gjennom brannmurer og adresseoversettere.

Hva gjør en brannmur?

Vi avgrenser oss i denne sammenheng til å betrakte brannmursystem som utøver nettverkssikkerhet på grensen mellom to nettverk, typisk mellom et lukket intranett og Internett.

For små- og mellomstore bedrifter går trenden mer og mer i retning av totalintegrerte løsninger som dekker flere sikkerhetsbehov. Vi omtaler disse ofte som alt-i-ett-brannmurer eller med den amerikanske betegnelsen «security appliance».

Slike brannmurer kommer som lukkede bokser med ferdiginstallert operativsystem og sikkerhetsprogrammer. Boksene kan inneholde funksjonalitet som pakkefilter, VPN-gateway (Virtual Private Network) og IDP-system (Intrusion Detection and Prevention). I mange tilfeller tilbys også innholdsfiltrering som antivirus og antispam for e-post og URL-siling for Web.

I dag har den begrensede tilgjengeligheten på IP-adresser ført til utstrakt bruk av adresseoversetting (Network Address Translation, NAT). Adresseoversettere er for mange et «must», og kan naturlig integreres med en vanlig brannmur selv om adresseoversetting prinsipielt sett ikke er en brannmurfunksjon.

Det er naturlig nok ikke mulig å standardisere sikkerhetsfunksjoner som inntrengingsbeskyttelse. Hvilke sårbarheter som til enhver tid finnes og hvilke som er mest truende, vil variere over tid. Dette er jo blant annet et resultat av hackermiljøenes varierende påfunn.

Så konkurransen mellom sikkerhetsutstyrsprodusentene er nok i seg selv en pådriver for å sikre best mulig beskyttelse. Det gir svært dårlig reklame for en produsent dersom man ikke kan takle angrep som en annen produsent takler. Dette gir en naturlig utvelgelse med en slags «survival of the fittest».

Markedsandelene til et sikkerhetsselskap kan gi en pekepinn om leverandørenes dyktighet. Men samtidig er sikkerhet en dynamisk materie, så det kan fort dukke opp nykommere med innovative løsninger. Benchmarktester vil i mange tilfeller være nyttige ved utvelgelse av leverandør, mens andre vil basere sine valg på gode (eller dårlige) erfaringer med sin nåværende leverandør.

Hvordan implementeres brannmurer?

Brannmurløsninger som finnes på markedet i dag kan grupperes ut fra ulike kriterier. Noen kjører på spesialutviklede maskinplattformer, som Netscreen/Juniper eller Ciscos PIX. Dette gir vanligvis en bedre ytelse på grunn av prosessorkrevende oppgaver kan utføres i dedikert hardware. Andre brannmurer er rene programvareprodukter som kjører på en generell tjenermaskin, som Checkpoints Firewall-1 eller ulike Open Source Linux-baserte løsninger.

Ser man på den generelle virkemåten til en brannmur, kan disse deles opp ut fra den lagdelte protokollmodellen. Man deler da ofte opp i to hovedtyper: Pakkefiltre og proxyfiltre. Pakkefiltre eksekverer på nettverkslaget (IP-protokollen) og til dels transportlaget (TCP og UDP) og siler trafikken basert på adresser og portnumre. Dette kan være helt enkle implementasjoner som kjører på en vanlig ruter eller i en hjemmegateway. Men disse løsningene er også blitt så avanserte etter hvert at de ofte kan gå enda lenger oppover i lagene i protokollstabelen.

Proxyfiltrene fungerer på en prinsipielt forskjellig måte. De terminerer kommunikasjonsprotokollene, analyserer de enkelte protokollene helt til bunns, hvorpå disse bygges opp igjen dersom de skal slippes gjennom brannmuren. Slike brannmurer går ofte svært dypt i sine sikkerhetssjekker og kan for eksempel blokkere spesifikke URLer eller luke bort ActiveX-objekter. Slike proxyløsninger er spesiallagede for de enkelte applikasjonene og kalles også Application Level Gateways.

For vikelig store brannmurer benyttes gjerne en kombinasjon av pakkefiltre og proxyfiltre. Ved Internett-tilknytningen opprettes et buffernettverk mellom to pakkefiltre, dette omtales som en demilitarisert sone (Demilitarized Zone, DMZ). I denne sonen plasseres de ulike proxyfiltrene og eventuelle tjenere som skal være tilgjengelige fra Internett (typisk e-post og Web). Også alt-i-ett-brannmurer kommer ofte med demilitariserte soner i form av egne porter, i tillegg til Internett-porten og intranettporten.

Innbruddsdeteksjons/prevensjonssystem baserer seg vanligvis på gjenkjenning av mønstre til angrepsmetodene, såkalte signaturer. Disse forutsetter naturligvis at angrepsmetoden er kjent på forhånd, hvilket betyr at helt nye metoder ikke vil kunne stoppes. I den senere tid har det vært økt fokus på å gjenkjenne den generelle virkemåten til dataangrep, omtales gjerne som behaviour-based eller anomaly-based. Det er ofte bestemte trekk som går igjen ved slike angrep som avviker fra normal oppførsel til et dataprogram. Kode som åpner Outlook i hytt og vær er et eksempel på mistenkelig funksjonalitet. Slike løsninger tilbys for eksempel på Proventia fra ISS eller Tippingpoint/3Com.

Krav til brannmurer

Kort sagt bør vel en brannmur være best mulig til lavest mulig pris. Så med utgangspunkt i hvor mye penger man kan legge i en løsning – noe som også er avhengig av viktigheten til nettet som skal beskyttes – kan man sammenligne produkter innen en viss prisklasse. Hvor godt en brannmur fungerer, består av flere faktorer, hvorav sikkerhetsnivået (hvor godt produktet beskytter mot uønsket trafikk) og ytelsen (hvor mange pakker brannmuren klarer å tygge) er to hovedkriterier.

Men også andre sider ved produktet er viktig, for eksempel hvor enkelt er systemet å administrere. Det er naturligvis også viktig at utstyret hele tiden kan oppgraderes med ny funksjonalitet som holder tritt med trusselbildet som man møter på Internett. En annen side ved brannmuren som ofte blir forsømt, er hvor applikasjonsvennlig den er. Men skal ikke en brannmur heller være uvennlig da? Den skal naturligvis være uvennlig mot angriperne, men den skal være vennlig mot legitim aktivitet.

IETF har en egen RFC som skisserer krav til brannmurer. Denne stiller det generelle kravet om at en brannmur ikke må hindre vanlig bruk av applikasjoner – det vil si de som skal tillates å passere. Dette er et tiltagende problem ettersom IP-nett brukes til stadig flere applikasjoner.

Mange har prøvd å løse dette ved å overlagre nye applikasjoner oppå Web-protokollen (HTTP). Men dette blir å bite seg selv i halen. For man er jo strengt tatt interessert i å vite eksplisitt hva man slipper gjennom brannmuren. En slik ad hoc løsning for brannmurpassasje fører til at protokollfiltreringen av HTTP blir meget omfattende for å sjekke om det er noen blindpassasjerer som følger med. Alternativt så bli dette ikke sjekket i det hele tatt.

Hadde man derimot brukt Internett-teknologiens metodikk, ville en ny applikasjon tatt i bruk et eget portnummer. En brannmur ville da fått en enkel måte å trigge analysen på, og analysen av applikasjonsprotokollen ville blitt mye mer oversiktlig. Komplekse protokollanalyser hvor mange ulike protokoller er vevd tett sammen er mer sårbar for programmeringsfeil, og øker sånn sett sannsynligheten for feil i selve brannmuren. Og det ville vel være det verst tenkelige scenariet.

Ved introduksjon av nye applikasjoner påhviler det også selve utviklingen av denne et ansvar for at brannmurene enkelt skal kunne forholde seg til nettverkskommunikasjonen som disse er opphavet til. Dette er jo også en klar fordel for å oppnå størst mulig utbredelse av applikasjonen. Med stor sannsynlighet vil mange potensielle brukere sitte bak en brannmur.