Come indurire un server SSH?

119

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.

    
posta LassePoulsen 30.01.2015 - 17:27

13 risposte

21

Rendi gli IP del blocco client sshd 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 tutte le mie scatole Linux che sono in qualche modo raggiungibili dal grande esterno.

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

    
risposta data LassePoulsen 10.06.2016 - 23:17
100

Utilizza 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 ogni computer in singole righe di ~/.ssh/authorized_keys sul server, oppure esegui ssh-copy-id [server IP address] su ogni computer a cui stai concedendo l'accesso (dovrai inserire la password del server al pronta).

  3. Disabilita l'accesso SSH della 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 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 indovina la mia password, sarà respinta. L'uso forzato di una coppia di chiavi pubblica / privata è impossibile con la tecnologia di oggi.

    
risposta data Evan Kroske 08.06.2016 - 02:31
67

Suggerirei:

  • Utilizzare fail2ban per impedire tentativi di accesso a forza bruta.

  • Disabilitare il login come root tramite SSH. Ciò significa che un utente malintenzionato doveva capire sia il nome utente che la password rendendo più difficile un attacco.

    Aggiungi PermitRootLogin no al tuo /etc/ssh/sshd_config .

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

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

risposta data Mark Davidson 08.06.2016 - 02:07
22

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 fuori dal tuo account:

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

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

    
risposta data Douglas Leeder 08.06.2016 - 02:15
21

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

Questo include l'uso dell'autenticazione a chiave pubblica tramite l'autenticazione della password come in un'altra risposta qui, ma richiede anche che l'utente dimostri di tenere in mano il suo dispositivo di secondo fattore oltre alla sua chiave privata.

Sommario:

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

  2. Chiedi a ogni utente di eseguire il comando google-authenticator , che genera ~/.google-authenticator e li aiuta a configurare i dispositivi a due fattori (ad esempio l'app Google Authenticator per Android).

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

    ChallengeResponseAuthentication yes
    PasswordAuthentication no
    AuthenticationMethods publickey,keyboard-interactive
    
  4. Esegui sudo service ssh reload per raccogliere le tue modifiche in /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 del blog dello scorso anno: Migliore autenticazione ssh a due fattori su Ubuntu .

    
risposta data Robie Basak 23.05.2017 - 00:29
19

Ecco una cosa semplice da fare: installa ufw (il "firewall non complicato") e usalo per valutare il limite delle connessioni in entrata.

Da un prompt dei comandi, digitare:

$ sudo ufw limit OpenSSH 

Se ufw non è installato, fallo e riprova:

$ sudo aptitude install ufw 

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

    
risposta data mpontillo 15.08.2010 - 00:45
12

Se voglio avere un po 'di sicurezza aggiuntiva o la necessità di accedere ai server SSH in profondità all'interno di qualche rete aziendale ho impostato un nascosto servizio utilizzando il software di anonimizzazione Tor .

  1. Installa Tor e configura il server SSH stesso.
  2. Assicurati che sshd ascolti solo a localhost .
  3. Apri /etc/tor/torrc . Imposta 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 linee:

    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 via Tor. Il server SSH sull'altro lato apre la sua porta solo su localhost. Quindi nessuno può collegarlo tramite "internet normale".

    
risposta data qbi 08.06.2016 - 02:10
8

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

Vedi l'articolo: Mantenimento sicuro dell'accesso SSH .

    
risposta data Huygens 12.10.2010 - 00:35
6

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

  1. Filtraggio del traffico a livello di confine tramite IDS / IPS con noti scanner di servizio e firme nella blocklist. Lo raggiungo con Snort tramite il mio firewall di confine (questo è il mio approccio, un pfSense apparecchio). A volte, però, non posso farlo, ad esempio con i miei VPS.

  2. Firewall / Filtro di rete della / e porta / e SSH. Permetto esplicitamente solo a determinati sistemi di raggiungere i miei server SSH. Questo viene fatto tramite un firewall pfSense al confine della mia rete, oppure i firewall su ogni server sono configurati esplicitamente. In alcuni casi, tuttavia, non riesco a farlo (il che non è quasi mai il caso, ad eccezione degli ambienti privati ​​di test delle penne o di test di sicurezza in cui i firewall non aiutano a testare le cose).

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

  4. Dove # 3 non è fattibile, 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 la bruteforcing - solo blocca automaticamente il firewall con fail2ban e meh. Configurare fail2ban è un dolore però ...

  5. Offuscamento della porta cambiando la porta SSH. Tuttavia, questa NON è una buona idea anche senza misure di sicurezza aggiuntive - il mantra di " La sicurezza attraverso l'oscurità "è già stata confutata e contestata in molti casi. Ho fatto questo in congiunzione con IDS / IPS e filtro di rete, ma è ancora una cosa MOLTO povera da fare da solo.

  6. Autenticazione a due fattori OBBLIGATORIA, tramite Soluzioni di autenticazione a due fattori di Duo Security . Ogni singolo dei miei server SSH è stato configurato su Duo, in modo tale che, al fine di entrare, i messaggi 2FA si verificano e devo confermare ogni accesso. (Questa è l'ultima funzione utile, perché anche se qualcuno ha la mia passphrase o interviene, non possono superare i plugin Duo PAM). Questa è una delle maggiori protezioni sui miei server SSH da accessi non autorizzati: ogni accesso utente DEVE legarsi a un utente configurato in Duo e, poiché ho un set restrittivo, non è possibile registrare nuovi utenti nel sistema.

I miei due centesimi per la sicurezza di SSH. O, almeno, i miei pensieri sull'approccio.

    
risposta data Thomas W. 10.06.2016 - 23:14
1

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

Se vuoi usare altri token hardware come un Yubikey o un eToken PASS o NG o se hai molti utenti o molti server, potresti voler utilizzare un backend di autenticazione a due fattori opensource.

Ultimamente ho scritto un howto su questo .

    
risposta data cornelinux 08.06.2016 - 02:12
0

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 nessuno di questi elementi, ci sono anche alcune informazioni su come proteggere il server rimuovendo le suite di cifratura deboli e altre nozioni di base. link

    
risposta data 01000101 19.05.2015 - 15:52
0

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

Computer e gruppi possono anche essere gestiti in LDAP dando la gestione delle credenziali centrali. In questo modo gli help desk possono avere uno sportello unico per gestire grandi popolazioni.

Ecco un link all'integrazione di centOS: link

    
risposta data weller1 29.04.2016 - 15:50
0

Puoi anche bloccare in base al Paese di origine utilizzando il database geoIP.

In pratica, se vivi negli Stati Uniti, non c'è motivo per qualcuno in Russia di connettersi al tuo SSH in modo che vengano automaticamente bloccati.

Lo script può essere trovato qui: link

Puoi anche aggiungere comandi iptables (ho fatto per le mie droplet) per far cadere automaticamente tutto il traffico su / da quegli IP.

    
risposta data Michael A Mike 10.08.2017 - 07:09

Leggi altre domande sui tag