---

Hvad er det helt præcis der adskiller en firewall med statefull
inspection fra en forbindelsesorienteret NAT router?

--
/Wegge <http://outside.bakkelygaard.dk/~wegge/>
echo mail: !#^."<>"|tr "<> mail:" dk@wegge

---

In article <m2fzdfx6jz.fsf@obelix.bakkelygaard.dk>, Anders Wegge Jakobsen wrote:
> Hvad er det helt præcis der adskiller en firewall med statefull
> inspection fra en forbindelsesorienteret NAT router?

Det er 2 forskellige ting, der har et par ting til faelles. En firewall
har typisk en state-tabel. Naar der oenskes en forbindelse oprettet
og denne godkendes indsaettes der i tabellen en state for forbindelsen.
Ideen er at man foerst konsulterer state-tabellen foer man checker
regelsaettet. Har man en state, accepterer man trafikken.

NAT er translation af IP-headeren saa netvaerk omskrives. For at holde
styr paa hvem man har omskrevet til hvad holder man en NAT-tabel.
Ankommer der data slaar man op i NAT-tabellen for at se om der
eksisterer en maskine bag routeren der har en forbindelse og derfor
oensker de data. Efter re-omskrivning af pakkerne forwardes de.

Firewalls i sig selv omskriver typisk ikke IP-headere, men gennemtvinger
en politik om hvilke forbindelser der maa oprettes til hvad. Man har
som regel ogsaa de to tabeller adskilt i kombinerede loesninger jeg
har set paa, men man kunne vel i princippet godt have dem i samme tabel.



--
j.

---

Anders Wegge Jakobsen wrote:

> Hvad er det helt præcis der adskiller en firewall med statefull
> inspection fra en forbindelsesorienteret NAT router?

Det er lidt tid siden, men som jeg husker det er det noget i stil med:

En forbindelsesorienteret NAT router (også kaldet et packet filter)
beskæftiger sig kun med lagene op til TCP og UDP (samt nogle af de andre
protokoller). En stateful inspection firewall kan have indbygget moduler
som fortolker applikationsprotokollerne og tager stilling til hvad der
skal ske på grundlag af dette.

Det betyder at man f. eks. i en stateful inspection firewall kan
indsætte en regel der hedder "blokér alle HTTP-GET-requests til URL'en
/regnskabet/", eller f. eks. afvise mails som indeholder virus. Det kan
man ikke med et packet-filter.

Et krydscheck på Webopedia siger mig at jeg ikke er helt galt på den:

http://www.webopedia.com/TERM/S/stateful_inspection.html

Mvh. Michael.

---

Michael Zedeler wrote:
> Anders Wegge Jakobsen wrote:
>
>> Hvad er det helt præcis der adskiller en firewall med statefull
>> inspection fra en forbindelsesorienteret NAT router?
>
>
> Det er lidt tid siden, men som jeg husker det er det noget i stil med:
[..]
>
> http://www.webopedia.com/TERM/S/stateful_inspection.html

Du er helt forkert paa den. Det er 'content inspection' der tillader at
man afviser HTTP requests baseret paa URLer, eller mail baseret paa
dennes indhold.

Se <slrnc2o48e.l5a.jlouis@miracle.mongers.org> for det korrekte svar paa
Anders' spoergsmaal.


--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

---

In article <402c1c5c$0$149$edfadb0f@dtext02.news.tele.dk>, Alex Holst wrote:
> Du er helt forkert paa den. Det er 'content inspection' der tillader at
> man afviser HTTP requests baseret paa URLer, eller mail baseret paa
> dennes indhold.

Stateful inspection dækker efterhånden over hvad som helst.

For at være enige over hvad det dækker over skal man først være
enige om hvilket lag man snakker om.


--
Mvh.
Christian E. Lysel
http://www.spindelnet.dk/

---

Christian E. Lysel wrote:
> In article <402c1c5c$0$149$edfadb0f@dtext02.news.tele.dk>, Alex Holst wrote:
>
>>Du er helt forkert paa den. Det er 'content inspection' der tillader at
>>man afviser HTTP requests baseret paa URLer, eller mail baseret paa
>>dennes indhold.
>
>
> Stateful inspection dækker efterhånden over hvad som helst.

Det kan der vaere noget om, dog skal det vaere muligt at oprette en
state -- noget som Michael Zedeler's eksempel ikke egner sig til:

'Det betyder at man f. eks. i en stateful inspection firewall kan
indsætte en regel der hedder "blokér alle HTTP-GET-requests til URL'en >
/regnskabet/"'

Jeg ville kalde ovenstaende for adgangskontrol eller, hvis man presser
den lidt, content inspection, men bestemt ikke stateful inspection.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

---

In article <402e8bff$0$175$edfadb0f@dtext02.news.tele.dk>, Alex Holst wrote:
> 'Det betyder at man f. eks. i en stateful inspection firewall kan
> indsætte en regel der hedder "blokér alle HTTP-GET-requests til URL'en >
> /regnskabet/"'
>
> Jeg ville kalde ovenstaende for adgangskontrol eller, hvis man presser
> den lidt, content inspection, men bestemt ikke stateful inspection.

Ikke enig, selvom jeg også ser det som en misfortolknning.

SPI benyttes ikke til at håndhæve filter reglerne generelt, men
til at tillade tilladte sessioner.

Om en session bliver tilladt ud fra nogle regler om IP adresse, eller
port numre, eller http request er vel sagen ligegyldt. Forskellen
er blov hvilken lag det er implementeret på.

Dog vil der være nogle pratiske problemmer i ovenstående tilfælde,
da man kan pipeline sin http request i HTTP protokollen, således kan
en TCP session, indeholde flere HTTP sessioner.
Men her kan SPI benyttes til at se hvilken tilstand HTTP-sesstionen
er i, og skifter denne tilstand skal regelsættet tage stilling til om det
er tilladt eller ej.

I 90% af alle SPI implementationer er bruges den blot som understøttelser
til et TCP/IP pakke filter. Og hvis det er helt vildt tages der også hånd
om evt. ICMP pakker.

-
Mvh.
Christian E. Lysel
http://www.spindelnet.dk/

---

Christian E. Lysel wrote:

> In article <402e8bff$0$175$edfadb0f@dtext02.news.tele.dk>, Alex Holst wrote:
>
>>'Det betyder at man f. eks. i en stateful inspection firewall kan
>>indsætte en regel der hedder "blokér alle HTTP-GET-requests til URL'en >
>>/regnskabet/"'
>>
>>Jeg ville kalde ovenstaende for adgangskontrol eller, hvis man presser
>>den lidt, content inspection, men bestemt ikke stateful inspection.
>
>
> Ikke enig, selvom jeg også ser det som en misfortolknning.
>
> SPI benyttes ikke til at håndhæve filter reglerne generelt, men
> til at tillade tilladte sessioner.
>
> Om en session bliver tilladt ud fra nogle regler om IP adresse, eller
> port numre, eller http request er vel sagen ligegyldt. Forskellen
> er blov hvilken lag det er implementeret på.

Netop HTTP/1.1 har dog ikke umiddelbart et koncept der hedder 'session'
eller 'state' paa samme maade som TCP har. Man kan, ved at kigge paa
forgaaende HTTP headers, ikke sige om den naeste HTTP request skal
tillades eller ej.

Man kan med server-side applikationer forsoege at *emulere* state over
HTTP, noget som er noedvendigt for f.eks. shopping applikationer.

State-over-HTTP implementeres ved at klienten faar udleveret en unik
cookie, og server-side applikationen saa husker hvilke trin af en
sekvens klienten har udfoert -- men det er stadigt ikke HTTP-states.
Derfor mener jeg at det er forkert at give bruge udtrykket "stateful
inspection" om en almindelig HTTP request der naegtes eller tillades.

Man *kunne* godt forstille sig at nogen byggede en stateful inspection
firewall der forstod (og kun tillod) en specifik HTTP-baseret
applikation men

Ovenstaaende understoettes af RFC 2616 der heller ikke naevner 'state'
eller 'session' som en feature. RFC 2617 goer, men det er authentication
specifikt.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

---

Alex Holst wrote:
> Netop HTTP/1.1 har dog ikke umiddelbart et koncept der hedder 'session'
> eller 'state' paa samme maade som TCP har. Man kan, ved at kigge paa
> forgaaende HTTP headers, ikke sige om den naeste HTTP request skal
> tillades eller ej.

Citat RFC 2616,

....It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext...

> Man kan med server-side applikationer forsoege at *emulere* state over
> HTTP, noget som er noedvendigt for f.eks. shopping applikationer.
>
> State-over-HTTP implementeres ved at klienten faar udleveret en unik
> cookie, og server-side applikationen saa husker hvilke trin af en
> sekvens klienten har udfoert -- men det er stadigt ikke HTTP-states.

Enig. Dette er en tilstand der skabes på applikationslaget. Dvs. et
endnu højere lag.

> Derfor mener jeg at det er forkert at give bruge udtrykket "stateful
> inspection" om en almindelig HTTP request der naegtes eller tillades.

Er det så også forkert at antage at en webserver holde en tilstandstabel
over fx klientes forspørgelser?

> Man *kunne* godt forstille sig at nogen byggede en stateful inspection
> firewall der forstod (og kun tillod) en specifik HTTP-baseret
> applikation men

Enig.

> Ovenstaaende understoettes af RFC 2616 der heller ikke naevner 'state'
> eller 'session' som en feature. RFC 2617 goer, men det er authentication
> specifikt.

Men jeg kan ikke se hvor du vil hen med din argumentation. At
protokollen ikke beskriver en tilstand, er ikke ensbetydende med
at man ikke kan bruge en tilstandstabel når man implementere
protokollen i en klient, server, proxy eller i et firewall filter.

--
Mvh.
Christian E. Lysel
http://www.spindelnet.dk/

---

Christian E. Lysel wrote:
> Men jeg kan ikke se hvor du vil hen med din argumentation. At
> protokollen ikke beskriver en tilstand, er ikke ensbetydende med
> at man ikke kan bruge en tilstandstabel når man implementere
> protokollen i en klient, server, proxy eller i et firewall filter.

Det er netop hvad det betyder. Da HTTP er stateless (og vi er enige om
at der skal en overbygning til for at goere den stateful), er det
umuligt at lave brugbar stateful inspection paa HTTP/1.1 requests. Der
er *ingen* information at oprette/vedligeholde/validere state ud fra.

Jeg tror denne diskussion burde hoere hjemme i netvaerksgruppen, men jeg
keder mig igen. EOD.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

---

Michael Zedeler wrote:

> Et krydscheck på Webopedia siger mig at jeg ikke er helt galt på den:
>
> http://www.webopedia.com/TERM/S/stateful_inspection.html

Hov, jeg laeste lige det link. Hvorfor du begynder at tale om HTTP og
SMTP content inspection efter at have laest den side, ved jeg altsaa
ikke. Siden er korrekt. Din opfattelse af dens indhold er ikke.

--
I prefer the dark of the night, after midnight and before four-thirty,
when it's more bare, more hollow. http://a.mongers.org

---

Alex Holst wrote:

> Michael Zedeler wrote:
>
>> Et krydscheck på Webopedia siger mig at jeg ikke er helt galt på den:
>>
>> http://www.webopedia.com/TERM/S/stateful_inspection.html
>
> Hov, jeg laeste lige det link. Hvorfor du begynder at tale om HTTP og
> SMTP content inspection efter at have laest den side, ved jeg altsaa
> ikke. Siden er korrekt. Din opfattelse af dens indhold er ikke.

Referencer, please. Ellers fører denne her diskussion vidst ikke til noget.

Hvordan tolker du ellers sætningen "An example of a stateful firewall
may examine not just the header information but also the contents of the
packet up through the application layer in order to determine more about
the packet than just information about its source and destination." på
den side som jeg refererer til?

Mvh. Michael.

---

Michael Zedeler wrote:

> Alex Holst wrote:
>
>> Michael Zedeler wrote:
>>
>>> Et krydscheck på Webopedia siger mig at jeg ikke er helt galt på den:
>>>
>>> http://www.webopedia.com/TERM/S/stateful_inspection.html
>>
>>
>> Hov, jeg laeste lige det link. Hvorfor du begynder at tale om HTTP og
>> SMTP content inspection efter at have laest den side, ved jeg altsaa
>> ikke. Siden er korrekt. Din opfattelse af dens indhold er ikke.
>
>
> Referencer, please. Ellers fører denne her diskussion vidst ikke til noget.
>
> Hvordan tolker du ellers sætningen "An example of a stateful firewall
> may examine not just the header information but also the contents of the
> packet up through the application layer in order to determine more about
> the packet than just information about its source and destination." på
> den side som jeg refererer til?
>
> Mvh. Michael.

"Stateful Packet Inspection" (SPI) teknikken refererer i sig selv ikke
til applikations-lags filtrering. Teknikken er skridtet op fra simpel
stateless filtrering, hvor kun IP-headere undersøges. SPI anvender en
state-tabel, til at checke indkommende forbindelser mod allerede
initierede forbindelser på de beskyttede net. Findes der ikke en entry i
FW state-tabellen, smides forbindelses request'en væk.

Flere "stateful"-enablede FW's, såsom Firewall-1, har en forenklet
applikations-lags proxy funktionalitet, der kan undersøge simple
protokoller som HTTP, FTP og SMTP på applikations niveau, altså en art
simpel content filtrering.

http://www.webopedia.com/TERM/S/stateful_inspection.html er dårligt
formuleret, jeg tror det de prøver at sige er ovenstående, altså at SPI
ofte på de større FW's (læs Checkpoint), kombineres med en meget
begrænset form for applikationslags filtrering.

Men selve SPI-begrebet giver ikke en implicit content inspektion som
applikations-lags proxier, det er vigtigt at skelne mellem de to
teknologier.

mvh
/michael

---

Hej Michael,

Michael U. Hove wrote:
> Michael Zedeler wrote:

>> Referencer, please. Ellers fører denne her diskussion vidst ikke til
>> noget.
>>
>> Hvordan tolker du ellers sætningen "An example of a stateful firewall
>> may examine not just the header information but also the contents of
>> the packet up through the application layer in order to determine more
>> about the packet than just information about its source and
>> destination." på den side som jeg refererer til?

> "Stateful Packet Inspection" (SPI) teknikken refererer i sig selv ikke
> til applikations-lags filtrering. Teknikken er skridtet op fra simpel
> stateless filtrering, hvor kun IP-headere undersøges. SPI anvender en
> state-tabel, til at checke indkommende forbindelser mod allerede
> initierede forbindelser på de beskyttede net. Findes der ikke en entry i
> FW state-tabellen, smides forbindelses request'en væk.
>
> Flere "stateful"-enablede FW's, såsom Firewall-1, har en forenklet
> applikations-lags proxy funktionalitet, der kan undersøge simple
> protokoller som HTTP, FTP og SMTP på applikations niveau, altså en art
> simpel content filtrering.

Når man sammenligner med applikations-proxyer som er ældre end begrebet
"stateful inspection" kan jeg godt se at der er noget som ikke hænger
sammen. Din forklaring virker bestemt plausibel - jeg overgiver mig

Mvh. Michael.

---

In article <9G4Xb.89313$jf4.5641619@news000.worldonline.dk>, Michael Zedeler wrote:
> Når man sammenligner med applikations-proxyer som er ældre end begrebet
> "stateful inspection" kan jeg godt se at der er noget som ikke hænger
> sammen. Din forklaring virker bestemt plausibel - jeg overgiver mig

proxy og inspection er to vidt forskellige ting.

En proxyserver har typisk to TCP sessioner, en mellem klient og
proxyen, og en mellem proxy og serveren.

Inspection, kikker "kun" på pakkerne der går igennem en gateway.


--
Mvh.
Christian E. Lysel
http://www.spindelnet.dk/

---

In article <c0i98s$31ga$1@news.cybercity.dk>, Michael U. Hove wrote:
> "Stateful Packet Inspection" (SPI) teknikken refererer i sig selv ikke
> til applikations-lags filtrering. Teknikken er skridtet op fra simpel

Enig, da der ikke bliver refereret til noget som helst lag

> stateless filtrering, hvor kun IP-headere undersøges. SPI anvender en
> state-tabel, til at checke indkommende forbindelser mod allerede
> initierede forbindelser på de beskyttede net. Findes der ikke en entry i

I en ftp session, udføreres inspectionen også i ftp commando strømen
for at fange hvordan data sessionen etableres.

> FW state-tabellen, smides forbindelses request'en væk.

Hvad med statefull packet inspection på MAC laget?

> Flere "stateful"-enablede FW's, såsom Firewall-1, har en forenklet
> applikations-lags proxy funktionalitet, der kan undersøge simple
> protokoller som HTTP, FTP og SMTP på applikations niveau, altså en art
> simpel content filtrering.

Dette er dog implementeret vha. en proxy daemon.

> Men selve SPI-begrebet giver ikke en implicit content inspektion som
> applikations-lags proxier, det er vigtigt at skelne mellem de to
> teknologier.

Enig...det er to vidt forskellige måder at løse et problem på.

--
Mvh.
Christian E. Lysel
http://www.spindelnet.dk/

---

"Anders" == Anders Wegge Jakobsen <wegge@bakkelygaard.dk> writes:

> Hvad er det helt præcis der adskiller en firewall med statefull
> inspection fra en forbindelsesorienteret NAT router?

Jeg takker for de svar der er kommet indtil nu, men jeg synes ikke
jeg er kommet ret meget længere. For at opsummere:

Statefull inspection dækker over en firewall, der inden den tillader
en pakke at slippe igennem, laver et opslag i en state tabel, for at
se om der i forvejen er en forbindelse oprettet fra den sikre side af
firewallen. I rene tekniske termer er der naturligvis en forskel fra
regulær NAT (Hedder det egentlig PAT når en public IP fordeles på
flere private?), men rent sikkerhedsmæssigt kan jeg ikke se hvad
forskellen er.

Er det bare et buzzword i stil med en "stealthed port", eller er der
en finere detalje jeg ikke lige er klar over?

--
/Wegge <http://outside.bakkelygaard.dk/~wegge/>
echo mail: !#^."<>"|tr "<> mail:" dk@wegge

---

Den 15 Feb 2004 00:29:32 +0100 skrev Anders Wegge Jakobsen:
>"Anders" == Anders Wegge Jakobsen <wegge@bakkelygaard.dk> writes:
>
>> Hvad er det helt præcis der adskiller en firewall med statefull
>> inspection fra en forbindelsesorienteret NAT router?
>
> Jeg takker for de svar der er kommet indtil nu, men jeg synes ikke
>jeg er kommet ret meget længere. For at opsummere:
>
> Statefull inspection dækker over en firewall, der inden den tillader
>en pakke at slippe igennem, laver et opslag i en state tabel, for at
>se om der i forvejen er en forbindelse oprettet fra den sikre side af
>firewallen. I rene tekniske termer er der naturligvis en forskel fra
>regulær NAT (Hedder det egentlig PAT når en public IP fordeles på
>flere private?), men rent sikkerhedsmæssigt kan jeg ikke se hvad
>forskellen er.

Nej, det hedder PAT, når man snakker med en Cisco-nørd.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

In article <m2y8r5utnn.fsf@obelix.bakkelygaard.dk>,
Anders Wegge Jakobsen wrote:

> Statefull inspection dækker over en firewall, der inden den tillader
> en pakke at slippe igennem, laver et opslag i en state tabel, for at
> se om der i forvejen er en forbindelse oprettet fra den sikre side af
> firewallen. I rene tekniske termer er der naturligvis en forskel fra
> regulær NAT (Hedder det egentlig PAT når en public IP fordeles på
> flere private?), men rent sikkerhedsmæssigt kan jeg ikke se hvad
> forskellen er.

Ud over en performanceforbedring er der et par ting man kan vinde ved
det:

* Hvis man har en state kan man lade passende ICMP pakker slippe igennem
denne state. Og kun passende ICMP pakker.

* Hvis man har en state ved man ogsaa hvilket vindue sequence numbers
skal ligge indenfor. Det betyder at man kan skaere haardere med hvad
man accepterer.

Der er nok et par stykker mere som jeg ikke kan huske.

--
j.