hvilke slags angreb stoppes?

Selve "grunnfunksjonen" i en hvilken som helst firewall vil normalt være en funksjon for pakkefiltrering.

Harware firewalls og softwarefirewalls fungerer i praksis ofte litt forskjellig. Det gjelder for eksempel nokså spessielle problemstillinger for adsl router/modemer med innebygget NAT funksjonalitet. Det spesielle her er at man benytter lokale ip adresser inne på LAN, typisk i nummerserien 192.168.x.x eller 10.x.x.x Disse lokale ip adressene er ikke "rotbare" eller "adresserbare" via internett. En natrouter kan således godt kjøre helt uten pakkefiltrering samtidig som man oppnår en effekt som om det fantes et effektivt pakkefilter ved at NAT mekanismen ikke vil forwarde trafikk inn til LAN med mindre den blir spesielt "instruert" eller konfigurert til å gjøre dette. Arbeidstasjoner inne på lan er derved "sikre" som om det fantes en firewall, selv om ingen firewall i realiteten finnes. Et ADSL modem/router som pleier å være satt opp til å kjøre på denne måten er Cisco 677.

Andre adsl modem/routere kan også benytte en kombinasjon av den beskyttelse som en NAT forbindelse gir sammen med en ordinær pakkefiltrering.

De fleste adsl modemer/routere som fungerer ved hjelp av NAT teknologi dvs som benytter lokale adresser inne på LAN vil ved dette også gi en beskyttelse mot Dos angrep. "Dos trafikken" vil normalt stanse ved Nat routerens inngang også selv om det egentlig ikke finnes noe "filter" slik som for Cisco 677.

Anvendelse av NAT teknologi er sikkerhetsmessig å foretrekke. Ulempen er at denne løsningen kan gi noe dårlligere funksjonalitet for eksempel med hensyn til Multimedia via internett. Man kan for eksempel ha problemer med å sette opp enkelte typer voice forbindelse, men ikke alle.

Hvorvidt man har et dataanlegg som benytter seg av NAT eller ikke i forholt til internett, det kan man vanligvis finne ut ved å gå inn i dos vindu på windows og skrive "ipconfig" eller console i Linux og skrive "ifconfig". Dukker det da opp en typisk lokal adresse, så har man en NAT forbindelse, på godt og ondt. Sjekker man i tillegg opp med http://www.myip.dk og hvis man finner en annen ip adresse her så kan man være ganske sikker på at det dreier seg om en NAT forbindelse.

For internettoppkoplinger basert på NAT forbindelse, så vil sikkerheten i utgangspunktet og vanligvis være rimelig bra ivaretatt slik at det man så legger til av firewall for eksempel som software firewalls inne på LAN vil komme til som en ekstra bariere no 2. Et slikt sikkerhetsopplegg i flere nivåer er meget bra. Det vil ikke være spesielt ankelt å komme gjennom.

Man kan tenke seg at en hacker kan klare å overta kontrollen over et modem eller en router med den hensikt å bruke dette som en "plattform" for videre angrep inn mot lan. Sikkerhetsbariere no 2, dvs firewall inne på servere og inne på vil da være den sikkerhetsbariere som eventuelt vil tre i funksjon og hindre dette.

Jeg vil mene at det kan være gunstig som en sikkerhetsbariere no 2 å bruke en softwarefirewall som gir varsel dersom noen har klart å passere sikkerhetsbariere no1. Jeg vil mene at for eksempel Zone alarm (eller andre software firewalls) med fordel vil kunne settes opp til å ivareta en slik bariere no 2 funksjon. Den innebygde firewall i Windows 2000/XP er også bra som nivå 2 firewall men her finnes det ingen varslingsfunksjon.

Har man den type internettforbindelse som gir en ekstern ip direkte inn på PC så har dette både fordeler og ulemper. Dette kan man undersøke med "ipconfig" eller "ifconfig" kommandoen. Dukker det opp en ekstern ip og er denne den samme som man kan lese vha http://www.myip.dk så har man ganske sikkert en forbindelse uten NAT. (NAT = network address translation altså omadressering til lokale adresser.)

Den største fordel med en slik forbindelse det er jo at slike ting som voice og video og forskjkellige serverfunsjoner i utgangspunktet kan fungere problemfritt ut mot internett. (Med mindre at isp filtrer trafikken slik at en del av funksjonene er stengt.)

Ulempen er at PC i utgangspunktet er adresserbar og tilgjengelig fra hele internett.

Hvis man vil bedre sikkerheten vesentlig så bør man innføre en hardwarefirewall med NAT. Hvis man ikke ønsker dette så bør/må man benytte en softwarefirewall på hver av PC'ene enten dette er servere eller arbeidsstasjoner. Den innebygde firewall til Win 2000/XP er nokså enkel, men den er robust.

Tror personlig at jeg heller ville valgt Windows sin innebygde firewall enn for eksempel Zone alarm dersom jeg ikke hadde en hardwarefirewall eller NAT forbindelse i tillegg ut mot internett.

Når det gjelder problemstillingen rundt ip spoofing så er dette etter min mening vanligvis ikke en svært viktig problemstilling.

Noen pakkefilter har filtrering for spoofede avsender ip andre har ikke.

Spoofede ip pakker kan imidlertid ikke være en del av en ordinær 2 veis ip forbindelse, så det er begrenset hva slike spoofede ip pakker kan brukes til.

Man vil vel for eksempel ikke kunne lage remoote logon ut fra spoofede ip pakker.

En NAT forbindelse eller en hardware firewall vil jo vanligvis gi beskyttelse mot både dos angrep og spoofede ip adresser.

Lækkert svar :-)

Selve grunnfunksjonen i de aller fleste firewalls det er som sagt "packet filtering" uansett firewallens pris, fabrikat og type. Typisk for packet filters det er at de behandler og forholder seg til en og en ip pakke. De kan for eksempel ikke forholde seg til opplysninger eller kriterier for sortering som framkommer ved å sette sammen flere datapakker til en fil eller et "filfragment".

Skal man benytte en firewall som undersøker datane på et fil eller dokumentnivå, så behøver man en "application level firewall" dette vil som oftest i praksis si en "proxy server med innebygget application level firewalling" for eksempel proxy delen av Microsoft ISA server eller Squid proxy server for Linux.

Ønsker man for eksempel en firewall som sorterer vekk alle dokumenter som inneholder visse setninger eller ord eller visse domeneadresser så kan dette utføres greit av en proxy firewall.

En packet filtering firewall er i utgangspunktet som oftest vesentlig raskere enn en proxy firewall med hensytn til selve fitreringsfunksjonen. Proxy funksjonen med mellomlagring av inernettinnhold vil allikevell kunne bidra så mye til en hastighetsøkning at proxyfirewall allikevell blir det raskeste alternativ.

For de fleste "normale" filtrerings eller firewallfunskjoner så er det i virkeligheten et "packet filter" man har bruk for og ikke en proxy firewall.

Den maskinen som proxy firewall kjører på vil uansett måtte beskytte seg selv og sine lokale prosesser ved hjelp av et "packet filter" slik at dette vil være i bruk uansett, også dersom det er snakk om en application level eller en proxy firewall.

"En screening router" det er vel stort sett det samme som et harware packet filter ofte i kombinasjon med Nat hvis det dreier seg om en ADSL forbindelse. (For ellers så måtte man kjøpe en hel serie med eksterne IP adresser, slik at man kan lage et "internt subnet" og det koster jo penger.)

Forsøkte å lage litt oppsummering av det som jeg kunne huske i farten som "det viktigste".

Det er ellers mange nyanser av dette og litt forskjellige måter å vurdere disse tingene på og sånn sett ikke noe som er "absolutt rett". Det hele blir ofte en avveining og vurderingssak, kanskje med litt forskjellige "trosretninger" og "relligioner".

Hvis det er andre medlemmer av eksperten som har andre syn på saken så ville det være interessant !!

Ellers - Ved å sette opp en Linux router så har man stort sett muligheten til å prøve ut neste alle de firewalls og filtreringsprinsipper som finnes til en pris av en gammel PC. Pentium 166 og Red Hat 7.3 fungerer bra !!

http://iptables.1go.dk

Langbein, du er kongen.
Men jeg er stadig lidt i tvivl om, hvordan der bliver filtreret på porte. Hvis man for eksempel vil stoppe al indgående trafik fra port 25 (SMTP), så skal man så vidt jeg kan forstå op og have en applikations firewall, som for eksempel en proxy, og det er ikke nok med en pakkefiltrering. Er det korrekt forstået?
Og er det korrekt, at det er fordi den kan filtrere på applikationslaget, hvorimod en pakkefiltrerering sker på netværks og transportlaget?
Endelig; Hvis man har en applikationsfirewall a la proxy, vil den kunne stoppe angreb som sniffing, session hijacking og lignende?

Så var det godt at du spurte for slik er det ikke :)

Hvis man vil stanse traikk inn eller ut dvs tl eller fra port 25 så benytter man først og fremst et packet filter og ikke en applikasjonsfirewall. Det er rent teknisk mulig å sette opp en applikasjonsfirewall eller en proxy til å gjøre det samme men et ordinært packet filter gjør nok denne jobben best.

Sniffing kan du egentlig ikke stoppe med noen type firewall. Sniffing vil si at noen tapper datakabelen din for data. Dette er vanligvis enklest å få til inne på Lan. Hvordan nettverket ditt er utformet rent fysisk vil ha en hel del å si. Det er noe vanskeligere å utføre sniffing på moderne (lan) nettverk der man benytter switcher i stedet for hubber. På gamle nettverk med hubber så er det meget enkelt å utføre sniffing. Det er i prinsipp teknisk mulig at noen kan utføre sniffing hos din isp for å se hva du holder på med. Problemet her vil være en stor mengde trafikk slik at dine data drukner i andre sine data. Det vil imidlertid være mulig å sette på et filter slik at det bare er dine data som kommer fram. Det er kanskje ikke sansynlig at en isp har tid eller råd til å holde på med slik overvåking i større omfang.

Hvis man skal stanse sniffing og hijacking (at en annen tar over en påbegynt session) ved hjelp av software så må man/kan man benytte kryptering av dataforbindelsen, for eksempel ssl, ssh eller vpn.

Mail er jo for eksempel ikke noen spesielt sikker forbindelse. Her går jo det meste vanligvis ukryptert. Her vil det være mulig å "plukke data" ved hjelp av en sniffer.

Fantastisk. Tak :)

Men hvad kan en applikationsfirewall så, som en packet filter firewall ikke kan? Udover at undersøge hele dokumenter, som for eksempel et website.

Etter mitt syn i prinsipp og i utgangspunktet ingen ting.

En "application level firewall" inneholder oftest også en proxy funksjon, fordi dette uansett følger som en nødvendighet ut fra virkemåten til "application level firewall". Den er nærmest pr definisjon nødt til å mellomlagre "komunikasjonsresultater" for å kunne utføre de logiske operasjoner på disse som man ønsker. Det vil si at den er bygget opp rundt en "proxy funksjon" (= "mellomlagrings fukksjon").

"Proxy" betyr egentlig noe slikt som "fullmektig". Når man benytter en "proxy" til å kommunisere ut mot internett så blir forbindelsen ut mot internett mere "indirekte". Man oppnår på denne måten en større grad av "anonymisering" av den virkelige bruker.

Det er for eksempel i prinsipp mulig å sette opp en proxy server i Canada eller i Tyskland for en virksomhet i Danmark.På denne måten vil kunne oppnås en høy grad av anonymisering av internetttrafikke til den danske virksomheten ved at for eksempel alle web servere vil logge ip adressen til proxy serveren i canada eller i tyskland i stedet for de virkelige ip adressene i Danmark.

Når web trafikken anonymiseres og gjøres "indirekte" på denne måten så vil dette gjøre oppgaven vanskeligere for eventuelle hackere som vil inn.

NAT gir imidlertid også en viss form for anonymisering ved at alle brukere utad blir logget som den samme eksterne ip adresse. Det vil kunne framgå av web server logger og annet at man har hatt besøk fra "firma x" i Danmark. Hvem den interne PC eller bruker er vil man ikke kunne se.

Hvis man ikke benytter NAT slik at man i stedet deler ut et "knippe" eksterne ip til de interne brukere, så vil det ute på internett være i stand til å følge med i og kartlegge internettbruken til den enkelte maskin og den enkelte medarbeider. I forbindelse med dette så har man for eksempel utviklet såkalte "spyware programmer" som for eksempel kan følge med visse gratis nytteprogrammer, for eksempel kasaa. Spyware programmer vil kunne settes opp til å sladre om brukerens internettvaner og hva som befinner seg bak en mere eller mindre anonym proxy eller nat forbindelse. 

I forhold til en privat hjemmeoppkopling via adsl så vil jeg mene at det har lite for seg å benytte en "application level firewall" med mindre at man ved hjelp av dette er i stand til å "speede op" internett forbindelsen. Bruker i denne "skrivende stund" en intern Sqid proxy med "application level firewall" inne på Lan men rent teknisk og funsjonsmessig så mener jeg dette egentlig bare er "tull og tøys". Har satt opp dette bare for å teste ut. Når det gjelder selve firewall fuksjonaliteten så ligger denne stort sett i harware packet filter dvs den som er innebygget i adsl modemet og i nat forbindelsen pluss de software firewalls som ligger inne på servere og workstations.

Hvis det er noen at ekspertens brukere som kjenner til andre forskjeller eller funksjoner til en "application level firewall" så ville det være interessant med en kommentar. Virkeligheten forandrer seg jo som kjent hele tiden i hvert fall innenfor området datasikkerhet.

Jeg er lige nødt til at kommentere applikations firewall, da jeg ofte roder med et konkret problem, som en applikations firewall kan løse - men ingen andre.

Hvis der foregår noget trafik imellem en klient og en server, hvor serveren i DATAdelen af tcp-pakken siger, at "nu laver vi et portskifte til port xxxx", så kan en procy firewall IKKE klare dette, hvorimod en applikations firewall, som kender protokollen er i stand til at gennemføre portskiftet.

Dette sker f.eks. i Oracle sql*net, hvis databasen er sat op som en multithreded server

takker mange gange for de flotte og udførlige svar :)

Hei lap !!

Interessant kommentar du har fordi du jobber med disse tingene mens jeg for det meste leser bøker og tester ut tingene i laboppsett. (Min bransje er egentlig mere over mot teknisk kybernetikk, dvs industriell automasjon mens dette andre er mere en slags hobby, samtidig som også data og nettverksteknologien gjør stadig mere inntog innefor automasjonsområdet hvilket er grunnen for "hobbyen". Det er jo snart ikke noen forskjell på "vanlige nettverk" og nettverk for automasjon.)

Når det gjelder begrepet "Aplicationlevel firewall" hva vil du egentlig legge i dette, rent konkret ?? En proxy vil vel ofte også kunne fungere som en "aplication level firewall" ?? Her er det vel slik at prinsippene for en aplication level firewall som Squid når denne er konfigurert for å fungere slik, i kombinasjon med Netfilter/Iptables egentlig fungerer ganske likt med prinsippene bak MS ISA server som også bygger på en kombinasjon av packet filter og proxy med "application firewalling" ?? Enig/uenig ?? Må tilstå at jeg ikke har testet ISA serveren, men jeg har da lastet ned Microsoft sin dokumentasjon, og jeg synes da beskrivelsen minner temmelig mye om det som man kan få ut av en konbinasjon mellom netfilter/iptables og Squid.

Hvilke andre "aplication level firewalls" kan man egentlig snakke om som eksempel ??

Man kunne for eksempel tenke seg at det fantes "application level firewalls" der proxy delen er "mindre tydelig" eller framtredende rent funksjonelt, men noen grad av proxy fynksjon må der vel være ?? Noen eksempler på merker eller typer ??

Slik som jeg som hovedregel ville dele inn i grupper mellom "packet filter" og application level firewall" så ville jeg si at hovedskillet går mellom pakket filter sitt grunnprinsipp å undersøke ip pakkene enkeltvis mens "application level firewall" undersøker dem "gruppevis" som filer eller filfragmenter.

Ut i fra en slik "grunndefinisjon" så skulle et pakkefileter være i stand til å sjekke for avsender og mottaker ip ut fra header informasjon men ikke for avsender og motaker domene, dette skulle da typisk være en oppgave for en "application level firewall" for eksempel Squid. Dette har jeg testet og det fungerer da.

Men det finnes jo på markedet små "bokser" eller hardwarefirewalls som umulig kan ha databehandlings kapasitet til å foreta en full proxy funksjon a la Squid. Hva i alle dager er egentlig dette og hvordan fungerer dette ?? Kan det dreie seg om det som egentlig er et packet filter med en slags "application level firewalling" tillegg ??

Jeg har sett at de nye revisjonene av netfiltet/ipfilter har fått muligheten til å sjekke datainnholdet i tekststengene, slik at dette gir et packet filter med noe som likner på "application level firewall egenskaper" selv om undersøkelsen av ip pakkene stadig vekk skjer enkeltvis, men da også med undersøkelse av datainnhold i tillegg til headerinformasjon.

Kan det være slik disse nye "boksene" virker at de sjekker for teksstrenger "pakkevis" ??

Hvilken application firewall er det som kan utføre et slikt dynamisk portskifte på basis av innhold i datadelen i ip pakkene ?? Og hvorfor er det da en "application level firewall" all den tid at "packet inspection" stadig vekk skjer "enekeltvis" pakke for pakke ?? De nye revisjonene av netfilter/iptables har vel ikke skiftet over fra å være packet filter til å være en "application level firewall" selv om det nå også er mulig å undersøke for datainnhold ??

Synes det er ting her som jeg ikke har helt oversikt over og som jeg skulle like å vite litt mere om !!! En problemstilling innefor området firewalls er også at veldig mange av de bøkene som er på markedet ble gitt ut allerede for et par-tre år siden slik at de ikke er helt oppdaterte.

Fant muliggens noe her: http://www.sans.org/rr/firewall/app_level.php

Litt her og: http://www.howstuffworks.com/firewall.htm/printable

Samler litt jeg synes ser interessant ut:
http://www.eeye.com/html/Research/Papers/DS20010322.html

http://www.platformlogic.com/products/appfire_exec_summ.pdf

http://niap.nist.gov/cc-scheme/PP_ALFWPP-MR_V1.0.html

http://m-tech.ab.ca/concepts/application_level_firewall.html

http://img.cmpnet.com/nc/1405/graphics/1405f3b.gif
http://www.networkcomputing.com/1405/1405f32.html

Har ellers lest litt gjennom linkene over. Når det gjelder den øverste fra sans.org så viser jo denne at utviklingen går sin gang. Det står jo for eksempel at packet filters ikke kan holde styr på "state of connections" og at de ikke kan undersøke "payload" (Datainnholdet) og at dette følgelig var funksjoner reservert for "application level firewalls". For Linux så forholder det seg jo slik at dette ble endret fra kernel versjon 2.4.x slik at kernel fikk mulighet både for "stateful inspection" og undersøkelse av payload pluss en del andre egenskaper som kanskje skulle tro ville være reservert for "application level firewalls".

En annen interessant tanke - hvordan fungerer egentlig slike firewalls som Zonealarm ??? Kan packet inspection her være integreert inn i kernel prosessen slik at den  inspiserer packets ut fra et "network layer" ?? Synes ikke det virker videre sannsynlig (???) (På grunn av at det neppe vil være enkelt/mulig å integrere et "applikasjonsprogram" så tett inn i kernel prosessen.)

Vil dette da si at gratis versjonen av Zone alarm ut i fra sin funksjon og virkemåte faktisk er en "application level firewall" mens at den innebygde firewallfunksjon i Windows XP faktisk er et "packet filter". Ville faktisk tro det. (???)

Noen ideer eller kommentarer ??

Hei Langbein

Jeg er grundlæggende enig i din opdeling. En applikationsfirewall kunne f.eks. være en Checkpoint firewall-1. Denne er grundlæggende en proxy-baseret firewall, men når der opsættes regler, så foregår det ved, at du fortæller, at trafik til f.eks. sql*net er tilladt.

I dette tilfælde åbner du hverken en almindelig proxy (eller port forwarder) men i virkeligheden loader du en service, hvor al trafik til port 1525/tcp transporteres igennem.

Stateful inspection under linux kan gøre nogenlunde det samme, men sådan som jeg ser det, så er iptables ikke i stand til at reagere på dataindholdet med meget andet, end "afvis", "ok" osv. - den kan ikke bruge de data, som den ser aktivt.

Checkpoint læser data i pakken(pakkerne - og reagerer ud fra data. Rent faktisk kører sql*net på port 1525 uanset om der sendes et portskifte i pakken eller ej - altså skal der også kunne ske direkte gennemstilling.

For mig at se er en application level firewall en server, som kender de konkrete applikationer, som transporterer data igennem firewall. Det kunne f.eks. være en firewall, som ved nøjagtig hvordan kazaa opfører sig - og vil være i stand til at stoppe for det, selvom det kører igennem port 80 (tidligere diskussioner :-)

Jeg er også enig i, at WinXP firewall er et pakkefilter - du kan åbne og lukke for porte. Zonealarm kan du reelt set også åbne og lukke for porte - ok, du kan også sige hvilke programmer, som har log til at slippe igennem, men igen kender fw ikke typen af trafik - og er derfor (for mig at se) et pakkefilter - og ikke intilligent.

Så jeg er uenig med det på et punkt - squid er ikke en app.level firewall. Squid er alene en proxy (på dansk oversætter jeg det gerne til "hjælpende hånd"), som kan sende pakker videre - og cache web-sider.

Jeg vil dog sige, at jeg er "super-generalist" - og ikke certificeret det ene eller det andet (endnu - har forhåbentlig en certificering på vej :-), men jeg har 15 års on-site erfaring.

Hei igjen !!

Takker for interessant og utdypende kommentar !!

Tror jeg ser litt av nyansene og er vel enig i det meste, unntatt med hensyn til Squid.

Har satt opp Squid (i laboppsett) til å ivareta stort sett de samme pakkefiltrerings funksjonene som iptables. Dessuten ble eksperimentert med div andre ting slik som foreksempel utestegning av visse domener. Husker ikke sikkert om jeg også satte opp filtrering for datainnhold, men jeg tror det. Konfigureringen for en "basic Squid er" imidlertid temmelig omstendig og tungvint ved at man må skrive inn firewall reglene inn i selve konfigurasjonsfeltet. Det skal også finnes en slags "konfigureringsfrontend" som skal kunne automatisere og forenkle oppsettet av firewallegenskaper for Squid, men denne har jeg aldri prøvd.

Hører ellers til dem som mener at Internettet bør være så åpent som mulig og at enhver filtrering som går på innhold eller domener bør være bannlyst. La derfor ikke særlig vekt på å finne videre ut av disse filtrereingsegenskapene annet enn å sette opp for testing og se at det fungerte.

En annen sak eller problemstilling som jeg har kommet i tanker om i forbindelse med dette spørsmålet og linkene over:

Jeg har alltid tenkt på begrepene "application firewall" og "application level firewall" som to skrivemåter for det samme.

Mon det kanskje slettes ikke er slik og at en "application level firewall" er en firewall som utfører generelle firewall oppgaver ut i fra en "application level virkemåte" (altså uten å være integrert inn mot kernel prosessene), mens på den annen side en "application firewall" er en firewall som er laget slik at den ivaretar spesialiserte firewall funksjoner i forhold til den enkelte applikasjon som den skal foreta firewalling i forhold til. Enig ???

Ellers å er det jo sant at iptables i utgangspunktet ikke er i stand til å gjøre stort annet enn "DROP" og "ACCEPT".

Men den kan jo også skrive til fil. Dette benyttes jon vanligvis bare til å føre firewall log. Mon det kunne vært mulig å avlede andre funksjoner ?? Har aldri prøvd.

Jeg tror (men vet ikke) at det er mulig å blande iptables syntaks med mere tradisjonelle eller generelle script kommandoer, slik at man kan få ut mere spesialiserte ting. Har aldri ekperimentert med dette selv, men mener å huske å ha sett eksempler på at andre har laget slike ting.

Kall til operativsystem eller funksjoner basert på lesing av filinnhold ville ellers uansett bli så langsomme at det er nokså begrenset hva de kan anvendes til.

"Konfigureringen for en "basic Squid er" imidlertid temmelig omstendig og tungvint ved at man må skrive inn firewall reglene inn i selve konfigurasjonsfeltet"

Jeg mener selvfølgelig "konfigurasjonsfilen"