1. Bevezetés

Szervusztok!

Ez a leírás olyan, mint egy utazás; egyes részei jól ki vannak dolgozva, míg más részeken esetleg egyedül érezhetitek magatokat. A legjobb tanács, amit adhatok Nektek, hogy szerezzetek egy nagy bögre kávét vagy meleg kakaót, üljetek le egy kényelmes székbe, és figyeljétek a tartalomjegyzéket mielõtt belevágtok a hálózat- programozás néha veszélyes világába.

A netfilter felületén elhelyezkedõ szerkezet jobb megismeréséhez ajánlom a Packet Filtering HOWTO és a NAT HOWTO átolvasását. A kernel programozásához szükséges információkhoz ajánlom a következõ leírásokat: Rusty's Unreliable Guide to Kernel Hacking és Rusty's Unreliable Guide to Kernel Locking.

(C) 2000 Paul `Rusty' Russell. Licenced under the GNU GPL.

1.1 Mi az a netfilter?

A netfilter egy váz a csomagok megváltoztatására, ami a hagyományos Berkeley socket felületen kívül helyezkedik el. Négy része van. Elsõ: minden protokoll definiál hook-okat (IPv4-nél 5 darab van), amik jól definiált pontokat határoznak meg a csomagok protokoll-stack-beli útjuk során. Mindegyik ilyen ponton a protokoll képes meghívni a netfilter vázat a csomaggal és a hook sorszámával.

Második: a kernel részei regisztrálni tudják magukat a különbözõ hook-okhoz minden protokoll esetében. Amikor a csomag megérkezik a netfilter vázhoz, az ellenõrzi, hogy valaki regisztrálta-e magát a megadott protokollhoz és hookhoz. Amennyiben van ilyen rész, akkor mindegyik lehetõséget kap a csomag megvizsgálására (esetleg megváltoztatására), ezután figyelmen kívül hagyhatja a csomagot (NF_DROP), átengedheti (NF_ACCEPT), kiveheti a netfilterbõl a csomagot (NF_STOLEN), vagy kérheti a netfiltert, hogy állítsa sorba a csomagot az userspace programok számára (NF_QUEUE).

Harmadik: a sorba állított csomagok (az ip_queue driverrel) a felhasználói programokhoz szabályozottan kerülnek elküldésre. A csomagok kezelése aszinkron.

Az utolsó rész a jó forráskód kommentezésbõl és a csodálatos dokumentációból áll. Ez szükséges bármilyen kísérleti projecthez. A netfilter mottója (szemtelenül lopva Cort Dougan-tól):

        ``So... how is this better than KDE?''

Ehhez az egyszerû vázhoz számos kiegészítés készült, amik az elõzõ kernelekhez hasonló funkcionalitást adnak a rendszerhez, ide értve a bõvíthetõ NAT rendszert, valamint a bõvíthetõ csomagszûrõ rendszert (iptables).

1.2 Mi a baj azzal, amit a 2.0 és 2.2-es verziókban találhatunk?

1. Nincs kialakított metódusa a csomagok felhasználói térbe való továbbításának
   • Kernel programozás nehéz
   • Kernel programozást C/C++ -ban kell végezni
   • Dinamikus szûrési szabályok nem tartozhatnak a kernelhez
   • 2.2 bevezette a csomagok userspace-be küldését netlinken keresztül, de a csomagok ismételt elküldése lassú. Például nm lehetséges a csomag olyan újraküldése, mintha valós interface-rõl érkezne.
2. Transzparens proxyzás olyan, mint egy cserépedény:
   • Minden csomagot meg kell néznünk, hogy van-e olyan socket, ami az adott címre van bind-olva
   • A root idegen címekre is bind-olhat
   • Nem lehet a helyileg készült csomagokat átirányítani
   • REDIRECT nem kezeli le az UDP válaszokat: az UDP névszerver csomagok átirányítása a 1153-as portra nem mûködik, mert egyes kliensek nem szeretik azokat a válaszokat, amik nem az 53-as portról érkeznek.
   • REDIRECT nincs összhangban a tcp/udp port-hozzárendeléssel: a felhasználó kaphat olyan portot, ami egy REDIRECT szabállyal el van fedve.
   • Legalább kétszer hibás volt a 2.1-es sorozat alatt.
   • A program-kód nagyon csúnya, tolakodó. Az #ifdef CONFIG_IP_TRANSPARENT_PROXY a 2.2.1-es kernelben 34-szer fordul elõ 11 fileban, szemben a CONFIG_IP_FIREWALL-al, ami 10-szer található meg 5 fileban.
3. Interface-tõl független csomagszûrõ szabályok készítése nem lehetséges:
   • Muszáj tudni a helyi interface címét, hogy a helyileg induló és végzõdõ csomagokat meg tudjuk különböztetni az áthaladóktól.
   • S mi több: ez nem elég a redirection vagy masquerading esetén.
   • Forward láncnak csak a kimenõ interface-en van információja a csomagról, ami azt jelenti, hogy a hálózati felépítés ismeretében magadnak kell kitalálnod a csomag lehetséges eredetét.
4. Masquerading össze van fûzve a csomagszûréssel:

   A masquerading és a szûrés közti kölcsönhatások bonyolulttá teszik a tûzfal kialakítását:

   • Bemeneti szûrésnél a válaszcsomag mintha magának az eszköznek szólna
   • Átmenû szûrésnél a visszaalakított (demasquerad) csomagok nem kerültek ellenõrzésre soha többé
   • Kimeneti szûrésnél: mintha maga az eszköz küldte volna a csomagot

5. TOS módosítás, átirányítás, ICMP unreachable és mart (ami a port átirányításra, routolásra és a QoS-re van hatással) szintén a csomagszûrési programkódban kerültek megvalósításra.
6. ipchains kód se nem moduláris, se nem bõvíthetõ (pl. MAC cím szûrés, opciók szûrése, stb.).
7. A szükséges alapok hiánya a különbözõ megoldások bõséges választékához vezetett:
   • Masquerading, és protokollonkénti modulok
   • Gyors állandó NAT routolási kóddal (nincs protokoll támogatás)
   • Port forwarding, redirect, automatikus forwarding
   • The Linux NAT és Virtual Server Project.
8. A CONFIG_NET_FASTROUTE és a csomagszûrés összeférhetetlensége:
   • Továbbított csomagok három láncon is áthaladnak
   • Nincs lehetõség ezeknek a láncoknak a kihagyására
9. Routing védelem (pl. forráscím-ellenõrzés) nem lehetséges a csomagok ellenõrzésének hiánya miatt
10. Nincs lehetõség a csomagszûrõ szabályok számlálóinak automatikus olvasására.
11. CONFIG_IP_ALWAYS_DEFRAG egy fordítási opció, nehezebbé téve az életet azok számára, akik egységes felépítést szeretnének.

1.3 Ki vagy?

Az egyetlen, aki olyan bolond, hogy ezt csinálja! Mint az ipchains társszerzõje és az aktuális Linux Kernel IP Firewall karbantartója látom azokat a problémákat, amelyek az alkalmazás során elõjönnek, valamint azokat a feladatokat, amiket egyes emberek megpróbálnak megoldani.

1.4 Miért omlott össze?

Woah! Bizonyára az elmúlt héten láttad!

Azért, mert nem vagyok egy nagy programozó - legalábbis mint szeretném, és természetesen nem tudtam minden esetet kitesztelni idõhiány, felszereltség és/vagy inspiráció miatt. Van egy tesztállományunk, aminek a kibõvítését bátran felajánlom.