Vad är väl en brandvägg i nätverket (del 2)
(Publicerad 2009-05-06)
Förra gången diskuterade vi hur man kan se det som att brandväggar behövs när man inte kan lita på sina datorer. Är det verkligen så enkelt?
Ja. Problemet är att detta inte hjälper dig hela vägen eftersom du fortfarande måste lita på applikationerna som kör på dessa datorer när de går att nå genom brandväggen. (Naturligtvis måste du lita på din personal oavsett.) I förra delen sa vi ju att nya applikationer kan dras igång på datorer utan att den som är ansvarig vet om det. Brandväggar är dennes sätt att skydda sig mot sådant. Tyvärr är applikationer sårbara emellanåt och man kan inte lita på en sårbar applikation. Så här ser din brandvägg och webbtjänst ut idag:
Klienten (webbsurfaren) skickar sina paket rakt genom brandväggen hela vägen fram till webbservern. En av brandväggens huvuduppgifter är att släppa fram sådan trafik.
Nu kanske du säger att du kör ISA Server, att din brandvägg normaliserar HTTP-trafik eller liknande. Det är ju förstås bra; om webbservern har sårbarheter i sig (nyare IIS och Apache skulle klara sig fint) så behöver den inte bli tagen på sängen av en 8000 tecken lång User-Agent. Sådana brandväggar har möjlighet att skydda webbservern.
Som bilden tydligt visar slutar det dock inte där. Inkommande trafik kan te sig helt normal och följa webbserverns protokoll (HTTP) till punkt och pricka medan den skulle innebära en katastrof för applikationen. En vanlig brandvägg, även en som förstår sig på HTTP, förstår sig inte på applikationens behov och begränsningar. Samma sak gäller i nästa steg mot databasen, varken applikationen eller brandväggen förstår sig på databasen. (Det är för övrigt därför vi har problem med SQL injection idag.)
Det här är förstås inget som stannar vid webbapplikationer. En brandvägg har precis lika liten uppfattning om hur andra komplicerade eller specialgjorda protokoll fungerar. Det finns givetvis funktioner i dyra brandväggar som kan kolla SMTP, FTP eller till och med andra protokoll efter fuffens. Tyvärr beror detta på att dessa protkoll är triviala jämfört med exempelvis kommunikationen mellan webbläsare och applikationer som Gmail eller EPiServer.
Är det något du ska ta med dig från den här blogposten så är det följande:
--
Stefan Pettersson
Förra gången diskuterade vi hur man kan se det som att brandväggar behövs när man inte kan lita på sina datorer. Är det verkligen så enkelt?
Ja. Problemet är att detta inte hjälper dig hela vägen eftersom du fortfarande måste lita på applikationerna som kör på dessa datorer när de går att nå genom brandväggen. (Naturligtvis måste du lita på din personal oavsett.) I förra delen sa vi ju att nya applikationer kan dras igång på datorer utan att den som är ansvarig vet om det. Brandväggar är dennes sätt att skydda sig mot sådant. Tyvärr är applikationer sårbara emellanåt och man kan inte lita på en sårbar applikation. Så här ser din brandvägg och webbtjänst ut idag:
Klienten (webbsurfaren) skickar sina paket rakt genom brandväggen hela vägen fram till webbservern. En av brandväggens huvuduppgifter är att släppa fram sådan trafik.
Nu kanske du säger att du kör ISA Server, att din brandvägg normaliserar HTTP-trafik eller liknande. Det är ju förstås bra; om webbservern har sårbarheter i sig (nyare IIS och Apache skulle klara sig fint) så behöver den inte bli tagen på sängen av en 8000 tecken lång User-Agent. Sådana brandväggar har möjlighet att skydda webbservern.
Som bilden tydligt visar slutar det dock inte där. Inkommande trafik kan te sig helt normal och följa webbserverns protokoll (HTTP) till punkt och pricka medan den skulle innebära en katastrof för applikationen. En vanlig brandvägg, även en som förstår sig på HTTP, förstår sig inte på applikationens behov och begränsningar. Samma sak gäller i nästa steg mot databasen, varken applikationen eller brandväggen förstår sig på databasen. (Det är för övrigt därför vi har problem med SQL injection idag.)
Det här är förstås inget som stannar vid webbapplikationer. En brandvägg har precis lika liten uppfattning om hur andra komplicerade eller specialgjorda protokoll fungerar. Det finns givetvis funktioner i dyra brandväggar som kan kolla SMTP, FTP eller till och med andra protokoll efter fuffens. Tyvärr beror detta på att dessa protkoll är triviala jämfört med exempelvis kommunikationen mellan webbläsare och applikationer som Gmail eller EPiServer.
Är det något du ska ta med dig från den här blogposten så är det följande:
- En av brandväggens viktigaste uppgifter är att släppa fram trafik till webbservern.
- Brandväggar avgör vilka applikationer som ska vara nåbara.
- En brandvägg kan inte skydda en applikation eftersom den inte förstår dennes behov och begränsningar.
--
Stefan Pettersson
Kommentarer
Trackback
