Apache2/mod_rewrite

[MHoff]

Habe (mal wieder) folgendes Problem:

Apache2 und mod_rewrite wollen nicht so wie es wohl sollte.

mod_rewrite existiert als normales Modul was auch korrekt geladen wird, davor habe ich es statisch versucht mit dem gleichen Ergebnis.
Apache2 ist aus den Original Quellen kompiliert, aber auch der Apache aus den Ports/Paketen funktioniert nicht, zumindest nicht mod_rewrite.

In den Logs ist keinerlei Fehlermeldung zu finden, auch wenn ich probiere über die .htaccess (mit entsprechenden Optionen in der httpd.conf) zu manipulieren.

Die Webseiten werden normal angezeigt, aber halt ohne mod_rewrite Regeln.

Jemand eine Idee?

 

[MHoff]

Nun füllen sich die Logs das keine Regel passen würde (not-matched).

Ich versuche z.B. das TRACE Sicherheitsleck aus Apache zu bekommen mittels mod_rewrite, kann dank guter Dokumentation also eigentlich nicht viel falschmachen.

Hoffe hier weiss jemand Rat.

 

[troll]

Wie wärs mal die Patterns zu posten?

CU

Martin

 

[MHoff]

Hoppala, war gestern wohl schon ein wenig müde.

RewriteCond: input='GET' pattern='^TRACE' => not-matched

Auch ^(TRACE|TRACK) funktioniert nicht (TRACK erscheint nicht in den Logs).

 

[troll]

*g* Guten Morgen ;-)

Noch ein Versuch, probier mal aus die Regel zu posten, die nicht matcht
*duck*

CU

Martin

 

[MHoff]

Ok, nun hab ichs *g*

Das ist die Regel wie sie in der httpd.conf steht, auch getestet mit .htaccess und den entsprechenden Einstellungen:

 RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]

Und das ist die Logmeldung:

192.168.1.11 - - [24/Jul/2005:12:32:41 +0200] [192.168.1.100/sid#809adc8][rid#81d0050/initial] (3) [per-dir /home/www/web01/] strip per-dir prefix: /home/www/web01/ ->
192.168.1.11 - - [24/Jul/2005:12:32:41 +0200] [192.168.1.100/sid#809adc8][rid#81d0050/initial] (3) [per-dir /home/www/web01/] applying pattern '.*' to uri ''
192.168.1.11 - - [24/Jul/2005:12:32:41 +0200] [192.168.1.100/sid#809adc8][rid#81d0050/initial] (4) RewriteCond: input='GET' pattern='^TRACE' => not-matched
192.168.1.11 - - [24/Jul/2005:12:32:41 +0200] [192.168.1.100/sid#809adc8][rid#81d0050/initial] (1) [per-dir /home/www/web01/] pass through /home/www/web01/
192.168.1.11 - - [24/Jul/2005:12:32:41 +0200] [192.168.1.100/sid#809adc8][rid#81d6050/initial] (3) [per-dir /home/www/web01/] strip per-dir prefix: /home/www/web01/favicon.ico -> favicon.ico
192.168.1.11 - - [24/Jul/2005:12:32:41 +0200] [192.168.1.100/sid#809adc8][rid#81d6050/initial] (3) [per-dir /home/www/web01/] applying pattern '.*' to uri 'favicon.ico'
192.168.1.11 - - [24/Jul/2005:12:32:41 +0200] [192.168.1.100/sid#809adc8][rid#81d6050/initial] (4) RewriteCond: input='GET' pattern='^TRACE' => not-matched
192.168.1.11 - - [24/Jul/2005:12:32:41 +0200] [192.168.1.100/sid#809adc8][rid#81d6050/initial] (1) [per-dir /home/www/web01/] pass through /home/www/web01/favicon.ico

Ich habe nicht so den Plan von mod_rewrite, aber auf meinen Linuxservern funktionieren diese Einstellungen.
Nun habe ich auch gemerkt das man viele, nützliche Dinge damit machen kann, nur dazu sollte es halt funktionieren.

 

[troll]

Hi,

funktioniert in der Tat nicht mehr.
Allerdings kommt auch kein Cookie zurück.
Es macht den Anschein, als wäre Trace abgeschaltet und als würde automatisch auf GET geswitcht werden.
input='GET' pattern='^TRACE' => not-matched
Was ich voreilig so interpretiere, dass der TRACE auf GET umgebogen wurde, bevor die Regel eingelesen wurde. Es ist wohl sinnvoll es genauer zu verfolgen um sich Klarheit zu verschaffen.

Wie auch immer, ich sehe das TRACE Problem nicht als Server bug, sondern als Browserbug. Einige Browser erlauben einem JS eine TRACE Anfrage an einen Server zu schicken. Hier liegt IMHO das Problem.

CU

Martin
P.S. an deiner Regel liegts nicht und mod_rewrite scheint zu laufen.

 

[MHoff]

Vielen Dank für Deine Hilfe.

Das Beispiel mit dem ich probiert habe funktioniert tatsächlich nicht.
Trotzdem erscheinen z.B. bei Nessus oder Nikto weiterhin die TRACE Meldungen.

Andere Beispiele wie

RewriteRule test.html /test/test2.html [R,L]

funktionieren einwandfrei. Jetzt zumindest.

Ich habe an der Konfiguration an sich nichts verändert, kann es vielleicht sein das es mit den Securityleveln (wie mein SSH Problem) zusammenhängen kann?

An sich nicht wichtig, da fast alles so funktioniert wie es soll

 

[troll]

Hi,

mir fällt nix ein, wie die Security-level da reinspielen könnten.

Mit Nessus muss ich mal ausprobieren, aber Nessus meldet manchmal auch viel, wenn der Tag lang ist ;-)
Ernst: Nix gegen Nessus, grossartiges Programm!

Mich würd mal interessieren, worauf Nessus testet.

Im Zweifelsfall sollte man mal die Apache Foundation anschreiben und nachfragen, was es damit auf sich hat.

CU

Martin

 

[Wiedmann]

Im Zweifelsfall sollte man mal die Apache Foundation anschreiben und nachfragen, was es damit auf sich hat.

Ein schöner Dialog dazu von der Apache-Dev-List:

> Well, reviewing Nessus reports this week has left me *very* pissed
> off. Has anyone assembled a list of all of the various client
> browser identifiers that are too moronic to handle a TRACE request
> properly?

No, I just ignore these silly Nessus reports. Every couple weeks
someone comes into #apache on Freenode IRC, all worried how TRACE is the
end of the world...

 

[troll]

Hi,

Ein schöner Dialog dazu von der Apache-Dev-List:

*LACH* so ähnlich schätze ich die Sache auch ein.
Trotzdem seltsam, dass das nicht mehr mit der rewrite_engine geht.

Vor nem Jahr wurde doch ein tierischer Kopfstand draus gemacht, dass man die TRACE Requests per Regel zerpflücken kann und jetzt sind se wech.

Ich kann mich noch dran erinnern, dass das für viele Leute der endgültige Grund war auf 2 umzusteigen

CU

Martin