Podcast on Hálózati biztonság: Tűzfalak, Proxyk és Átjárók

Přepis

Jakub: Tudjátok, mi az az egy dolog, ami a tűzfal vizsgán majdnem mindenkit összezavar? Mindenki azt hiszi, hogy a tűzfal csak egy szabálylista – „engedélyezd ezt, tilts le amazt”. Mint egy kidobóember egy papírral a kezében. De ez csak az igazság fele. A mai tűzfalak többsége teljesen másképp működik. És ha megértitek a kulcsfontosságú különbséget, soha többé nem fogtok belezavarodni.

Adéla: Ez ígéretesen hangzik. Ez itt a Studyfi Podcast.

Adéla: Rendben, Jakub, vágjunk is bele. Tűzfalról beszélsz, de gondolom, az alapja a szűrés, igaz? Mit is jelent ez pontosan?

Jakub: Pontosan. A szűrés az abszolút alap. Képzeld el, mint egy határellenőrzést. Egy aktív elem, mondjuk egy router vagy maga a tűzfal, megnézi a rajta áthaladó adatokat, és eldönti: „Téged átengedlek, téged nem.”

Adéla: Tehát csak szétválogatja a forgalmat, nem változtat rajta?

Jakub: Pontosan. Semmit sem változtat, csak átengedi vagy eldobja. Ebben különbözik például egy proxy szervertől, amiről majd máskor beszélünk. És a szűrésnél két fő megközelítésünk van.

Adéla: Feketelista és fehérelista, ugye?

Jakub: Persze. A feketelistázás olyan, mintha egy bulin lenne egy listád a problémás vendégekről. Mindenki más bejöhet. Tehát „ami nincs tiltva, az engedélyezett.” Ez nyitottabb, de kevésbé biztonságos.

Adéla: A fehérelista pedig az ellenkezője. Egy lista a meghívottakról, és senki más nem jut be.

Jakub: Pontosan! „Ami nincs kifejezetten engedélyezve, az tiltva van.” Ez sokkal biztonságosabb, de a kezelése is munkaigényesebb. A gyakorlatban gyakran kombinálják. Egy cég határán van egy szigorú fehérelista, de a saját laptopodon inkább egy engedékenyebb feketelista.

Adéla: És hol történik ilyen szűrés? Csak egy helyen?

Jakub: Dehogy, ez egy rétegzett védelem. Szűrés történik switcheken, routereken, speciális hardvereken, amelyeken minden forgalom átfolyik, és közvetlenül a számítógépeden is, például a Windows tűzfal segítségével. Ha az egyik réteg meghibásodik, van esély, hogy a következő elkapja.

Adéla: Rendben, az alapokkal megvagyunk. Lépjünk egy szinttel feljebb. Mit ellenőrizhetünk hálózati szinten, tehát az IP protokoll alapján?

Jakub: Na, itt kezd érdekes lenni a dolog. A tűzfal minden csomag fejlécébe belenéz, és megkérdezi: „Ki vagy és hová mész?” Tehát ellenőrzi a forrás- és cél-IP-címet. Így engedélyezheti vagy tilthatja a kommunikációt konkrét számítógépek vagy akár egész hálózatok között.

Adéla: Tehát mondhatom azt: „Az A számítógép beszélhet a B számítógéppel, de a C-vel nem”?

Jakub: Pontosan. És nem csak azt. Szűrhet aszerint is, hogy milyen protokoll utazik benne – TCP, UDP, vagy például ICMP, ami azok a vezérlőüzenetek, amiket a számítógépek küldenek egymásnak.

Adéla: Csakhogy ez önmagában… hát, kicsit erőtlenül hangzik. Nem mondja meg, *mit* csinálnak a számítógépek. Hogy épp weboldalakat néznek, vagy valaki megpróbál betörni a szerveremre.

Jakub: Telitalálat. Az önmagában vett IP-szűrés alap, de nem elég. Ezért jön a modern tűzfalak legnagyobb sztárja… a reflexív szűrő!

Adéla: Reflexív szűrő? Ez valami pszichológiai dolognak hangzik.

Jakub: Majdnem. Állapotfüggő, vagyis stateful tűzfalnak is nevezik. És most érkezünk el ahhoz, ami összezavarja a diákokat. Egy régi, „állapotmentes” tűzfal minden csomagot külön-külön vizsgál. Megvannak a szabályai, és semmi más nem érdekli. Jön egy csomag, ellenőrzi a szabályokat, átengedi vagy eldobja. Kész.

Adéla: És az állapotfüggő… az megjegyzi a kontextust?

Jakub: Pontosan! Megjegyzi a létrejött kapcsolatokat. Úgy működik, mint egy intelligens recepciós. Ha valaki a cégedből felhív valakit kívülről, a recepciós megjegyzi: „Aha, Jana hívja Novák urat.” És amikor Novák úr visszahív, a recepciós tudja: „Persze, ez a hívás Janának szól, kapcsolom.”

Adéla: Tehát ha a számítógépem kérdez valamit a Google-től, a tűzfal megjegyzi, és beengedi a Google válaszát, még akkor is, ha nincs erre külön szabályom?

Jakub: Pontosan! Kiengedi a kimenő csomagot, majd befelé csak azokat az adatokat engedi át, amelyek ahhoz kapcsolódnak. Ez dinamikus és sokkal biztonságosabb, mert nem kell nyitva tartanod az ajtót olyan bejövő kommunikáció számára, amit senki sem kezdeményezett belülről.

Adéla: Ennek van értelme. De mi van, ha valaki megpróbálja becsapni a tűzfalat? Mondjuk úgy tesz, mintha belülről jönne?

Jakub: Kiváló kérdés. Ez egy klasszikus támadás, az úgynevezett „címhamisítás” (address spoofing). A támadó küld egy csomagot az internetről, de a forráscímnek a belső hálózatod IP-címét állítja be.

Adéla: És egy buta, állapotmentes tűzfal azt hihetné, hogy a csomag belülről származik, és továbbengedné?

Jakub: Pontosan. Ez olyan, mintha egy levelet küldenél hamis feladóval. A válasz ugyan nem jut el a támadóhoz, mert a router a hamis, valós címre küldi a hálózat belsejébe…

Adéla: De a káros csomag bejutott. És ez elég lehet, igaz?

Jakub: Pontosan. Így lehet például hamis DNS-választ kézbesíteni, és az áldozatot egy csaló weboldalra átirányítani. Szerencsére van védelem. Ezt „ingress filteringnek” nevezik.

Adéla: Ami azt jelenti?

Jakub: Ez egy egyszerű szabály a határ-routeren: „Ha kívülről érkezik egy csomag, ami azt állítja, hogy belülről jön, az nonszensz. Dobd el.” Ez egyfajta alapvető digitális higiénia.

Adéla: Rendben, az IP-címekkel megvagyunk. De azt mondtad, ez nem elég a szolgáltatások megkülönböztetéséhez. Ehhez portokra van szükségünk, tehát TCP vagy UDP szintű szűrésre, igaz?

Jakub: Pontosan. Itt már eljutunk oda, hogy konkrét alkalmazásokat engedélyezhetünk vagy tilthatunk. Minden szolgáltatás egy bizonyos porton fut – a web a 80-as vagy 443-as porton, az SSH a 22-esen, és így tovább. Tehát mondhatjuk: „Ez a szerver csak a 443-as webes porton keresztül kommunikálhat a világgal, és semmi máson.”

Adéla: Itt ismét az állapotfüggő tűzfal lép színre, igaz? Figyeli a kapcsolat létrejöttét?

Jakub: Abszolút kulcsfontosságú. TCP esetén főleg a SYN jelzésű csomagokat figyeli, ami egy kapcsolatfelvételi kérés. Amint létrejön a kapcsolat, a tűzfal beírja a táblázatába, és ideiglenesen engedélyezi a kétirányú forgalmat ezen az egyetlen munkameneten belül.

Adéla: Tehát ellenőrzi, hogy stimmelnek-e az IP-címek, a portok, sőt még a csomagok sorszámai is?

Jakub: Igen, pontosan. Figyeli az egész beszélgetést. És ez fontos, mert egyes protokollok elég alattomosak. Például a régi FTP.

Adéla: Miben alattomos az FTP?

Jakub: Az aktív módjában. Te csatlakozol a szerverhez a 21-es porton, hogy parancsokat adj neki. De amikor le akarsz tölteni egy fájlt, a szerver megpróbál visszacsatlakozni hozzád egy teljesen más porton, hogy elküldje az adatokat. És ezt minden normális tűzfal azonnal blokkolná!

Adéla: Mert ez egy kéretlen kapcsolat kívülről befelé?

Jakub: Pontosan! Tehát egy okos, állapotfüggő tűzfalnak értenie kell az FTP protokollt. Tudnia kell: „Aha, most megegyeztek egy adatkapcsolatban, egy rövid időre engedélyeznem kell a bejövő kapcsolatot ezen a konkrét porton.” Enélkül nem működne.

Adéla: És mi van a fragmentációval? Tudom, hogy a nagy csomagok útközben kisebb darabokra szakadhatnak. Ez egy tűzfal számára rémálom lehet.

Jakub: Ez probléma. Mert a TCP fejléc a portinformációkkal csak az első fragmentumban van. A többiben már nincs. Tehát egy egyszerű szűrő blokkolná az első darabot, de a többi átmenne.

Adéla: És a célgép megpróbálná összerakni, nem sikerülne neki, és hibaüzenetet küldene. Ami felesleges forgalom.

Jakub: Pontosan. Egy robusztusabb, de teljesítményigényesebb megoldás az, hogy a tűzfal megvárja, amíg az összes fragmentum megérkezik, összerakja belőlük az egész szegmenst, ellenőrzi, majd vagy mindet átengedi, vagy mindet eldobja.

Adéla: Tehát ha mindent összeadunk és aláhúzunk… mi is valójában egy tűzfal manapság?

Jakub: A tűzfal egy alkalmazás, vagy gyakrabban egy speciális hardver, ami elvégzi mindezt az okos szűrést, és emellett mindent naplóz is. Rögzíti, mi próbált átjutni, mi volt engedélyezve, mi volt elutasítva. Ez kulcsfontosságú a későbbi elemzéshez, ha valami történik.

Adéla: Speciális hardverről beszélsz. Ez azt jelenti, hogy elég nagy teljesítményű gépeknek kell lenniük?

Jakub: Nagy forgalom esetén mindenképpen. Kell hozzá egy rendes processzor, sok memória az állapotfüggő táblázathoz és minőségi hálózati kártyák. A mai tűzfalak már az úgynevezett „deep packet inspection”-t, azaz mélyreható csomagvizsgálatot is tudják. Nem elégszenek meg a fejlécekkel, hanem magukba az adatokba is belenéznek.

Adéla: Tehát értik az alkalmazási protokollokat, mint a HTTP? És kereshetnek benne valamit?

Jakub: Pontosan. És a legfejlettebbek még tovább mennek. Képesek a titkosított SSL/TLS forgalom vizsgálatára is.

Adéla: Várjunk csak, hogyan tudnak titkosított forgalmat ellenőrizni? Hiszen ez nem lehetséges, pont ezért van a titkosítás.

Jakub: Lehetséges, de kicsit ellentmondásos. A tűzfal lényegében „Man-in-the-Middle” típusú támadóként viselkedik. Dekódolja a tőled érkező forgalmat, ellenőrzi, majd újra titkosítja és továbbküldi. Ahhoz, hogy ez működjön, a számítógépednek teljesen meg kell bíznia a tűzfalban. Cégeknél ezt úgy oldják meg, hogy a céges eszközökre telepítik a céges tűzfal tanúsítványát.

Adéla: Ez kicsit aláássa a magánélet és a végpontok közötti titkosítás gondolatát, nem?

Jakub: Aláássa. Ez egy kompromisszum a biztonság és a magánélet között. Lehetővé teszi a HTTPS-ben rejtőző rosszindulatú szoftverek felderítését, de a bizalom megsértésének árával. Ezért használják főleg céges környezetben. Tehát, hogy összefoglaljuk – a mai tűzfal nem csak egy buta kidobóember egy listával. Egy okos detektív, aki emlékszik a kontextusra, érti a különböző nyelveket, és néha még nagyítót is vesz elő, hogy megnézze, mi utazik a csomag belsejében.

Adéla: Tehát a hálózati feltérképezés az alap. De hogyan tudom pontosan megállapítani, mi is fut valójában ezeken az eszközökön?

Jakub: Pontosan. És itt lép színre egy technika, amit portszkennelésnek hívnak. Ez az egyik leggyakoribb első lépés.

Adéla: Rendben, portszkennelés. Mit is kell ez alatt értenem? Valami kikötői átkutatást?

Jakub: Majdnem. Képzeld el a hálózat minden eszközét házként. A portok olyanok, mint az ajtók és ablakok abba a házba. A portszkennelés pedig lényegében annak ellenőrzése, hogy nyitva van-e valamelyik.

Adéla: Tehát tulajdonképpen… megpróbálom a kilincset minden ajtón?

Jakub: Pontosan! Küldünk egy kis adatcsomagot egy adott portra, és várjuk a választ. Ha ésszerű válasz érkezik, tudjuk, hogy valami figyel azon a porton. Valamilyen szolgáltatás.

Adéla: És mire jó ez? mármint azon kívül, hogy úgy hangzik, mint egy betörés előkészítése.

Jakub: Nos, két oldala van. A rendszergazdák legitim módon használják. Például amikor ellenőrizniük kell, hogy fut-e a webszerverük, vagy hogy nem blokkolja-e a tűzfal. De a támadók természetesen sebezhető alkalmazások keresésére használják.

Adéla: Tehát többféle módja is van annak, hogy bekopogjunk ezeken az ajtókon?

Jakub: Igen, rengeteg. A leg alapvetőbb az úgynevezett TCP connect scan. Ez udvarias – kopog, várja a nyitást, és bemutatkozik. Végrehajtja a teljes háromutas kézfogást. De lassú, és ami a legfontosabb… nyomokat hagy. Az alkalmazás rögzíti, hogy érkeztél.

Adéla: És a kevésbé udvarias mód?

Jakub: Azt SYN scannek, vagyis „lopakodó szkennelésnek” hívják. Ez olyan, mint csengetni és elfutni. Csak az első SYN csomagot küldöd el, és ha a cél SYN-ACK-kal válaszol, tudod, hogy nyitva van. De te már nem küldöd el a harmadik lépést, az ACK-t. A kapcsolat soha nem jön létre teljesen.

Adéla: Tehát a cél nem tudja, hogy ott jártam?

Jakub: Pontosan, az alkalmazás általában nem naplózza. De figyelem! A modern tűzfalak és behatolásérzékelő rendszerek látják ezt. És a nagyméretű szkennelést az internetszolgáltató támadásnak tekintheti, és nyugodtan lekapcsolhat.

Adéla: Értem. Tehát ez egy erős eszköz, de tudnunk kell, mit csinálunk. Akkor mit tegyünk az így szerzett információkkal?

Adéla: Tehát a tűzfalakkal végeztünk, és világos, hogy a biztonság alapját képezik. De mi van, ha valami… okosabbra van szükségünk, ami belát a forgalomba?

Jakub: Pontosan, Adéla. És ezzel eljutunk az utolsó nagy témánkhoz. A proxy szerverekhez.

Adéla: Proxy… ez valami közvetítőnek vagy képviselőnek hangzik.

Jakub: Ez abszolút telitalálat! Képzeld el a proxyt, mint a számítógéped személyi asszisztensét. Te megmondod neki, mit akarsz az internetről, és ő elintézi helyetted.

Adéla: Tehát nem kommunikálok közvetlenül a cél szerverrel?

Jakub: Pontosan. Te a proxyval kommunikálsz, a proxy pedig a szerverrel. Ez két különálló kapcsolat. Kívülről úgy tűnik, hogy a kérés a proxytól érkezett, nem tőled.

Adéla: És mire jó ez? Miért ez a plusz lépés?

Jakub: Főleg két dologra. Az első a szűrés. Mivel a proxy érti az alkalmazási protokollokat, mint a HTTP, sokkal többet lát, mint egy tűzfal. Blokkolhat konkrét weboldalakat, vagy akár oldalak részeit is.

Adéla: Aha! Tehát ez a fontos különbség a tűzfallal szemben, ami csak a címeket és a portokat figyeli.

Jakub: Pontosan. A másik dolog régebben a gyorsítótár volt. A proxy tárolta a gyakran látogatott oldalakat. Ma már ez nem igazán működik, mert minden dinamikus. De a szűrés továbbra is kulcsfontosságú.

Adéla: Rendben, ennek van értelme. Létezik több fajtája ezeknek az „asszisztenseknek”?

Jakub: Persze! Nézzünk meg három alapvető típust. Az első a klasszikus proxy.

Adéla: Klasszikus? Úgy érted, a legrégebbi?

Jakub: Azt is mondhatnánk. Itt a kliens, például a böngésződ, tud a proxyról. Közvetlenül a beállításokban kell megmondanod neki: „Használd ezt a proxyt ezen a címen.”

Adéla: Ez jellemző a cégekre vagy iskolákra, igaz?

Jakub: Pontosan. A böngésző ekkor nem közvetlenül a Seznam.cz-re küldi a kérést, hanem elküldi a proxynak azzal, hogy a Seznam.cz oldalt szeretné. És a proxy elintézi.

Adéla: Értem. De mi van, ha van egy alkalmazásom, amit nem tudok beállítani? Mondjuk valami régi szoftver.

Jakub: Remek kérdés! Ezekre az esetekre van generikus proxynk. Itt az a trükk, hogy a kliens azt hiszi, közvetlenül a cél szerverrel beszél.

Adéla: Hogyan?

Jakub: Mert a proxyba „bekábelezzük” a cél szerver címét. Minden szerverhez, amihez csatlakozni akarunk, fut egy speciális port a proxyn. A kliens csatlakozik a proxy:port1-hez, és az automatikusan átirányítja a szerver1-re. Nem veszi észre a különbséget.

Adéla: Tehát a kliens egyáltalán nem tud a proxiról. És mi van a harmadik típussal?

Jakub: Azt transzparens proxynak hívják, és még tovább megy. Itt egyáltalán nem kell semmit sem beállítanod, sem a kliensen, sem a proxyn.

Adéla: Várjunk csak, hogyan lehetséges ez? Ez varázslatnak hangzik.

Jakub: Majdnem. A klienstől érkező csomagot egyszerűen elküldöd a cél szervernek, de egy hálózati elem, mondjuk egy router, elkapja, és titokban átirányítja a proxynak. Az elvégzi a munkáját, és a választ visszaküldi, mintha közvetlenül a szervertől érkezett volna.

Adéla: Tehát a kliens teljesen tudatlan. Hol használják ezt?

Jakub: Régebben gyakori volt például nyilvános Wi-Fi hálózatokon, hotelekben a tartalom szűrésére. Ma már a titkosított HTTPS forgalommal sokkal bonyolultabb.

Adéla: Rendben, a proxyval megvagyunk. De hallottam még a „átjáró”, vagyis gateway kifejezésről. Van különbség?

Jakub: Van, és alapvető. A proxy ugyanazt a nyelvet beszéli, mint a kliens és a szerver is. Például HTTP-t. De az átjáró protokollokat fordít!

Adéla: Fordít? Mondj egy példát.

Jakub: Képzeld el, hogy egy webböngészőből (HTTP) akarsz hozzáférni egy FTP szerverhez. Az átjáró veszi a HTTP kérésedet, lefordítja FTP-re, letölti a fájlokat, és neked normális weboldalként jeleníti meg.

Adéla: Aha! Tehát az átjáró egyfajta univerzális tolmács két különböző világ között. Ez okos.

Jakub: Pontosan. És ez elvezet minket a biztonsági sorozatunk legvégére. Tényleg sok mindenen keresztülmentünk.

Adéla: Igen, ez igaz. Az alapvető tűzfalaktól kezdve, az okos behatolásérzékelő rendszereken át, egészen a mai proxy szerverekig és átjárókig. Mindegyiknek megvan a maga helye.

Jakub: Pontosan. Nem egyetlen golyóálló technológiáról van szó, hanem védelmi rétegekről. És most, remélem, sokkal jobb áttekintésetek van arról, hogyan működnek ezek a rétegek. Ez egy utazás volt.

Adéla: Az biztos. Jakub, nagyon köszönöm az összes információt. És nektek, kedves hallgatók, köszönjük a figyelmet a Studyfi Podcastnál. Reméljük, segítettünk, és sok sikert kívánunk a vizsgákhoz! Sziasztok!

Jakub: Sziasztok!