Newsgroup: it.comp.os.linux.sys
Titolo: Apache, PHP, sicurezza, carico server ...

Ciao,
mi capita spesso di dover mettere le mani su server
con diverse decine o centinaia di domini che
presentano carichi della CPU molto elevati ( load avarage ) ma a tratti.
Nel 99% dei casi si tratta di Apache che ciuccia tutta la CPU.
e fra questi, nel 90% dei casi si tratta o di script bacati
o di exploit lanciati da remoto e caricati in dir a 777.
Domandona: come rilevo lo script dannoso ?
Come limitare i danni ?
L'unica idea che mi ï¿œ venuta ï¿œ "compartimentare" il server
tramite la creazione di N VSERVER x sito .. ma non ï¿œ sempre fattibile
e rende la gestione piï¿œ macchinosa.
Oppure crare una partizione per la dir pubblicata da apache
e montarla con noexec .. ma non so se sia risolutivo ..
Oppure passo ore alla ricerca con lsof ...
trova la magagna, faccio pulizia .. ma dopo x giorni siamo dacapo.
PHP come FastCGI non l'ho mai provato ( normalmente lo installo come 
modulo ) puï¿œ aiutare ?
Sostituire Apache con Lighttp ? ( la butto li .. non penso possa aiutare  )
Grazie per le idee
-- Yena --

 o di exploit lanciati da remoto e caricati in dir a 777.
Bloccare l'esecuzione di script/software/ecc da directory con permessi 
tipo quello sopra indicato puï¿œ essere una delle vie risolutive. Se non 
sbaglio, mod_security per apache fa questo per te ;-)
Enrico

  )
Non serve a nulla.

 con TOP (non è apache a palla ma solo lo script).
Io uso suPhp anzichè suexec, lo trovo più versatile.
-- 
g4b0, linux user n. 369000
http://gabo.homelinux.com

 Io uso suPhp anzichè suexec, lo trovo più versatile.
Ancora meglio mod-itk, imho.
Almeno ti fa girare tutto apache con i permessi utente e non
solo lo script in php.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 Io uso suPhp anzichè suexec, lo trovo più versatile.
Ad ognuno i suoi gusti.
L'unica mia considerazione è:
fcgi+suexec : suphp = mod_php : cgi puro
Ovvero: Le prestazioni di fcgi non sono nemmeno paragonabili a quelle di 
CGI puro (che forka ogni richiesta e richiede molte + risorse ed è + 
lento).

 script in php.
Since mpm-itk has to be able to setuid(), it runs as root.
Io apache non lo farei MAI girare come root, viste le vuln che comunque 
ci sono state negli anni precedenti.


In effetti avevo letto di questa limitazione, ma se devo essere sincero 
non ne ho mai risentito.. Non credo che prestazionalmente avere qualche 
processo in più che gira possa essere deleterio quanto il codice mal 
scritto dei vari joomla&co che girano sul web server. In fin dei conti 
se uno script per generare del codice dinamico trita per 20 secondi e mi 
fa 50 query che differenza ho se gli dedico un porocesso o meno?
Spero di essere contraddetto, e mi accingo a testare fcgi+suexec, che in 
effetti conosco poco.


 effetti conosco poco.
Beh se il codice è scritto male o il DB gira su un 486DX266, posso 
concordare che non ha senso.
Se il webserver fa 4 accessi in croce posso concordare che una soluzione 
vale l'altra.
Se il webserver deve fare roba seria ed è seriamente caricato, non puoi 
nemmeno fare un confronto tra le due soluzioni perchè sarebbe come 
confrontare una 500 ed una ferrari.
Inoltre, il problema non è avere o meno qualche processo in più che gira.
Con suexec+fastcgi hai lo stesso numero di processi, se non di più.
Solo che li hai già pronti ad eseguire la richiesta. Con CGI o suphp, 
invece, devi fare una fork, lanciare l'interprete blah blah...
Se hai voglia/tempo, usa ab (apache bench) in apache-utils per fare dei 
confronti.

 ci sono state negli anni precedenti.
Anni precedenti....
Me ne trovi una attuale? Inoltre, facciamo una proporzione:
quante vulnerabilità di php/perl/quelchevuoi ci sono per ogni
singola vulnerabilità del core di apache?
Facciamo anche una seconda valutazione:
quanti hacker veri esistono, che si metterebbero a bucare il
server grazie ad una vulnerabilità di apache, rispetto ad una
vulnerabilità di php eseguita da un lamer? Per me il rapporto
è grossomodo 100.000:1, per ogni hacker vero in grado di bucare
un apache sfruttando le sue vulnerabilità ci son 100.000 lamer.
E poi, da fuori, come fai a sapere che apache gira come root?
Ovviamente non metterei mai ITK su un sito della banca, ma su
un server shared dove ci girano dei blog, chi può avere interesse
a bucare tale macchina ed a che pro, considerato che dovrebbe fare
una analisi delle vulnerabilità e visto che apache non gira come root
da millenni, devi avere una bella voglia a prendere di mira un blog
e cercare di bucarlo passando da apache piuttosto che da wordpress.
Inoltre, devi trovare il modo di bucare apache prima della chiamata
al vhost perchè da li in poi avresti i permessi utente.
(non per polemizzare, vorrei avere una opinione)


 confronti.
Appena tiro su un server con suexec+fastcgi provo un bel bench, sono 
proprio curioso..


 processo, ma la logica applicativa di ciò che ci gira sopra.
Ni.
Applicativamente parlando ci sono infiniti modi per ottimizzare una 
applicazione (cache delle pagine o delle query, ad esempio).
Quando l'applicazione è ottimizzata, usare fastcgi o un metodo che ad 
ogni richiesta fa un fork() ti porta a grosse differenze.
Per reggere lo stesso carico che reggo con fastcgi dovrei, su alcuni 
cluster, triplicare le macchine.
Gestisco siti "piuttosto trafficati", quindi qualcosa ne so.
Anche quando hai applicazioni scritte a cazzo, un server con fcgi 
gestisce MOLTE più connessioni contemporanee di uno che fork()a ad ogni 
richiesta.
Su questo non ci sono dubbi.

 (non per polemizzare, vorrei avere una opinione)
Ho visto exploit 0day fare molti danni, più di quanti voi umani possiate 
immaginare.
Se apache non gira come root, io dormo più tranquillo.
Il mio sonno non ha prezzo.


Mi fai venire voglia di buttare un occhio a fcgi, anche se i siti che 
gestisco non sono "piuttosto trafficati", bensì "piuttosto scritti alla 
cazzo" :)


 con TOP (non è apache a palla ma solo lo script).
Quindi ricapitolando provo questa configurazione:
Mod security per proteggere le dir 777
PHP Fast-CGI
"Aiuta perchè se hai uno script PHP che si impalla, lo identifichi subito
con TOP (non è apache a palla ma solo lo script)."
Questo non è affatto male !
/tmp montata con "nosuid,noexec,nodev"
Metterei anche una cache x php tipo e-Accelerator o xCache ..
Infine cosa ne dite, estensioni di php tipo Suhosin servono ?
-- Yena --

 ha prezzo.
Lol, quoto.

whiplash ha scritto:

LOL quoto.

 Metterei anche una cache x php tipo e-Accelerator o xCache ..
php-apc

 Il mio sonno non ha prezzo.
L'importante è che per tutto il resto ci sia mastercard.

 /tmp montata con "nosuid,noexec,nodev"
Direi che puoi montare tutto in nosuid,noexec,nodev eccetto la /
e poche altre cose.
Dipende da come hai partizionato.
Fai una partizione per mysql, una per il web ed una per la posta
e monta tutto in nosuid,noexec,nodev

 (non per polemizzare, vorrei avere una opinione)
Permettimi di aggiungere un'ultima nota:
Le tue considerazioni mi ricordano tanto Giacobbo e Voyager, nella loro 
logica e schiettezza.

 - apache come utente non privilegiato
-----------------------------------------
Ora è più chiaro ?
Prova fcgid+suexec, nel caso tu non abbia capito come funziona.

 comunque ci sono state negli anni precedenti.
Apache parte comunque sempre come root e poi abbassa i privilegi.
Farlo un attimo dopo aver caricato un modulo non mi pare tutto 'sto
problema...
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
CBR600F "Cerbero" - In vendita - 
http://www.slimmit.com/go.asp?7X0
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

 problema...
Ok Ok :-D
non hai capito una cippa di cosa si sta parlando!

 ha scritto nel messaggio
news:ha5hop$qgv$
1...@nnrp.ngi.it

Ok, allora appena scendi dalla cattedra puoi spiegarmi cosa c'� di
errato in ci� che ho detto?
Tu apache non lo avvii come root e poi i child droppano i privilegi?


 richiesta.
Hai per caso provato acceleratori come eaccelerator o apc con fcgid? Io 
ci avevo provato tempo fa, ma probabilmente avevo sbagliato io la 
configurazione, e ad ogni script mi perdeva la cache, quindi era come non 
averlo (anzi, peggio).
Sto provando, su un server di test, itk proprio per vedere se poi 
funzionano le cache.
Grazie.
Bye.

 Tu apache non lo avvii come root e poi i child droppano i privilegi?
Quello e' il modo "classico" ed e' usato se Apache deve ascoltare
sulla porta 80/443 che richiedono un utente privilegiato. Un modo
diverso e' far funzionare Apache senza privilegi di root fin
dall'inizio in modo che non vi sia NESSUN processo con privilegi di
root in funzione e chrootare Apache da qualche parte. Quanto sia piu'
o meno "sicuro" e' questione di opinioni.
In ogni caso, l'avere n centinaia di web-applicascion di cui *non si
sa una cippa* e' sempre una brutta cosa ed una soluzione "perfetta"
non esiste.
Davide

 Prova fcgid+suexec, nel caso tu non abbia capito come funziona.
fcgid+suexec ti consente di far girare tutti gli script con
utente non privilegiato o solo php?
Nel caso volessi far girare uno script python (non ho idea di come
si faccia, è solo un esempio), con fcgid potrei farlo?
suphp, ad esempio, fa girare solo il php.....

 Tu apache non lo avvii come root e poi i child droppano i privilegi?
Con ITK apache gira sempre come root.
Lo avvii come root e sta in esecuzione come root.
I privilegi vengono droppati solo in fase vhost, banalmente
dopo aver inviato "Host:" al server.
Tutto quello che accade prima viene fatto come root.
In condizioni normali, invece, hai la prima istanza di apache che
gira come root e poi forka i figli con i privilegi droppati.
In tal caso, tu ti colleghi ad un child che ha i privilegi di nobody,
mentre nel mio caso ti colleghi ad un child che ï¿œ root, finchï¿œ non gli
arriva il comando che gli indica un vhost di riferimento.

 non esiste.
Purtroppo vero, io ho usato a volte qualche script per scandagliare
tutti i nuovi php uploadati alla ricerca di vulnerabilit� 'classiche' 
(header
delle mail che arrivano dal form, upload senza controllare il mimetype),
ma la fantasia degli utenti a volte � inarrivabile.


 dopo aver inviato "Host:" al server.
Ok, avevo capito, ma a parte una grossa vulnerabilit� del server
direttamente sull'input non mi sembra cos� pericoloso.
Si sono gi� viste situazioni che permettevano di fare privilege
escalation anche se avevi il child non-privileged.
A questo punto se vuoi stare tranquillo root non va proprio usato,
come diceva Davide, salvo poi dover usare sistemi alternativi
per collegare httpd alla 80.
E poi mi sembra pi� probabile che un attaccante provi ad attaccarti
pensando che il tuo server _non sia_ root, com'� lo standard,
piuttosto che il contrario.
Leggendo il thread, comunque, mi pareva che il problema non fosse
il proteggere la macchina dagli attacchi esterni al webserver, ma
dagli attacchi (o semplicemente dai malfunzionamenti) agli script
scritti male. E per questo, root o non root non cambia molto...


 suphp, ad esempio, fa girare solo il php.....
suexec è a prescindere da php.
fcgid è a prescindere da php.
tutti gli script possono essere messi dietro suexec.
tutto ciò che supporta il protocollo fastcgi può essere messo dietro 
fcgid.
Se hai uno script in bash, python, ruby o quellochevuoi, può girare con 
l'utente che vuoi.

 Hai per caso provato acceleratori come eaccelerator o apc con fcgid?
Uso felicemente APC senza configurazioni particolari e fa il suo sporco 
dovere.
Non uso più eaccelerator, preferendo APC che fa le stesse cose ma almeno 
nasce e vive insieme al PHP.

 piuttosto che il contrario.
E' esattamente quel che dico io.
Inoltre, come ho scritto, il 99.9% degli attacchi a server "normali"
(non banche e cose simili) son fatti da lamer che sfruttano qualche
vulnerabilitï¿œ del codice PHP, non tanto da veri e propri hacker che
si impegnano per abbattarti il server per intero mirando ad una
qualche privilege escalation.
Per i lamer, che tu usi root o che tu usi nobody non cambia niente,
tanto non saprebbero sfruttare quella possibilitï¿œ, si limitano solo
ad eseguire codice php preimpostato.
E poi, da fuori non si vede se un server gira come root o meno, per cui
bisogna anche avere la sfiga di incappare in qualche malintenzionato che
si mette a fare delle prove per vedere se apache gira come root, e dato
che oggigiorno apache, di default, non gira come root da millenni, chi
avrebbe voglia di mettersi a smanettare su un server con sopra dei
blog o dei siti delle comunioni?

 l'utente che vuoi.
Ecco, questa è una buona cosa che può valere la sostituzione di ITK.
Quando passai ad ITK lo feci perchè conoscevo solo suPHP e quest'ultimo
proteggeva solo gli script PHP.
Piuttosto che proteggere solo i PHP ho preferito proteggere tutto il vhost.
E' un peccato però che con suexec/fcgi non sia possibile usare permessi
come 600 nei file e 700 nelle directory, dato che l'utente di apache
non riuscirebbe ad accedervi. Con ITK invece si, tant'è che non consento
l'utilizzo di permessi superiori.
Solo 600 sui file e 700 sulle directory.


Questo è il motivo per cui ho preferito suphp a suexec. Ho dei vhost che 
hanno la necessità di creare file, e permettere ad un vhost di leggere 
file appartenenti ad un altro non mi andava proprio...


 file appartenenti ad un altro non mi andava proprio...
sono utenti di sistema e valgono le solite considerazioni sui permessi 
utente sui vari unix.
Sui miei server, questo problema non sussiste.
Avrò forse fatto un pò di prove e settato i permessi correttamente ?

 o dei siti delle comunioni?
Così, ad occhio e croce, qualche migliaio di spammers più o meno evoluti 
tecnologicamente, a cui un'altra sorgente di spam non fa assolutamente 
schifo.

 schifo.
Giuro che non ho capito cosa intendi.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 file appartenenti ad un altro non mi andava proprio...
Con suphp non puoi impostare 600.
O meglio, lo puoi fare solo sui file .php elaborati da suphp stesso.
Ma se metti, ad esempio, in 700 la directory "pippo" con utente "nobody"
apache ti entra e suphp non legge, dato che suphp è in esecuzione con un
utente diverso da nobody.


 Giuro che non ho capito cosa intendi.
Q: chi avrebbe voglia di mettersi a smanettare su un server con sopra dei
   blog o dei siti delle comunioni?
A: Tanti

 assolutamente schifo.
Ma questi smanettano per le vulnerabilit� degli script, del fatto che
il server sia root o meno non se ne possono importare di meno
(sempre considerato che a livello script il sistema ha privilegi bassi).


 utente sui vari unix.
Ovvero che sono limitati e le ACL sono oggettivamente meglio? :)
-- 
Vide

 
Appunto, la directory pippo come utente ha pluto (proprietario del 
vhost) e permessi 700. Tutti i file creati dagli script php hanno come 
utente pluto.


 utente pluto.
ma con suPHP tu dai il proprietario agli script di PHP, non a tutto il 
vhost.
O meglio, quando suphp va in esecuzione, cambia i privilegi con quelli
del proprietario del file php ma supponiamo che:
apache giri con www-data:www-data
/www/pippo/ = 700, pippo:pippo
/www/pippo/pluto.php = 600, pippo:pippo
apache non ci arriva dentro pippo, perchè apache gira con www-data e la
directory "pippo" è 700 con proprietario "pippo", ovvero www-data
non può accedere.
Per cui devi dare per forza 755 a /www/pippo.


 Per cui devi dare per forza 755 a /www/pippo.
O mettere sugid la directory e 750, che e` un po' piu` sicuro.
Che e` esattamente il motivo per cui stavo provando alternative a 
suphp... :)
Bye.

 O mettere sugid la directory e 750, che e` un po' piu` sicuro.
Sempre meglio 700 che 750, così di sicuro nessuno legge all'infuori
dell'utente proprietario, come è giusto che sia, imho.
Il problema è come usare 700 o simile senza ITK.