infokonnyeden.hu | Samba konfiguráció paraméterek magyarázata – biztonságos Linux fájlmegosztás lépésről lépésre

Az alábbi a teljes cikk egyben, a kért paraméterek részletes kifejtésével, az eredeti szerkezetet és stílust követve.

A cikksorozat első részében bemutattam, hogyan alakítottam ki egy gyors és biztonságos fájlmegosztási megoldást Android telefon és Linux számítógép között. Ott elsősorban a rendszer felépítésére és a biztonsági rétegek szerepére koncentráltam. A teljes cikket add vissza egyben.

Olvasási idő: ~9 perc
Nehézségi szint: középhaladó
Fő platform: Linux
Kliens platformok: Android, Windows, iOS, macOS

A folytatásban a Samba konfiguráció gyakorlati oldalára helyezem a hangsúlyt: milyen szerepet töltenek be az egyes paraméterek, milyen problémákat előznek meg, és mely beállítások számítanak valóban indokoltnak egy stabil és biztonságos működéshez.

Mit érdemes átlátni a beállítások mögött?

milyen Samba biztonsági beállítások szükségesek egy modern Linux fájlmegosztáshoz
miért érdemes kikapcsolni az SMB1 protokollt
hogyan segítik a teljesítményt az AIO és sendfile opciók
mikor hasznos az opportunistic locking és mikor érdemes tiltani
miért célszerű külön kezelni az adatbázis jellegű fájlokat
mely Samba opciók válnak feleslegessé WireGuard VPN használata mellett
milyen logika mentén érdemes egy stabil konfigurációt felépíteni

SMB protokoll és alap biztonsági beállítások

SMB verziók tudatos korlátozása

server min protocol = SMB2
server max protocol = SMB3

Az SMB1 tiltása az egyik legegyszerűbb, mégis leghatékonyabb biztonsági lépés. Ez a protokoll mára elavult, és több ismert sérülékenység kapcsolódik hozzá.

A server min protocol = SMB2 azt jelenti, hogy a szerver nem fogad el SMB1 kapcsolatot még akkor sem, ha egy kliens megpróbálná azt használni. A server max protocol = SMB3 pedig azt határozza meg, hogy a Samba a jelenleg stabil és széles körben támogatott SMB3 verzióig használja a modernebb funkciókat, például a jobb teljesítménykezelést és fejlettebb hitelesítési mechanizmusokat.

Mivel a modern rendszerek SMB2 vagy SMB3 verziót használnak, az SMB1 engedélyezése általában csak régi eszközök kompatibilitása miatt merülhet fel. Ha ilyen igény nincs, célszerű teljesen kikapcsolva hagyni.

Mi történne ha SMB1 engedélyezve maradna?

A szerver elfogadhatna downgrade kapcsolatot, ahol egy támadó régi protokollra kényszerítheti a kapcsolatot. Ez több ismert exploitnál (például EternalBlue jellegű támadásoknál) belépési pont lehet.

Hitelesített hozzáférés kikényszerítése

security = user
map to guest = never
restrict anonymous = 2

Ezek a beállítások biztosítják, hogy minden kapcsolat felhasználóhoz legyen kötve, és ne létezzen automatikus guest hozzáférés.

A security = user a Samba klasszikus, felhasználó alapú hitelesítési módját jelenti, ahol minden hozzáférés felhasználónév és jelszó ellenőrzésével történik. A map to guest = never megakadályozza, hogy sikertelen bejelentkezés esetén a rendszer automatikusan guest felhasználóra váltson.

A restrict anonymous = 2 a legszigorúbb anonim korlátozási szint, ami még a megosztások listázását sem engedi hitelesítés nélkül. Ez gyakorlatilag megszünteti az anonim információgyűjtés lehetőségét a szerveren.

A Samba alapértelmezett működése sok esetben a kompatibilitást próbálja segíteni, azonban egy saját használatú rendszerben általában előnyösebb az egyértelmű működés: csak hitelesített kapcsolat létezzen.

Mi történne ha ez lazább lenne?

Például map to guest = bad user esetén hibás felhasználónévvel is létrejöhetne kapcsolat. Ez nem feltétlen jelent közvetlen sebezhetőséget, de növeli a támadási felületet és a logokban nehezebben követhetővé teszi a próbálkozásokat.

Megosztások láthatóságának szabályozása (Access-based enumeration)

access based share enum = yes

Ez a beállítás szabályozza, hogy a Samba kliens milyen megosztásokat jelenít meg a szerveren. Engedélyezett állapotban a felhasználó csak azokat a megosztásokat látja a hálózati listában, amelyekhez tényleges hozzáférési jogosultsága van.

Ez nem közvetlen hozzáférésvédelmi mechanizmus, mert a jogosultságokat továbbra is a valid users és a fájlrendszer szabályai határozzák meg. Ugyanakkor csökkenti az információszivárgás lehetőségét, mivel a felhasználó nem lát olyan megosztásokat, amelyekhez nincs hozzáférése.

Gyakorlati szempontból ez egy tisztább és átláthatóbb működést eredményez, különösen akkor, ha több felhasználó vagy több különböző jogosultsági szint létezik a rendszerben.

Mi történne ha ez ki lenne kapcsolva?

A felhasználó minden megosztást látna, még ha nem is fér hozzá. Ez információszivárgás lehet, például megosztásnevek alapján következtetni lehet a rendszer felépítésére.

Modern NTLM hitelesítés használata

ntlm auth = ntlmv2-only
client ntlmv2 auth = yes
lanman auth = no
client lanman auth = no

Ezek a paraméterek kizárják a régi LANMAN és NTLMv1 hitelesítést, és kizárólag NTLMv2 használatát engedélyezik. Ez ma a minimálisan elfogadható biztonsági szint Samba környezetben.

A ntlm auth = ntlmv2-only konkrétan megtiltja a gyenge NTLMv1 használatát, amely több ismert támadási módszerrel visszafejthető. A lanman auth = no és client lanman auth = no még a nagyon régi LANMAN hitelesítést is tiltja, amely ma már gyakorlatilag teljesen elavult.

A client ntlmv2 auth = yes biztosítja, hogy a Samba kliens módba kerülve is csak modern hitelesítést használjon. Ez különösen akkor fontos, ha a gép más SMB szerverekhez is csatlakozik.

Mi történne ha NTLMv1 engedélyezett maradna?

Offline brute force vagy relay támadásokkal a hitelesítési adatok megszerezhetők lehetnek. Modern hálózatban ez teljesen indokolatlan kockázat.

Hálózati működés egyszerűsítése és stabilizálása

Névfeloldás optimalizálása

name resolve order = host
wins support = no

Ez a konfiguráció a DNS alapú névfeloldást részesíti előnyben, és nem használ NetBIOS broadcast vagy WINS mechanizmust.

A name resolve order = host azt jelenti, hogy a Samba először a rendszer hosts fájlját és DNS feloldást használ, nem pedig a régi NetBIOS névkeresést. A wins support = no pedig kikapcsolja a WINS szerver funkciót, ami modern hálózatokban általában teljesen felesleges.

Ennek eredménye egyszerűbb működés, kevesebb hálózati zaj és gyorsabb kapcsolatfelépítés. Egy otthoni vagy kisebb saját hálózatban ez általában a legpraktikusabb megközelítés.

Mi történne ha NetBIOS maradna aktív?

Felesleges broadcast forgalom keletkezne, ami nagyobb hálózatban már teljesítményromlást és nehezebb hibakeresést okozhat.

SMB signing szerepe a biztonságban

server signing = mandatory

Az SMB signing biztosítja az adatcsomagok integritását. Ez nem titkosítás, hanem módosítás elleni védelem.

A mandatory érték azt jelenti, hogy a szerver csak olyan kliensekkel kommunikál, amelyek támogatják a csomagok digitális aláírását. Ez megakadályozza a man-in-the-middle típusú támadások egy részét, még akkor is, ha a hálózat egyébként biztonságosnak számít.

Ebben a felépítésben a titkosítást a WireGuard VPN végzi, míg a Samba a hitelesítést és az adatok sértetlenségének ellenőrzését. Ez jól elkülönített feladatköröket jelent.

Mi történne ha optional lenne?

Régi kliens is csatlakozhatna signing nélkül, ami downgrade támadások lehetőségét nyitná meg.

Samba teljesítmény optimalizálási lehetőségek

SMB Multi Channel használata

server multi channel support = yes

Ez lehetővé teszi több hálózati kapcsolat egyidejű használatát, ha a kliens ezt támogatja.

A yes érték aktiválja azt a képességet, hogy a Samba párhuzamos TCP kapcsolatokat használjon egyetlen megosztáshoz. Ez például több hálózati interfész vagy modern WiFi kapcsolat esetén növelheti az adatátviteli sebességet és stabilitást.

Mi történne ha ki lenne kapcsolva?

Semmi kritikus, csak a potenciális teljesítménynyereség maradna ki.

Aszinkron IO szerepe

aio read size = 1
aio write size = 1

Az aszinkron IO különösen nagy fájlok másolása esetén javíthatja az adatátvitel hatékonyságát.

Az itt megadott 1 érték azt jelenti, hogy gyakorlatilag minden fájlműveletnél engedélyezett az aszinkron működés (mivel minden 1 byte-nál nagyobb műveletre aktiválódik). Ez egy bevett gyakorlat olyan rendszereknél, ahol a háttértár és a hálózat is képes párhuzamos műveletek kezelésére.

Mi történne ha 0 lenne?

A Samba csak szinkron IO-t használna, ami nagy fájloknál lassabb lehet.

Kernel sendfile optimalizáció

use sendfile = yes
min receivefile size = 16384

Ez lehetővé teszi az adat közvetlen kernel szintű továbbítását.

A use sendfile = yes engedélyezi, hogy a Samba a felhasználói tér megkerülésével közvetlenül a kernelből küldje az adatot a hálózati stack felé. Ez csökkenti a CPU terhelést.

A min receivefile size = 16384 (16 KB) azt szabályozza, hogy csak ennél nagyobb fájloknál használja ezt az optimalizációt, mert kisebb fájloknál a hagyományos módszer néha gyorsabb lehet.

Mi történne ha minden fájlra aktiv lenne?

Sok kis fájlnál akár lassabb is lehetne.

Cache és fájlkezelési optimalizálás

Könyvtár cache használata

getwd cache = yes
directory name cache size = 100

Ez csökkenti a fájlrendszer lekérdezések számát.

A getwd cache = yes gyorsítótárazza az aktuális munkakönyvtár elérési útját, így a Samba nem kérdezi le folyamatosan a fájlrendszert. A directory name cache size = 100 pedig azt határozza meg, hogy hány könyvtárnév legyen eltárolva a cache-ben.

Ez különösen sok kisebb fájl esetén csökkentheti a késleltetést és gyorsabb böngészést eredményezhet.

Mi történne ha túl kicsi lenne?

Több filesystem lookup történne.

Opportunistic locking gyakorlati szerepe

kernel oplocks = yes
oplocks = yes

Az opportunistic locking cache alapú gyorsítást ad általános fájloknál.

A kernel oplocks = yes lehetővé teszi, hogy a Linux kernel is részt vegyen a zárolási mechanizmus kezelésében, míg az oplocks = yes engedélyezi a Samba kliens oldali cache optimalizációját.

Ez jelentősen gyorsíthatja az olyan fájlok használatát, amelyeket egyszerre csak egy kliens használ, például dokumentumok vagy médiafájlok esetén.

Mi történne ha adatbázisnál maradna?

Cache miatt adatvesztés vagy fájl sérülés is előfordulhat.

KeePassXC megosztás speciális biztonsági kezelése

kernel oplocks = no
oplocks = no
strict locking = yes
posix locking = yes

Itt a stabil működés volt a prioritás.

A KeePassXC adatbázis fájl valójában egy tranzakciós jellegű bináris adatbázis, nem egyszerű dokumentum. Az oplocks = no és kernel oplocks = no kikapcsolása megakadályozza, hogy a kliens agresszíven cache-elje a fájlt, ami adatvesztéshez vagy szinkronizációs hibához vezethetne több eszköz használatakor.

A strict locking = yes biztosítja, hogy minden olvasási és írási művelet valódi zárolási ellenőrzésen menjen keresztül, ne csak cache logika alapján történjen. Ez lassabb lehet, viszont adatbázis jellegű fájloknál sokkal biztonságosabb működést ad.

A posix locking = yes pedig a Linux fájlrendszer natív zárolási mechanizmusát is bevonja a folyamatba. Ez különösen fontos lehet akkor, ha a KeePassXC adatbázist egyszerre több eszköz is elérheti (például telefon és számítógép), mert segít elkerülni a fájl sérülését.

Gyakorlati tapasztalat alapján az ilyen jellegű fájloknál mindig a konzisztencia fontosabb, mint a sebesség, ezért itt tudatosan a biztonság felé lett eltolva a konfiguráció.

Mi történne ha oplocks aktív maradna?

Tipikus jelenség:

egyik eszköz ment
másik még cache-ből olvas
konfliktus jön létre
adatbázis corrupted lehet

Ez pont az a fájltípus ahol a Samba wiki is javasolja oplocks tiltását.

Inaktív kapcsolatok kezelése

Deadtime paraméter szerepe

deadtime = 15

Ez a beállítás 15 perc után lezárja az inaktív kapcsolatokat.

A 15 érték percben értendő, és azt jelenti, hogy ha egy kliens negyed órán keresztül nem végez műveletet, a Samba bontja a kapcsolatot. Ez segít felszabadítani a szerver erőforrásait és csökkenti a „beragadt” kapcsolatok számát.

Otthoni használatban ez egy jó kompromisszum: nem bont túl gyorsan, de nem is tart fenn feleslegesen kapcsolatokat órákig.

Mi történne ha 0 lenne?

A kapcsolat sosem záródna automatikusan.

Jogosultságkezelés a megosztásoknál

Hozzáférés és tulajdonosi szabályok

valid users = istvan
force user = istvan
force group = istvan

Ez biztosítja az egységes tulajdonosi struktúrát.

A valid users = istvan korlátozza a hozzáférést erre az egy felhasználóra. A force user és force group pedig azt biztosítja, hogy minden létrehozott fájl a megadott Linux felhasználó és csoport tulajdonába kerüljön, függetlenül attól, melyik eszközről történt a feltöltés.

Ez megakadályozza a jogosultsági káoszt és azt a tipikus problémát, amikor egy fájl egyik eszközről írható, másikról viszont nem.

Mi történne ha force user nem lenne?

Android feltölt → más UID
Linux használ → permission denied

Megosztás alap paraméterei

comment = István Cloud
path = /home/istvan/Cloud
browseable = yes
writeable = yes

Ezek a beállítások magát a megosztást definiálják és a működés alapját adják.

A comment = István Cloud egy leíró mező, amely a kliens oldalon jelenhet meg a megosztás neve mellett. Funkcionálisan nem biztonsági paraméter, inkább az átláthatóságot javítja. Több megosztás esetén segít gyorsan azonosítani a célját.

A path = /home/istvan/Cloud határozza meg, hogy a Samba pontosan mely könyvtárat osztja meg a fájlrendszerből. Ez az egyik legkritikusabb paraméter, mert a tényleges hozzáférés mindig ehhez a Linux könyvtárhoz kötődik. Fontos, hogy a mögöttes fájlrendszer jogosultságai is megfelelően legyenek beállítva.

A browseable = yes azt jelenti, hogy a megosztás megjelenik a hálózati böngészés során (például Windows Network vagy fájlkezelők listájában). Ha ez no lenne, a megosztás csak közvetlen elérési út ismeretében lenne használható.

A writeable = yes engedélyezi az írási műveleteket. Ha ez no lenne, a megosztás csak olvashatóként működne, ami például archiválási célokra lehetne hasznos.

Mi történne ha writeable = no lenne?

A fájlok letölthetők lennének, de feltöltés, módosítás és törlés nem lenne lehetséges.

Fájl és könyvtár jogosultságok egységesítése

create mask = 0775
directory mask = 0775
force create mode = 0775
force directory mode = 0775

Ezek a paraméterek határozzák meg, milyen Linux jogosultságokkal jönnek létre az új fájlok és könyvtárak.

A create mask = 0775 azt szabályozza, hogy új fájlok milyen maximális jogosultságokat kaphatnak. A 0775 azt jelenti:

tulajdonos → olvas / ír / futtat
csoport → olvas / ír / futtat
mások → olvas / futtat

A directory mask = 0775 ugyanezt határozza meg könyvtárak esetén.

A force create mode = 0775 biztosítja, hogy a Samba akkor is alkalmazza ezeket a jogosultságokat, ha a kliens más értéket próbálna megadni. Ez egy konzisztens működést ad különböző platformok között.

A force directory mode = 0775 ugyanezt végzi könyvtáraknál.

Ez különösen fontos heterogén környezetben (Android, Windows, Linux), mert a különböző rendszerek eltérő alap jogosultságokkal hozhatnak létre fájlokat. Ezek a beállítások ezt egységesítik.

Mi történne ha ezek hiányoznának?

Tipikus problémák:

egyik fájl csak root által írható
másik csak egy eszközről módosítható
chmod javítás szükséges kézzel

Ez hosszabb távon kezelhetetlenné teheti a megosztást.

Guest hozzáférés tudatos tiltása

usershare allow guests = no

Privát rendszerben ez általában felesleges kockázatot jelentene.

Ez a beállítás megakadályozza, hogy felhasználók saját megosztásokat hozzanak létre guest hozzáféréssel. Egy egyfelhasználós rendszerben ez nem jelentene előnyt, viszont egy potenciális hibaforrást igen.

Mi történne ha yes lenne?

Egy rosszul konfigurált usershare véletlenül publikus megosztást hozhatna létre.

Mely Samba beállítások maradtak ki és miért

Bizonyos opciók nem adtak volna valós előnyt.

Fedora és más Linux disztribúciók közötti eltérések

Más disztribúciókon rövidebb lehet a konfiguráció, mert több biztonsági paraméter alapértelmezett.

Összegzés

A bemutatott Samba konfiguráció egy jól használható egyensúlyt képvisel a biztonság, a teljesítmény és az egyszerű működés között.

Ez a konfiguráció számomra azért vált be, mert valós használat során bizonyított.

A következő lépés a hálózati hozzáférés további szűkítése, vagyis annak bemutatása, hogyan lehet elérni, hogy a Samba megosztás kizárólag hitelesített VPN kapcsolaton keresztül legyen elérhető. Ezt a sorozat következő részében mutatom be, ahol a WireGuard alapú izolációs modellt vesszük végig.

Ebben részletesen bemutatom:

a WireGuard VPN konfigurációját
a Samba VPN-only elérését
a tűzfalszabályok logikáját
a hálózati biztonsági rétegeket