Newsgroup: it.comp.os.linux.sys
Titolo: di webservi, reverseproxy e dmz

Ho ereditato dai governi precedenti un webservo pubblico (apache su 
debian squeeze) che vorrei rifare.
 
Delle conf apacchie, metà sono delle reverseproxate ad altri server 
dedicati, metà sono siti php più o meno legacy più o meno intoccabili 
più o meno privi di manutenzione.
Questo saltuariamente genera mostri (che meriterebbero un altro thread 
dedicato) ma in buona sostanza ogni tanto apache va in out of memory e 
tracciarne il perché s'è rivelato un'odissea. Probabilmente a causa 
della parte php, ma finisce per tirarsi dietro anche la parte di reverse 
proxy.
 
Seguono domande:
1) Può essere una buona idea scorporare tutto in modo da avere il server 
principale che fa solo da reverse proxy e confinare la parte php in 
altro server dedicato in modo se non altro da isolare il problema?
2) L'attuale server è in dmz ma le conf reverseproxate puntano 
tristemente a server in lan. Qui nessuno s'è mai posto il problema e un 
eventuale spostamento in dmz di tutti i server coinvolti porterebbe ad 
una royal rumble con sviluppatori (e dirigenza) dove l'unico a 
sostenerne la necessità sarei io. Sto cercando di documentarmi un po' 
meglio sul tema, anche se è pacifico che avere tutto in dmz sia più 
sicuro l'effettiva necessità di implementazione della cosa pare più 
soggettiva e/o legata a sensibilità dei dati esposti. Pareri? Qualcuno 
c'è già passato? Mi sto fasciando la lan prima di essermela rotta?

 c'è già passato? Mi sto fasciando la lan prima di essermela rotta?
 
Se la macchina effettua query verso la LAN, il concetto di DMZ è 
assolutamente vanificato in quanto una compromissione della macchina 
comunque consente ad un attaccante di rimbalzare in LAN. La DMZ stessa 
ha come fine il confinare un'area e le eccezioni sono come i buchi in 
uno scolapasta che deve contenere liquidi.
 
Laddove proprio non si possa fare altrimenti, andrebbe visto COSA è 
abilitato dalla DMZ alla LAN. Un conto magari è solo la query mysql, un 
conto è "SrvDMZ -> NetworkLAN -> Pass Any" come invece spessissimo 
accade per superficialità e frettolosità nella scrittura della policy.

 proxy.
 
PHP ha un parametro memory_limit che appunto limita la memoria che un 
singolo script può usare.
 
Se il server ha 2 GB di RAM e il memory_limit è a 64 MB controlla che 
Apache non possa spawnare più di 25 figli (1.6 GB circa). In questo modo 
non dovrebbe più andare in OOM.
 
Puoi provare a rischiare dandogliene 30, 40, 50, nella speranza che gli 
script che ne usano tanta siano sporadici.
 
Se il memory_limit è più alto (probabilmente perchè i programmatori non 
sanno come usare uno stream o un cursore di DB e volevano 512 MB o oltre 
di memory_limit), imposta i limiti di conseguenza (3 processi se è 
512MB, per esempio) e poi, se si lamentano delle prestazioni, fagli un 
preventivo per aumentare il server o per sistemare gli script.
 
Se non è qui il problema, almeno hai escluso PHP e puoi vedere se c'è un 
memory leak in un modulo di apache o altro.
 
Bye.
 
 

 non dovrebbe più andare in OOM.
 
Grazie della risposta e dell'interessamento, vedo di dettagliare meglio:
php al momento ha un memory limit di 128MB, ma in condizioni di carico 
medio siamo sui 30MB a processo per un server con 8Gb di ram. Non dico 
che ho dovuto litigare ma poco ci manca per tirar giù il MaxClients nel 
prefork di apache a 150 (era a 500) che è comunque più del doppio del 
dovuto se uno piglia il memory limit come riferimento.
 
Questo ha fatto calare drasticamente il problema ma ogni tanto si 
ripresenta. Purtroppo (riassumo) sostanzialmente non ho il supporto 
degli sviluppatori nel diagnosticare cosa s'impippi la ram in codice 
vecchio di anni e quando accade ho le torce e i forconi fuori 
dall'ufficio (se riesco a tirare un restart di apache sul server bradipo 
e swappone è già tanto).
 
Essendo l'unico server affacciato sulle interwebs da lì m'era venuta 
l'idea di trasformarlo in reverse proxy duro e puro e appaltare il php 
mal configurato ad altro server. In effetti ora che l'ho scritta tutta 
mi rendo conto che è un problema più politico che tecnico.
 

 abilitato dalla DMZ alla LAN.
 
Sono tristissime rewrite rules che proxano la connessione http a 
specifici url di server interni. Tutto http in vari gusti, alcuni 
webservice, alcune interfacce.
Ho una certa ignoranza anche in questo campo, ma la cosa più banale che 
mi viene in mente è che se uno trova il modo di "bucare" un'interfaccia 
in qualche modo compromette un server in lan con tutti gli annessi e 
connessi del caso.
 

 e swappone è già tanto).
 
Capisco.
 
Non ho mai provato, ma volendo potresti tentare di isolare i vari siti 
in diversi FPM (uno per sito), così almeno quando crasha un FPM sai in 
quale sito è successo e riduci l'area di debug.
 
Sempre che i siti supportino di girare in FPM invece che su Apache (se 
sono vecchi potrebbero dare per scontato che sono su Apache e usare 
alcune sue env vars)
 
Buona fortuna. :)
 

 tristemente a server in lan. 
 
beh ma quale sarebbe l'alternativa? 
I dati del DB, da qualche parte devi pur attingerli. L'application server 
in qualche modo deve comunicare con i load balancer/reverse proxy. 
Metti tutto in DMZ? Ma a quel punto è peggio, perché i dati saranno alla 
mercé di tutti. 
 
-- 
Massimiliano Adamo

 Buona fortuna. :)
 
Grazie della dritta! Non ci avevo pensato, mi documento un po' sul tema.

 mercé di tutti.
 
Attualmente c'è un mod_rewrite che sostanzialmente riscrive url 
facendoli puntare a server in lan, e in alcuni casi sono effettivamente 
webservice di fornitura dati, ma in altri sono proprio interfacce utente 
di fatto fornite da server in lan, è quello che vedevo come fonte di 
rischio principale (almeno per questioni di injection, in teoria è roba 
sviluppata a modino ma è un range un po' ampio per mettere la mano sul 
fuoco sul fatto che sia stata fatta input sanitization a regola d'arte)
 
L'alternativa (per tornare alla tua domanda) sarebbe spostare almeno 
tutte le interfacce in dmz ma stavo appunto cercando di valutare il 
rapporto rischio/sbattimento

 rapporto rischio/sbattimento
 
si ok, si puo' porre il caso che il tuo codice php sia vulnerabile al php 
traversal path e quindi blah blah... ma tutto puo' essere vulnerabile in 
qualche modo. Anche il DB che hai sul backend potra' essere vulnerabile a un 
buffer overflow. Quindi che fai? Metti anche il DB in DMZ? 
Ma cosi' via a cosi' via, finisce che metti tutto nella DMZ. 
 
Magari potrebbero essere piu' probabilita' che il codice PHP sia vulnerabile ma 
l'idea di avere una DMZ che parla solo con se stessa mi sembra un po' 
velleitaria. 
 
Vado di wikipedia:
(italiano)
Una DMZ (demilitarized zone) è un segmento isolato di LAN (una "sottorete") 
raggiungibile sia da reti interne sia esterne, ma caratterizzata dal fatto che 
gli host attestati sulla DMZ hanno possibilità limitate di connessione verso 
host specifici della rete interna.[1][2]
(inglese)
"Hosts in the DMZ are permitted to have only limited connectivity to specific hosts in the internal network"
 
Da notare l'uso della parola "limitate/limited"... cioe', pensare che un 
reverse proxy parli solo con se stesso mi pare un po' limitante.