Das längste Thema

    Also bisher ist meine Erfahrung so, dass wenn man den Leuten das vernünftig, in ruhe und nicht zu technisch erklärt, die dann auch sehr gut kooperieren. Ein Satz was SPF grob ist, wofür es da ist und dann noch eine kleine Übersicht warum das System meckert, was ich von meiner Seite aus für die Domain sehe und was meine Vermutung ist wie sich das beheben lässt. Dann sollen die das natürlich auch noch an die zuständige IT weiterleiten.

    Zitat von Valkyrie

    Also bisher ist meine Erfahrung so, dass wenn man den Leuten das vernünftig, in ruhe und nicht zu technisch erklärt, die dann auch sehr gut kooperieren.

    Ich habe eher die gegenteilige Erfahrung gemacht. Da kommt nur zurück: „Andere Kunden erreichen wir problemlos. Sie haben was geändert, also haben Sie keine Ahnung!!!“ Das geht dann auch öfters direkt CC an einen oder mehrere Leute in der Hierarchie über einem. Dazu kommt die Weigerung, allein zur „Prüfung“ dieses Problem an die eigene IT zu eskalieren.


    Ganz ehrlich:
    * SPF ist über 10 Jahre alt

    * Auch echt große Firmen reagieren genau so

    "Security is like an onion - the more you dig in the more you want to cry"

    Ich hätte das Monitoring für die TLS-Version lieber implementieren sollen, bevor ich TLS 1.0/1.1 abdrehe…

    nginx_tls-day.png

    Wobei "abdrehen" relativ ist. Ist ein neuer Server mit neuer Konfiguration :D

    (Auf den derzeit hauptsächlich Bots zugreifen. Deswegen soviel TLS 1.2.)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Zitat von killerbees19

    Ich hätte das Monitoring für die TLS-Version lieber implementieren sollen, bevor ich TLS 1.0/1.1 abdrehe…

    nginx_tls-day.png

    Wobei "abdrehen" relativ ist. Ist ein neuer Server mit neuer Konfiguration… :D

    (Auf den derzeit hauptsächlich Bots zugreifen. Deswegen soviel TLS 1.2.)

    Jetzt bin ich neugierig. Wie monitort man das bei nginx? Also an welche Schnittstelle geht man da ran?

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

    Hier gibt es doch sicherlich ein paar nginx- und/oder Traefik-sich-auskennende.

    Folgende Konstellation: reverse Proxy (bspw. nginx) <> Traefik <> Docker-Container mit Webserver.

    Wenn jetzt der Docker-Container ausfällt, liefert Traefik einen wunderschönen "404 page not found" mit dem Antwort-Header Content-Type: text/plain; charset=utf-8. Die Middleware "errors" behandelt leider nur HTTP-Fehler, welche vom Service, also dem Docker-Container, kommen -> greift nicht.

    Hat jemand eine Idee, wie ich den 404-Fehler vom Traefik (der mit dem Header) behandeln kann (einfach eine statische Fehlerseite), jedoch NICHT die Fehler, welche aus dem Docker-Container kommen?

    Zitat von whoami0501

    Wie monitort man das bei nginx? Also an welche Schnittstelle geht man da ran?

    Keine Ahnung, ob es dafür eine bessere Lösung gibt. Ich habe mich für die Holzhammermethode entschieden: Eigenes Logfile, das nach einem Tag wegrotiert wird.

    Code: nginx.conf
    log_format ssl '$ssl_protocol';
access_log /var/log/nginx/ssl.log ssl;

    Nginx kann zum Glück in mehrere Access-Logs gleichzeitig schreiben. Aber Achtung, das gilt angeblich nur fürs aktuelle Konfigurationslevel! Wenn Du das Access-Log irgendwo neu definierst, muss das zweite Log dort ebenfalls nochmals konfiguriert werden. Außer Du willst es dort nicht haben.

    In Munin landen die Daten dann so, ist aber relativ unschön gelöst:

    Ganz interessant sind auch die anderen Variablen, wenn man sie mal in ein eigenes Logfile oder direkt ins access.log packen möchte. Damit kann man z.B. den genutzten oder die unterstützten Cipher protokollieren. Das kann besonders zum Debuggen von Verbindungsproblemen sehr nützlich sein.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Zitat von timkoop

    Hat jemand eine Idee, wie ich den 404-Fehler vom Traefik (der mit dem Header) behandeln kann (einfach eine statische Fehlerseite), jedoch NICHT die Fehler, welche aus dem Docker-Container kommen?

    Dein nginx reicht das ja nur durch. Du könntest mit proxy_hide_header Content-Type; arbeiten. Das sollte eigentlich helfen.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

    Zitat von timkoop

    Ich will den Header ja nicht verschwinden lassen, nginx soll eine Fehlerseite für den Traefik-404 anzeigen; bei allen anderen Fehlern jedoch die reguläre Fehlerseite aus dem Container


    Uff. Na dann suchst du wohl eher sowas

    Code
    error_page 404 =404 @notfound;
location @notfound {
        return bla;
}

    bzw. einfach nur

    Code
    error_page 404 /bla.html;


    EDIT: Ach bzgl. SPF - das habe ich heute noch besser gesehen: Mail kommt von domain.tld bzw. 1.2.3.4 - der SPF von domain.tld erlaubt diese IPv4 Adresse auch. In besagten Fall hat man die Mails durch ein Relay geschoben und dann die SPF Prüfung vorgenommen. Dummerweise steht die IPv4 des Relays bloß bei niemandem im SPF Record... dementsprechend hämmert der Mailserver alles von extern grundsätzlich erstmal in den Spam.

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

    Zitat von timkoop

    Das bewirkt eben leider, dass auch 404-Seiten aus dem Container "überschrieben" werden:)

    Okay Okay - ich habe jetzt kein Beispiel, aber einen Plan.

    Pseudocode:

    Wenn Statuscode aus dem Upstream gleich 404 und Content Type Header aus dem Upstream gleich "text/plain; charset=utf-8" dann

    zeige folgende Seite

    Vielleicht hilft dir das ^^

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

    Zitat von whoami0501

    Okay Okay - ich habe jetzt kein Beispiel, aber einen Plan.

    Pseudocode:

    Wenn Statuscode aus dem Upstream gleich 404 und Content Type Header aus dem Upstream gleich "text/plain; charset=utf-8" dann

    zeige folgende Seite

    Vielleicht hilft dir das ^^

    Danke, so weit war ich aber leider auch schon :D Ich hätte vielleicht meine Erkenntnisse direkt mit nennen sollen:/

    An der Umsetzung davon hapert es leider. Den Header kann man zwar mit nginx abfragen, jedoch konnte ich den nicht dazu bewegen, eine statische Seite anzuzeigen anstatt dem Proxy zu folgen...

    Zitat von killerbees19

    @timkoop Soll sich der Content-Type dann auch ändern und nur der ausgegebene Body? Bei Letzterem könnte man mit dem sub-Modul tricksen: http://nginx.org/en/docs/http/ngx_http_sub_module.html

    Das kann man auch auf bestimmte MIME-Typen einschränken.

    Ich bin mir nicht sicher, aber ich glaube HTML und text/plain vertragen sich nicht so gut; kann mich da aber auch täuschen. -> Content-Type müsste wahrscheinlich auch geändert werden.

    Das sub-Modul klingt schon einmal vielversprechend, aber wie stellst du dir das tricksen vor? Dann müsste ich ja den String "404 page not found" mit massig HTML ersetzen...