Tűzfalak
(v0.0) |
(v0.1) |
||
177. sor: | 177. sor: | ||
** -m random: véletlenszerűen illeszkedik (vagy nem); pl. véletlen csomagvesztés szimulálására jó |
** -m random: véletlenszerűen illeszkedik (vagy nem); pl. véletlen csomagvesztés szimulálására jó |
||
** -m recent: táblázatot csinálhatunk vele azokról az IP-kről, amelyeket valamilyen kontextusban "láttunk", aztán később vizsgálhatjuk, hogy elemei-e a táblázatnak; pl. primitív SMTP greylistingre jó, de sokminden másra is lehet használni: házi feladat |
** -m recent: táblázatot csinálhatunk vele azokról az IP-kről, amelyeket valamilyen kontextusban "láttunk", aztán később vizsgálhatjuk, hogy elemei-e a táblázatnak; pl. primitív SMTP greylistingre jó, de sokminden másra is lehet használni: házi feladat |
||
− | ** -m ipset: egyetlen szabállyal több IP-re is illeszthetünk (ez pl. akkor jó, ha ACL-t akarunk csinálni); külön programmal, az ipset-tel lehet az egyes halmazokat adminisztrálni. Házi feladat, vagy legközelebbre megnézem jobban is... |
+ | ** -m ipset: egyetlen szabállyal több IP-re is illeszthetünk (ez pl. akkor jó, ha ACL-t akarunk csinálni); külön programmal, az ipset-tel lehet az egyes halmazokat adminisztrálni. L. később. |
** -m state: a kapcsolat állapota |
** -m state: a kapcsolat állapota |
||
** -m string: a csomag tartalma |
** -m string: a csomag tartalma |
||
189. sor: | 189. sor: | ||
* REJECT |
* REJECT |
||
* DROP |
* DROP |
||
− | * LOG (de itt még nincs vége) |
+ | * LOG: naplóüzenetet generál, de folytatja a következő szabállyal |
* MARK |
* MARK |
||
* SNAT |
* SNAT |
||
* DNAT |
* DNAT |
||
+ | * RETURN |
||
* MASQUERADE |
* MASQUERADE |
||
− | * to be continued... |
+ | * BALANCE: round-robin terheléselosztáshoz |
+ | * CLASSIFY: forgalmi osztályba sorolás (aztán az osztálynak lehet sorbanállási prioritása, l. [http://www.lartc.org/ Linux Advanced Routing and Traffic Control HOWTO]) |
||
+ | * CLUSTERIP: elvileg terheléselosztó clustert lehet vele csinálni. Házi feladat. :) |
||
+ | * CONNMARK: a kapcsolathoz tartozó jelölés beállítása |
||
+ | * IPMARK: a forrás-IP-címből számítja ki a csomagra illesztendő jelölést (akkor jó, ha rengeteg usernek egyéni sávszélességkorlátokat ill. saját várakozási sort szeretnénk csinálni) |
||
+ | * IPV4OPTSSTRIP: leszedi az opciókat az IPv4-es csomagokról - ''mikor van értelme?'' |
||
+ | * LOG: naplózza az illeszkedő csomagokat; a feldolgozás a következő szabálynál folytatódik. |
||
+ | * MARK: csomag megjelölése |
||
+ | * NETMAP: tömeges NAT, címtér-tömörítés nélkül (pl. egy /16-os hálózatot leképez egy másikra) |
||
+ | * QUEUE/NFQUEUE: átadja a csomagot egy userspace programnak (ami már fut és regisztrálta magát a kernelben) |
||
+ | * NOTRACK: az illeszkedő csomagokra nem kérünk kapcsolatkövetést. Erőforrást takarít meg; mondjuk beállíthatjuk a DNS-szerverünk felé menő 53/udp csomagokon. |
||
+ | * REDIRECT: átírja a célcímet a lokális gép címére, a portot megadhatjuk (pl. transzparens http-proxyhoz) |
||
+ | * ROUTE: routing-gányolás. Megadhatjuk, melyik interface-en menjen ki a csomag, vagy hogy melyiken jött be (!), vagy hogy melyik gatewayen át kell küldeni. Le is tudja másolni a csomagot, így lehet pl. monitoring portot eszkábálni linuxos switchre. |
||
+ | * SET: hozzáadja a forrás- vagy cél-IP-t vagy -portot egy ipset-hez, vagy törli belőle (l. később) |
||
+ | * TARPIT: tcp-s "szurokgödör"; váratja a túloldalt, a kapcsolatot nem hagyja lebontani (pl. féregterjedés lassítására ajánlják - de csak buta féreg ellen jó, ill. buta portscan ellen is) |
||
+ | * TCPMSS: workaround arra az esetre, ha az upstream szolgáltató szűrné az ICMP fragmentation needed üzeneteket: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu |
||
+ | * TRACE: bekapcsolja a nyomkövetést az adott csomagon. Naplóüzenet keletkezik, valahányszor a csomag illeszkedik egy szabályra. |
||
+ | * TTL: a TTL-mezőt állítgathatjuk vele - ''miért akarnánk ilyet csinálni?'' |
||
+ | * ULOG: összetett naplózás. Házi feladat. |
||
+ | * XOR: egyszerű "titkosítás" |
||
+ | |||
+ | == Tűzfalscriptek írása == |
||
+ | |||
+ | Általános jótanács: ha nem ülünk a gép előtt, mindig hagyjunk egérutat új tűzfalkonfiguráció élesítésekor; nem jó egy elgépelés miatt utazni. |
||
+ | |||
+ | * Naiv módszer: rakjuk össze a szabályrendszert a parancssorból. Az iptables-save elmenti, utána rebootkor, vagy amikor kell, az iptables-restore-ral betölthetjük. |
||
+ | ** Előnyök: |
||
+ | *** Egyszerű |
||
+ | *** Gyorsan megvan |
||
+ | *** Újratöltéskor a szabályok betöltése atomi |
||
+ | *** Viszonylag könnyű permanens módosításokat automatizálni |
||
+ | ** Hátrányok: |
||
+ | *** Karbantartás nehézkes |
||
+ | *** Dinamikus szabályok készítése nehézkes (pl. dinamikus hostnevek IP-címeinek követése) |
||
+ | *** Kommentálás problémás |
||
+ | *** Könnyen átláthatatlanná válik |
||
+ | *** Nem választja el a "kódot" a konfigurációtól |
||
+ | *** Nehéz a konfiguráció bizonyos részeit más gépen újrahasznosítani |
||
+ | *** Nehéz nem azonos, de hasonló tűzfalakat szinkronban tartani |
||
+ | *** Jogok részleges delegálása lehetetlen |
||
+ | * Spagettiscript: írjunk egy monolitikus scriptet, ami először töröl minden szabályt, majd betölti a szükséges szabályokat |
||
+ | ** Előnyök: |
||
+ | *** Egyszerű |
||
+ | *** Viszonylag gyorsan megvan |
||
+ | *** Dinamikus szabályokat is megadhatunk (betöltéskor lesz DNS lookup) |
||
+ | *** A script kommentálható |
||
+ | *** Minimális mértékben elválasztható a kód és a konfiguráció (pl. a script elején shell-változókban beállíthatjuk a "konfigurációt") |
||
+ | *** A script bizonyos részeit átvihetjük más gépre |
||
+ | ** Hátrányok: |
||
+ | *** Ha több dinamikus szabály is felhasználja ugyanazt a hosztnevet, feleslegesen lassú |
||
+ | *** Könnyen átláthatatlanná válik |
||
+ | *** Nehéz nem azonos, de hasonló tűzfalakat szinkronban tartani |
||
+ | *** Sok gépelést igényel (ami sok hibalehetőség és rontja az átláthatóságot) |
||
+ | *** A tűzfalszabályok betöltése nem atomi |
||
+ | *** Nehéz permanens módosításokat automatizálni |
||
+ | *** Jogok részleges delegálása lehetetlen |
||
+ | * Strukturált script: |
||
+ | ** Shell tömbök adják a konfiguráció ACL-jeit (pl. WEBSERVERS="192.168.1.2 192.168.1.3 192.168.1.4") |
||
+ | ** Shell függvények felelősek bizonyos láncok összeállításáért (pl. ACCEPT() proto tcp from 0/0 to "$WEBSERVERS" srcport any dstport 80 parent INPUT) |
||
+ | ** A DNS-alapú szabályokhoz szükséges DNS-feloldásokat egyszer végezzük el, az eredményt tároljuk és újrafelhasználjuk |
||
+ | ** Előnyök: |
||
+ | *** Jól szétválasztja a kódot és a konfigurációt |
||
+ | *** Átláthatóvá tehető |
||
+ | *** Aránylag gyorsan lefut (bár sok szabály felvétele még mindig lassú) |
||
+ | ** Hátrányok: |
||
+ | *** A shell-függvényeket meg kell hozzá írni, és ez nem feltétlenül triviális (''vagy: van kész megoldás?'') |
||
+ | *** A kódot rajtunk kívül senki sem érti majd |
||
+ | *** A tűzfalszabályok betöltése nem atomi |
||
+ | *** Nehéz (bár már könnyebb) nem azonos, de hasonló tűzfalakat szinkronban tartani |
||
+ | *** Nehéz permanens módosításokat automatizálni |
||
+ | *** Jogok részleges delegálása lehetetlen |
||
+ | * Strukturált, modularizált script: |
||
+ | ** Mint fent, de rc.d mechanizmust használva szétszedjük sok kicsi file-ra |
||
+ | ** Az ACL-ekhez használjunk felsorolás-file-okat |
||
+ | ** Előnyök: |
||
+ | *** Teljesen szétválasztja a kódot és a konfigurációt |
||
+ | *** Átláthatóvá tehető |
||
+ | *** Könnyű nem azonos, de hasonló tűzfalakat szinkronban tartani |
||
+ | *** Jogok részleges delegálása körülményes, de megoldható |
||
+ | ** Hátrányok: |
||
+ | *** A shell-függvényeket meg kell hozzá írni (bár van kész megoldás, az "iptablez" by yours truly) |
||
+ | *** A kódot rajtunk kívül senki sem érti majd |
||
+ | *** A tűzfalszabályok betöltése nem atomi |
||
+ | * További javítási lehetőség: ne az iptables-t hívogassuk, hanem állítsunk elő iptables-restore formátumú szövegfile-t, majd a végén töltsük be azt |
||
+ | ** Így atomivá válik a szabályok betöltése |
||
+ | |||
+ | == Ajánlott irodalom == |
||
+ | |||
+ | A Skype-pal kapcsolatban: |
||
+ | |||
+ | * [http://en.wikipedia.org/wiki/Skype Wikipedia szócikk] |
||
+ | * [http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pdf Silver Needle in the Skype], egy prezentáció a Skype visszafejtéséről |
A lap 2006. november 3., 01:37-kori változata
Az iptables a Linux kernelben található Netfilter csomagszűrő userspace komponense; egy olyan program, amellyel a Netfilter beállításait kezelhetjük.
A továbbiakban nem teszünk éles különbséget az iptables és a Netfilter között; a szövegkörnyezetből mindig egyértelmű lesz, melyikről van szó.
Tartalomjegyzék |
1 Fogalmak
Az iptables működésének megértéséhez fontos tudni, mi a csomagszűrő (packet filter) és mi a kapcsolatkövető tűzfal (connection tracking firewall).
1.1 Tűzfal
A tűzfal általánosságban egy olyan hálózati eszköz (általában router), amely a rajta áthaladó forgalmat "jólformálttá" teszi annak érdekében, hogy az egyes interface-eihez tartozó hálózatokat kölcsönösen megvédje a többiből érkező "érvénytelen" (vagy legalábbis érdektelen) kommunikációtól.
Különböző tűzfalmegoldásokkal más-más mértékű "jólformáltság" érhető el.
1.2 Csomagszűrő
A csomagszűrő minden egyes csomagról önmagában dönti el, hogy áthaladhat-e a tűzfalon. A döntéshez felhasználhat mindent, amit az adott csomagról tud, akár a tartalmát is, de általában a fejléc alapján születik a döntés.
Előnye, hogy állapotmentes, így elvileg akárhány kapcsolatot tud kezelni.
Hátránya, hogy buta és rugalmatlan: pl. nem tudja megállapítani, hogy egy új TCP-kapcsolat egy már fennálló FTP-kapcsolathoz tartozó adatkapcsolat-e.
A Netfilterrel építhetünk ilyet, de általában jobb kapcsolatkövető tűzfalat csinálni.
1.3 Kapcsolatkövető csomagszűrő
Olyan tűzfal, amely a nyomon követi a rajta keresztül felépített hálózati kapcsolatok állapotát, és ezt az információt is fel tudja használni a döntés során.
1.4 NAT, PAT
Network Address Translation, Port Address Translation.
A Linux összemossa a tűzfalfunkcióval.
1.5 Fogalmak a Netfilter/iptables körül
Alulról felfelé haladva az iptables a következő fogalmakkal dolgozik:
- match (illesztés): egy feltétel, amelynek egy csomag meg kell, hogy feleljen. Pl.:
- forrás-IP
- protokoll
- célport
- a kapcsolat állapota
- melyik interface-en jön be vagy megy ki
- rengeteg más match van
- akció (target): döntés arról, hogy mi történjen egy csomaggal, pl.:
- engedélyezés
- eldobás
- visszautasítás (pl. TCP RST-vel vagy icmp admin-prohib üzenettel)
- ugrás másik láncra (l. lejjebb)
- van még jópár akció
- szabály (rule): ÉS kapcsolatban levő matchek és egy akció együttese. Ha minden match illeszkedik, az adott csomagon az adott akciót kell végrehajtani.
- lánc (chain): a szabályokat "láncokra" tudjuk felfűzni. Ha egy csomag eljut egy láncba, akkor a kernel sorban minden szabályt kiértékel, amíg az első olyat meg nem találja, amire a csomag illeszkedik. Ennek az akcióját végrehajtja, és a későbbi szabályokat figyelmen kívül hagyja.
- láncokat definiálhatunk mi is, de van néhány speciális, beépített lánc (l. később)
- a beépített láncoknak lehet "policy"-je, ami azt adja meg, mi történjen azokkal a csomagokkal, amelyekről egyetlen szabály sem rendelkezett
- tábla: láncok vannak benne. Bizonyos akciók csak bizonyos táblákban értelmezettek; pl. van nat tábla, amiben NATolhatunk. A csomagok meghatározott sorrendben járják be a táblákat.
A csomag útjának megértésében sokat segít a (sajnos nem feltétlenül naprakész, teljes és pontos) "Kernel Packet Traveling Diagram".
2 Táblák
- filter: INPUT, OUTPUT és FORWARD lánc; szűrésre való
- nat: PREROUTING, OUTPUT és POSTROUTING lánc; címfordításra való
- mangle: PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING lánc; bizonyos csomagmódosításokat lehet itt elvégezni
- raw: PREROUTING és OUTPUT lánc; megjelölhetjük benne azokat a csomagokat, amelyekre nem kérünk kapcsolatkövetést.
3 Az iptables parancssora
- iptables [-t table] -A chain rule-specification [options]
- új szabály felvétele a lánc végén
- iptables [-t table] -D chain rule-specification [options]
- szabály törlése a láncból a törlendő szabály megadásával
- iptables [-t table] -D chain rulenum [options]
- szabály törlése a láncból a sorszáma megadásával
- iptables [-t table] -I chain [rulenum] rule-specification [options]
- szabály beszúrása a láncba (scriptben ne használjuk)
- iptables [-t table] -R chain rulenum rule-specification [options]
- szabály cseréje (scriptben ne használjuk)
- iptables [-t table] -L [chain] [options]
- lánc listázása
- iptables [-t table] -F [chain] [options]
- lánc törlése (flush)
- iptables [-t table] -Z [chain] [options]
- csomag- és byte-számlálók törlése
- iptables [-t table] -N chain
- új lánc létrehozása
- iptables [-t table] -X [chain]
- lánc törlése (csak, ha már nincs benne szabály, és rá se hivatkozik szabály)
- iptables [-t table] -P chain target [options]
- policy beállítása
- iptables [-t table] -E old-chain-name new-chain-name
- lánc átnevezése
Példa pár szabály felvételére:
iptables -A INPUT -p tcp --dport ssh -s 1.2.3.4 -j ACCEPT iptables -A INPUT -p tcp --dport ssh -j REJECT --reject-with tcp-reset iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
A -j-vel ugorhatunk más láncra is:
iptables -N ssh_input iptables -A INPUT -p tcp --dport ssh -j ssh_input iptables -A ssh_input -s 1.2.3.4 -j ACCEPT iptables -A ssh_input -s 2.3.4.5 -j ACCEPT iptables -A ssh_input -s 3.4.5.192/26 -j ACCEPT iptables -A ssh_input -m limit --limit 3/minute -j LOG --log-prefix "FW: ssh_input REJECT: " iptables -A ssh_input -p tcp -j REJECT --reject-with tcp-reset iptables -A ssh_input -j DROP
Itt -j ("jump") helyett írhattam volna -g-t ("goto") is; a különbség az, hogy -j esetén, ha a meghívott láncban nincs illeszkedő szabály, akkor a -j-s szabály után folytatódik a szabályok kiértékelése (tehát ez "gosub"), míg -g esetén, ha nincs egyezés, akkor az utolsó kiértékelt -j után. Mi van, ha beépített láncban használjuk a goto-t?
Sem a matchek, sem az akció megadása nem kötelező. Akciómentes szabályt használhatunk pl. forgalomszámolásra.
4 Kapcsolók
- -c: csomag- és byte-számlálók kézi beállítása
- -n: ne legyen reverse-DNS-feloldás a listázáskor (ott van helyette az adnsresfilter, ha muszáj)
- -v: szószátyárabb output (nemcsak listázásnál)
- -x: számlálók pontos értékkel, nem SI prefixekkel jelennek meg
- --line-numbers: minden szabály elé odaírja, hanyadik a láncban
5 Match-ek
- -p, --protocol protokoll
- -s, --source cím[/maszk]: cím lehet hosztnév is; ha több IP tartozik hozzá, minden IP-hez külön szabály képződik
- -i, --in-interface név
- -o, --out-interface név
- -f, --fragment
- --icmp-type típus
- --sport, --dport port[:port]: tcp, udp forrás- ill. célport
- --tcp-flags vizsgálandók melyiklegyenbeállítva
- --syn == --tcp-flags SYN,RST,ACK,FIN SYN
- -m modulnév: bővített matchek. Ezek közül néhány érdekesebb:
- -m account: forgalomstatisztika, házi feladat; [1]
- -m addrtype: forrás- vagy célcím osztálya (UNICAST, BROADCAST, MULTICAST stb.)
- -m childlevel: "főkapcsolat" vagy "gyermekkapcsolat" (pl. ftp-data)
- -m comment: no-op, kommentálni lehet vele a szabályt: iptables -A INPUT -s 192.168.0.0/16 -m comment --comment "A privatized IP block" -j valahova
- -m condition: létrehoz nekünk egy file-t a /proc-ban, és attól függően illeszkedik vagy nem, hogy abba a file-ba egyest vagy nullát írunk
- -m connbytes: az adott kapcsolathoz tartozó adatforgalom nagysága alapján matchel (csomagszám, byte-szám vagy átlagos csomagméret)
- -m connlimit: kapcsolatok számának korlátozása. Példák:
# allow 2 telnet connections per client host iptables -p tcp --syn --dport 23 -m connlimit --connlimit-above 2 -j REJECT # you can also match the other way around: iptables -p tcp --syn --dport 23 -m connlimit ! --connlimit-above 2 -j ACCEPT # limit the nr of parallel http requests to 16 per class C sized network (24 bit netmask) iptables -p tcp --syn --dport 80 -m connlimit --connlimit-above 16 --connlimit-mask 24 -j REJECT
- -m connmark: a kapcsolatokat meg lehet jelölni a mangle táblában; ezzel a matchel vizsgáljuk, hogy egy adott kapcsolaton egy adott jelzés van-e
- -m connrate: a kapcsolat aktuális adatátviteli sebességét nézi
- -m conntrack: a kapcsolatkövető mechanizmus belső paraméterei alapján matchel. Értelmes felhasználás: házi feladat. :)
- -m ecn: explicit congestion notification, RFC3168: házi feladat
- -m fuzzy: fuzzy ratelimit. Értelmes felhasználás: házi feladat. :)
- -m hashlimit: rátalimit, de nem szabályonként, hanem szabályonként és cécímenként vagy célcím-célport-páronként. Házi feladat.
- -m iprange: net/maszk helyett ip1-ip2 alakban adható meg tartomány
- -m length: csomagméret
- -m limit: rátalimit. A szabály legfeljebb x alkalommal illeszkedik y idő alatt. Logoláshoz jó.
- -m mac: ethernet-forráscím
- -m mark: a kapcsolatokhoz hasonlóan egyes csomagokat is meg lehet jelölni, erre illeszthetünk ezzel a match-csel
- -m mport: több port sorolható fel
- -m multiport: majdnem ugyanaz, de a felsorolásban szerepelhet tartomány is
- -m nth: minden n. alkalommal illeszkedik
- -m osf: passzív OS fingerprinting (pl. csak linuxos gépek küldhetnek levelet). Nem bombabiztos, inkább játék.
- -m owner: a csomagot küldő folyamat UID, GID, PID, SID (session ID) értékei, ill. a processz neve alapján matchel
- -m physdev: bridge interface esetén a fizikai interface-re matchel
- -m pkttype: adatkapcsolati rétegbeli címtípus (unicast|broadcast|multicast)
- -m psd: portscan-detektor. Nemigen van értelme.
- -m quota: forgalmi kvótát lehet csinálni vele
- -m random: véletlenszerűen illeszkedik (vagy nem); pl. véletlen csomagvesztés szimulálására jó
- -m recent: táblázatot csinálhatunk vele azokról az IP-kről, amelyeket valamilyen kontextusban "láttunk", aztán később vizsgálhatjuk, hogy elemei-e a táblázatnak; pl. primitív SMTP greylistingre jó, de sokminden másra is lehet használni: házi feladat
- -m ipset: egyetlen szabállyal több IP-re is illeszthetünk (ez pl. akkor jó, ha ACL-t akarunk csinálni); külön programmal, az ipset-tel lehet az egyes halmazokat adminisztrálni. L. később.
- -m state: a kapcsolat állapota
- -m string: a csomag tartalma
- -m time: dátumhoz ill. napszakhoz kötött illesztés
- -m tos
- -m ttl
6 Akciók
- ACCEPT
- REJECT
- DROP
- LOG: naplóüzenetet generál, de folytatja a következő szabállyal
- MARK
- SNAT
- DNAT
- RETURN
- MASQUERADE
- BALANCE: round-robin terheléselosztáshoz
- CLASSIFY: forgalmi osztályba sorolás (aztán az osztálynak lehet sorbanállási prioritása, l. Linux Advanced Routing and Traffic Control HOWTO)
- CLUSTERIP: elvileg terheléselosztó clustert lehet vele csinálni. Házi feladat. :)
- CONNMARK: a kapcsolathoz tartozó jelölés beállítása
- IPMARK: a forrás-IP-címből számítja ki a csomagra illesztendő jelölést (akkor jó, ha rengeteg usernek egyéni sávszélességkorlátokat ill. saját várakozási sort szeretnénk csinálni)
- IPV4OPTSSTRIP: leszedi az opciókat az IPv4-es csomagokról - mikor van értelme?
- LOG: naplózza az illeszkedő csomagokat; a feldolgozás a következő szabálynál folytatódik.
- MARK: csomag megjelölése
- NETMAP: tömeges NAT, címtér-tömörítés nélkül (pl. egy /16-os hálózatot leképez egy másikra)
- QUEUE/NFQUEUE: átadja a csomagot egy userspace programnak (ami már fut és regisztrálta magát a kernelben)
- NOTRACK: az illeszkedő csomagokra nem kérünk kapcsolatkövetést. Erőforrást takarít meg; mondjuk beállíthatjuk a DNS-szerverünk felé menő 53/udp csomagokon.
- REDIRECT: átírja a célcímet a lokális gép címére, a portot megadhatjuk (pl. transzparens http-proxyhoz)
- ROUTE: routing-gányolás. Megadhatjuk, melyik interface-en menjen ki a csomag, vagy hogy melyiken jött be (!), vagy hogy melyik gatewayen át kell küldeni. Le is tudja másolni a csomagot, így lehet pl. monitoring portot eszkábálni linuxos switchre.
- SET: hozzáadja a forrás- vagy cél-IP-t vagy -portot egy ipset-hez, vagy törli belőle (l. később)
- TARPIT: tcp-s "szurokgödör"; váratja a túloldalt, a kapcsolatot nem hagyja lebontani (pl. féregterjedés lassítására ajánlják - de csak buta féreg ellen jó, ill. buta portscan ellen is)
- TCPMSS: workaround arra az esetre, ha az upstream szolgáltató szűrné az ICMP fragmentation needed üzeneteket: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
- TRACE: bekapcsolja a nyomkövetést az adott csomagon. Naplóüzenet keletkezik, valahányszor a csomag illeszkedik egy szabályra.
- TTL: a TTL-mezőt állítgathatjuk vele - miért akarnánk ilyet csinálni?
- ULOG: összetett naplózás. Házi feladat.
- XOR: egyszerű "titkosítás"
7 Tűzfalscriptek írása
Általános jótanács: ha nem ülünk a gép előtt, mindig hagyjunk egérutat új tűzfalkonfiguráció élesítésekor; nem jó egy elgépelés miatt utazni.
- Naiv módszer: rakjuk össze a szabályrendszert a parancssorból. Az iptables-save elmenti, utána rebootkor, vagy amikor kell, az iptables-restore-ral betölthetjük.
- Előnyök:
- Egyszerű
- Gyorsan megvan
- Újratöltéskor a szabályok betöltése atomi
- Viszonylag könnyű permanens módosításokat automatizálni
- Hátrányok:
- Karbantartás nehézkes
- Dinamikus szabályok készítése nehézkes (pl. dinamikus hostnevek IP-címeinek követése)
- Kommentálás problémás
- Könnyen átláthatatlanná válik
- Nem választja el a "kódot" a konfigurációtól
- Nehéz a konfiguráció bizonyos részeit más gépen újrahasznosítani
- Nehéz nem azonos, de hasonló tűzfalakat szinkronban tartani
- Jogok részleges delegálása lehetetlen
- Előnyök:
- Spagettiscript: írjunk egy monolitikus scriptet, ami először töröl minden szabályt, majd betölti a szükséges szabályokat
- Előnyök:
- Egyszerű
- Viszonylag gyorsan megvan
- Dinamikus szabályokat is megadhatunk (betöltéskor lesz DNS lookup)
- A script kommentálható
- Minimális mértékben elválasztható a kód és a konfiguráció (pl. a script elején shell-változókban beállíthatjuk a "konfigurációt")
- A script bizonyos részeit átvihetjük más gépre
- Hátrányok:
- Ha több dinamikus szabály is felhasználja ugyanazt a hosztnevet, feleslegesen lassú
- Könnyen átláthatatlanná válik
- Nehéz nem azonos, de hasonló tűzfalakat szinkronban tartani
- Sok gépelést igényel (ami sok hibalehetőség és rontja az átláthatóságot)
- A tűzfalszabályok betöltése nem atomi
- Nehéz permanens módosításokat automatizálni
- Jogok részleges delegálása lehetetlen
- Előnyök:
- Strukturált script:
- Shell tömbök adják a konfiguráció ACL-jeit (pl. WEBSERVERS="192.168.1.2 192.168.1.3 192.168.1.4")
- Shell függvények felelősek bizonyos láncok összeállításáért (pl. ACCEPT() proto tcp from 0/0 to "$WEBSERVERS" srcport any dstport 80 parent INPUT)
- A DNS-alapú szabályokhoz szükséges DNS-feloldásokat egyszer végezzük el, az eredményt tároljuk és újrafelhasználjuk
- Előnyök:
- Jól szétválasztja a kódot és a konfigurációt
- Átláthatóvá tehető
- Aránylag gyorsan lefut (bár sok szabály felvétele még mindig lassú)
- Hátrányok:
- A shell-függvényeket meg kell hozzá írni, és ez nem feltétlenül triviális (vagy: van kész megoldás?)
- A kódot rajtunk kívül senki sem érti majd
- A tűzfalszabályok betöltése nem atomi
- Nehéz (bár már könnyebb) nem azonos, de hasonló tűzfalakat szinkronban tartani
- Nehéz permanens módosításokat automatizálni
- Jogok részleges delegálása lehetetlen
- Strukturált, modularizált script:
- Mint fent, de rc.d mechanizmust használva szétszedjük sok kicsi file-ra
- Az ACL-ekhez használjunk felsorolás-file-okat
- Előnyök:
- Teljesen szétválasztja a kódot és a konfigurációt
- Átláthatóvá tehető
- Könnyű nem azonos, de hasonló tűzfalakat szinkronban tartani
- Jogok részleges delegálása körülményes, de megoldható
- Hátrányok:
- A shell-függvényeket meg kell hozzá írni (bár van kész megoldás, az "iptablez" by yours truly)
- A kódot rajtunk kívül senki sem érti majd
- A tűzfalszabályok betöltése nem atomi
- További javítási lehetőség: ne az iptables-t hívogassuk, hanem állítsunk elő iptables-restore formátumú szövegfile-t, majd a végén töltsük be azt
- Így atomivá válik a szabályok betöltése
8 Ajánlott irodalom
A Skype-pal kapcsolatban:
- Wikipedia szócikk
- Silver Needle in the Skype, egy prezentáció a Skype visszafejtéséről