Posts by m_ueberall

    H6G das dachte ich mir damals zwar, aber welchen Sinn hat der _dmarc TXT-Record dann noch?

    sprich: können Mails dann ohne einem _dmarc TXT-Record abgelehnt werden?

    Die rua- und ruf-Tags sind laut RFC7489 optional und beeinträchtigen die übrige Funktionalität nicht.

    Ganz ohne _dmarc-TXT-RR geht es aber nicht! Die v- und p-Tags sollten schon vorhanden sein…


    Linktip zum Thema: https://www.msxfaq.de/spam/dmarc.htm

    Quote

    Achtung:
    Als deutsche Firma sollten Sie überlegen ob sie selbst DMARC-Reports an andere Firmen senden oder in welcher Weise Sie die Reports aus Datenschutzgründen verwässern.
    https://www.eco.de/2015/presse…-empfiehlt-redacting.html

    […] den Sinn von dem DMARC hab ich übrigens nicht wirklich verstanden, zumal die Mails nicht wirklich Humanoid-lesbar sind X(

    Also, der Sinn ist ja in RFC7489 (DMARC) und RFC6591 (Authentication Failure Reporting Using the Abuse Reporting Format) beschrieben – man erhält eine Mail, wenn dem Empfänger keine korrekte Authentifizierung gelang; sofern man diese Berichte erhält und als Ursache weder eine lokale Fehlkonfiguration noch eine Fehlkonfiguration einer Mailingliste (vgl. Actually, DMARC works fine with mailing lists) identifizieren kann, ist die Ursache unter Umständen Mail-Spoofing (und genau darum, diesem auf die Spur zu kommen, geht es ja beim Einsatz von DMARC).

    Nachtrag: Die obige Einstellung im SCP regelt nur das Netcup-seitige Routing für die zusätzliche IP-Adresse, d.h. serverseitig muss diese natürlich auch verwaltet werden (siehe hierzu die Erläuterung im Netcup-Wiki).

    […] habe ich noch eine zusätzliche ip mir besorgt.

    nun kann ich diese zur zeit nicht "anpingen" da der rDNS noch nicht gesetzt ist

    meine frage nun: was trage ich nun in das rDNS feld ein?? […]

    Die zusätzliche IP-Adresse muss im SCP (unter "Netzwerk") zunächst dem gewünschten Server zugeordnet werden (ob die Zuordnung automatisch vorgenommen wird, wenn nur ein Server gemietet wurde, kann ich nicht sagen). Danach kann in das rDNS-Feld der gewünschte [FQ]DN, also [host.][subdomain.]domain.tld (Teile in eckigen Klammern sind optional) eingetragen werden, welcher im CCP normalerweise in derselben Form als DNS-Eintrag auftaucht. Im Bild unten wäre der grüne Platzhalter die zusätzliche IP-Adresse, der gelbe Platzhalter die primäre IP-Adresse des Servers, und rechts davon stehen die gewünschten Namen.

    rdns01.png

    Wenn ein Anpingen nicht funktioniert, liegt das entweder daran, dass der Server auf ein "ping" gar nicht reagiert (dann dürfte das auch nicht für die primäre IP-Adresse funktionieren), oder dass die zusätzliche Adresse noch gar nicht zugeordnet wurde. An der rDNS-Namensvergabe kann es nicht liegen, denn diese ist optional – manchmal wird eine Zuordnung zu einer Domäne hier auch absichtlich nicht vorgenommen...

    FYI: Wer Rspamd nutzt und u.a. Mails von Google Groups empfängt, sollte ein Aufge auf Issue #3090 haben und ggf. Rspamd 2.1 abwarten, bevor er von 1.9.x wechselt. Ein Blick auf die Mailingliste lohnt sich hier immer…

    Macht es also einen Unterschied, ob ich nun für den Mailversand mail.kundendomain.com oder mx2f6b.netcup.net nutze?

    Probieren geht über Studieren… ob mx2f6b.netcup.net entsprechende Anfragen akzeptiert, ist die eine Frage. Allerdings wird der "Originalname" überall wieder auftauchen, d.h. selbst bei Definition bspw. eines CNAME-Eintrags, welcher im MX-Eintrag namentlich referenziert wird, wird sich der Netcup-Mailserver wie folgt melden:

    [2019-10-19T15:12:14+0200] sys-maint@desktop01:~% telnet mail.kundendomain.com smtp
    Trying 188.68.47.107...
    Connected to mail.kundendomain.com.
    Escape character is '^]'
    220 mx2f6b.netcup.net ESMTP Postfix (Debian/GNU)
    ...

    Die Mailheader, IP-Adressen und – sofern die Domäne bei Netcup registriert ist – auch der WHOIS-Eintrag verweisen nach wie vor sichtbar auf Netcup als Dienst­leister. Ist mit o.g. Referenz also viel/genug gewonnen?

    [Zu Rspamd 2.0]

    Wie steht es bei euch um den Ram-Verbrauch bei der neuen Version?

    Kommt mir etwas hoch vor nach dem Mootober-Update :/

    Der Unterschied ist vernachlässigbar (hier zwei Mailserver im Active/Active-Betrieb zu Vergleichszwecken):

    […] Enable mal SELinux auf Deiner Maschine https://wiki.ubuntu.com/SELinux […]

    C-132 hat erwähnt, dass er Ubuntu 18.04 einsetzt – hier ist die Verwendung von AppArmor deutlich "gängiger" als SELinux. In Verbindung mit AppArmor oder einer generischer Einführung in "Härtungsansätze" ist unter anderem die Artikelreihe von Mike Kuketz empfehlenswert:

    1. Linux härten (Teil 1) – Sicheres Desktop-System
    2. Linux härten (Teil 2) – Linux Systemhärtung: Basis
    3. Linux härten (Teil 3) – AppArmor
    4. Linux härten (Teil 4) – FireJail

    https://ssl-config.mozilla.org/

    Mozilla hat überall den Prefer Server Cipher deaktiviert in den Konfigurationen. ¯\_(ツ)_/¯

    Ja, da gibt es zwei Meinungen; ich verwende momentan ebenfalls diese Einstellung (in der Quelle unten findet sich eine Erklärung – querlesen lohnt sich immer):

    Code: /etc/apache2/sites-enabled/100-default-ssl.conf
    1. # Let clients choose the cipher suite again: https://mastodon.at/@infosechandbook/102393205262657245
    2. SSLHonorCipherOrder off

    Es gibt hierzu einen Bugreport: Bug#942100: openssh-server: /etc/ssh/sshd_config unconditionally overwritten by update.

    Eine generische Absicherung gegen derartige Fehler zu empfehlen ist schwierig, da ein Überschreiben wirklich niemals vorkommen sollte, Modifikationen jedoch schon – blockiert man das eine, dann auch das andere. Verzögert man "unattended updates" in der Hoffnung, dass evtl. Fehler zwischenzeitlich behoben wurden, ist die Frage, welche Frist man hier ansetzen will (auf den obigen Fehlerreport hat nach knapp einer Woche bislang niemand auf der Mailingliste reagiert); und im Zweifelsfall muss man dann bestimmte Pakete doch im Auge behalten, was das zugrundeliegende Konzept der vorgenannten Updates teilweise aushebelt.

    Man kann jedoch in solchen Fällen unter anderem die Restaurierung von alten Konfigurationen erleichtern durch Installation von etckeeper.

    Kann ich noch etwas tun, um den Server mehr abzusichern?

    Dieses hier verinnerlichen: Das sichere Betreiben eines Servers ist eine niemals endende Aufgabe, welche regelmäßig viel Zeit in Anspruch nimmt.

    Als Einstieg: InfoSec Handbook: Web server security series durchlesen, einschlägige RSS-Feeds (Beispiel) abonnieren.

    Alleine bei Betreiben eines Webservers sollten "Stichworte" wie mod_security, OWASP, ... dem Administrator etwas sagen.

    Speziell Port 22 muss nicht zwingend dauerhaft geöffnet sein, dafür gibt es beispielsweise knock.

    Jegliche Administrationsschnittstellen/nicht-öffentliche Dienste lassen sich (lies: sind) mittels 2FA ab(zu)sichern, und sei es initial durch Beschränkung des Zugriffes auf den lokalen Host, über welchen man nur mittels SSH (port forwarding) herankommt.

    Protokolle über sicherheitsrelevante Ereignisse sind zum Lesen da. tenshi o.ä. kann helfen, diese vorzufiltern, aber man will immer alle Informationen im Zugriff haben.

    [Zu Rspamd 2.0] Ein Tip, nach was ich Ausschau halten soll? Dkim signing & ARC Sealing, etc. funktioniert.

    Exemplarische Beispiele ohne Anspruch auf Vollständigkeit, nachdem ich eine diff -r -U2-Ausgabe von >3200 Zeilen einmalig durchgesehen und auf knapp 600 Zeilen reduziert habe. Bei einem Test-Update und im laufenden Betrieb über die UI wurden keinerlei Warnungen diesbezüglich angezeigt–erst ein Blick auf die Paketinstallationsscripts wird zeigen, ob nutzerspezifische Anpassungen überprüft und wenn ja ggf. verschoben/angepasst werden:

    • In .../mime_types.conf: Nutzerdefinierte Include-Datei entfernt (Kommentare dokumentieren, dass sich Namen/Ort von Dateien teilweise änderte)
    • In .../greylist.conf: Referenz einer Include-Datei zeigt nun auf neu eingeführtes Unterverzeichnis
    • In .../arc.conf: Änderung der Vorgabewerte, was/wie signiert wird
    • In .../composites.conf: Einführung von "LEAKED_PASSWORD_SPAM_FP" mit Referenz auf "LEAKED_PASSWORD_SCAM" (befand sich ursprünglich in derselben Datei, wird nun aber gleichzeitig entfernt)
    • In .../options.inc: "dns_max_requests" entfernt (nicht mehr erforderlich?)
    • In .../surbl_group.conf: Viele Gewichtsänderungen (deutlich stärkere Gewichtung von RSPAMD_EMAILBL)

    Sicherlich delegiert man mit Verwendung vieler Standardwerte (die wenigsten werden bei eigenen Installationen übersteuert) sowieso viele Bewertungen an die Rspamd-Autoren, die sich mit dem Thema besser auskennen sollten. Aber wenn diese Gewichtungs-/Signatur-Änderungen jetzt im Rahmen eines Major-Releases "mit eingekippt" werden, will ich dennoch wissen, warum sich hier etwas geändert hat.

    Bibliotheks-/Backend-Änderungen (redis statt sqlite) sind das Eine, aber die Änderungen an der "business logic", welche nicht in der Migrations-Zusammenfassung in dieser Form erwähnt wird, sind das Andere.

    Ich hab vorhin mal zum test, ein Debian Buster updated und schein keine Probleme zu machen.

    Naja… Das Update läuft immer durch. Aufgrund von Namensraum- und Vorgabewertänderungen ist aber die Frage, ob wirklich alles noch so abläuft wie vorher. Je nach verwendeten Regelsätzen/Definitionen erforderte das eine Menge Einzeltests und/oder Analyse der Konfigurationen.

    Wer am Wochenende noch nichts vorhat: Rspamd 2.0 ist erschienen. Ich habe in zwei Antworttweets mal eine Statistik über geänderte Konfigurationen angehängt. Und nach erster sehr oberflächlicher Durchsicht haben sich hier unter anderem Vorgabewerte für die (ARC-)Signierung von Nachrichten geändert. Man sollte neben den kurzgefassten Migrationshinweisen also gegebenenfalls wirklich einmal einen Blick auf die diff-Ausgabe werfen. Und/oder vor dem Wochenende kein Update einspielen, da die neue Hauptversion im selben stable-Zweig liegt wie die vorhergehende. [I think also that I spider…]

    Aber trotzdem sehe ich keinen großen unerschied ich meine laufen die root server dann auf anderen servern welche eine bessere veerfügbarkeit haben oder wieso gibt es bei denen eine zufriedenheitsgarantie?

    Laut Aussagen des Geschäftsführers unterscheidet sich die eingesetzte Hardware(zusammenstellung); einige VPS-Sonderangebote dienen – nach internen Tests – bisweilen als "Testballons" (vgl. Optane-Cache), bevor vergleichbare RS-Angebote geschnürt werden. Ein anderes Beispiel ist der bessere/konstantere Festplattendurchsatz bei Rootserver- verglichen mit VPS-Angeboten (Thread).