Quali metodi sono disponibili per proteggere SSH? [chiuso]

• Disabilita login root - La maggior parte degli attacchi automatizzati si concentrerà sull'account root, quindi non consentire gli accessi da quell'account è un buon punto di partenza.

• Consenti solo determinati gruppi / utenti : limita ciò che utenti e gruppi possono utilizzare SSH nel sistema.

• Limite per IP o intervallo IP : uno dei modi più efficaci per proteggere il sistema dagli attacchi SSH.

• Usa autenticazione basata su chiave - Come descritto da Olivier

• Usa fail2ban - fail2ban monitorerà i tentativi di accesso SSH e dopo un determinato numero di errori tenta di bloccare l'indirizzo IP degli aggressori per un determinato periodo di tempo. Questo può essere un metodo molto efficace per rallentare gli attaccanti.

Le altre risposte si concentrano sulla protezione del server - che è importante, ma anche il lato client merita una certa protezione:

• In / etc / ssh / ssh_config (o ~ / .ssh / config) imposta StrictHostKeyChecking su yes o ask . Ciò fornisce una certa protezione contro gli attacchi man-in-the-middle verificando che il server a cui ci si sta connettendo sia quello che ci si aspetta.
• Se puoi aggiungere record alla tua zona DNS, pubblica un record SSHFP e imposta VerifyHostKeyDNS su yes o ask . Il client preleverà SSHFP dal DNS e verificherà l'impronta digitale. (Nota che sei ancora vulnerabile se il tuo aggressore controlla DNS.)
• Forza la versione del protocollo 2. I.e. imposta Protocol 2 in / etc / ssh / ssh_config - il valore predefinito è 2,1 che consente di tornare a v1 se v2 non è disponibile.
• Preferisci le chiavi alle password per l'accesso. Usa una password sicura sulle tue chiavi ssh. Utilizzare chiavi di lunghezza adeguata (numero di bit).
  • Se hai utenti che forniscono chiavi ssh, verifica la potenza della password eseguendo john sulle chiavi.
• Utilizza un token hardware per sbloccare la chiave invece di digitare la password (per evitare keylogger e spalla surf).
• Assicurati che UseBlacklistedKeys sia no (questo è il valore predefinito). Questo ti impedisce di usare le chiavi della "lista nera" generate durante i deboli pacchetti Debian openssl. Controlla le chiavi host e user con ssh-vulnkeys. Sui sistemi derivati da Debian (ad esempio ubuntu) puoi installare i pacchetti openssh-blacklist e openssh-blacklist-extra.
• Assicurati che CheckHostIP sia yes (il valore predefinito). Questo fa sì che il client controlli l'IP dell'host contro known_hosts per aggiungere protezione contro lo spoofing DNS.
• Imposta HashKnownHosts su yes . Ciò impedisce la perdita di informazioni dal file known_hosts.

Disabilitazione degli accessi basati su password

La sostituzione dell'autenticazione basata sulla password mediante l'autenticazione basata su chiave impedirà:

• Tentativi di cracking della password con forza bruta
• Spalla: le persone si nascondono dietro mentre stai digitando la tua password.
• Registratori di tasti.

Un'altra cosa, se solo poche persone sono autorizzate su SSH, fai una mail bashrc con un avviso ogni volta che qualcuno accede a SSH

Per cominciare bisognerebbe disabilitare le password e consentire solo l'autenticazione usando le chiavi RSA. Questo rende gli attacchi di forza bruta non fattibili. Le persone tenteranno comunque , quindi dovrai limitare i tentativi di accesso e magari cambiare la porta per risparmiare larghezza di banda. Questo approccio si basa sulla fiducia per gli utenti di crittografare e proteggere le proprie chiavi private.

Non dovresti consentire il login di root da remoto. Usa su o sudo una volta effettuato l'accesso.

Potrebbe essere una buona idea impedire alle persone di eseguire il tunneling di ssh tramite il server gateway ai server interni. Ciò può impedire ai server interni di essere esposti a Internet.

Dovresti usare la versione 2 di SSH.

Mi viene in mente che nessuna delle altre risposte parla di un punto molto importante per la protezione di SSH: educa i tuoi utenti . Qualunque cosa tu faccia, se gli utenti non imparano a reagire sensibilmente quando accade qualcosa di sospetto, allora sei condannato. Per lo meno, gli utenti devono essere a conoscenza della gestione delle chiavi del server (quando si connettono per la prima volta a un determinato server, devono controllare l'impronta digitale chiave con una fonte affidabile e se SSH avvisa di una chiave che è cambiato, loro non devono ignorare l'avviso).

La tecnologia non può che farti arrivare così lontano; Finché un essere umano è coinvolto nel processo, la quantità di consapevolezza della sicurezza di quell'utente è un limite difficile al livello di sicurezza che si può sperare di ottenere.

C'è una nuova opzione sul server per richiedere passphrase sulle chiavi del client. Penso che questa sia un'ottima idea. Tuttavia, non si conosce ancora la complessità della passphrase e gli utenti potrebbero potenzialmente ricompilare il client per simulare questo.

Come tutti dicono: disabilita sempre il login root, cambia il numero di porta predefinito (anche se questo può rendere difficile l'utilizzo di alcuni client sftp) e accetta solo l'autenticazione basata su chiave.

Inoltre, se si modificano le dimensioni della chiave in sshd_config o si specifica una dimensione bit della chiave quando si esegue ssh-keygen, è necessario rivedere le dimensioni della chiave specificate di volta in volta.

Indietro quando ssh-keygen era in default per generare chiavi RSA a 1024 bit. Usavo l'opzione -b per generare chiavi a 1536 bit. Nel tempo il valore predefinito è cambiato per generare chiavi a 2048 bit e stavo ancora generando le chiavi a 1536 bit.