Názory k článku Jak nahradit FTP pomocí SFTP a zamknout uživatele

„FTP je snad posledním „starým“ protokolem, který k přenosu dat ani přihlašovacích informací nepoužívá šifrování.“

A co SMTP a POP?

A explicitne FTP vie AUTH TLS.

Dobre, doted jsem pouzival FTP pro jeho jednoduchost – na WIN. Pouzival sem Gild. Cim to tedy mam nahradit ? Muzete mi poradit ? NA FTP serverech se mi libilo jednoduche nastaveni. Za rady budu vdecny.

Omluvam se za chybu a nepresnost… uz je na mne pozde. Pouzivam Guild.. a mam na mysli svuj server.

„FTP hnané skrze SSH tunel. Opět stejný protokol SSH, který je ale přenášen přes SSH tunel“

s/protokol SSH/protokol FTP/
?

http://developer.berlios.de/projects/sftp4tc/

Tento plugin nefunguje spravne, par let uz se nevyvyji, a s poslednima verzema openssh, prave v situaci, kdy je uzivatel zamcen v chrootu ma problem. Spravny plugin je tenhle, primo od tvurce TC: http://www.ghisler.ch/wiki/index.php/Secure_FTP_plugin, Download: http://www.ghisler.ch/board/viewtopic.php?t=19994

Nerekl bych ze se nevyvyji, posledni verze je z listopadu 2009…

Zcela určitě se navyvyji, neboť takové slovo ani neexistuje!

Administrátoři rozhodně nemají obavy z toho, že by se jim po systému potulovali uživatelé a nahlíželi, kam nemají (snad jen administrátoři-studenti).

Důvodem rozšířenosti FTP je:
1. že je to řešení dostatečné pro publikování dat a v řadě případů dostatečné i pro upload.
2. špatná dostupnost klientů jiných protokolů pro uživatele.
3. nastavení firewallů příp. proxy často nepočítá s jinými protokoly

Autor navíc zcela opomněl problématiku ověřování pravosti účastníků přenosu, která je pro mnohé uživatele složitá a řada klientů ji ani neimplementuje resp. implementuje špatně. Bez tohoto ověřování je jakékoli bezpečnostní řešení řešením jen na půl cesty.

Situaci, kdy mi druhá strana není ani telefonicky schopena potvrdit pravost serveru a to ani u komerčních subjektů jako je Česká spořitelna nebo dokonce Global Payments Europe, které jsou zodpovědné u nás za většinu karetních transakcí přes internet (v podstatě ani nevěděli, co po nich chci), považuji za dost tristní. .

A ještě bych dodal:

4) Rychlost přenosu – šifrování přece jen poněkud snižuje dosažitelnou přenosovou rychlost, a pokud mám FTP server určený pouze pro upload velkých souboru na GBit LAN (který není přístupný zvnějšku), tak mi může vadit cca poloviční až třetinová dosažitelná rychlost SFTP.

ad 4) skutecne sftp/scp neni dost dobry na gigabitu, protoze puvodne slo o bezpecnost a ne o rychlost, ale da se to resit treba takto: http://www.psc.edu/networking/projects/hpn-ssh/

Ale to je velmi zajímavé. Před pár lety jsem si říkal, kdy v open-ssh konečně upraví chování bufferů, aby se přenos souborů tak nevlekl (SCP/SFTP u mě nepřekročil 2 mega, FTP sviští co linka dovolí). A ono asi nic, musíme použít patch od někoho jiného. A dokonce je tam i patch na dodatečný server logging! Hezká stránka, díky :-).

Prave, nejvetsi problem jsou uzivatele, co tak maximalne zvladnout si najit ftp server, pres ikonku „mista v siti“. O nejakem stahovani a instalaci sftp klienta nemuze byt rec. BTW, nevite nekdo o nejake programku pod win, co by takovymto (pro BFU jednoduchym zupsobem) umel zprostredkovat i to SFTP – namountovat ho jednoduce uzivateli jako slozku?

sshfs?

Rozumeju BFU mountovaniu a nie je „jednoduche mountovanie“ nahodou oxymoron?

Ad 1 a ad 2: WebDAV over HTTPS umí to samé a je vestavěný i ve Windows. Protože WebDAV používá HTTPS, tak je už velmi dobře implementované i ověřování serveru pomocí HTTPS certifikátů. Jenže správně nastavit WebDAV není moc jednoduché a většina adminů spíše upřednostní svoji lenost před bezpečím uživatelských dat

Ad 3: zrovna FTP je jeden z nejhorších protokolů pro nastavoení firewallu, právě proto, že používá dva porty a navíc umí pasivní a aktivní mód, takže firewall musí zkoumat všechny FTP pakety na příkaz PORT, což je výkonově docela náročné a znemožňuje použití FTPS (v případě, že firewall je dedikovaný, což by z bezpečnostních důvodů měl být). SSH a WebDAV over HTTPS je oproti tomu pohádka

WebDAV ma ale podla mojich skusenosti problem s priamim otvorenim suboru. Windows dava hlasku o tom, ze sa nepodaril oneskoreni zapis.. Toto mnoho uzivatelov zmatie a pre mna je velkou nevyhodou WebDAVu..

WebDAV s ničím problém nemá, je to velmi dobře definovaný a standartizova­ný protokol. Problém má Micro$hit, který záměrně svoji podporu WebDAV-u przní (je to vidět mj. na tom, jak vždy WebDAV funguje nějak teprve od SP2-SP3, nová verze widlí je zmršená. Na netu se dá najít kopie mailu, který rozesílal velký DeBill někdy kolem roku 2000, ve kterým nařizuje programátorům M$, že musí WebDAV zprznit, protože je to nebezpečný protokol pro M$ :-(. Ten mail nějak unikl z onoho antimonopolního řízení proti M$ v USA před pár lety…).

To je problém implementace ve Windows a ve srovnání s implementací FTP je na tom WebDAV daleko lépe

Ano FTP neni bezpecne, prihlasovaci udaje i cely prenos nejsou sifrovane. Ale koho z uzivatelu to zajima? Proti spatne ulozenym FTP heslum v Total Commanderu vas ani SFTP nezachrani. Oproti tomu je pocet zneuziti skutecne odchycenych hesel marginalni.

Nešlo o žádné „špatné uložení hesel“, problém by byl i v případě existence „master password“. Problém je v tom, že uživatel měl v systému někoho cizího. Trojan by si v pohodě odchytil i to master password.

Nikoliv. FTP se používá proto, že ho umí nativně MS Windows. Můžu vám poslat:
\\mujserver\adresar
http://nekde.neco.com/aaa
ftp://nekde.jinde.com/aaa

Cokoliv z toho je klikatelný odkaz. Prostě kliknete a jste tam. Možná bude chtít username a heslo, ale o to si řekne.

Jakmile začne SFTP, SCP nebo něco jiného být stejně „nativně klikatelné“, bude to použitelné. Do té doby (s nutností něco instalovat) je to neschůdné. Pokud potřebuji zprovoznit adresář, kam má přístup 150 lidí z naší firmy, 80 lidí od zákazníka a dalších 190 lidí od různých dodavatelů, pak v případě FTP vím, že to bude fungovat. Požadavek na větší zabezpečení obvykle nevede na SFTP/SCP, ale vede k HTTPS a PHP/Java/Ruby atd. Posílat zákazníkovi ultimátum, ať na počítače uživatelů instaluje SW třetí strany… no, zkusit to můžete :-)

Nevím jaký je stav dnes, ale když jsem cca před rokem sftp „pro uživatele“ používal, tak jsem narazil jednak na problém logování a jednak nastavení práv. Zatímco normální FTP servery mají docela propracovaný systém, aby se transakce logovaly, a aby uživatelé nemohli libovolně měnit práva nahraných souborů, tak řešení pro SFTP v tomto ohledu vyžadovalo aplikaci nějakého (neoficiálního) patche a pak ještě večer nad kódem ve stylu „proč to sakra nefunguje“.

Kdo si neumí zabezpečit ftp, tak není dobrý admin. Na citlivá data přes internet použiji třeba scp; ale to nic nemění na tom, že nahrazovat šifrovaným přenosem anonymní ftp je pitomost. Pro velké objemy dat na rychlých sítích je veškeré šifrování přenosu neakceptovatelné zpomalení a pruda. Rozumný člověk volí vždy takový nástroj, který je pro danou akci nejvhodnější.

a niekto tu hovoril on anon ftp? imho predmetom clanku bol hlavne prenos suborov na hostingy, tj user/pwd a nie anonymous..

predmetom clanku nebol „hlavne prenos suborov na hostingy.“

Dalsi duvod, proc se porad pouziva klasicke FTP pripadne FTPS je jednotna sprava uctu. Vetsina hostingu ma nejakou sql databazi klientu, kde ma klient centralni login a heslo. Pro nej si saha extranet, ftp, posta. Jde nejak rict SSH, aby se neoveroval vuci /etc/passwd ale vuci SQL databazi nebo LDAPu?

Všechny dnešní distribuce používají PAM a PAM se umí ověřovat vůči prakticky čemukoliv včetně MySQL a PostgreSQL databází, Kerberos, RADIUS, LDAP, HTTP, POP3, IMAP, SMTP, SMB/CIFS, přítomnosti Bluetooth nebo USB zařízení, čtečce otisků prstů, PCKS#11, MuscleCard a OpenPGP/GnuPGP kartám nebo klidně FTP nebo jinému SSH serveru a dokonce umožňuje mít pro každou službu jinou metodu autentifikace, jiné heslo nebo jiný domovský adresář nebo metody autentifikace skriptovat

Co se stane kdyz nekdo v sftp session napise:
!/bin/bash

Pokud byl /bin viditelny tak se spusti bash, pokud byl chrootovany, tak stale muzu udelat

put /bin/bash
put make-me-the-root
chmod 755 bash
!./bash
$ chmod 755 make-me-the-root
$ make-me-the-root
# gotyou!

Doufam ze se da ! nejak vypnout.

Jeste nejak nerozumim te poznamce s /etc. Muze mi nekdo vysvetlit jak ziskam roota tim ze budu moct vytvorit /etc ?

Přes vykřičník se dostanete na lokální shell u sebe na klientovi, ne na straně serveru, ne?

Jo uz mi to taky doslo. Asi jsem mel nejaky `zkrat' v mysleni.

Jenom porad nevim proc vadi dat nekomu moznost vytvorit /etc. I kdyby nekdo vytvoril /etc/passwd s rootem bez hesla, tak jelikoz nemuze spustit su, tak je mu to nanic. Predpokladam teda ze kdyby se pak pokusil o ssh root@machine tak ze se pouzije globalni /etc/passwd a taky ho to nepusti.

Takze me nenapada jak by se to dalo zneuzit.

a kdyz si vytvorim root privilegia pro stavajiciho usera?

… a se odhlasim a prihlasim?

Stejně se použije globální /etc/passwd (nebo cokoliv jiného nastaveného v globálním PAM), takže to nic nezmění

Celý tenhle postup je sice hezký a jednoduchý má však drobnou vadu – při takto vytvořeném spojení nebude fungovat scp. Jen sftp!

„Tento problém se dříve řešil pomocí prostředí chroot, do kterého byl uživatel uzavřen. Problém ale je, že tento postup vyžaduje kopírování systémových souborů do domovského adresáře, udržování verzí knihoven, ruční konfiguraci a má další nevýhody.“

Riesenie:

1) # aptitude install vsftpd alebo # pkg_add -r vsftpd
2) v vsftpd.conf zmenit chroot_local_u­ser=NO na chroot_local_u­ser=YES
2.1) pre freebsd este # echo ‚vsftpd_enable=„Y­ES“‘ >> /etc/rc.conf
3) spustit vsftpd

SSH/SFTP pouzivam casto a paci sa mi, ze SFTP je nastavene out of box. Data transfer funguje aj cez firewall bez FTP proxy (pokial mate otvorenu 22ku).
Autorov argument mi ale pripada samoucelny. Viem, ze v pripade FreeBSD so standardnym ftpd je potrebne robit nieco ako autor popisuje a argument plati. No aj tam ma clovek moznost nainstalovat alternativny FTP server a vyhnut sa celej procedure.

Ak niekto poskytuje FTP pristup pre vela uzivatelov, urcite spusta ftp server v jail-e alebo nejakom sandboxe.

„ruční konfiguraci“

je mozne nazvat aj zmenu v sshd_conf, preto nechapem, ktory konkretny krok ma autor na mysli.

Ospravedlnujem sa. Z povodnej struktury mi to nebolo jasne.

Preco uz potom rovno nepouzit FTP server s podporou FTPS, ktory je primarne urceny na poskytovanie suborov a neni nutne v nom obmedzovat shell pristup atd.?

Ak by ste napr. chceli povolit shell pre dalsiu skupinu uzivatelov pripajajucich sa na ssh server, aj tak by im bolo treba kopirovat userland.

Není mi jasné, který systém je podle autora více uživatelský, zda některý z víceuživatelských či některý z jednouživatel­ských systémů… :-D

Chtel jsem na tuto chybku upozornit, ale nenapadlo me nic takto vtipneho. :-)

Muze mi to prosim nekdo vysvetlit? Prijde mi to jako uplna blbost.

Taky mě to při čtení praštilo. Autorizace se přece provádí ještě před chroot… ?

Tiež si myslím že to je nezmysel, /etc by sa dal zneužiť len ak je z chroot prostredia prístup na nejakú setuid binárku, čo by znamenalo že admin je blbec :)

tiez mi to pripada nezmyselne
skoda ze sa autor clanku nevyjadril ako to myslel
mohol by sa

rssh umoznuje priamo chrootovat userov. OK, az po autentifikacii, kedze ma kazdy vlastny chroot, ale bez toho by to asi neslo.

shell v /etc/passwd

/usr/bin/rssh

v rssh.conf

user = "rudy:011:00001­:/usr/local/my chroot

Nedavno jsem toto resil a nasel jsem i dalsi shelly k tomuto urcene:
http://sourceforge.net/projects/lshell/
http://mysecureshell.sourceforge.net/

Prvni dovoli i interaktivni prihlaseni, kdy muzu vyjmenovat povolene prikazy a znaky. Vse je logovano, muzu nastavit pocet provineni (treba pokus o opusteni chroot adresare) a po dosazeni tohoto poctu je uzivatel automaticky odhlasen.
Lze ho pomerne snadno chrootnout, home adresar nemusi vlastnit root, jen pridam uzivatele do systemu a do konfiguraku jeden radek pro jeho domovsky adresar

Vůbec se mi nelíbí, že SCP/SFTP pouští uživatele na nějaký shell. Výhod FTP je v možnosti virtuálních účtů a virtuálních adresářů.

Pustit lidi do shellu a pak řešit, jak to omezit aby se nedostali dál je po vzoru „admin blbec“. Mnohem lepší je vystavit internetu server, který umí jen to co má umět a nic víc.

Svět potřebuje přenosový protokol. ale SFTP to fakt nebude.

+1

Zdielam identicky nazor.Degradovat SSH na quasi FTP mi pripada trochu divne. Preco rovno nepouzit software urceny primarne na prenos suborov a netrapit sa s chrootom?

SSH už dávno není jenom shell (dokonce ani nemusí spouštět shell, aby fungovalo např. jako VPNka), je to šifrovaný multiplex (tunel) a pomocí toho lze realizovat nejrůznější úkoly. Včetně SFTP, které je pro přenos souborů v současném nebezpečném internetovém světě daleko lépe vymyšlené než velice důvěřivé FTP.

Kdyz provedete chroot do /sftp, tak by prece uzivatel nemel mit home dir /sftp/uzivatel, ale jen /uzivatel (http://www.debian-administration.org/articles/590)? To ale pak muze kolidovat s FTP (ktere uzivatele stejne vyzaduji) a ktere potrebuje v home dir realnou cestu, tj. /sftp/uzivatel. Dal by me zajimalo, proc je nutne, aby mel adresar vlstnika a skupinu root, kdyz FTP toto nevyzaduje a chroot do domovskeho adresare provadi take?

FTP nedělá chroot, ale „překládá“ zadané adresáře na adresáře na serveru. Adresář, do kterého se chrootuje, může vlastnit kdokoliv, pokud vím, tak SSH to nijak neomezuje.

Kolize lze vyřešit tak, že se do /sftp vytvoří symlink „sftp“ ukazující na „.“. Nebo přes PAM lze pro SFTP a FTP nastavit rozdílné domovské adresáře.

Umi uz WinSCP cestinu? Dik

Tu snad umel od zacatku, kdyz je to SW puvodem z Ceska, ne? Dokonce i jeho stranka na winscp.sf.net je cesky.

http://winscp.net/eng/docs/lang:cs

Nevim, ale asi se neptal na pocesteni programu. V nazvu prenasenych souboru neumel, ale ted se zda, ze to alespon pro UTF-8 umi.

kecy v kleci

FTP-TLS/SSL je samozrejme krajsie a vykonnejsie riesenie, ale ma problem so striktnymi firewallmi a NAT-om, dokonca v pripade ze obe strany su za NAT-om, tak to nechodi vobec.
RFC 4217 sice popisuje sposob ako sa s tym vyrovnat – CCC FTP command (Clear Command Channel), ale za prve to musi byt specialne povolene na strane serveru a za druhe tu musi podporovat tiez klient, navyse to moze vies k bezpecnostnym problemom.

Takze z mojho pohladu este si musime pockat na skoro idealny, bezpecny a vykonny protokol na efektivny prenos dat.

Omlouvám se jestli to už padlo.
Nemá být nastaveno 755 místo 700 ??

jj , minimalne 750

Nepadlo. Taky si myslím, že by tam mělo být 755, ale jsem zelenáč, takže nevím. Mohl by to tu nějaký zkušený SFTPak potvrdit. Bez tohoto nastavení mi to nejede.

jj mas pravdu vzdyt je to krcmar co bys chtel:D

Super návod, škoda že výsledkem je:
Permission denied, please try again.