Montare condivisioni Windows da Linux

Montare condivisioni Windows da Linux

CIFS (formalmente conosciuto come SMB) è il protocollo di default delle condivisioni Windows.
Da una macchina Linux è facile connettersi ad una condivisione Windows, sia utilizzando la GUI che la CLI.

Occorre innanzitutto installare i seguenti pacchetti:
(in RHEL/CentOS/Fedora)

# yum install samba-client samba-common cifs-utils

CONNETTERSI TRAMITE GUI:

E’ la soluzione sicuramente più comoda perchè permette di gestire i file remoti tramite interfaccia grafica come se fossero locali. Ovviamente non è affatto adatta agli script.
A seconda del sistema Linux e del server grafico, la procedura può variare.
Dal browser Nautilus, ad esempio, basta inserire nella barra di navigazione l’indirizzo del server Windows nella forma:
smb://<server>/<share>
Una volta dato l’invio, verranno chieste le credenziali per l’accesso alla condivisione.
Nelle ultime versioni di Ubuntu in Nautilus troviamo la comoda opzione “Connetti al server” che apre una finestra di dialogo dove inserire smb://<server>/<share>.

CONNETTERSI TRAMITE CLI
Utilizzando il comando smbclient è possibile accedere alla condivisione Windows tramite linea di comando, in una modalità assai simile a quella ftp. E’ questa la soluzione migliore per l’utilizzo tramite script.
Per visualizzare le condivisioni remote disponibili:

# smbclient -L <server> -U <user>

Dopo aver fornito la corretta password, il comando visualizzerà le condivisioni in forma di tabella a 3 campi: sharename, type, comment.
Per connettersi ad una particolare condivisione:

# smbclient //<server>/<share> -U <user>

Dopo aver fornito la password corretta apparirà il prompt “smb:\>” che riconoscerà svariati comandi “FTP-like” come: ls, cd, lcd, get, put, mget, mput etc

UTILIZZO DEL COMANDO MOUNT
In alternativa alle due precedenti soluzioni possiamo usare il comando “mount”, particolarmente adatto se abbiamo bisogno di un accesso persistente alla condivisione. In tal modo la condivisione apparirà come una cartella locale e sarà possibile utilizzare comandi come “cp” o “rm” per gestire i file remoti.
Potrebbe essere necessario installare alcuni pacchetti come cifs-utils e smbfs, dipende dalla distribuzione e dalla versione.
La sintassi per montare la condivisione è la seguente:

# mount -t cifs -o user=<user> //<server>/<share> /win_share

“win_share” è il punto di mount della condivisione remota nel sistema locale. Di fatto è una cartella locale dentro alla quale appariranno gli oggetti della condivisione. Se non esiste va creata con “mkdir /win_share”.

Per smontare:

# umount /win_share

Se vogliamo che la condivisione venga montata all’avvio, potremo editare il file /etc/fstab ed aggiungere la riga seguente:

//servername/sharename /win_share cifs username=msusername,password=mspassword,iocharset=utf8,sec=ntlm 0 0

Failsafe System – Cluster Linux con Heartbeat

Heartbeat consente di configurare facilmente un cluster Linux, ovvero un sistema che incrementa l’affidabilità assicurando che in caso di malfunzionamento/spegnimento di un server, i servizi vengano automaticamente presi in carico ed erogati da uno dei servers “secondari”, con un downtime del servizio quasi impercettibile.

In pratica Heartbeat si occupa di spostare l’erogazione del servizio (nell’esempio di seguito il servizio http) da un server ad un altro al verificarsi di particolari condizioni configurabili. Per far ciò ovviamente non gestisce solamente il servizio, ma anche l’indirizzo ip secondario virtuale, qui definito VIP, attraverso il quale il servizio stesso viene erogato.

1. SCENARIO

2 X OS Ubuntu 12.04 server 64bit LAMP, full updated, root enable.
Both servers are configured as web-servers (apache2), up and running:
web-1: eth0 192.168.252.129/24 gw 192.168.252.2 (note: hostname must be web-1, check using the command “hostname”) -> NODE 1
web-2: eth0 192.168.252.130/24 gw 192.168.252.2 (note: hostname must be web-2) -> NODE 2
During configuration we need to check which server replies to our request (or which server is working as “master”). For this reason we configure differently two /var/www/index.html page:
/var/www/index.html page on web-1 contains : “Ciao, sono WEB-1 WEB-1 WEB-1”
/var/www/index.html page on web-2 contains : “Ciao, sono WEB-2 WEB-2 WEB-2”

At the end of this procedure node 1 (configured as default “master”) will have the subinterface eth0:0 (VIP) with ip address 192.168.252.135/24 and provide web services. In the event of node 1 failure, node 2 (configured as default “slave”) will become “master” and it will start to provide web services from subinterface eth0:0 with same ip address 192.168.252.135/24. If the fault is fixed web-1 become master again (failback).

2. NETWORK CONFIGURATION

2.1 check hostname and name resolving of two nodes (very important for heartbeat)
# NODE 1
# check the hostname:
root@web-1:~# hostname
web-1 # -> OK

Edit file hosts:

# NODE 1
# Edit hosts file:
root@web-1:~# vim /etc/hosts
127.0.0.1 localhost.localdomain localhost
127.0.1.1 web-1 
192.168.252.129 web-1
192.168.252.130 web-2
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
# NODE 2
# check the hostname:
root@web-2:~# hostname
web-2 -> OK
# NODE 2
# Edit file hosts
root@web-2:~# vim /etc/hosts
127.0.0.1 localhost.localdomain localhost
127.0.1.1 web-2
192.168.252.130 web-2
192.168.252.129 web-1
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

From each node check if you can successfully ping the hostname of the other node:

root@web-1:~# ping web-2
PING web-2 (192.168.252.130) 56(84) bytes of data.
64 bytes from web-2 (192.168.252.130): icmp_req=1 ttl=64 time=0.940 ms
64 bytes from web-2 (192.168.252.130): icmp_req=2 ttl=64 time=0.271 ms

And viceversa:

root@web-2:~# ping web-1
PING web-1 (192.168.252.129) 56(84) bytes of data.
64 bytes from web-1 (192.168.252.129): icmp_req=1 ttl=64 time=0.314 ms
64 bytes from web-1 (192.168.252.129): icmp_req=2 ttl=64 time=0.246 ms
2.2 add a NIC heartbeat dedicated

Now we add a dedicated NIC to heartbeat, so the connection will be more reliable.
Two NICs may be connected between web-1 and web-2 with a cross cable.
This is network configuration:

NODE 1
root@web-1:~# cat /etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface INTERFACE FOR COSTUMER SERVICES
auto eth0
iface eth0 inet static
 address 192.168.252.129
 netmask 255.255.255.0
 network 192.168.252.0
 broadcast 192.168.252.255
 gateway 192.168.252.2
auto eth1
iface eth1 inet static
 address 10.10.50.90
 netmask 255.255.255.0
 network 10.10.50.0
 broadcast 10.10.50.255
NODE 2
root@web-2:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface INTERFACE FOR COSTUMER SERVICES
auto eth0
iface eth0 inet static
 address 192.168.252.130
 netmask 255.255.255.0
 network 192.168.252.0
 broadcast 192.168.252.255
 gateway 192.168.252.2
auto eth1
iface eth1 inet static
 address 10.10.50.91
 netmask 255.255.255.0
 network 10.10.50.0
 broadcast 10.10.50.255

On web-1 we have the NIC eth1 with ip 10.10.50.90
On web-2 we have the NIC eth1 with ip 10.10.50.91
Connect with a cross cable the two NICs and check connectivity pinging the new NIC from a node to the other.

3. HEARTBEAT INSTALLATION AND CONFIGURATION

# NODE 1
# Execute:
root@web-1:/etc/ha.d# apt-get install heartbeat
# Go to the heartbeat configuration directory:
root@web-1:/etc/ha.d# cd /etc/ha.d
# Create and edit file “authkeys” for authentication key:
root@web-1:/etc/ha.d# vim authkeys
auth 1 ### use key 1:
1 sha1 zoobe1234! ### key 1 has the sha1 encryption key “zoobe1234!”

# NB This file must be readable only by root:
root@web-1:# chmod 0600 /etc/ha.d/authkeys
# NODE 1
# Create and edit “ha.cf” config file :
root@web-1:/etc/ha.d# vim ha.cf
logfacility daemon ### facility to use for logging
keepalive 1 #### heartbeat packets frequency
deadtime 5 ### after 5 lost packets the other server became "master"
warntime 3 ### after 3 lost packets a warn log appears
initdead 60 ### after a reboot heartbeat wait 60 sec to start running
ping 192.168.252.2 ### ping the default gateway to check if all the network is dead
#ucast eth1 10.10.50.130 ### heartbeat keepalive destination
udpport 694 ### listening port for heartbeat broadcast
bcast eth1 ### broadcast outgoing interface
auto_failback on ### failback is active
node web-1 ### node-1 hostname
node web-2 ### node-2 hostname
# NODE 1
# Create and edit resurces file “haresources”:
root@web-1:/etc/ha.d# vim haresources
web-1 IPaddr::192.168.252.135/24/eth0 apache2 
## web-1 is the "master",
## 192.168.252.135/24 on eth0 is the "VIP"
## apache2 is the clustered service
# NODE 2
# Execute
root@web-2:# apt-get install heartbeat
# Go to heartbeat configuration directory:
root@web-2:# cd /etc/ha.d
# Create and edit file “authkeys” for authentication key:
root@web-2:/etc/ha.d# vim authkeys
auth 1 ### use key 1
1 sha1 zoobe1234! ### key 1 has the sha1 encryption key “zoobe1234!”
# This file must be readable only by root:
root@web-2:# chmod 0600 /etc/ha.d/authkeys
# NODE 2
# Create and edit “ha.cf” config file :
root@web-2:/etc/ha.d# vim ha.cf
logfacility daemon ### facility to use for logging
keepalive 1 #### heartbeat packets frequency
deadtime 5 ### after 5 lost packets the other server became "master"
warntime 3 ### after 3 lost packets a warn log appears
initdead 60 ### after a reboot heartbeat wait 60 sec to start running
ping 192.168.252.2 ### ping he default gateway to check if all the network is dead
#ucast eth1 10.10.50.129 ### heartbeat keepalive destination
udpport 694 ### listening port for heartbeat broadcast
bcast eth1 ### broadcats outgoing interface
auto_failback on ### failback is active
node web-1 ### node-1 hostname
node web-2 ### node-2 hostname
# NODE 2
# Create and edit resurces file “haresources”:
root@web-2:/etc/ha.d# vim haresources
web-1 IPaddr::192.168.252.135/24/eth0 apache2 ## web-1 is the "master",
## 192.168.252.135/24 on eth0 is the "VIP"
## apache2 is the clustered service

4. HEARTBEAT STARTS

Start heartbeat on both servers:

/etc/init.d/heartbeat start

4. CLUSTER AND FAILOVER TEST

From a browser: http://192.168.252.135. You display the page “Ciao, sono WEB-1 WEB-1 WEB-1” (web-1 is replying to your requests) -> OK, web-1 is now “master”;
If you try http://192.168.252.130 you don’t display anything: apache2 on web-2 is down -> OK
From a client in the network try to permanent ping (ping –t) 192.168.252.135.
Shutdown web-1.
After few seconds you loose only one packet and then the ip starts again to respond correctly: VIP is switched from web-1 to web-2.
From a browser: http://192.168.252.135. You display the page “Ciao, sono WEB-2 WEB-2 WEB-2” (web-2 is replying to your requests) -> OK, web-2 is now “master”;
Power on web-1. After few seconds web-1 become “master” again: failover feature works correctly.

Disinfettare Windows con Linux e non solo

bomberUltimamente capita spesso di dover intervenire su sistemi Windows attaccati dai virus più diversi con effetti più o meno palesi, invasivi e distruttivi.

E’ anche comune che un cliente/amico ci chieda di fare qualcosa: “… non riesco più a navigare!”, indipendentemente dal browser si aprono automaticamente decine di finestre che impediscono completamente la navigazione o nel migliore dei casi la rendono molto difficoltosa.

Se consideriamo quante cose facciamo con il nostro PC, ci rendiamo conto che un problema del genere non deve essere sottovalutato: se il nostro sistema è infetto significa che è stato violato e che occorre intervenire il prima possibile. Il rischio maggiore che si corre è il furto di identità: l’attaccante, magari dall’altra parte del globo, riesce nel tempo a collezionare tutti i dati che gli servono – credenziali varie, immagini di documenti, recapiti, collegamenti etc – per poter dichiarare e dimostrare di essere voi stessi e per svolgere alcune operazioni come l’apertura di un nuovo conto corrente on-line, l’apertura di una linea di credito, l’ordine di bonifici, l’acquisto di beni e servizi… con le conseguenze che potete facilmente immaginare. Egli riesce a collezionare questi dati grazie a poche righe di codice nascosto in qualche file del vostro sistema operativo che gli invia periodicamente le informazioni desiderate. E’ solo questione di tempo e il gioco è fatto.

PREVENZIONE

Un buon antivirus è sicuramente importante ai fini della prevenzione. Per mia esperienza il migliore in circolazione è ESET NOD32 Antivirus, estremamente sicuro e, visto l’eccellente lavoro che svolge, poco vorace di risorse.

Sicuramente anche un buon firewall sarebbe importante, ad esempio per bloccare le connessioni verso internet non volute, ma la configurazione di un firewall esula dallo scopo di questa guida e generalmente non è gestione dell’utente comune.

Sempre in termini di prevenzione, occorre fare molta attenzione quando si scaricano e installano software di terze parti (specie se gratuiti): nella procedura di scaricamento e installazione quasi sempre di default sono flaggate opzioni di installazione di nuove barre strumenti e altri software addizionali che generalmente sono parecchio invasivi, difficili da rimuovere e che potenzialmente aprono falle di sicurezza.

In generale vale la regola (“quasi” sempre) che un software malevolo per installarsi ha bisogno di una qualche azione dell’utente, solitamente il click ad un link di una mail insolita, l’apertura di un allegato, il click su un “OK” in una finestra aperta dal sistema. Vale la regola: nel dubbio non cliccare su nulla se non sai quello che stai facendo.

Un ultimo aspetto è quello legato alle utenze del sistema. In qualche caso una buona soluzione con gli utenti meno “attenti” e forse recidivi, è stata quella di assegnare loro un’ utenza non amministrativa, ben distinta da quella equivalente ad Administrator. In tal modo si limitano i danni delle infezioni, perché il codice malevolo che dovesse attaccare il sistema difficilmente riuscirebbe ad acquisire i privilegi necessari per svolgere azioni altamente dannose.

CURA

Di seguito riporto le operazioni che generalmente svolgo quando devo sistemare un pc infetto o sospetto tale. Se riesco ad avviare il sistema nativo, innanzitutto:

1. Backup su disco esterno dei dati che devo conservare e successiva scansione antivirus con antivirus su macchina non compromessa.

2. Pulizia dei plugins Chrome, Firefox, IE. Disabilitiamoli/disinstalliamoli tutti.

3. Pulizia di tutti i file temporanei, coockies, cronologia navigazione di tutti i browser.

4. Disinstallazione dal sistema tutti i programmi indesiderati o presunti tali, antivirus compreso (è compromesso o comunque non ha funzionato).

5. Scansione antivirus a freddo: Avvio il sistema da Live Ubuntu 14.04. Una volta che il sistema è partito, apro il terminale, installo l’antivirus di Linux ClamAV, aggiorno le definizioni dei virus con freshclam e creo una directory dove posizionare i virus trovati:

# installo ClamAV
 sudo apt-get install ClamTk
 # aggiorno le definizioni dei virus
 sudo freshclam
 # creo una dir temporanea per i virus trovati
 sudo mkdir /tmp/virus

A questo punto monto la partizione di sistema di Windows (nell’esempio sarà in /mnt/windows-partition) e lancio la scansione:

sudo clamscan -r --move=/tmp/virus /mnt/windows-partition

Con l’opzione “-i” visualizziamo solo i virus trovati, che vengono rimossi e spostati in /tmp/virus

Al termine avviamo il sistema operativo sotto osservazione e rimuoviamo la live

6. Pulizia Sistema e Registro (ADWcleaner + Combofix)

A sistema avviato, scaricare ADWcleaner e Combofix. Installare ed avviare i due programmi in successione, seguendo le chiare indicazioni a schermo. Essi eseguono una straordinaria pulizia del sistema, agendo anche sulle chiavi di registro, dove spesso si annidano buona parte dei problemi.

Attenzione: i due software sono soggetti a continui aggiornamenti, possono richiedere la rete per avviarsi e se non superano il check degli aggiornamenti forzano al download della nuova versione. Sarà mia cura cercare di tenere aggiornate le versioni scaricabili, ma, se non ci dovessi riuscire, dovrete seguire le indicazioni a schermo e scaricare le ultime versioni. Fate attenzione a ciò che scaricate. E’ buona norma cercare in rete se le soluzioni proposte dal produttore del software sono affidabili. In alcuni casi i software ti fanno perdere un sacco di tempo per la scansione, ti avvisano poi che hai una serie di problemi e, dulcis in fundo, se vuoi correggere i problemi devi pagare! Se trovate altri tool o versioni più aggiornate di ADWcleaner e Combofix fatemi sapere da dove li scaricate, così li metto a disposizione anche da soluzionilinux.com.

Riavvio del PC.

7. Installazione di tutti gli aggiornamenti di sistema tramite Windows Update. E’ di fondamentale importanza che il sistema sia aggiornato. Spesso gli aggiornamenti correggono falle di sicurezza, o per lo meno dovrebbero farlo…

8. Installazione nuovo antivirus. Se devo usare una versione free generalmente utilizzo Avast, altrimenti, come già detto, consiglio ESET NOD32 Antivirus.

9. Aggiornamento di tutti gli applicativi installati: check degli aggiornamenti, software per software.

10. Al momento della riconsegna del pc pulito, cercare di convincere l’utente di installare solo ed esclusivamente gli applicativi necessari e di utilizzare per l’uso quotidiano, una utenza non amministrativa.

Non mi è mai successo di fallire la disinfezione avendo seguito tutti gli steps qui indicati.

Ad ogni modo, se dovesse capitare, consiglio di togliere il disco di sistema dal pc, inserirlo in un case usb e farlo scansionare da un buon antivirus, come disco esterno. Qualora anche questo fallisse, resta solo da “piallare” completamente il disco (anche l’MBR e tutte le partizioni – consiglio gparted da live Linux) e reinstallare a nuovo il sistema operativo per poi ripristinare i dati salvati nello step 1.

Fatemi avere vostri suggerimenti, esperienze e integrazioni, in modo da creare una guida davvero completa alla disinfezione di Windows.

Samba 4 as Active Directory Domain Controller

In questo articolo configureremo samba 4 come domain controller. Da precisare che tale configurazione potrà prevedere samba 4 come unico gestore del dominio oppure come domain controller aggiunto ad un dominio Active Directory Windows preesistente.
La documentazione di riferimento è quella ufficiale:Samba_AD_DC_HOWTO per la prima soluzione e Join_a_domain_as_a_DC per la seconda. Aggiungerei anche questa tagliata su Ubuntu 14.04 e personalmente testata con successo.

1. Preparazione

Partiamo da una installazione di Ubuntu 14.04 server senza interfaccia grafica. Durante l’installazione sceglieremo solamente di aggiungere il server ssh (Openssh-server).  Per semplicità io generalmente opto per abilitare l’utente root e poter lavorare senza dover ogni volta ulitizzare il sudo. Quindi:

$ sudo passwd root
 [sudo] password for luca:
 Inserire nuova password UNIX:
 Reinserire la nuova password UNIX:
 passwd: password aggiornata correttamente
 $ su -
 Password:
 #

In tal modo lavoreremo come root. Aggiorniamo il sistema:

# apt-get update && apt-get upgrade

2. Installazione e configurazione di samba

2.1 Installazione prerequisiti di samba come DC

# apt-get install attr build-essential libacl1-dev libattr1-dev libblkid-dev libgnutls-dev libreadline-dev python-dev libpam0g-dev python-dnspython gdb pkg-config libpopt-dev libldap2-dev dnsutils libbsd-dev attr krb5-user docbook-xsl libcups2-dev acl ntp

Durante l’installazione di Kerberos verranno richiesti alcuni parametri. Sostanzialmente quelli relativi alla mia configurazione sono:

Realm=DOMINIOSAMBA.IT / Server=samba4 (o anche samba4.dominiosamba.it)

2.2 Configurazione di rete e ntp

Settare un ip statico in /etc/network/interfaces ed aggiungerci come dns server l’ip del server stesso + l’ip di un server dns esterno (generalmente quello del nostro provider) + l’indicazione del dominio:

# vim /etc/network/interfaces

# The primary network interface
auto eth0
iface eth0 inet static
     address 192.168.201.136
     netmask 255.255.255.0
     gateway 192.168.201.20
     dns-nameservers 192.168.201.136 8.8.8.8
     dns-search dominiosamba.it

Ovviamente i dati relativi agli indirizzi dovranno essere adattati alla vostra rete.

Settare l’hostname (in /etc/hostname) in modo congruente, nel mio caso “samba4″.

Visto che samba fa uso di attributi di filesystem che generalmente ext3/4 non supportano, occorre indicarli in /etc/fstab. Qualcosa del tipo:

#questa è la partizione dove risiede samba:
UUID=xyzxyzxy-xyzx-xyzx-x    /    ext4     errors=remount-ro 0 1
#Occorre aggiungere qualche parametro:
UUID=xyzxyzxy-xyzx-xyzx /    ext4     user_xattr,acl,barrier=1,errors=remount-ro 0 1

Ora settare /etc/hosts con qualcosa del tipo:

# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 samba4.dominiosamba.it samba4
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

2.3 Configurazione ntp

# service ntp stop

In /etc/ntp.conf aggiungere il proprio server ntp (nel mio caso 192.168.17.22), altrimenti lasciare quelli di default (ntp server di ubuntu.pool.ntp.org):

# vim /etc/ntp.conf
  Continue reading 

Freeradius: AD domain users authentication and filter by domain groups

L’obiettivo è quello di permettere l’autenticazione radius di utenti di dominio per l’accesso telnet ad uno o più apparati di rete. Nel mio caso utilizzerò uno switch C2960. L’accesso dovrà essere consentito solamente agli utenti appartenenti ad un determinato gruppo del dominio e dovrà fornire loro il livello 15 di privilegi (il massimo livello).

Freeradius grazie all’utility samba ntlm_auth consentirà l’autenticazione degli utenti del dominio.

Prima di iniziare consiglio la lettura attenta di questo sito per comprendere i metodi di autenticazione di Freeradius. Se l’avessi letto io quando ho iniziato la configurazione la prima volta avrei risparmiato davvero tanto tempo. La documentazione seguita: wiki ufficiale, simweb.ch,  e alcune indicazioni contenute in freeradius.1045715…, in particolare per lo script scritto da Scott McLane Gardner.

Questo articolo presuppone che abbiate già a disposizione un dominio active directory gestito (in esclusiva o inserito in un dominio Windows pre-esistente) da samba 4. Questo articolo vi spiegherà passo passo come fare.

Freeradius andrà installato sullo stesso server, nel mio caso Ubuntu 14.40 LTS Server.

1. Installazione e configurazione freeradius

Iniziamo con l’installazione di alcune dipendenze necessarie a freeradius

# apt-get install snmp libtalloc-dev libssl-dev

Ora scarichiamo i sorgenti di openssl e di freeradius direttamente dai siti ufficiali oppure dal mio server: openssl-1.0.1j.tar e freeradius-server-3.0.4.tar

Ci spostiamo nella directory dove abbiamo scaricato gli archivi e  compiliamo e installiamo openssl:

# tar -xvf openssl-1.0.1j.tar 
# cd openssl-1.0.1j/
# ./config --prefix=/usr/local/openssl shared
# make
# make install

Il primo comando scompatta l’archivio tar, il secondo ci fa entrare nella directory scompattata, il terzo esegue uno script di shell che fa un check per i requisiti di sistema, il quarto costruisce i binari (richiede un po’ di tempo), il quinto esegue le istruzioni di installazione.

Ora è la volta di freeradius:

# tar -xvf freeradius-server-3.0.4.tar 
# cd freeradius-server-3.0.4/
# ./configure
# make
# make install

Ora lavoriamo ai file di configurazione.

Entriamo nel file /usr/local/etc/raddb/clients.conf e alla fine inseriamo la rete dalla quale verranno le richieste di autenticazione, con la password di autenticazione e il nas_type:

# vim /usr/local/etc/raddb/clients.conf
....
client 192.168.201.0/24 {
 secret = testing123
 shortname = ReteCOS
 nas_type = cisco
 }
......

Ora modifichiamo il file /usr/local/etc/raddb/users, dopo aver salvato, per sicurezza, la versione originale:

# cp /usr/local/etc/raddb/users /usr/local/etc/raddb/users_orig

Inseriamo in users alcuni utenti di test (per i quali verrà bypassata l’autenticazione da dominio):

....
# The canonical testing user which is in most of the
# examples.
testuser1 Cleartext-Password := "testuser1!", MS-CHAP-Use-NTLM-Auth := 0
testuser2 Cleartext-Password := "testuser2!", MS-CHAP-Use-NTLM-Auth := 0
testuser3 Cleartext-Password := "testuser3!", MS-CHAP-Use-NTLM-Auth := 0
....

Notare che “MS-CHAP-Use-NTLM-Auth := 0″ indica proprio che l’autenticazione dell’utente indicato non dovrà essere processata da ntlm_auth ma avvenire “localmente” tramite il file di configurazione.

Verificare poi che il file di configurazione inner-tunnel contenga la seguente indicazione:

# cat /usr/local/etc/raddb/sites-available/inner-tunnel
...
...
authorize {
 ...
 # Read the 'users' file
 files # <--- questo
 ...
 pap # <--- e questo
}

Ora in /usr/local/etc/raddb/radiusd.conf, sezione security, aggiungere il parametro:
allow_vulnerable_openssl = ‘CVE-2014-0160′

# vim /usr/local/etc/raddb/radiusd.conf
...
...
security {
 allow_core_dumps = no
 max_attributes = 200
 reject_delay = 1
 status_server = yes
 allow_vulnerable_openssl = 'CVE-2014-0160' # <- questo parametro va confiurato
}
...

Ora possiamo effettuare un primo test, cercando di autenticare gli utenti che abbiamo inserito in “users”.

1.1 test autenticazione utenti in “file”

Avviamo il servizio radius in modalità debug:

# radiusd -X

Su altra macchina Linux installare le freeradius-utils per il test dell’autenticazione freeradius

$ sudo apt-get install freeradius-utils

NB Nel prossimo comando troviamo la parola chiave “testing123″, che dovrà essere configurata uguale in /usr/local/etc/raddb/clients.conf, nella sezione “client” che da poco abbiamo inserito.
Eseguire il test:

$ radtest testuser1 testuser1! 192.168.201.136 0 testing123
Sending Access-Request of id 197 to 192.168.201.136 port 1812
 User-Name = "testuser1"
 User-Password = "testuser1!"
 NAS-IP-Address = 127.0.1.1
 NAS-Port = 0
 Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 192.168.201.136 port 1812, id=197, length=20

L’autenticazione è riuscita.

1.2 Configurazione freeradius per autenticazione utenti di dominio

Per permettere a freeradius di autenticare gli utenti di dominio è necessario il binario ntlm_auth, fornito dal pacchetto “winbind”. Installiamo quindi winbind:

# apt-get install winbind

Testare l’autenticazione tramite binario ntlm_auth:

# ntlm_auth --request-nt-key --domain=DOMINIOSAMBA --username=administrator
Password: 
NT_STATUS_OK: Success (0x0)

e ancora:

# ntlm_auth --request-nt-key --domain=DOMINIOSAMBA.IT --username=pippo
assword: 
NT_STATUS_OK: Success (0x0)

Per altri test possiamo utilizzare wbinfo:

wbinfo -u -> lista tutti gli utenti di dominio
-u, –domain-users -> Lists all domain users
-g, –domain-groups -> Lists all domain groups
–user-info=USER-> Get user info
–user-groups=USER-> Get user groups
–authenticate=user%password-> authenticate user

Alcuni esempi:

# wbinfo --user-info=administrator
DOMINIOSAMBA\Administrator:*:0:100::/home/DOMINIOSAMBA/Administrator:/bin/false
# wbinfo --user-info=guest
DOMINIOSAMBA\Guest:*:3000011:3000012::/home/DOMINIOSAMBA/Guest:/bin/false
# wbinfo --user-groups=administrator
100
3000004
3000006
3000008
3000007

Ora configuriamo opportunamente il file di configurazione di ntlm_auth gestito da freeradius. Sostanzialmente inseriamo il path al binario e il nome del nostro dominio:

# vim /usr/local/etc/raddb/mods-enabled/ntlm_auth
exec ntlm_auth {
 wait = yes
 program = "/usr/bin/ntlm_auth --request-nt-key --domain=DOMINIOSAMBA.IT --username=%{mschap:User-Name} --password=%{User-Password}"
}

Se ora proviamo a fare il radtest di prima cercando l’autenticazione di un utente di dominio, l’utente non sarà autenticato. Analizzando il debug di freeradius (ottenuto avviandolo con l’opzione “-X”) si vedrà che il problema è relativo al fatto che freeradius non riesce a gestire correttamente la richiesta, non riuscendo ad identificare il tipo di autenticazione e dando quindi un:
(2) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject

$ radtest pippo pippo123! 192.168.201.136 0 testing123
Sending Access-Request of id 178 to 192.168.201.136 port 1812
 User-Name = "pippo"
 User-Password = "pippo123!"
 NAS-IP-Address = 127.0.1.1
 NAS-Port = 0
 Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Reject packet from host 192.168.201.136 port 1812, id=178, length=20

Il debug mostra:

.....
(2) WARNING: pap : No "known good" password found for the user. Not setting Auth-Type
(2) WARNING: pap : Authentication will fail unless a "known good" password is available
(2) [pap] = noop
(2) } # authorize = ok
(2) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject
.....
.....

Per risolvere il problema dobbiamo indicare a freeradius di utilizzare il protocollo PAP (possiamo quindi disabilitare tutto il resto) che a sua volta deve attivare il modulo ntlm_auth. O meglio: se l’Auth-Type non viene inviato dal client, aggiorna il “control” affinchè usi il proprio ntlm_auth che definito nella sezione authenticate.

fonte: http://www.simweb.ch/blog/2013/08/a-freeradius-for-your-switch-authentication/

Salviamo una copia del file default (sito di default) originale:

cp /usr/local/etc/raddb/sites-available/default /usr/local/etc/raddb/sites-available/default_orig

Poi tagliamo il contenuto della sezione “authorize” e “authenticate” incolliamo il contenuto seguente:

# vim /usr/local/etc/raddb/sites-available/default
authorize {
# If you are using multiple kinds of realms, you probably
# want to set "ignore_null = yes" for all of them.
# Otherwise, when the first style of realm doesn't match,
# the other styles won't be checked.
#
suffix

expiration
logintime
# Most switches support PAP only
 #
 # This module should be listed last, so that the other modules
 # get a chance to set Auth-Type for themselves.
 #
 pap
# If no Auth-Type was sent, we assume PAP but that we should
 # use ntlm_auth for AD authentication through ntlm_auth.
 if(!control:Auth-Type) {
 update control {
 Auth-Type = "ntlm_auth"
 }
 }
 }
authenticate {
 # For PAP against AD with ntlm_auth we need to
 # let Samba ntlm_auth do the authentication work.
 Auth-Type NTLM_AUTH {
 ntlm_auth
 }
># For local users with plaintext password we can still use LDAP
 # Reminder - you might disable update conrol in such casse in
 # authorize because it's an unconditinal update.
 Auth-Type PAP {
 pap
 }
 }

Se ora ripetiamo il test di prima otterremo la corretta autenticazione dell’utente:

$ radtest pippo pippo123! 192.168.201.136 0 testing123
Sending Access-Request of id 54 to 192.168.201.136 port 1812
 User-Name = "pippo"
 User-Password = "pippo123!"
 NAS-IP-Address = 127.0.1.1
 NAS-Port = 0
 Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 192.168.201.136 port 1812, id=54, length=20

E il debug di radiusd restituirà che nella fase di “authorize” (prima fase), freeradius non trova l’Auth-Type e quindi “sovrascrive” con “NTLM_AUTH”:

....
(0) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default
(0) authorize {
(0) suffix : Checking for suffix after "@"
(0) suffix : No '@' in User-Name = "pippo", looking up realm NULL
(0) suffix : No such realm "NULL"
(0) [suffix] = noop
(0) [expiration] = noop
(0) [logintime] = noop
(0) WARNING: pap : No "known good" password found for the user. Not setting Auth-Type
(0) WARNING: pap : Authentication will fail unless a "known good" password is available
(0) [pap] = noop
(0) if (!control:Auth-Type) 
(0) if (!control:Auth-Type) -> TRUE
(0) if (!control:Auth-Type) {
(0) update control {
(0) Auth-Type = NTLM_AUTH
(0) } # update control = noop
(0) } # if (!control:Auth-Type) = noop
(0) } # authorize = noop
(0) Found Auth-Type = NTLM_AUTH
(0) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
.....

L’Auth-Type NTLM_AUTH è configurato nella sezione “authorize” e quindi nella seconda fase di autenticazione freeradius lancia ntlm_auth seconda la configurazione che abbiamo precedentemente settato in /usr/local/etc/raddb/mods-enabled/ntlm_auth:

......
(0) Auth-Type NTLM_AUTH {
Executing: /usr/bin/ntlm_auth --request-nt-key --domain=DOMINIOSAMBA.IT --username=%{mschap:User-Name} --password=%{User-Password}:
(0) ntlm_auth : EXPAND --username=%{mschap:User-Name}
(0) ntlm_auth : --> --username=pippo
(0) ntlm_auth : EXPAND --password=%{User-Password}
(0) ntlm_auth : --> --password=pippo123!
Program returned code (0) and output 'NT_STATUS_OK: Success (0x0)'
(0) ntlm_auth : Program executed successfully
(0) [ntlm_auth] = ok
(0) } # Auth-Type NTLM_AUTH = ok
.......

La fase successiva e ultima, la fase “post-auth”, tutto procede senza problemi:

........
(0) # Executing section post-auth from file /usr/local/etc/raddb/sites-enabled/default
(0) post-auth {
(0) [exec] = noop
(0) remove_reply_message_if_eap remove_reply_message_if_eap {
(0) if (&reply:EAP-Message && &reply:Reply-Message) 
(0) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE
(0) else else {
(0) [noop] = noop
(0) } # else else = noop
(0) } # remove_reply_message_if_eap remove_reply_message_if_eap = noop
(0) } # post-auth = noop
(0) Sending Access-Accept packet to host 192.168.201.205 port 36553, id=54, length=0
Sending Access-Accept Id 54 from 192.168.201.136:1812 to 192.168.201.205:36553
(0) Finished request
Waking up in 0.2 seconds.
Waking up in 4.7 seconds.
(0) Cleaning up request packet ID 54 with timestamp +5
.........

2. Configurazione dello switch Cisco 2960 series

In questa sede non indicheremo step by step la procedura per la configurazione del C2960 ma ci limiteremo a mostrare la running-config (configurazione principale) dalla quale si potranno facilmente dedurre i vari comandi da impartire all’apparato:

Switch#sh run
Building configuration...
Current configuration : 1727 bytes
!
version 12.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Switch
!
boot-start-marker
boot-end-marker
!
enable password password
!
username admin privilege 15 password 0 password
!
!
aaa new-model
!
!
aaa authentication login default group radius local
aaa authorization exec default group radius if-authenticated 
aaa accounting exec default start-stop group radius
aaa accounting system default start-stop group radius
!
!
aaa session-id common
system mtu routing 1500
!
!
spanning-tree mode pvst
spanning-tree extend system-id
!
vlan internal allocation policy ascending
!
!
interface FastEthernet0/1
!
(.....)
!
interface FastEthernet0/24
!
interface GigabitEthernet0/1
!
interface GigabitEthernet0/2
!
interface Vlan1
 ip address 192.168.201.5 255.255.255.0
!
ip default-gateway 192.168.201.20
ip http server
ip http secure-server
radius-server host 192.168.201.136 auth-port 1812 acct-port 1813
radius-server key testing123
radius-server vsa send authentication
!
line con 0
line vty 5 15
!
end

Da una qualsiasi macchina della rete possiamo accedere in telnet allo switch, utilizzando le utenze di dominio:

$ telnet 192.168.201.5
Trying 192.168.201.5...
Connected to 192.168.201.5.
Escape character is '^]'.


User Access Verification

Username: pippo
Password: 

Switch>

L’autenticazione è riuscita. Il livello di privilegi è però il più basso, come prova il simbolo “>” dopo l’hostname “Switch” dell’apparato.

3. Configurazione avanzata di freeradius per filtrare gli accessi ed assegnare livello 15 di privilegi sull’apparato di rete

Ora vogliamo che si possano loggare solo gli utenti appartenenti al gruppo “NetAdmins” e che si logghino direttamente al massimo livello di privilegi (level 15), ovvero in enable. Tutti gli altri utenti devono essere rifiutati.

Il livello massimo di privilegi assegnato agli utenti autenticati, si può semplicemente settare inserendo nella sezione “post-auth” (terza e ultima fase) sempre dello stesso file (/usr/local/etc/raddb/sites-enabled/default) queste poche righe:

post-auth {
....
          update reply {
                        Service-Type = Administrative-User
                       Cisco-AVpair = "shell:priv-lvl=15"
          }
....
}

Testiamo:

$ telnet 192.168.201.5
Trying 192.168.201.5...
Connected to 192.168.201.5.
Escape character is '^]'.

User Access Verification
Username: pippo
Password:
Switch#

OK: il segno “#” dopo “Switch” indica che l’utente viene automaticamente associato la livello di enable.

Ora vediamo come autenticare solo gli utenti appartenenti al gruppo “NetAdmins” del dominio.
Tramite Windows 7 e RSAT creiamo il gruppo “NetAdmins” e vi inseriamo il nuovo utente “pluto”.

Ora ricorriamo ad uno stratagemma, forse non molto “ortodosso” ma efficace: creiamo uno script basato su wbinfo che restituisca una stringa contenente i gruppi di appartenenza di un utente:
creiamo una directory che conterrà il nostro script:

mkdir /usr/local/etc/raddb/myscripts

ci entriamo e creiamo lo script get_groups.sh (grazie a Scott McLane Gardner):

 # cd /usr/local/etc/raddb/myscripts
# vim get_groups.sh
#!/bin/sh
 for T in $(wbinfo --user-domgroups `wbinfo -n $1`) ; do wbinfo -s $T |
perl -ne 'chomp and print'; done

a questo punto facciamo in modo che la sezione “post-auth” di /usr/local/etc/raddb/sites-enabled/default, lanci lo script passandogli come primo argomento lo username dell’utente che sta tentando l’autenticazione, sovrascrivendo in parte ciò che abbiamo settato nello step precedente. Se il match viene verificato l’utente viene accettato e gli vengono assegnati i privilegi level 15, altrimenti viene rifiutato:

# vim /usr/local/etc/raddb/sites-enabled/default
....
post-auth {
...
 if (`/bin/sh /usr/local/etc/raddb/myscripts/get_groups.sh %{User-Name}` =~ /NetAdmins/) {
 update reply {
 Service-Type = Administrative-User
 Cisco-AVpair = "shell:priv-lvl=15"
 }
 noop
 }
# No-one else is allowed.
 else {
 reject
 }
....

La restante parte della sezione deve rimanere invariata.

Come test conclusivo provo l’accesso telnet allo switch con le credenziali di pippo (utente non appartenente al gruppo “NetAdmins”):

$ telnet 192.168.201.5
Trying 192.168.201.5...
Connected to 192.168.201.5.
Escape character is '^]'.

User Access Verification

Username: pippo
Password:

% Authentication failed

Username:

giustamente l’autenticazione fallisce.
Se invece tento l’autenticazione dell’utente pluto (appartenente al gruppo “NetAdmins”), l’autenticazione andrà a buon fine e l’utente godrà dei privilegi livello 15:

$ telnet 192.168.201.5
Trying 192.168.201.5...
Connected to 192.168.201.5.
Escape character is '^]'.

User Access Verification

Username: pluto
Password:

Switch#

Freeradius and Samba4: radius authentication of domain users

Il nostro obiettivo è quello di creare una piattaforma grazie alla quale sia possibile accedere agli apparati di rete (Cisco nel mio caso) utilizzando le credenziali di dominio.

A tal fine configureremo prima samba 4 come domain controller. Da precisare che tale configurazione potrà prevedere samba 4 come unico gestore del dominio oppure come domain controller aggiunto ad un dominio Active Directory Windows preesistente.
La documentazione di riferimento è quella ufficiale:Samba_AD_DC_HOWTO per la prima soluzione e Join_a_domain_as_a_DC per la seconda. Aggiungerei anche questa tagliata su Ubuntu 14.04 e personalmente testata con successo.

Il passo successivo sarà l’installazione di Freeradius che grazie all’utility samba ntlm_auth consentirà l’autenticazione degli utenti del dominio. Prima di iniziare consiglio la lettura attenta di questo sito per comprendere i metodi di autenticazione di Freeradius. Se l’avessi letto io quando ho iniziato la configurazione la prima volta avrei risparmiato davvero tanto tempo. La documentazione seguita: wiki ufficiale, simweb.ch,  e alcune indicazioni contenute in freeradius.1045715…, in particolare per lo script scritto da Scott McLane Gardner.

1. Preparazione

Partiamo da una installazione di Ubuntu 14.04 server senza interfaccia grafica. Durante l’installazione sceglieremo solamente di aggiungere il server ssh (Openssh-server).  Per semplicità io generalmente opto per abilitare l’utente root e poter lavorare senza dover ogni volta ulitizzare il sudo. Quindi:

$ sudo passwd root
 [sudo] password for luca:
 Inserire nuova password UNIX:
 Reinserire la nuova password UNIX:
 passwd: password aggiornata correttamente
 $ su -
 Password:
 #

In tal modo lavoreremo come root. Aggiorniamo il sistema:

# apt-get update && apt-get upgrade

2. Installazione e configurazione di samba

2.1 Installazione prerequisiti di samba come DC

# apt-get install attr build-essential libacl1-dev libattr1-dev libblkid-dev libgnutls-dev libreadline-dev python-dev libpam0g-dev python-dnspython gdb pkg-config libpopt-dev libldap2-dev dnsutils libbsd-dev attr krb5-user docbook-xsl libcups2-dev acl ntp

Durante l’installazione di Kerberos verranno richiesti alcuni parametri. Sostanzialmente quelli relativi alla mia configurazione sono:

Realm=DOMINIOSAMBA.IT / Server=samba4 (o anche samba4.dominiosamba.it)

2.2 Configurazione di rete e ntp

Settare un ip statico in /etc/network/interfaces ed aggiungerci come dns server l’ip del server stesso + l’ip di un server dns esterno (generalmente quello del nostro provider) + l’indicazione del dominio:

# vim /etc/network/interfaces

# The primary network interface
auto eth0
iface eth0 inet static
     address 192.168.201.136
     netmask 255.255.255.0
     gateway 192.168.201.20
     dns-nameservers 192.168.201.136 8.8.8.8
     dns-search dominiosamba.it

Ovviamente i dati relativi agli indirizzi dovranno essere adattati alla vostra rete.

Settare l’hostname (in /etc/hostname) in modo congruente, nel mio caso “samba4″.

Visto che samba fa uso di attributi di filesystem che generalmente ext3/4 non supportano, occorre indicarli in /etc/fstab. Qualcosa del tipo:

#questa è la partizione dove risiede samba:
UUID=xyzxyzxy-xyzx-xyzx-x    /    ext4     errors=remount-ro 0 1
#Occorre aggiungere qualche parametro:
UUID=xyzxyzxy-xyzx-xyzx /    ext4     user_xattr,acl,barrier=1,errors=remount-ro 0 1

Ora settare /etc/hosts con qualcosa del tipo:

# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 samba4.dominiosamba.it samba4
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

2.3 Configurazione ntp

# service ntp stop

In /etc/ntp.conf aggiungere il proprio server ntp (nel mio caso 192.168.17.22), altrimenti lasciare quelli di default (ntp server di ubuntu.pool.ntp.org):

# vim /etc/ntp.conf
  Continue reading