it-swarm.it

Come indurire un server SSH?

Quali misure posso/dovrei prendere per assicurarmi che la sicurezza intorno 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.

128
LassePoulsen

Rendere gli IP del client sshd block che non sono riusciti a fornire le informazioni di accesso corrette " DenyHØsts " può fare 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.

21
LassePoulsen

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.pub da ciascun computer in singole righe di ~/.ssh/authorized_keys sul server o esegui ssh-copy-id [server IP address] su tutti i computer a cui stai concedendo l'accesso (dovrai accedere al server password al prompt).

  3. Disabilita accesso SSH password:

    Apri /etc/ssh/sshd_config, trova la riga che dice #PasswordAuthentication yes e cambiala in PasswordAuthentication no. Riavviare il daemon del server SSH per applicare la modifica (Sudo service ssh restart).

Ora, l'unico modo possibile per accedere a SSH nel server è utilizzare una chiave che corrisponda a una riga in ~/.ssh/authorized_keys. Usando questo metodo, I non si preoccupa degli attacchi di forza bruta perché anche se indovinano la mia password, verrà rifiutata. È impossibile forzare brutalmente una coppia di chiavi pubblica/privata con la tecnologia di oggi.

108
Asa Ayers

Suggerirei:

  • Utilizzo di fail2ban per impedire tentativi di accesso alla 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 no a /etc/ssh/sshd_config.

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

    Aggiungi AllowGroups group1 group2 o AllowUsers user1 user2 per limitare chi può SSH al server.

72
Mark Davidson

Altre risposte forniscono sicurezza, ma c'è una cosa che puoi fare che renderà più silenziosi i tuoi registri 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.

24
Douglas Leeder

Abilitare 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 tramite autenticazione con 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 comando google-authenticator, che genera ~/.google-authenticator e li aiuta a configurare i dispositivi a due fattori (ad es. L'app Google Authenticator Android).

  3. Modifica /etc/ssh/sshd_config e imposta:

    ChallengeResponseAuthentication yes
    PasswordAuthentication no
    AuthenticationMethods publickey,keyboard-interactive
    
  4. Esegui Sudo service ssh reload per confermare le modifiche a /etc/ssh/sshd_config.

  5. Modifica /etc/pam.d/sshd e 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 Ubunt .

23
Robie Basak

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

Da un prompt dei comandi, digitare:

$ Sudo ufw limit OpenSSH 

Se fw non è installato, farlo e riprovare:

$ Sudo aptitude install ufw 

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

20
mpontillo

Se voglio avere un po 'di sicurezza aggiuntiva o ho bisogno di accedere ai server SSH in profondità all'interno di una rete aziendale, imposto 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. Apri /etc/tor/torrc. Impostare HiddenServiceDir /var/lib/tor/ssh e 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/config e 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 inserire ssh myhost e 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".

12
qbi

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 interessare anche un server SSH rinforzato.

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

8
Huygens

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

  1. Filtraggio a livello di confine del traffico tramite IDS/IPS con scanner e firme di servizi noti nella block list. Lo ottengo con Snort tramite il mio firewall di confine (questo è il mio approccio, un apparecchio 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, Accesso solo VPN ai server . 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. Dove # 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 costantemente attaccare 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, NON è una buona idea fare a meno di 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 OBBLIGATORIA a due fattori, tramite 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.

6
Thomas Ward

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 about this .

1
cornelinux

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 all'integrazione di centOS: http://itdavid.blogspot.com/2013/11/howto-configure-openssh-to-fetch-public.html

0
weller1

È 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 comandi iptables (come ho fatto per i miei droplet) per eliminare automaticamente tutto il traffico da/verso quegli IP.

0
Michael A Mike

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 crittografia deboli e altre nozioni di base. https://joscor.com/blog/hardening-openssh-server-ubuntu-14-04/

0
01000101