Newsgroup: it.comp.os.linux.sys
Titolo: Modsecurity + Joomla: esecuzione condizionale

Il problema e' che Joomla!... anzi no, il problema e' Joomla!, e' uno dei
bersagli preferiti degli attacchi.
La configurazione prevede un apache come reverse proxy che fa da front end e 
poi N apache, uno per ogni applicazione, compartimentati a livello di utenti 
con cui girano, con modsecurity sul reverse proxy. 
Il problema e' che modsecurity blocca una operazione lecita di Joomla!,
ovvero quando c'e' l'installazione di un nuovo template, poiche' il POST
invocato contiene la stringa echo, la regola 950006 di modsecurity lo filtra
in quanto lo considera "system command injection" (lo confonde con il
comando echo).
Ora sul manuale di modsecurity c'e' scritto che si puo' eliminare la regola
per una certa location, ovvero potrei avere:
<Location /uri>
   SecRuleRemoveByID 950006
</Location>
ma questo elimina la regola per tutti gli /uri, mentre io vorrei mantenerla
e averla eliminata solo se il metodo POST avviene dalla rete interna.
Non so come fare questo, perche':
1) per quel che vedo di Apache non ci puo' definire una regola 
condizionale basata sugli IP, ovvero qualcosa del tipo
<IP addr/netmask>
   SecRuleRemoveByID 950006
</IP>
che sarebbe l'ideale;
2) non sembra che modsecurity consenta di scrivere una secrule eseguita
condizionalmente con parametri gli IP del client.
Qualcuno sa come fare per risolvere 1 o 2 o qualsiasi altro modo che non
riduca la sicurezza? 
-- 
Per rispondermi, sostituisci a nomecognome il mio nome e cognome
To reply me, substitute nomecognome with my real name and surname

 di utenti con cui girano, con modsecurity sul reverse proxy.
Joomla! e` in PHP. Hai pensato di usare suphp per compartimentare, 
invece di lanciare n istanze di Apache chrootate?
Bye.

 invece di lanciare n istanze di Apache chrootate?
Sì, ma ci sono due aspetti:
1) abbiamo cose che non sono in PHP, notabilmente in Ruby on Rails;
2) preferisco una soluzione che non tocchi o sfiori PHP, visto che c'e' un
consolidamento di applicazioni che sono anni che nessuno tocca più.
Poi mi pare che suphp non sia supportato da RHEL.
Questo comunque, cosa c'entrerebbe con modsecurity?


 Questo comunque, cosa c'entrerebbe con modsecurity?
Ti avrebbe permesso di togliere la riga riguardante echo dai file di 
config di modsecurity senza troppi patemi. :)
Bye.

 config di modsecurity senza troppi patemi. :)
"suPHP is a tool for executing PHP scripts with the permissions of their
owners"
"N Apache, uno per ogni applicazione, compartimentati a livello di utenti
con cui girano"
Se non hai capito, e non hai capito, lascia perdere. 


 Se non hai capito, e non hai capito, lascia perdere.
Allora puoi arrangiarti con le altre decine di risposte che hai 
ricevuto.
Buona fortuna.
Bye.

 
forse fare una rule chain tipo:
SecRule REMOTE_ADDR "^192\.168\.1\.*" chain
SecRuleRemoveById 950006

 SecRuleRemoveById 950006
forse no.

gt wrote:

ci riprovo.
copia la regola 950006 in un file customrules.conf, cambiagli l'id, falla
precedere da:
SecRule REMOTE_ADDR "^192\.168\.1\.*" "phase:1,skip:1"
e alla fine mettici
SecRuleRemoveById 950006

 ricevuto.
Apprezzo di piu' chi capisce di non capire.


 SecRuleRemoveById 950006
Non conoscevo questo chain - ho fatto poco i compiti - grazie per il
suggerimento ci provero'!


gt wrote:

Non l'ho provato ancora, ma perche' non dovrebbe funzionare? Secondo il
manuale, chain serve proprio a realizzare l'AND di condizioni. 


 
anch'io avevo capito così, ma in realtà chain unisce solo due o più SecRule.
guarda questo thread: 
http://thread.gmane.org/gmane.comp.apache.mod-security.user/2951/focus=2957