staging.inyokaproject.org

Hallo,

in dem Skript /usr/bin/fastcgi-wrapper.pl ist das hier evtl. nicht ganz so gut

print("Content-type: text/plain\r\n\r\n"); print "Error: No such CGI app - $req_params{SCRIPT_FILENAME} may not "; print "exist or is not executable by this process.\n";

weil das im wesentlichen zu einem XSS führen kann...was Nessus dann so meldet

"The remote host is running a web server that fails to adequately sanitize request strings of malicious JavaScript. By leveraging this issue, an attacker may be able to cause arbitrary HTML and script code to be executed in a user's browser within the security context of the affected site."

The request string used to detect this flaw was :

/<script>cross_site_scripting.nasl</script>.pl

The output was :

HTTP/1.1 200 OK Server: nginx/1.7.6 Date: Tue, 28 Oct 2014 14:47:10 GMT Content-Type: text/plain Transfer-Encoding: chunked Connection: keep-alive Strict-Transport-Security: max-age=15768000

Error: No such CGI app - /home/pi/www/xxxx/<script>cross_site_scrip ting.nasl</script>.pl may not exist or is not executable by this process .

Falls man es nicht braucht ist die einfache Lösung "- $req_params{SCRIPT_FILENAME}" einfach zu löschen...oder bessere Ideen ?

Grüße

Hey hey,

Ich würde ggf. noch einen Abschnitt bzgl. SSL & Poodle hinzufügen, sodass Nutzer sich dagegen absichern können - falls niemand was dagegen hat ...

Also noch die Datei "/etc/nginx/conf.d/ssl.conf" anlegen mit dem Inhalt:

# only use the new SSL protocols
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

# set ciphers to force PFS
ssl_prefer_server_ciphers on;
ssl_ciphers EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS;

Dann wird SSLv2 & SSLv3 abgeschaltet und nur Cipher benutzt die PFS bereitstellen.

Liebe Grüße,

icewave

Hallo,

ich werde wohl den Artikel mal für 14.04 testen & anpassen.

Vorab aber ein bisschen Diskussion:

Zwecks besserer Wartbarkeit würde ich die Abschnitt zu

• PHP

• Perl

in eigene Unterartikel auslagern.

Den Abschnitt zu Python + FastCGI würde ich kicken, weil das ziemlich veraltet ist. Der Python-Standard ist schon lange WSGI (was auch flächendeckend und von allen Webframeworks eingesetzt wird).

Dazu würde ich den Abschnitt "proxy_pass mit Django/Werkzeug" in eine Abschnitt "nginx als Proxy / Reverse-Proxy" umbauen - ist dann allgemeingültiger, gilt aber auch für Python.

Feedback ist willkommen. Wenn keine Gegenwehr kommt fange ich die Tage mal an.

Gruß, noisefloor

Unter Ubuntu 15.10 im Abschnitt php-fpm scheint es include fastcgi.conf zu sein statt fastcgi.config Ich bin mir nur nicht ganz sicher ob das im allgemeinen immer so ist.

Hi!

Die letzte Änderung zu nginx zeigt bei existierenden Dateien im Browser 403 an ist nicht gerade sonderlich klar:

Ein weiterer Grund kann ein fehlender Index sein. Der Eintrag autoindex on; kann Abhilfe schaffen.

Wo soll genau soll hier was eingetragen werden? Bitte etwas präzisieren, und gerne in passender Syntax.

so long
hank

Hallo,

außerdem ist es IMHO inhaltlich auch falsch autoindex on schaltet laut Doku 🇬🇧 das "directory listing" ein - was man a) bei öffentlicher Server in der Regel nicht will und b) sowieso kein probates Mittel gegen "403 forbidden" ist.

Habe Diddy1010 mal eine PN geschickt, sich hier zu äußern.

Gruß, noisefloor

Hallo,

ich glaube, ich muss mich hier bereits vorab entschuldigen. Hätte meinen Vorschlag vorab posten und mit dem Board besprechen sollen. Da ging mit mir die Freude über meine Problemlösung durch.

Zu meinem Problem: Habe auf einem kleinen Server, der nur zeitweise im Einsatz ist, nginx installiert und konfiguriert. Leider hatte ich keinen Zugriff auf die abgelegten Daten, da ich beim Aufruf immer den 403 erhillt. Erst nach dem autoindex on hatte ich Zugriff auf die abgelegten Daten. Da ich auch nach langer Suche keine entsprechenden Hinweise fand, dachte ich, dass dieser Umstand auch für andere hilfreich sein könnte, da der Rechtehinweis nicht die einzige mögliche Ursache für einen 403 ist. Das dies bei öffentlichen Servern nicht gewollt sein könnte, hatte ich zum Zeitpunkt meiner Artikeländerung nicht bedacht.

MfG

Diddy

Hallo,

ich glaube, ich muss mich hier bereits vorab entschuldigen.

Nee, brauchst du nicht ☺

Wie gesagt, "logisch" ist das IMHO nicht, weil autoindex rein gar nichts an den (Datei-) Rechten ändert. Vielleicht funktioniert das mit dem autoindex bei dir als Workaround. Klingt aber nicht wie eine saubere Lösung.

Tipp: poste dein Problem doch mal im "Serverdienste und Dateifreigaben im Netzwerk" hier bei ubuntuusers.de. Da bekommst du (hoffentlich) eine bessere Lösung als das mit dem autoindex.

Gruß, noisefloor

Ok wunderbar 👍

Gut das mach ich. Soll auch sauber laufen das gute Stück. ☺

Soll/kann ich den, von mir eingestellten Eintrag entfernen?

MfG

Diddy

Hallo,

Soll/kann ich den, von mir eingestellten Eintrag entfernen?

Habe ich gerade gemacht.

Falls ein von dir gestarteter Thread im Supportforum neu Erkenntnisse bringt, die brauchbar für's Wiki sind, kannst du das dann ja gerne ergänzen.

Gruß, noisefloor

Hallo,

wie vor 837 Tagen angekündigt habe ich den Perl und PHP Teil in eigene Artikel ausgelagert: nginx/PHP und nginx/Perl.

Gruß, noisefloor

Hallo,

in die Baustelle zwecks Aktualisierung.

Gruß, noisefloor

Hallo,

so, fertig. Alle veralteten / heute irrelevanten Teile der Konfiguration entfernt, die Konfiguration um ein kleines Beispiel erweitert und die Einleitung leicht überarbeitet. Alles ab "Tipps und Tricks" ist sonst quasi unverändert.

Gruß, noisefloor

Hallo,

Artikel ist wieder im Wiki.

Gruß, noisefloor

Hallo,

von nginx gibt es jetzt scheinbar einen Fork. Ist auch im Planeten nachzulesen.