KFKI RMKI SZHK

Az Internethez kapcsolódva a hálózati betörések ellen védekeznünk kell, mert védenünk kell

• az adatainkat, amelyeket a rendszereinken tárolunk
• a számítógépeink, hálózataink erőforrásait
• a jó hírünket az Interneten

Lehetnek olyan adataink, amelyeket titokban kívánunk tartani (magánlevelezésünk, vagy akár kutatási/fejlesztési adataink). Adataink értékét azok váratlan elvesztésekor becsüljük meg igazán: egészen biztosan nem szeretnénk, ha bármely adatunkat (pl. egy beküldés előtt álló fontos cikkünket) egy betörő véletlenül vagy szándékosan letörölné. Mégha rendelkezünk biztonsági másolattal, az elveszett vagy módosított adatok helyreállítása időt, többletmunkát igényel - akár fontos határidőt késhetünk le miatta.

Számítógépeink (processzoridő, memória, diszkterület, stb.), hálózati erőforrásaink (sávszélesség) pénzbe kerülnek. A betörők ezeket pazarolják, vagy éppen használják el/foglalják le előlünk. Egy betörés után - hacsak nem rombolták le az egész rendszert és nem töröltek le mindent - annak kiderítése, hogy mi történt, mit módosítottak, mit tettek tönkre, ezek helyreállítása, sok-sok emberi munkaórát - erőforrást - igényel.

Az egyes személyek, intézmények jó híre pénzben ki nem fejezhető érték. A betörők a hálózatunkon megszerzett adatokat más hálózatokba való betörésre használhatják fel. Terjeszthetnek rajtunk keresztül illegális, lopott szoftvereket, jogvédett vagy pornográf anyagokat. Önhibánkon kívül vagy sem, nevünk, intézményünk neve tiltó, fekete listákra kerülhet föl, amelyekről azután csak nehezen lehet majd eltávolítani. Noha nem tekinthető szigorúan véve betörésnek, ez jól látható az Internet jelenlegi pestise, az E-mail szemét, a spam elleni harcon: domain-ek, amelyek keresztül spam terjed, a spam ellen küzdők tiltó listáira kerülnek föl és hosszú időre kizáródnak a szabad E-mail forgalomból.

Egy tipikus profit szférába tartozó hálózat védekezésénél szigorúan konfigurált tűzfal rendszereket alkalmaznak, amelyek vagy gondosan kontrollálják-monitorozzák a kifelé irányuló hálózati forgalmat, vagy gyakran teljesen megakadályozzák azt. Az Internet felé nyújtott publikus szolgáltatásaikat olyan rendszerekről nyújtják, amelyek egy tűzfal mögött, de még a második tűzfallal védett belső hálózatukon kívül helyezkednek el (semleges zóna). Ha lehetővé tesznek interaktív belépést, akkor azt csak bizonyos hálózatokról és/vagy csak szigorú ellenőrzés után engedik meg.

Akadémiai hálózatok nagyobb nyitottságot követelnek meg. Felhasználóinknak szükségük van a (majdnem) teljes és korlátozás-mentes Internet elérésre, kutatási eredményeiket, adataikat szintén az Interneten keresztül akarják mások számára szabadon elérhetővé tenni. Csoportok alakulnak, amelyeknek a tagjai csak az Interneten keresztül érintkeznek, kommunikálnak. Konferenciák résztvevői levelezésüket, adataikat távolról is el akarják érni. Ugyanakkor általában nincs elegendő anyagi forrás kereskedelmi biztonsági szoftverek, eszközök beszerzésére, semleges zónák, publikus-nem publikus szerverek beállítására.

Bizonyos esetekben előfordulhat, hogy hálózatunk rendszereit csak individuálisan tudjuk vagy akarjuk megvédeni. Ezt a megoldást választhatjuk akkor, ha kisméretű a hálózatunk még kezelhető számú rendszerrel, amelyeket valóban meg tudunk egyenként védeni. Erre kényszerülünk akkor is, ha az Internet kapcsolatunkat biztosító routerünk nem képes tűzfalként működni és a router valamint a lokális hálózatunk között nincs mód tűzfal gépet elhelyezni.

Melyek lehetnek ekkor a védekezésünk elemei:

• Meghatározzuk, hogy milyen szolgáltatásokat óhajtunk nyújtani az Internet felé. Ezeket kiemelten kezelt rendszereken (kapugépek) nyújtjuk.
• Minimális számú kapugépre törekszünk, mégis lehetőleg maximálisan szétválasztva a szolgáltatásokat. Például két kapugépet használunk: az egyiken az interaktív bejelentkezési lehetőségekkel (telnet, ftp, esetleg WWW, stb.), a másikon a természetes proxy szolgáltatásokkal (DNS, SMTP, esetleg WWW).
• A kapugépeken valóban naprakészen a rendszerekre jellemző összes feltárt és publikussá vált biztonsági problémát megoldjuk.
• Beállítjuk, hogy a többi gép az Internet felé ne nyújtson lehetőleg semmilyen szolgáltatást - ez tűzfal nélkül teljesen nem biztosítható (ping) - és a kritikus biztonsági problémákat ezeken a rendszereken is rendszeresen megoldjuk.
• Központi naplózást és napló-feldolgozást vezetünk be.

A modell nyilvánvalóan rendelkezik hibákkal. Minden egyes gép szabadon látható az Internetről, mindegyik egy-egy gyenge láncszem. Bármelyikre betörve az egész LAN biztonsága sérül. Ha következetesek akarunk lenni, alapvető szolgáltatásokat tiltanunk kell a hálózaton (pl. NFS) és ez nem mindíg keresztülvihető. Igen nehéz meghúzni a határt a még engedett/már tiltott szolgáltatásoknál úgy, hogy mindenki értse és elfogadja mit miért tiltunk és ne legyen kísértés egyes szabályok esetleges belső megsértésére. (Nincs minden egyes gép fölött kezünkben az állandó és teljes kontroll, nincs módunk az egységes védekezési módszer mindenkori betartatására.)

• A tűzfal segítségével betartathatjuk, hogy valóban csak a kapugépeink szolgáltassanak az Internet felé és hogy a közönséges gépek csak kliensként használhassák az Internetet: érvényesíttethejük a „ minden tilos, kivéve amit szabad” elvet.
• Egyetlen ponton teljes kontroll alatt tarthatjuk az Internettel való forgalmunkat.
• Az egész Internet-LAN forgalmunkat könnyebben naplózhatjuk, monitorozhatjuk.

A védekezés mélysége ebből a modellből is hiányzik: ha betörnek egy kapugépre, az egész LAN-ra törnek be. Azonban valóban kellően kisszámú, jól karbantartott kapugéppel, biztonságosnak tekintett protokollok támogatásával és propagálásával minimalizálhatjuk ennek az esélyét.

A tűzfallal védett LAN biztonságát tovább növelhetnénk egy semleges zóna (DMZ: de-militarized zone) kialakításával. A felhasználó-nélküli kapugépek (DNS, publikus FTP, WWW, stb.) ekkor átkerülnek a semleges zónába, amelyet a belső LAN-tól egy második tűzfal választ el: így ha ezekre betörnek, a LAN biztonsága még nem sérül. Az Internetről való interaktív bejelentkezés biztonságát közönséges protokollok (telnet, FTP) esetén nem javíthatjuk azzal, ha az ezeket szolgáltató kapugépeket a DMZ-ben helyezzük át (az Internet ® kapugép közti forgalom lehallgatható): megoldást csak titkosított bejelentkezési módszerek (Sesame, ssh, SRP, stb.) támogatása, alkalmazása jelentheti.

Noha kívánatos lenne, semleges zónák kialakítása az akadémiai/egyetemi hálózatokon ma még általában praktikusan nem lehetséges: nincs elegendő pénz a kellő számú megfelelő számítógép beszerzéséhez. Az akadémiai/egyetemi hálózatokon felépített nagy FTP, WWW archívumok mindegyike (az általában egyetlen) nagy szervergépen üzemel, amelyek még sok lokális felhasználót szolgálnak ki. A pénzügyi források jó ha (az általában pályázatokon nyert) szerverek karbantartását, esetleg lassú bővítését fedezik, nem közel megduplikálásukat.

• Nem igényel további beruházást.
• Egy routert általában könnyebb megvédeni a külső támadásoktól, mint egy általános célú számítógépből kialakított tűzfal gépet.
• Sebesség: csak a router belső látenciája lassítja a forgalmat.
• Kevesebb eszköz, kevesebb lehetséges hibapont.

Ha lehetőség van a router és a belső hálózat közé elhelyezni egy a tűzfal szerepét átvevő célszámítógépet, annak a megoldásnak is vannak előnyei:

• A routereket elsősorban routolásra tervezték. Vannak olyan routerek, amelyek már csupán néhány szűrési szabály bekapcsolásának a hatására teljesítményük drasztikus romlásával reagálnak (80 -90 %-os csökkenés!).
• A hibafelderítés nehezebb, ha egyetlen gép látja el a két funkciót.
• A routerek csupán statikus szűrésre képesek - megfelelő tűzfal szoftverek képesek a TCP kapcsolatok állapotának a figyelésére (stateful firewalls), nyomonkövetésére, amely nagyobb biztonságot eredményez.
• A forráskód birtokában a szoftverhibák gyorsabban kijavíthatók; a speciális igények nagyobb valószínűséggel elégíthetők ki.

Körülbelül mekkora feladattal kerül szembe egy számítógép, amelyik tűzfalként üzemel? Az alábbi táblázatban összefoglaljuk a maximális csomag/másodperc arányokat különböző sebességű Internet kapcsolatok és csomagméretek esetén (a legkisebb még érvényes IP csomag mérete 20 byte/s; a legkisebb még érvényes TCP-t hordozó IP csomag mérete 40 byte/s; az átlagos csomagméret egy Ethernet szegmensen méréseink alapján 512 byte/s):

A csomagszűrő tűzfalunkon van néhány alapszabály, amelyet be kell állítanunk, amelyek nélkül nem indulhatunk el:

• megtiltjuk a „ souce route” IP opciót tartalmazó csomagok átengedését
• megtiltjuk, hogy az Internetre mutató interface-en olyan IP csomag jöhessen be, amelyiknek a forrás IP címe a belső hálózatunkról származik (ellenünk irányuló IP cím hamisítás)
• megtiltjuk, hogy a belső hálózatunkra mutató interface-ről olyan IP csomag mehessen ki, amelyiknek a forrás IP címe nem a belső hálózatunkról származik (mások ellen irányuló IP cím hamisítás)

El kell döntenünk, hogy a tűzfal építése során melyik alapelvet követjük:

• mindent szabad, kivéve amit tilos
• mindent tilos, kivéve amit szabad

Csábító lehet a „ mindent szabad, kivéve amit tilos” elv, de ne felejtsük el: ekkor soha nem lesz biztonságos kontroll alatt a hálózatunk. Bárki, bármikor tetszőleges alkalmazást (akár telnet) indíthat tudtunk nélkül egy magas, nem ellenőrzött porton.

Az alábbi táblázatban összefoglaljuk, hogy az összes lehetséges közül melyek azok az ICMP típusok, amelyek forgalmának a megengedésén el kell gondolkodnunk:

Ha teljesen megtiltjuk az ICMP forgalmat, hálózatunk „ vakká” válik a hálózati és protokoll-problémákkal, azok detektálásával és bizonyosfajta kezelésével szemben. Ha viszont ezek forgalmát megengedjük, nem veszítjük el a hálózatmenedzseléshez szükséges ICMP típusokat, de szembe kell néznünk azzal, hogy DOS (denial-of-service) támadások még érhetik a hálózatunkat.

A megoldást a fenti ICMP típusok forgalmának a megengedése és dinamikus szabályok létrehozására alkalmas tűzfalak alkalmazása jelentheti, amelyek még ilyen típusú DOS támadások ellen is tudnak bizonyos fokú védelmet nyújtani.

Vagyis megengedtük bárkinek, hogy az 517 vagy 518-as UDP portokról bármely 10 23 port fölött szolgáltató szerverünkkel (pl. NFS) kommunikálhasson.

Az UDP protokoll ezen sajátossága miatt nem engedhető át tűzfalon olyan UDP alapú alkalmazás, amelynél a belső kliensünk véletlenszerűen kiválasztott portról külső szerverrel kíván kommunikálni.

Nézzük meg röviden az egyes fontosabb UDP alapú alkalmazásokat:

• traceroute

A traceroute csomagoknál a kliens által küldött UDP csomagokban a forrás és címzett portok a megvalósítástól, a parancs argumetnumaitól függenek. Általában igaz, hogy a forrás port 32768 fölött, míg a címzett port 33434 és 33523 között van. A válasz nem egy UDP csomag, hanem ICMP destination unreachable üzenet.

• NFS = No File Security

Az NFS-el túl sok probléma van ahhoz, hogy tűzfalon átengedjük: csupán az IP cím alapján engedélyezi a hozzáférést; a kliens hoston múlik, hogy mely felhasználó használhatja a file rendszert; az NFS szerver csak egyszer ellenőrzi a klienst, a továbbiakban annak csak érvényes file kezelőt kell hasznáni, amely egyébként kitalálható/próbálgatható, stb, stb.

• NTP (Network Time Protokol)

Az NTP UDP alapú, de két NTP szerver egymás közt a 123-as forrás és címzett portokon kommunikál. Így ha a belső hálózatunkon nincs pontos időforrás, adott külső NTP szerverek - adott belső NTP szerver közti forgalom tűzfalon keresztül átengedhető.

• talk

A talk nemcsak UDP alapú, hanem egy meglehetősen bonyolult protokoll: a kliens a szerverrel való kommunikációra UDP-t használ (forrás: > 10 23, címzett 517 vagy 518), majd a két kliens TCP-vel „ beszélget” (forrás: > 10 23, címzett: > 10 23). Amennyiben a tűzfal nem ismeri a talk protokollt, az biztonsággal nem engedhető át :-(.

• archie

Az archie kliens-hívások az UDP miatt nem engedhetők ki. Lehetséges megoldások, hogy a szolgáltatást mégsem veszítsük el:

• megtanítani a felhasználókat arra, hogy az archie szervereket telnet-el érjék el
• WWW gateway-eket használni
• mégis kiengedjük az ismert kisszámú archie szerverek felé...

A TCP egy megbízható, kapcsolat-létesítő, folytonos adatforgalmat biztosító protokoll. A kapcsolat irányultsága (ki a kliens és ki a szerver) a csomagfolyamból egyértelműen megállapítható. Ezért modellünkben minden kifelé irányuló kliens-kérést engedélyezhetünk, míg befelé csak az egyes kapugépekre és csak az azokon futtatott szolgáltatást tesszük elérhetővé.

Csupán a legfontosabb protokollokat érintjük vázlatosan:

• SMTP

MX rekordokkal minden, felhasználót érintő probléma nélkül elérhetjük, hogy a teljes befelé irányuló E-mail forgalom egy vagy csupán néhány nagy mail szerver gépen keresztül történjen, és a tűzfallal biztosíthatjuk, hogy csak azokon keresztül történhessen. A biztonsági megfontolásokon kívül a központi mail szerverek használata kényelmessé teszi az engedély nélküli E-mail relay és spam elleni harcot.

• telnet, ftp

A lehallgatható, meghamisítható, stb. interaktív belépési lehetőséget nyújtó protokollokkal sajnos együtt kell élnünk. Biztonságos alternatívaként támogatnunk és propagálnunk kell a nem lehallgatható protokollokat (pl. ssh) vagy a legalább biztonságos felhasználói azonosítást lehetővé tevő protokollokat (pl. az SRP alapú telnetet és ftp-t).

Az ftp-t esetében a protokoll egyébként is nehézségeket okoz. Normál módú ftp-nél az adat-csatornát a szerver (kliensként) nyitja meg a kliens (ebben az esetben szerver) által megadott véletlenszerű porton. Ha a tűzfalunk érti az ftp protokoll ezen sajátosságát, ez nem jelent problémát. Ha azonban egyszerű csomagszűrő tűzfalunk van, a megoldást az ún. passive módú ftp használata adhatja, amikor az adatcsatornát is a kliens nyitja meg, kliensként. Ennek megtanulása/elfogadása nehézséget okozhat a felhasználók számára.

• rsh, rlogin, rcp

Mint nem biztonságos protokollokat, ne engedjük át. Bizonyos mértékig helyettesíthetők telnet-el és ftp-vel, ssh, slogin, scp esetén pedig a teljes funkcionalitás biztonságosan megőrizhető.

Ssh esetén nem szabad megfeledkezni arról, hogy a szerver a default 22-es porton kívül általában a 6010, 6011, ..., 60nn portokon is figyel (X11DisplayOffset), valamint hogy az ssh kliens Rhosts és RhostsRSA autentikációk esetén 1023 alatti portról kezdeményezi a kapcsolatokat.

• NNTP (news)

Bejövő news kliens kéréseket elegendő a news szerver felé beengednünk - ha egyáltalán akarunk news-t szolgáltatni mások számára is, egyébként elégséges a news szerverek közti forgalmat engedélyeznünk.

• HTTP

• DNS

A DNS-t említhettük volna az UDP-nél is, mivel az alkalmazás mindkét protokollt használja:

• kliens ® szerver kérés (> 10 23 ® 53), UDP
• szerver ® kliens válasz (53 ® > 10 23), UDP
• kliens Û szerver kommunikáció (> 10 23 ® 53), TCP, ha az UDP alapú kérés sikertelen volt
• szerver Û szerver kommunikáció (53 ® 53), UDP
• szerver Û szerver kommunikáció (> 10 23 ® 53), TCP

A fentiek alapján a DNS szerverünkre beengedhetünk minden kliens/szerver hívást, mind UDP, mind TCP protokollokkal. Ugyanakkor kifelé csak TCP, UDP alapú szerver, és TCP alapú kliens kéréseket engedhetünk ki, azaz az UDP alapú kliens kihívásokat - az UDP protokoll fentebb említett problémái miatt - tiltanunk kell. Ez szerencsére egyrészt ritkán fordul elő (pl. nslookup-al külső szerverhez kapcsolódunk), másrészt csak lassítja az alkalmazás használatát, de nem teszi lehetetlenné.

• X11

Az X11 Window System speciális, mivel „ fordított” protokoll a többihez képest: ahol a képernyő/billentyűzet/egér fizikailag található, ott a szerver, míg ahonnan az alkalmazás ablaka megjelenik a képernyőnkön, ott a kliens. Másrészt biztonsági problémákkal szembesülünk az X11-nél: egy támadó például leolvashatja a képernyőnkent, a billentyű-leütéseinket, vagy akár „ gépelhet” helyettünk. Az X11 rendelkezik ez elleni védelemmel, de sajnos ezek a mechanizmusok vagy gyengék és rosszul használtak (xhost), vagy nem mindíg alkalmazottak (magic cookie).

Ezért az a furcsa helyzet áll elő, hogy távoli gépek számára engedélyezhetjük az X ablak felhozatalát a lokális hálózatunkról, míg a lokális hálón nem engedélyezhetjük a távoli ablak felhozatalát, azaz tiltanunk kell kívülről a belső 6000, 6001, ..., 600n valamint 2000, 2001, ..., 200n szerver-portokhoz való hozzáférést.

Két megoldás kínálkozik: a biztonságos ssh propagálása X11 használatához, vagy hogy az X11 klienseket például az mxconns proxy program segítségével engedjük be. Az mxconns a felhasználók számára kényelmetlenebb, mint az ssh, viszont ssh-t nem támogató hostokhoz kapcsolódva is használható, valamint veszélyes X kérések letilthatók vele (statikus linkeléssel megkerülhető hátránya, hogy szükség van hozzá a Motif toolkit-re).

Simson Garfinkel and Gene Spafford: Pratical UNIX and Internet Security,

O’ Reilly & Associates, 1996

D. Brent Chapman and Elizabeth D. Zwicky: Building Internet Firewalls,

O’ Reilly & Associates, 1995

Steve Bellowin and Bill Cheswick: Firewalls and Internet Security,

Addison-Wesley, 1994

The sf Firewall Software:

http://www.ifi.unizh.ch/ikm/SINUS/firewall.html

Linux IP Firewalling and Accounting:

http://simba.xos.nl/linux/ipfwadm/

Linux IP Firewall Chains:

http://www.adelaide.net.au/~ rustcorp/ipfwchains/ipfwchains.html

IP Filter:

ftp://coombs.anu.edu.au/pub/net/kernel

SSH (Secure Shell) Remote Login Program:

http://www.cs.hut.fi/ssh/

The SRP (Secure Remote Password) Authentication System:

http://srp.stanford.edu/srp/

mxconns:

http://wwwinfo.cern.ch/dis/security/x/mxconns/

SESAME:

http://www.esat.kuleuven.ac.be/cosic/sesame3.html

ssh, SRP és IP Filter mirror:

http://www.kfki.hu/ftp.html