proftpd +mysql +passive mode

Linux-haladó

Sziasztok

egy proftp problémában szeretném a Ti segítségeteket kérni.
Van egy mysql alapú azonosítással működő proftpd, mellyel valóban be lehet lépni a szerverre, de az ls parancs a "227 entering passive mode..." sorral leáll és nincs tovább.
A dolog érdekessége, hogy ha login után kiadom pl. az mkdir parancsot, azt habozás nélkül végrehajtja.
A szerver úgy van beállítva, hogy automatikusan létrehozza a bejelentkezett felhasználó home könyvtárát és ezt a proftpd user/group tulajdonába teszi.
Vajon mivel tudnám rávenni a proftpd -t arra, hogy listázzon? Merre lehet a gond?
Köszönöm a válaszokat,
András

  • 4931 megtekintés

( csonti | 2006. 11. 13., h – 20:43 )

van valakinek valamilyen ötlete? Akár egy rossz ötlet is jöhet :)

Javaslom a tcpdump aktív használatát.
Mégvalami:
Voltak hasonló gondjaim, a részletekre már nem emlékszem, de ez a sor a konfigban megoldotta:

DelayEngine Off

Igaz, nálam csak időnként akadt fel a szeme, nem pedig állandóan. (Ha esetleg ráfutsz erre a hibára is, akkor még hasznos lehet.)

Nézelődtem és létrehoztam pl. a 20000-20100 passzív portokat:
iptables -A INPUT -p tcp -m multiport --destination-ports 20000:20100 -j ACCEPT
beírtam a proftpd.conf -ba a passiveports direktívát, proftpd restart, de az eredmény ugyanaz: entering passive mode .. és semmi.
Eléggé meg vagyok lőve. :(

Nem sokra mégy ezzel, mert elég nagy port-tartományból választ véletlenül.
tcpdump-al tudsz halgatózni, hogy milyen csomagok közlekednem a szerver és kliens között.
Átmenetileg engedélyezz mindent a szerver és kliens között, és úgy teszteld le.

A tcpdump egész jó ötlet volt, kiküldtem egy textfájlba, míg ftpéztem és tényleg elképesztő nagy tartományban nyitogat(na) portokat. (30000-64000). Azt még nem próbáltam, hogy kikpacsolom a szerver tűzfalat, de ma este majd veszek egy nagy levegőt :)
Egyébként ha proftpd-nek megmondom a konfigban, hogy mely tartományban használjon passzív portokat és mindent beállítok ehhez, akkor miért nem jó?
Lehet, hogy mégis másol van a hiba. a tcpdump.txt -ben fura volt pl. hogy a szerverem nevét úgy írta, hogy
domainem.hu.ftp...
Nem vagyok egy ftp guru, az biztos..

domain.hu.ftp = domain.tld.port az /etc/services alapjan feloldja a port szamat, hogy valami olvashatobb formaban talalhassa neked.

Egyebkent, ha konfigban megadtad, hogy milyen tartomanyban nyisson portot, akkor ott kell neki.

# 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 49000 50000

Az igy megadott tartomanyt nyisd meg tuzfalban is.

Szerk.:
"proftpd.conf -ba a passiveports direktívát..."
Ugye definialtal tol-ig port tartomanyt is?

igen második próbálkozásra is difiniáltam egy nagyon széles tartományt (azt hiszem 20000 - 640000 -ig), majd engedélyeztem tűzfalban az említett iptables szabállyal. Proftpd restart és ugyanaz.
Más ftp szerverekre be tudok lépni a kliens oldalról, azaz az otthoni gépemről.
Nem vagyok iptables szakértő (finoman szólva) az említett iptables szabályt jól írtam?

Az iptables szabaly alapvetoen jo. A 'multiport'-nak sok keresnivaloja nincs ugyan benne, mivel anelkul is megadhatsz port tartomanyt (arra port, illetve port tartomany felsorolas eseten lenne szukseg: 22, 23:25, 21), de ez mar csak formasag.

Ki tudnad tenni valahova az iptables szkriptedet, vagy az 'iptables -n -L' kimenetet + proftpd konfodat?

( eax | 2006. 11. 14., k – 01:29 )

Ha iptables baja van, akkor egy, a -j DROP-ok eleg tett -j LOG-gal viszonylag egyszeru kideriteni, hogy pontosan mit kellene ki/be engedni.
Ha mindent ACCEPT-olsz, akkor mukodik?

( mess | 2006. 11. 14., k – 20:30 )

szerk: előző hozzászólás törölve; így
jár az, aki nem olvassa végig az althreadeket :) : amit
javasoltam, már kipróbáltad.

New:

Nem lehet, hogy valami már figyel (netstat) azonkon a portokon,
ahová a proftpd szeretne passzívot nyitni?
Proftpd restart megvolt, miután beállítottad a "PassivePorts"-ot
a configban? (Ne érts félre; nem nézlek hülyének, de nekem
volt már ilyen. :) )

proftpd restart, előtte tűzfalnyitás, konfig megvolt, mégis ez van.
A neten található doksik ill. a "linux bevetés közben" c. mű alapján próbáltam beállítani a cuccot, de a doksik többsége nem (a könyv se) említett tűzfal-mágiát.
Ha a kliens oldalon ftp -ben kapcsolódás előtt kiadom a passive off parancsot, utána a kapcsolódást elutasítja "no route to host" hibaüzenettel.
Más szolgáltatás nem figyel azokon a "magas" portokon. A proftpd gond nélkül elindul a szerveren, de a hibakereső tesztparancs IPV6 hiányára panaszkodik.

Köszi az eddigi tanácsokat is!

( nlaszlo | 2006. 11. 14., k – 22:06 )

Nekem it teljesen ugyanez volt a hibajelenség mikor megpróbáltam beüzemelni a proftpd-t, a DLink routerem mögül. Megnyitottam a 21-es portot, aztán egy másik adag portot a passziv kapcsolódáshoz és mégse ment. Ugyanott akadt el ahol neked. Utána gugliztam még egy adagot és ott olvastam, hogy mikor összebeszélnek (a szerver és a kliens), akkor a szerver által küldött PASSV mezőben a belső IP-t küldi ki, a kliens meg ehhez próbál kapcsolódni, ami természetesen az ő oldaláról nem elérhető. (Ez szép mondat lett... remélem érthető :-))

Végülis a /etc/proftpd/proftpd.conf-ba kellett beszúrni egy sort: 


MasqueradeAddress ftp.cimed.hu

A cím helyére mehet IP-is, a lényeg hogy ne a belső legyen :-)
gFTP-vel próbáltam ki, hogy tényleg ez volt-e a baj. A menüben FTP->Options->FTP_fül->Ignore PASSW Address bepilál. Ha így megy, akkor neked is ez a hiba.

Remélem segítettem valamit...

--
Nagy László
Ubuntu Linux 6.10 "Edgy Eft" on laptop 2.6.17-10-686

Hello,

kipróbáltam ezt is. Gondosan elvégeztem minden teendőt a tűzfal körül és újraindítottam a proftpd-t. Ellenőriztem, hogy tényleg az általam megadott ip tartományt használja. De sajnos semmi. Valahol másutt lehet a hiba.
LEhet, hogy holnap a confokat is kiteregetem valahova, csak most már gyufaszálakkal tartom fenn a szemhélyaimat. :)

A szerver es kliens halozatarol tudnal mondani nehany szot? Nem emlitetted explicit, igy csak feltetelezem, hogy a szerver publikus IP-vel log a neten.

"227 entering passive mode..." utan nalam gFTP-ben ott figyel zarojelben az IP, valamint 2 szam, ami a port tartomanyt hivatott definialni (nem ugyanazok a szamok lesznek ott, amiket a konfigban megadtal, de ez ne zavarjon).

Ezek nalad mik?

A készülődő szerverem valóban publikus IP címen figyel, ami a 217.113.61.137.
A gftp-ben majd délután megnézem pontosan mi az a két szám az IP mögött, viszont úgy emlékszem, hogy ezek max. 3 jegyű számok voltak annak dacára is, amikor megadtam az ötjegyű IP tartományt a proftpd.conf -ban.

Megáll az eszem, de amikor a gftp -vel próbálok kapcsolódni, nem az én IP címemet írja ki az "entering passive mode..." -nál Most már tényleg orvost hívok..

Íme:
217.113.61.137 kikeresése
Próba: 217.113.61.137:21
Kapcsolódva: 217.113.61.137:21
220 FTP Server ready.
USER walaki

331 Password required for walaki.
PASS xxxx
230 User walaki logged in.
SYST

215 UNIX Type: L8
TYPE I

200 Type set to I
CWD /

250 CWD command successful
/ könyvtárlista betöltése a kiszolgálóról (LC_TIME=hu_HU.UTF-8)
PASV

227 Entering Passive Mode (195,70,36,180,192,20).
Adatkapcsolat létrehozása sikertelen: A csatlakozás megtagadva
Lekapcsolódás a(z) 217.113.61.137 helyről

Ilyen jelenseg akkor all fent, ha a kliens es a szerver kozott valahol cimforditas tortenik. A kliens csatlakozik a .137-re, ami az ftp portra erkezo csomagokban kicsereli a celallomas cimet .180-ra, majd tovabbitja. A .180 mivel nem tudja, hogy volt egy DNAT, a kliens PASV parancsara a sajat cimet kuldi vissza + a portokat. Ezt a viselkedest a PassivePorts es MasqueradeAddress konfig file direktivakkal valtoztathatod.

A esetedben valoszinuleg a MasqueradeAddress opcio megoldja a problemat, de valaszt nem ad a kerdesedre: honnan jon a .180? Elerheto mar a proFTPd konfigod valahol?

PS: a PASV parancsra a1,a2,a3,a4,p1,p2 formaban jon a valasz, ahogy irtad.

IP: a1.a2.a3.a4
PORT: p1*256 + p2

Sziasztok,

megadom magam, :) a proftpd konfig:

proftpd konfig
iptables:

iptables

minden ugyanúgy, csak most már annyi a különbség, hogy ls -re connection refused -et kapok bejelentkezés után.

ui: most a masquerade address-t átítam fpt.dhost.hu-ra és most már a gftp a következőt írja:
227 Entering Passive Mode (217,113,61,137,192,21).

Előrelépés! :)

Sorry, csak most volt idom atnezni.

A helyzet a kovetkezo:

RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 49152:65534

Elobb rakod a csomagokat a RH-Firewall-1-INPUT lancba, mint ahogy az ACCEPT sorral elfogadnad azokat. Mivel a RH-Firewall-1-INPUT lanc szabalyai nem teszik lehetove, hogy azok a csomagok, amik nem felelnek meg egyik ott definialt feltetelnek sem, kiessenek a lancbol a vegen - ezzel visszakerulve az INPUT lancba ujra - hanem az utolso alapertelmezett szabaly ervenyesul, igy ennek megfeleloen eldobod oket:

REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Megoldasi javaslat: A RH-Firewall-1 lancban az utolso szabaly ele helyezd el a passziv port tartomanyra vonatkozo szabalyodat.

Köszönöm, így már működik!!!
Betöltöttem az ftp conntrack modult és miután végrehajottam az általad írt módosítást, szépen be tudok csekkolni passzív módban (aktív módban nem, de nem is nyitottam meg a 20-as portot), minden úgy működik, ahogy kell.

Még egyszer köszönöm a rengeteg segítséget, amit nyújtottatok nekem:
András

Hasznald egeszseggel. Csak mellesleg jegyzem meg, hogy a port tartomany megnyitasa, es az ftp conntrack modul egyuttes hasznalata felesleges. Vagy az egyik, vagy a masik megteszi. Szemelyes velemenyem szerint az utobbi elegansabb, de az eredmeny mindket esetben ugyanaz.

A kliens alkalmazasok szempontjabol "az eredmeny mindket esetben ugyanaz".

F: "...velemenyem szerint az utobbi [ftp conntrack] elegansabb"
B: "...nem kell értelmetlenül portokat kinyitni."

Azt hiszem egyrol beszelunk annyi kulonbseggel, hogy szerintem azert, mert valami elegansabb, meg nem teszi ertelmetlenne a masikat, ami ugyanarra a problemara nyujt megoldast.

( budacsik | 2006. 11. 16., cs – 13:45 )

Az aktív ftp miért nem jó neked? Azzal nincs ilyen gond.

( csonti | 2006. 11. 19., v – 17:38 )

még elegánsabb megoldás (nem kell modprobe, rc.local szkript editálás, hanem csak

/etc/sysconfig/iptables-config -ba a következő sort:

IPTABLES_MODULES="ip_conntrack_ftp"

majd iptables restart.

UI természetesen betű szerint ez Redhat/Fedora alatt értendő, de a logika mindenütt u. az.

A fenti kérdésre a válasz engem is érdekelne :)

Lenne mégegy kérdésem:

debian sarge -> etch upgrade után nem működik a proftpd mysql authentikációval, de anélkül jó. A csomag se volt hajlandó feltelepülni addig, amíg ki nem kommenteztem az összes SQL-es sort a proftpd-conf-ból. Találkoztatok már ezzel a problémával? Mi lehet rossz?

Petya

mivelhát az iptables állapotfüggő vagymi két dolog kell:

- tcp 21 forward accept meghát preroute ha csomagszűrős tűzfal mögött van az ftp szervered, ha a public ip-s gép a szerver akkor csak tcp 21 input accept kell (preroute: fixme, fejből írom)
- ip_conntrack_ftp (mert ez tulképp egy appproxy és ő foglalkozik a további portbiznyágolásokkal)

más lehetőség: tűzfal gépen tcp 21 nyit és valamiféle ftp proxy használata

és persze iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT is kell mert enélkül nem állapotfüggő szegényke....

ellenvélemény?

( errotan v | 2007. 04. 16., h – 23:13 )

Hello.

Úgylátom, hogy a géped címe 217.113.61.137 ,de passiváláskor :

227 Entering Passive Mode (195,70,36,180,192,20).

a 195.70.36.180 belső IP címre akar passiválni ami internetről nem elérhető,
gondolom router mögött van tehát be kell állítanod, hogy a netes IP címedre passiváljon,
nekem is volt ilyen bajom, csak én pure-ftpd -t használok nemtudom , hogy a proftpd-be,
hogy kell ezt átállítani, de ez lehet a hiba.

( PMC | 2008. 02. 26., k – 03:27 )

Kicsit régi ez a topic, de úgy látom nem sikerült teljesen megoldani a problémát és kezdőknek mindíg visszatérő probléma a tűzfal beállítása. Sok elb@szott tűzfalat látok, akár Solaris és/vagy Linux (iptables és ipfilter) platformon, ezért itt jegyzem le az utókornak:

A passive és active ftp alapvetően másként működik. Valahogy így:

Active FTP :
command line: client port>1024 ---> server port=21
data line : client port>1024 <--- server port=20

Passive FTP :
command line : client port>1024 ---> server port=21
data line : client port>1024 ---> server port>1024

Szerver oldalon meg kell nyitni 21-es portot az input láncon; a 20-as portot az output láncon, és az 1024-nél magasabb portokat az input láncon.

Kliens oldalon kvázi ki lehet silabizálni az inverz képletet. És az ICMP-kell is csak okosan...

A tűzfal specikifukus dolgokat keresd a googlen vagy a manban!

( piedone | 2008. 05. 11., v – 22:43 )

Hali!

Én is egy proftpd-s problémával küzdök. Méghozzá szeretném beállítani a passzív portokat. Van a proftpd-hez a PassivePorts nevű direktíva. Ugye ez után kell megadni a kezdő, és a végportot.

Eddig ez szép, és jó. De miért van az, hogy egyszerűen nem foglalkozik vele a protfpd? Állandóan 2000 és 6000 közötti portokat nyitogat automatikusan. Hiába állítok be neki bármit.

Ezen hogy lehet változtatni?

Köszi.
Üdv.

Ha biztos, hogy a jó konfigfile-t szerkeszted (a default: proftpd -V), akkor a következő kérdések merülnek fel.

Milyen disztribúció?
Milyen kernelverzió?
Milyen ProFTPD-verzió?
Standalone vagy inetd-ből fut?
Mi a /proc/sys/net/ipv4/ip_local_port_range tartalma?
A PassivePorts hová van írva? (<Global>, <VirtualHost> vagy server config)

Milyen disztribúció?

Debian Etch 4.0r2

Milyen kernelverzió?

2.6.18-fza-028stab051.1-686-bigmem

Milyen ProFTPD-verzió?

1.3.0

Standalone vagy inetd-ből fut?

standalone

Mi a /proc/sys/net/ipv4/ip_local_port_range tartalma?

32768 61000

A PassivePorts hová van írva? (, vagy server config)

Server config

Sajnos semmi változás... Egyébként a portot úgy figyelem, hogy az iptables-szel loggolom a forgalmat. Ott írja, hogy melyik porton próbál kommunikálni, és hova. De egyszerűen nem működik. Sehogy nem írja át a passzív portot a proftpd...

Na mindegy. Akkor marad úgy, ahogy van. Köszi.

Mielőtt írtam, kipróbáltam, nálam múködött a <Global>-ban, de a server configban nem. Itt a magyarázat:

ProFTPD-mini-HOWTO-Vhost.html:
"Anything inside of a <Global> section is applied to every server configuration in the file, to every <VirtualHost> as well as the default "server config" server.

Just like the <VirtualHost> context, any configuration directives inside the "server config" context do not apply outside of the context. Many administrators often assume that this is the case. It is not. This is what the <Global> context is for."

Illetve:
"server config
This means that the directive may be used in the server configuration file (e.g., proftpd.conf) outside of any other context (i.e. not inside a <VirtualHost> or <Global> context). This context defines a "main" or "default" server."