Il modo migliore per sandbox Apache su Linux

Question

Ho Apache in esecuzione su un server Debian pubblico e sono un po 'preoccupato per la sicurezza dell'installazione. Questa è una macchina che ospita diversi progetti di hobby per il tempo libero, quindi nessuno di noi che usa la macchina ha davvero il tempo di controllare costantemente le patch a monte, stare attento ai problemi di sicurezza, ecc. Ma vorrei tenere fuori i cattivi o, se entrano, tienili in una sandbox.

Quindi qual è la soluzione migliore, facile da configurare e da mantenere? È facile configurare un sandbox linux in modalità utente su Debian? O forse una prigione chroot? Mi piacerebbe avere un facile accesso ai file all'interno del sadbox dall'esterno. Questa è una di quelle volte in cui mi risulta molto chiaro che sono un programmatore, non un amministratore di sistema. Qualsiasi aiuto sarebbe molto apprezzato!

Answer 1

Le jail chroot possono essere davvero insicure quando si esegue un ambiente sandbox completo. Gli aggressori hanno accesso completo alla funzionalità del kernel e, ad esempio, possono montare unità per accedere all'host " sistema.

Suggerirei di usare linux-vserver. Puoi vedere linux-vserver come una prigione chroot migliorata con un'installazione debian completa all'interno. È veramente veloce poiché è in esecuzione all'interno di un singolo kernel e tutto il codice viene eseguito in modo nativo.

Uso personalmente linux-vserver per la separazione di tutti i miei servizi e ci sono solo differenze di prestazioni appena percettibili.

Dai un'occhiata al linux-vserver wiki per le istruzioni di installazione.

saluti, Dennis

Answer 2

Secondo ciò che dice xardias, ma raccomando invece OpenVZ .

È simile a Linux-Vserver, quindi potresti voler confrontare quei due quando vai su questa strada.

Ho configurato un server web con un server http proxy ( nginx ), che quindi delega il traffico a diversi OpenVZ contenitori (in base al nome host o al percorso richiesto). All'interno di ciascun contenitore è possibile configurare Apache o qualsiasi altro server web (ad esempio nginx, lighttpd, ..). In questo modo non hai un Apache per tutto, ma potresti creare un contenitore per qualsiasi sottoinsieme di servizi (ad es. Per progetto).

I contenitori OpenVZ possono essere facilmente aggiornati del tutto (" per i in $ (vzlist); vzctl exec apt-get upgrade; done ")

I file dei diversi contenitori sono memorizzati nel nodo hardware e quindi è possibile accedervi facilmente SFTP nel nodo hardware. A parte ciò, potresti aggiungere un indirizzo IP pubblico ad alcuni dei tuoi contenitori, installare lì SSH e quindi accedervi direttamente dal contenitore. Ho anche sentito da proxy SSH, quindi l'indirizzo IP pubblico extra potrebbe non essere necessario anche in quel caso.

Answer 3

Puoi sempre configurarlo all'interno di una macchina virtuale e conservarne un'immagine, quindi puoi ripetere il roll-up se necessario. In questo modo il server viene estratto dal tuo computer reale e qualsiasi virus o giù di lì è contenuto all'interno della macchina virtuale. Come ho detto prima, se si mantiene un'immagine come backup, è possibile ripristinare abbastanza facilmente lo stato precedente.

Answer 4

Per essere sicuro che sia detto, le Jail CHRoot raramente sono una buona idea che, nonostante l'intenzione, sia molto facile da evadere, infatti l'ho visto accidentalmente fatto dagli utenti!

Answer 5

Senza offesa, ma se non hai tempo di controllare le patch di sicurezza e di essere consapevole dei problemi di sicurezza, dovresti preoccuparti, indipendentemente dalla configurazione. D'altra parte, il semplice fatto che stai pensando a questi problemi ti distingue dall'altro 99,9% dei proprietari di tali macchine. Sei sulla strada giusta!

Answer 6

Trovo sorprendente che nessuno abbia menzionato mod_chroot e suEXEC , che sono le cose di base da cui partire e, molto probabilmente, le uniche cose di cui hai bisogno.

Answer 7

Dovresti usare SELinux. Non so quanto sia supportato su Debian; in caso contrario, installare un Centos 5.2 con SELinux abilitato in una macchina virtuale. Non dovrebbe essere troppo lavoro e molto più sicuro di qualsiasi chrooting amatoriale, che non è sicuro come la maggior parte della gente crede. SELinux ha la reputazione di essere difficile da amministrare, ma se stai solo eseguendo un server web, questo non dovrebbe essere un problema. Potresti semplicemente fare un po 'di "sebool" per consentire a httpd di connettersi al DB, ma questo è tutto.

Answer 8

Mentre tutti i precedenti sono buoni suggerimenti, suggerisco anche di aggiungere una regola iptables per impedire connessioni di rete in uscita impreviste. Poiché la prima cosa che fanno gli exploit Web più automatici è scaricare il resto del loro payload, impedire la connessione di rete può rallentare l'attaccante.

Alcune regole simili a queste possono essere utilizzate (attenzione, il tuo server web potrebbe aver bisogno di accedere ad altri protocolli):     iptables --append OUTPUT -m proprietario --uid-owner apache -m state --state STABILITO, CORRELATO - jump ACCEPT     iptables --append OUTPUT -m proprietario --uid-owner apache --protocollo udp --destination-port 53 --jump ACCEPT     iptables --append OUTPUT -m proprietario --uid-owner apache --jump REJECT

Answer 9

Se usi Debian, debootstrap è il tuo amico associato a QEMU, Xen, OpenVZ, Lguest o una pletora di altri.

Answer 10

Crea una macchina virtuale. prova qualcosa come vmware o qemu

Answer 11

Quale problema stai davvero cercando di risolvere? Se ti interessa cosa c'è su quel server, devi impedire agli intrusi di accedervi. Se ti interessa cosa farebbero gli intrusi con il tuo server, devi limitare le capacità del server stesso.

Nessuno di questi problemi potrebbe essere risolto con la virtualizzazione, senza compromettere seriamente il server stesso. Penso che la vera risposta al tuo problema sia questa:

1. esegui un sistema operativo che ti fornisce un meccanismo semplice per gli aggiornamenti del sistema operativo.
2. utilizza il software fornito dal fornitore.
3. esegui il backup di tutto spesso.