So che una delle prime cose che fai per proteggere un server è impedire l'accesso remoto remoto.
Le password sono piuttosto deboli; cosa pensa la gente di consentire l'accesso root solo tramite chiavi ssh o altri metodi senza password.
Quali sono i metodi migliori? È meglio non rischiare? Ssh-ing con un account secondario e l'utilizzo su -aggiunge davvero sicurezza?
In che modo le persone su serverfault.com accedono alla radice su un server remoto?
Risposte:
Nella maggior parte dei casi, si guadagna poco disabilitando effettivamente gli accessi root remoti. Aiuta marginalmente a far rispettare una politica che gli amministratori effettuano l'accesso tramite i propri account e suche eseguono il root come necessario (o sudoeventualmente usano con sudosh... a seconda delle proprie politiche).
Creare password di root estremamente lunghe e ingombranti (efficaci fino a quando non stai ancora usando l'antico hash salt DES + 12 bit per le tue password) è altrettanto efficace nel far rispettare tale politica.
Un sito con cui ho familiarità aveva un sistema in base al quale le password univoche venivano generate casualmente per ciascun host, archiviate in un database e trasferite ai sistemi. Gli amministratori dovevano utilizzare i sshloro account normali e sudoper la maggior parte delle operazioni. Tuttavia, la password di root era accessibile a loro tramite un servizio Web interno basato su SSL (che richiedeva ulteriormente il loro token RSA SecurID e PIN). Il recupero di una password di root ha comportato l'inserimento di una giustificazione (di solito un collegamento a un numero di ticket Remedy (TM)) e gli accessi dove sono stati periodicamente controllati. Uno dei pochi motivi accettabili per l'utilizzo diretto della password di root era nei casi in cui un sistema era stato arrestato fsckdurante il processo di avvio ... esuloginrichiedeva una vera password di root per eseguire manualmente i processi di controllo e riparazione del filesystem. (C'è stata una discussione sui metodi alternativi per questo --- che sono relativamente facili per Linux, ma diventano molto più difficili mentre provi ad estendere le tue procedure per tenere conto dei numerosi sistemi HP-UX, AIX e precedenti SunOS e Solaris che erano ancora in produzione in quell'ambiente).
Ci sono casi angolari in cui è necessaria una password di root --- o almeno è la migliore alternativa disponibile. Mantenerlo disponibile rendendolo sufficientemente robusto contro il tipo di minacce che puoi prevedere è generalmente la tua migliore strategia.
Un altro sito che conosco ha un approccio piuttosto elegante alla gestione decentralizzata degli account. Hanno pacchetti user- * e sudo- * (pensate agli RPM) che sono installati nei sistemi usando le normali procedure di gestione dei pacchetti e l'infrastruttura di automazione. Nel loro caso il pacchetto sudo- * ha una dipendenza dal corrispondente pacchetto user- *. Questo è utile perché ti consente di avere gruppi di macchine con account localizzati (tutti gli account sono amministratori, sviluppatori, personale di supporto o account "senza testa") ed elimina la dipendenza da LDAP / NIS o altri servizi di autenticazione e identità in rete. (Ciò riduce l'accoppiamento tra i sistemi rendendoli significativamente più robusti).
Una cosa che mi piace di questo approccio è che offre flessibilità. Chiunque abbia sudoaccesso può emettere un comando per aggiungere un utente normale o un altro sudoaccount utente. Quindi, se sto lavorando su un ticket, qualcuno delle persone che hanno già accesso a un sistema può facilmente darmi accesso. Non ci sono ritardi mentre un ticket per aggiungermi a un elenco di controllo degli accessi in alcuni database centrali esegue un processo di approvazione centralizzato e, infine, propaga una modifica al sistema in questione. Qualsiasi utente autorizzato sudosul sistema può darmi accesso e successivamente rimuovermi. (Sì, se fossi cattivo e loro mi prendessero in girosudoPotrei modificare maliziosamente le cose per mantenere l'accesso ... in effetti ci sono alcune cose che potrei fare come un normale utente per mantenere l'accesso dopo tale rimozione. Tuttavia, questa non è la minaccia di cui sono preoccupati. Il mio accesso è ancora limitato a un numero relativamente ridotto di sistemi in generale; quindi l'impatto di un account compromesso è ancora più limitato rispetto alla maggior parte degli schemi simili che ho visto.
Se si disabilita l'accesso remoto remoto, si impedisce a utenti malintenzionati remoti di ottenere direttamente il root: devono rompere un altro account, ottenere l'accesso al computer, quindi provare a ottenere l'accesso al root. È un passo in più.
Generalmente il root è disabilitato per l'accesso remoto. SU funziona bene. Se qualcosa si rompe davvero c'è sempre l'accesso diretto alla scatola per risolverlo.
Se vuoi essere più rigoroso, basta disabilitare completamente root, è ciò che serve a sudo. Ancora una volta, con questo approccio è ancora possibile ottenere l'accesso root passando alla modalità utente singolo - alla Ubuntu. Anche se, credo che abbiano usato un init patchato per quello, secondo i loro documenti.
Inoltre, puoi impostare inattivo per dare il via agli utenti inattivi nel caso in cui i loro terminali vengano lasciati aperti e anche i PC siano aperti. È possibile forzare tutti gli utenti a utilizzare le chiavi, ma la gestione delle chiavi può essere difficile.
Un singolo host di registrazione pass-through come sistema di tipo breakglass ha anche forzato un ulteriore livello di protezione e una pista di controllo.
Suggerisco di configurare il sistema per consentire l'accesso root SOLO sulla console.
Altrimenti, usando sudo con l'opzione password, consenti agli utenti selezionati di accedere a comandi privati. A proposito, renditi conto che sudo può essere progettato per limitare un account utente a determinati comandi, se lo desideri. Sudo, lascia un "segno" nel registro di sistema che è stato utilizzato. sudo è meglio di su perché la password di root non viene rivelata. Quindi puoi cambiare la password di root e l'utente che usa sudo non sarebbe più saggio.
L'uso consentito di sudo per accedere ai comandi privati dovrebbe essere accompagnato da modifiche periodiche forzate della password con la frequenza in base all'ambiente.
non consentire mai il root
impostare il sistema per consentire l'accesso tramite chiavi solo senza password
quindi configurare sudo per gli utenti autorizzati ad apportare modifiche tramite l'account root