Belső hálózaton az általam üzemeltetett gépeken fájlmegosztásra ...

 ( Botond | 2016. november 1., kedd - 8:59 )
kizárólag Samba szervert használok
34% (85 szavazat)
többnyire Samba szervert használok, de ritkán NFS szervert is
13% (33 szavazat)
vegyesen használok Samba és NFS szervereket
23% (57 szavazat)
kizárólag NFS szervert használok
10% (25 szavazat)
egyéb egyszerű fájlmegosztásokat használok (pl. Ubuntu Shared Folders)
1% (2 szavazat)
egyéb fájl szervert használok, leírom a hozzászólásban
6% (14 szavazat)
csak az eredmény érdekel
14% (36 szavazat)
Összes szavazat: 252

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Céges fájlszerver: Open Enterprise Server (NCP)
Szerverek között: NFS
Ahol az a cél, hogy $RANDOM win/android/akármi kliens könnyen tudjon csatlakozni: a fentiek mellett(!) Samba.

Jelen pillanatban azon megy a küzdelem, hogy az NCP és a Samba egyrészt bazi lassú WAN kapcsolatok felett (sok az oda-vissza kommunikáció, ami magas latency felett hatványozottan szívás) másrészt, a roadwarrior júzerek macerásnak tartják a VPN csatlakozást (két kattintás, paszmek!) ezért mostanság azon agyalunk, hogy valami HTTPS fölötti okosságot (pl. DAV) is bevetünk.

Igen, csak ha roadwarrior, akkor a VPN rendszeres megszakadása gáz lehet, és ha nem tud visszacsatlakozni fél óráig, vagy csak 10 percig, akkor feltartja a munkában. HTTPS fölé egy selfhosted ownCloud tud segíteni, kliens (iPhone, Android, Windows, Linux, Mac) tud sync-elni szelektíven is, és weben keresztül is elérhető a tartalom. User bedobja egy mappába amit be akar, aztán felmegy amikor felmegy. S ha ezt rakod egy VPN-be, akkor már a megszakadás se annyira zavaró.

--
Where do you want to go today?
[nobody@salcay:~]$_

Az owncloud (nextcloud) dav kienst használ ami több ezer fáj esetében nagyon lassú, ezért én ott ahol aktív munka folyik, seafile-t használok, összemérhetetlenül gyorsabb.

foleg samba (vagy win srv), de van ahol owncloud van webdav-al.

sshfs

FTP. Azért érdemes tudni, hogy ez egy egyszerű otthoni hálózat, így a biztonság, jogosultságok, stb. nemigen szempont.

egyszerű otthoni hálózat, így a biztonság, jogosultságok, stb. nemigen szempont

Pedig.

--
L

A jogosultság azért nem szempont, mivel gyakorlatilag csak a torrent-letöltéseket osztjuk meg. A letöltéseket az RPI-n (szerveren) futó transmission intézi. Másik gépről a torrent-könyvtárhoz csak RO hozzáférés van, törölni, átnevezni a transmission webes felületével törlünk, nevezünk át (illetve "összetettebb" fájlműveletekhez SSH-val lépünk be).
Biztonság: kívülről nem érhető el, csak a 192.168.2.* IP-című gépekről.

Elég 1db remote code execution a gépen, ahonnan feltöltöd a torrent fájlt, és az FTP jelszó megfújható, a belső hálózatos gépedről ennek ismeretében a torrent fájl megszerezhető, amiben benne van a tracking ID, amivel a te nevedben lehet torrentezni, és mellesleg kivághatnak érte a torrent oldalról. Nem nagy kockázat, csak na... ennyi erővel mást is meg lehetne fújni.

--
Where do you want to go today?
[nobody@salcay:~]$_

Anonymus ftp van (nincs jelszó) :)

Kicsit "komolyabban": nem vagyok egyáltalán biztonsági szakértő, de az általad vázolt történet NFS-nél, Samba-nál, SSHFS-nél nem történhet meg?

Másrészt akkor kicsit bővebben, hogy oldottam meg a "rendszert": a normál gépen megkeressük a letöltendő torrentet. A torrent-fájlt letöltjük, ami a ~/downloads (vagy ilyesmi) könyvtárba kerül. Az RPI percenként megnézi a normál gépek /home/megadott_userek/downloads könyvtárait, és onnan a torrent fájlt áthelyezi (rsync+ssh segítségével) a transmission automatikusan figyelt könyvtárába.

Nem látom, ilyenkor mi a gond az FTP-vel, miközben ha a "normál" gép tölti a torrentet, a torrent-fájl pont ugyanúgy megszerezhető lenne (vagy inkább még könnyebben is, mert nem másik gépről kell előkotorni).

FTP-n a jelszó és minden más egyszerűen, mindenféle védelem vagy titkosítás nélkül, egyszerű szövegként közlekedik. Az NFS-nél biztonságról hasonló szinten beszélhetünk, nagyon picit több van. Az SSHFS sokkal jobb, ott már titkosítva van az adatfolyam, beleértve a jelszót is. SSHFS viszont kapcsolat szakadás esetén kernel szinten tudja megfogni az IO-t a kiszolgálóján, ami elég egzotikus rendszer viselkedéshez vezethet, lyukakat nyithat, és instabillá válik a rendszered.

A leírásod alapján még az FTP jelszó ellopása sem kell, de a többi ugyanúgy megvalósítható. Sőt, rsync-en keresztül a célgépre is átkerül a tartalom, ahová egy kraftolt torrent fájlt elhelyezve a kliensedet rá lehet venni túlcsordulás okozására, esetleg a tracker URL hamisításával (is) jelet lehet kifelé küldeni arról a gépről, és mivel a kliensed most működik, a tűzfalad át fogja engedni ezt is. Mivel több tracker URL-t lehetséges megadni, rá lehet venni a torrent kliensedet arra, hogy más gépeket zaklasson, akár a neten, akár a saját helyi hálódon, és a támadó saját magához is haza tudja küldeni a kliensed adatait ugyanígy, amivel mégtöbb infót szerez rólad, a torrentjeidről, és a kliensed technikai adatairól. Azt is tudni fogja milyen pornót nézel.
Ha ezeket felhasználja, kraftolni tud olyan torrentet, ami az általa kiválasztott fájlokat/mappákat seed-eli a te gépedről, a mindennapi usered jogaival, például a céges dokumentumaidat, családi fényképeket, bármit amit a géped elér. Kell részletezzem?

Egy anonymous FTP pedig... ne, öreg, ne... tényleg! Használj inkább SFTP-t! Ugyanazt meg tudod csinálni vele, jelszó sem feltétlen kell, mert tud kulcsos azonosítást. Igaz, ha a gépeden van remote code execution, akkor a kulcsot se védi meg semmi, de ha a kulcsra teszel egy jelszót - amit lehet -, akkor egy fokkal jobb vagy.
A torrent kliensedet pedig szerintem futtasd külön neki szánt userrel!

--
Where do you want to go today?
[nobody@salcay:~]$_

Tisztázzuk még egyszer: minden gép, a "szerverrel" együtt egy routeren lóg. Kívülről (tehát a routeren túlról) nem érhető el az FTP-szerver (nincs semmi port forwarding és hasonló).

Idézet:
Egy anonymous FTP pedig... ne, öreg, ne... tényleg!

Még egyszer: MINDEN egy lokális, 3-gépes (az RPI-t beleszámolva) hálón történik, egy router mögött (mindenkinek egy 192.168.2.* IP-címe van). Az FTP-könyvtár csak olvasható (mint írtam), és kívülről nem látható.

Idézet:
A torrent kliensedet pedig szerintem futtasd külön neki szánt userrel!

Képzeld, egy transmission nevű júzer futtatja...

De hadd kérdezzem meg: ha nem lenne egy torrent-szerver, hanem a saját gépemre letöltöm a torrent-fájlt, és az ott futó torrent-kliens töltögetne, akkor az általad vázolt ál-torrentezés melyik lépése bukna? Nyilván egyik sem, mivel abból indulsz ki, hogy valahol ott egy torrent-fájl. Torrent-fájl nélkül én speciel nem tudok torrentet letölteni...

Nem bonyolult a felépítés, értem miről van szó.

Távoli kódvégrehajtáshoz nem kell aktívan elérnem a géped. Elég ha ő ér el olyan tartalmat, ami ilyen sebezhetőséget használ ki. Lehet ez a laptopod akár.

A távoli kódvégrehajtás lényege, hogy a te géped hajtja végre azt, amit távolról megetet vele valaki vagy valami. Tehát a te géped hajt végre idegen parancsot, neki pedig van hozzáférése a te helyi hálódhoz, látja mi megy rajta.

A NAT nem tűzfal, ahogy szokás mondani, és nem véletlenül!
Az anonymous FTP még ha router mögött van, akkor is vérgáz. Velem egyidős a protokoll! Még Kádár Jánosnak is volt esélye ismerni! Használd ha nagyon akarod, de ha egyszer megütöd vele a bokád, én szóltam!

Nem tudhatom, hogy a "szervered" milyen egyéb adatokat tartalmaz, nem tudhatom mi egyébre használod, vagy van-e rajta interaktív felhasználói tevékenység. Amihez a torrent kliensed (szoftver) hozzáfér, ahhoz az is hozzáférhet, aki oda tud valahogy csocsózni egy torrent fájlt, pláne ha automatán olvas fel mappát. Az általam felvázolt lépések erre kívántak rávilágítani. Ezek a lépések pontosan akkor buknak, ha külön gépen, dedikált userrel, esetleg chroot-olt környezetben vagy konténerben fut a torrent kliensed, és akkor is csak az adatlopás súlyosságát tudnád vele csökkenteni, a tényét nem másítaná meg.

Torrent fájl nélkül is lehet torrentezni. Ott a magnet link, lehet azt használni, ha a kliensed támogatja. S mellesleg ezzel meg tudod előzni a kraftolt torrentek bejuttatását, ezzel együtt az összes hatásukat is.
Transmission + magnet link tutorial:
http://linuxtutorialok.blogspot.hu/2012/03/transmission-magnet-link.html

--
Where do you want to go today?
[nobody@salcay:~]$_

Idézet:
Lehet ez a laptopod akár.

Pontosan. Ezáltal (ebből a szempontból) nem az FTP a necces, hanem a torrentezés maga.

Idézet:
Amihez a torrent kliensed (szoftver) hozzáfér, ahhoz az is hozzáférhet, aki oda tud valahogy csocsózni egy torrent fájlt, pláne ha automatán olvas fel mappát.

Szerintem itt félreértesz. A laptopon letöltöm a torrent-fájlt. Ezt a torrent-fájlt másolja át magának az RPI rsync+ssh-val (tehát itt nincs ftp).

Idézet:
A távoli kódvégrehajtás lényege, hogy a te géped hajtja végre azt, amit távolról megetet vele valaki vagy valami.

Azért annyira nem vagyok nulla biztonságtechnika terén, hogy ezt ne tudjam ;)

Idézet:
Tehát a te géped hajt végre idegen parancsot, neki pedig van hozzáférése a te helyi hálódhoz, látja mi megy rajta.

Ez tiszta sor. De ha teszem azt, sshfs-t használnék, akkor az idegen parancs is meg tudná hívni az scp parancsot, nem?

Az FTP-vel csak a letöltött cuccokat látom, semmi mást, több infóra nincs rálátásom. Ha az FTP-vel mást is látnék, az azt jelentené, hogy az FTP-programban hiba van (feltételezve, hogy a véregyszerű /etc/ftpchroot fájl egyetlen egy sorát nem cseszem el). Hiba meg bármelyik megvalósításban ugyanúgy lehet.

A szerver: leginkább torrent, de ellát nyomtatószerver, scanner-szerver és backup funkciót is. Üzleti titkokat meg nem tárolok :)

Magnet-link: hallottam már róla, de még nem használtam. Ha majd lesz időm, meg a legális torrent-oldalakon magnet-link lesz, nekiesek. De valóban biztonságosabbnak tűnik.

Szóval elhiszem (és tudom), hogy az sFTP biztonságosabb, mint a sima FTP, de nem gondolom, hogy az esetemben bármilyen, nem elhanyagolható előnyt jelentene. De nem gondolom, hogy pl. egy cp parancsot meg kellene tűzdelni ssh-val, mikor a gépről teszem azt, egy pendrive-ra másolok bármit is.

Az ötleteket, észrevételeket, tanácsokat köszi!

$lt;offtopci>
Szinte bele-könnyezik a szemem, olyan boldogság a soraid olvasni, mikor belegondolok, hogy esetleg nekem is volt némi hatásom a paranoiád ilyetén irányú fejlődésében! ;-)
</offtopic>

A privát kulcs megvédésére akartam csak reagálni:
* yubikey, mint Janesznak
* gemalto-s (ha jól emlékszem) gpg-key, amivel a céges laptopodat is zárolni szoktad. abból nem jön ki a titkos kulcs, ha azon generáltad. ssh-ra te nem lőtted be, csak a desktop zárolására?

Azokból semmi nem szedi ki a privát kulcsot, max. pár jólfelkészült bme mérnök részecskegyorsítóval, tervrajzokkal, stb.
A legtöbb, amit el lehet érni, hogy pár aláírási kérést "sutyiban" elnyom a remote code.

Btw.: A mostani hw-tokenes ssh kulcsunkhoz, amikor aláír valamit / bármit egy kis notification window diszkretén jelzi a makkosix-en, hogy épp aláírt egy request, tudjál róla.

+1 az FTP mellet
Egyszerű, gyors, még a kenyérpirító is kezeli, a biztonsága meg kit érdekel otthoni hálón...

-1 az FTP mellett. Esetileg kevés fájl mozgatására oké, de napi használatra az FTP nettó szopás.

A vázolt esetre mi lenne jobb? NFS?

Leírom, nálunk hogy megy a torrent.

rtorrent fut egy screen-ben, fel van konfigurálva watchdir.
Van egy dir a letöltés alatt álló torrenteknek, és egy másik, ahova áthelyezi, amikor completed lesz --> így nem kell mindig azt csekkolgatni, vajon lejött-e már.
Mivel az RPi NFS szerverén látom az egész fát, csak elmentem a torrent fájlt a watchdir-be, akár egy helyi mappába. Ezt felszippantja az rtorrent, és amikor letöltődött, megjelenik a completed mappában az anyag. Innen nem is kell átmásolni, akár mindjárt NFS-en keresztül is meg tudod nézni a filmet / el tudod érni az anyagot. Vagy a linuxos médiabox is be tudja tallózni (NFS-en ide is fel van mountolva).
Az a jó az NFS-ben, hogy tulajdonképpen észre sem veszed, hogy nem helyi lokáción dolgozol (csak a 100Mbit/Gigabit korlát, amiből sejteni lehet). És nem ülteti le az RPi-t, mint mondjuk a samba.

Ha valamilyen okból rá szeretnék nézni az rtorrent-re, csak be-ssh-zok és átveszem a screen session-t.
Az rtorrent nem leakel, mint a transmission (pár éve volt vele ilyen gondom, lehet azóta már javították), és szerintem a legprofibb torrentkliens.
Az egyetlen hátránya, hogy ha munkahelyről nem megy az ssh, akkor meg vagy lőve. Mondjuk van hozzá out-of-the-box működő PHP frontend, amivel kb. ugyanott vagy, mint a transmission-nel.

LAN-on belül az NFS nyilván autentikál.
WAN felé csak ssh/scp kapcsolat van (illetve ha akarod, https). (Régebben használtam cgi-s felületet is kifelé, de már nem teszem. Na az tényleg insecure volt.)
In-house man-in-the-middle támadások ellen nem vagyok felkészülve. Eddig nem volt rá okom. (Vendégnek külön guest wifi van, ahonnan nem látszik a LAN.)

Tehát hasonló, mint nálunk, csak NFS van FTP helyett, meg rtorrent transmission helyett (egyébként nem leak-el, legalábbis több hónapos futás után is van még szabad memória és swap). Meg mondjunk nálunk nincs mediabox, egy szimpla pendrive-ra másoljuk át a letöltött anyagot, és egy asztali DVD-lejátszó hoz létre hangot és képet a bájtokból. Úgy látom, az NFS nem fedi le jobban az igényeinket, mint az FTP.

Egyébként az FTP-t is fel lehet csatolni, pl. a CurlFtpFS-sel (most nézem, eléggé leállt a fejlesztése, biztos már közel tökéletes :) ).

Igen, ismerem a curlftpfs-t. Használtam is régen. Csak az is gyakran stalled lett aztán lehalt az mc meg stb. Szimpatikus volt, de sajnos nem vált be.
Mióta NFS van, azóta vagyok boldog. Mi nem csak a torrentet kezeljük rajta, hanem egyben NAS is az RPi. NFS mount kb. olyan, mintha local winyó lenne. Semmi elszaródás, semmi vacakolás, nem lagzik, tök jó.

Idézet:
Szimpatikus volt, de sajnos nem vált be.

Akkor lekopogom, eddig még bejött.

Idézet:
Semmi elszaródás, semmi vacakolás, nem lagzik, tök jó.

Én is az ilyen megoldásokat szeretem :) A jelenlegi (most még) ilyen, de úgy gondolom, ha valami miatt a jelenlegi megoldást le kell cserélni, NFS lesz (FreeBSD-re normális leírás van, az alaprendszer része).

Jomagam is rtorrenteztem egy darabig, de a deluge sokkal kenyelmesebb a webes interfeszevel. Az eredmenyt meg sshfs-el nezem meg.

Attol fugg mire kell...

Van nalunk egy file szerver ami alapvetoen Samba, de kiderult, hogy a Linuxos build-ek sokkal gyorsabbak ha NFS-en erik el (az _egyik_ megosztast amin a buildhez szukseges amugy to:k publikus dolgok vannak).

A sebesség miatt kérdeztem én is. Úgy találtam, hogy a Samba is képes kihasználni a gigabites sávszélességet, de erősebb gép kell hozzá.

"X is képes kihasználni a gigabites sávszélességet, de erősebb gép kell hozzá."

Hat ez nagy igazsag, kb mindenre igaz. Ha valami gyengebb/lassab/CPU igenyesebb azzal is mindig el lehet ernia kivant teljesitmenyt, csak HW kell hozza.

Amugy meg a kliens oldal is erdekes lehet. (Marmint a kliens oldali teljesitmeny, CPU hasznalat, amit a szerever oldalrol eszre se veszel.)

NAS-on NFS és Samba van beállítva otthon.

+1

AFP+SMB

Owncloud + Webdav

docker -v er?

ezeket használom:

- OwnCloud: sync kliens miatt
- Samba: a nagy fáljokhoz
- NFS és FTP: az IP kameráknak

--
zrubi.hu

Tapasztalataim:

- Ha egyszer kipróbálod az NFS-t, többé nem vágysz másra.
- Samba hitvány lassú és CPU-intenzív. Ráadásul rendszeresek voltak a behalt mountok.
- FTP kényelmetlen. Le kell töltened a fájlt, hogy meg tudd nyitni. Ráadásul a metadata se mindig úgy jön át, ahogy várná az ember.

Nekem nfs+autofs vált be. Akkor van gond, ha gyenge Wifi kapcsolaton keresztül próbálom használni, mert akkor nagyon megáll minden fájl művelet. Ekkor sshfs-t használok.

> - Ha egyszer kipróbálod az NFS-t, többé nem vágysz másra.

Nekem nagyon rossz tapasztalatom van vele.
Szakadozo kapcsolat mellett allandoan behal es nem lehet umountolni, vagy remountolni.
(lehet ujrainditani a gepet). Szoval engem nem gyozott meg.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

fuserrel lehet azt unmountolni (néha szükség van rá, amikor kilövöm alóla a NAS-t és elfelejtettem umountolni előtte).
NFS nekünk LAN-ban van; mondjuk egy GPRS kapcsolaton keresztül biztosan más a helyzet. De ott meg eleve a rosseb megette, és sok adatot úgyse mozgatsz.

Nekem van egy kis node.js programocskam. Akinel szinten van node.js az osszeszinkronizalodik, akinel nincs (telefon) az pedig http-n eri el a fajlokat.

Nem tudom, hogy ez fajlmegosztasnak minosul-e.
Meg abszolut minimalis (csak a legszuksegesebb) fajlokat kezeli, ami mindosszesen 5TB csak.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....