tuzfal

Hálózatok általános

pistike irodai gepere nem akarunk beengedni senkit kivulrol, kifele meg csak tcp kapcsolatokat kezdemenyezhet (email letoltes, ssh, web, barmi). mi a kulonbseg a gyakorlatban es/vagy biztonsagi szempontbol az alabbi ket iptables-alapu implementacio kozott? 


...
-A INPUT -d 11.22.33.44 -p tcp -m tcp --syn -j DROP
-A INPUT -d 11.22.33.44 -p tcp -j ACCEPT
...

illetve 


...
-A INPUT -d 11.22.33.44 -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -d 11.22.33.44 -p tcp -j DROP
...

(a ...-ba megy a loopback ill a -s 11.22.33.44 -d 11.22.33.44 tipusu szabalyok engedelyezese ill minden egyeb csomag ejte'se, stb; ill szerk: a --syn azt takarja, hogy a syn/ack/rst/fin bitekbo"l csak a syn lehet 1, a tobbi 0).

  • 1507 megtekintés

( stra | 2010. 09. 16., cs – 19:00 )

Hogy csak a legtriviálisabb dolgot említsük ami működik a második esetben, de az elsőben nem: pl. aktív FTP. Nem működik a részben TCP alapú PPTP sem az első esetben (a másodikban is csak akkor, ha az állapotvizsgálatot nem korlátozzuk kizárólag a TCP-re). Továbbá a kapcsolódó ICMP üzenetek is célba érnek. Használjuk ki a connection trackinget, hogy nem kell bajlódnunk ezekkel.

Ezen kívül az első példánál az INVALID állapot által lefedett esetekben, illetve a kezdő SYN nélkül jövő TCP-nél ACCEPT lesz, hibásan.

(Itt szokott lenni a netfilter egyik atyja, tanulságos, amikor ilyen esetekben hozzászól.)

Hogy csak a legtriviálisabb dolgot említsük
igen, az aktiv ftp az ilyen, de azert az egy elegge beteg protokoll, ugy enbloc. azt nem is engedelyezzuk :]

Ezen kívül az első példánál az INVALID állapot által lefedett esetekben, illetve a kezdő SYN nélkül jövő TCP-nél ACCEPT lesz, hibásan.
na ezaz. ez jelenthet barmi biztonsagi(bb) kockazatot? a sporadikus csomagokat a tcp stack ugyis dobja, tehat oda bele eppenseggel csak adott isrc:psrc:idst:pdst kerulhetnek vissza, ettol eltero port/ip ma'r nem.

Túlfolyásos támadás bárhol lehet nem?
syn flood-ra gondolsz? (bocs, csak igy laikuskent nem ismerem a bevett magyar kifejezest, sajnos :/) viszon syn flood ellen mindke't modszer ve'd (syn drop nyilvan, es persze a masik is, lasd fentebbi feltetel, hogy mind a 4 parameternek /2 ip + 2 port/ stimmelnie kell, ill ha ez stimmel es csak syn aktiv az meg hibas allapot, tehat a stack dobja).

Fura, hogy a bejövő ágon csak a tcp csomagokkal foglalkoztunk.
Hogy pl. az ICMP-val mi történik, az a kipontozott sorokban dől el...

Az álmoskönyvek szerint nem árt átengedni a kapcsolódó ICMP csomagokat is!
Ha pedig ftp-t akarunk engedni, akkor se engedjünk mindenféle ismeretlen related TCP csomagot, hanem a state helyett használjuk a helper modult.

Az alábbi input szabályrendszert javasolnám kiindulási alapnak: 


iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT         -m state  --state ESTABLISHED -j ACCEPT
iptables -A INPUT -p icmp -m state  --state RELATED     -j ACCEPT
iptables -A INPUT         -m helper --helper ftp        -j ACCEPT
iptables -A INPUT -j DROP

"Fura, hogy a bejövő ágon csak a tcp csomagokkal foglalkoztunk."
Mivel az én hzzászólásomra válaszoltál, jelzem, hogy én is megemlítettem a második változat javára a RELATED által lekezelt kapcsolódó ICMP forgalmat. Természetesen fontos.

"a state helyett használjuk a helper modult."
De akkor feltennék én is egy kérdést. A kérdés általános is lehetne, de a szemléltetés miatt maradjunk az FTP-nél. Mennyiben érzed biztonságosabbnak az FTP esetében a helper match használatát a RELATED-del szemben? Ha jól sejtem, az FTP esetében a helper munkájának hatására kerül rá a RELATED címke az adatcsatorna forgalmára, mint ahogy a helper match is az adott helper által kezelt RELATED-nek minősülő forgalomra illeszkedik. Van-e valahol olyan pont, ahol anélkül válhat RELATED-dé egy TCP session, hogy azt ne a felelős FTP helper illesztette volna rá a meglévő kontrollcsatorna forgalmának tartalma alapján? Én úgy érzem, a háttérben ugyanaz van mindkettő mögött ebben a konkrét esetben.

A topiknyitó viszont nem kizárólag az FTP-t szeretné engedni, hanem a TCP forgalmat. Amibe viszont más protokollok is beletartoznak. Jobbnak gondolod mindegyiket külön-külön felsorolni helper match-csel, minthogy egy közös RELATED legyen?

A félreértések elkerülése végett: nem az általad vázoltak működőképességét vagy jóságát vitatom, csak az eredeti kérdés, ti. a biztonság okán az kimenő FTP kapcsolathosz tartozó TCP forgalom input irányú szűrésének kétféle megközelítését szeretném összevetni.

A jelen egyszerű esetben én sem érzem feltétlen szükségét a helpernek, de összetetteb, párszáz soros szabályrendszernél már nem árt tudni, hogy az adott ágacskán melyik helper általi related csomagokat akarjuk átengedni.

Másrészt a mindenhol csak a minimálisan szükségeset engedjük alapján inkább használom a szorosabb feltételt támasztó helper modult.
Elvileg itt nincs rá semmi ok, de ki tudja, bármi kódhiba vagy akármi miatt RELATED-é válik egy csomag, akkor még nem biztos, hogy az ftp helper illeszkedik rá. Azt viszont elismerem, hogy ez már fokozott paranoia :) Nem hiszem, hogy reális esélye lenne ilyen csomaganak, azt meg még kevésbé hiszem, hogy valóban ártalmas tudna lenni.