Dovremmo disabilitare l'utente root?

Dovremmo rimuovere la password di root, disabilitare l'accesso remoto e fondamentalmente richiedere agli amministratori di utilizzare sudo per eseguire azioni amministrative?

Tutti i miei server hanno l'account root disabilitato ( sp_pwdpimpostato su *). Questo è necessario sudoper tutti gli accessi root. [1] Lo scopo è di controllare tutte le attività dei superutente, in modo che le persone possano vedere cosa è stato fatto al sistema.

Per un'opzione più hardcore, puoi sudoscrivere su un file di registro (al contrario di syslog) e rendere il file solo accodato (usando chattrsu Linux o chflagssu BSD). In questo modo, nessuno può modificare l'audit in seguito.

[1] Ho anche la politica di non eseguire una shell di root o di eseguire escape di shell da un processo di root. (Va bene usare sudo sh -c '...'per fare pipeline o reindirizzamenti, però.)

Ho decisamente consiglio contro disabilitando l'utente root. Disabilita o limita gli accessi root (tramite securetty e via sshd_config e tramite PAM e tramite quello che hai) Se il tuo sistema lo consente, limita i privilegi di root o dividi il ruolo di root (simile a come lo fa RSBAC ). Ma per favore, per favore , fallo non disabilitare l'account root rimuovendo la password, altrimenti sarà impossibile accedere al sistema tramite sulogin. suloginviene utilizzato da tutti gli initscript che conosco in caso di errori gravi segnalati da fsck - e ciò significa che sarai bloccato fuori dal sistema se il file system di root viene danneggiato.

Per chiarire: "Disabilitando l'account root rimuovendo la password" intendo i vari meccanismi che finiscono con un! o un * nel campo password di / etc / shadow, o simile. Non intendo "modificare il meccanismo di accesso di root in modo da non ricevere una password".

Ho l'account di root abilitato su tutti i miei server. Tutti gli amministratori hanno il proprio utente e devono accedere tramite quello. Da lì passano alla radice. (root ssh è disabilitato)

Mantieni basso il conteggio degli amministratori. Solo le persone che hanno davvero bisogno dell'accesso root su quel server hanno la password.

Non sono un fan di sudo. È troppo facile fare semplicemente "sudo bash" per una shell root. Sono consapevole che questo può essere disabilitato, ma perché preoccuparsi? Basta limitare gli utenti che possono eseguire compiti di amministratore e parlare tra loro. Abbiamo una politica per non consentire l'apertura automatica dei terminali root. Quindi è il login, su, fare il lavoro, disconnettersi.

Nota: lavoro in un'azienda abbastanza piccola (50 dipendenti) e ci spostiamo con solo 2 amministratori part-time (1 windows / 1 linux). Questo modo di fare le cose potrebbe non essere il migliore quando hai ordini di grandezza più utenti. Personalmente non userei ancora sudo. Esistono altri modi per registrare l'attività di root.

Disabilitare la password di root è una falsa "buona idea". Il giorno in cui ne avrai bisogno, ne avrai davvero bisogno. (in base alla configurazione, potrebbe essere necessario accedere per esempio in modalità utente singolo)

La disabilitazione dell'accesso remoto alla radice potrebbe essere rilevante ma solo se si è in grado di accedere localmente.

E sì, sudo dovrebbe essere installato su ognuno dei tuoi server. È utile e facile da configurare. Perché vorresti non usarlo?

Disabilito l'accesso SSH per root e richiedo agli utenti (spesso sono solo sviluppatori) di usare le chiavi ssh. Ci sono troppi attacchi ai dizionari e cambiare la porta SSH non è un'opzione per noi.

In questo modo non devi fidarti della capacità di nessuno di scrivere una buona password. Una volta dentro, solo gli amministratori hanno i permessi per sudo.

So che questo thread è davvero vecchio ma ci sono alcuni importanti difetti nella logica degli articoli collegati e mi sento "rant'ie" - sudo consente sia la whitelisting che la blacklist. Non solo nero come specificato nell'articolo collegato - Salta l'idea di AAA (autenticazione, autorizzazione e controllo) - su & sudo consentono sia l'autenticazione graduale che la responsabilità.

Scenario 1 Un amministratore introduce accidentalmente del codice non valido in un sistema, ha effettuato l'accesso come root al codice con accesso completo e l'amministratore potrebbe non sapere mai cosa è successo. Almeno con accessi classificati (ad es. Su / sudo) all'amministratore verrà richiesto di autenticarsi se il codice canaglia tenta di utilizzare diritti elevati ... Se non viene elevato, si limita ai diritti degli utenti che dovrebbero comportare un danno minimo.

Scenario 2 Un amministratore non autorizzato desidera ottenere informazioni / apportare una modifica. Si connettono alla console (accesso alla console fisica, HP iLo / simile o accesso alla console vGuest), effettuano il login come root e fanno tutto ciò che desiderano. A meno che non vi sia una carta di accesso / account denominata utilizzata per ottenere l'accesso alla console, probabilmente non c'è molto di una pista di controllo.

1. Assicurati di essere davvero quello che dicono di essere. Il furto di identità non è il problema, lo è la verifica dell'identità.
2. Controlla la loro autorizzazione, dai loro solo ciò di cui hanno bisogno in quel momento. L'autorizzazione graduale consente loro di elevarsi quando ne hanno bisogno.
3. Controlla tutto, registra, in modo da sapere chi, cosa ha fatto, quando e dove. Preferibilmente anche perché

Dovresti richiedere a tutti di usare sudo per ogni comando di root come criterio. Non c'è mai un motivo per eseguire "sudo bash" o simili, è solo per comodità, a causa dell'ignoranza, o per coprire le proprie tracce.

Se si disabilitano direttamente gli accessi all'account root, si paralizza la capacità di riparare il sistema in caso di problemi gravi.

Se non riesci a convincere i tuoi amministratori ad accedere come se stessi ed eseguire sudo per ogni comando eseguito come root e a non dividerlo in una shell, hai seri problemi per i quali non esiste una soluzione tecnica.

Gli autori di Owl Secure Distribion ​​(e Solar designer) hanno un punto di vista opposto, accuratamente giustificato; vedere, ad esempio, la risposta /unix/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660 per una presentazione delle loro affermazioni. Il problema del controllo delle azioni del superutente (quale persona ha fatto cosa) è anche affrontato dal loro punto di vista (in sostanza, la soluzione è avere diversi utenti root con nomi diversi).