Domanda:
Perché la disabilitazione di root è necessaria per la sicurezza?
Randomblue
2016-02-16 03:04:36 UTC
view on stackexchange narkive permalink

Questa pagina sulla protezione avanzata del server afferma:

La disabilitazione dell'account root è necessaria per motivi di sicurezza.

Perché è disabilitare l'account root necessario per motivi di sicurezza?

Credo che la tua risposta sia nella sezione appena sopra la tua citazione "Crea" utente ombra "con poteri sudo"
Il collegamento suggerisce solo di disabilitare la password per l'account di root usando [passwd -l] (http://man7.org/linux/man-pages/man1/passwd.1.html), non di disabilitare il root conto in una sorta di modo più grande. Puoi ancora fare "su".
BTW, non posso dire che penso che sia un ottimo articolo.
Se stai utilizzando un server Ubuntu, prova `tail -f / var / log / auth.log` e vedi quanti aggressori tentano di accedere come root.
Un account root non disabilitato è protetto solo dalla forza della password. Se quella password è compromessa, il tuo sistema è compromesso.
E tutto ciò riflette essenzialmente che il modello di sicurezza originale in Unix di root onnipotente non funziona bene nel mondo di Internet. È necessaria una granularità più fine.
Una pagina sull'indurimento del server che va avanti molto su quanto sia importante proteggere / tmp, ma riesce a confondere / tmp e / var / tmp ([non sono la stessa cosa!] (Http: //www.pathname. com / fhs / pub / fhs-2.3.html # VARTMPTEMPORARYFILESPRESERVEDBETWEE)) e in qualche modo * non * menzionare [libpam-tmpdir] (https://launchpad.net/ubuntu/trusty/+package/libpam-tmpdir)? Sebbene abbia sicuramente alcuni buoni suggerimenti, chiaramente quella pagina * non * dovrebbe essere presa come vangelo.
Correlato, da Unix Stack Exchange: [Qual è il modo più sicuro per ottenere i privilegi di root: sudo, su o login?] (Http://unix.stackexchange.com/questions/8581/which-is-the-safest-way- to-get-root-privileges-sudo-su-or-login /)
@ThorbjørnRavnAndersen: "Un account root non disabilitato è protetto solo dalla forza della sua password": Quindi, se si disabilita il login con password per root e si usa invece una coppia di chiavi ssh, allora il problema è risolto! O è?
@SteveJessop è un passo nella giusta direzione. Potresti voler vedere cosa ha fatto Apple con "rootless" in OS X. http://apple.stackexchange.com/questions/193368/what-is-the-rootless-feature-in-el-capitan-really
Sei risposte:
#1
+81
Ohnana
2016-02-16 03:12:38 UTC
view on stackexchange narkive permalink

Se non stai usando Root, stai usando sudo! Sudo è un ottimo modo per diventare root solo quando è necessario.

  1. Root è un obiettivo gigante. Qual è il nome utente di root? Radice! Sono così intelligente :)
  2. Registrazione. Sudo ha un maggiore controllo della registrazione degli audit (in modo che quando qualcuno usa sudo per fare qualcosa di stupido, puoi parlarne con server di registrazione centrale). Questo è utile per l'analisi forense in alcuni casi.
  3. Autorizzazioni granulari. Root è un grande martello ribelle. Non consegnare BFH ai tuoi utenti. Sudo ti consente di specificare che un utente può eseguire comandi di aggiornamento come aptitude senza password, ma tutto è off limits! Non puoi farlo con il BFH che è root. L'IT consente la flessibilità di approvare determinati comandi per gli utenti, ma di non consentirne altri. Ciò consente di creare una politica di sicurezza che non richiede a un amministratore di accedere fisicamente a una macchina ogni volta che una macchina deve essere aggiornata (o un'altra attività umile).
  4. A prova di idiota. Perché non consegni agli utenti un BFH? Perché sono stupidi. Perché uso sudo invece di root? Sono stupido. Dumb significa errori e errori significano falle di sicurezza e problemi di amministratore di sistema.
Quindi l'utente digita: `sudo bash`
E se si dispone di una corretta politica di controllo, l'utente vedrà: `Permission denied. Questo incidente verrà segnalato »
Quindi l'utente digita "SHELL = / mio / programma apt-get install " e ottiene una shell perché alcuni pacchetti hanno scambiato "$ SHELL" con "sh".
Oppure l'utente crea un pacchetto con una shell setuid, quindi lo installa. Oppure installa una vecchia versione di un demone root che presenta vulnerabilità note.
Sebbene tu sia un buon argomento per l'utilizzo di `sudo` sull'account di root, non sono sicuro che tu effettivamente fornisca un argomento per disabilitare la password di root.
@Gilles A meno che non si consentano solo gli aggiornamenti o si disponga di una lista bianca di pacchetti.
@Ohnana puoi fare tutto questo pur avendo un account di root abilitato. Devi solo disabilitarlo se le persone che usano il tuo sistema devono essere costrette a seguire le regole (cioè sono stupide o non possono essere completamente affidabili).
@TomLeek `sudo su` sembra funzionare meglio, perché imposta l'ambiente correttamente, esegue una shell di login, ecc.
@PyRulez Consentire solo gli aggiornamenti non sarebbe di aiuto. Tuttavia, la configurazione predefinita di sudo su molte distribuzioni in cui cancella la maggior parte delle variabili d'ambiente, inclusa "SHELL", risolve * questa particolare * via di escalation. Probabilmente ce ne sono altri che coinvolgono pacchetti con configurazione interattiva, anche se consentire solo gli aggiornamenti riduce notevolmente il rischio.
@immibis L'esecuzione di `sudo su` invece di` sudo bash`è sia irrilevante (il punto di Tom è che l'utente esegue una shell, dopodiché può fare tutto ciò che vuole) che inutile (`sudo su` non“ imposta l'ambiente correttamente "Più di quanto non faccia` sudo bash`, e non esegue una shell di login - esegue la shell di login dell'utente (campo `pw_shell` del database utente), ma non come una shell di login (` -bash` o simile eseguire `.profile`)).
Il mio unico problema con questo è l'uso del termine "a prova di idiota". Si può rendere un sistema infallibile, ma solo resistente agli idioti. La vera protezione dagli idioti è impossibile, perché l'Universo continua a produrre idioti migliori.
Si potrebbe sostenere che l'utilizzo di un account di root dedicato e l'avvio sempre di una shell di root sia più sicuro di `sudo`, perché` sudo` memorizza nella cache le credenziali (consentendo a un programma dannoso di nascondersi in background e cavalcare sulle code di un legittimo richiesta) o richiede di digitare la password così spesso che diventa un'abitudine.
@Gilles @immibis l'implicazione è che l'utente potrebbe essere dannoso, nel qual caso l'uso di `sudo` non è un'opzione
@immibis, `sudo su` non fa nulla che` sudo -i` non fa, a parte chiamare inutilmente eseguibili non necessari.
Allora perché non rinomini root?
@Joshua è una cosa incredibilmente difficile da fare e molto probabilmente ti perseguiterà per il resto della vita del sistema. Tutti dipendono da root! È meglio disabilitare l'accesso e lavorare da lì.
@Ohnana: vim / etc / password è facile. I file sono di proprietà dell'ID non del nome.
@Joshua / etc / shadow, / etc / groups. Inoltre, `find / etc -type f -exec grep -l root {} +` indica quanti file di configurazione cercano root come root e non UID 0. E questo non tiene conto di tutti gli strumenti che potresti dover ricompilare per il nuovo sistema configurazione ... In un mondo perfetto, tutti direbbero UID 0 invece di root, ma quei maledetti insaccati continuano a mungere tutto.
Stai trascurando il fatto che l'ho provato con successo.
Motivo principale per sudo rispetto al login di root per me: se devi concedere l'accesso di root a più persone, allora vuoi revocarlo per una persona (ad esempio, lui o lei lascia l'azienda). Con sudo, facile. Se hai consegnato la password di root a queste persone, devi cambiarla e tutti gli altri devono memorizzare la nuova password.
@Ohnana [Questo incidente verrà segnalato] (https://xkcd.com/838/) davvero.
#2
+38
schroeder
2016-02-16 03:11:58 UTC
view on stackexchange narkive permalink

Il sito a cui ti colleghi è molto scarso nello spiegare cosa ti stanno portando a fare. L'account root non viene disabilitato, ma piuttosto la password per root è disabilitata. Questo è ciò che fa passwd -l .

L'intento di queste istruzioni è di fare in modo che le persone non possano accedere come utente root, perché l'account root è facile da indovinare. Non sono sicuro che il loro approccio alla creazione di uno pseudo-utente con un "nome difficile da indovinare" sarà molto più sicuro ...

root è infatti l'obiettivo principale dei bot ssh. Se ti dimentichi di disabilitarlo in `sshd_config`, il sistema operativo ti farà il backup.
#3
+16
Tom Leek
2016-02-16 03:12:25 UTC
view on stackexchange narkive permalink

È un'antica tradizione dei tempi del Mainframe. L'idea è che root possa fare ciò che vuole con la macchina, inclusa la sostituzione del kernel o la distruzione delle variabili UEFI, che possono bloccare la macchina. Mentre un account non root non può farlo, a meno che a quell'account non vengano concessi diritti amministrativi tramite sudo , che è ciò che avrai con Ubuntu, e distrugge completamente la logica di cui sopra.

In realtà, disabilitare l'account root è ora utilizzato esclusivamente per placare gli dei più anziani, che:

  1. sono scontrosi;
  2. sono obsoleti;
  3. sono morti da decenni, ma sono ancora adorati da una potente casta di sommi sacerdoti, noti collettivamente come "auditor di conformità".

In pratica , la tua vita digitale è completamente accessibile dal tuo normale account utente, quindi fare qualsiasi protezione relativa all'utente root non ha molto senso. Masticare con la distinzione root / non- root è una cosa del passato, quando le macchine erano grandi server condivisi tra centinaia di utenti che erano probabilmente ostili l'uno all'altro. p>

"la tua vita digitale è completamente accessibile dal tuo normale account utente" - chiede OP nel contesto del rafforzamento del * server *. Ciò presuppone un sistema desktop.
Inoltre, `sudo` registra cose, credo.
C'è un aspetto di responsabilità quando su macchine multiutente. Root è un account generico, quindi qualsiasi cosa fatta da root non può essere legata a un utente (a meno che l'accesso non sia stato elevato da un account utente specifico).
Questa risposta è ironica? O usi ancora l'autenticazione della password invece delle coppie di chiavi?
#4
+5
Mike McManus
2016-02-17 04:51:41 UTC
view on stackexchange narkive permalink

Tieni presente che (almeno su Ubuntu e le sue derivate), c'è un compromesso coinvolto nella disabilitazione della password di root.

In caso di disastro sul tuo sistema, ti consigliamo di avviare il sistema in modalità di ripristino (o utente singolo) dalla console. Se la password di root è disabilitata (come è di default), allora nessuna autenticazione di sorta può essere richiesta quando si avvia in modalità utente singolo, perché l'account di root non ha credenziali da usare per questo scopo, e nessun altro account può essere garantito per funzionare in tali circostanze. Questo è gestito da codice in casi speciali nel programma sulogin.

A conti fatti, però, questo è un mestiere facile da fare: stai impedendo un'intera classe di attacchi remoti mentre apri il sistema a root non autenticati accedi dalla console fisica. Ricorda che non puoi mai proteggere un sistema da un utente malintenzionato con accesso fisico ad esso comunque. Questo è il motivo per cui esistono data center sicuri con controlli elettronici degli accessi.

#5
+2
Alexander C. Solon
2016-02-16 11:46:49 UTC
view on stackexchange narkive permalink

Il root è generalmente disabilitato per fornire un ulteriore livello di sicurezza in tutto il sistema operativo Linux. L'utente root ha la capacità di cambiare letteralmente qualsiasi cosa, indipendentemente dall'importanza. Questo lo rende un bersaglio comune di hacker, virus, ecc. Disattivarlo (o piuttosto disabilitare la password) garantisce che l'account non possa essere loggato se la password viene recuperata (cosa non così difficile da fare).

In realtà, può essere abbastanza difficile "recuperare" una password di root complessa sui moderni sistemi Linux, nonostante l'errore di base dell'utente.
Ci sono sempre i metodi di forza bruta, o se usano una password con qualsiasi tipo di parola, potrebbe essere usata una tabella arcobaleno. In ogni caso, è possibile farlo e se stai utilizzando un server che potrebbe essere un obiettivo popolare (ad esempio un server per Google, Facebook o qualcosa del genere) sarebbe meglio assicurarsi che non accada comunque
Dipende dalla configurazione, ma buona fortuna per la forzatura bruta di una password di root complessa che è stata memorizzata con bcrypt. E poiché le password sono salate (praticamente in tutte le configurazioni possibili, inclusa la maggior parte delle impostazioni predefinite), le tabelle arcobaleno sono inutili.
#6
  0
GAD3R
2016-02-16 17:21:36 UTC
view on stackexchange narkive permalink

Per impostazione predefinita, la password dell'account root è bloccata in Ubuntu.

Perché se l'account dell'utente viene compromesso da un utente malintenzionato, l'attaccante può anche ottenere i privilegi di root la prossima volta che l'utente lo fa. L'account utente è l'anello debole di questa catena e quindi deve essere protetto con la stessa cura di root.

La password dell'account root non deve essere condivisa con chiunque abbia bisogno di eseguire qualche tipo di amministrazione attività sul sistema.

Per disabilitare il tuo account di root usa il seguente comando:

  sudo passwd -dl root  


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...