Tűzfal miatt nem megy az ftp.

Linux-kezdő

Sziasztok!

iptables-szel kapcsolatban van egy kis gondom. Szeretném tiltani a hálózaton (NAT) a DC futtatást és engedélyezni az FTP-t.
A következő két sorral próbláltam ezt elérni:

#FTP engedelyezes
iptables -A FORWARD -o $EXTINT -p tcp --dport 21 -j ACCEPT

#Nem publikus portok kitiltása a DC miatt
iptables -A FORWARD -p tcp -s 192.168.1.0/24 --dport $UNPRIVPORTS -j DROP

Így nem megy a DC, de az FTP sem. Én úgy tudom, hogy az FTP kapcsolatok a 21-es porton működnek.
Ha kikommentezem a második bejegyzést akkor működik mindkettő. Nem értem miért fáj az FTP nek, hogy kitiltom a forward láncban az 1024-esnél nagyobb portokat. (ESTABLISHED, RELATED engedélyezve van
iptables -A FORWARD -m state --state ESTABLISHED -j ACCEPT
iptables -A FORWARD -m state --state RELATED -j ACCEPT
).

  • 2433 megtekintés

( sany | 2006. 06. 27., k – 18:37 )

$UNPRIVPORTS

ebben nem került bele véletlenül a 21 port is?

Íme a forward lánc: (Policy DROP)
#FORWARD LANC SZABALYAI
#######################
#KULSO INTERFACE

#Meglevo kapcsolatok engedelyezese
iptables -A FORWARD -m state --state ESTABLISHED -j ACCEPT
iptables -A FORWARD -m state --state RELATED -j ACCEPT

#DNS engedelyezese
iptables -A FORWARD -o $EXTINT -p udp --dport 53 -j ACCEPT
iptables -A FORWARD -o $EXTINT -p tcp --dport 53 -j ACCEPT

#PING kiengedese
iptables -A FORWARD -o $EXTINT -p icmp -j ACCEPT

#HTTP engedelyezese
iptables -A FORWARD -o $EXTINT -p tcp --dport 80 -j ACCEPT

#FTP engedelyezes
iptables -A FORWARD -o $EXTINT -p tcp --dport 21 -j ACCEPT

#Portok kitilt�sa
iptables -A FORWARD -p tcp -s 192.168.1.0/24 --dport $UNPRIVPORTS -j DROP

#LAN INTERFACE
#Minden csomag engedese a belso halozatrol
iptables -A FORWARD -i $INTINT -s 192.168.1.0/24 -j ACCEPT

( zither | 2006. 06. 27., k – 19:01 )

Az ftp a 21 _és_ 20 portokat használja. Az egyiken az adatok, a másikon a kapcsolatot szabályozó üzenetek utaznak.

Többek között ez az egyik oka annak, hogy nem megy.
A másik, hogy pont e miatt az öszetett elrendezés miatt a netfilter (iptables) alapból nem tudja lekezelni a státusz alapján (tehát hiába írod le, attól még nem fog rá illeszkedni state kitételű szabály). Szerencsére erre is van megoldás, csak néhány kernel modult be kell tölteni hozzá:

modprobe ip_conntrack_ftp #hogy a tűzfal tudjon ftp-t (frissítéshez)
modprobe iptable_nat #a NAT modulja, gondolom betöltötted
modprobe ip_nat_ftp #az ftp NAT-olásához kell.

Harmadszor a címfordításhoz (NAT) egy ilyen jellegű szabály kell:
iptables -t nat -A POSTROUTING -o $IFACE_EXT -j MASQUERADE

Egyébként van kinnt egy elég jó tűzfal szkriptem (elég bonyolult is). Ötletek szerintem tudsz belőle meríteni, hogy mit is kellene csinálni: http://free.x3.hu/zither/firewall.txt
Sok sikert a beállításhoz és a tanulmányozáshoz is (szerintem fogsz rajta kicsit agyalni mire megérted minden részét).

Zavard össze a világot: mosolyogj hétfőn.

Igazából ezt a megfelelő RFC-ből lehetne megtudni, bár az a gyanúm, hogy a megadott-1 portot használja.
Ettől függetlenül nem ilyen esetekre cél a felkészülés (sőt, jobb ha ezeket már hálózati policy-ben kizárjuk), hanem a szbványos esetekre.
Ekkor elsődleges forrás az IANA szabványosított portlistája: http://www.iana.org/assignments/port-numbers . (És csodák csodájára a 20,21-ben megtalálod az ftp-t. Csupán úgy tűnik, hogy pont fordítva van, mint írtam, a 21 a kontroll és a 20 az adat. Bár ez azt hiszem jelen helyzetben részlet kérdés)

Zavard össze a világot: mosolyogj hétfőn.

Hah! Az FTP és szépségei... :-))

Az FTP mint olyan nagyon nem tűzfalakra lett kitalálva. Megpróbálom közérthetően elmagyarázni, de azért nem garantálom, hogy 100%-ig pontos leszek...
A következő a helyzet: az FTP mehet aktív és passzív módban. Mindkét esetben a kommunikáció a 21-es porton indul, ahol leegyeztetik a kapcsolat paramétereit. Ezután aktív módban a kliens nyit egy portot (ahol neki jól esik), majd szól a szervernek hogy erre a portra kapcsolódjon rá (a 20-as portról), és itt fogják lefolytatni az adatforgalmat. Persze a kliens hálózati rétegben működő tűzfala erről nem tud, úgyhogy a bejövő kapcsolatot eldobja (megtehetné, hogy a 20-as portról bárkit beenged, de ez egy kissé lukas lenne...). A passzív eset már egy fokkal jobb, ott már van esély a kapcsolatra. Ilyenkor ugyanis a szerver nyit egy új portot és közli ezt a klienssel, aki oda rákapcsolódik és már mehet is az adatkapcsolat. A dolog akkor lesz igazán szép, amikor mindkét fél NAT mögött csücsül - ugyanis a paraméteregyeztetés során nem csak a port megy át, hanem a kliens/szerver IP címe is. Tehát vagy a kliens szól a szervernek, hogy "kapcsolódj a 192.168.x.y:zzzzz-re" amitől az néz egy nagyot, vagy a szerver mondja azt a kliensnek, hogy "csatlakozz a 192.168.x.y:zzzzz-re", amitől meg a kliens borul be.
Szerencsére van megoldás, csak egy kicsit feljebb kell mászni a protokoll stacken: a tűzfalba be kell építeni egy modult, ami képes FTP protokollelemezést végezni, és így a NATtal együttműködve megkerülni ezt a problémát. (Ez persze kernel modul...) A modul neve ha jól emlékszem ip_conntrack_ftp.

Remélem segítettem valamit...

Babszem.

( freebush | 2006. 06. 27., k – 19:05 )

szerintem az új csomagokat is engedélyezni kellene az 1024-nél magasabb portokon kifelé és a forward láncon is. Nem tud új kapcsolatot létesíteni, hiába van engedélyezve a már felépített kapcsolat, nincs ami "átmenjen" rajta.

( o_O v | 2006. 06. 27., k – 19:24 )

1024:65535 < ez nagyon nagy hiba igy biztos nem fog menni foleg , hogy az aktiv ftp mas portszamon megy.Regne hasznaltam Linuxot Openbsd erre az ftp-proxy a megoldas.

Köszönet az eddigi hozzászólásokért, így már sokkal tisztább a kép.
A http forgalomhoz squid proxy-t használok. Ez tud ftp proxyként működni? Ha igen hogyan? Nálam transzparens módban megy, tehát egyszerűen átirányítom a 80-as portra irányuló csomagokat a squid portjára. FTP-nél is gondolom hasonlóan kell eljárni. Ha így nem megvalósítható akkor tudtok ajánlani valami jó ftp-proxy-t? (lehetőleg ami képes a squid http-hez hasonó transzparens módban működni, hogy ne kelljen a gépeket matatni)