Torniamo sul tema ssh, credo che questo sia il terzo o forse il quarto articolo riguardante ssh, uno dei miei strumenti preferiti su un server Linux, e che molte volte non viene utilizzato o configurato correttamente. In questa piccola guida vi mostrerò alcune operazioni di configurazione per rendere il vostro server ssh un po’ più sicuro dai più comuni attacchi.
In particolare vi mostrerò le configurazioni per openssh che è il server ssh più comune e utilizzato in tutte le distribuzioni Linux ma, come piccolo suggerimento, se si utilizza un VPS e volete risparmiare un po’ di memoria guardate anche dropbear, è una valida alternativa a openssh e permette di risparmiare un pò di spazio nella vostra ram.
Per Debian e Ubuntu (ma anche per altre distribuzioni) il file di configurazione si trova in /etc/ssh/sshd_config ed alla fine di tutte le modifiche è necessario riavviare il demone ssh.
1 – Disabilitare l’accesso di root
Ho sempre pensato che il collegamento diretto con l’account di root sia una cattiva abitudine, perché
- Attaccanti già conoscono il nome utente, quindi devono solo scoprire la password
- Se l’account è violato tutte la vostra macchina è FUBAR
- Se più di 1 persona amministra quella macchina è meglio usare sudo per tenere traccia di chi fa le cose.
Quindi, per disattivare la connessione diretta di root impostare questa opzione:
PermitRootLogin no |
2 – Abilitare solo alcuni utenti o gruppi
Probabilmente sulla macchina solo pochi utenti devono accedere via ssh, se sono pochi è possibile utilizzare la direttiva:
AllowUsers username |
Questa opzione può essere seguita da un elenco di di nomi utente, separati da spazi. Se specificato, l’accesso è consentito solo per i nomi utente che corrispondono a uno dei nomi indicati. ‘*” e “?” possono essere utilizzati come jolly nei nomi. o se si desidera gestire l’accesso tramite un gruppo è possibile utilizzare un’altra opzione:
AllowGroups groups |
Come sopra, questa opzione può essere seguita da un elenco di nomi di gruppi, separati da spazi. Se specificata, l’accesso è consentito solo agli utenti il cui gruppo primario o gruppo secondario corrisponde a uno dei nomi. “*” E “?” possono essere utilizzati come jolly nei nomi.
Questi 2 direttive sono davvero utili perché non ci si deve preoccupare più dei prodotti che durante l’installazione di creare un nuovo account, magari con una password debole.
3 – Cambiare la porta standard
Un’altra norma di sicurezza è quella di cambiare la porta di default, cioè la 22, visto che la maggior parte dei tool automatici eseguono gli attacchi di tipo Brute Force o Dictionary Attacks proprio su questa porta.
E’ consigliabile usare una porta superiore alla 1024, perchè i tools di solito scansionano le prime 1024 porte, diciamo ad esempio la 2222.
Modifichiamo quindi la direttiva ed invece di 22 mettiamo 2222:
Port 2222 |
Ora per la connessione al tuoserver.com con il vostro client ssh è necessario specificare la porta, questo è fatto facilmente aggiungendo l’opzione -p al cliente openssh:
ssh -p 2222 yourserver.com |
Conclusioni
E questo è tutto, come potete vedere questi sono veramente 3 semplici passaggi, ma renderanno più sicuro il server dagli attacchi più comuni.
Popular Posts:
- Nightingale un bellissimo riproduttore audio per Linux
- Livarp – Una distribuzione Linux molto leggera
- (English) Linux shell: Dfc – Check your disk space with style
- Come convertire facilmente i Video di Youtube ad MP3 su GNU/Linux
- 5 Visualizzatori di fumetti per Linux
Find me on Google+
4th should be edit hosts.allow
Do you really need to allow the whole planet to connect?
On my Mom’s ssh server only hosts allowed are connections from my ISP (US – small phone cooperative). Even though her router only works with port 22 all attempts to connect but mine have seen “connnection refused”. Even if your ISP is a big US company this would drop all South America, Africa, Europe, Asia connection attempts.
hosts.deny of course is ALL:ALL
I suggest to disable password authentication and use only public keys auth so you don’t have to bother for weak passwords, brute force attacks or someone looking from your back.
You forgot about using private-public keys and disabling password login. I’ve never heard a single report of anyone brute-forcing a public/private key, but passwords are brute-forced daily.