Perché eseguire named (bind) in chroot è così importante per la sicurezza? O forse no?

Sto giocando con bind e ho iniziato a chiedermi perché questo software è, ad esempio, in CentOS in esecuzione su chroot. Non fraintendermi, so cos'è il legame e a cosa serve chroot (prigione). Ma la mia domanda principale è che legare senza chroot è così insicuro?

È davvero dannoso installarlo senza una prigione (più di qualsiasi altro servizio o software). Nei sistemi ci sono molti processi in esecuzione senza chroot e penso che il compromesso di uno di essi sia molto pericoloso, ma cosa rende più pericoloso il nome di altri software in esecuzione senza chroot?

Come ha menzionato @Some Guy, devi pensarci in una prospettiva storica.

La prospettiva storica era che un singolo componente hardware fosse una dozzina di servizi diversi in un unico sistema operativo. Se un servizio veniva compromesso, veniva compromesso tutto ciò che riguardava quell'hardware.

Con la virtualizzazione questo è molto meno un problema. Sebbene non sia impossibile uscire da una VM, è tutt'altro che banale. È sicuramente più difficile uscire da una macchina virtuale, quindi per un processo in esecuzione con privilegi di root uscire da una chroot. Quindi i miei server bind sono in esecuzione sulla propria VM. In questo caso non ha molto senso un chroot poiché il danno è già limitato semplicemente dal fatto che si tratta di una macchina virtuale.

Un chroot è un tentativo molto debole di creare qualcosa come una VM. I chroot possono essere evitati da qualsiasi processo con privilegi di root. Un chroot non è destinato e non funziona come meccanismo di sicurezza. Un chroot con un jail BSD o LXC offre la virtualizzazione a livello di sistema operativo e offre funzionalità di sicurezza. Ma oggigiorno, essendo così semplice creare una nuova macchina virtuale di un intero computer, potrebbe non valere la pena di configurarlo o imparare a utilizzare gli strumenti di virtualizzazione a livello di sistema operativo a questo scopo.

Le versioni precedenti di bind non rilasciavano privilegi. Su Unix, solo l'account root può aprire porte inferiori a 1024 e Bind come tutti sappiamo deve ascoltare su udp / 53 e tcp / 53. Poiché Bind inizia come root e non rilascia privilegi, qualsiasi compromesso significherebbe compromettere l'intero sistema. Quasi tutti i software in questi giorni inizieranno ad aprire i loro socket e faranno qualsiasi altra cosa che richieda i privilegi di root, quindi cambieranno l'utente che stanno eseguendo in un account non privilegiato. Una volta eliminati i privilegi, l'impatto della compromissione è molto più basso per il sistema host.

Le altre risposte sono piuttosto buone, ma non menzionano il concetto di sicurezza a strati. Ogni livello di sicurezza che aggiungi al tuo sistema è un altro livello che un avversario deve superare. Mettere BIND in un chroot aggiunge un altro ostacolo.

Supponiamo che ci sia una vulnerabilità sfruttabile in BIND e che qualcuno sia in grado di eseguire codice arbitrario. Se sono in chroot, devono uscirne prima di arrivare a qualsiasi altra cosa nel sistema. Come accennato, sono richiesti i privilegi di root per rompere il chroot. BIND non funziona come root, e dovrebbero esserci strumenti minimi disponibili nel chroot, limitando ulteriormente le opzioni e essenzialmente lasciando solo chiamate di sistema. Se non c'è nessuna chiamata di sistema per intensificare i privilegi, l'avversario è bloccato guardando i tuoi record DNS.

La situazione di cui sopra è alquanto improbabile, come menzionato da SomeGuy, BIND ha abbastanza poche vulnerabilità in questi giorni e sono per lo più limitati agli scenari di tipo DoS piuttosto che all'esecuzione remota. Detto questo, l'esecuzione in chroot è la configurazione predefinita su un bel numero di sistemi operativi, quindi è improbabile che tu faccia qualsiasi sforzo da parte tua per mantenere la sicurezza sempre leggermente aumentata.

preambolo

Continuo a sentire le persone ribadire idee sbagliate da tutta Internet. Quindi, cercherò di fornire alcuni chiarimenti

prima di tutto; quante scoperte accidentali ci sono state, che semplicemente ... a causa di causa ed effetto , sono finite per essere utilizzate per qualcosa di diverso dal suo scopo?

che cosa era e che cosa era una prigione di Chroot

Chroot è stato inizialmente progettato per modificare la directory principale per il processo o l'utente (ottimo per la compilazione di software da fonti sconosciute). ciò ha fornito sicurezza al sistema di base, nonché un dispositivo di test rapido, compresa una facile pulizia. sono passati anni da allora, e anche il suo concetto e gli usi impliciti sono certamente cambiati.

chroot è stato usato in modo efficace ed è direttamente nella base di codice per diversi programmi e librerie (ad esempio openSSHd, apache2 + mod_security2 / mod_chroot, dovecot, sendmail, openVPN, pam_chroot e molto altro ). supponendo che tutte queste applicazioni tradizionali abbiano implementato soluzioni di sicurezza difettose non è proprio vero

chroot è una soluzione alla virtualizzazione del file system: niente di meno, niente di più. anche il presupposto che si possa facilmente uscire da un chroot non è vero ... purché si rispettino le linee guida per l'esecuzione dei processi all'interno del carcere chroot.

alcuni passaggi per proteggere la tua prigione chroot

cioè NON eseguire processi come ROOT. questo potrebbe aprire un vettore di escalation di radice (che è anche vero all'interno o all'esterno del chroot). non eseguire un processo all'interno del chroot, utilizzando lo stesso utente di un altro processo esterno al chroot. separare ogni processo e utente nel proprio Chroot al fine di limitare le superfici di attacco e fornire privacy. monta solo i file, le librerie e i dispositivi necessari. infine, chroot NON sostituisce la sicurezza del sistema di base. proteggere il sistema nella sua interezza.

un'altra nota importante: molte persone pensano che OpenVZ sia rotto o che non sia uguale rispetto alla virtualizzazione completa del sistema. fanno questo presupposto perché è essenzialmente un Chroot, con una tabella di processo che è stata sterilizzata. con misure di sicurezza in atto su hardware e dispositivi. la maggior parte delle quali è possibile implementare in un chroot.

non tutti gli amministratori hanno il livello di conoscenza necessario per proteggere tutti i parametri del kernel necessari su un server dedicato o con la virtualizzazione completa del sistema. questo significa che la distribuzione di OpenVZ significa che i tuoi clienti avranno molto meno superficie d'attacco per cercare di coprire e proteggere prima di distribuire le loro applicazioni. un buon host farà un buon lavoro assicurando questi parametri e, a sua volta, questo è meglio non solo per tutti sul nodo o nel data center, ma per Internet nel suo insieme ...

come detto, il chroot fornisce la virtualizzazione del file system. devi assicurarti che non ci siano eseguibili setuid, applicazioni non sicure, librerie, collegamenti simbolici senza proprietario penzolanti, ecc. Se l'attaccante POTREBBE compromettere il legame, avrebbe bisogno di cercare nel file system virtuale qualcosa da bufferare, giocare con i descrittori di file o in qualche modo compromettere qualcosa che risiede all'interno del chroot, sfuggendo alla prigione di solito attraverso l'escalation dei privilegi o iniettando il suo payload nel sistema di base.

se ciò accade, di solito è il risultato di un aggiornamento errato , exploit zero day o errore umano idiomatico .

perché Chroot è ancora usato, al contrario della virtualizzazione completa del sistema

considera questo scenario: stai eseguendo un Virtual Private Server, con il nodo host che esegue OpenVZ. semplicemente non puoi eseguire nulla che funzioni a livello di kernel. questo significa anche che non è possibile utilizzare la virtualizzazione del sistema operativo per separare i processi e fornire ulteriore sicurezza. quindi, DEVI usare chroot per questo scopo.

inoltre, chroot è sostenibile su qualsiasi sistema, indipendentemente dalle risorse disponibili. in poche parole, ha il minimo sovraccarico di qualsiasi tipo di virtualizzazione. questo significa che è ancora importante su molte scatole di fascia bassa.

considera un altro scenario: apache è in esecuzione all'interno di un ambiente virtualizzato. vuoi separare ogni utente. fornire un file system virtualizzato tramite un chroot aggiunto ad apache (mod_chroot, mod_security, ecc.) sarebbe l'opzione migliore per garantire la massima privacy tra gli utenti finali. questo aiuta anche a prevenire la raccolta di informazioni e offre un ulteriore livello di sicurezza.

in poche parole, è importante implementare la sicurezza a strati . Chroot potenzialmente è uno di questi. non tutti e tutti i sistemi hanno il lusso di avere accesso al kernel, quindi chroot STILL ha uno scopo. ci sono una varietà di applicazioni in cui la virtuizzazione del sistema completo è essenzialmente eccessiva.

In risposta alla tua domanda

non uso particolarmente CentOS, ma so che Bind ora abbassa i suoi privilegi prima delle operazioni. suppongo, tuttavia, che il legame sia chrootato a causa della sua storia di vettori di attacco e potenziali vulnerabilità.

inoltre ... ha più senso chroot automaticamente questa applicazione, che no, perché NON TUTTI hanno accesso alla virtualizzazione completa a livello di sistema / sistema operativo. questo a sua volta, e in teoria, aiuta a fornire sicurezza alla base di utenti CentOS:

i fornitori di sistemi operativi semplicemente non vanno in giro supponendo che tutti stiano eseguendo lo stesso sistema. in questo modo, possono aiutare a fornire un ulteriore livello di sicurezza in generale ...

c'è un motivo per cui così tante applicazioni usano questo , e perché ovviamente il tuo sistema operativo lo fa di default: perché è usato come una funzione di sicurezza e funziona. con un'attenta preparazione, come precedentemente affermato, è l'ennesimo ostacolo che il potenziale attaccante deve superare per la maggior parte del tempo, limitando i danni arrecati alla sola prigione chroot.

Ciò è in parte dovuto a ragioni storiche, quando le versioni precedenti di Bind presentavano vulnerabilità di sicurezza gravi e frequenti. Non mi sono davvero aggiornato sull'argomento, ma scommetterei che è molto migliorato dai vecchi tempi.

L'altro motivo, il più pratico, è proprio il fatto che è generalmente distribuito in un ruolo di fronte a Internet e, come tale, è aperto a più attacchi, sondaggi e malizia generale.

Pertanto, come spesso accade la regola empirica in materia di sicurezza: meglio prevenire che curare, soprattutto perché lo sforzo di chroot è relativamente piccolo.