Domanda:
Quali metodi sono disponibili per proteggere SSH?
Olivier Lalonde
2010-11-12 04:26:43 UTC
view on stackexchange narkive permalink

Quali metodi sono disponibili per proteggere SSH?

http://library.linode.com/security/basics
Otto risposte:
#1
+35
Mark Davidson
2010-11-12 04:45:31 UTC
view on stackexchange narkive permalink
  • Disabilita accesso root : la maggior parte degli attacchi automatici si concentrerà sull'account root, quindi non consentire l'accesso da quell'account è un buon punto di partenza.

  • Consenti solo a determinati gruppi / utenti : limita gli utenti e i gruppi che possono accedere in SSH al sistema.

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

  • Usa autenticazione basata su chiavi - Come descritto da Olivier

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

Inoltre, assicurati di utilizzare tutte le nuove funzionalità di sicurezza in sshd. Attualmente questo significa "UsePrivilegeSeparation yes" e "Compression delayed", che aiutano entrambi a proteggere dai bug del codice.
E configuralo con il port knocking (incluso) o cambia la porta SSH in una porta diversa, inutilizzata e ben nota (non una porta alta o $ user può eseguire il proprio servizio in ascolto su quella porta e raccogliere le credenziali per gli utenti più privilegiati ). E aggiungi l'autenticazione a due fattori (o, almeno, a due canali).
#2
+18
bstpierre
2011-10-29 02:15:35 UTC
view on stackexchange narkive permalink

Le altre risposte si concentrano sulla protezione del server - che è importante, ma anche il lato client merita un po 'di 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 controllando che il server a cui ti stai connettendo sia quello che ti aspetti.
  • Se puoi aggiungere record alla tua zona DNS, pubblica un record SSHFP e imposta VerifyHostKeyDNS su yes o ask . Il client recupererà SSHFP dal DNS e verificherà l'impronta digitale. (Tieni presente che sei ancora vulnerabile se il tuo aggressore controlla il DNS.)
  • Forza il protocollo versione 2. Ad esempio imposta il 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 complessa per le tue chiavi ssh. Usa chiavi di lunghezza adeguata (numero di bit).
    • Se hai utenti che forniscono chiavi ssh, controlla la sicurezza della password eseguendo john sulle chiavi.
  • Utilizza un token hardware per sbloccare la chiave invece di digitare la password (per evitare i keylogger & spallacci).
  • Assicurati che UseBlacklistedKeys sia no (questo è il valore predefinito). Questo ti impedisce di usare le chiavi 'nella lista nera' generate durante i pacchetti Debian openssl deboli. Controlla le chiavi host e utente con ssh-vulnkeys. Su sistemi derivati ​​da Debian (es. Ubuntu) puoi installare i pacchetti openssh-blacklist e openssh-blacklist-extra.
  • Assicurati che CheckHostIP sia yes (impostazione predefinita). Questo fa sì che il client controlli l'IP dell'host rispetto a known_hosts per aggiungere protezione contro lo spoofing DNS.
  • Imposta HashKnownHosts su yes . Ciò impedisce la fuga di informazioni dal tuo file known_hosts.
#3
+11
Olivier Lalonde
2010-11-12 04:31:02 UTC
view on stackexchange narkive permalink

Disabilitare gli accessi basati su password

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

  • Bruto -Forza i tentativi di cracking delle password.
  • Attacchi alle spalle: persone che si intrufolano mentre digiti la tua password.
  • Registratori di chiavi.
Se hai bisogno di token hardware, ottieni questi vantaggi. Ma il collegamento a cui punti riguarda le chiavi software e lascia aperta anche l'idea di non avere una passphrase sulla chiave - accidenti! Senza i token hardware, i tasti non protetti o i logger della tastiera otterranno comunque la tua chiave o password, così come i surfisti con il giusto tempismo o gli attacchi di forza bruta.
#4
+7
Aviah Laor
2010-11-12 11:10:38 UTC
view on stackexchange narkive permalink

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

Se qualcuno sa che lo stai facendo, non è difficile andare in giro.`echo mv .bashrc .bashrc_old |ssh hostname` sposterà '.bashrc` fuori mano in modo che tu possa quindi eseguire un login interattivo senza che `.bashrc` venga eseguito.(Per un vero attacco dovresti estenderlo per spostare anche `.profile` e` .bash_profile`, o usare una delle molte altre tecniche per fare qualunque cosa tu debba fare senza eseguirle.)
#5
+6
Magnus
2010-11-12 04:38:40 UTC
view on stackexchange narkive permalink

Per cominciare dovresti disabilitare le password e consentire solo l'autenticazione utilizzando le chiavi RSA. Ciò rende impossibili gli attacchi di forza bruta. Tuttavia, le persone continueranno a provare, quindi ti consigliamo di limitare i tentativi di accesso e forse cambiare la porta per risparmiare larghezza di banda. Questo approccio si basa sulla fiducia che i tuoi utenti crittografano e proteggono le loro 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 attraverso il tuo server gateway verso i server interni. Questo può impedire ai tuoi server interni di essere esposti a Internet.

Dovresti usare la versione 2 di SSH.

#6
+6
Thomas Pornin
2012-11-25 08:26:32 UTC
view on stackexchange narkive permalink

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

La tecnologia può solo portarti lontano; fintanto che un essere umano è coinvolto nel processo, la consapevolezza della sicurezza di quell'utente è un limite rigido al livello di sicurezza che potresti sperare di raggiungere.

#7
+3
nowen
2010-12-02 22:10:49 UTC
view on stackexchange narkive permalink

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

#8
+2
ewalshe
2010-11-13 05:25:25 UTC
view on stackexchange narkive permalink

Come dicono tutti: disabilita sempre il login di 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 cambi qualsiasi chiave dimensioni in sshd_config o specificare una dimensione di bit della chiave quando si esegue ssh-keygen, è necessario rivedere le dimensioni della chiave specificate di volta in volta.

Indietro quando ssh-keygen utilizzava per impostazione predefinita la generazione di chiavi RSA a 1024 bit per utilizzare l'opzione -b per generare chiavi a 1536 bit. Nel tempo l'impostazione predefinita è cambiata per generare chiavi a 2048 bit e stavo ancora generando chiavi a 1536 bit.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 2.0 con cui è distribuito.
Loading...