iptables - szabályok sorrendje (szemlélet)

Linux-kezdő

Az világos, hogy ha mondjuk a 80-as porton publikus szolgáltatás fut, és tegyük fel, az x. szabályom az hogy

iptables -A INPUT --dport 80 -j DROP,

akkor hiába lesz az (x+n). szabály ugyanez csak az ACCEPT beépített céllal, nem fogják kintről elérni a 80-as portot, mert fentről lefelé szépen sorjában gondolkodik az iptables.

Nade van ugye 3 tábla (FILTER, MANGLE, NAT) és öt beépített lánc (INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING). Minden táblához több lánc tartozik, és -a másik irányból nézve- természetesen egy lánchoz több tábla is tartozhat.

Bár itt kell megemlíteni, hogy az álmoskönyv (Gregor N. Purdy) szerint nem túl jó az a szemlélet hogy a láncok a táblákhoz tartoznak. Inkább hívjuk a láncokat kapcsolódási pontoknak, amelyek a feldolgozás _folyamatában_ vesznek részt. A táblák pedig a feldolgozás típusát adják meg.

Hogyan kell nekiállni szigorú sorba tenni a szabályaimat? Én 3 esetet látok, de hogy melyik a jó, azaz melyik fog pontosan a célnak megfelelően (= a biztonsági szempontokat maximálisan figyelembe véve) működni, azt nem tudom. Ezek:

-lánconként (jellemzően INPUT, OUTPUT, esetleg FORWARD) bepakolom a szabályaimat, és a végére bedobok mondjuk portforwardhoz egy iptables -t nat -A PREROUTING kezdetű sort.
-táblánként (mondjuk NAT, FILTER)
-aszerint hogy a forgalom melyik csoportba tartozik a következők közül:

    -ethA -> ethB (FORWARDING)
    -local process A -> ethA (OUTPUT)
    -ethA -> local process A (INPUT)
    -local process A -> local process B (LOCAL)

Kérlek segítsetek, mert valami nagyon össze van keveredve a fejemben.

A szűrés kapcsán önmagában kevésnek érzem azt az indoklást hogy elég a filter táblán (ami ugye a default ha nem írunk táblanevet) szűrni. --> Miért?

http://dl.dropbox.com/u/3715374/iptables/nf-packet-flow.png
http://dl.dropbox.com/u/3715374/iptables/PacketFlow.png
http://dl.dropbox.com/u/3715374/iptables/Iptables_packet_traversal.png

  • 2288 megtekintés

( uid_2716 | 2010. 09. 04., szo – 00:15 )

Én úgy szoktam csinálni, hogy a filter táblában a legelején átcsapok minden (= INPUT, FORWARD, OUTPUT) policy-t DROP-ra. Az összes táblában megszüntetem az összes felhasználói láncot, a beépített láncokat pedig ürítem.

Ezután felveszem egyesével azokat az INPUT, OUTPUT és FORWARD szabályokat, a lehető legszigorúbban / legspecifikusabban, amelyekre feltétlenül szükségem van. (A legelső két szabály az, amely a loopback interface-en megengedi a kimenő ill. bejövő forgalmat.)

Az egészben a "vezérlő motívum" a hálózati interface (vagy interface-pár), vagyis csinálok egy rajzot, amin elhelyezem a gépet az összes lábával és a kapcsolódó szegmensekkel, és kitalálom, honnan fogadhatok mit, hova küldhetek mit, és honnan hova továbbíthatok mit.

Ha valahova SNAT/MASQ kell, akkor azt közvetlenül a FORWARD szabály előtt veszem fel a script-ben (persze ez a nat táblát érinti, nem a filter-t). A mangle táblával nem szokott dolgom lenni.

A filter tábla mindhárom sorának a végére ragasztok egy LOG szabályt (esetleg valami rate limiter-rel). A LOG nem-termináló szabály, így ezek után a DROP policy érvényesül.

A szűrés kapcsán önmagában kevésnek érzem azt az indoklást hogy elég a filter táblán (ami ugye a default ha nem írunk táblanevet) szűrni. --> Miért?

Azért, mert a filter táblának valamelyik default során (INPUT, OUTPUT, FORWARD) a csomag mindenképpen átmegy (ha addig el nem dobta már valami más mechanizmus, mittomén rp_filter vagy ilyesmi). Mivel a filter táblának mindhárom beépített során DROP-ra állítottuk a policy-t, ezért feledékenységgel tévedni csak biztonságos irányba tudunk. Túlzottan engedékeny, egyedi ACCEPT szabállyal persze tudunk ellenkező irányba is tévedni, de ezért kell a szabályokat a lehető legrészletesebben megadni. (A kimenő és bemenő interface a fentiek szerint az alap, azok alapján "bontjuk" a problémát; ezek mellett forrás- és cél-IP, protokoll, forrás- és célport, kapcsolatstátusz, csomag-flag-ek; amit csak meg lehet adni és ott éppen értelmes.)

A fentinél maradva, az ACCEPT szabályok sorrendje mindegy, legfeljebb a "gyakrabban tüzelőket" érdemes a láncok elejére rakni (ez az interface alapú bontásból ki tud esni). A sorrend akkor kritikus, ha if-then-else jellegű döntési fát csinálunk, saját láncokkal (amikor egyetlen szabállyal nem tudjuk eldönteni a csomag sorsát). Ilyet elég régen csináltam, és valóban elég nehezen átlátható.