Quick 'n Dirty Samba Tutorial
In questo articolo do per scontato che il lettore abbia una (minima) conoscenza di TCP/IP. Nessuna conoscenza di Windows o del protocollo SMB e' richiesta.
Inoltre non trattero' ne' la configurazioni di Samba come WINS server o la condivisione di stampanti.
In pratica in questo articolo descrivero' una minimale configurazione di Samba per creare un fileserver per una rete locale.
1. Perche' usare Samba
Perche' no?
Le principali alternative a Samba possono essere l'installazione di un server FTP/SFTP, NFS, o eventualmente Appletalk/Netatalk.
1.1 Apple Talk / Netatalk
Escludo immediatamente Appletalk dalla lista perche' la cosa non ha in generale senso. Io uso Appletalk nella mia rete locale esclusivamente perche' ho dei vecchi Mac che con questo protocollo si trovano piu' a loro agio. I suoi limiti sono comunque evidenti. In primo luogo si comporta come il vecchio filesystem Apple, e quindi i nomi sono limitati a 31 caratteri. Questo in generale non e' un problema finche' (appunto) si usano dei Mac, in quanto i files che condividono hanno comunque meno di 31 caratteri. Tuttavia siccome io condivido files su un filesystem Unix, i files originali spesso superano i famosi 31 caratteri, creando spiacevoli inconvenienti. Inoltre trasferire file grossi funziona male, perche' Netatalk segnala il filesystem pieno e respinge la copia (non mi sono preoccupato di stabilire se a causa di un baco, o piu' semplicemente di qualche impostazione, i suddetti Mac hanno HD di 4GB o meno, e quindi comunque non potrei fare tali trasferimenti, anche se Netatalk funzionasse).
Inoltre la password massima accettata e' 8 caratteri, che e' troppo poco per garantire la sicurezza (beh, se volete ridere, leggete qualcosa sul sistema di autenticazione Samba/NetBIOS... anzi piu' che ridere c'e' da piangere), e in generale non va bene, perche' non potrete autenticarvi come utente normale del sistema unix (cosa abbastanza utile), poiche' un utente Unix generalmente ha password che supera gli 8 caratteri; se avete degli utenti con password di 8 caratteri siete dei pazzi a lasciarglielo fare.
Infine se si hanno in rete anche macchine windows, e' necessario che queste installino (se esiste) qualche client ulteriore per la condivisione. Specialmente questo e' il limite di Netatalk, che invece permette (per esempio) un ottimo sistema di condivisione stampanti.
1.2 NFS
NFS e' in generale considerato insicuro. E la faccenda la liquido cosi'. Alcuni dicono di si', altri dicono di no, io non mi pronuncio. Tuttavia questo sistema e' parte della storia di Unix. Inoltre una saggia politica firewall puo' garantire un ottimo livello di sicurezza (dall'esterno). Purtroppo in una LAN (specie una Hubbed) piu' di tanto non si puo' fare.
1.3 FTP
Beh... FTP e' certamente insicuro!!! I server FTP sono fra i programmi piu' buggati della storia... La connessione (password incluse) e' interamente in chiaro. In pratica la faccenda puo' avere senso solo se si condivide anonimamente, altrimenti in una LAN, chiunque puo' sniffare egregiamente, e quindi e' come avere condiviso pubblicamente... e tuttavia un server ftp anonimo e' un bambino difficile. Bisogna starci molto attenti... e ormai con la possibilita' di downloadare e uploadare tramite HTTP e l'uso di SSH, l'uso di FTP sta diventanto sempre piu' marginale.
Ovviamente bisogna assicurarsi che risponda alle sole chiamate della rete locale, sempre se non si vuole avere il mondo fra i piedi!!!
1.4 SFTP
Niente da dire riguardo la sicurezza. Pero' bisogna usare client esterni. Questo in generale non spaventa l'utente Unix, ma l'utente Win/Mac puo' non essere dello stesso avviso. Inoltre molti di questi prodotti sono shareware e la faccenda e' terribilmente seccante (o meglio, su Unix e' tutto free, su Win e su Mac invece e' diffuso lo shareware). Infine e' necessario avere un account sulla macchina (SFTP si appoggia a SSH in tutte le implementazioni), anche se questo non e' un problema perche' nelle impostazioni di base quasi tutti i protocolli richiedono o l'accesso anonimo o un utente sulla macchina.
Ovviamente in generale i server SSH girano su Unix (incluso MacOS X), anche se ora si stanno diffondendo anche su Win (ottimo quello incluso nella suite Cygwin).
1.5 SAMBA
E allora usiamo SAMBA (non che io sia un gran fan). Ad ogni modo a coloro che obiettano che anche SAMBA e' quasi tutto in chiaro, faccio presente che la si puo' tunnellare sotto ssh (prrr 1 a 0 per me).
Con Samba non ho incontrato particolari restrizioni sulle dimensioni dei files. Ne ho trasferito senza difficolta' uno da 6 GB.
Le password sono crittabili (ahem... si, nel senso che un messaggio in ROT13 e' crittato, non che non e' decrittabile) ecc.. ecc...
2. Configurazione
La configurazione viene fatta quasi tutta dal file /etc/samba/smb.conf .
Per questo articolo ho usato Debian 3.0 nel tree testing, e conseguentemente la versione di Samba impiegata e' 2.2.3a-14. Ad ogni modo per quello che verra' trattato in questo articolo, anche altre versioni non dovrebbero creare problemi.
2.1 Sezione global
Questa sezione inizia con la parola chiave
[global]
e contiene alcune configurazioni generali del server stesso.
Per prima cosa settiamo il nome NETBIOS con
netbios name = FOO
Ovviamente al posto di FOO dovra' esserci il nome NETBIOS che volete assegnare alla macchina. Dopo di che dovrete definire il gruppo di lavoro (workgroup). Ovviamente nell'ipotesi che state costruendo una rete locale isolata da altre reti, potete assegnare qualunque cosa vi piaccia. In caso contrario, contattate l'amministratore.
workgroup = FOOBAR
Dopo di che impostate la stringa che il vostro server restituira' quando gli si chiede "cosa" sia. In generale la seguente (quella di default) puo' andare bene per in quasi tutti i casi.
server string = %h server (Samba %v)
Le lettere precedute da % sono delle variabili che verranno riempite con i valori piu' opportuni. Nella pagina di man troverete informazioni su tutte (gran parte) le variabili valide.
2.1.1 Sicurezza
Ora cominciamo ad interessarci della sicurezza. Un server, qualunque esso sia, puo' essere una potenziale falla in un sistema. Tuttavia in genere possiamo configurarlo in modo tale che l'accesso sia consentito solo a determinate macchine tramite firewall o personalizzazione della configurazione del servizio stessa, creando qualche problema in piu' agli attacker.
Adesso configureremo Samba stesso per non rispondere se non a dati host
hosts allow = 192.168.1.0/30 except 192.168.1.17
host deny = all
Con queste due righe consentiamo esplicitamente l'accesso a tutte le macchine della rete locale, ad eccezione della 192.168.1.17 (che potrebbe per esempio essere connessa direttamente sul web ed essere quindi compromessa). Un'altro modo puo' essere esplicitare direttamente gli host ammessi. Ovviamente questo ha senso solo in una rete casalinga o poco piu', in quanto appena il numero degli host cresce, o si introduce la possibilita' concreta che gli ip possano in qualche modo variare, l'amministrazione rischia di divenire improbabile.
Se nella vostra rete avete davvero pochi computer, puo' essere una buona scelta elencare esplicitamente gli ip, ma la cosa diviene impensabile se avete piu' di un paio di macchine. Ecco un esempio
host allow = 192.168.1.2 192.168.1.3
host deny = all
Samba ci offre anche un'ulteriore garanzia di sicurezza, possiamo infatti scegliere le interfacce ammesse. Nell'esempio, ancora una volta, si sceglie di previlegiare solo gli host locali, ammesso che questi si trovino connesssi all'interfaccia eth1
interfaces = eth1 lo
bind interfaces only
Questo esempio crea un livello di sicurezza di tutto rispetto, in quanto in questo caso il sistema operativo non passa nemmeno a Samba le richieste che provengono da altre interfacce, di fatto impedendo attacchi, in quanto nessuna porzione del codice di Samba viene eseguita.Un firewall puo' aggiungere sicurezza alla sicurezza.
Tuttavia non dobbiamo dimenticare cche non tutti gli attacchi provengono dall'esterno, e che dobbiamo (per esempio) impedire anche che un utente abbia accesso in lettura (o addirittura in scrittura) ai documenti di un altro utente, anche se questo puo' non essere di particolare importanza in una rete casalinga. Un'ultimo accorgimento e' quello di disabilitare l'accesso di root come utente. Infatti connettersi da root non e' per nulla utile, e ovviamente e' problematico in quanto l'utente connesso come root puo' sovrascrivere ogni file contenuto nelle directory condivise... e ovviamente puo' vedere le cartelle condivise di ogni altro utente, salvo prendere misure di sicurezza molto piu' difficili da implementare (per esempio variando il file smb.conf a seconda della macchina dalla quale viene effettuata la connessione). Tuttavia siccome non c'e' alcuna ragione di loggarsi da root, disabilitate con questa stringa:
invalid users = root
Ovviamente il principio puo' valere per qualunque utente o gruppo
invalid users = root paperino @wheel
.Ammesso che voi non vogliate credere che nessuna delle persone che usano la vostra rete locale e' tanto stupida da usare la password vuota potete (e fate bene a) impedire che chi abbia password bianca si connetta. Usate la seguente stringa
null passwords = no
Ora sempre parlando della sicurezza, dobbiamo trattare un problema che ha (vagamente) a che fare con la crittografia. Le password.
L'autenticazione puo' essere svolta in chiaro, oppure in modo crittografato. Ovviamente anche se siete in una rete locale, potreste avere interesse che la password non vada a cani e porci. Un tool come ettercap potrebbe essere usato per sniffare facilmente la password (non che per altro i protocolli crittografici del NetBIOS offrano seri problemi ad essere crakkati)
encrypt password = true
Questo ve lo potete permettere solo se tutte le macchine sono in grado di connettersi usando password cifrate (questo non dovete darlo per scontato, vecchi client per esempio entrano in paranoia). Inoltre subentra la proverbiale insicurezza di Windows a complicare le cose. Le funzioni di hash usate per memorizzare le password nel file /etc/samba/smbpasswd o /etc/samba/private/smbpasswd sono crittografate usando l'algoritmo LM e quello NTLM. Ovviamente dovete essere piu' che certi che nessuno a parte root abbia il minimo accesso a questo file, in quanto entrambi gli algoritmi sono spaventosamente meno sicuri (specie LM) degli standard Unix, e quindi crackare queste e' banale.
Inoltre anche da remoto abilitare questi metodi di autenticazione non e' il massimo, tuttavia, siccome non si puo' fare altrimenti, dei due, consentite esclusivamente NTLM, che ha delle falle grosse come delle case, ma comunque minori di quelle di LM. Queste mie affermazioni non sono immotivate, cercate sul web per maggiori chiarimenti.
Per disabilitare LM
lanman auth = no
Per abilitare a partire da NTLMmin protocol = NT1
Sul tutto potete aggiungere qualche regola del firewall, che non guasta mai. Tenete anche presente che con le impostazioni attuali non e' possibile alcuna connessione a Samba da remoto, e quindi non c'e' alcuna ragione per non blindare le porte 137, 138, 139, 445. Solo per informazione
| Porta | Servizio |
| 137 | NetBIOS Name Service |
| 138 | NetBIOS Datagram Service |
| 139 | NetBIOS Session Service |
| 445 | Direct Hosted |
Blindate blindate... Ovviamente la configurazione del firewall e' standard... tenete conto che il Name Service e il Datagram Service (come dice il nome) sono UDP, gli altri sono TCP.
Tenete anche presente che la sicurezza non e' un gioco da tavolo. Che non riguarda solo le corporation e le aziende. Mi e' capitato una volta di avere il Samba mal configurato (avevo semplicemente scordato di specificare = yes nel bind interfaces only). La cosa non era un gran problema in se, perche' rimaneva comunque il controllo dell'ip e la protezione password (che anche se non e' il massimo, comunque un po' fa). Bene mi sono trovato fra i log una quindicina di sfigati lamer che avevano cercato di connettersi cercando se condividevo C:. Ovviamente il loro tentativo e' stato abbastanza frustrato, ma questo per dirvi che il web e' pieno di perdenti senza speranza che altro non fanno se non fare girare programmini automatici, di cui probabilmente non conoscono nemmeno il funzionamento. Cionondimeno la faccenda puo' essere ugualmente noiosa. Stesse cose accadono con Apache (o meglio con qualunque cosa che giri sulla 80), e questi individui cercano di risalire alle directory di sistema per esempio cercando di violare l'interpretazione delle url. Ora questo problema Apache in pratica non lo ha avuto mai, ma IIS lo aveva (anche se e' stato risolto da anni, forse anche 4 ormai). Bene. Loro continuano a provarci. Questo indica 2 cose. Primo che c'e' gente che e' di una imprudenza/ignoranza inaudita, questo in generale causa fastidi a loro stessi. Secondo che esistono persone che sono in agguato per trovare questa gente e' approfittarne. Il trucco e' non essere nella prima categoria, per ovvi motivi, ma stare lontano anche dalla seconda, perche' in natura essere predatori non e' garanzia sufficiente a non essere mangiati. Bisogna essere i predatori piu' grossi.
Ricapitolando brevemente:
[global]
lanman auth = no
min protocol = NT1
netbios name = FOO
workgroup = FOOBAR
server string = %h server (Samba %v)
hosts allow = 192.168.1.0/30 except 192.168.1.17
host deny = all
interfaces = eth1 lo
bind interfaces only
invalid users = root
null passwords = no
encrypt password = true
2.2 Sharare le cartelle
Se avete pensato di fare i furbi saltando qui, senza avere prima letto la parte sulla sicurezza, non siete affatto stati furbi, tornate indietro e leggetevelo. Ho cercato di scrivere scendendo nel minor dettaglio possibile e di essere quanto piu' chiaro potessi.
Questo e' il formato generale:
[ nomeShare ]
comment =
path = /dir1/dir2
browseable =
writable =
create mask =
directory mask =
Il nome della share puo' essere una qualunque sequenza di 8 o meno carattere. comment e' ovviamente una stringa che descrive il contenuto.
path sono convinto che parla chiaro. Indica dove si trova nel filesystem la directory che vi piacerebbe condividere.
browseable puo' essere impostato a yes o a no. In pratica gli elementi settati a yes, vengono elencati, quelli settati a no, non lo sono, e per accedere a questi e' necessario conoscerne a priori la loro esistenza. Nemmeno da dire che non elencare una share, significa che per attaccarla, bisogna conoscerne a priori l'esistenza. Io consiglio quindi di non renderle browsabili. Tenete presente che i famosi lamer coi loro programmini automatici, non riescono a indovinare i nomi delle vostre share, se voi non li elencate :-).
writable: puo' essere settato a yes o a no. controlla se Samba vi deve dare permesso anche in scrittura su una data cartella. A seconda di quello che dovete farci vi converra' attivare questa opzione o meno.
create mask e directory mask indica i permessi unix che verranno attribuiti ai files e alle directory. Vengono espressi come valore ottale (0700, 0550 ecc)
Tenete infine conto che Samba e' comunque un processo Unix che si appoggia alla struttura sottostante. Ovvero se voi vi loggate con un utente, non avrete piu' permessi di quell'utente sul sistema, a prescindere da come sia stato configurato samba in proposito. Se vi loggate con un utente normale, ammesso che l'amministratore sia tanto pazzo da condividere la cartella /etc (per esempio), non potrete comunque cambiare i files di sistema, perche' il vostro utente non e' abbastanza potente.
In molte configurazioni Samba trovate di default
[ homes ]
comment = Home Directories
browseable = yes
writable = no
o magari (anche se in genere di default non viene dato il permesso di scrittura)
[ homes ]
comment = Home Directories
browseable = yes
writable = yes
create mask = 0700
directory mask = 0700
In questo modo ogni utente puo' per lo meno avere accesso alla propria directory. Questo a senso se gli utenti tengono i files nella home. Io per esempio i files li tengo generalmente in altre directory sparse nel filesystem, e quindi questa configurazione ha poco senso per me.
Se i vostri utenti sono pochi (come in una LAN famigliare), probabilmente non ha senso togliere loro i diritti di scrittura nella loro cosidetta home, anche perche' molto probabilmente il server non lo useranno direttamente dalla macchina, ma probabilmente vorranno usare la loro macchina. In questo caso, usare il server come posto per tenere files ingombranti (ammesso che il server stesso sia un computer potente e non una vecchia macchina adattata a fare da router/firewall, ma in tal caso non vedo perche' usarlo per condividere files, se mai ha piu' senso usarlo per condividere le stampanti -- cosa che peraltro non descivo in questo articolo).
3. Appendice
3.1 Miracoli di LM
In questa appendice spieghero' come funziona il sistema crittografico LM, e perche' e' intrinsecamente insicuro.
In primo luogo, per quelli fra voi che usano Windows 2k/XP, va detto che in generale LM non serve ai suddetti sistemi, che normalmente usano NTLM e NTLMv2, ma le password vengono comunque storate anche con LM, in questo modo abbassando radicalmente la sicurezza del sistema.
- Lunghezza delle Password: le password sono tutte di 14 caratteri. Se la password originaria era piu' lunga, viene troncata, se era piu' corta viene allungata aggiungendo degli spazi.
- Caratteri: tutti i caratteri alfanumerici sono convertiti a maiuscolo.
- Le password vengono divise in due blocchi di 7 caratteri e questi sono criptati.
Non mi dilunghero' particolarmente nella spiegazione degli algoritmi, perche' questo non e' certo il luogo...
Allora... l'hash LM e' 16 bytes. I primo 8 derivano dai primi 7 caratteri, gli ultimi dai restanti caratteri. Ovviamente siccome molta gente e' pigra e non usa password particolarmente lunghe, supporre che sia piu' probabile che gli ultimi caratteri della password siano spazi (in un brute force) e' abbastanza lecito.
Inoltre tenete conto che in ogni caso dovete crakkare due hash da 8 bytes, non uno da 16. Siccome le possibili combinazioni di una stringa di n caratteri (scegliendo da un alfabeto di m caratteri) sono m^n (m alla n), evidentemente per fare un bruteforce di una stringa di 14 caratteri dovrete fare n^14 tentativi se sono due stringhe da 7 caratteri dovrete fare 2 * n ^7 << n^14. Ammettendo per esempio come alfabeto S= {A-Z, 1-0, _} e quindi |S|=37, otteniamo che 37 ^ 14 = 9*10^21, mentre 2 * 37 ^ 7 < 2 * 10^12. Per metterla semplice semplice con una singola stringa da 14 caratteri dovrete fare piu' di un miliardo di volte i tentativi che fate nell'altro caso.
3.2 Miracoli di NTLM
FONTI:
Putroppo mi deve scappare detto che nemmeno NTLM e' particolarmente sicuro. Recenti test condotti in Svizzera hanno mostrato che anche password create con NTLM possono essere facilmente craccate. Il tempo medio per craccare una password alfanumerica e' infatti compreso fra 13 secondi e 1 minuto e 40 secondi. Questo e' crittograficamente parlando un inezia.
Questo nuovo (veramente era stato teorizzato da tempo ) sistema si basa sull'uso di tavole di lookup. Questo e' possibile (e conveniente) in quanto Windows non usa alcun salt, ovvero non aggiunge elementi random alle password, o per dirla semplice, la stessa password codificata su due sistemi, da luogo alla stessa stringa. MacOS/Unix/Linux invece usano un salt di 12 bit, il che rende il tempo necessario 4096 volte maggiore (per capirci si passa da una media di 1 minuto a 4096 minuti, ovvero 68 ore, praticamente tre giorni, ma anche piu' in caso di password ben scelte.
In linea teorica potremmo far finta di non preoccuparci troppo in quanto il computer usato per il test aveva 1.5 GB di RAM. Ma se non siamo a conoscenza dello stato dell'hardware. Al momento attuale infatti e' normale avere (acquistando un computer nuovo) 512 MB, e volendo spendere qualcosa in piu', si riesce ad avere senza problemi 1 GB o anche di piu'.
L'unica cosa che ci salva e' che se un sys admin non si accorge di un attacco lungo 3 giorni, la sua stessa presenza e' piu' dannosa di suddetto attacco.
4. Link
- Come impedire che Win XP/2k salvi le password anche con un hash Lan Manager: http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q299/6/56.asp&NoWebContent=1
