Napjainkban a számítógépes hálózatok növekedésével, az Internet felhasználók számának gyors emelkedésével egyre növekszik a kockázat is, melyet a hálózatok összekötése, különösképpen saját hálózatunk Internetre kötése jelent. Amint a való világban is ajtókat, rácsokat, riasztókat és hasonló biztonsági eszközöket alkalmazunk az illetéktelen behatolókkal szemben, a virtuális világban is hasonló lépésekkel tudunk védekezni. Egyszerű hasonlattal élve ha hálózatunkat védelem nélkül kapcsoljuk az Internetre, az olyan, mintha irodánk bejáratát legfeljebb egy függünnyel vagy lengőajtóval választanánk el az utcától. Egyszóval bárki aki arra jár és be akar menni, be fog tudni menni. És ahogyan az utcán sétálva is végigpróbálhatjuk a kapukat, nyílnak-e, az internetes felhasználó is végigpróbálhatja a hálózatokat, hogy be lehet-e jutni. Ez utóbbi ráadásul sokkal kisebb erőfeszítéseket jelent, sokkal több ajtó próbálható végig sokkal kevesebb idő alatt.

Mi a tűzfal?

Ahogy az irodánkat zárható ajtóval és riasztóval látjuk el, halózatunkat tűzfalakkal védhetjük. A tűzfal alapvetően egy határvédelmi eszköz. A határokat, melyeket védeni kell pedig mi szabjuk. Irodai példánkhoz visszatérve a határ lehet az iroda bejárata, irodánkon belül a főnok szobája, a pénztár vagy a páncélszekrény. A valós életben többek között ezeket védjük külön. A hálózat szempontjából a határok az internetes kapcsolatunk, modemes kapcsolat más rendszerekhez, a hálózaton belül a könyvelést végző számítógépek vagy más, belső bizalmas adatokat használó hálózati szegmensek. A tűzfal mint határvédelmi eszköz ezeket tudja elválasztani egymással. Akinek van joga belépni, azt beengedi, akinek nincs azt távoltartja, ha valaki illetéktelenül próbál behatolni "bekapcsol" a riasztó.
természetesen tökéletes védelem nem létezik. Ahogy a zárakon álkulcsokkal, a páncélszekrény burkolatán robbanószerekkel át lehet jutni, úgy a tűzfalakon is sikerülhet ugyanez. A tűzfalak egymástól főleg abban a tulajdonságukban térnek el, hogy mennyire biztonságosak, mennyire tudják ellenőrizni, hogy tényleg jogosult-e valaki áthaladni, mennyire lehet őket becsapni.

A tűzfalak alapvető csoportjai

A határvédelmi rendszerek fejlődése során számos megoldás született. Napjainkban alapvetően két csoportra sorolhatjuk a tűzfalakat: csomagszűrő eszközök és applikációs tűzfalak. A besorolást az alapvető működési elvük alapján végeztük, mivel ez az a legfontosab tulajdonság, mely a biztonságot meghatározza.

Csomagszűrő rendszerek

A csomagszűrő eszközök egyszerűbb megoldások, így az általuk nyújtott védelem is kisebb. Működési elvük szerint a hálózati forgalom minden egyes továbbítandó csomagját egyenként ellenőrzik és csak a csomag fejléce által hordozott információk alapján hozzák meg a döntést. Az IP alapú hálózatokban egy-egy csomag csak alapvető, annak továbbításához szükséges információkat hordozza fejlécében. Ilyen információk a csomag protokollja (TCP, UDP, ICMP, ESP, stb.), a feladó és a címzett IP száma, protokolltól függően az allprotokoll típusa (pl. ICMP esetén) vagy a feladó és a címzett portja (pl. TCP és UDP esetén), ezen kívül egyes protokollok hordozhatnak további információkat is, mint a TCP, ahol a csomag fejléce tartalmazza azt is, hogy az egy kapcsolati kérés vagy egy már létrejött kapcsolathoz tartozik. A modernebb un. állapotfüggő (stetefull) csomagszűrők képesek emlékezni egy-egy áthaladt csomagra, így egy kimenő TCP kapcsolati kérésre érkező választ felismerhet, és általános szabályok helyett állapotfüggő szabályokat lehet hozni. Ez különösen hasznos azon protokolloknál (pl. ICMP, UDP), ahol a kommunikáció nem kapcsolat alapú, azaz mindkét fél adatokat küld, de előtte nincs kapcsolatfelépítés. Ilyenre példa a DNS kérés (UDP 53-as port). Az állapottartás lehetővé teszi ezen protokollok kommunikációjának nyomonkövetését is.
A csomagszűrő ezen információk alapján kell meghozza döntését. Lássunk erre egy példát. Ha egy csomagszűrő eszközön szeretnénk megengedni, hogy a web böngészés működjön, azaz HTTP protokollal lehessen webszervereket elérni a következő szabályokat tudjuk felállítani: a web szerverek általában a 80-as TCP porton érhetők el, így a hálózatunkból kifelé engedélyeznünk kell minden 80-as portra menő TCP csomagot. A webszerver biztosan nem akar TCP kapcsolatot indítani a mi hálózatunkba, így befelé a TCP kapcsolati kéréseket nem, a többi 80-as portról érkező TCP csomagot viszont be kell engednünk. Minden más forgalmat tiltunk (a példa kedvéért eltekintünk az kapcsolat működéséhez emellett elengedhetetlen protokolloktól). Ezekkel a szabályokkal elérhető minden 80-as porton működő webszerver, és minden kliens a hálózatunkban el is éri azokat.
Felmerül a kérdés, hogy mi van a nem 80-as porton elérhető webszerverekkel? Ha egy webszerver a 81-es porton érhető el, akkor annak eléréséhez engedélyeznünk kell a 81-es portra is a fentieket. Itt természetesen megtehetjük, hogy csak az ismert IP számú szerverre engedjük a 81-es portot, de egy idő mulva az ilyen kiegészítések átláthatatlanná tehetik szabályrendszerünket, és egy átláthatatlan biztonsági rendszer nem ellenőrizhető, így annak biztonsága kétséges. A másik probléma a csomagszűréssel, hogy ha egy szerveren a 80-as porton nem webszerver, hanem pl. egy e-mail szerver (SMTP) működik, akko a belső hálózatunk azt a szervert eléri SMTP protokollal is, holott mi csak a HTTP protokollt szerettük volna megengedni. Ez azért baj, mert ha egy betörő indirekt módon, egy trójai program hálózatunkba juttatásával eléri, hogy az ő általa üzemeltetett szerver 80-as portjára kapcsolódjon a trójai program egy saját ismeretlen protokollal, ezzel egy alagutat tud nyitni hálózatunkba. Természetesen itt is alkalmazhatnánk a fenti módszert, azaz egyes IP címekre szabályozni az elérést vagy nem elérést, de a fenti problémához (átláthatatlanság) vezetne ez is, ráadásul nem tudjuk előre, mely gépen van a 80-as porton olyan szolgáltatás, amit mi tiltani akarunk.
Érdemes itt kitérni, hogyan juthat be hálózatunkba az említett trójai program. A legegyszerűbb két lehetőség a belső felhasználókat ártatlanul kihasználni erre a célra. Küldhetünk nekik e-mail-t, mely tartalmazza a trójai programot, és ha a felhasználó azt elindítja, észrevétlenül kezd dolgozni. A valós életben számos ilyen vírus (un. internetes féreg / worm) terjed a hálózatokon. Volt köztük olyan, mely véletlenszerűen .doc és .xls kiterjesztésű fájljainkat küldte e-mailben a címlistánkban szereplő címekre. A másik módszer a böngészőprogramokban fellehető biztonsági réseket kihasználni. Ha a felhasználó a betörő honlapjára téved, onnan a biztonsági rés miatt bejuthat a trójai program.
Ezen problémákra a megoldást az applikációs tűzfal jelenti. A fentiek ellenére a csomagszűrés egy mai modern tűzfal-rendszer alapvető részét képezi, de csak részét, azaz a teljes védelem az applikációs tűzfal és a csomagszűrés együttes alkalmazásával érhető el.

Applikációs tűzfalak

Az applikációs tűzfal magasabb szinten végzi a működését mint a csomagszűrő rendszer. Itt már nem csak a csomagok fejlécében hordozott információkat, hanem a csomagban található adatokat, pontosabban a teljes adatfolyamot egészében vizsgáljuk. Itt a tűzfal szoftver proxyként működik, így a kéréseket értelmezi, és saját nevében küldi tovább, és ezt teszi a kapott válaszokkal is. Visszatérve a fenti példánkhoz, ahol a web böngészést szeretnénk lehetővé tenni, azt applikációs tűzfallal úgy tehetjük meg, hogy a 80-as TCP porta menő kéréseket a tűzfalon feldolgozzuk. Mivel a teljes adatforgalomhoz hozzáférünk, ellenőrizhezjük, hogy a kimenő adat egy szabványos HTTP kérést trartalmaz-e. Amennyiben igen, továbbítjuk, ha nem, visszautasítjuk. A kapott válasznál szintén ellenőrizhetjük, hogy az szintén szabványos HTTP válasz-e. Ezzel kizártuk, hogy a HTTP protokollon kívül mást is (pl. SMTP vagy egy trójai program saját ismeretlen protokollja) átjuthasson a tűzfalon. Itt még nem vizsgáltuk az átküldött adatokat, csak a protokollt. Ha az adatokat is ellenőrizni szeretnénk (pl. e-mail esetében vírus ne juthasson át), akkor tartalomszűrésre is szükségünk van, mely az applikációs tűzfal mellé kiegészítőként társulhat.
Mivel a teljes protokollt ellenőrizzük, lehetőségünk van olyan döntéseket hozni, melyekhez a protokoll által hordozott információkra is szükség van. Ilyen lehet a HTTP esetében a kért URL, ahol tulthatunk címeket (pl. a sex szót tartalmazó URL-eket), vagy kiszűrhetünk a böngésző által elküldött információkat (pl. böngésző típusa, operációs rendszer verziója, cookie-k). Ugyanígy pl. egy FTP szerver védelmekor megadhatjuk, hogy authentikációra nincs mód, csak anonymous ftp lehetséges, ezzel elejét véve a belépési kísérleteknek (jelszó próbálkozásoknak).
A modern applikációs tűzfalak moduláris felépítésűek. Ez azt jelenti, hogy egyes általa támogatott protokollok egymásba ágyazhatók. Erre akkor van szükségünk, ha egy átengedett protokollban egy másik protokollt szeretnénk átengedni. Az egyik legáltalánosabb péda erre a HTTPS, ahol a HTTP protokoll az SSL vagy TLS protokollba ágyazva halad. A HTTPS pedig egy fontos protokoll, hiszen ez biztosítja, hogy a böngésző és a szerver közötti kommunikáció titkosított legyen. A titkosított csatorna a tűzfal szempontábol viszont kockázat, hiszen ha ténylegesen biztosítjuk a titkosságot a külső szerver és a kliens között, nem tudjuk mi folyik a kódolt csatornában, ahol így mehet bármi. Ha a tűzfalon szeretnénk tudni, hogy a HTTPS kommunikáció ténylegesen SSL-be (TLS-be) ágyazott HTTP protokoll, a kódolt csatornát ki kell bontani. Itt használjuk fel az applikációs tűzfal modularitását. Egyrészt a 443-as TCP porton (HTTPS port) menő kommunikációt SSL-ként (TLS-ként) kezeljük, dekódoljuk, a dekódolt adatfolyamot pedig HTTP-ként kezeljük, és így ellenőrizzük. Ha mindekét ellenőrzésnek megfelelt az adatfolyam, újra titkosítjuk és továbbítjuk a kért irányba. Ezzel ugyan megsértjük a kliens-szerver közötti biztonságot, a kliens és a szerver nem fogják látni egymás hitelességi bizonyítványait (mindketten a tűzfal hitelességi bizonyítványát látják csak), viszont az adatcsatornát tudtuk ellenőrizni. Ha a hitelességi bizonyítványok ellenőrzése szükségszerű, akkor ezt a tűzfalon kell elvégezni. Ez utóbbi lehetőséget nyújt arra, hogy a hitelességi ellenőrzést a tűzfalat üzemeltető biztonsági szakember végezze el a felhasználó helyett.
Mivel az applikációs tűzfalnak ismernie kell az általa továbbított protokollt, csak azon szolgáltatások ellenőrzésére képes, melyeket kifejezetten ismer. A csomagszűréssel szemben (ahol egy port megnyitása elegendő szokott lenni egy szolgáltatás elérhetővé tételére) itt minden egyes protokollt egyenként definiálnunk kell. természetesen így nem gond a szokatlan portok kezelése sem, hiszen a példánkban említett 81-es portot ha hozzáadjuk a HTTP protokollt használó protokhoz, máris működik a web böngészés a 81-es porton működő web szerver felé is, és garancia van rá, hogy a protokoll tényleg HTTP.

Megoldások Linux alapon

A Linux operációs rendszer kernel szinten támogatja az állapotfüggő csomagszűrést, valamint számtalan applikációs tűzfal programot találunk rá. A pilátus-Comp Kft. az elérhető applikációk közül kiválogatta a legjobbakat, és biztonsági megoldásainkat ezek segítségével végezzük. Ezen programok ügyfeleinknél már számos esetben bizonyítottak.
Jelenleg applikációs szinten az alábbi főbb protokollokat tudjuk támogatni: HTTP, SSL (TLS), FTP, SMTP, POP3, IMAP, DNS. A moduláris rendszerekkel ezek természetesen egymásba ágyazhatók, így az SSL+HTTP segítségével a HTTPS protokoll is elérhető, vagy az SSL+POP3-al a POP3S. A fentiek csak a főbb interneten használt protokollok. Ezek mellett más protokollok támogatását is meg tudjuk valósítani.