SSh è un protocollo che permette di creare connessioni tramite un canale di comunicazione sicuro tra il Client ed il Server. Il canale che viene creato è cifrato tramite chiavi di crittografia asimmetriche, che vengono scambiate e verificate da entrambi i dispositivi agli estremi dell canale.
Una delle implementazioni del protocollo SSH è OpenSSH. Inizialmente sviluppato nell’ambito del progetto OpenBSD è ormai da tempo disponibile in quasi tutte le distribuzioni GNU Linux e sistemi operativi UNIX -Like.
Il protocollo SSH può oggi essere considerato, senza ombra di dubbio, uno strumento imprescindibile per gli amministratori di sistema e non solo.
La possibilità di creare connessioni sicure è di vitale importanza per la sicurezza dei server da amministrare; basti pensare ad un Sysadmin che ha necessità di accedere a server remoti attraverso la rete internet. Nessuno deve essere in grado di carpire le informazioni sensibili in transito; soprattutto le credenziali di accesso.
Prima dell’avvento di SSH, infatti, i Sysadmin utilizzavano il protocollo Telnet per connettersi ai server remoti. Tale protocollo trasmette e riceve tutti i dati in chiaro, comprese le credenziali di Login; cosicché chiunque poteva fare traffic sniffing sulla rete, poteva “leggere” il contenuto di tutti i pacchetti in transito nella sessione e trafugare username e password senza troppa fatica.
Con l’introduzione di SSH, tutte le comunicazioni da e verso i server sono ora cifrate con chiavi asimmetriche di crittografia. Il contenuto dei pacchetti trasmessi è cifrato; senza cioè che Client e Server condividano una password comune condivisa. E soprattutto, senza che estranei possano leggerne i contenuti.
1. Cambio della porta SSH di default
Per impostazioni di default il servizio ssh è in ascolto sulla port TCP/22. Il ché rende esposto il server ad attacchi su una porta TCP universalmente conosciuta.
Dovrebbe sempre essere una pratica comune per i Sysadmin cambiare la porta di ascolto standard per i sistemi che è chiamato ad amministrare. Questa pratica, contribuisce non poco a mitigare i rischi di attacco ai server che espongono in internet il servizio SSH.
Per cambiare le impostazioni relative alla porta di ascolto del servizio è necessario modificare il file /etc/ssh/sshd_config, utilizzando un editor di testi, come vi o nano.
Una volta aperto il file, localizzate il parametro Port e modificate il numero della porta a vostro piacimento, indicando un valore maggiore di 1024. Nell’esempio qui sotto è stato impostato il valore 47122, il ché rappresenta un numero di porta abbastanza “improbabile” per il protocollo SSH; ciò contribuirà a disorientare gran parte dei tentativi di attacco, almeno quelli meno sofisticati e basati su script “semplici” e facilmente reperibili in rete.
Port 47122 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress ::
Notare che nell’esempio precedente, sono state lasciate commentate le righe relative agli statement AddressFamily e ListenAddress; questo poiché essi sono già impostati al valore di default e non è buona pratica e non c’è motivo di impostare un parametro al suo valore di default.
Da tenere presente che cambiare la porta di default di SSH non è una di quelle pratiche che possono mettere al sicuro al 100%: per un hacker smaliziato è un gioco da ragazzi fare una scansione su tutte le porte e scoprire che SSH è in ascolto su una porta diversa dalla porta TCP/22; cioè, quella standard. Tuttavia, questo metodo può contribuire a mitigare il problema. oltre che ridurre di molto i messaggi di log.
2. Niente più password da digitare
Il fatto di dover necessariamente ricordare svariate decine di password (talvolta anche diverse centinaia) può mettere il Sysadmin in grave imbarazzo. Questo poiché le password sono troppo difficili da ricordare: spesso sono un insieme di caratteri speciali, senza contare che dovremmo premurarci di cambiarla spesso. Per non parlare del problema dello shoulder surfing.
Si, è vero che possono essere utilizzati i cosiddetti Password Manager, ma il semplice fatto di dover digitare un password sulla tastiera, rimane comunque un elemento di debolezza nell’ambito della Cyber Security. Quindi, tanto vale evitare del tutto la necessità di dover digitare una password per accedere al server remoto.
Utilizzando le chiavi SSH, la password da digitare, può diventare un inutile incombenza, giacché si può sfruttare proprio l’utilizzo delle chiavi per accedere al server remoto in modo sicuro e rapido.
Per poter accedere al server remoto con SSH senza digitare alcuna password è necessario configurare sia il Client che il Server.
2.1 Operazioni nel Client
Nella macchina Client bisogna innanzi tutto generare la coppia di chiavi SSH; ovverosia, una chiave pubblica (Public Key) ed una chiave privata (Private Key). Come intuibile, la chiave privata dovrà essere custodita gelosamente e con cura nel proprio client senza condividerla con nessuno; mentre la chiave pubblica potrà essere distribuita ed installata nei Server remoti dove vogliamo accedere.
Per generare la coppia di chiavi nel Client si può invocare un unico comando ssh-keygen utilizzando l’opzione -t per specificare il tipo di chiave, come mostrato nell’esempio qui sotto.
$ ssh-keygen -t ed25519 Generating public/private ed25519 key pair. Enter file in which to save the key (/home/dpm/.ssh/id_ed25519):
Verrà proposto il nome del file nel quale salvare le chiavi, per lo scopo di questo tutorial, sarà utile utilizzare il nome di default proposto da ssh-keygen.
Il comando di creazione delle chiavi chiederà anche una password da utilizzare per accedere alle chiavi stese, in modo che non possano essere utilizzate da persone non autorizzate. Tuttavia, per lo scopo di questo tutorial, sarà utile non assegnare alcuna password alla coppia di chiavi. Per fare ciò, premere <INVIO> all’offerta di inserimento password.
A questo punto, la coppia di chiavi è creata e disponibile per l’uso. Nella cartella .ssh della Home dell’utente saranno presenti i due file id_ed25519 (la chiave privata) e id_ed25519.pub (la chiave pubblica). Mentre la chiave privata dovrà essere custodita con cura e mai divulgata a nessuno, la chiave pubblica dovrà essere depositata nel Server remoto.
Per trasferire la chiave pubblica nel Server remoto abbiamo a disposizione un comando specifico che si preoccupa di fare tutto il necessario per copiare in sicurezza la chiave pubblica di SSH nel posto esatto del server remoto. il comando specifico per copiare la chiave pubblica nel server remoto è ssh-copy-id. Nell’esempio qui sotto, si è voluto copiare la chiave pubblica nel server remoto il cui indirizzo IP è 192.168.4.11 per l’utente jordan.
$ ssh-copy-id jordan@192.168.4.11
Ovviamente, in questa fase non essendo presente alcuna chiave pubblica nel Server remoto verrà chiesta la password dell’utente jordan sul Server remoto.
Al completamento del comando, nel Server remoto la chiave pubblica sarà archiviata, insieme alle eventuali altre già presenti, nel file authorized_keys della directory .ssh della Home directory dell’utente jordan. Qualora questa fosse la prima chiave ad essere trasferita nel server remoto ed il file authorized_keys non fosse presente, esso verrà creato con i permessi e appropriati.
Ora è possibile effettuare il login al Server remoto come utente jordan, senza che ci venga richiesta la password.
2.2 Operazioni nel Server
Al fine di rendere più sicuro l’accesso sul Server remoto, facendo cioè in modo che solo gli utenti che dispongono di una chiave privata corrispondente all pubblica su questo Server remoto possano accedere con il protocollo SSH, è necessario modificare la configurazione del file /etc/ssh/sshd_config ed impostare il parametro PasswordAuthentication al valore no, come mostrato qui di seguito.
PasswordAuthentication no
Successivamente, si dovrà riavviare il servizio ssh del server remoto con il seguente comando.
$ sudo systemctl restart sshd
Se tutto è andato a buon fine, da ora in poi per accedere al Server remoto 192.168.4.11 come utente jordan non sarà più necessario digitare alcuna password
3. Controllare chi può accedere al server
Molte distribuzioni non permettono il login con l’utente root; questo per assicurare il sistema in modo che solo gli utenti non privilegiati possano effettivamente accedere al sistema. Solo in una seconda fare (una volta effettuato il login) possono scalare ai privilegi di root, solo se consentito per quel determinato utente. Questa tecnica serve a prevenire attacchi ad uno degli utenti più delicati e sensibili del sistema (root appunto), tramite semplici ma estremamente comuni e pericolosi script di attacco.
Una utilissima opzione di configurazione di SSH è espressamente dedicata a definire quali utenti possono avere accesso al sistema da remoto; ciò, nonostante all’interno del sistema vi siano più utenti registrati.
Per impostare la lista di utenti abilitati all’accesso da remoto via SSH, editare il file /etc/ssh/sshd_config
AllowUsers marco giorgio axsuser
Riavviare il servizio ssh per rendere effettive le modifiche
$ sudo systemctl restart sshd
Dopo il riavvio del servizio, gli utenti marco, giorgio e axsuser potranno liberamente effettuare l’accesso al sistema con il proprio Client SSH.
4. Controllare da dove si può accedere al server
Per mantenere sempre alta la guardia sul versante sicurezza, i Sysdmin più accorti, preferiscono avere sotto controllo anche da dove si può accedere ai propri server. A tale proposito va detto che lasciare incontrollato l’accesso a tutti i Client che hanno una connessione internet, non è proprio il massimo della sicurezza. Perché mai qualcuno da Hong Kong o da Manila, oppure da New York dovrebbe poter accedere ad un server che normalmente viene amministrato da Milano?.
Ebbene. Agendo sulla configurazione del file /etc/ssh/sshd_config è possibile restringere l’accesso solo per le connessioni che provengono da un determinato indirizzo IP, utilizzando il parametro AllowUsers.
Abbiamo già accennato all’uso di AllowUsers nel capitolo 3. Controllare chi può accedere al server. Questo parametro in effetti può essere utilizzato anche per controllare il Source IP. Vediamo un breve esempio all’opera.
AllowUsers marco@* giorgio@87.1.223.8 *@192.168.27.112 axsuser@195.110.128.*
La riga di configurazione, il cui esempio è illustrato qui sopra, specifica che:
- L’utente
marcopuò collegarsi da qualunque indirizzo IP; - L’utente
giorgiopuò collegarsi solo ed esclusivamente dall’indirizzo IP87.1.223.97; - Qualsiasi utente registrato può collegarsi solo ed esclusivamente dall’indirizzo IP
192.168.27.112; - L’utente
axsuserpuò collegarsi da qualsiasi indirizzo IP della Subnet195.110.128.0/24.
Utilizzando questa tecnica, è possibile avere un controllo quasi completo della provenienza (indirizzo IP sorgente) degli utenti abilitati; restringendo di molto la potenziale superficie di attacco al Server, limitando l’accesso solo a coloro che provengono da set di indirizzi IP noti a priori.
Ovviamente per rendere effettive le modifiche al file /etc/ssh/sshd_config, è necessario riavviare il servizio SSH:
$ sudo systemctl restart sshd
Dopo il riavvio del servizio SSH le restrizioni saranno attive.
Considerazioni finali
OpenSSH è un eccellente strumento per implementare un SSH server forte e robusto. Le configurazioni che sono state illustrate in questo post sono solo alcune di quelle possibili; certamente le più semplici da implementare sin da subito per iniziare a collegarsi al proprio server in sicurezza.
Nel file /etc/ssh/sshd_config
Tuttavia, SSH è solo uno dei tanti elementi per rendere sicuro l’accesso remoto ad un Server; esso dovrebbe essere sempre attivato in cooperazione con altri strumenti, come ad esempio il Port Knocking, Fail2ban e soprattutto un buon Firewall.
CondividiDisclaimer
Questa pagina potrebbe contenere link di affiliazione. Gli acquisti o gli ordini che effettuerai tramite tali link possono generare commissioni che ci aiutano a sostenere questo sito web.
