Quali sono le implicazioni sulla sicurezza dell'avvio di un server di origine proxy inverso come utente non privilegiato?

Question

Quali sono le implicazioni sulla sicurezza dell'avvio di un server di origine proxy inverso come utente non privilegiato?

#1 da (1 voti)
#2 da (0 voti)

2

Una raccomandazione comune come parte della sicurezza del server Web è eseguire il daemon del server come utente non privilegiato (ad es. nessuno) in modo che gli exploit che eseguono codice arbitrario possano avere meno effetti indesiderati. Tuttavia, poiché la porta 80 è una "porta privilegiata", il server deve essere avviato come amministratore (ad es .: root) e rilasciare i privilegi nella richiesta ai figli.

Tuttavia, non ho trovato alcuna fonte che discuta le implicazioni sulla sicurezza di avere root in questione quando si esegue un server di origine su una porta non privilegiata che si trova dietro un proxy inverso.

Poiché la porta non è privilegiata, il server di origine non deve necessariamente essere root per il binding. Ci sono motivi di sicurezza per avviare il server di origine come root? Perché non avviare il server come utente non privilegiato per iniziare?

Assumi configurazioni quasi identiche in cui l'unica differenza è che ad esempio A il server di origine viene avviato come root e quindi rilascia i privilegi mentre l'istanza B viene avviata come utente non privilegiato.

webserver

posta benrifkah 18.05.2013 - 00:12

fonte

2 risposte

Leggi altre domande sui tag webserver

L'utente di "www-data" aggiornerà i noti problemi di sicurezza? Mescolando regole firewall stateless e stateful

score 1 · Answer 1

La ragione principale per avviare un servizio come root (che quindi esegue il downgrade a un utente non privilegiato) è aumentare la separazione tra il servizio stesso e ciò che fa il servizio.

L'esempio classico è l'apertura di una porta privilegiata, ma ci sono anche altre operazioni simili. Ad esempio, è possibile che il servizio carichi i file di configurazione a cui non è possibile accedere dal servizio "figlio" una volta che il servizio è in funzione.

Inoltre, solo root può chroot() in una directory jailed o setuid() in un altro utente.

score 0 · Answer 2

Istanza B: Il bambino può uccidere il genitore

Si supponga che entrambe le istanze abbiano una vulnerabilità in base alla quale un utente malintenzionato remoto può creare una richiesta che causa l'esecuzione di codice arbitrario in un processo secondario. Inoltre, si supponga che l'istanza A che inizia come root cancelli i privilegi all'interno del figlio prima di servire le richieste. Questo lascia il processo genitore in esecuzione come root.

Con l'istanza B un utente malintenzionato potrebbe causare l'omissione del genitore del processo figlio e sostituire l'intero daemon del server di origine con il suo demone.

Tuttavia, con l'istanza A il genitore non ascolterà i segnali dal bambino, quindi un utente malintenzionato non sarebbe in grado di uccidere il genitore in questo modo .

Istanza A: il genitore può eseguire il hashing del sistema

Ora assumiamo una vulnerabilità in base alla quale un utente malintenzionato remoto può creare una richiesta che causa l'esecuzione di codice arbitrario nel processo principale .

Con l'istanza A un utente malintenzionato ottiene le chiavi della città perché il genitore è in esecuzione come root e può eseguire codice arbitrario.

Tuttavia, con l'istanza B l'attaccante ottiene un accesso limitato a qualsiasi cosa l'utente non privilegiato possa fare.