Problem bei nginx-location mit Ispconfig

[computerwuffi]

Hallo,
ich betreibe einen kleinen Server mit Debian 10, Nginx und Ispconfig (3.2.5), alle aktuellen Updates. Ich habe mehrere PHP-Versionen installiert.
Leider finde ich keine Lösung zu folgendem Problem: in den Nginx-Direktiven einer Webseite (php-fpm 7.3) habe ich folgende Location, die bei Aufruf von Dateien in den aufgeführten Verzeichnissen, speziell auch bei Dateien mit .php Endung Error 403 zurückgeben soll. (wird z.B. bei Matomo im Sicherheitscheck geprüft).
location ~ ^/(config|tmp|core|lang) {
deny all;
return 403;
}
Das funktioniert auch mit allen Dateien, jedoch leider nicht bei .php Dateien in diesen Verzeichnissen. Weiss jemand, woran das liegen könnte?

Ist das vielleicht der php-Handler von Ispconfig? Wenn ich die von ISPConfig automatisch generierte, etwas vor meiner eigenen Anweisung im Code des vhosts stehende
location ~ \.php$ {
try_files /364168ac6c5481d5e1dae82219ac7b5d.htm @php;
} auskommentiere, dann funktioniert meine obige Location auch mit .php Dateien. Mache ich da etwas falsch?
Vielen Dank für eure Antwort.

 

[michelangelo]

Habe exakt das selbe Problem mit Matomo in einer Nginx Umgebung.
Gibt es hier evtl. einen workaround um die ~ \.php$ location im Template zu deaktivieren oder zu neutralisieren @Till?

 

[michelangelo]

Falls jemand über Google/Boardsuche auf diesen Thread stoßen sollte, habe ich durch Zufall die Lösung gefunden, da ich sonst kurz davor gewesen wäre eine extra Funktion zu implementieren, die den PHP Handler deaktiviert.

Wie gut, dass sich bereits eine noch bessere Funktion im PHP Code des Nginx Plugins versteckte, siehe Link:

server/plugins-available/nginx_plugin.inc.php · develop · ISPConfig / ISPConfig 3 · GitLab

GitLab Community Edition

git.ispconfig.org

Wenn man nach ##delete## und ISPConfig sucht, findet man auch paar Threads zu dieser gut undokumentierten Funktion.


Nun, wie funktioniert das nun?
Im Direktiven Feld der Website fügt man das folgende hinzu:

location ~ \.php$ { ##delete##
}

##subroot matomo##

    ## only allow accessing the following php files
    location ~ ^/(index|matomo|piwik|js/index|plugins/HeatmapSessionRecording/configs)\.php$ {
        try_files $fastcgi_script_name =404; # protects against CVE-2019-11043. If this line is already included in your snippets/fastcgi-php.conf you can comment it here.
        fastcgi_param HTTP_PROXY ""; # prohibit httpoxy: https://httpoxy.org/
            {FASTCGIPASS}
            include /etc/nginx/fastcgi_params;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_intercept_errors on;
    }

Die erste Anweisung mit dem ##delete## löscht dann die location des PHP handlers.

Man muss dann noch die Nginx fastcgi spezifische Direktiven der Location "~ ^/(index|matomo|piwik|js/index|plugins/HeatmapSessionRecording/configs)\.php$" hinzufügen, die zuvor der globale PHP Handler "@php" übernommen hat.

Danach sollte die Matomo Systemprüfung erfolgreich sein, bzw. nicht mehr diese zwei Locations anmeckern.

 

[Till]

Wenn man nach ##delete## und ISPConfig sucht, findet man auch paar Threads zu dieser gut undokumentierten Funktion.

Steht im ISPConfig Handbuch auf Seite 150.

 

[michelangelo]

Steht im ISPConfig Handbuch auf Seite 150.

Ahh, Okay!
Habe das Handbuch zwar vor ein paar Jahren über die Firma gekauft, habe aber selten reingeschaut, was teils auch der Aktualität des Handbuchs geschuldet ist.
Auf der anderen Seite denkt man, man wüsste schon alles über ISPConfig und stolpert dann trotzdem hin und wieder über solche Funktionen/Features

edit
Habe gerade mal nachgeschaut, Handbuch ist sogar älter als ein paar Jahre. Es dadiert von 2014, Version 1.4 für ISPC 3.0.5 und enthielt damals nur ##merge## und nicht ##delete##.
Irgendwann sind mir diese Funktionen aber schon mal über den Bugtracker über den Weg gelaufen, nur wenn man diese nicht - häufiger - einsetzt, vergisst man, dass es diese Funktion überhaupt gibt.