unbekannte .htaccess

[Wolfgang]

Hallo,
mir ist eine .htaccess aufgefallen, die ich nicht erstellt hatte.
Sie befindet sich in dem Unterordenr acme-challenge eines Ordners .well-known.
Der Inhalt sieht so aus:

<IfModule mod_rewrite.c>  
    RewriteEngine off  
</IfModule>  


Satisfy Any  
Order Deny,Allow  
Allow from all  

<FilesMatch "^\.">  
    # Require all denied  
    Order Allow,Deny  
    Deny from all  
</FilesMatch> 

Was bewirken diese Statements?
Schönen Gruß
Wolfgang

[TS]

Hello Wolfgang,

Die Steuerdatei sorgt dafür, dass für eine automatisch durchgeführte Zertifikatsvergabe (vermutlich über getssl und letsencrypt) auf die Gegenprobe zugegriffen werden kann, ohne dass die mit "." am Anfang markierten Schlüssel über HTTP/s zugänglich sind.

Damit der eingespielte Schlüssel nicht versehentlich als Skript ausgeführt werden kann, wird mit "engine off" die Skriptausführung deaktiviert.

[Edit: Siehe hierzu die weiteren Postings]

Unaufmerksam von mir:

Selbstverständlich nicht php_value engine off sondern Apache RewriteEngine Off

.

Das <FilesMatch "^\.">sorgt dafür, dass alle Dateien, die mit "." beginnen, nicht per HTTP/s aufgerufen werden können.

Das Caret-Zeichen zeigt an, dass am Anfang der Zeichenkette begonnen wird mit der Mustersuche. Der Backslash vor dem Punkt ist als Escape-Zeichen notwendig, damit der Punkt nicht als Ersetzungszeichen für beliebige Zeichen behandelt wird, sondern eben als Punkt.

mir ist eine .htaccess aufgefallen, die ich nicht erstellt hatte.
Sie befindet sich in dem Unterordenr acme-challenge eines Ordners .well-known.
Der Inhalt sieht so aus:

<IfModule mod_rewrite.c>  
    RewriteEngine off  
</IfModule>  


Satisfy Any  
Order Deny,Allow  
Allow from all  

<FilesMatch "^\.">  
    # Require all denied  
    Order Allow,Deny  
    Deny from all  
</FilesMatch> 

Glück Auf
Tom vom Berg

[Wolfgang]

Danke für die rasche und gute Auskunft!

[Rolf B]

Hallo Tom,

dass Dateien mit . vorneweg ausgeblendet werden, hatte ich auch verstanden. Ich hing noch am Rest.

Damit der eingespielte Schlüssel nicht versehentlich als Skript ausgeführt werden kann, wird mit "engine off" die Skriptausführung deaktiviert.

Da steht "RewriteEngine off" - das lese ich jetzt so: FALLS mod_rewrite aktiv ist, sollen bei Zugriffen in diesen Ordner keine Rewrites durchgeführt werden. Den Bezug zu Skriptausführungen sehe ich nicht - aber ich bin ja auch kein Winnetou.

Den Satisfy Any verstehe ich so: Satisfy stellt einen Bezug zwischen Allow/Deny und Require her (also User-basierende Berechtigungen). Im Normalfall wird also zunächst geschaut, ob es irgendeinen Deny für diesen Ordner gibt, und wenn nicht, wird der Zugriff für alle Herkunftadressen erlaubt. Der Satify Any sorgt dafür, dass Benutzerberechtigungen dann keine Rolle mehr spielen. Jeder kann Dateien ohne Punkt vorneweg lesen, egal ob eingeloggt oder nicht.

Ich kenne das von Let's Encrypt verwendete Schema in acme-challenge Ordner nicht. Aber - ist dieser Allow from all nicht etwas zu großzügig? Muss man das nicht präziser einstellen?

Falls der Dateiname mit einem Punkt beginnt, wird die Order herumgedreht, so dass Deny als letztes kommt und Vorrang vor eventuell anderswo stehenden Allows hat (z.B. dem direkt darüber).

Aber hier kommt, wenn ich das richtig verstehe, der Satisfy Any leicht quer: Der sorgt nämlich dafür, dass eine eventuell irgendwo stehende Require Direktive den Zugriff dennoch erlauben kann. Stünde bspw. irgendwo Require valid-user, dann würde jeder (per HTTP Login) angemeldete User die Schlüsseldateien lesen können.

Das scheint mir jetzt nicht im Sinne des Erfinders zu sein. Muss in den <FilesMatch> nicht noch ein Satisfy All hinein? Okay, solange keine HTTP-Authentication auf der Seite verwendet wird, passt das. Aber wenn irgendwer meint, sowas nutzen zu müssen, könnte das ein Schlüssel-Leak erzeugen.

Rolf

[TS]

Hello Rolf,

Damit der eingespielte Schlüssel nicht versehentlich als Skript ausgeführt werden kann, wird mit "engine off" die Skriptausführung deaktiviert.

Da steht "RewriteEngine off" - das lese ich jetzt so: FALLS mod_rewrite aktiv ist, sollen bei Zugriffen in diesen Ordner keine Rewrites durchgeführt werden. Den Bezug zu Skriptausführungen sehe ich nicht - aber ich bin ja auch kein Winnetou.

Oh ja. Du hast Recht. Nicht engine off

Das sollte man aber ebenfalls vermerken, da die Challenges ja von außen (getssl, letsencrypt) eingeholt werden). Und was man sich da einfängt, basiert nur auf Vertrauen.

Glück Auf
Tom vom Berg

[Rolf B]

Hallo TS,

jetzt hab ich erstmal suchen müssen. Mein PHP läuft ja unter einem IIS 😉

Du meinst die php_flag-Einstellung? Das greift aber nur, wenn PHP als mod_php läuft. Mit FastCGI dürfte das nicht wirksam sein. Oder?

Rolf

[TS]

Hello,

jetzt hab ich erstmal suchen müssen. Mein PHP läuft ja unter einem IIS 😉

Du meinst die php_flag-Einstellung? Das greift aber nur, wenn PHP als mod_php läuft. Mit FastCGI dürfte das nicht wirksam sein. Oder?

Nein. Das ist mWn keine PHP-Einstellung, sondern eine des Apachen. Und dem sollte es dann egal sein, welche Skript-Engine er für diesen Verzeichnisstrang ausschaltet.

Aber lassen wir das mal durch JR überprüfen ;-)

Glück Auf
Tom vom Berg

[TS]

Hello,

das war selbstverständlich Shit. :-O
Dank an Rolf...

• php_value engine off in der Conf, in den VirtHosts oder in der .htaccess., bezieht sich auf PHP als Modul und lässt sich überschreiben in .htaccess

• php_admin_value engine off nur in der Conf, oder den VirtHosts, nicht aber in der .htaccess. Lässt sich dort auch nicht überschreiben.

Nächstes Mal nicht wieder drei Sachen auf einmal: Telefonieren, SelfForum, Biertrinken ;-)

[Mitleser 2.0]

jetzt hab ich erstmal suchen müssen. Mein PHP läuft ja unter einem IIS 😉

Du meinst die php_flag-Einstellung? Das greift aber nur, wenn PHP als mod_php läuft. Mit FastCGI dürfte das nicht wirksam sein. Oder?

Irgendwie kann ich euch nicht so Recht folgen. M.E. ist die Sache doch ganz simpel: Der Abruf der Challenge muss komplett offen möglich sein. Dabei könnten einem sowas via Rewrites oder halt sämtliche Beschränkungen in die Quere kommen.

Mit PHP hat das nichts zu tun.

EDIT: Der Abruf der Challenge muss offen möglich sein, wenn man die HTTP-Challenge verwendet. Es gibt ja beispielsweise auch noch DNS…

[Rolf B]

Hallo Mitleser 2.0,

Mit PHP hat das nichts zu tun.

Nur weil Tom paranoid ist, heißt das nicht, dass keiner hinter ihm her ist.

Und wenn man Let's Encrypt misstraut, dann könnten sie diverse böse Dinge anrichten mit den Dateien, die sie einem auf den Server schreiben.

Ich kenne den Ablauf von ACME nicht. Wenn der Ordner, in den let's encrypt schreibt, einer ist, der auch vom Web gelesen werden kann, DANN besteht die Gefahr, dass sie eine spy.php hochladen und laufen lassen, wenn die Script-Ausführung erlaubt ist.

Das würde ich dann aber als einen Designfehler im Let's Encrypt Ablauf ansehen, der bei heise oder CCC schon längst zu Aufregung hätte führen müssen.

Rolf

[Mitleser 2.0]

Mit PHP hat das nichts zu tun.

Nur weil Tom paranoid ist, heißt das nicht, dass keiner hinter ihm her ist.

Was Tom's Paranoia mit PHP zu tun hat, verstehe ich auch nicht ;-)

Und wenn man Let's Encrypt misstraut, dann könnten sie diverse böse Dinge anrichten mit den Dateien, die sie einem auf den Server schreiben.

Ich kenne den Ablauf von ACME nicht. Wenn der Ordner, in den let's encrypt schreibt, einer ist, der auch vom Web gelesen werden kann, DANN besteht die Gefahr, dass sie eine spy.php hochladen und laufen lassen, wenn die Script-Ausführung erlaubt ist.

Naja, wenn man beispielsweise das von Tom erwähnte "getssl" verwendet, dann führt man auf der Shell ein Script aus, was auch jede Menge Unsinn machen kann.

Das würde ich dann aber als einen Designfehler im Let's Encrypt Ablauf ansehen, der bei heise oder CCC schon längst zu Aufregung hätte führen müssen.

Das sehe ich anders. Es gibt mehrere Möglichkeiten, die Challenge zu absolvieren, die alle Ihre Vor- und Nachteile haben. Auf der verlinkten Seite siehst Du auch welche, die bereits wieder abgeschafft wurden. Daraus lässt sich IMHO ablesen, dass die Mädels und Jungs sich durchaus viele Gedanken machen und selbst immer auf der Suche nach der „besten“ Lösung sind. Gäbe es ein verfügbares Konzept für die eierlegende Wollmichsau, die nur Vor- und keine Nachteile hat, dann hätten die die bereits implementiert.

Du kannst die komplette Nummer auch manuell fahren. Dann bist Du Safe. Klitzekleiner Nachteil: dann musst Du alle paar Monate ran zur Erneuerung des Certs.

Ich persönlich präferiere die Variante, die Sache über einen vorgeschalteten Proxy laufen zu lassen. Das vereint eine Menge Vorteile. Das Setup steht aber nicht jedem zur Verfügung.

Das Ziel von Let's Encrypt war von Anfang an: möglichst viel verschlüsselte Verbindungen im Web. Sich da auf unterschiedlichste Begebenheiten einzulassen scheint mir eine gute Idee.

[TS]

Hello,

Mit PHP hat das nichts zu tun.

Nur weil Tom paranoid ist, heißt das nicht, dass keiner hinter ihm her ist.

Und wenn man Let's Encrypt misstraut, dann könnten sie diverse böse Dinge anrichten mit den Dateien, die sie einem auf den Server schreiben.

Ich kenne den Ablauf von ACME nicht. Wenn der Ordner, in den let's encrypt schreibt, einer ist, der auch vom Web gelesen werden kann, DANN besteht die Gefahr, dass sie eine spy.php hochladen und laufen lassen, wenn die Script-Ausführung erlaubt ist.

Das würde ich dann aber als einen Designfehler im Let's Encrypt Ablauf ansehen, der bei heise oder CCC schon längst zu Aufregung hätte führen müssen.

Trotzdem stimmte dein Einwand selbstverständlich, dass engine off keine direkte Apache-Einstellung ist, sondern zu PHP gehört.

Apache kennt hier scheinbar nur

• RewriteEngine Off
• SSL Engine Off

Und wenn Apache unter Solaris läuft, kann auch eine getrennte User-Zuweisung für VirtHosts duchgeführt werden.

Glück Auf
Tom vom Berg

[Rolf B]

Hallo TS,

Danke für die Rückmeldung.

Im IIS gibt es noch die auf Extensions basierende Zuordnung von MIME Typen und HTTP Handlern. Was nichts davon hat, wird nicht ausgeliefert.

Kann der Apache ähnliches?

Rolf

[TS]

Hello,

Im IIS gibt es noch die auf Extensions basierende Zuordnung von MIME Typen und HTTP Handlern. Was nichts davon hat, wird nicht ausgeliefert.

Kann der Apache ähnliches?

Das Filtern müsste dann vermutlich im mod_mime stattfinden. Da ist aber keine Möglichkeit zu finden, um nach dem tatsächlichen (vermeintlichen) MIME-Type Entscheidungen zu treffen.

Die Zugriffsbeschränkung über die Erkennung der Extension kann man auch schon mit dem Core-Modul und FilesMatch vornehmen.

Das erkennt aber nicht wirklich den MIME-Type.

Den sollte man zwar ohnehin bereits beim Upload prüfen (z. B. mit PHP und passender Apache-API), aber wer weiß schon, wie Dateien wohin auf den Server gelangt sind.

Da an der Extension aber i.d.R. der zugeordnete Handler hängt, ist die Sache durchaus kritisch zu betrachen.

Glück Auf
Tom vom Berg

[Raketenwilli]

Order Allow,Deny
Deny from all

sorgt beim Apache 2.4 ohne mod_access_compat für einen 500er. Verhindert also den Zugriff.

[Mitleser 2.0]

Order Allow,Deny
Deny from all

sorgt beim Apache 2.4 ohne mod_access_compat für einen 500er. Verhindert also den Zugriff.

Yep. Daher irritiert mich auch die Aussage des OP "mir ist eine .htaccess aufgefallen, die ich nicht erstellt hatte".

Soweit dem OP da nicht "irgendein Kumpel" bei der Einrichtung geholfen hat, fällt mir dazu nur ein, dass der Hoster das so angelegt hat. Macht aber auch irgendwie keinen Sinn. Warum löst er dass dann nicht anders, um absehbaren Kummer zu vermeiden... für mich irgendwie mysteriös...

[Mitleser 2.0]

Damit der eingespielte Schlüssel nicht versehentlich als Skript ausgeführt werden kann, wird mit "engine off" die Skriptausführung deaktiviert.

Ich würde eher tippen, dass man den Request auf das Challange-File auch das Gewünschte liefern lassen möchte und nicht ein - wie auch immer geartetes - Rewrite Ergebnis. Dass muss ja nicht zwangsläufig ein Scriptaufruf sein.

[Rolf B]

Hallo Mitleser 2.0,

Du wiederholst Toms Vermutung, dass engine off eine valide Apache Direktive sei, die Scripting abschaltet.

Gerne lasse ich meine diesbezügliche Wissenslücke füllen. Hast Du einen Link auf eine Dokumentation zur engine Direktive? Meine eigene Suche war vergeblich, aber ich kann ja die falschen Stichwörter verwendet haben.

Rolf

[Mitleser 2.0]

Du wiederholst Toms Vermutung, dass engine off eine valide Apache Direktive sei, die Scripting abschaltet.

Punkt für Dich. Das habe ich tatsächlich nicht genau genug gelesen und verarbeitet. Sorry. Ja, das "mag" auch eine gute Idee sein.

Gerne lasse ich meine diesbezügliche Wissenslücke füllen. Hast Du einen Link auf eine Dokumentation zur engine Direktive? Meine eigene Suche war vergeblich, aber ich kann ja die falschen Stichwörter verwendet haben.

Im Kontext des OP wiederhole ich gerne, dass es im hiesigen Kontext eine gute Idee ist, Rewrites als Solche zu deaktivieren.

[MudGuard]

Hi,

Du wiederholst Toms Vermutung, dass engine off eine valide Apache Direktive sei, die Scripting abschaltet.

Wie kommt Ihr auf eine engine-Direktive?

Im Originalposting gibt es nur eine RewriteEngine-Direktive ...

cu,
Andreas a/k/a MudGuard

[Raketenwilli]

Du wiederholst Toms Vermutung, dass engine off eine valide Apache Direktive sei, die Scripting abschaltet.

Das war rewrite engine. Warum heißt die wohl so?

Nein, die Abschaltung verhindert kein Skripting an sich. Aber eben, dass die Requests, die den Ordner betreffen, nicht an Skripte durchgereicht werden. Wie gündlich weiß ich aber nicht. Bin aber grad zu faul, die Doc zu quälen oder zu testen, was passiert, wenn es obendrüber angeschaltet ist und Regeln (Rules) gesetzt sind…

Hint: Da hier vermutet wird, dass es mit let's encrypt zu tun hat:

Das Paket von mir genutzte und empfohlene certbot macht solchen „Scheiß“ nicht.

[TS]

Hello,

Ich würde eher tippen, dass man den Request auf das Challange-File auch das Gewünschte liefern lassen möchte und nicht ein - wie auch immer geartetes - Rewrite Ergebnis. Dass muss ja nicht zwangsläufig ein Scriptaufruf sein.

Wo Du Recht hast ;-)
Stimmt selbstverständlich. Rewrites wären hier nicht sinnvoll.

Glück Auf
Tom vom Berg