Dopo aver parlato della configurazione di rete su una macchina Linux, oggi daremo spazio a ciò che riguarda l’amministrazione remota di una macchina Linux, parleremo cioè di SSH ( Secure SHell ).
SSH è un protocollo che ci permette di stabilire una connessione remota cifrata a riga di comando verso l’host che vogliamo gestire e amministrare;
Questo è molto importante perchè ci da la possibilità di gestire la macchina anche da una postazione remota.
La porta che viene usata per questo servizio di default è la 22, ma possiamo sempre cambiarla.
Parleremo di SSH facendo uso di OpenSSH: Una suite opensource che rende disponibile le comunicazioni cifrate.
Su di un sistema come prima cosa verifichiamo se è gia stato installato tramite il seguente comando:
rpm -qa | grep openssh-server
Nel nostro caso come vediamo è gia stato installato.
Nel caso in cui non fosse installato procediamo alla sua installazione:
yum install openssh-server
Avviamo il servizio:
service sshd start
Nel caso in cui dovessimo usare la nostra macchina Linux per connettersi in SSH ad altri host dobbiamo installare anche la versione client di SSH cioè il pacchetto openssh-clients.
La comunicazione SSH avviene tramite una connessione cifrata sia in fase di autenticazione che durante la sessione di lavoro, infatti la comunicazione SSH non si basa solamente sull’indirizzo IP e sulla porta ma viene generata anche una chiave univoca per ogni host che vi si connette.
Nel caso in cui la chiave gia associata ad un host specifico venisse alterata verrà negato l’accesso e si dovrà procedere alla ricreazione di una nuova chiave.
Mettiamo in pratica ciò che è stato detto:
CONNESSIONE SSH DA HOST LINUX
La nostra macchina Linux ha IP: 192.168.0.34
Sono stati creati 2 utenti: michele e nicola a cui vogliamo concedergli l’accesso SSH
L’accesso SSH dei 2 utenti viene effettuato da un altra macchina Linux presente in rete
CONFIGURAZIONE DEL SERVER
Sulla macchina Server ossia 192.168.0.34 installiamo openssh-server e ci assicuriamo che il servizio sia in esecuzione come mostrato sopra.
Creiamo i 2 utenti con relative password:
useradd michele
passwd michele
CONFIGURAZIONE DEL CLIENT
Installiamo openssh-client tramite il seguente comando:
yum install openssh-clients
Fatto ciò effettuiamo l’accesso verso il server con l’utente michele:
La struttura del comando ssh per la connessione è strutturata nel seguente modo:
ssh nomeutente_remoto@ip_remoto
Andremo cosi a scrivere:
ssh michele@192.168.0.34
A questo punto ci verrà posta una domanda, ossia se accettare la chiave che è stata generata sul server altrimenti non ci potremmo connettere, e noi gli diciamo di si. ( YES )
L’associazione dell’indirizzo IP del client con la chiave appena creata viene inserita o aggiunta in un file nella root directory dell’host che ha effettuato la connessioneche si chiama “known_hosts”.
Fatto ciò ci viene chiesta la password precedentemente impostata sul server durante la creazione degli utenti e se tutto ha esito positivo riusciamo a collegarci come mostrato in figura.
Per vedere l’associazione della chiave andiamo nel root directory del Client precisamente in “/root/.ssh/” e come vediamo il file “known_hosts” contiene l’associazione IP_SERVER – CHIAVE DEL SERVER
Da questo momento in poi ad ogni successiva connessione non verrà più chiesta la verifica della chiave.
Se invece proviamo ad accedere da un altro host della rete alla prima connessione ci viene sempre richiesta la verifica della chiave.
Vediamo cosa succede se nel server ( 192.168.0.34 ) cancelliamo e ricreiamo la chiave.
La collocazione delle chiavi sul server si trova nel percorso /etc/ssh/ e i file che ci interessano sono:
ssh_host_rsa_key.pub Chiave pubblica ossia quella che dobbiamo accettare in fase di connessione
ssh_host_rsa_key Chiave privata.
Eliminiamo questi 2 file e per la ricreazione riavviamo il servizio SSH:
cd /etc/ssh/
rm ssh_host_rsa_key.pub
rm ssh_host_rsa_key
service sshd restart
A questo punto se dall’ host Client riproviamo ad accedere sempre con l’utente michele vediamo che avremo il seguente messaggio di errore e non potremmo accedere:
Questo messaggio ci informa che l’identità ossia la chiave sul server è cambiata e l’associazione IP_SERVER – CHIAVE_DEL_SERVER che si era creata precedentemente nel file “known_hosts” non combacia più, infatti se andiamo a vedere il file “known_hosts” e la chiave pubblica sul server “ssh_host_rsa_key.pub” vedremo che le 2 chiavi sono diverse.
Il file “known_hosts” si trova nella root directory del Client da cui effettuiamo la connessione e per poter ripermettere di nuovo l’accesso dobbiamo cancellare o commentare (#) la linea relativa all’host a cui ci connettiamo ossia 192.168.0.34 come in figura:
Fatto ciò al primo tentativo ci verrà richiesto di nuovo di accettare la nuova chiave creatasi sul server.
CONNESSIONE SSH DA HOST WINDOWS
Se dovessimo amministrare il nostro server Linux da un pc con un sistema Microsoft ci dobbiamo scaricare un software che si chiama Putty dal seguente sito:
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
Una volta scaricato aprimo il programma e sulla schermata principale inseriamo l’IP del server:
Prima di connettersi potremmo anche salvare l’indirizzo con la relativa porta dandogli un nome in Saved Session e cliccando sul pulsante Save e nella lista sottostante verranno salvate le impostazioni per l’apertura della connessione di modo che al successivo avvio basterà fare doppio click sul nome che abbiamo scelto di memorizzare.
Anche qua il discorso dell’accettazione della chiave alla prima connessione si ripete tramite il seguente messaggio:
CONNESSIONE SSH DA HOST LINUX CON CIFRATURA ASIMMETRICA RSA
Abbiamo parlato fino adesso del modo più diretto per connettersi ma per aumentare la sicurezza possiamo sfruttare la cifratura asimmetrica che consiste nell’uso di una chiave pubblica e una chiave privata.
La Chiave Pubblica rimane sul Server e serve per Cifrare mentre la Chiave Privata viene conservata segretamente dall’utente che vuole accedere e serve per Decifrare ciò che viene Cifrato con la relativa chiave pubblica.
Tra le 2 entità transiterà cosi l’hash di un codice che puo essere ad esempio a 2048 bit
Ogni coppia di chiavi è specifica per ogni utente e inoltre possiamo aggiungere anche un eventuale passphare per maggior sicurezza.
L’algoritmo con cui creeremo le chiavi si chiama RSA.
Passiamo alla configurazione.
CONFIGURAZIONE DEL SERVER
Il server ha ip 192.168.0.34
L’utente a cui daremo l’accesso SSH con cifratura asimmetrica è nicola
Creiamo l’utente nicola:
useradd nicola
passswd nicola
Entriamo con l’utente nicola e iniziamo la creazione delle chiavi a 2048 bit con i seguenti comandi:
su – nicola
ssh-keygen -t rsa -b 2048
Ci vengono fatte delle domande:
Dove salvare le 2 chiavi e noi lascieremo che vengano salvati nella home dell’utente nel percorso predefinito.
Un eventuale passphare che volendo possiamo inserirla, dopo di che viene completata la procedura.
Ci spostiamo all’interno della directory .ssh nella home dell’utente e vediamo le 2 chiavi:
id_rsa Chiave privata
id_rsa.pub Chiave pubblica
Copiamo la chiave pubblica nel file authorized_keys tramite il seguente comando:
cp id_rsa.pub authorized_keys
Adesso copiamo la chiave privata sul Client da cui vogliamo accedere ( 192.168.0.100 ), la copiamo ad esempio nella root directory:
scp .ssh/id_rsa root@192.168.0.100:/root
Andiamo a modificare il file di configurazione di SSH ossia sshd_config:
nano /etc/ssh/sshd_config
Metteremo a no il parametro relativo all’accesso senza l’uso delle chiavi cioè PasswordAuthentication:
Decommentiamo i parametri relativi all’uso delle chiavi tramite algoritmo RSA e inseriremo il percorso corretto di dove si trova il file “authorrized_keys”
Riavviamo il servizio ed il server risulta configurato:
service sshd restart
CONFIGURAZINONE DEL CLIENT
Sul Client andando nella root directory abbiamo la chiave privata appena copiata.
La dobbiamo usare per la connessione al server tramite il comando ssh con l’opzione -i:
ssh -i id_rsa nicola@192.168.0.34
Ci verrà chiesta l’eventuale passphare se l’abbiamo inserita e se tutto va a buon fine siamo entrati.
Se proviamo ad entrare senza l’uso della chiave ossia con il comando visto precedentemente ci verrà negato l’accesso:
Per uscire dalla connessione SSH una volta terminato il lavoro useremo il comando:
exit
CONNESSIONE SSH DA HOST WINDOWS CON CIFRATURA ASIMMETRICA RSA
Adesso vediamo come poter accedere facendo uso delle chiavi da un client con sistema operativo Microsoft.
CONFIGURAZINONE DEL SERVER
La configurazione sul server rimane tale e quale a ciò che abbiamo fatto prima, l’unica cosa che cambia è l’esportazione della chiave privata al client Windows che possiamo fare nel modo in cui preferiamo.
Da un semplice trasferimento in una chiavetta usb o piuttosto effettuando una condivisione di una rusorsa se gia il Server deve fare questo ad esempio tramite Samba .
CONFIGURAZINONE DEL CLIENT
Sul client Windows una volta che abbiamo prelevato la chiave dal Server e l’abbiamo a disposizione sul nostro Client non possiamo usarla direttamente con il software Putty di cui abbiamo parlato precedentemente ma dobbiamo fare uso di un altro strumento che si chiama PuttyGen scaricabile dal seguente sito:
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
Questo strumento ci consente di “convertire” la chiave prelevata per renderla utilizzabile al Putty.
E’ una sorta di conversione anche se forse non è il termine adatto, ma lo scopo è quello di poterla rendere utilizzabile al software con cui ci connettiamo via SSH al Server ossia Putty.
Vediamo come procedere:
Dopo averci scaricato PuttyGen lo apriamo e ci carichiamo la chiave al suo interno tramite il pulsante “Load“.
Ci verrà chiesta la Passphare nel caso l’avessimo inserita:
Fatto ciò ci verrà mostrato un messaggio di notifica con Successo.
Adesso controlliamo i Parametri della finestra:
Il file che andremo a salvare sarà a 2048 bit
L’algoritmo RSA come è gia selezionato di default nella finestra
Non resta che cliccare su “Save Private Key”
A questo punto il file che si è creato sarà utilizzabile da Putty.
Apriamo il Putty, inseriamo l’ip del server e invece di cliccare subito sull’apertura della connessione ci spostiamo sul menu a sinistra in SSH — Auth e nella Text Box che vediamo cliccando su Browse andiamo a prelevare la chiave che abbiamo salvato.
Apriamo la connessione e se tutto è andato bene vedremo che la chiave sarà accetta e ci chiederà l’eventuale inserimento della Passphare:
SSH PORT FORWARDING
Parlando di SSH non possiamo fare a meno di parlare dell’ SSH Port Forwarding.
Per SSH Port Forwarding intendiamo la creazione di un “tunnel” di connessione protetto dove al suo interno faremo passare una connessione che non è protetta.
Un esempio potrebbe essere quello di far passare all’interno del tunnel una sessione di VNC piuttosto che di un SMTP di posta e cosi via.
Si crea una connessione sicura, quindi un tunnel per tutte quelle connessioni che non risultano essere protette di per se ma che viaggiando all’interno della connessione lo diventano.
Vediamo come procedere.
Praticamente apriamo una porta locale che non è utilizzata da altri servizi e creiamo un tunnel per far redirigere le connessioni effettuate su quella porta verso il server remoto.
Immaginatevi di avere 3 host: pc1, pc2 e pc3 ( nel nostro caso fanno parte di una LAN interna )
pc 2 e pc3 sono 2 macchine Linux che comunicano tra di loro
pc1 deve poter gestire pc3 ma non può connettersi direttamente, deve passare per forza da pc2
Quindi:
pc2 aprirà una porta locale e creerà il tunnel di connessione verso pc3
pc1 si connette alla porta locale di pc2 che forwarderà la connessione verso pc3
Nel momento in cui pc2 chiude la connessione il collegamento di pc1 cade.
La struttura del comando per eseguire questa operazione è la seguente:
ssh -L porta_locale:localhost:porta_remota host_remoto
Facciamo un esempio pratico:
Vogliamo aprire la porta locale 14223
Tutte le connessioni sulla porta 14223 devono raggiungere il Server ( 192.168.0.34 ) sulla porta 25
Per fare questo dobbiamo eseguire il seguente comando: !!!!!ATTENZIONE!!!!
Questo comando non va eseguito sul Server ma sull’host che ci permetterà di accedere al Server, nel nostro caso è una macchina Linux che fa parte della rete interna ( pc2 ).
ssh -L 14223:localhost:25 192.168.0.34
Per avere la conferma dell’avvenuta creazione del tunnel usiamo il comando netcat nc:
Facciamo un esempio più chiaro:
Lo facciamo con SSH, che nonstante sia cifrato di suo ci serve per capire il concetto.
Su un host ( 192.168.0.100 ) apriamo la porta locale 14223 con cui verrano forwardate le richieste verso il server 192.168.0.34 sulla porta 22.
L’utente che deve usufruire di questa connessione si chiama pippo.
Sulla macchina 192.168.0.100 daremo il seguente comando:
ssh -L 14223:localhost:22 pippo@192.168.0.34
A questo punto chi vuole entrare in SSH sull host 192.168.0.34 deve passare per forza da 192.168.0.100 che è l’unico a fornirgli il collegamento.
Quindi chi dovrà connettersi a 192.168.0.34 entrerà in 192.168.0.100 con una normale connessione SSH.
Dopo di che si connetterà al localhost ( 127.0.0.1 ) in SSH sulla porta locale 14223 con il nome utente nicola e sarà forwardato a 192.168.0.34.
Riassiumiamo il tutto in questo screenshot:
SICUREZZA SSH
Per concludere il discorso SSH parliamo di come poter rendere sicuro l’uso di questo servizio.
Facciamo un elenco delle cose per renderlo maggiormente sicuro:
- Potremmo fare uso delle cifratura asimmetrica
- Non dobbiamo permettere la login da remoto per l’utente root
- Potremmo cambiare porta invece che lasciare la 22 che è quella di default
- Potremmo inserire una regola nel firewall che solamente da certi indirizzi ip si accettano connessioni
- Potremmo limitare il numero di tentativi o di sessioni che possiamo aprire contemporaneamente
Detto questo vediamo come mettere in pratica ciò che abbiamo appena detto, saltando la cifratura che abbiamo gia visto.
Vi ricordiamo che per ogni modifica effettuata per vedere se è andata a buon fine va riavviato ogni volta il servizio SSH tramite il comando:
service sshd restart
Per non permettere la login dell’utente root andiamo nel file di configurazione di SSH in “/etc/ssh” esattamente nel file sshd_config.
Decommentiamo la linea PermitRootLogin e la settiamo a no
Riavviamo il servizio e come vediamo non potremmo accedere come utente root
Vediamo come cambiare porta e come collegare questa cosa al firewall iptables:
Andiamo a lavorare sempre sul file sshd_config
Decommentiamo la linea relativa e la impostiamo ad esempio a 4222
Riavviamo il servizio e se proviamo a connettersi sulla 22 riceviamo un errore:
Oltre a questo che potrebbe essere banale questa cosa ci protegge in parte.
Se da un altro host della rete facciamo una scansione con nmap generica vediamo che non ci da nessuna porta aperta.
Se la facciamo sulla porta 22 ci dice che risulta essere chiusa
Ma se la facciamo specificando tutto il range di porte vediamo che alla porta 4222 esce fuori tutto, pure il banner che identifica la versione di OpenSSH che usiamo e questo può essere un buco di sicurezza
Potremmo quindi inserire in iptables una Policy di DROP nella catena di INPUT, e un paio di regole dove in una gli diciamo di accettare la connessione solamente da certi host tipo una cosa del genere:
iptables -P INPUT DROP
iptables -I INPUT 1 -m state –state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -s 192.168.0.2 –dport 4222 -j ACCEPT
Questo comporta di avere non più una porta completamente aperta ma FILTRATA e per di più con la Policy a DROP non verrà identificato nessun Banner e il servizio annesso a quella porta rimarrà sconosciuto come in figura.
Per concludere vediamo come limitare il numero di tentativi e di sessioni tramite 2 voci presenti nel file sshd_config:
MaxAuthTries: Ci indica il numero massimo di errori di inserimento della login SSH, ossia una volta aperta la sessione SSH ad esempio tramite Putty quante volte ci è consentito inserire la login a causa ad esempio di errori di digitazione sulla tastiera
Se inseriamo questo valore a 2 vediamo che anche se lo username è corretto al secondo tentativo di inserimento password sbagliata veniamo buttati fuori.
Riavviamo il servizio e come vediamo al secondo tentativo errato veniamo buttati fuori.
Vediamo adesso l’altro parametro:
MaxStartups: Ci indica il numero di sessioni che possiamo aprire verso il server a cui ci vogliamo collegare in SSH ma senza aver effettuato nessun tentativo di login. Ci si basa sulle richieste di connessione.
Se impostiamo il valore a 3 e riavviamo il servizio quando andiamo a eseguire più di 3 sessioni ad esempio con il nostro Putty all’apertura della quarta sessione ci darà un errore
Infine il file di log degli accessi si trova in /var/log/secure.