it-swarm.it

Qual è il modo più sicuro per ottenere i privilegi di root: Sudo, su o login?

Vorrei avere l'account di root in sicurezza anche se il mio utente non privilegiato è compromesso.

Su Ubuntu è possibile utilizzare Sudo solo per "motivi di sicurezza" per impostazione predefinita. Tuttavia non sono sicuro che sia più sicuro del semplice utilizzo dell'accesso su una console in modalità testo. Ci sono troppe cose che possono andare storte se un utente malintenzionato può eseguire il codice come mio normale utente. Ad esempio aggiungendo alias, aggiungendo cose al mio PATH, impostando i keylogger LD_PRELOAD e X11 solo per citarne alcuni. L'unico vantaggio che posso vedere è il timeout, quindi non dimentico mai di disconnettermi.

Ho gli stessi dubbi su su ma non ha nemmeno un limite di tempo. Alcune operazioni (specialmente IO reindirizzamento) sono più comode con su, ma per quanto riguarda la sicurezza questo sembra essere peggio.

L'accesso su una console in modalità testo sembra essere il più sicuro. Poiché viene avviato da init se un utente malintenzionato può controllare PATH o LD_PRELOAD è già root. Gli eventi di pressione dei tasti non possono essere intercettati dai programmi in esecuzione su X. Non so se i programmi in esecuzione su X possano intercettare [ctrl] + [alt] + [f1] (e aprire una finestra a schermo intero che assomiglia a una console) o è sicuro come [ctrl] + [alt] + [del] su Windows. Oltre a ciò, l'unico problema che vedo è la mancanza di timeout.

Quindi mi sto perdendo qualcosa? Perché i ragazzi di Ubuntu hanno deciso di consentire solo sudo? Cosa posso fare per migliorare la sicurezza di uno qualsiasi dei metodi?

Che dire di SSH? Tradizionalmente il root non può accedere tramite SSH. Ma usare la logica sopra non sarebbe questa la cosa più sicura da fare:

  • consentire il root tramite SSH
  • passa alla modalità testo
  • accedi come root
  • ssh sull'altra macchina
  • accedi come root?
124
stribika

La sicurezza è sempre una questione di compromessi. Proprio come il proverbiale server che si trova in una posizione sicura, non collegata, in fondo all'oceano, root sarebbe la maggior parte sicuro se non ci fosse modo di accedervi affatto.

Gli attacchi LD_PRELOAD e PATH come quelli che descrivi presuppongono l'esistenza di un attaccante con accesso al tuo account o almeno ai tuoi dotfile. Sudo non lo protegge affatto molto bene: se hanno la tua password, dopo tutto, non c'è bisogno di provare a ingannarti per dopo ... possono semplicemente usare Sudo now.

È importante considerare ciò per cui Sudo è stato progettato originariamente: delega dei comandi specifici (come quelli per gestire le stampanti) a "subamministratori" (forse studenti laureati in un laboratorio) senza dare completamente radice . Usare Sudo per fare tutto è l'uso più comune che vedo ora, ma non è necessariamente il problema che il programma doveva risolvere (da qui la sintassi ridicolmente complicata del file di configurazione).

Ma Sudo-for-unrestricted-root lo fa risolve un altro problema di sicurezza: la gestibilità delle password di root. In molte organizzazioni, queste tendono ad essere scambiate come caramelle, scritte su lavagne e lasciate le stesse per sempre. Ciò lascia una grande vulnerabilità, poiché la revoca o la modifica dell'accesso diventa un grande numero di produzione. Anche tenere traccia di quale macchina ha quale password è una sfida - per non parlare del monitoraggio who know quale.

Ricorda che la maggior parte dei "crimini informatici" proviene dall'interno. Con la situazione della password di root descritta, è difficile rintracciare chi ha fatto cosa - qualcosa che il Sudo con la registrazione remota gestisce abbastanza bene.

Sul tuo sistema di casa, penso che sia davvero più una questione di comodità di non dover ricordare due password. È probabile che molte persone li stessero semplicemente impostando per essere uguali - o peggio, impostandoli inizialmente uguali e poi lasciandoli fuori sincrono, lasciando marcire la password di root.

L'uso delle password affatto per SSH è pericoloso, poiché i demoni ssh trojan sniffati con password vengono messi in atto in qualcosa come il 90% dei compromessi del sistema reale che ho visto. È molto meglio usare le chiavi SSH, e questo può essere un sistema praticabile anche per l'accesso root remoto.

Ma ora il problema è che sei passato dalla gestione delle password alla gestione delle chiavi e le chiavi ssh non sono davvero molto gestibili. Non c'è modo di limitare le copie e se qualcuno ne fa una copia, ha tutti i tentativi che vuole forzare la passphrase. Puoi stabilire una politica dicendo che le chiavi devono essere archiviate su dispositivi rimovibili e montate solo quando necessario, ma non c'è modo di applicarlo - e ora hai introdotto la possibilità che un dispositivo rimovibile venga perso o rubato.

La massima sicurezza arriverà attraverso chiavi singole o token crittografici time/counter-based. Questi possono essere eseguiti tramite software, ma l'hardware a prova di manomissione è ancora migliore. Nel mondo open source, c'è WiKiD , YubiKey o LinOTP , e ovviamente c'è anche il peso massimo proprietario RSA SecurID . Se fai parte di un'organizzazione medio-grande, o anche piccola, attenta alla sicurezza, consiglio vivamente di esaminare uno di questi approcci per l'accesso amministrativo.

Probabilmente è eccessivo per la casa, tuttavia, in cui non si hanno davvero i problemi di gestione, purché si seguano pratiche di sicurezza sensate.

105
mattdm

Questa è una domanda molto complessa. mattdmha già coperto molti punti .

Tra su e Sudo, se consideri un singolo utente, su è un po 'più sicuro in quanto un utente malintenzionato che ha trovato la tua password non può ottenere immediatamente i privilegi di root. Ma tutto ciò che serve è che l'attaccante trovi un buco radice locale (relativamente raro) o installi un trojan e aspetti che tu esegua su.

Sudo presenta vantaggi anche rispetto all'accesso alla console in presenza di più utenti. Ad esempio, se un sistema è configurato con registri remoti a prova di manomissione, puoi sempre scoprire chi ha eseguito Sudo l'ultima volta (o il cui account è stato compromesso), ma non sai chi ha digitato la password di root sulla console.

Sospetto che la decisione di Ubuntu sia stata in parte nell'interesse della semplicità (solo una password da ricordare) e in parte nell'interesse della sicurezza e della facilità di distribuzione delle credenziali su macchine condivise (affari o famiglia).

Linux non ha una chiave di attenzione sicura o un'altra interfaccia utente sicura per l'autenticazione. Per quanto ne so, anche OpenBSD non ne ha. Se sei così preoccupato per l'accesso root, potresti disabilitare del tutto l'accesso root da un sistema in esecuzione: se vuoi essere root, dovresti digitare qualcosa al prompt del bootloader. Questo ovviamente non è adatto a tutti i casi d'uso. (* BSD's securelevel funziona in questo modo: a un livello di sicurezza elevato, ci sono cose che non puoi fare senza riavviare, come abbassare il grado di sicurezza o accedere direttamente ai dispositivi raw montati.)

Limitare i modi in cui si può diventare root non è sempre un vantaggio per la sicurezza. Ricorda il terzo membro della triade di sicurezza : riservatezza , integrità , disponibilità . Bloccarsi fuori dal sistema può impedire di rispondere a un incidente.

I progettisti della distribuzione protetta OpenWall GNU/*/Linux hanno anche espresso opinioni critiche su su (per diventare root) e Sudo. Potresti essere interessato a leggere questa discussione:

... sfortunatamente sia su che Sudo sono sottilmente ma fondamentalmente imperfetti.

Oltre a discutere i difetti di su e altre cose, Solar Designer si rivolge anche a un motivo specifico per usare su:

Sì, era una saggezza comune tra i sysadmin "su root" piuttosto che effettuare il login come root. Quei pochi che, quando richiesto, potrebbero effettivamente trovare un motivo valido per questa preferenza farebbero riferimento alla migliore responsabilità raggiunta con questo approccio. Sì, questa è davvero una buona ragione a favore di questo approccio. Ma è anche l'unico. ...(leggi di più)

Nella loro distribuzione, hanno "completamente eliminato i programmi root SUID nell'installazione predefinita" (cioè, incluso su; e non usano le funzionalità per questo):

Per i server, penso che le persone debbano riconsiderare e, nella maggior parte dei casi, vietare l'invocazione di su e Sudo da parte degli utenti. Non c'è sicurezza aggiuntiva dal vecchio "login come non-root, quindi su o Sudo per root" sysadmin "saggezza", rispetto al login come non-root e come root direttamente (due sessioni separate). Al contrario, quest'ultimo approccio è l'unico corretto, dal punto di vista della sicurezza:

http://www.openwall.com/lists/owl-users/2004/10/20/6

(Per rendere conto di più amministratori di sistema, il sistema deve supportare la presenza di più account con privilegi di root, come fa Owl.)

(Per i desktop con X, questo diventa più complicato.)

Devi anche assolutamente avere a che fare con ...

A proposito, dovevano sostituire sulogin con msulogin per consentire l'installazione con più account root: msulogin consente di digitare anche il nome utente quando si passa alla modalità utente singolo (e si preserva la "responsabilità") (queste informazioni provengono da questa discussione in russo ).

Sembra che tu supponga che l'uso di Sudo preservi sempre le variabili di ambiente, ma non è sempre così. Ecco un estratto dalla manpage del Sudo:

Esistono due modi distinti per gestire le variabili di ambiente. Per impostazione predefinita, l'opzione suvers env_reset è abilitata. Questo fa sì che i comandi vengano eseguiti con un ambiente minimo contenente TERM, PATH, HOME, Shell, LOGNAME, USER e USERNAME oltre alle variabili del processo di invocazione consentite dalle opzioni suvers env_check ed env_keep. Esiste effettivamente una whitelist per le variabili di ambiente.

Se, tuttavia, l'opzione env_reset è disabilitata nei sudoer, tutte le variabili non esplicitamente negate dalle opzioni env_check ed env_delete vengono ereditate dal processo di invocazione. In questo caso, env_check e env_delete si comportano come una lista nera. Poiché non è possibile inserire nella blacklist tutte le variabili di ambiente potenzialmente pericolose, si consiglia di utilizzare il comportamento predefinito env_reset.

In tutti i casi, le variabili di ambiente con un valore che inizia con () vengono rimosse in quanto potrebbero essere interpretate come funzioni bash. L'elenco delle variabili di ambiente che Sudo consente o nega è contenuto nell'output di Sudo -V quando eseguito come root.

Quindi se env_reset è abilitato (impostazione predefinita), un utente malintenzionato non può ignorare PATH o altre variabili di ambiente (a meno che non le si aggiunga specificamente a una whitelist di variabili che devono essere conservate).

4
Cedric

L'approccio più sicuro è l'accesso ssh utilizzando (almeno) chiave lunga 2048 (con accesso password disabilitato) utilizzando un dispositivo fisico per memorizzare la chiave.

4
Šimon Tóth

Voglio solo aggiungere qualcosa un po 'fuori tema. (per l'argomento selezionare "/ bin/su -" qui dopo)

Penso che la "sicurezza" di cui sopra dovrebbe anche essere collegata ai dati reali che vogliamo proteggere.

Sarà e dovrebbe essere diverso se vogliamo proteggere: my_data, my_company_data, my_company_network.

Di solito, se parlo di sicurezza, parlo anche di "sicurezza dei dati" e backup. Possiamo anche aggiungere sistemi tolleranti ai guasti e simili.

Alla luce di ciò, penso che la sicurezza nel suo insieme sia un equilibrio tra l'usabilità, la "sicurezza dei dati" e lo sforzo necessario per implementare un sistema sicuro.

L'obiettivo di Ubuntu era, e per lo più è ancora, l'utente finale: Sudo è l'impostazione predefinita.

Fedora è la versione gratuita di RedHat che a sua volta è più orientata ai server: il Sudo era disabilitato.

Per le altre distribuzioni non ho informazioni dirette.

Sto usando in questo momento, principalmente, Fedora. E da vecchio utente non ho mai digitato "su". Ma posso digitare "/ bin/su -" in brevissimo tempo anche se non sono esattamente un dattilografo. La variabile PATH .. non dovrebbe essere un problema (scrivo il percorso). Anche il "-" (meno) in linea di principio dovrebbe rimuovere le variabili di ambiente dell'utente e caricare solo quelle di root. cioè evitando alcuni possibili problemi extra. Probabilmente anche LS_PRELOAD.

Per il resto immagino che @mattdm fosse abbastanza preciso.

Ma mettiamolo nella scatola corretta. Supponiamo che uno smart kit di scripting abbia accesso ai miei dati. Cosa diavolo pensi che ci farà? - Pubblica le mie foto? mio? - Stai cercando di scoprire il nome della mia ragazza e dirle che visito siti porno?

Nella foto di un singolo utente le due peggiori situazioni sono: - Il bambino elimina tutti i miei dati: per divertimento o per errore - Il bambino usa la mia macchina per creare un ulteriore attacco a qualche altra entità. O obiettivi simili.

Per il primo caso, ho menzionato sopra, meglio impegnarsi su un backup piuttosto che sulla sicurezza della rete. Sì, sei salvo. Voglio dire, un incidente hardware non è poi così diverso.

Il secondo caso è più sottile. Ma ci sono segnali su queste attività. In ogni caso, puoi fare il possibile, ma non configurerei il mio PC di casa per essere protetto da attacchi terroristici!

Salterò gli altri scenari.

salute F

3
user5520

Se la preoccupazione è che un account utente compromesso può essere utilizzato per annusare la password utilizzata per Sudo o su, quindi utilizzare un passcode monouso per Sudo e su.

È possibile forzare l'uso di chiavi per utenti remoti, ma ciò potrebbe non essere necessario per scopi di conformità. Potrebbe essere più efficace impostare un box gateway SSH che richiede un'autorizzazione a due fattori, quindi consentire l'uso della chiave da lì. Ecco un documento su tale configurazione: Proteggi la tua distribuzione SSH con autenticazione a due fattori WiKID .

2
nowen

Puoi anche dare un'occhiata a privacyIDEA , che non ti offre solo la possibilità di usare OTP per accedere alla macchina (o per fare su/Sudo) ma può anche fare OTP offline.

Inoltre è in grado di gestire le tue chiavi SSH. Cioè se hai molte macchine e diversi utenti root, tutte le chiavi SSH sono memorizzate centralmente. Quindi è facile "revocare"/cancellare una chiave SSH, se la chiave non può più essere considerata attendibile.

Naturalmente ci sono attività organizzative e flussi di lavoro, per proteggere il sistema.

0
cornelinux