Perché l'accesso root tramite SSH è così grave che tutti consigliano di disabilitarlo?

Tutti su Internet consigliano di disabilitare il login root tramite SSH poiché è una cattiva pratica e una falla nella sicurezza del sistema, ma nessuno spiega perché sia ​​così.

Cosa c'è di così pericoloso nell'abilitare l'accesso root (specialmente con l'accesso con password disabilitata)?

E qual è la differenza tra nome utente simbolo X e password simbolo Y o nome utente root e password simbolo X + Y dal punto di vista della sicurezza nel caso in cui sia consentita l'autenticazione password?

Perché root su SSH è male

Ci sono molti robot là fuori che provano ad accedere al tuo computer tramite SSH. Questi robot funzionano nel modo seguente.

Eseguono qualcosa del genere ssh root@$IPe poi provano password standard come "root" o "password123". Lo fanno il più a lungo possibile, fino a quando non trovano la password giusta. Su un server accessibile in tutto il mondo è possibile visualizzare molte voci di registro nei file di registro. Posso andare fino a 20 al minuto o più.

Quando gli attaccanti hanno fortuna (o abbastanza tempo) e trovano una password, avrebbero accesso alla radice e ciò significherebbe che sei nei guai.

Ma quando si impedisce a root di accedere tramite SSH, il bot deve prima indovinare un nome utente e quindi la password corrispondente. Supponiamo quindi che l'elenco di password plausibili contenga Nvoci e che l'elenco di utenti plausibili sia Mcomposto da voci di grandi dimensioni. Il bot ha una serie di N*Mvoci da testare, quindi questo rende un po 'più difficile per il bot rispetto al caso radice in cui è solo una serie di dimensioni N.

Alcune persone diranno che questo ulteriore Mnon è un vero guadagno in termini di sicurezza e sono d'accordo che si tratta solo di un piccolo miglioramento della sicurezza. Ma penso a questo più come questi piccoli lucchetti che di per sé non sono sicuri, ma impediscono a molte persone di accedere facilmente. Questo ovviamente è valido solo se la tua macchina non ha altri nomi utente standard, come tor o apache.

Il motivo migliore per non consentire il root è che root può fare molti più danni sulla macchina di quanto un utente standard possa fare. Quindi, se per fortuna trovano la tua password, l'intero sistema viene perso mentre con un account utente standard puoi solo manipolare i file di quell'utente (che è ancora molto male).

Nei commenti è stato menzionato che un utente normale potrebbe avere il diritto di utilizzare sudoe se si indovinasse la password di questo utente, anche il sistema andrebbe completamente perso.

In sintesi, direi che non importa quale password dell'utente ottiene un utente malintenzionato. Quando indovinano una password non puoi più fidarti del sistema. Un utente malintenzionato può utilizzare i diritti di quell'utente per eseguire comandi sudo, l'attaccante può anche sfruttare una debolezza del sistema e ottenere i privilegi di root. Se un attaccante ha avuto accesso al tuo sistema non puoi più fidarti di esso.

La cosa da ricordare qui è che ogni utente nel tuo sistema a cui è consentito accedere tramite SSH è un ulteriore punto debole. Disabilitando root si rimuove un'ovvia debolezza.

Perché le password su SSH sono sbagliate

Il motivo per disabilitare le password è davvero semplice.

• Gli utenti scelgono password errate!

L'intera idea di provare le password funziona solo quando le password sono indovinabili. Quindi quando un utente ha la password "pw123" il tuo sistema diventa insicuro. Un altro problema con le password scelte dalle persone è che le loro password non sono mai veramente casuali perché sarebbe difficile da ricordare.

Inoltre, gli utenti tendono a riutilizzare le proprie password, utilizzandole per accedere a Facebook o ai loro account Gmail e per il proprio server. Quindi, quando un hacker ottiene la password dell'account Facebook di questo utente, potrebbe accedere al tuo server. L'utente potrebbe facilmente perderlo a causa del phishing o il server di Facebook potrebbe essere violato.

Ma quando si utilizza un certificato per accedere, l'utente non sceglie la sua password. Il certificato si basa su una stringa casuale che è molto lunga da 1024 bit fino a 4096 bit (~ 128 - 512 caratteri password). Inoltre, questo certificato è lì solo per accedere al tuo server e non viene utilizzato con alcun servizio esterno.

link

http://bsdly.blogspot.de/2013/10/the-hail-mary-cloud-and-lessons-learned.html

Questo articolo proviene dai commenti e volevo dargli una posizione un po 'più prominente, poiché va un po' più a fondo nella questione delle botnet che provano ad accedere tramite SSH, come lo fanno, come appaiono i file di registro e cosa si può fare per fermarli. È stato scritto da Peter Hansteen.

Questi potrebbero essere alcuni dei motivi per cui l'accesso al root diretto non dovrebbe essere consentito.

• Tentativi di forza bruta. L'accesso diretto alla radice potrebbe causare più danni in caso di attacco bruteforce riuscito.
• La mancata configurazione su chiavi SSH "senza password" (si verifica un errore umano) potrebbe esporre la macchina a Internet

Ma questo è solo il SUGGERIMENTO dell'iceberg. Devi configurare altre restrizioni e configurazioni come:

• Cambia la porta predefinita (22)
• Password complesse e passphrase
• Disabilita autenticazione basata su host
• Crea un elenco di utenti consentiti
• Configurare il timeout di inattività
• Forza il protocollo SSHv2
• Disabilita password vuote
• Usa fail2ban come misura ancora bruteforce
• Registra tutto
• Configura le chiavi SSH e affidati solo alle chiavi pubbliche su .ssh / authorized_keys

Hai ragione che il nome utente di root e la password del simbolo X + Y sono crittograficamente sicuri almeno quanto il nome utente del simbolo X + la password del simbolo Y. In effetti è ancora più sicuro, perché i nomi delle persone sono facili da indovinare (i robot possono semplicemente provare john, mike, bill, ecc ... e btw: questo è quello che fanno molti di loro invece di provare root). E sei particolarmente sfortunato se si tratta di un attacco mirato, perché se qualcuno vuole rompere il server di un'azienda non sarebbe un problema scoprire il nome (nick) dell'amministratore di sistema.

E non appena l'attaccante ha accesso all'account utilizzato da sysadmin per gli accessi ssh (e quindi utilizza suo sudoper svolgere le sue attività) può infettare la sessione dell'utente con un programma che invierà la password di root dell'attaccante quando il sysadmin digita quello successivo tempo.

È qualsiasi tipo di login root che sono (o dovrebbero essere) considerati cattive pratiche dal punto di vista della sicurezza. Il login "normale" dell'utente -> catena su / sudo aggiunge una traccia di controllo. In parole povere: permette di scoprire chi ha fatto cosa.

Un caso speciale può essere quello in cui solo una persona ha accesso come root. In tal caso l'utilizzo dell'utente "normale" aggiuntivo non aggiungerà molto valore (almeno non ho mai visto quel valore). Ma comunque - dovresti comunque avere un semplice utente sul sistema (per attività non amministrative, eseguire wget, ecc ;-)).

Cosa c'è di così pericoloso nell'abilitare l'accesso root (specialmente con l'accesso con password disabilitata)?

L'attaccante (bot / botnet / hacker) deve solo indovinare la password e ha il controllo completo sul sistema, se si è aperti a Internet. Inoltre, nessuno degli account di sistema (dati www, proxy, ecc.) Dovrebbe essere in grado di accedere tramite SSH, per gli stessi motivi.

Se hai disabilitato l'accesso con la password (usando la chiave pubblica, ad esempio), tieni presente che chiunque ottiene la chiave privata ottiene il controllo completo sul tuo sistema. Scopri perché usare la chiave pubblica con un utente è meglio sotto.

E qual è la differenza tra nome utente simbolo X e password simbolo Y o nome utente root e password simbolo X + Y dal punto di vista della sicurezza nel caso in cui sia consentita l'autenticazione password?

Il nome utente extra può aggiungere un livello di sicurezza poiché: a) un utente malintenzionato deve conoscere sia coppia, nome utente e password; b) nel caso in cui un utente malintenzionato violi il sistema non avrebbe accesso immediato a un account privilegiato aggiungendo un po 'di sfumatura per l'utente malintenzionato.

In questo caso la chiave pubblica è anche un vantaggio, poiché:

1. L'attaccante ha bisogno della tua chiave pubblica
2. L'attaccante ha bisogno della password (o del metodo di autenticazione) per ottenere privilegi elevati

Non è esattamente male finché si prendono precauzioni di sicurezza. Ad esempio, è possibile installare CSF (Configure Server Firewall) e impostare il numero di tentativi di errore consentiti, quindi se qualcuno ha provato, diciamo più di 5 tentativi di errore ?, vengono automaticamente bloccati. Quindi l'intera prima parte del miglior risponditore non sarà affatto un problema. Questo mi è successo molte volte e fortunatamente tutti gli introduttori sono stati bloccati in modo permanente. Immagino che per un server non sia un grosso problema se sei l'unica persona che gestisce il server, ma ovviamente se ci sono molti amministratori di sistema o se lavori in un'organizzazione, ovviamente non usare radice. Anche per un PC desktop, suppongo che utilizzare un altro account sia migliore in quanto esiste un rischio per la sicurezza poiché si utilizza un sacco di software, ma in un server non si ' Scegli un software casuale di cui non ti fidi, assicurati di mantenerli il più bassi possibile. Quindi la conclusione è che No non è davvero dannoso se sai come gestire correttamente un server.