Das längste Thema

Quote from Valkyrie

Seitdem wir auf der Arbeit einen Spam Filter haben, der konsequent auf korrektes SPF achtet, musste ich tatsächlich schon mehrere Firmen belehren. Das sind hauptsächlich Architektbüros oder ähnliches... aber auch eine Deutschlandweite Firma hatte es getroffen, deren Website aber auch aussah wie 1990 Wenn man einen Email Anbieter nutzt, der sogar ein richtiges SPF FAQ hat und seine zig IPs unter einem schönen Namen (z.B. "spf.anbieter.de") zusammenfasst, aber im SPF Record dann nur 93.schlag.mich.tot steht, hmpf!

Und verklicker das dann mal den Mitarbeitern, die sich wundern warum plötzlich keine Emails mehr von XYZ kommen.

"Wir haben jetzt eine bessere Spam Filterung und der Absender hat seine Emails nicht vernünftig konfiguriert."

"Aber vorher ging es doch auch!!"

Display More

Bei der gleichen Zielgruppe hatte ich das Spiel auch schon mal. Bei mir scheppert öfter mal was in Junk und Quarantäne rein, was ganz normal ist...

Die haben schon öfter mal Hausaufgaben von mir bekommen - aber mehr als eine Empfehlung kann ich da auch nicht aussprechen...

whoami0501 einfach rejecten, dann werdens sie schon merken,

dass sie was tun sollen, wenn deren Mails retourknallen;

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.

Quote from 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

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

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

Quote from 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…

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

Display More

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

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?

Quote from 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.

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:

#!/bin/bash

if [[ "$1" == "autoconf" ]]
then
    echo "no"
    exit 1
elif [[ "$1" == "config" ]]
then
    echo 'graph_title Nginx TLS Versions'
    echo 'graph_vlabel Requests per ${graph_period}'
    echo 'graph_args --base 1000'
    echo 'graph_category nginx'
    echo 'graph_total Total'

    # Diesen Teil könnte man eigentlich auch statisch ausgeben. Man weiß ja, welche Versionen man erwartet...
    awk='{ k=gensub(/[^a-z0-9_]/, "_", "g", tolower($2)); print k".label "$2"\n"k".draw AREASTACK\n"k".type DERIVE\n"k".min 0"; }'
else
    awk='{ k=gensub(/[^a-z0-9_]/, "_", "g", tolower($2)); print k".value "$1; }'
fi

sort /var/log/nginx/ssl.log | uniq -c | sort -k 2 | awk "$awk"

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.

Quote from 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.

Quote from whoami0501

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

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

Bezüglich Monitoring musste ich heute auch wieder mal jemanden beruhigen, der sich Sorgen um sein RAM gemacht hat, weil es beständig immer weniger wird.

Q: Hilfe. Mir geht das RAM aus!

A: Nö

Q: Aber es ist kaum noch was frei!

A: Gut so!

Q: ???

In diesem Sinne:

pasted-from-clipboard.png

So tot wie immer gesagt wird ist btrfs doch nicht: https://www.golem.de/news/entw…y-clones-2007-149444.html

Wobei zfs auch tun würde

Quote from 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

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

bzw. einfach nur

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.

Quote from whoami0501

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;

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

Quote from 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

Quote from 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

Display More

Danke, so weit war ich aber leider auch schon 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...

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.

Quote from 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...

Schlechte Neuigkeiten für die Nutzer von Teams, Zoom und Co.

Hinweise für Berliner Verantwortliche zu Anbietern von Videokonferenz-Diensten

Ja sowas aber auch, das hätte ja mal wieder keiner ahnen können.

Na, da haben wir ja mit BBB auf das richtige Pferd gesetzt.