Quanti di voi trovano più conveniente utilizzare una piattaforma Linux da adibire a fileserver piuttosto che un server dedicato di casa Microsoft?

Ebbene, ciò è possibile grazie a SAMBA, applicativo che permette di condividere file e stampanti nell’ambito di reti miste (Windows/Linux).

Il suo funzionamento è abbastanza semplice, in quanto si tratta di un demone il cui file di configurazione è solitamente posizionato all’interno della directory /etc/samba/smb.conf. 

Lo scopo di questa guida non è comunque quello di insegnare ad un utente come fare a gestire il demone SAMBA mediante le operazioni di start/stop/restart (a tal proposito in rete troverete migliaia di how-to), ma quello di fornire alcune dritte essenziali per la messa in sicurezza del fileserver in questione.

Ma ora veniamo al dunque; apriamo il file di configurazione SAMBA mediante il comando:

nightfly@nightbox:~$ sudo nano /etc/samba/smb.conf

digitatiamo la password di superuser ed avremo accesso al file in scrittura (cioè potremo modificarne il contenuto).

Una volta aperto il file vi troverete  davanti a tutta una serie di opzioni impostate di default. La mia raccomandazione è di non modificarle, in quanto sono già sufficienti per garantirvi un livello accettabile di protezione.

Bene, posizioniamoci all’interno della sezione [global] e scorriamo il file fino alla subsection Networking. Le operazioni di messa in sicurezza del fileserver iniziano proprio da qui. Adiamo ad osservare il valore impostato alla direttiva interfaces, e se è il caso sostituiamolo con l’indirizzo IP locale del fileserver (per intenderci, l’indirizzo privato assegnato al fileserver nell’ambito della nostra LAN), ad esempio:

interfaces = 192.1.1.1/24 eth0

Successivamente abilitiamo il binding esclusivamente sull’interfaccia specificata (eth0), in modo da impedire eventuali connessioni da reti esterne (vedi Internet), attraverso la direttiva:

bind interfaces only = true

Ora è necessario specificare quali sono gli indirizzi sorgenti che possono collegarsi al nostro server e quali invece debbano essere bloccati. La direttiva che fa al caso nostro è la seguente:

host deny = ANY EXCEPT 192.168.1.1 192.168.1.2 192.168.1.3 127.0.0.1

cioè stiamo dicendo al server di rifiutare TUTTE le richieste di connessione eccezion fatta per gli indirizzi locali 192.168.1.1 192.168.1.2 192.168.1.3 127.0.0.1

Adesso spostiamoci nella subsection Debugging/Accounting in cui lasceremo invariate le direttive di default, aggiungendo però la seguente stringa:

log level = 3

che indica il livello di accuratezza del file di log (cioè specifica che tipo di eventi riguardanti il fileserver debbano essere registrati all’interno del log di sistema)

Bene, adesso possiamo posizionarci all’interno della subsection Authentication. Lasciate invariate le direttive di default (soprattutto security = user) ed aggiungete le seguenti stringe:

valid users = utente1 utente2

che specifica i nomi utente che possono accedere al fileserver

invalid users = root administrator

che elenca i nomi utente che non possono assolutamente accedere al fileserver

e infine commentate la direttiva:

guest account = nobody

mettendoci un # davanti (#guest account = nobody)

E’ importante inoltre aggiungere al nostro file di configurazione la stringa:

restrict anonymous = 2

in modo da contrastare efficacemente le famigerate NULL SESSION, attraverso le quali è possibile ad esempio procedere con l’enumerazione delle risorse condivise e degli utenti relativi al fileserver.

Ora non ci resta che mettere in sharing le risorse di cui abbiamo bisogno (facendo attenzione che le cartelle condivise abbiano i permessi di lettura e scrittura adeguati già nell’ambito del server stesso) ed il gioco è fatto.

Una volta messe in sharing le risorse, controllate che per ognuna di esse vi sia la direttiva guest ok = yes, la quale permette di utilizzare un ulteriore meccanismo di controllo contro gli accessi non autorizzati alle cartelle condivise.

PS: Il mio consiglio è quello di adoperare il fileserver ESCLUSIVAMENTE nell’ambito della vostra LAN, magari posizionandolo dietro uno screened router (dotato delle opportune ACL) e dietro uno o più bastion host. In questo modo, salvo eventuali exploit futuri, dovreste garantire un buon livello di sicurezza alle vostre risorse condivise.

Bye.