Qual è la soluzione migliore per gestire la password di root di migliaia di server


12

Sono un amministratore di sistema. Nell'ambiente di produzione ho bisogno di gestire migliaia di server. Io e i miei colleghi utilizziamo un server di gestione centrale e distribuiamo la sua chiave pubblica attraverso altri server. Quindi possiamo usare questo server di gestione per ssh su altri server.

A volte è necessario utilizzare la password di root, ad esempio quando il server è inattivo, è necessario utilizzare iLO per determinare il motivo.

Attualmente, utilizziamo una password di root condivisa. Non è sicuro. Ho anche esaminato alcune soluzioni a server singolo come OPIE(One-time Passwords In Everything), ma poiché abbiamo così tanti server, questa non è una buona idea.

MODIFICARE:

Quello che voglio dalla soluzione di gestione password è:

  1. Dovrebbe essere sicuro, quindi One-time Password è un'ottima soluzione.
  2. La password può essere facilmente inserita, a volte è necessario collegare il monitor al server o con iLO, come ho detto sopra.
  3. La soluzione dovrebbe funzionare anche se il server è offline (senza alcuna connessione di rete)

Quindi non è una buona idea impostare la password di root su una stringa lunga e casuale, sebbene sia generata da un comando noto (come openssl passwd). È difficile da ricordare, e talvolta è difficile da generare (senza il mio laptop in giro)


1
Stai già utilizzando un sistema di gestione della configurazione come fantoccio? Che cosa stai usando?
Zoredache,

Puppet ++ per questo.
Tom O'Connor,

Usiamo cfengine :-)
yegle

Risposte:


5

Puoi usare Puppet per inviare la modifica della password a tutti i tuoi server. Definiresti rootusando il usertipo in questo modo:

    user { 'root':
            ensure => present,
            password => '$1$blablah$blahblahblahblah',
    }

Per generare la password crittografata:

openssl passwd -1 -salt "blah"

Suggerirei di cambiarlo ogni mese o giù di lì --- magari usando uno schema che le tue SA hanno memorizzato. Puoi anche distribuirlo tramite un metodo sicuro o metterlo in una cassaforte.


3

Puoi sempre semplicemente impostare una password disabilitata. Ciò impedirebbe qualsiasi accesso di rete al root e se si avvia in modalità utente singolo la maggior parte delle distribuzioni si avvierà direttamente su una shell.

Questo probabilmente non è un grosso problema di sicurezza come potresti pensare. È banale bypassare la password di root comunque, a meno che tu non abbia bloccato grub con una password, praticamente chiunque potrebbe semplicemente dire a grub di avviare bash invece di initrd.

Ovviamente questo può significare che dovresti invece capire come proteggere con password il tuo bootloader.


0

È possibile utilizzare una volta le password con una gestione centrale. So che questo non si adatta a "deve funzionare quando eth è offline e al server si accede con iLO".

Comunque: la domanda è: quanto spesso il server è offline.

Quindi potresti pensare alla seguente configurazione:

Utilizzare una soluzione OTP gestita centralmente come privacyidea ( http://www.privacyidea.org ). È possibile assegnare diversi token OTP all'utente root. Ogni token ha un PIN OTP diverso ed è un dispositivo diverso. In questo modo tutti i tuoi colleghi possono accedere come utente root ma nel registro di controllo vedrai quale token autenticato, in modo da poter sapere a quale collega ha effettuato l'accesso in quel momento.

Sui server è necessario configurare pam_radius per passare la richiesta di autenticazione a RADIUS e privacyIDEA.

Bummer. Ora il tuo server diventa offline. In questo caso dovresti giocare con il tuo stack. Potrei pensare a qualcosa del tipo:

auth sufficient pam_unix.so
auth required pam_radius.so use_first_pass

In modo che tu possa accedere con una password fissa offline, altrimenti la password viene consegnata a pam_radius e viene convalidata come OTP contro privacyIDEA.

Guarda questo howto https://www.howtoforge.com/manage-two-factor-authentication-in-your-serverfarm-with-privacyidea .

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.