Newsgroup: it.comp.macintosh
Titolo: Apache non filtra!


| |._/|_|\__/\__/\__/ | *Non e' bello cio' che e' bello,
|        /_/ /_/      |  figurarsi cio' che e' brutto.

 metodo.
La regex è corretta.
In quel contesto potresti omettere sia l'escape del segno meno che dei 2 
punti:
SetEnvIfNoCase Request_URI "cgi-bin|awstats|cmd\.exe|http:|php" blockem
ma non è questo il problema, perché gli escape ridondanti non danno 
fastidio.
L'unica cosa che mi viene in mente è che nel fare le prove hai 
utilizzato inavvertitamente URI che uscivano fuori dalla Location (o 
dalla Directory) nella quale hai messo il Deny, per cui quello che non 
scatta è proprio il Deny piuttosto che il match della regex.
Se già non l'hai fatto, prova a fare dei test utilizzando:
<Location />
     Deny from env=blockem
</Location>
che intercetta qualsiasi richiesta.
Se il problema non è questo, sono a corto di idee.
Comunque queste so' cose da professionisti, altro che fai il modesto ;-)
Ciao, Emanuele.

 Comunque queste so' cose da professionisti, altro che fai il modesto ;-)
LOL. Diciamo che sono cose da hobbisti craponi. Mi annoia vedere il log
che si ingigantisce per colpa di quelli che tentano di sfondare il
server con URI da 100 righe.
Comunque ho provato anche a spezzare la regex facendo degli if separati,
ma niente. Uffa.
Grazie per il supporto, o unico temerario! .-)


 Grazie per il supporto, o unico temerario! .-)
Di nulla.
Ti confermo pure che la regex č corretta, nel senso che per scrupolo 
l'ho testata (esattamente quella da te riportata) su un'istanza di 
Apache (mod_setenvif 2.0.55.0) e funziona senza alcun problema, anche 
quando nella URI c'č piů di una keyword.
Se riesci a svelare l'arcano fammi sapere ché sono curioso.
Ciao, Emanuele.
-- 
What does VISTA mean?
Viruses, Infections, Spyware, Trojan horses & Adware.

 Se riesci a svelare l'arcano fammi sapere ché sono curioso.
Ho capito una cosa: non e' quando e' verificata piu' di una condizione
che il test fallisce, ma solo in certi particolari casi che vado ad
esemplificare.
Dal log:
192.168.1.34 - - [09/Aug/2006:01:26:20 +0200] "GET /cgi-bin/ HTTP/1.1" 
Risposta: 403 324
Cioe' mi da' "forbidden", che andrebbe anche bene.
Subito dopo:
192.168.1.34 - - [09/Aug/2006:01:28:12 +0200] "GET /cgi-bin/test.xxx
HTTP/1.1"
Risposta: 404 328
Cioe' un "not found".
In ambedue i casi il test e' fallito (altrimenti questi due accessi non
starebbero nel log). Nel primo caso, la cartella cgi-bin non esiste e
dunque, per difetto, non e' listabile: prima ancora di cercare se c'e',
Apache sa che non puo' listarla e da' il forbidden. Nel secondo caso
punto a un file, dunque Apache lo cerca e non trovandolo da' not found.
Poi in error.log ho ad esempio:
client denied by server configuration:
/Library/WebServer/Documents/cgi-bin
Dunque se cerco un file che si chiama "cgi-bin" il test funziona, ma se
cerco una *cartella* "cgi-bin/" non funziona.
Sempre in error.log noto questo:
script not found or unable to stat:
/Library/WebServer/CGI-Executables/cmd.exe
e
script not found or unable to stat:
/Library/WebServer/CGI-Executables/test.php
Ovvio che in nessuno dei due casi mi sono sognato di rivolgermi alla
cartella "CGI-Executables/". Mi par di capire che *prima ancora della
verifica* Apache cerchi di intuire la natura della richiesta, e se trova
un'estensione eseguibile (php o exe) vada a cercare il file altrove
senza passare dal test. Dunque capisco anche perche' non funzia il
"cgi-bin/": deviato su una cartella che non e' nella mia location, il
parser salta il test a pie' pari.
Mo', quando ho un secondo di tempo, devo scoprire dov'e' in httpd.conf
la parte che si occupa di dire ad Apache che .exe e' eseguibile eccetera
o_O
Ho capito anche perche' non riesco a liberarmi dei SEARCH[mille cifre
esadecimali] e di altre simpatiche incursioni: prima ancora di
interpretare l'URI, Apache da' un errore, dunque non fa il test, non
setta la variabile e io mi trovo l'URI in access.log *e* l'errore in
error.log, come in questi due casi:
[error] [client 84.226.50.163] request failed: URI too long
[error] [client 216.72.6.93] client sent HTTP/1.1 request without
hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
Affaire a' suivre.
