Quali sono i possibili problemi di sicurezza con un demone SSH?

La preoccupazione maggiore sarebbe che le persone accedano come amministratore del computer tramite SSH. Questo può essere fatto con la forza bruta se hai una password facile da indovinare.

Esistono diverse misure di sicurezza che puoi adottare, di seguito sono riportate alcune di quelle che prendo sempre durante la configurazione di un server SSH e alcune extra.

1. Usa una password complessa, composta da almeno (diciamo) 10 lettere maiuscole e minuscole, numeri e altri caratteri.

2. Incarcera gli utenti nella loro home directory. Gli utenti incarcerati non saranno in grado di accedere/modificare i file che si trovano al di fuori della loro home directory. Quindi il tuo utente non sarà in grado di accedere/modificare i file di sistema chiave. Online si possono trovare molti tutorial su come imprigionare un utente. La maggior parte di loro usa JailKit. Un esempio di tale tutorial può essere trovato qui. In alternativa, puoi anche usare ChrootDirectory nativo del server OpenSSH direttiva. Un esempio di tutorial su questo può essere trovato qui.

3. Installa Fail2Ban. Fail2Ban è un programma che controlla i log di autenticazione per voci errate. Quando viene raggiunto un certo limite, aggiunge un blocco firewall per quel determinato IP per un periodo di tempo prestabilito. Ci sono anche diversi tutorial online trovati online su come configurare Fail2Ban con SSH, un esempio potrebbe essere questo. La homepage di Fail2Ban contiene anche alcuni HOWTO carini e completi.

4. Disabilita l'accesso root tramite SSH. Questo è l'utente che ha accesso praticamente a tutti i file sul tuo sistema, quindi si consiglia di disabilitare il suo login di shell. Nelle ultime versioni di Ubuntu, l'utente root è automaticamente disabilitato ma non fa male disabilitare comunque il suo accesso SSH. Questo viene fatto modificando il file /etc/ssh/sshd_config . Cerca la seguente riga e assicurati che non ci sia # davanti.

   #PermitRootLogin no
   

5. Usa una porta non standard (ad esempio non 22) Questo viene fatto tramite il port forwarding nel tuo router (ad esempio 16121 -> 22 invece di 22 -> 22) o facendo ascoltare il demone SSH su una porta diversa. Ciò renderà il tuo servizio SSH meno facilmente rilevabile da utenti malintenzionati. Questo viene fatto modificando il file /etc/ssh/sshd_config . Cerca la seguente riga e cambia 22 in qualsiasi porta desideri. Non dimenticare di inoltrare la porta corretta nel tuo router in seguito.

   Port 22
   

6. Non utilizzare password per accedere. Oltre alle password, SSH consente anche l'accesso tramite l'uso di chiavi private. Ciò significa che una chiave è memorizzata sul tuo computer su cui accedi all'SSH della macchina SSH. Quando viene tentata una connessione, il client SSH utilizza la chiave per accedere al server anziché tramite l'autenticazione della password. Le chiavi di autenticazione sono crittograficamente molto più solide rispetto alle password e quindi non così facili da decifrare. Ci sono anche diversi tutorial online trovati online su come impostare l'autenticazione basata su chiave con SSH, un esempio potrebbe essere questo. (Se usi SSH da Windows con PuTTY, controlla questo link per una guida su PuTTY.) Dopo aver impostato l'autenticazione basata su chiave, puoi disabilitare l'autenticazione della password modificando il file /etc/ssh/sshd_config . Cerca la seguente riga e assicurati che non ci sia # davanti.

   #PasswordAuthentication no
   

7. Facoltativamente, come menzionato da @ Linker3000 nel suo commento, è possibile impostare un tunnel VPN sul PC a cui si desidera accedere tramite SSH e quindi impedire l'accesso alla rete non locale sul server SSH. In questo modo, nessun dispositivo esterno senza una connessione VPN sarà in grado di accedere al tuo server SSH. Questo può essere fatto negando TUTTI gli host e quindi consentendo l'accesso solo agli IP della rete locale. Questo viene fatto modificando /etc/hosts.deny e aggiungi quanto segue:

   sshd: ALL
   

   e a /etc/hosts.allow aggiungere quanto segue:

   sshd: 192.168.1.*
   

   dove l'IP corrisponde a quello della tua rete locale. * è un carattere jolly, quindi tutti gli indirizzi IP iniziano con 192.168.1. sarà accettato. Se questo non funziona, la tua distribuzione potrebbe usare ssh invece di sshd . In tal caso, dovresti provare ssh: 192.168.1.* e ssh: ALL invece.

8. Puoi consentire solo host specifici, fai lo stesso con /etc/hosts.allow e /etc/hosts.deny come descritto in 6, ma in /etc/hosts.allow aggiungi la riga seguente e ogni host da consentire separato da spazi:

   sshd: {IP OF HOST TO ALLOW 1} {IP OF HOST TO ALLOW 2} {IP OF HOST TO ALLOW 3} {ETC.}
   

9. Consenti solo a utenti specifici di accedere al tuo server SSH. Questo viene fatto modificando il file /etc/ssh/sshd_config . Cerca la riga seguente e assicurati che non ci sia # davanti. Se non esiste, crealo. Ad esempio, se vuoi consentire solo john, tom e mary, aggiungi/modifica questa riga:

   AllowUsers john tom mary
   

   Puoi anche negare utenti specifici, ad esempio, se vuoi negare l'accesso a john, tom e mary, aggiungi/modifica questa riga:

   DenyUsers john tom mary
   

10. Consenti solo il protocollo SSH2 per le connessioni in entrata. Esistono due versioni del protocollo SSH. SSH1 è soggetto a problemi di sicurezza, quindi si consiglia di utilizzare SSH 2. Questo può essere forzato modificando il file /etc/ssh/sshd_config . Cerca la riga seguente e assicurati che non ci sia # davanti. Se non esiste, crealo.

    Protocol 2,1
    

    rimuovi ,1 così la linea sarà

    Protocol 2
    

11. Non consentire l'accesso agli utenti che non hanno una password impostata. Questo può essere forzato modificando il file /etc/ssh/sshd_config . Cerca la riga seguente e assicurati che non ci sia # davanti. Se non esiste, crealo.

    PermitEmptyPasswords no
    

12. E sebbene semplice e forse inutile dirlo ma dimostrato cruciale in più casi, mantieni aggiornato il tuo software. Aggiorna regolarmente i pacchetti/software installati.

=dopo aver modificato il file di configurazione SSH, non dimenticare di riavviare il demone per applicare le modifiche. Riavvia il demone eseguendo:

sudo /etc/init.d/ssh restart

o

sudo /etc/init.d/sshd restart

a seconda della distribuzione di Linux in uso.

Alcuni consigli:

1. Utilizza l'autenticazione basata su chiave, che è MOLTO più sicura delle password
2. Solo SSH 2
3. Disattiva gli accessi root
4. Per i paranoici, cambia la porta dalla porta standard 22
5. Per comodità, usa uno strumento per mappare il tuo IP a un nome DNS, come Dyndns o simili. Puoi andare avanti per molto tempo con lo stesso IP, ma una volta che sei in viaggio e ne hai bisogno, scoprirai che ne hai rilasciato uno nuovo.
6. Naturalmente, consenti solo la porta necessaria per SSH (porta 22 o una non standard se lo desideri) attraverso il tuo firewall.

Il rischio principale è dimenticare che stai eseguendo un server ssh e inserire una password debole su un account. Esistono utenti malintenzionati che tentano sistematicamente nomi di account comuni (come webmaster e bob ) e password deboli. Puoi eliminare questo rischio vietando gli accessi con password (inserisci PasswordAuthentication no in sshd_config , e inserisci anche UsePAM No o disabilitare l'autenticazione della password nelle impostazioni PAM per ssh). Una misura intermedia consiste nel limitare gli accessi ssh a una lista bianca di utenti con AllowUsers o AllowGroups in sshd_config .

Si noti che consentire l'accesso tramite password non è di per sé un problema di sicurezza. Le password deboli e le password snooped sono i problemi e consentire l'autenticazione della password nel server ssh è un fattore abilitante. Per proteggerti dallo spionaggio delle password, non digitare mai la tua password su una macchina di cui non ti fidi completamente (ma se ti fidi di una macchina potresti anche installare una chiave privata su di essa, e quindi non hai bisogno dell'autenticazione della password).

Il requisito minimo per usare un client ssh su una macchina è che tu abbia fiducia che non ci sarà un dirottamento attivo della comunicazione ssh (è possibile un attacco man-in-the-middle se è in esecuzione sulla macchina client - pensi stai digitando i comandi in un client ssh incontaminato ma il client in realtà trasmette fedelmente i tuoi dati di autenticazione ma successivamente inserisce anche un cavallo di troia nella comunicazione). Questo è un requisito più debole rispetto alla fiducia che non ci sarà un ficcanaso di password (di solito eseguito tramite un keylogger, ma ci sono altri metodi meno automatizzati come lo shoulder surfing). Se hai un minimo di fiducia ma temi ancora i ficcanaso, puoi utilizzare password monouso (OpenSSH le supporta tramite il suo supporto PAM).

Ovviamente, come qualsiasi altro programma che interagisce con macchine al di fuori del tuo controllo (non solo server di rete ma anche client), devi stare al passo con gli aggiornamenti di sicurezza.