<<TableOfContents: execution failed “] (vedi anche il log)>>
OpenSSH (o Secure SHell) è diventato uno standard de facto per l’accesso remoto sostituendo il protocollo telnet. SSH ha reso superflui protocolli come telnet grazie, in gran parte, al fatto che la connessione è criptata e le password non sono più inviate in chiaro per tutti.
Tuttavia, un’installazione predefinita di ssh non è perfetta, e quando si esegue un server ssh ci sono alcuni semplici passaggi che possono rendere l’installazione molto più resistente.
Usa password/nomi forti
Una delle prime cose che noterai se hai ssh in esecuzione ed esposto al mondo esterno è che probabilmente registrerai i tentativi degli hacker di indovinare il tuo nome utente/password. Tipicamente un hacker farà una scansione della porta 22 (la porta predefinita su cui ssh ascolta) per trovare macchine con ssh in funzione, e poi tenterà un attacco brute-force contro di essa. Con password forti in atto, si spera che qualsiasi attacco venga registrato e notato prima che possa avere successo.
Spero che usiate già password forti, ma se non lo fate allora cercate di scegliere password che contengano:
- Minimo 8 caratteri
- Misto di lettere maiuscole e minuscole
- Misto di lettere e numeri
- Caratteri non alfanumerici (es. caratteri speciali come ! ” £ $ % ^ etc)
I benefici delle password forti non sono specifici di ssh, ma hanno un impatto su tutti gli aspetti della sicurezza dei sistemi. Ulteriori informazioni sulle password possono essere trovate nella documentazione di CentOS:
http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-wstation-pass.html
Se non potete assolutamente evitare che i vostri utenti scelgano password deboli, allora considerate di usare nomi utente generati casualmente o difficili da indovinare per i vostri account utente. Se i cattivi non possono indovinare il nome utente, allora non possono forzare la password. Tuttavia, questa è ancora la sicurezza attraverso l’oscurità e siate consapevoli della fuga di informazioni dei nomi utente da cose come le e-mail inviate dagli account utente.
Disabilita i login di root
Le impostazioni del server SSH sono memorizzate nel file /etc/ssh/sshd_config. Per disabilitare i login di root, assicurati di avere la seguente voce:
# Prevent root logins:PermitRootLogin no
e riavviare il servizio sshd:
service sshd restart
Se avete bisogno dell’accesso come root, fate il login come utente normale e usate il comando su.
Limitare i login degli utenti
I login SSH possono essere limitati solo a certi utenti che hanno bisogno di accesso remoto. Se hai molti account utente sul sistema, allora ha senso limitare l’accesso remoto solo a quelli che ne hanno veramente bisogno, limitando così l’impatto di un utente casuale che ha una password debole. Aggiungete una linea AllowUsers seguita da una lista di nomi utente separati da spazi in /etc/ssh/sshd_config Per esempio:
AllowUsers alice bob
e riavviare il servizio sshd.
Disabilita il protocollo 1
SSH ha due protocolli che può usare, protocollo 1 e protocollo 2. Il vecchio protocollo 1 è meno sicuro e dovrebbe essere disabilitato a meno che tu non sappia che ne hai specificamente bisogno. Cerca la seguente linea nel file /etc/ssh/sshd_config, decommentala e modifica come mostrato:
# Protocol 2,1Protocol 2
e riavviate il servizio sshd.
Usa una porta non standard
Di default, ssh ascolta le connessioni in entrata sulla porta 22. Per un hacker per determinare che ssh è in esecuzione sulla vostra macchina, molto probabilmente farà una scansione della porta 22 per determinarlo. Un metodo efficace è quello di eseguire ssh su una porta non standard. Qualsiasi porta inutilizzata andrà bene, anche se una sopra la 1024 è preferibile. Molte persone scelgono la 2222 come porta alternativa (perché è facile da ricordare), proprio come la 8080 è spesso conosciuta come porta HTTP alternativa. Proprio per questo motivo, probabilmente non è la scelta migliore, in quanto qualsiasi hacker che scansiona la porta 22 probabilmente scansionerà anche la porta 2222 per buona misura. È meglio scegliere una porta alta a caso che non sia usata per nessun servizio conosciuto. Per effettuare il cambiamento, aggiungete una linea come questa al vostro file /etc/ssh/sshd_config:
# Run ssh on a non-standard port:Port 2345 #Change me
e riavviare il servizio sshd. Non dimenticate di apportare tutte le modifiche necessarie al port forwarding nel vostro router e alle regole del firewall. Per esempio su CentOS 7 (e superiori) puoi cambiare il servizio ssh di firewalld facendo un duplicato del suo file di servizio in /etc/firewalld/ e cambiando la linea della porta:
$ cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/ssh-custom.xml
Poi cambiate la linea della porta in /etc/firewalld/services/ssh-custom.xml in modo che la porta sia la stessa del file di configurazione ssh:
<port protocol="tcp" port="2345"/>
Infine, rimuovete il servizio ssh, aggiungete il servizio ssh-custom e ricaricate firewalld affinché il cambiamento abbia effetto:
$ firewall-cmd --permanent --remove-service='ssh'$ firewall-cmd --permanent --add-service='ssh-custom'$ firewall-cmd --reload
O su CentOS 6, aggiungere una regola iptable per aprire la nuova porta ssh:
$ iptables -I INPUT -p tcp --dport 2345 -j ACCEPT
Non dimenticare di chiudere anche la vecchia porta.
Su CentOS 6 e superiori dovreste anche aggiornare selinux, etichettando correttamente la porta scelta, altrimenti sshd non potrà accedervi. Per esempio:
$ semanage port -a -t ssh_port_t -p tcp 2345 #Change me
Poiché ssh non è più in ascolto per le connessioni sulla porta standard, dovrete dire al vostro client su quale porta connettersi. Usando il client ssh dalla linea di comando, possiamo specificare la porta usando lo switch -p:
$ ssh -p 2345 myserver
o se state usando il protocollo fish in konqueror, per esempio:
fish://myserver:2345/remote/dir
Se state pensando che questo suona come un dolore dover specificare la porta ogni volta che vi collegate, aggiungete semplicemente una voce che specifichi la porta nel vostro file locale ~/.ssh/config:
# Client ~/.ssh/configHost myserverHostName 72.232.194.162 User bob Port 2345
E il file: ~/.ssh/config deve avere i seguenti permessi:
$ chmod 600 ~/.ssh/config
Filtrare SSH al Firewall
Se hai bisogno di accesso remoto solo da un indirizzo IP (ad esempio dal lavoro al tuo server di casa), allora considera di filtrare le connessioni al tuo firewall aggiungendo una regola firewall sul tuo router o in iptables per limitare l’accesso alla porta 22 solo a quello specifico indirizzo IP. Per esempio, in iptables questo potrebbe essere ottenuto con il seguente tipo di regola per iptables (CentOS 6):
$ iptables -A INPUT -p tcp -s 72.232.194.162 --dport 22 -j ACCEPT
o usando firwalld (CentOS 7) usare rich-rules per permettere ssh solo su una porta specifica. L’indirizzo sorgente può essere un indirizzo singolo o un indirizzo base con una bitmask:
SSH supporta anche nativamente i wrapper TCP e l’accesso al servizio ssh può essere controllato in modo simile usando hosts.allow e hosts.deny.
Se non si è in grado di limitare gli indirizzi IP sorgente, e si deve aprire la porta ssh globalmente, allora iptables può ancora aiutare a prevenire attacchi brute-force registrando e bloccando ripetuti tentativi di accesso dallo stesso indirizzo IP. Per esempio, con iptables
La prima regola registra l’indirizzo IP di ogni nuovo tentativo di accedere alla porta 22 utilizzando il modulo recente. La seconda regola controlla se quell’indirizzo IP ha tentato di connettersi 4 o più volte negli ultimi 60 secondi, e in caso contrario il pacchetto viene accettato. Si noti che questa regola richiederebbe una politica predefinita di DROP sulla catena di ingresso.
Non dimenticate di cambiare la porta come appropriato se state eseguendo ssh su una porta non standard. Dove possibile, il filtraggio sul firewall è un metodo estremamente efficace per assicurare l’accesso a un server ssh.
Per i sistemi che usano il servizio FirewallD (CentOS 7 o superiore), usate firewall-cmd:
Il primo comando rimuove la regola di servizio più permissiva, il secondo instituisce una regola per accettare solo 4 connessioni in un minuto e registrare tutte le connessioni.
Utilizzare chiavi pubbliche/private per l’autenticazione
L’utilizzo di chiavi cifrate per l’autenticazione offre due vantaggi principali. In primo luogo, è conveniente in quanto non è più necessario inserire una password (a meno che non si criptino le chiavi con una protezione a password) se si usano chiavi pubbliche/private. In secondo luogo, una volta che l’autenticazione con coppia di chiavi pubbliche/private è stata impostata sul server, è possibile disabilitare completamente l’autenticazione con password, il che significa che senza una chiave autorizzata non è possibile ottenere l’accesso – quindi niente più tentativi di cracking della password.
È un processo relativamente semplice per creare una coppia di chiavi pubbliche/private e installarle per l’uso sul tuo server ssh.
Prima di tutto, create una coppia di chiavi pubbliche/private sul client che userete per connettervi al server (dovrete farlo da ogni macchina client da cui vi collegate):
$ ssh-keygen -t rsa
Se non vuoi che ti venga ancora chiesta una passphrase (che è fondamentalmente una password per sbloccare una data chiave pubblica) ogni volta che ti connetti, premi semplicemente invio quando ti viene chiesta una passphrase durante la creazione della coppia di chiavi. Sta a te decidere se aggiungere o meno la crittografia protettiva della passphrase alla tua chiave quando la crei. Se non proteggete la vostra chiave con la passphrase, allora chiunque acceda alla vostra macchina locale avrà automaticamente accesso ssh al server remoto. Inoltre, root sulla macchina locale ha accesso alle vostre chiavi, anche se si presume che se non ci si può fidare di root (o root è compromesso) allora si è in guai seri. Criptare la chiave aggiunge ulteriore sicurezza a scapito dell’eliminazione della necessità di inserire una password per il server ssh da sostituire con l’inserimento di una passphrase per l’uso della chiave. Questo può essere ulteriormente semplificato dall’uso del programma ssh_agent
Ora imposta i permessi sulla tua chiave privata:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/id_rsa
Copiate la chiave pubblica (id_rsa.pub) sul server e installatela nella lista authorized_keys:
$ cat id_rsa.pub >> ~/.ssh/authorized_keys
Nota: una volta importata la chiave pubblica, puoi cancellarla dal server.
e infine impostare i permessi dei file sul server:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/authorized_keys
I permessi di cui sopra sono richiesti se StrictModes è impostato su yes in /etc/ssh/sshd_config (il default).
Assicuratevi che i contesti SELinux corretti siano impostati:
$ restorecon -Rv ~/.ssh
Ora, quando accedete al server, non vi verrà richiesta una password (a meno che non abbiate inserito una passphrase quando avete creato la vostra coppia di chiavi). Per impostazione predefinita, ssh cercherà prima di autenticarsi usando le chiavi. Se non vengono trovate chiavi o l’autenticazione fallisce, allora ssh tornerà all’autenticazione con password convenzionale.
Una volta che avete controllato di poter accedere con successo al server usando la vostra coppia di chiavi pubbliche/private, potete disabilitare completamente l’autenticazione tramite password aggiungendo la seguente impostazione al vostro file /etc/ssh/sshd_config:
# Disable password authentication forcing use of keysPasswordAuthentication no
Frequently Asked Question (FAQ)
Q: CentOS usa la versione X di OpenSSH e l’ultima versione è la Y. La versione X conteneva una grave falla di sicurezza, dovrei aggiornare?
A: No. Il fornitore upstream ha una politica di backporting delle patch di sicurezza dalle ultime versioni nella versione corrente della distribuzione. Finché hai gli ultimi aggiornamenti applicati per la tua distribuzione CentOS sei completamente protetto. Vedi qui per ulteriori dettagli sul backporting delle patch di sicurezza:
http://www.redhat.com/advice/speaks_backport.html
Q: Come posso fare in modo che ssh permetta l’autenticazione basata su chiave senza password tra macchine che condividono le home directory degli utenti tramite NFS?
A: SElinux blocca l’accesso di root alle directory condivise NFS e ai file che non sono leggibili dal mondo per impostazione predefinita e quindi sshd non può leggere i file chiave degli utenti in ~/.ssh. Per abilitare l’accesso, cambiate l’impostazione di use_nfs_home_dirs eseguendo il seguente comando come superutente:
setsebool -P use_nfs_home_dirs 1
https://www.centos.org/forums/viewtopic.php?t=49194
Links
http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-openssh.html
http://www.dragonresearchgroup.org/insight/sshpwauth-tac.html