Come indurire un server SSH?

Quali misure posso / dovrei prendere per assicurarmi che la sicurezza attorno al mio server SSH sia assolutamente impermeabile?

Questa sarà la wiki della comunità fin dall'inizio, quindi vediamo cosa fanno le persone per proteggere i loro server.

Utilizzare le coppie di chiavi pubbliche / private per l'autenticazione anziché le password.

1. Genera una chiave SSH protetta da passphrase per ogni computer che deve accedere al server:

   ssh-keygen

2. Consentire l'accesso SSH a chiave pubblica dai computer consentiti:

   Copia il contenuto di ~/.ssh/id_rsa.pubogni computer in singole righe del ~/.ssh/authorized_keysserver o eseguilo ssh-copy-id [server IP address]su tutti i computer a cui stai concedendo l'accesso (dovrai inserire la password del server al prompt).

3. Disabilita accesso SSH password:

   Apri /etc/ssh/sshd_config, trova la riga che dice #PasswordAuthentication yese modificala in PasswordAuthentication no. Riavviare il demone del server SSH per applicare il change ( sudo service ssh restart).

Ora, l'unico modo possibile per SSH nel server è usare una chiave che corrisponda a una linea ~/.ssh/authorized_keys. Utilizzando questo metodo, io non mi preoccupo di attacchi di forza bruta, perché anche se indovinare la password, sarà rifiutato. La forzatura bruta di una coppia di chiavi pubblica / privata è impossibile con la tecnologia di oggi.

Suggerirei:

• Utilizzo di fail2ban per impedire tentativi di accesso con forza bruta.

• Disabilitazione dell'accesso come root tramite SSH. Ciò significa che un utente malintenzionato ha dovuto capire sia il nome utente che la password rendendo un attacco più difficile.

  Aggiungi PermitRootLogin noal tuo /etc/ssh/sshd_config.

• Limitare gli utenti che possono SSH al server. O per gruppo o solo utenti specifici.

  Aggiungi AllowGroups group1 group2o AllowUsers user1 user2limita chi può SSH sul server.

Altre risposte forniscono sicurezza, ma c'è una cosa che puoi fare che renderà i tuoi registri più silenziosi e renderà meno probabile che sarai bloccato dal tuo account:

Spostare il server dalla porta 22 a un'altra. O sul tuo gateway o sul server.

Non aumenta la sicurezza, ma significa che tutti gli scanner casuali di Internet non ingombreranno i tuoi file di registro.

Abilita l'autenticazione a due fattori con HOTP o TOTP . Questo è disponibile dal 13.10 in poi.

Ciò include l'uso dell'autenticazione con chiave pubblica rispetto all'autenticazione tramite password come in un'altra risposta qui, ma richiede anche all'utente di provare di possedere il suo dispositivo di secondo fattore oltre alla sua chiave privata.

Sommario:

1. sudo apt-get install libpam-google-authenticator

2. Chiedi a ciascun utente di eseguire il google-authenticatorcomando, che genera ~/.google-authenticatore aiuta a configurare i dispositivi a due fattori (ad es. L'app Android Google Authenticator).

3. Modifica /etc/ssh/sshd_confige imposta:

   ChallengeResponseAuthentication yes
   PasswordAuthentication no
   AuthenticationMethods publickey,keyboard-interactive
   

4. Esegui sudo service ssh reloadper ritirare le modifiche a /etc/ssh/sshd_config.

5. Modifica /etc/pam.d/sshde sostituisci la riga:

   @include common-auth
   

   con:

   auth required pam_google_authenticator.so
   

Maggiori dettagli su diverse opzioni di configurazione sono il mio post sul blog dello scorso anno: migliore autenticazione ssh a due fattori su Ubuntu .

Rendere gli IP del client sshd block che non sono riusciti a fornire le informazioni di accesso corrette " DenyHØsts " può svolgere questo lavoro in modo abbastanza efficace. L'ho installato su tutti i miei box Linux che sono in qualche modo raggiungibili dall'esterno.

Questo farà in modo che gli attacchi di forza sull'SSHD non siano efficaci, ma ricorda (!) In questo modo puoi finire per bloccarti se dimentichi la password. Questo può essere un problema su un server remoto a cui non hai accesso.

Ecco una cosa semplice da fare: installare ufw (il "firewall semplice") e usarlo per limitare le connessioni in entrata.

Da un prompt dei comandi, digitare:

$ sudo ufw limit OpenSSH 

Se ufw non è installato, farlo e riprovare:

$ sudo aptitude install ufw 

Molti aggressori cercheranno di utilizzare il server SSH per le password a forza bruta. Ciò consentirà solo 6 connessioni ogni 30 secondi dallo stesso indirizzo IP.

Se voglio avere un po 'di sicurezza in più o devo accedere ai server SSH in profondità all'interno di una rete aziendale, installo un servizio nascosto usando il software di anonimizzazione Tor .

1. Installa Tor e configura il server SSH stesso.
2. Assicurati che sshd ascolti solo localhost.
3. Aprire /etc/tor/torrc. Imposta HiddenServiceDir /var/lib/tor/sshe HiddenServicePort 22 127.0.0.1:22.
4. Guarda var/lib/tor/ssh/hostname. C'è un nome come d6frsudqtx123vxf.onion. Questo è l'indirizzo del servizio nascosto.

5. Apri $HOME/.ssh/confige aggiungi alcune righe:

   Host myhost
   HostName d6frsudqtx123vxf.onion
   ProxyCommand socat STDIO SOCKS4A:127.0.0.1:%h:%p,socksport=9050
   

Inoltre ho bisogno di Tor sul mio host locale. Se è installato, posso accedere ssh myhoste SSH apre una connessione tramite Tor. Il server SSH dall'altra parte apre la sua porta solo su localhost. Quindi nessuno può collegarlo tramite "Internet normale".

C'è un articolo di Debian Administration su questo argomento. Copre la configurazione di base del server SSH e anche le regole del firewall. Questo potrebbe essere interessante anche per rafforzare un server SSH.

Vedi l'articolo qui: Protezione dell'accesso SSH .

Il mio approccio all'indurimento SSH è ... complesso. I seguenti elementi sono in termini di come lo faccio, dal bordo più esterno della mia rete (s) ai server stessi.

1. Filtraggio a livello di frontiera del traffico tramite IDS / IPS con scanner e firme di servizi noti nella block list. Lo raggiungo con Snort tramite il mio firewall di confine (questo è il mio approccio, un'appliance pfSense). A volte, tuttavia, non posso farlo, ad esempio con i miei VPS.

2. Filtro firewall / rete delle porte SSH. Autorizzo esplicitamente solo alcuni sistemi a raggiungere i miei server SSH. Questo viene fatto tramite un firewall pfSense al confine della mia rete, oppure i firewall su ciascun server vengono esplicitamente configurati. Ci sono casi in cui non riesco a farlo, tuttavia (il che non è quasi mai il caso, tranne che in ambienti privati ​​di test con penna o test di sicurezza in cui i firewall non aiutano a testare le cose).

3. In combinazione con my pfSense, o un firewall di confine NAT, che collega la rete interna e si separa da Internet e dai sistemi, l' accesso ai server solo VPN . Devo VPN nelle mie reti per accedere ai server, perché non ci sono porte rivolte a Internet in quanto tali. Questo sicuramente non funziona per tutti i miei VPS, ma in combinazione con il n. 2, posso avere un VPS come "gateway" tramite VPN su quel server e quindi consentire i suoi IP alle altre caselle. In questo modo, so esattamente cosa può o non può essere SSH - la mia unica casella che è la VPN. (Oppure, nella mia rete domestica dietro pfSense, la mia connessione VPN e sono l'unico con accesso VPN).

4. Laddove il n. 3 non è possibile, fail2ban, configurato per bloccare dopo 4 tentativi falliti e bloccare gli IP per un'ora o più è una protezione decente contro le persone che attaccano costantemente con il bruteforcing: basta bloccarli automaticamente sul firewall con fail2ban e meh. Configurare fail2ban è una seccatura però ...

5. Offuscamento della porta modificando la porta SSH. Tuttavia, questa NON è una buona idea da fare senza ulteriori misure di sicurezza : il mantra di "Sicurezza attraverso l'oscurità" è già stato confutato e contestato in molti molti casi. L'ho fatto insieme a IDS / IPS e al filtro di rete, ma è ancora MOLTO scarso da fare da solo.

6. Autenticazione a due fattori OBBLIGATORIA, tramite le soluzioni di autenticazione a due fattori di Duo Security . Ognuno dei miei server SSH ha Duo configurato su di esso, in modo tale che, anche per entrare, avvengano i messaggi 2FA e devo confermare ogni accesso. (Questa è la massima funzionalità utile - perché anche se qualcuno ha la mia passphrase o si rompe, non può superare i plugin Duo PAM). Questa è una delle maggiori protezioni sui miei server SSH dall'accesso non autorizzato: ogni accesso utente DEVE ricollegarsi a un utente configurato in Duo e poiché ho un set restrittivo, nessun nuovo utente può essere registrato nel sistema.

I miei due centesimi per proteggere SSH. O almeno i miei pensieri sull'approccio.

Potresti voler controllare l'app FreeOTP da RedHat invece di utilizzare Google Authenticator. A volte durante l'aggiornamento dell'app, ti bloccano! ;-)

Se si desidera utilizzare altri token hardware come Yubikey o eToken PASS o NG o se si hanno molti utenti o molti server, è possibile utilizzare un back-end di autenticazione a due fattori opensource.

Ultimamente ho scritto un howto su questo .

Ho scritto un piccolo tutorial su come farlo di recente. Fondamentalmente, è necessario utilizzare PKI e il mio tutorial mostra anche come utilizzare l'autenticazione a due fattori per una sicurezza ancora maggiore. Anche se non usi nessuna di queste cose, ci sono anche alcuni suggerimenti su come proteggere il server rimuovendo le suite di cifratura deboli e altre basi. https://joscor.com/blog/hardening-openssh-server-ubuntu-14-04/

Per un gran numero di utenti / certificati considerare l'integrazione LDAP. Le grandi organizzazioni utilizzano LDAP come repository per le credenziali utente e i certificati archiviati su badge o portamonete, indipendentemente dal fatto che i certificati vengano utilizzati per l'autenticazione o la firma di e-mail. Gli esempi includono openLDAP, openDJ, Active Directory, Oracle Universal Directory, IBM Directory Server, snareWorks ...

Computer e gruppi possono anche essere gestiti in LDAP fornendo una gestione delle credenziali centralizzata. In questo modo i banchi di assistenza possono avere uno sportello unico per gestire grandi popolazioni.

Ecco un link per l'integrazione di centOS: http://itdavid.blogspot.com/2013/11/howto-configure-openssh-to-fetch-public.html

È inoltre possibile bloccare in base al paese di origine utilizzando il database geoIP.

Fondamentalmente se vivi negli Stati Uniti, non c'è motivo per qualcuno in Russia di connettersi al tuo SSH, quindi verranno automaticamente bloccati.

Lo script può essere trovato qui: https://www.axllent.org/docs/view/ssh-geoip/

Puoi anche aggiungere i comandi iptables (l'ho fatto per i miei droplet) per eliminare automaticamente tutto il traffico verso / da quegli IP.