Tűzfalak

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
(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., 00: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
  • 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

8 Ajánlott irodalom

A Skype-pal kapcsolatban:

Személyes eszközök