Perché l'account amministratore di sistema * nix (root) dovrebbe avere una password complessa se gli accessi root remoti sono disabilitati?

Se si segue il principio del minimo privilegio e della sicurezza a più livelli, è necessario assicurarsi che a ogni livello di un sistema vengano implementate misure di sicurezza avanzate. Ad ogni livello significa che non fai alcuna ipotesi su quanto sia facile / difficile per un attaccante arrivare a quel livello in primo luogo.

Quando scrivi

As a consequence of the above, to gain root access remotely, you first need to break into an ordinary user's account, then additionally escalate to root access. In this case, the password on the root account only protects against a password-cracking attack on the root account, not any of the other multitude of possible ways for an attacker to escalate privileges.

hai perfettamente ragione, ma perché dici

only protects against a password-cracking attack

? Una password sicura elimina questo vettore di attacco anche se potrebbero rimanere altri vettori di attacco per aumentare i privilegi. Anche gli altri vettori di attacco devono essere presi in considerazione.

La password di root è la protezione per evitare che gli utenti ordinari possano avviare comandi amministrativi. L'unico caso in cui la password di root potrebbe essere debole è che qualsiasi utente nel sistema (compresi gli utenti daemon come www o postgresql) può utilizzare sudo per ottenere l'accesso amministrativo senza password o, più precisamente, avere un la password di root è più o meno equivalente a quella strana di configurazione

Perché anche il normale sudo richiede che l'utente:

• ha una password normale (gli utenti daemon solitamente hanno una respingono tutta la password)
• conosce la propria password

Quindi, se un utente malintenzionato viola la sicurezza di un'applicazione e ottiene l'accesso a un utente non root, dovrà comunque trovare una password per ottenere l'accesso come root. E se la password di root è debole sarà molto più semplice passare quella seconda barriera.

Nella tua domanda hai coperto solo due aree: l'aspetto fisico e gli attacchi di un aggressore normale . Se l'attaccante è più determinato o meglio finanziato, è lecito ritenere che lui / lei abbia accesso a attacchi più sofisticati - forse anche 0 giorni non dichiarati. Se il tuo sistema è stato violato, come hai detto tu, ci sono ancora decine di modi in cui un utente malintenzionato potrebbe aumentare i suoi privilegi, ma perché non provare alcune password facili per aumentare i privilegi? (Adoro un MD5 che inizia con 5f4d.. :))

Inoltre, molti utenti (anche gli amministratori attenti alla sicurezza) tendono a riutilizzare le password. Questo è un fatto ben noto. Richiedendo che l'account root abbia una password complessa, si riducono le possibilità dell'amministratore di voler digitare di nuovo quella stringa in altre applicazioni, che potrebbero non memorizzare le password in modo sicuro. Questo tipo di riduce la possibilità di riutilizzo della password.

Come qualcuno nelle risposte collegate già menzionate - potresti semplicemente attaccare l'utente in un sacco di modi diversi (permetti di scaricare un binario backdoored, MITM il loro traffico e poi tentare di accedere a un account alternativo creato dallo stesso utente, crea una applicazione dannosa (sì, sembra inverosimile, ma - ehi.)

Metto la testa sul ceppo - Nella maggior parte dei casi, non penso che tu debba davvero preoccuparti della tua password di root . Se sei sicuro del resto delle tue abitudini di sicurezza, nessuno può impedirti di usare password123# (ma semplicemente mandami un link al tuo server: P)

C'è anche un aspetto legale in questo. Se il tuo server è stato violato, e nella successiva indagine è stato trovato che la tua password di root era debole, è possibile che eventuali sanzioni inflitte sarebbero aumentate, a causa di una mancanza percepita di due diligence, anche se, come precedentemente notato, l'effettiva il rischio è minimo È un ragionamento simile dietro i problemi di sicurezza, sia sui computer che in altro modo: i rischi derivanti dall'avere una password del server scritta in una stanza protetta che ha un accesso ristretto completamente limitato sono minime, ma se li tenete su una scrivania lì, piuttosto che in un casella / cassetto bloccati, è possibile che vengano rilevati dei controlli.

Anche se il rischio legale non si applica, ci sono argomenti simili per i potenziali aspetti reputazionali. La maggior parte delle persone che leggono questo sito sa che i rischi reali sono minimi, date le altre precauzioni correttamente implementate, ma sono in minoranza. Considera che è abbastanza noto che per molto tempo i codici di lancio nucleari per gli Stati Uniti erano "00000000", ma l'accesso a un sistema che ti permetteva di entrare non era banale - i rapporti su questo tendevano a concentrarsi su "guarda la password davvero facile da indovinare "piuttosto che" se hai ottenuto l'accesso appropriato, da una rete strettamente controllata, e hai convinto il personale di turno che eri autorizzato, e avevi le credenziali precedenti appropriate, potresti lanciare un missile premendo e tenendo premuto 0 ".

C'è un'alternativa in cui non hai bisogno di quella password complessa: blocca l'account di root.

In tal caso, potresti evitare di impostare una password sicura per quell'account. In realtà, probabilmente farei entrambi, perché non richiede molto sforzo.

Vedi link per una discussione su questo.

In generale, ha più senso vedere ciò che sudo può fare per te, piuttosto che fornire la possibilità a su - root .

Un'area chiave in cui ciò è importante è il controllo: con sudo (anche se qualcuno esegue sudo -i o sudo su - root ), puoi comunque ottenere informazioni sull'utente reale che fa tutto questo (registrato da auditd come AUID).