Az Iptables és a Netfilter architektúrája

A tűzfal egy olyan biztonsági eszköz (hardver/szoftver), amely a forgalom szűrésével és a privát adatokhoz való nemkívánatos/illetéktelen hozzáférés blokkolásával védi a hálózatot. A megfelelő tűzfal megléte fontos a szerverek és az infrastruktúra védelme érdekében. Nemcsak a nemkívánatos forgalmat képes blokkolni, hanem azt is megakadályozhatja, hogy a rosszindulatú szoftverek megfertőzzék a rendszert.

A Linux ökoszisztémában az iptables egy népszerű tűzfal, amely kapcsolatot teremt a netfilter keretrendszerrel a Linux-kernelen. A legtöbb modern Linux rendszer már előre beépítve tartalmazza ezeket az eszközöket. Ahhoz, hogy a legtöbbet hozzuk ki ezekből a rendszerekből, elengedhetetlen az architektúrájuk megértése. Ellenkező esetben a megbízható tűzfal-irányelvek kidolgozása ijesztő feladat lehet. Ez bonyolult szintaxisok, a keretrendszer egymással összefüggő részei stb. létrehozásához vezethet.

Ez az útmutató mélyen elmerül az iptables architektúrájában, hogy segítsen azoknak a felhasználóknak, akiknek saját tűzfal-irányelveket kell létrehozniuk. Azt is megvizsgáljuk, hogyan lép kapcsolatba az iptables a netfilter keretrendszerrel, és hogyan illeszkednek egymáshoz a különböző összetevők.

Iptables és Netfilter

Linux alatt az iptables tűzfal a legelterjedtebb. Úgy működik, hogy kapcsolatba lép a Linux-kernel hálózati veremében található csomagszűrő hookokkal. Ezeket a kernel-hookokat nevezzük összefoglaló néven a netfilter keretrendszernek.

A rendszerbe érkező minden bejövő/kimenő csomag aktiválja ezeket a hookokat, ahogy áthalad a hálózati vermen. Így az ezekhez a hookokhoz regisztrált programok képesek interakcióba lépni a forgalommal a kulcsfontosságú pontokon. Végül az iptables eszközhöz kapcsolódó kernelmodulok csatlakoznak ezekhez a hookokhoz a megadott tűzfalszabályok érvényesítése érdekében.

Netfilter hookok

A programok csatlakozásához öt különböző netfilter hook létezik. Ahogy a csomagok haladnak a vermen, a hookok aktiválják a hozzájuk regisztrált kernelmodulokat. Az aktiválási feltétel olyan körülményektől függ, mint például: a csomag iránya (bejövő/kimenő), a csomag célállomása, hogy a csomagot elvetették-e/elutasították-e egy korábbi ponton, stb.

Ezek a hálózati verem különböző, jól meghatározott pontjait képviselő hookok:

• NF_IP_PRE_ROUTING: Ezt a hookot bármilyen bejövő forgalom aktiválja. Az aktiválás még azelőtt megtörténik, hogy bármilyen útválasztási döntés születne a csomag célállomására vonatkozóan.

• NF_IP_LOCAL_IN: Ez a hook egy bejövő csomag útválasztása után aktiválódik. A csomagnak a helyi rendszerre kell irányulnia.

• NF_IP_FORWARD: Ez a hook szintén egy bejövő csomag útválasztása után aktiválódik. Azonban akkor lép működésbe, ha a csomagot egy másik gazdagépre kell irányítani.

• NF_IP_LOCAL_OUT: Bármilyen helyi kimenő forgalom, amint eléri a hálózati vermet, aktiválja ezt a hookot.

• NF_IP_POST_ROUTING: Ezt a hookot bármilyen kimenő/továbbított forgalom aktiválja az útválasztás megtörténte után, mielőtt a csomag elérné a fizikai hálózatot.

Az ezekhez a hookokhoz regisztrálni kívánó kernelmoduloknak meg kell adniuk egy prioritási számot. Ez az érték segít meghatározni a hívási sorrendjüket a hook aktiválása után. Ez a mechanizmus lehetővé teszi, hogy több modul (különböző modulok vagy ugyanazon modul több példánya) meghatározott sorrendben csatlakozzon az egyes hookokhoz. Minden modul egy döntést küld vissza a netfilter keretrendszernek a csomagok feldolgozása után.

Táblák és láncok az Iptables-ben

A szabályok rendszerezéséhez az iptables tűzfal táblákat használ. A táblák az általuk hozott döntések típusa alapján kategorizálják a szabályokat. Például, ha egy szabály a NAT-tal (hálózati címfordítással) foglalkozik, akkor a szabály a nat táblába kerül. Hasonlóképpen, ha egy szabály arról dönt, hogy engedélyez-e vagy elutasít-e egy csomagot a célállomása felé, akkor az a filter táblába kerül.

Az iptables minden egyes tábláján belül a szabályok különálló “láncokba” vannak szervezve. Míg a tábla a benne lévő szabályok típusát képviseli, a láncok azokat a netfilter hookokat írják le, amelyek aktiválják a szabályokat. Röviden, a láncok határozzák meg, hogy a szabály mikor kerül kiértékelésre.

Íme a beépített láncok, amelyeket használ az iptables. Érdekes módon a láncok nevei is tükrözik a kapcsolódó netfilter hookokat:

Lánc (iptables)	Használat
PREROUTING	NF_IP_PRE_ROUTING
INPUT	NF_IP_LOCAL_IN
FORWARD	NF_IP_FORWARD
OUTPUT	NF_IP_LOCAL_OUT
POSTROUTING	NF_IP_POST_ROUTING

A láncok használatával a rendszergazdák meghatározhatják, hogy a csomagkézbesítés melyik szakaszában kerüljön kiértékelésre a szabály. Mivel minden tábla több láncot tartalmaz, a feldolgozás több pontján is kifejtheti a hatását. Bizonyos döntéseknek csak a hálózati verem bizonyos pontjain van értelme. Így nem minden tábla rendelkezik majd az összes kernel hookhoz regisztrált lánccal.

A netfilter keretrendszer mindössze 5 kernel hookot kínál. Ebből adódóan több tábla láncai is regisztrálva vannak a hookok egyes pontjain. Például, ha három lánc rendelkezik a PREROUTING lánccal, akkor az regisztrálva van a NF_IP_PRE_ROUTING hookhoz. Mindegyiküknek meg kell adnia egy prioritást, amely eldönti, hogy az egyes táblák PREROUTING lánca milyen sorrendben kerül meghívásra. A legmagasabb prioritású PREROUTING lánc kerül először kiértékelésre, a következő legmagasabb prioritású másodikként, és így tovább.

Az iptables táblák

Lépjünk egyet hátra, és nézzük meg azokat a táblákat, amelyeket az iptables kínál. Mint korábban említettük, minden tábla különböző szabálykészleteket képvisel, amelyek a feladatkörök szerint vannak rendszerezve a csomagok kiértékeléséhez.

• filter tábla

Az iptables -ben a filter tábla az egyik legnépszerűbb. Arra szolgál, hogy meghatározza, a csomag továbbhaladhat-e a célállomására vagy sem. A tűzfal-terminológiában ezt a folyamatot a csomagok “szűrésének” nevezik.

Leginkább a filter tábla funkcióira gondolnak az emberek, amikor a tűzfalakról beszélnek (többnyire).

• nat tábla

Ez a tábla a NAT-ot szabályozó szabályokat valósítja meg. Amikor a csomagok belépnek a hálózati verembe, az ebben a táblában leírt szabályok döntik el, hogyan módosítsák a csomag forrás-/célcímét, befolyásolva a csomag útvonalválasztását és a válaszforgalmat.

Gyakran a nat táblát arra használják, hogy a csomagokat olyan hálózatokba irányítsák, amelyekhez nincs közvetlen hozzáférés.

• mangle tábla

Ez a tábla azokat a szabályokat tartalmazza, amelyek különböző módon módosítják a csomagok IP-fejléceit. Például módosíthatja egy csomag TTL (Time to Live) értékét azáltal, hogy meghosszabbítja/lerövidíti a csomag által elviselhető érvényes hálózati ugrások számát. Emellett a mangle tábla hasonló módon módosíthat más IP-fejléceket is.

Ez a tábla egy belső kernel-“jelölést” is elhelyezhet a csomagon, amelyet más táblák és hálózati eszközök átvehetnek a további feldolgozáshoz. Ez a jelölés nem érinti a tényleges csomagot, hanem a jelölést a csomag kernelbeli reprezentációjához adja hozzá.

• raw tábla

Az iptables tűzfal állapotalapú (stateful), ami azt jelenti, hogy a csomagok kiértékelése a korábbi csomagokhoz való viszonyuk kontextusában történik. A netfilter keretrendszerre épülő kapcsolatkövetési funkció lehetővé teszi az iptables számára, hogy a csomagokat egy folyamatban lévő kapcsolat vagy munkamenet részeként tekintse, nem pedig különálló, egymástól független csomagok folyamaként. Általában a kapcsolatkövetési logika nagyon hamar alkalmazásra kerül, miután a csomag eléri a hálózati interfészt.

A raw tábla egy nagyon szűken meghatározott funkcióval rendelkezik. Ennek a táblának az egyetlen célja, hogy mechanizmust biztosítson a csomagok megjelölésére a kapcsolatkövetésből való kizárás érdekében.

• security tábla

A security tábla belső SELinux biztonsági kontextus jelöléseket helyez el a csomagokon. Ez viszont befolyásolja, hogy a SELinux (vagy bármely más alkalmazás, amely értelmezi a SELinux biztonsági kontextusokat) hogyan kezeli a csomagokat.

A SELinux jelölések csomagonkénti vagy kapcsolatonkénti alapon is alkalmazhatók.

Az egyes táblákban megvalósított láncok

Eddig külön beszéltünk a táblákról és a láncokról. Itt az ideje áttekinteni, hogy mely láncok érhetők el az egyes táblákban. Ez a témakör kibővíti az ugyanahhoz a hookhoz regisztrált láncok kiértékelési sorrendjéről szóló vitát. Például mi történik, ha három tábla rendelkezik PREROUTING lánccal? Mi a kiértékelési sorrendjük?

Ezután tekintse meg a következő táblázatot. Ez mutatja azokat a láncokat, amelyek elérhetők az egyes iptables táblában.

	PREROUTING	INPUT	FORWARD	OUTPUT	POSTROUTING
(útválasztási döntés)				✓
raw	✓			✓
(kapcsolatkövetés engedélyezve)	✓			✓
mangle	✓	✓	✓	✓	✓
nat (DNAT)	✓			✓
(útválasztási döntés)	✓			✓
filter		✓	✓	✓
security		✓	✓	✓
nat (SNAT)		✓			✓

Balról jobbra olvasva azt írja le, hogy melyik táblák milyen láncokat tartalmaznak. Például a raw tábla rendelkezik mind a PREROUTING és OUTPUT láncokkal is. Fentről lefelé olvasva azt írja le, hogy milyen sorrendben hívódnak meg az egyes láncok, amikor a hozzájuk kapcsolódó netfilter hook aktiválódik.

Vegye figyelembe, hogy a nat tábla fel lett osztva a DNAT műveletek (a csomag céljának módosítása) és a SNAT műveletek (a csomag forrásának módosítása) között, hogy a sorrendjük egyértelműbb legyen. A táblázat azokat a reprezentációs pontokat is tartalmazza, ahol az útválasztási döntések születnek, és ahol a kapcsolatkövetés engedélyezve van.

A csomag által kiváltott hookok (oszlopok) a csomag jellegén (bejövő/kimenő), a meghozott útválasztási döntéseken, valamint azon alapulnak, hogy a csomag megfelel-e a szűrési feltételeknek.

Bizonyos események a feldolgozás során kihagyhatják egy tábla láncát. Például egy kapcsolatnak csak a legelső csomagja lesz kiértékelve a NAT szabályok alapján, ahogyan azt a nat tábla leírja. Ugyanazon kapcsolat minden további csomagjára ugyanazok a nat döntések lesznek alkalmazva, további kiértékelés nélkül. A NAT-kapcsolatokra adott válaszokra automatikusan a fordított NAT-szabályok fognak vonatkozni a megfelelő útválasztás érdekében.

Láncbejárási sorrend

Feltételezve, hogy a szerver ismeri a csomagútválasztási szabályokat, és a tűzfalszabályok engedélyezik az átvitelt, a következő folyamatok mutatják be, hogyan történik a különböző útvonalak bejárása:

• A helyi rendszernek címzett bejövő csomagok: PREROUTING >> INPUT

• Egy másik gazdagépnek címzett bejövő csomagok: PREROUTING >> FORWARD >> POSTROUTING

• Helyileg generált csomagok: OUTPUT >> POSTROUTING

Összefoglalva, az eddig megbeszélt információkat kombinálva láthatjuk, hogy a helyi rendszernek címzett bármely bejövő csomag kiértékelésre kerül a PREROUTING láncaiban a raw, mangle, és nat táblákban. Ezután áthalad az INPUT láncain a mangle, filter, security, és nat tábláknak, mielőtt végül elérné a helyi socketet.

Iptables szabályok

Az iptables tűzfalszabályok egy adott tábla egy adott láncán belül helyezkednek el. Amikor egy lánc meghívásra kerül, a kérdéses csomag a lánc minden egyes szabálya alapján kiértékelésre kerül. Minden szabály két összetevőből áll: egy egyezési összetevőből és egy műveleti összetevőből.

• Egyezés

Egy szabály egyezési része határozza meg azokat a feltételeket, amelyeknek a csomagnak meg kell felelnie a megadott művelet (vagy “célpont”) végrehajtása előtt.

Az egyezési rendszer hihetetlen rugalmasságot kínál. Funkcionalitása bővíthető az iptables kiterjesztések segítségével is. A szabályok leírhatók úgy, hogy a csomagokat protokoll típus, forrás-/célcím, forrás-/célport, forrás-/célhálózat, bemeneti/kimeneti interfész, fejlécek, kapcsolat állapota és egyéb kritériumok alapján egyeztessék. Egy szabály ezen feltételek kombinációjával is rendelkezhet, ami összetett szabálykészleteket eredményez a különböző forgalmak megkülönböztetésére.

• Célpontok

A célpont az a művelet, amely akkor hajtódik végre, ha egy csomag megfelel egy szabály egyezési feltételeinek. Általában a célpontok két csoportra oszthatók:

• • Lezáró célpontok: Ez leállítja a kiértékelési folyamatot a láncon belül, és visszaadja az irányítást a netfilter hooknak. A visszatérési érték alapján a hook vagy engedi a csomagot továbbhaladni, vagy eldobja azt.

  • Nem lezáró célpontok: A célpont végrehajt egy műveletet, és a láncban a kiértékelés folytatódik. Bár minden láncnak át kell mennie egy végső lezáró döntésen, előtte tetszőleges számú nem lezáró célpont is helyet kaphat.

A szabályokon belüli célpontok elérhetősége a kontextustól függ. Például a lánc és a tábla típusa befolyásolhatja a célpontok elérhetőségét. További lehetséges tényezők közé tartoznak a szabályban aktivált kiterjesztések és az illeszkedési feltételek.

Felhasználó által definiált láncok

Létezik egy speciális osztálya is a nem lezáró célpontoknak: az ugrási célpont. Az ugrási célpontok olyan műveletek, amelyek akkor hajtódnak végre, amikor a kiértékelés az egyik láncról a másikra lép át további feldolgozás céljából. Eddig olyan beépített láncokról beszéltünk, amelyek szorosan kapcsolódnak a netfilter hookokhoz, amelyek meghívják őket. Azonban a iptables lehetővé teszi a rendszergazdák számára saját egyéni láncok létrehozását is.

A felhasználó által definiált láncokban lévő szabályok szintén hasonlóak a beépített láncokban lévőkhöz. A legfőbb különbség az, hogy a felhasználó által definiált láncok csak egy szabályból történő “ugrással” érhetők el. Ez azért van, mert a felhasználó által definiált láncok nincsenek összekapcsolva semmilyen netfilter hookkal.

A felhasználó által definiált láncokra úgy is gondolhat, mint az őket eredetileg meghívó lánc kiterjesztéseire. Például egy felhasználó által definiált láncban a kiértékelés visszakerül a hívó lánchoz, ha eléri a szabálylista végét, vagy ha egy egyező szabály végrehajt egy RETURN célpontot. Érdekesség, hogy egy felhasználó által definiált lánc is “átugorhatja” a kiértékelést egy másik felhasználó által definiált láncra.

Ez a funkció megalapozza a jobb rendszerezést és a robusztus elágazásokhoz szükséges keretrendszert.

Kapcsolatkövetés

Amikor a raw táblát és a kapcsolatállapot-illesztési feltételeket tárgyaltuk, szó esett a netfilter keretrendszerre épülő kapcsolatkövető rendszerről. Ez a funkció lehetővé teszi az iptables  számára, hogy a csomagokat egy folyamatban lévő kapcsolat kontextusában vizsgálja. A kapcsolatkövető rendszer biztosítja az iptables számára az “állapotalapú” műveletek elvégzéséhez szükséges funkciókat is.

Közvetlenül azután, hogy egy csomag belép a hálózati verembe, alkalmazásra kerül a kapcsolatkövetés. A raw tábla láncai és néhány alapvető érvényességi ellenőrzés alkotják azt a teljes logikát, amely a csomagok kapcsolathoz rendeléséhez szükséges.

A rendszer minden csomagot ellenőriz a meglévő kapcsolatok listájával szemben. Ha szükséges, a rendszer frissíti a meglévő kapcsolatok állapotát, vagy újakat hoz létre. Azok a csomagok, amelyeket bármelyik raw tábla láncában NOTRACK célponttal jelöltek meg, elkerülik a további kapcsolatkövetési folyamatokat.

• Elérhető állapotok

A kapcsolatkövető rendszer által követett kapcsolatokhoz az alábbi állapotok bármelyike hozzárendelhető:

• • NEW : Egy olyan csomag érkezésekor, amely nem kapcsolódik meglévő kapcsolathoz, de első csomagként nem érvénytelen, egy új kapcsolat kerül hozzáadásra a rendszerhez ezzel a címkével. Ez mind a kapcsolat-orientált protokollok (például TCP), mind a kapcsolat nélküli protokollok (például UDP) esetében megtörténik.

  • ESTABLISHED: Egy kapcsolat állapota frissül a NEW  állapotról ESTABLISHED állapotra, amikor érvényes választ kap az ellenkező irányból. TCP-kapcsolatok esetén ez egy SYN/ACK. UDP- és ICMP-forgalom esetén olyan választ jelent, amelyben az eredeti csomag forrása és célja fel van cserélve.

  • RELATED: Azok a csomagok, amelyek nem részei egy kapcsolatnak, de kapcsolódnak egy már kiépített kapcsolathoz, a következő címkét kapják: RELATED . Ez jelenthet egy segédkapcsolatot (például FTP adatátviteli kapcsolat esetén), vagy más protokollok kapcsolódási kísérleteire adott ICMP-válaszokat.

  • INVALID: Azok a csomagok, amelyek nem részei egy kiépített kapcsolatnak, alkalmatlannak minősülnek új kapcsolat megnyitására, nem azonosíthatók, nem irányíthatók stb., a következő címkét kapják: INVALID.

  • UNTRACKED: Egy csomag megjelölhető UNTRACKED címkével, ha egy raw tábla láncában arra jelölték ki, hogy elkerülje a követést.

  • SNAT: Egy olyan virtuális állapotot jelöl, amely akkor áll be, ha a forráscímet egy NAT-művelet módosítja. Ezt a kapcsolatkövető rendszer kezeli, így a válaszcsomagokban a forráscímek lefordításra kerülnek.

  • DNAT: Hasonló ehhez: SNAT, egy virtuális állapotot jelöl, amikor a célcímet egy NAT művelet módosítja. A kapcsolatkövető rendszer úgy kezeli ezt, hogy tudja, vissza kell fordítania a célcímet a válaszcsomagok irányításakor.

A kapcsolatkövető rendszer által nyomon követett állapotok lehetővé teszik a rendszergazdák számára, hogy specifikus szabályokat hozzanak létre a kapcsolat életciklusának meghatározott pontjaira célozva. Ez biztosítja a szükséges funkcionalitást az alaposabb és biztonságosabb szabályokhoz.

Záró gondolatok

Linuxban a netfilter keretrendszer és az iptables tűzfal szolgál alapul a legtöbb tűzfal számára. A netfilter hookok elég közel vannak a hálózati veremhez ahhoz, hogy hatékony ellenőrzést tegyenek lehetővé a rendszer által feldolgozott csomagok felett. Ezen képességek kihasználásával az iptables tűzfal rugalmas módot kínál az irányelvi követelmények kernel felé történő kommunikálására.

Ez az útmutató részletesen bemutatja a netfilter keretrendszer és az iptables tűzfal belső felépítését. Emellett tárgyalja a kapcsolatkövető rendszert is. Ha megérti, hogyan illeszkednek egymáshoz ezek a részek, jobban kihasználhatja őket robusztusabb és biztonságosabb szerverkörnyezetek kialakítására.

Végezetül, bár ez az útmutató a belső működéssel foglalkozik, tekintse meg ezt az útmutatót az iptables konfigurálásáról szóló részt, hogy alkalmazza őket a gyakorlatban. Emellett láthatja, hogyan UFW tűzfal egyszerűsíti tovább az iptables használatát. Ezenkívül hasznos lesz megtanulni, hogyan lehet kilistázni és törölni az iptables tűzfalszabályokat.

Kellemes számítógépezést!