SSH. Lo sappiamo. Ci piace. Dobbiamo usarlo.
Ti guiderò attraverso otto passaggi per aiutarti a proteggere meglio il servizio SSH sulla tua rete. Penso che tutti apprezziamo l'importanza di SSH. Ci consente di connetterci da e verso dispositivi Linux, server Unix, dispositivi di rete e talvolta anche box Windows. Non cercherò di venderti su quanto spesso viene utilizzato SSH o quanto sia importante. Fornirò una solida lista di controllo che puoi utilizzare per assicurarti che i servizi SSH nel tuo ambiente siano bloccati.
1. Eseguire il backup del file di configurazione
Innanzitutto, eseguire il backup del file di configurazione prima di apportare modifiche importanti. Questo è un consiglio comune, ma è reale. È facile, richiede solo un momento e ti protegge in caso di errore durante la modifica del file. E chi non ha sbagliato in Vim?
# cp /etc/ssh/sshd_config ~/sshd_config_original Vedi, non è così male.
Sfida:esegui costantemente il backup dei file di configurazione prima di apportare modifiche importanti?
2. Imposta un messaggio banner
Certo, si tratta tanto di requisiti legali quanto di qualsiasi altra cosa, ma ancora una volta, questa impostazione richiede solo un momento. Puoi effettivamente fornire alcune informazioni piuttosto buone anche nei messaggi banner. Per prima cosa, scriveremo il messaggio banner nel /etc/issue.net file utilizzando Vim. Quindi apriremo sshd_config file e digli di utilizzare il contenuto di issue.net come lo stendardo.
# vim /etc/issue.net
Warning! Authorized use only.
This server is the property of MyCompanyName.com [ Potrebbe piacerti anche: Automazione password SSH in Linux con sshpass ]
Ovviamente, vorrai inventare qualcosa di specifico per la tua organizzazione. Rimuovi tutte le informazioni già presenti in issue.net file.
Quindi, chiedi a SSH di utilizzare il messaggio banner. Apri sshd_config file in Vim e trova la riga che legge Banner . Ricordi che puoi usare il carattere barra in avanti nella modalità Comando di Vim per cercare parole chiave in un file, giusto? Ad esempio, /banner
# vim /etc/ssh/sshd_config Trova la riga che dice # nessun percorso banner predefinito , quindi decommenta la riga successiva (dice Banner ).
# no default banner path
Banner /etc/issue.net Salva le modifiche in Vim con :wq e quindi riavvia il servizio SSH:
# systemctl restart sshd Nota:da questo punto in poi non ti ricorderò di riavviare SSH. Ogni volta che apporti una modifica al file di configurazione, devi riavviare il servizio.
Sfida:il messaggio banner è coerente su tutti i dispositivi SSH sulla tua rete?
3. Impedisci password vuote
Sembra un gioco da ragazzi, ma le password vuote sono chiaramente una cattiva idea. Potresti avere altre utilità, come Pluggable Authentication Modules (PAM), che regolano le tue password regolari, ma è anche una buona idea assicurarsi che SSH applichi anche impostazioni di sicurezza responsabili.
Apri il /etc/ssh/sshd_config file in Vim, quindi trova la riga che legge PermitEmptyPasswords . Decommentalo e sostituisci il sì valore con no .
PermitEmptyPasswords no Questo è tutto.
4. Impedisci all'utente root di attraversare la rete tramite SSH
L'idea qui è piuttosto semplice. Invia le credenziali utente standard attraverso la rete anziché le credenziali di root. Dopo aver stabilito la connessione SSH utilizzando un account utente standard, utilizza su o sudo per elevare i tuoi privilegi.
Apri il file di configurazione SSH, quindi decommenta PermitRootLogin linea. Modifica l'impostazione da sì a no .
PermitRootLogin no
Sfida:la tua organizzazione ha adottato sudo , giusto?
5. Inserisci nella whitelist account utente specifici
Se stai già impedendo l'uso dell'account utente root su SSH, perché non fare un ulteriore passo avanti e indicare esplicitamente quali utenti possono connettersi al server? Forse hai un normale account amministratore non root che usi o uno che è già configurato con sudo privilegi.
Nel file di configurazione SSH, aggiungi la seguente riga (non è lì per impostazione predefinita):
AllowUsers user1 Lo metterei vicino a PermitRootLogin no impostazione.
A proposito, puoi effettivamente filtrare con tutte le seguenti impostazioni:AllowUsers , Nega utenti , Consenti gruppi , NegaGruppi . Li ho scritti apposta in quell'ordine:questo è l'ordine in cui vengono elaborati. Puoi scoprire maggiori informazioni sulla pagina man di sshd_config .
Sfida:fai attenzione a chi è autorizzato esattamente.
Nota:puoi limitare le connessioni anche tramite iptables.
6. Niente più porta 22
Un'altra modifica comune consiste nel configurare SSH per l'ascolto su una porta diversa da quella standard 22/tcp che tutti abbiamo memorizzato. C'è già una voce in sshd_config file.
Puoi commentare l'impostazione della porta predefinita e aggiungere un'altra riga, come ho fatto di seguito:
#Run SSH on a non-standard port
#Port 22
Port 2222 Sospetto che molte persone utilizzino 2222 come numero di porta sostitutivo, quindi potresti voler standardizzare qualcosa di un po' più unico.
È necessario ricordare di aggiungere il nuovo numero di porta non standard ai tentativi di connessione SSH da questo momento in poi. Ad esempio:
# ssh -p 2222 [email protected] Sfida:hai lo stesso numero di porta non standard configurato per tutte le tue destinazioni SSH? La coerenza ti semplificherà la vita.
7. Il tempo è scaduto!
Il suggerimento successivo riguarda il timeout delle connessioni. L'IntervalloClientAlive gestisce le connessioni SSH inattive. Il server invia un messaggio al client e attende una risposta. L'IntervalloClientAlive è lo spazio di tempo tra i messaggi. Il ClientAliveCountMax definisce quante volte il server lo farà prima di decidere che il client non è più presente. A quel punto, la connessione viene interrotta.
Ecco un esempio di configurazione che controlla ogni 60 secondi e lo farà tre volte:
ClientAliveInterval 60
ClientAliveCountMax 3 Modifica questi valori in modo che abbia senso per il tuo ambiente.
Nota:se utilizzi SSH per eseguire il tunneling di altre connessioni, potrebbe essere necessario assicurarsi che l'intervallo sia sufficientemente lungo da supportare correttamente qualsiasi altra applicazione lo stia utilizzando.
C'è un ServerAliveInterval valore che puoi configurare anche sul lato client. Ciò consente ai client di interrompere le connessioni ai server SSH che non rispondono.
8. Ecco la chiave
Una delle impostazioni di sicurezza più comuni per SSH al giorno d'oggi è l'autenticazione basata su chiave. Negli anni in cui ho insegnato Linux, questo metodo di autenticazione è diventato sempre più comune. In effetti, non tenterei un esame di amministratore di Red Hat senza sentirmi sicuro di questo processo. Fortunatamente non è difficile.
Facciamo una rapida rassegna. L'autenticazione basata su chiave utilizza la crittografia asimmetrica. Ciò significa che ci sono due chiavi, diverse ma matematicamente correlate tra loro. Uno è privato e non viene mai inviato attraverso la rete. L'altro è pubblico e può essere trasferito attraverso la rete. Poiché le chiavi sono correlate, possono essere utilizzate per confermare le identità, come i tentativi di autenticazione SSH.
Dovrai generare la coppia di chiavi sul computer client SSH locale e quindi trasferire la chiave pubblica attraverso la rete al server SSH di destinazione. In altre parole, le chiavi ti identificheranno sulla tua workstation di amministrazione. Una volta che questa configurazione è a posto, non ti viene più richiesta una password quando stabilisci una connessione SSH.
Il processo richiede solo pochi passaggi.
Innanzitutto, genera la coppia di chiavi:
# ssh-keygen
Le chiavi sono memorizzate nella tua home directory in una directory nascosta denominata .ssh e i nomi delle chiavi predefiniti sono id_rsa (chiave privata) e id_rsa.pub (chiave pubblica).
Successivamente, invia la chiave pubblica user1 attraverso la rete al server SSH di destinazione situato in 10.1.0.42:
# ssh-copy-id [email protected] Infine, prova la connessione:
# ssh [email protected] Nota che non ti viene richiesta una password.
Poiché ora hai adottato l'autenticazione basata su chiave, puoi modificare sshd_config file per impedire qualsiasi accesso basato su password. Dopo aver configurato questa impostazione, verrà accettata solo l'autenticazione basata su chiave.
Modifica queste due righe nel file:
PasswordAuthentication no
PublicKeyAuthentication yes [ Vuoi saperne di più sulla sicurezza? Consulta la checklist di sicurezza e conformità IT. ]
Concludi
Ho elencato diverse configurazioni SSH comuni ma efficaci per aiutarti a proteggere meglio il tuo ambiente. Ricorda, con la sicurezza, è probabile che nessuna impostazione protegga i tuoi dispositivi. L'obiettivo sono i livelli di sicurezza, la cui combinazione aiuta a mitigare le minacce alla sicurezza. Consiglio vivamente di organizzare con cura le chiavi se si implementa l'autenticazione basata su chiavi. Potresti anche considerare l'utilizzo di un /etc/ssh/sshd_config centralizzato per mantenere le configurazioni di sicurezza coerenti sui server SSH. Non dimenticare di riavviare SSH ogni volta che modifichi il file di configurazione.