samba webshare

Security-all

Sziasztok,

Szeretnem a velemenyeteket kerni a kovetkezo problemaban.
Meg kell osztanom tobb telephely kozott dokumentumokat. VPN egyeb okok miatt nem johet szoba, ugyan igy nem johet szoba semmilyen publikus cloud szolgaltatas sem. Az ownCloud-ot probaltam, sajnos nem tudja azt amire szukseg van. Arra gondoltam, hogy egy Samba megosztast atengedek a tuzfalon, termeszetesen a Sambat kellokeppen felkonfoguralom, jogosultsagokat, eros jelszavakat beallitok.
A tuzfalon csak a tcp 139,445 es a udp 137,138,445 portokat engedem be. A doksi szerint ez kell a Samba-hoz.

Lattok-e ebben biztonsagi kockazatot, ill. az emlitett portokkal sebezhetove teszem-e a servert es ezzel a belso halot is?
Kell-e a samba configba valamilyen plusz szabaly, engedelyezes a webshare-hoz?

Minden tanacsot , eszrevetelt koszonok !

Sztupi

  • 5290 megtekintés

( uid_7086 | 2014. 01. 21., k – 10:53 )

Kíváncsi vagyok a válaszokra.

Szerintem ez így kész életveszély, de nem tudnám szakmai érvekkel alátámasztani.
Az mennyire publikus, hogy VPN miért van kizárva?

Azért ha megoldható, csak fix IP-k számára nyisd ki ezeket a portokat!

Gondolom , te itt vmi CISCO-s vpn-re ,openvpnre gondolsz. Na az nem jarhato ut, egyeb okok miatt sem . A virtual halozat mint olyan meg az osszekottetes hianya miatt sem ok.
Egyelore ugy nez ki, h vagy vmi Samba share, vagy vmi cloud mely a belso halon van, es kepes kezelni az M$Office termekeit, es tudja kovetni az egyszerre megnyitott doksi kezelest(megnyitas csak olvashatokent)

Sima samba megosztás bőven jó, még nagyon korlátozni sem kell semmit.
A megfelelő portok forgalmát lokálisan beletereled egy ssl tunnelbe, azt teszed távolról elérhetővé, amit a túloldalon dekódolsz, és plain teszed elérhetővé az ottani gépek számára.
stunnel a barátod, az egyik oldalon (ahol a samba van) szerver módban, a másik oldalon kliens módban. Meg kell még Neked hozzá egy ssl kulcspár, amit openssl-lel megcsinálsz.

--
PtY - www.onlinedemo.hu

Nem írta, hogy mi a probléma a VPN-nel, de akár ez is lehet. Meg az is, hogy más a probléma.

Ellenben egy intel atom uszkve 30-40 ezerből megoldja a GW problémát, és nem a klienseknek kellene az encrypt/decrypt-et csinálni, és főleg nem kellene a klienseken változtatni.
--
PtY - www.onlinedemo.hu

( mezo | 2014. 01. 21., k – 13:38 )

Nalunk 14 telephely van. Mindenhol egy openwrt-s router openvpnel. Van egy szerver bent a hostingban ő a vpn server.
Megfelelő iptables szabaly es a wrts routerek mögött lévő kliensek elerik a másik vpnen levo szervert.
Tok korrektul megy.
Kar h kizartad a vpnt. :(

( zrubi v | 2014. 01. 21., k – 15:10 )

Egy SAMBA-t kitenni a netre igen nagy kockázatot jelent. Ez nem biztonsági szoftver, még akkor sem, ha vannak erre utlaó fícsörei.

Én inkább valami webdaw frontendet tennék elé, ahhoz elég egy böngésző és eleve SSL-be csomagolt a forgalom...

De ha ez sem játszik, akkor:

Elég neki a TCP/445, más nem kell!

Samba konfigba pedig ilyesmiket:

lanman auth = no
ntlm auth = no
client ntlmv2 auth = yes
client lanman auth = No
client plaintext auth = No
server signing = mandatory

Ezek a beállítások force-olják az ntlmv2 auth-ot, + a packet signing-et.
Emiatt régi elavult kliensek (pl win XP) persze nem is tudják majd használni.

Ezek mellett már csak arra kell ügyelni, hogy:

- ne hozz létre publikus megosztásokat
- ne engedj gagyi jelszavakat használni
- és rendszeresen olvasgasd az erre vonatkozó security híreket ;)

--
zrubi.hu

Ezen kívül - bár sosem voltam még elég suicid, hogy megpróbáljam - egyeltalán gyakorlatilag képes normálisan működni egy samba megosztás pl. egy NAT mögötti kliensről a szolgáltatók routerein át egy publikus IP-n meghívva?
Nekem 3 privát hálózatom van VPN-ekkel összekötve, a samba(k) WINS-el irányítva, kliensek DNS szerverekbe oda-vissza bejegyezve, de néha még így is köpköd a szerver, ha véletlenül egy távolabbi kliens reverse DNS-ét nem tudja feloldani :(
Szóval én megfelelően tervezett, irányított és kézben tartott alhálózat nélkül nem is próbálkoznék a dologgal.

Ez az egyik pont ami hibádzik, a másik az, hogy a szolgáltatók pont ezeket a portokat szokták filterelni default;)
Eddig egy olyan szolgáltatót láttam, ahol nem, ott minden 10. gépen volt public share, volt egy kettő amit szemlátomást nem csak a tulaja használt:D
A külön vicces kategória, hogy van bot, ami public share-elt nyomtatót keres, majd nyomtat rajta:)

// Happy debugging, suckers
#define true (rand() > 10)

Hát, ha egész eddig csak ennyi védte a szervert a külső hozzáféréstől, az régen rossz! :(
Elég sok minden kell(het) ahhoz hogy működjön, akár olyanok is, ami(k)re neked nincs ráhatásod (pl. Mcsiv által említett samba portok szolgáltatók általi szűrése).
1., Samba esetén felejtsd el a kívülről történő _közvetlen_ elérést
2., Konkurens írások esélye esetén én a webdav-ot is mellőzném (read-only-ra jó, meg ha kb. egyedül szeretnéd elérni írásra a saját kis cuccaidat bárhonnét)

Szerintem, ha valóban megoldást szeretnél, mesélj kicsit a részletekről:
- A Samba server lóg közvetlen a neten (ő a router is), vagy router mögött van NAT-olt hálón a fő iroda gépeivel együtt? (utóbbi esetben milyen, mennyire komoly router-ed van?)
- A "több telephely" kb. 2-3, vagy 20-50?
- Telephelyenként többgépes NAT-olt alhálózat router mögött, vagy 1db számítógép közvetlen a netre csatlakoztatva?

Egy átlag netkapcsolaton keresztüli Sambázás amúgy sem lesz túl gyors. Kisebb xls/doc-ok használatára még OK, de mondjuk képletekkel egymáshoz kapcsolt Excel táblákban való közös munkával ne számolj!

Nem termeszetesen nem csak ez vedi.Netfilter ami meg vedi a servert.
A Samba server egyik laba a neten, masik a LAN-ban. O maga a router es , tuzfal vedi. Csak a fent felsorolt portok vannak nyitva.

Telephely 3. s nincsnek VPN-ben.
Tobb gepes NAT-olt halo tuzfal mogott.

Webdav: nem jo nekem , mert mint mondtad "read-only-ra jó, meg ha kb. egyedül szeretnéd elérni írásra a saját kis cuccaidat bárhonnét" , nem tobben , hasznalnak.

ha csak nekem kellene eszembe sem jutna a Samba.

Mint mondtam owncloudot probaltam. mar, nem ok. Publikus cloud megint nem ok. Van esetleg otleted ?

Bár írtad, hogy "felülről" nem támogatják a VPN-t, de ennek okára sajnos nem találok értelmes magyarázatot (egyetlen ötletem, hogy külső cég fizetős szolgáltatását értik alatta és emiatt ódzkodnak tőle - de itt, ugye nem erről van szó).

Mert, hogy én továbbra sem mondanék más megoldást, mint:
- Fő telephelyen (Open)VPN szerver (én azért biztonsági szempontból külön fizikai routert tennék a Samba elé és ezt arra bíznám rá)
- Al-telephelyek routerei VPN-el becsatolva a fő router-re
- Privát alhálózatok az egész cég szintjén szisztematikusan kiosztva (telephelyenként különböző C IP tartomány, statikus route-ok beállítva)
- Sambára WINS és ez DHCP-vel kiosztva a klienseknek a telephelyeken is.
- Innentől kezdve - elvileg - bármely telephelyről bármely kliens minden különösebb hókusz-pókusz nélkül látja a Samba szervert, innentől már csak a user jogosultságokon múlik, hogy ki mihez fér hozzá.
- Ellenben cégtől független külsősöknek még elvi lehetőségük sincs hozzáférni az adataidhoz (profik persze mindig vannak, de mégsincs kint egy Samba megosztás az interneten)

Én is "költséghatékony" cégnél oldottam meg így, de ennél alább nem adnám. Fokozni még persze lehet(ne) a csillagos égig...

Na kezd alakulni:-)
En a még nem tamogatott vpn-en a virtualisan osszekotott maganhalozatokat ertettem,pl. osszefuzve az alhalozatok egy invitel vpn haloba. Ez meg nem jarhato egyelore.
A VPN serverrrel beleultetted a bogarat a fulembe, ui. openvpn servert uzemeltetek, bar ez most nem p2p vpn server, de ezen lehet segiteni.
A public samba share elvetve.

Sejtettem, hogy a "Ne kerüljön a körbe idegen cég" probléma áll fent. Én is szeretem saját fennhatóságom és teljes kontrollom alatt megoldani, amit tudok - persze a multisok, meg a "nagyrendszeres" profik ezzel biztosan vitatkoznának.

OpenVPN-hez annyit, hogy kicsit nagy az overhead-je (nekem kb. a net sávszél 50-60%-át sikerült átpréselnem rajta - és itt persze a 2 oldali kapcsolatok upload értékeit kell nézni), ezért később IPoverIP tunel-re váltottam (MikroTik eszközök között), bár ez kevésbé védett, de arra nálam épp adott volt más megoldás.

"Emiatt régi elavult kliensek (pl win XP) persze nem is tudják majd használni."

Sajnos meg vannak...

Akkor alakul a dontes , nem lesz Samba. Megnezem a webdav-ot. Csak gyanitom , ugyanugy fogok jarni vele mint a cloud-al. Lassu, es nem kezelte az egyszerre megnyitott fileokat. Pl. nem csak olvashatonak nyitott meg , ha mar nyitva volt valahol.

"Emiatt régi elavult kliensek (pl win XP) persze nem is tudják majd használni."

Sajnos meg vannak...

Akkor alakul a dontes , nem lesz Samba. Megnezem a webdav-ot. Csak gyanitom , ugyanugy fogok jarni vele mint a cloud-al. Lassu, es nem kezelte az egyszerre megnyitott fileokat. Pl. nem csak olvashatonak nyitott meg , ha mar nyitva volt valahol.