Aktivni vs. pasivni FTP

10.3.2009 18:52 | Přečteno: 13458× | Rady | poslední úprava: 10.3.2009 21:33

Zdravim vsechny citatele, rad bych slysel vas nazor na nasledujici problem. Jiste vsichni znate rozdil, vyhody a nevyhody aktivního a pasivního rezimu FTP.

Mejme nasledujici situaci:
Aktivni rezim:

Pasivni rezim:

Moji otazkou je: "Proc i v pasivnim rezimu neni navazovano spojeni na port 20 ale na "nahodny" neprivilegovany port (v tomto pripade 2024)?"
Muze mit souvislost s:

• Zbaveni se prav roota po startu ftp daemona?
• Rozlisitelnosti klientu podle socketu?
• Nejakym zvlastnim implemetacnim detail, ktery mi unika?

Jsem si zcela jisty, ze jen stale neco prehlizim nebo si dostatecne neuvedomuji. Zatim ale nemuzu prijit na pro me prijatelne vysvetleni. Dekuji vsem za reakce.

       

Komentáře

[|🇵🇸]

Použil jsi tag BREAK? Otravuje to přes půl výpisu blogů.

[pele]

Sorry, opraveno.

[Messa]

V pasivním režimu datové spojení navazuje klient. Ten spojení z portu 20 nenastaví už jen proto, že klient obvykle není root

Navíc, proč by sakra někdo měl nastavovat pro nějaké spojení odchozí port? Dělá to snad ještě nějaký jiný protokol než archaické FTP?

[Luk]

archaické FTP

Mimochodem, ďábelská kombinace je FTPS (FTP over SSL, resp. FTP + TLS) s NATem u klienta a firewallem na serveru. Connection tracking (verze pro FTP) samozřejmě nebude fungovat, takže kdo by to chtěl používat (namísto čistší náhrady protokolem SFTP), může zažít docela zábavné chvilky.

[Shadow]

Mohu potvrdit, konfiguroval jsem. Jestli si dobře vzpomínám, eftýpku jsem vyhradil skupinu vyšších portů, kterou jsem pak na firewallu otevřel. No, bohužel jsem při tom tenkrát zaměnil u iptables parametr -d za -s (když ony ty dvě klávesy jsou tak blízko u sebe...), takže jsem nějakou dobu ještě zjišťoval, proč se FTP klient za NATem někdy připojí a někdy ne.

[pele]

V pasivním režimu datové spojení navazuje klient. Ten spojení z portu 20 nenastaví už jen proto, že klient obvykle není root

Zde sem udelal chybu, melo tam byt: "Proc i v pasivnim rezimu neni navazovano spojeni na port 20 ale na "nahodny" neprivilegovany port (v tomto pripade 2024)?"

Navíc, proč by sakra někdo měl nastavovat pro nějaké spojení odchozí port? Dělá to snad ještě nějaký jiný protokol než archaické FTP?

Ja zil v domeni ze odchozi port se musi nastavit vzdy, ze je to vyzadovana polozka hlavicky protokolu.

[trekker.dk]

Zde sem udelal chybu, melo tam byt: "Proc i v pasivnim rezimu neni navazovano spojeni na port 20 ale na "nahodny" neprivilegovany port (v tomto pripade 2024)?"

Důvod může být v podstatě stejný - aby server nemusel běžet jako root, tak začne naslouchat na portu 21 a pak se zbaví svých práv. Tím pádem když chce někomu poskytnout data pasivně, nemůže už použít privilegovaný port.

Ja zil v domeni ze odchozi port se musi nastavit vzdy, ze je to vyzadovana polozka hlavicky protokolu.

Nemusí, když ho nenastavíš, OS si nějaký vybere sám.

[Messa]

V pasivním režimu datové spojení navazuje klient. Ten spojení z portu 20 nenastaví už jen proto, že klient obvykle není root

Zde sem udelal chybu, melo tam byt: "Proc i v pasivnim rezimu neni navazovano spojeni na port 20 ale na "nahodny" neprivilegovany port (v tomto pripade 2024)?"

Jak odpověděl níže mich, aby šlo rozeznat od sebe různá datová spojení. To už by asi bylo fakt trapný, aby klient musel po kontrolním spojení říci, ze kterého svého portu se připojil, aby to datové mohl FTP server dohledat.

Navíc, proč by sakra někdo měl nastavovat pro nějaké spojení odchozí port? Dělá to snad ještě nějaký jiný protokol než archaické FTP?

Ja zil v domeni ze odchozi port se musi nastavit vzdy, ze je to vyzadovana polozka hlavicky protokolu.

Povinná hlavička protokolu TCP to je, nicméně obvykle se o to postará operační systém (přidělí náhodný volný), programátor se o to vůbec nemusí zajímat. Co je důležité je nastavit především cílový port.

Mimochodem, pár FTP serverů jsem zkusil, na port 20 kašlaly. Asi to je jen featura pro lepší firewallování serverů...

FTP je dnes dobré akorát tak pro PHP webhostingy a jejich PHP klienty, kteří si neumí nastavit SCP nebo SFTP.

[trekker.dk]

Navíc, proč by sakra někdo měl nastavovat pro nějaké spojení odchozí port?

V aktivním režimu by se to mohlo hodit jako omezující pravidlo do firewallu...

[Michal Kubeček]

Navíc, proč by sakra někdo měl nastavovat pro nějaké spojení odchozí port? Dělá to snad ještě nějaký jiný protokol než archaické FTP?

Třeba IKE. Smysl to má ale jen tehdy, když se jedná o proces, který z principu poběží jen v jedné instanci a nepotřebuje navazovat víc "spojení" na stejný cíl.

[default]

Jiste vsischni znate rozrdil, vyhody a nevyhody aktivního a pasivního rezimu FTP.

Jediná výhoda, která mě napadá, je, že musím při použití FTP klienta ještě lozit do nastavení, abych řešil přesně tenhle aktivní a pasivní mód.

[alblaho]

FTP je jeden z nejdebilnějších běžně používaných protokolů. Nevím co fetovali, když rfc 959 psali. Pasivním a aktivním režimem to začíná, pokračuje nedefinovaným listingem adresářů, potom tu máme několi potrhlých formátů souborů, nápad konvertovat CRLF (pak si dělejte checksum, že). Určitě jsem ještě na nějakou idiotskou vlastnost zapomněl.

Doufám že umře, patří do propadliště dějin. Máme HTTP, WebDav, sftp.

[Martin Mareš]

Nedefinovaný formát listingu je opravdu nešťastný, ale zrovna aktivní mód u FTP je moc pěkný nápad. Můžete pomocí něj například zkopírovat soubor mezi dvěma FTP servery, aniž přitom teče přes váš počítač. To HTTP ani sftp neumí. Textový mód a všelijaké konverze byly v době dinosauřích počítačů docela potřebné, dnes už stejně každý FTP provozuje v binárním módu, takže nepřekáží.

(O WebDavu raději mlčím, sic bych působil jako hulvát a škarohlíd.)

[slush]

> O WebDavu raději mlčím

Proc? Pokud mate nejake postrehy, me by to urcite zajimalo...

[Luk]

Já mám postřehy ohledně WebDAVu takové, že například kombinace Thunderbird (resp. Lightning) + Apache 2.2 někdy blbne. Konkrétně jde o to, že z nějakého neznámého důvodu selže zápis (vrátí kód 500) a výsledkem je, že se data ztratí (protože to Lightning nijak nedá najevo - prostě při příštím spuštění je kalendář úplně prázdný). Stává se to velmi zřídka (řekněme jednou za několik měsíců), ale je to dost nepříjemné.

[Martin Mareš]

WebDav je takový kočkopes, který se snaží být napůl filesystem a napůl revision control system, pořádně žel nedělá ani jedno...

[alblaho]

Zkopírovat soubor mezi dvěma ftp servery je možné a je to i docela chytré.

Ale už jsi to někdy použil? Já za 12 let internetu ještě ne. Asi to nejde naklikat žádným normálním klientem, řekl bych, že to vyžaduje poctivou práci v konzoli.

[Martin Mareš]

Občas to opravdu používám, ale z používání klikacích klientů mne skutečně podezírat nemůžete

[Ladicek]

Já to nepoužil nikdy, skoro ani nevím, že to jde, zato jsem podobnou věc párkrát dělal netcatem

[Dušan Hokův]

Rika se tomu FXP.

[Grunt]

Můžete pomocí něj například zkopírovat soubor mezi dvěma FTP servery, aniž přitom teče přes váš počítač.

Heh. A zkoušeli jste už někdo překopírovat pár větších souborů mezi dvěma FTP servery v nějakých velkých housingových centrech?

[Grunt]

LOL. Asi se už fakt něco začíná dít.

[Milan Jurik]

Nic nefetovali, definovali nenarocny protokol pro dobu, kdy ho definovali. Krome toho by me zajimalo, proc bych mel uzivat naprosto zbytecne narocne protokoly jako sftp ci webdav na tak jednoduchou vec jako stazeni souboru. Pindy o checksumech jsou jen pindami, nic vam nebrani uplne vse stahovat v binarnim modu. Mozna by to chtelo se zamyslet nad pouzitym slovnikem...

[Semo]

sftp je narocny iba sifrovanim. Existuje nieco podobne, co vsetko tlaci/taha jedinym spojenim a pritom to nesifruje? Pokial clovek funguje cez SSH tuneloch cez NTLM proxy a este niekolko medziproxy, tak je zbytocne to sifrovat este raz. FTP je ale kvoli divoko otvaranym spojeniam nepouzitelne.

[Ondrej 'SanTiago' Zajicek]

> pokračuje nedefinovaným listingem adresářů, potom tu máme několi potrhlých formátů souborů, nápad konvertovat CRLF

...

> Doufám že umře, patří do propadliště dějin. Máme HTTP

Ackoliv s vyhradama proti FTP vicemene souhlasim, tak nechapu preferovani HTTP - HTTP nema vubec zadny definovany listing adresaru (FTP aspon definuje moznost vylistovat ciste jmena souboru) a ruzne konverze (napr. kodovani) jsou u HTTP serveru take mnohem rozsirenejsi a obtizneji vypnutelne (ze strany klienta). SFTP je velice pekny protokol, nicmene pro verejnou distribuci souboru me stale prijde FTP jako nejvhodnejsi z bezne rozsirenych sitovych protokolu.

[Luk]

Pro veřejnou distribuci souborů mi přijde nejvhodnější HTTP, protože typický případ použití je takový, že uživatel klikne na odkaz na webu a stahuje. HTTP odešle jeden požadavek a už tečou data (přičemž příliš nezáleží na tom, jak je udělané připojení, jestli je tam NAT apod.), kdežto u FTP je potřebných kroků více a jsou tam různá úskalí.

[rADOn]

…uživatel klikne na odkaz na webu a stahuje…

Na které planetě ? Tady na zeměkouli je to tak, že klikne co chce stáhnout, pak odklikne potvrzení licenčních podmínek, pak klikne na výběr místa odkud se stahuje, pak klikne na přeskočení reklamy, pak klikne na "nefunguje to" odkaz protože nechce čumět dalších deset sekund na další reklamu, pak musí odklikat všechny popupy,které v průběhu procesu vznikly. A to jen když má štestí a nenachází se na místě s povinnou registrací pro zasílání vyžádaného obchodního lančmítu, pak je kliků daleko víc.

[Luk]

Na které planetě ? Tady na zeměkouli je to tak, že klikne co chce stáhnout, pak odklikne potvrzení licenčních podmínek, pak klikne na výběr místa odkud se stahuje, pak klikne na přeskočení reklamy, pak klikne na "nefunguje to" odkaz protože nechce čumět dalších deset sekund na další reklamu, pak musí odklikat všechny popupy,které v průběhu procesu vznikly.

Ano, takhle to chodí na webech firem typu Adobe, a také na hrůzách typu SourceForge (ano, SF je hrůza - pokud mám možnost stahovat odjinud, rád tak činím, se SF jsou jen problémy). Při stahování z webu tvůrce obvykle stačí kliknout na odkaz. Jdu příkladem (např. tady nebo tady)

[default]

I na SF to jde zjednodušit. Tedy aspoň o tu zbytečnou stránku těch podělanejch mirrorů. Stačí cílový soubor otevřít do nového tabu (funguje v Safari a snad i ve Firefoxu), počkat na download okýnko a zavřít prázdný tab.

[Luk]

Problém je, že často některý mirror nejde, takže člověk musí vybrat jiný. Kde jsou ty časy (cca 2002), kdy byl jeden mirror i u CESNETu a byl velmi spolehlivý...

[Jendа]

<reklama>IGNUM SF mirror připravuje (už dlouho ). Zeptám se jejich člověka a dám vědět, jak to vypadá.

PS: už mají Debian a Ubuntu - ucho.ignum.cz</reklama>

[default]

No, já abych řekl pravdu, tak SF rád nemám. Nejen kvůli reklamám, ale hlavně je strašně pomalý a nepřehledný. Když hledám nějakou knihovnu, jedno z pravidel výběru je, že nejlépe kdekoli jen né na SF.

[Ondrej 'SanTiago' Zajicek]

U FTP je tech pozadavku sice vice, ale vzhledem k poctu paketu na preneseni celeho souboru je to obvykle prakticky jedno. Navic jsem mel na mysli spis cely  FTP archiv, kde je tech souboru vic (treba ftp.kernel.org) - napriklad adresar s ruznyma verzema souboru. Tam HTTP neumoznuje napriklad strojove parsovatelne prochazeni adresaru.

 > kdežto u FTP je potřebných kroků více a jsou tam různá úskalí.

No u HTTP je tech uskali mnohem vic - server to muze posilat se spatnym MIME typem a klient se pak bude chovat divne, server se muze usmyslet ze se jedna o textovy soubor a je treba ho prelozit z ISO-8859-2 na CP1250 :–), ci ze k tomu bude posilat divnou informaci o platnosti pro cache. Samozrejme, pokud je clovek adminem toho HTTP serveru, tak si to ohlida aby to bylo v poradku, ale pokud ne, tak s tim muze byt problem.

Za asi jedinou podstatnou vyhodu (pro ucely verejne distribuce souboru) HTTP proti FTP povazuji podporu pro virtualni domeny.

[Grunt]

Spíš je třeba brát ohled na dobu kdy vznikal(fňuk). Tehdy se o takovém Internetu jako je dnes nikomu ani nezdálo(a o takovém NATovém bazmeku jako je dnes se asi ani nikomu zdát nechtělo). Je docela zázrak, že přežil až do dnešních dob. Znám už jen jeden a ještě starší protokol, kterému se povedlo něco podobného. Docela zajímavé, že ani ne za měsíc bude mít první RFCéčko čtyřicáté výročí a Telnet to čeká jen o pár měsíců později.(A furt tu s námi je)

[Käyttäjä 11133]

Telnet to čeká jen o pár měsíců později.(A furt tu s námi je)

I někde jinde, než v embeded zařízeních?

[Grunt]

Co myslíš, že leze přes kanál Connection protocolu poté co je zabezpečeno spojení Binary Transport Protocolem, Key Exchange Protocolem a popř. Authentication Protocolem u SSH? A ani tak nejde o samotný telnet tak jak ho známe v dnešní době, ale o jeho podmnožinu NVT.(Samotná norma také nepopisuje telnet, ale takové jakési čudo) K tomu si dovolím citaci:

Právě protokol NVT je použit v omezené míře pro prezentaci dat v mnoha dalších protokolech jako jsou FTP, POP3, SMTP, NNTP i HTTP apod. MIME v podstatě je rozšířením této filosofie.

Bůh ví ve všem čem je to ještě dneska zadrátováno.

[Käyttäjä 11133]

Já měl na mysli samozřejmě samotný telnet protokol. Bez rozšíření.

[Grunt]

Já měl zase na mysli přesně to na co jsem odkázal. Projel jsem si RFCčka před RFC15 a po TCP/IP ani vidu ani slechu. To musely být nádherné doby. Jinak rozšířením toho NVT vznikne právě telnet jako ho známe dneska.

[tomk]

Myslim si, ze i zbaveni se roota ma smysl, ale b) je IMHO ten hlavni duvod. Jak jinak by server s jistotou vedel, jaka data ma do daneho socketu posilat? Tomas

[mich]

Kdybyste si na portu 21 "domluvil" 3 přenosy souborů a na jeden stejný (třeba 20) port by vám přišli 3 spojení, jak byste věděl komu máte co poslat (případně kde očekávat jaká data)?

[trekker.dk]

jak byste věděl komu máte co poslat (případně kde očekávat jaká data)?

Ideálně podle IP adresy.

[mich]

Není možné, aby data posílal někdo jiný, než ten kdo navazoval spojení? Třeba při přenosu mezi dvěmi servery, který řídí klient? Tím by se to rozlišení podle ip dost zkomplikovalo.

[Grunt]

Co to? Není náhodou jednoznačné spojení dáno zdrojovou adresou, zdrojovým portem, cílovou adresou, cílovým portem a protokolem?

[mich]

Jak se to týka toho, co jsem napsal já?
Funguje to následovně:
1) Server čeká na portu (defaultně 21) na klienty.
2) Pro každého klienta se vytvoří nový socket, přes který se serverem komunikuje.
3) Pokud má dojít k přenosu dat, vytvoří se nové spojení (stávající se používá pouze pro komunikaci).
V pasivním režimu:
4) Klient pošle serveru "PASV\r\n" (bez argumentů), server vybere náhodně port a odešle jej (spolu se svou ip adresou) klientovi jako odpověď.
5) Klient se připojí na ip a port, přenos dat proběhne.
Já jsem psal, že kdyby se nevolil náhodný port, ale byl by stejný pro všechny spojení, vypadal by bod 5 následovně:
5) Server čeká na portu (třeba těch 20) a snaží se k němu připojit několik (třeba taky 20 ) klientů. Všechny spojení akceptuje, nicméně neví kam má co poslat (kde očekávat data), protože komunikace se děje na portu 21 (chudák, teď je mi ho líto). Mohlo by se to řešit třeba tak, že spolu s výzvou PASV by klient odesílal i ip a port toho, kdo bude se serverem komunikovat, což ale není tak jednoduché.

[Grunt]

Mohlo by se to řešit třeba tak, že spolu s výzvou PASV by klient odesílal i ip a port toho, kdo bude se serverem komunikovat, což ale není tak jednoduché.

A přesně o tomto jsem mluvil. Bohužel jsem si až teď uvědomil, že přes kaskádu NATů by to asi opravdu nebylo tak jednoduché a v podstatě by to byl aktivní mód naopak, takže žádné řešení.

[Grunt]

Proč se nezeptat přímo u zdroje?:

Reuse of the Data Connection: When using the stream mode of data transfer the end of the file must be indicated by closing the connection. This causes a problem if multiple files are to be transfered in the session, due to need for TCP to hold the connection record for a time out period to guarantee the reliable communication. Thus the connection can not be reopened at once.

There are two solutions to this problem. The first is to negotiate a non-default port. The second is to use another transfer mode.

A comment on transfer modes. The stream transfer mode is inherently unreliable, since one can not determine if the connection closed prematurely or not. The other transfer modes (Block, Compressed) do not close the connection to indicate the end of file. They have enough FTP encoding that the data connection can be parsed to determine the end of the file. Thus using these modes one can leave the data connection open for multiple file transfers.

[mich]

Řekl bych, že tenhle odstavec se týká nečeho úplně jiného.

[Grunt]

Je to možné, ale jiné vysvětlení týkající se portů jsem nenašel.