Qual è il valore effettivo della disabilitazione dell'accesso root remoto usando ssh?

4

Ho letto le risposte sul perché dovresti disabilitare il login di root, ma c'è qualcosa che mi assilla. Supponi questo:

  • Scenario 1:
    • Server remoto A.
    • Accesso root remoto disabilitato.
    • L'autenticazione della password è disabilitata.
    • L'utente A utilizza l'autenticazione rsa per accedere.
    • L'utente A esegue /bin/su - per diventare root e inserisce la password di root.
  • Scenario 2:
    • Server remoto B.
    • Accesso root remoto abilitato.
    • L'autenticazione della password è disabilitata.
    • L'utente B utilizza l'autenticazione rsa per accedere come root.

Conosco già il modo di dire su più linee di difesa, e sì - so che i bot su Internet hanno maggiori probabilità di provare a penetrare usando root rispetto alla maggior parte degli altri accessi, ma lo scenario 1 offre vantaggi significativi rispetto allo scenario 2 se si ipotizza che un utente malintenzionato trovi un modo per aggirare l'autenticazione rsa (tramite il dirottamento, l'exploit o semplicemente la copia del file chiave) utilizzato in entrambi gli scenari?

Diciamo che un utente malintenzionato accede al server A ed è in grado di accedere come utente A. Non è giusto che da quel momento in poi l'utente A non possa accedere e su a root senza condividere potenzialmente il password di root con l'attaccante? È difficile aggiungere semplicemente un comando fatto in casa alla fine dello script di login degli utenti che intercetterà e inoltrerà (o memorizzerà) la password di root?

Il mio punto non è che sia sicuro permettere agli utenti di accedere come root da remoto, ma forzare gli utenti ad accedere usando un altro account è quasi altrettanto pericoloso - modulo di vari bot che stanno sempre martellando sugli account di root ovunque.

Mi manca qualcosa?

    
posta Michael Zedeler 27.04.2013 - 00:28
fonte

1 risposta

6

Appena in cima alla mia testa:

  • Se le credenziali dell'utente sono compromesse, il blocco di quell'account nella directory utente è molto più rapido e affidabile rispetto alla modifica di /root/.ssh/authorized_keys su tutti i sistemi per rimuovere la chiave dell'utente.
  • I daemon di controllo di Linux distinguono tra "uid" e "uid efficace". Gli utenti che eseguono ssh come se stessi e poi sudo per ottenere i privilegi saranno visti dal demone di controllo come "utente bob che agisce da root" vs solo "root utente" se eseguono ssh direttamente come root. È importante disporre di una traccia di controllo che ritorni all'utente che esegue le azioni.
  • È possibile richiedere un token di autenticazione a 2 fattori per sudo. Anche se questo può essere fatto anche a livello di sshd, ciò richiede una patch di terze parti e ha un impatto significativo sull'usabilità, in quanto non può essere abilitato solo per un gruppo di utenti.
risposta data 27.04.2013 - 00:59
fonte

Leggi altre domande sui tag