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

Mi piacerebbe poter accedere a SSH sul mio PC da ufficio Ubuntu 10.04 dall'esterno. Sto quindi pensando di avviare un demone SSH sul PC. Quali sono i problemi di sicurezza, possibili anomalie, impostazioni di configurazione specifiche, ecc. Di cui dovrei essere a conoscenza?

Nel caso sia importante: questo è essenzialmente solo per mio uso personale, non credo che ci saranno altre persone che lo usano; è un PC Ubuntu 10.04 in un ambiente prevalentemente Windows 7 / Vista / XP.

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

Ci sono diverse misure di sicurezza che puoi prendere, di seguito alcune di quelle che prendo sempre quando installo un server SSH e altre.

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

2. Porta gli utenti nella loro home directory. Gli utenti imprigionati non saranno in grado di accedere / modificare i file che si trovano al di fuori della loro home directory. Pertanto, l'utente non sarà in grado di accedere / modificare i file di sistema chiave. Molti tutorial sono disponibili online su come imprigionare un utente. Molti di loro usano JailKit . Un esempio di tale tutorial può essere trovato qui . In alternativa, puoi anche usare la ChrootDirectorydirettiva nativa del server OpenSSH . Un esempio di tutorial su questo può essere trovato qui .

3. Installa Fail2Ban . Fail2Ban è un programma che verifica la presenza di voci errate nei registri di autenticazione. Quando viene raggiunto un certo limite, viene aggiunto un blocco firewall per quel determinato IP per un periodo di tempo prestabilito. Ci sono anche diversi tutorial online trovati su come impostare Fail2Ban con SSH, un esempio potrebbe essere questo . La homepage di Fail2Ban contiene anche alcuni HOWTO completi e gradevoli.

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

   #PermitRootLogin no
   

5. Utilizzare una porta non standard (ad es. Non 22) Questo avviene tramite il port forwarding nel router (ad es. 16121 -> 22 anziché 22 -> 22) o facendo ascoltare il daemon SSH su una porta diversa. Ciò renderà il servizio SSH meno facilmente rilevabile per gli utenti malintenzionati. Questo viene fatto modificando il file /etc/ssh/sshd_config. ^✝ Cerca la seguente riga e cambia 22 in qualunque porta desideri. Non dimenticare di inoltrare la porta corretta nel router in seguito.

   Port 22
   

6. Non utilizzare le password per accedere. Oltre alle password, SSH consente anche l'accesso mediante l'uso di chiavi private. Ciò significa che sul computer è memorizzata una chiave su cui si accede a SSH della macchina SSH. Quando viene tentata una connessione, il client SSH utilizza la chiave per accedere al server anziché tramite l'autenticazione con password. Le chiavi di autenticazione sono molto più crittograficamente crittografiche delle password e quindi non sono così facili da decifrare. Ci sono anche diversi tutorial online trovati su come impostare l'autenticazione basata su chiave con SSH, un esempio potrebbe essere questo . (Se si SSH da Windows con PuTTY, controllare questo collegamento per un howto PuTTY.) Dopo aver impostato l'autenticazione basata su chiave, è possibile disabilitare l'autenticazione della password modificando il file /etc/ssh/sshd_config. ^✝ Cerca la seguente riga e assicurati che non ci siano # 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.denye aggiungendo quanto segue:

   sshd: ALL
   

   e /etc/hosts.allowaggiungere quanto segue:

   sshd: 192.168.1.*
   

   dove l'IP corrisponde a quello della rete locale. *è un carattere jolly, quindi 192.168.1.verranno accettati tutti gli indirizzi IP che iniziano con . Se questo non funziona, la tua distribuzione potrebbe usare al sshposto di sshd. In tal caso, dovresti provare ssh: 192.168.1.*e ssh: ALLinvece.

8. È possibile consentire solo host specifici, fare lo stesso con /etc/hosts.allowe /etc/hosts.denycome descritto in 6, ma /etc/hosts.allowaggiungere la seguente riga e ogni host per consentire separati 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 seguente riga e assicurati che non ci siano # davanti. Se non esiste, crealo. Ad esempio, se si desidera consentire solo john, tom e mary, aggiungere / modificare questa riga:

   AllowUsers john tom mary
   

   Ad esempio, potresti anche negare utenti specifici, se desideri 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 l'utilizzo di SSH 2. Questo può essere forzato modificando il file /etc/ssh/sshd_config. ^✝ Cerca la seguente riga e assicurati che non ci siano # davanti. Se non esiste, crealo.

    Protocol 2,1
    

    rimuovere il, 1 in modo che la linea sarà

    Protocol 2
    

11. Non consentire agli utenti di accedere senza password impostata. Questo può essere forzato modificando il file /etc/ssh/sshd_config. ^✝ Cerca la seguente riga e assicurati che non ci siano # davanti. Se non esiste, crealo.

    PermitEmptyPasswords no
    

12. E sebbene sia 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 che stai utilizzando.

Alcuni consigli:

1. Utilizzare l'autenticazione basata su chiave, che è MODO più sicura delle password
2. Solo SSH 2
3. Disabilita gli accessi root
4. Per il paranoico, cambiare la porta dalla porta standard 22
5. Per comodità, usa uno strumento per mappare il tuo IP su un nome DNS, come Dyndns o il suo simile. Puoi passare molto tempo con lo stesso IP, ma quella volta che viaggi e ne hai bisogno, scoprirai che ne è stato rilasciato uno nuovo.
6. Ovviamente, consenti solo la porta necessaria per SSH (porta 22 o non standard se lo desideri) attraverso il tuo firewall.

Il rischio principale è dimenticare che si sta eseguendo un server SSH e mettere una password debole su un account. Esistono aggressori che cercano sistematicamente nomi di account comuni (come webmastere bob) e password deboli. È possibile eliminare questo rischio vietando login senza password (messo PasswordAuthentication noin sshd_config, e sia anche mettere UsePAM Noo autenticazione della password disabilita nelle impostazioni PAM per ssh). Una misura intermedia è limitare gli accessi ssh a una whitelist di utenti con AllowUserso AllowGroupsin sshd_config.

Si noti che consentire l'accesso con password non è di per sé un problema di sicurezza. Le password deboli e le password ficcate sono i problemi e consentire l'autenticazione delle password nel server ssh è un fattore abilitante. Per proteggerti dallo snooping delle password, non digitare mai la 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 con password).

Il requisito minimo per utilizzare un client ssh su una macchina è che ti fidi che non ci sarà un dirottamento attivo della comunicazione ssh (un attacco man-in-the-middle è possibile se è in esecuzione sulla macchina client - pensi stai digitando i comandi in un client SSH incontaminato, ma il client sta effettivamente trasmettendo fedelmente i tuoi dati di autenticazione ma successivamente inserendo un cavallo di Troia nella comunicazione). Questo è un requisito più debole rispetto alla fiducia che non ci sarà uno snooper password (di solito eseguito tramite un keylogger, ma ci sono altri metodi meno automatizzati come la navigazione sulle spalle). Se hai la minima fiducia ma temi ancora i ficcanaso, puoi usare le password una tantum (OpenSSH le supporta attraverso il suo supporto PAM).

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

Mi sono venute in mente tre cose:

1. Se apri la porta predefinita 22, molto presto verrà rilevata e il tuo PC verrà martellato da attacchi di forza bruta. Ti consiglio di configurare sshd per ascoltare qualche altra porta o fare il port mapping sul tuo firewall. Anche se questo non è un proiettile magico, ti farà risparmiare almeno gli stessi cicli della CPU.

   Porta 12345

2. Disabilita esplicitamente l'autenticazione con password e usa solo le chiavi. Qualsiasi chiave sarà migliore della password più complessa che ricordi.

   Password autenticazione n

3. Anche se Ubuntu ha l'utente root disabilitato per impostazione predefinita, disabilita esplicitamente l'accesso root

   PermitRootLogin no