Tűzfal segítség kérés

Linux-haladó

Sziasztok!

Építő jellegű segítségeiteket, tanácsaitokat szeretném kérni.
Van egy pár domaint kiszolgáló web szerverem, melyet a lehető legjobban szeretnék IPTABLES tűzfalszabályokkal védeni.
A szerverben egy hálózati kártya van.
A HTTP, IMAP, POP3, SMTP, FTP és még egy-két TCP portot szeretnék engedélyezni, ezeket most nem sorolom végig, mert feleslegesen növelné a listát.
A DNS, NTP pedig UDP protokollon lenne engedélyezve hasonlóképpen, minden más UDP-t tiltani akarok.

Szeretném, ha a default policy minden irányba DROP lenne, azaz csak az jöhet-mehet, amit külön engedélyezek.

Emellett érdekelnének egyéb, általában IPTABLES-szel megoldandó védelmek, mint a ping-flood, syn-flood elleni védelmek, illetve ha még van egyéb javaslatotok, akkor szívesen venném.
Gondolom ennek is, akár egy bash szkriptnek, lehet több jó megoldása, nem igazán a tűzfallal fekvő-kelő ember vagyok, de szeretnék egy jó védelmet. Ezért gondoltam, hogy megkérdezem a HUP közösségét, ki mit ajánl, mit gondol.
Csináltam már valamit, ami javarészt működik, kivéve az FTP-t. Az nem megyen. ProFTPD fut a szerveren, annak a konfigurációs fájljában szerepel egy ilyen rész:

--------------------------------
# In some cases you have to specify passive ports range to by-pass
# firewall limitations. Ephemeral ports can be used for that, but
# feel free to use a more narrow range.
# PassivePorts 49152 65534
PassivePorts 49152 49162
--------------------------------

Ebből azt gondolnám (rosszul?), hogy ha itt megadok egy tartományt, akkor az FTP az adatcsatornákat ezen a portokon nyitogatja, nem össze-vissza, így ha ezen port tartományt a tűzfalon engedélyezem, akkor az FTP-nek mennie kellene.
De nem megy...

Hasonló "eredményeket" értem el különféle SYN-flood elleni védelemmel is, de ezt a végére hagynám, előbb menjen az FTP. Virtualbox-ban futtatott Debian-t tűzfalazok most próbaként, lehet, hogy amiatt nem akaródzik ez a SYN flood védelem működni?

És akkor egy bash szkript, ami a tűzfalat állítgatja be:
--------------------------------
#!/bin/bash

IPT=/sbin/iptables

$IPT -F
$IPT -X

#### Default policy: DROP ####
$IPT -P INPUT DROP
$IPT -P FORWARD DROP
$IPT -P OUTPUT DROP

#### Invalid allapotu csomagok eldobasa ####
$IPT -A INPUT -m state --state INVALID -j DROP

#### A beerkezo ping icmp csomagok limitalasa (pingflood ellen) ####
$IPT -A INPUT -p icmp -m limit --limit 1/s --limit-burst 1 -j ACCEPT
$IPT -A INPUT -p icmp -j DROP
$IPT -A OUTPUT -p icmp -j ACCEPT

################### Bejovo kapcsolatok ####################
$IPT -I INPUT -i lo -j ACCEPT

$IPT -A INPUT -p tcp -m multiport --dports 21,25,80,110,143 -m state --state NEW,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -p tcp -m multiport --sports 21,25,80,110,143 -m state --state ESTABLISHED -j ACCEPT

$IPT -A INPUT -p udp -m multiport --dports 53,123 -m state --state NEW,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -p udp -m multiport --sports 53,123 -m state --state ESTABLISHED -j ACCEPT

################## Kimeno kapcsolatok ######################
$IPT -I OUTPUT -o lo -j ACCEPT

$IPT -A OUTPUT -p tcp -m multiport --dports 21,25,80,110,143 -m state --state NEW,ESTABLISHED -j ACCEPT
$IPT -A INPUT -p tcp -m multiport --sports 21,25,80,110,143 -m state --state ESTABLISHED -j ACCEPT

######### FTP probalkozas ######
$IPT -A OUTPUT -p tcp --dport 49152:49162 -m state --state NEW,ESTABLISHED -j ACCEPT
$IPT -A INPUT -p tcp --sport 49152:49162 -m state --state ESTABLISHED -j ACCEPT
################################

$IPT -A OUTPUT -p udp -m multiport --dports 53,123 -m state --state NEW,ESTABLISHED -j ACCEPT
$IPT -A INPUT -p udp -m multiport --sports 53,123 -m state --state ESTABLISHED -j ACCEPT
--------------------------------

1) Tudnátok-e segíteni abban, hogyan tudnám az FTP-t is elérhetővé tenni?
2) Van-e esetleg javaslatotok, mit és hogyan lenne érdemes optimalizálni, átrendezni, hozzátenni ehhez a szabályrendszerhez? (IPV6-ot tiltottam, azzal most nem kívánok foglalkozni, ha esetleg felmerülne)

Előre is köszönök mindent!

  • 5248 megtekintés

( th v | 2013. 11. 27., sze – 21:49 )

Az FTPnek a 20,21-es portok kellenek, plusz a passzív porttartomány.

--
TH

( Semir | 2013. 11. 27., sze – 21:53 )

Szia!

1) Tudnátok-e segíteni abban, hogyan tudnám az FTP-t is elérhetővé tenni?

Vagy nyitod a passzív portokat, vagy van az ftp conntrack modul, ami megoldja dinamikusan. (http://www.cyberciti.biz/faq/iptables-passive-ftp-is-not-working/)

Berakénék egy accpetet a --state state RELATED,ESTABLISHED a helyedben.

Tipp: ha nincs közvetlen hozzáférésed a géphez, amíg csinálod, tedd cronba a tűzfal ürítését.

Még tipp: tegyél fel egy cfst pl, egész jól megoldja neked az egészet.

( secretx v | 2013. 11. 28., cs – 09:55 )

Én kettő dolgot tennék, amivel ki lehet pofon egyszerűen debuggolni:

-logolni a dropped csomagokat szépen megszűrve, ebből látszik mit dob el, innen könnyű rájönni mi nem kóser
-tcpdumpolni a forgalmat

Az első egyszerűbb és célravezetőbb szerintem most.

szerk: fentebb írtak egy működőnek tűnő megoldást, azt próbáld ki szerintem.
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( uid_7086 | 2013. 11. 27., sze – 21:55 )

Ha ennyire bizonytalan vagy benne, nem lenne jobb mondjuk felrakni egy ufw-t (tudom, van sok hasonló, én ezt tartom a legérthetőbbnek) és azzal beállítgatni amit engedélyezni akarsz?

Egyébként utolsó infóm szerint az ftp-nek csak a 21-es portot kell engedélyezni, meg valami "related" rémlik, de hogy azt pontosan hol is kell, arra már nem emlékszem (15+ éve nem használok ftp-t). Annyi a megkötés, hogy a kliensnek passzív módban kell működnie.

update: amint látom, mialatt gépeltem, páran megelőztek. :)

( kallaics | 2013. 11. 27., sze – 22:06 )

Szia,
Én annyival járulnék hozzá, szerkeszd más szempontból a file-t.

#!/bin/sh
IPT=/sbin/iptables

$IPT -F -t filter
$IPT -X -t filter
$IPT -Z -t filter

#### Default policy: ACCEPT, végén DROP ####
$IPT -P INPUT ACCEPT
$IPT -P FORWARD ACCEPT
$IPT -P OUTPUT ACCEPT

#### Invalid allapotu csomagok eldobasa ####
$IPT -A INPUT -m state --state INVALID -j DROP

# Mindent elfogad a aloopback interface-n
$IPT -I INPUT -i lo -j ACCEPT
$IPT -I OUTPUT -o lo -j ACCEPT

# Ping
$IPT -A INPUT -p icmp -m limit --limit 10/s --limit-burst 5 -j ACCEPT
$IPT -A OUTPUT -p icmp -j ACCEPT

# FTP hozzáférés
$IPT -A INPUT -p tcp -m multiport --dports 21,49152:49162 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -p tcp -m multiport --sports 21,49152:49162 -m state --state ESTABLISHED,RELATED -j ACCEPT

# Web hozzáférés
$IPT -A INPUT -p tcp -m multiport --dports 80,443 -m state --state NEW,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -p tcp -m multiport --sports 80,443 -m state --state ESTABLISHED -j ACCEPT
# Web hozzáférés, kifelé
$IPT -A INPUT -p tcp -m multiport --sports 80,443 -m state --state NEW,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -p tcp -m multiport --dports 80,443 -m state --state ESTABLISHED -j ACCEPT

# Levelezés sztem. csak biztonságos csatornákon
$IPT -A INPUT -p tcp -m multiport --dports 465,537,993,995 -m state --state NEW,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -p tcp -m multiport --sports 465,587,993,995 -m state --state ESTABLISHED -j ACCEPT
# Levelezés kifelé
$IPT -A INPUT -p tcp -m multiport --sports 25,465,587 -m state --state NEW,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -p tcp -m multiport --dports 25,465,587 -m state --state ESTABLISHED -j ACCEPT

# DNS engedélyezés, bejövő lekérdezések
$IPT -A INPUT -p udp -m multiport --dports 53 -m state --state NEW,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -p udp -m multiport --sports 53 -m state --state ESTABLISHED -j ACCEPT
# DNS engedélyezés, kimenő lekérdezések
$IPT -A INPUT -p udp -m multiport --sports 53 -m state --state NEW,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -p udp -m multiport --dports 53 -m state --state ESTABLISHED -j ACCEPT

# NTP szerver
$IPT -A INPUT -p udp -m multiport --dports 123 -m state --state NEW,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -p udp -m multiport --sports 123 -m state --state ESTABLISHED -j ACCEPT
# NTP kliens
$IPT -A INPUT -p udp -m multiport --sports 123 -m state --state NEW,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -p udp -m multiport --dports 123 -m state --state ESTABLISHED -j ACCEPT

# Minden mást naplózni
$IPT -A INPUT -j LOG --log-prefix "INPUT-DROP: "
$IPT -A OUTPUT -j LOG --log-prefix "OUTPUT-DROP: "
$IPT -A FORWARD -j LOG --log-prefix "FORWARD-DROP: "

# Minden mást eldobni
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP

logger -t FIREWALL "Firewall script end"

( KeeF | 2013. 11. 28., cs – 00:46 )

amiert nem mukodik: a forward chain-en el fogja dobni kb. az osszes csomagot ami befele (vagy kifele) menne. (default policy drop)
az 53,123 azert mukodik, mert nem kerul a forward chainre, es igy nem dobja el.
talan tudod, de azert leirom: egy csomag csak egy chain-en kerulhet szuresre filter table eseten. (doksi: http://www.netfilter.org/documentation/HOWTO/hu/netfilter-hacking-HOWTO…) a forward-ra kerulnek azok a csomagok amik _nem_ az fw-szerveren keletkeznek es _nem_ az fw-szerver a celjuk, pl. az ftp-szervernek szolo csomagok.

A lokálisan futó ftp szerverhez hogy jön a forward chain?
Nem dobja el a forward chain a lokális ftp-re jövő illetve onnan kimenő packetet, mivel az csak input és output chainekbe kerül.
Ha natolva lenne egy másik címre a csomag, akkor kellene a forward szabály is.

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( Mono v | 2013. 11. 28., cs – 19:56 )

Nagyon szépen köszönöm mindenkinek a segítséget!
Azt valóban elfelejtettem írni, hogy a conntrack, illetve ftp_conntrack modul be volt/van töltve.
A 20-as port engedélyezése (az eredeti felállásban) sajnos nem hozott változást.
Gondolkodtam azon én is, hogy valami grafikus tűzfalprogit felteszek és azzal kattintgatok, ez lett volna a "B" terv. De arra gondoltam, hogy talán ez nem annyira bonyolult dolog, hogy emiatt ilyesmihez nyúljak.

Lényegében kallaics gyakorlatilag komplett megoldása tökéletesen működik, nagyon úgy tűnik, hogy pont azt csinálja, amit eredendően szerettem volna, sőt! Hatalmas gratula és köszönet érte!
Mit gondoltok, van-e sebességbeli különbség az általa felvázolt, nagyon jól átlátható szabályrendszerek felsorolása és a kezdő hozzászólásomban is látható, "soroljuk fel a világot is egy sorba" típusú megoldás között? Nyilván nem lesz annyira átlátható, viszont ha egy ilyen multiportos sor feldolgozása egy lépés, míg az áttekinthetőbb megoldás több lépést jelent a feldolgozásban, akkor gondolom ez erőforrást is jobban igényel. Mit gondoltok/tudtok erről?

Miben jobb, vagy másabb az, ha a default policy drop, vagy ha az accept és a szabályrendszerek felsorolása után minden mást drop-ra teszek?

Bocs a sok kérdésért, de szerintem ezek olyan kérdések, melyek egy később erre látogatóban is felmerülnének.

És akkor még egy dolog: a SYN flood elleni védelem. Próbálkoztam, megannyi szabályt találtam erről a neten, sokat meg is próbáltam, de az eredmény annyira nem győzött meg. A védeni kívánt gépem egy Virtualbox-ban futó Debian Squeeze. A host gép pedig, melyről támadni próbáltam egy Linux Mint.
A parancs ez volt (az IP cím a támadott gépé természetesen):

hping3 -S --faster -p 80 192.168.1.11

A támadott gépen egy sosem látott jelenséget figyeltem meg: egyik processz sem terhelt semmit, de az egyik processzor magot teljesen kihajtotta, eközben alig tudtam gépelni a támadott gép konzolján. Azt gondolom, hogy vagy hatástalan volt a SYN flood védelem, vagy valamiért Virtualboxban ez egy nem tesztelhető dolog.
Van esetleg erről tapasztalatok, infótok, bevált szabályotok? Most, hogy tudom, mennyire egyszerűen be lehet tenni a kaput egy szervernek egy ilyen flood-dal, szeretném kivédeni.
Ilyesmiket próbáltam:

iptables -A INPUT -p tcp -m state --state NEW -m recent --update --seconds 60 --hitcount 20 -j DROP

iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 20 --connlimit-mask 24 -j REJECT --reject-with tcp-reset

De sajna mindegyik a fent leírt eredményt hozta.

A nálam tapasztalt SYN flood sosem okozott CPU terhelést. Csak a beállított max. kapcsolatot próbálta elérni. Ugyan nem sikerült ez, de azért bekerült egy szabály iptablesbe.

Ez:
iptables -I INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT

Ahogy néztem ez bevált (itt találtam huppon)

--
openSUSE 12.2 x86_64

Köszi a gyors választ, ezt láttam és próbáltam én is, sajnos nem volt hatással a nagy proci terhelésre. Lehet, hogy ehhez egy külön fizikai gépre lesz szükségem akkor... köszönöm még egyszer!

Szerk1:
kipróbáltam egy fizikai géppel is, de sajna nincs változás. Ennek is az egyik magját 100%-ba kihúzza, 1,1 körülire felmegy a load és a kworker/0:0 nevű processz olyan 18...20% között mocorog a támadás alatt.
Csak ezt az egy sort írtam bele a támadott gépbe, semmi egyéb IPTABLES dolog nem volt benne:

iptables -I INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT

A próba kedvéért kiürítettem az összes szabályt, de a jelenség nem változott meg. Fura...

Minden ötletet szívesen vennék! :)

Szerk2:
Érdekes, hogy ezt használva olyan 45-65% között mozog "csak" a procimag terhelése, egészen jól lehet közben a terminálba is gépelni:

iptables -N syn_flood
iptables -A INPUT -p tcp --syn -j syn_flood
iptables -A syn_flood -m limit --limit 1/s --limit-burst 3 -j RETURN
iptables -A syn_flood -j DROP

Forrás: http://www.cyberciti.biz/tips/howto-limit-linux-syn-attacks.html
Mit csinál ez másként és hogyan tudnék még finomítani rajta, hogy ne húzza meg a proci egy szálát még ennyire se?

Szerk3:
Feltettem egy képernyőképet a htop-ról. Az "egy soros" szabály ezt generálja, ha hagyom futni, akkor 1-2 perc után már olyan 1,1 körüli a load.

http://kepfeltoltes.hu/view/131128/synflood_www.kepfeltoltes.hu_.png

üresen nem tudom mitcsinál, nekem van egy -j drop az egész végén (azért is -I és nem -A, mert ezt csak később illeszti a script bele, és így felkerül legelső szabálynak)

netstat szerint az egyidejű SYN_RECV-k száma 1, egyébként sok. ebből következtettem ki, hogy működik. De egyébként, attól a bejövő csomagok még jönnek, tehát a gépnek foglalkoznia kell velük.

A második példád amúgy ugyanazt a hatást váltja ki, mint az enyém. csak ott külön van.

--
openSUSE 12.2 x86_64

>>A második példád amúgy ugyanazt a hatást váltja ki, mint az enyém. csak ott külön van.

Ez attól is függ, hogy hol van a szabályod a láncban.

Ha a végén van mindkettő, akkor feleslegesen megy végig a SYN az egész láncon, esetleg még (valószínűleg) acceptelődik és hatástalannak látszik a szabály.

Ha az elején van, akkor az egy soros megoldás acceptel egyet, a többit meg átengedi a többi szabálynak.

A limiteket mindig accept, a maradékot drop megoldásban kell betenni. (+ esetleg egy log.)

@Mono:
esetleg nézd meg az ipsetet, azzal listára tudod tenni a limiten fennakadtakat és a lista alapján már a lánc tetején droppolni minden forgalmat a támadótól.

Szia!

Mondjuk nem ez az alap téma, de nem vagyok benne biztos, hogy érted-e tényleg?
A Te szabályod a lánc tetején elfogad dest porttól függetlenül 3 (+ burst, de azt nem állítottál) SYN-t, majd a negyediket (és az aztán következőket egészen a másodperc végéig) ráküldi a többi szabályodra, ahol a következőknek megfelelően vagy elfogadásra kerül, vagy eljut a láncod aljáig, ahol droppolódik.
Tehát: ha a beérkező synflood olyan portot érint, amire van később -j ACCEPT szabályod, akkor az acceptelődni fog és nem droppolódni, mint az kívánotos lenne. De ehhez még a limit eléréséig teljesen szűrés nélkül beengedsz 3 csomagot.

Szevusz Mono!

Én a lent linkelt ábrát szeretem nézni, mert itt látszik, hogy mit jár meg a csomag, mire az általad leírt alap esetben az INPUT FILTER táblába került szűrés elvégzi a dolgát.

http://upload.wikimedia.org/wikipedia/commons/8/8f/Diagrama_linux_netfi…

Ez az oka a magas CPU loadnak, ezért előfordul hogy a mangle táblát használják input filter megvalósításra.
Kadlecsik Józsi itt beszélt róla, érdemesnek tartom végignézni:

http://videotorium.hu/hu/recordings/details/611,Linux_NetFilter_iptable….

Üdv, vf

( Mono v | 2013. 11. 29., p – 09:05 )

A SYN flood védelemre még visszatérek, ha a teszt környezetem mellé keveredek. Addig is volt még két kérdésem, amire nagyon várnám a véleményeiteket:

1) Van-e sebességbeli/terhelésbeli különbség a portonkénti szabályok egymás alatti felsorolása, illetve egy multiportos szabály használata között?
Hogyan kerül feldolgozásra tulajdonképpen ilyenkor a dolog? A multiportos "megfogalmazás" csak nekünk, humán embereknek ad könnyebséget, vagy a kernelnek is (a sorok számát tekintve)?

2) Miben jobb, vagy másabb az, ha a default policy drop, vagy ha az accept és a szabályrendszerek felsorolása után minden mást drop-ra teszek?

( Mono v | 2013. 11. 29., p – 20:47 )

Sajna megint elakadtam :(

Kallaics szkriptjét betöltve sajnos más, külső FTP szerverhez nem tudok kapcsolódni.
Ahhoz, hogy kívülről mást engedjek a saját FTP-hez kapcsolódni, meg kellett adnom, mely passzív portokat használhatja az FTP kiszolgálóm, illetve ezeket be is kellett állítani a tűzfalban. Emiatt totál tanácstalan vagyok, hogyan tudnék kifelé más FTP-hez kapcsolódni.

Van valami ötletetek? Már csak ez hiányzik, hogy jó legyen.

Azon a szerveren, melyet védeni szeretnék, több web oldal kap helyet. PHP, ingyenes CMS rendszerek, stb. Ezen alkalmazásoknak kell tudniuk úgy külső FTP-hez kapcsolódniuk.
Nincs mód arra, hogy az FTP host, login és jelszó hármason kívül bármilyen egyéb paramétert megadhassunk.

Ha az FTP modul alatt az ip_conntrack_ftp-re gondolsz, akkor ezt is, illetve a sima ip_conntrack modult a szkript indulásakor betöltetem:
# lsmod | grep conn

nf_conntrack_ftp 5521 0
nf_conntrack_ipv4 9833 19
nf_defrag_ipv4 1139 1 nf_conntrack_ipv4
nf_conntrack 46391 3 nf_conntrack_ftp,nf_conntrack_ipv4,xt_state

Kallaics szkriptjéből az FTP-t illető két sor ez:
$IPT -A INPUT -p tcp -m multiport --dports 21,49152:49162 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -p tcp -m multiport --sports 21,49152:49162 -m state --state ESTABLISHED,RELATED -j ACCEPT

A 49152-19162 tartomány a védendő szerver FTP szerverének port tartománya, így kintről befelé szépen megy az FTP.
Bentrl tetszőleges külső FTP-hez azonban nem sikerül csatlakozni, a logban ez a három sor szerepel, ha Midnight Commanderből szeretnék külső FTP-re csatlakozni usernév@szerver-t beírva (jelsző bekérő ablakot sem dobja fel):

Nov 30 10:01:27 debian-test kernel: [ 4101.917788] OUTPUT-DROP: IN= OUT=eth0 SRC=192.168.26.11 DST=80.xx.xx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=26813 DF PROTO=TCP SPT=39898 DPT=21 WINDOW=5840 RES=0x00 SYN URGP=0
Nov 30 10:01:30 debian-test kernel: [ 4104.916139] OUTPUT-DROP: IN= OUT=eth0 SRC=192.168.26.11 DST=80.xx.xx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=26814 DF PROTO=TCP SPT=39898 DPT=21 WINDOW=5840 RES=0x00 SYN URGP=0
Nov 30 10:01:36 debian-test kernel: [ 4110.917124] OUTPUT-DROP: IN= OUT=eth0 SRC=192.168.26.11 DST=80.xx.xx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=26815 DF PROTO=TCP SPT=39898 DPT=21 WINDOW=5840 RES=0x00 SYN URGP=0

A 192.168.26.11 az a gép, melyen a tűzfalat futtatom, illetve róla próbálok meg kijutni.
Mit ajánlotok?

$IPT -A OUTPUT -p tcp -m multiport --sports 21,49152:49162 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Pont a NEW kapcsolatokat hagyod ki. Nem véletlenül javasolták, hogy a related és established csomagokat már az elején fogadd el, akkor nem lenne ilyen könnyű kihagyni a new-t.

Kicsit fentebb már pike.killer is ezt javasolta, természetesen kipróbáltam és mint írtam is, sajnos nem megy.
Ezt kapom a logba:
Nov 30 19:43:17 debian-test kernel: [39012.545293] OUTPUT-DROP: IN= OUT=eth0 SRC=192.168.26.11 DST=80.xx.xx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=27576 DF PROTO=TCP SPT=39966 DPT=21 WINDOW=5840 RES=0x00 SYN URGP=0
Nov 30 19:43:20 debian-test kernel: [39015.544136] OUTPUT-DROP: IN= OUT=eth0 SRC=192.168.26.11 DST=80.xx.xx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=27577 DF PROTO=TCP SPT=39966 DPT=21 WINDOW=5840 RES=0x00 SYN URGP=0
Nov 30 19:43:26 debian-test kernel: [39021.544142] OUTPUT-DROP: IN= OUT=eth0 SRC=192.168.26.11 DST=80.xx.xx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=27578 DF PROTO=TCP SPT=39966 DPT=21 WINDOW=5840 RES=0x00 SYN URGP=0

Ilyen most a két FTP sorom:
$IPT -A INPUT -p tcp -m multiport --dports 21,49152:49162 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -p tcp -m multiport --sports 21,49152:49162 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Próbaként betettem még mindkét sorba a 20-as portot is, de nem változott a helyzet :(

( Mono v | 2013. 11. 30., szo – 20:08 )

Picit javult a helyzet e négy sor alkalmazásával:

$IPT -A INPUT -p tcp -m multiport --dports 20,21,49152:49162 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -p tcp -m multiport --sports 20,21,49152:49162 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

$IPT -A INPUT -p tcp -m multiport --sports 20,21,49152:49162 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -p tcp -m multiport --dports 20,21,49152:49162 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Így már nem csak "vár" a kifelé irányuló FTP csatlakozás a Midnight Commanderben, hanem a login@szerver után azonnal bekéri a jelszót, de utána megint csak a "várakozás", majd timeout.

Logokban most ez látszik:

Nov 30 20:00:30 debian-test kernel: [40045.717681] OUTPUT-DROP: IN= OUT=eth0 SRC=192.168.26.11 DST=80.xx.xx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=20257 DF PROTO=TCP SPT=33373 DPT=34627 WINDOW=5840 RES=0x00 SYN URGP=0
Nov 30 20:00:33 debian-test kernel: [40048.716183] OUTPUT-DROP: IN= OUT=eth0 SRC=192.168.26.11 DST=80.xx.xx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=20258 DF PROTO=TCP SPT=33373 DPT=34627 WINDOW=5840 RES=0x00 SYN URGP=0
Nov 30 20:00:39 debian-test kernel: [40054.716169] OUTPUT-DROP: IN= OUT=eth0 SRC=192.168.26.11 DST=80.xx.xx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=20259 DF PROTO=TCP SPT=33373 DPT=34627 WINDOW=5840 RES=0x00 SYN URGP=0

Conntrack_ftp modul természetesen továbbra is be van töltve. Van még tippetek?

( Mono v | 2013. 11. 30., szo – 20:40 )

Találtam egy megoldást a neten, ami alapján szerintem megcsináltam a dolgot. Működni működik, mindkét irányba megy rendesen az FTP.

$IPT -A INPUT -p tcp --sport 1024:65535 --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -p tcp --sport 21 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT

$IPT -A INPUT -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT

$IPT -A OUTPUT -p tcp --sport 20 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -p tcp --sport 1024:65535 --dport 20 -m state --state ESTABLISHED -j ACCEPT

###

$IPT -A OUTPUT -p tcp --sport 1024:65535 --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
$IPT -A INPUT -p tcp --sport 21 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT

$IPT -A OUTPUT -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A INPUT -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT

$IPT -A INPUT -p tcp --sport 20 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPT -A OUTPUT -p tcp --sport 1024:65535 --dport 20 -m state --state ESTABLISHED -j ACCEPT

Véleményeznétek? Láttok benne valami problémát, szerintetek esetleg lehetne valahogy optimalizálni, vagy így jó, ahogy van?

Szia Mono!

Amit Semir írt 27-én azzal mi a probléma? :)
Sztem. sokkal egyszerűbb, mint ez a sok szabály. Sztem. cseréld ki arra, mit ott írnak. Ne felejtsd el a modult engedélyezni majd.

Ez volt a link, amit betett a hozzászólásába:
http://www.cyberciti.biz/faq/iptables-passive-ftp-is-not-working/

Szia!

Az eredendő gondom az volt azzal, hogy akárhogy variáltam is, külső FTP-hez nem tudtam csatlakozni. Kicsit bogarászva még a neten, találtam azt, amit most ide betettem. Eredendően ez is hat sor, azért kétszer annyi, mert a kifelé irányuló FTP tűzfalazás is szerepel a "###" sor alatt.