Upgrade to Pro — share decks privately, control downloads, hide ads and more …

rspamd ...aus der Perspektive eines Hobbyadmins

rspamd ...aus der Perspektive eines Hobbyadmins

Traditionell besteht ein gängiges Setup eines Standalone-Mailservers aus einem Mail Transfer Agent wie Postfix, einem Mailfilter wie amavisd-new samt Spamfilter SpamAssassin und einen Virenscanner wie clamav sowie einem IMAP-Server wie Dovecot.

rspamd ist eine moderne Alternative zu amavisd-new und SpamAssassin, die insbesondere für Admins, die eher nebenher einem kleinen Mailserver für die Familie oder kleine Büros betreiben, interessant ist. Dieser Talk stellt rspamd vor und beschreibt basierend auf aktuellen Versionen >= 1.7.2 die Integration in ein Postfix-Setup, wie ich es für meine eigenen Domains verwende.

Pieter Hollants

August 25, 2018
Tweet

More Decks by Pieter Hollants

Other Decks in Technology

Transcript

  1. Pieter wer? Entwickler (vorallem Python) im Rhein-Main-Gebiet, aber auch... ➔

    3J Support-Front (zu Netware/Win95-Zeiten) ➔ 9J (Senior) Werkstudent im SUSE Consulting ➔ 4J Linux Systems Engineer bei der Deutschen Flugsicherung (u.a. Automatisierte Installationen hoch-verfügbarer Systeme, Hardware Standardisierung) ...und Freelancer seit über 15J (Dev & Admin)
  2. Gründe für eigenen Server Private Daten bleiben privat ➔ keine

    automatisierten Auswertungen (Werbung...) ➔ aber: nutzt wenig, wenn andere Seite bei GMail & co. Volle Kontrolle übers Mailsystem ➔ unendlich Speicherplatz, E-Mail-Adressen, Aliase... ➔ Spamfilterung, Virenscans, E-Mail-Sicherheit Unabhängigkeit von anderen Anbietern ➔ Tarifänderungen, komplette Diensteinstellung ➔ Kostenfaktoren nach https://thomas-leister.de/warum-eigener-mailserver/
  3. Gründe gegen eigenen Server Es ist Arbeit! ➔ Komplexes System

    mit vielen Komponenten ➔ Einmal manuell eingerichtet = in zwei Jahren vergessen ➔ Laufender administrativer Aufwand (vermisste Mails, Konfigurationstuning, Zertifikate...) Rechtlicher Rahmen ➔ eigentlich nur für Soloselbständige empfehlenswert, maximal Familien ➔ eigene kleine Firma besser bei unabhängigen Mailprovidern aufgehoben
  4. Mailserveranatomie (2/2) ➔ Erhöhte Komplexität durch Spam, Viren & co.,

    hier am Beispiel von Postfix ➔ amavisd-new als Interface zwischen MTA und content scanner ➔ SpamAssassin: Mail filter, in Perl geschrieben, automatisiertes Update der Regeln ➔ Virenscanner wie clamav, kommerzielle Vertreter ➔ Zwei smtpd-Instanzen benötigt: eine mit amavisd-new als Content Filter, eine ohne
  5. Hintergrund ➔ Geschrieben durch Vsevolod Stakhov ➔ Neuentwicklung aus Betroffenheit

    heraus: ➔ Administrierte E-Mail Systeme bei rambler.ru ➔ Vorhandene Lösungen erzeugten zuviel CPU-Last ➔ Releases: 0.2.7 (2009) → 1.0 (2015) → 1.7.9 (01.08.2018) ➔ Ziel: Performance für “Mass mail processing” ➔ Apache 2.0-Lizenz https://de.slideshare.net/VsevolodStakhov/rspamdfosdem-57772063
  6. Grundprinzip ➔ MTA reicht empfangene Mails an rspamd weiter ➔

    z.B. Milter-Schnittstelle ➔ Module werten Mails anhand von Regeln/Tests aus ➔ Jeder Test wird durch Symbol (Name) identifiziert ➔ Konfiguration weist Symbolen Scores zu ➔ Gesamtscore = ∑ Scores zutreffender Tests ➔ Abhängig von Gesamtscore Empfehlung an MTA ➔ Pass ➔ Reject ➔ Add header
  7. Features ➔ Content scanning ➔ Reguläre Ausdrücke ➔ Fuzzy hashes

    ➔ Policy checks ➔ SPF, DKIM, DMARC, ARC (→ Talk von Jan Büren, So 17:45) ➔ Realtime blacklists (RBLs): DNS-based IP checks, URLs ➔ Phishing checks ➔ IP reputation, Rate limits ➔ Greylisting ➔ Statistical tools ➔ Bayes classifier ➔ Neural networks ➔ Integriertes Webinterface inkl. Statistiken
  8. Architektur ➔ Kern in C geschrieben, Erweiterungsmodule in Lua ➔

    Eventgetriebenes Prozessmodell ➔ Paralleles Abarbeiten von Regeln ➔ Asynchrone Netzwerkrequests ➔ Unterschiedliche Typen von Regeln ➔ Pre rules (z.B. Greylisting) ➔ Normal rules (Scoring positiv/negativ) ➔ Post rules (z.B. Composite rules) ➔ Verschiedene Prozesse ➔ Hauptprozess (Config, Logs, Prozessmanagement) ➔ Scannerprozesse (Scannen Mails) ➔ Workerprozesse (Controller (API), Service (z.B. Lua host)) ➔ Viele Module nutzen Redis als Cache
  9. Konfigurierbares ➔ Zu aktivierende Module ➔ Eingebaute Module (C) vs.

    externe Lua-Module ➔ Modul-spezifische Konfigurationsoptionen ➔ z.B. antivirus: welche Virenscanner sollen verwendet werden ➔ Scores (Kommazahlen) ➔ z.B. Default config: FORGED_SENDER (Absender in Envelope und From: unterschiedlich) Gewicht 0,30 ➔ Aktionen bei Gesamtscore X ➔ z.B. Default config: Greylisting ab Gesamtscore 4,0 ➔ Worker-Konfiguration ➔ z.B. Listen-Sockets, Skalierung ➔ Allgemeine Optionen ➔ z.B. Timeouts
  10. Konfigurierbares ➔ Zu aktivierende Module ➔ Eingebaute Module (C) vs.

    externe Lua-Module ➔ Modul-spezifische Konfigurationsoptionen ➔ z.B. antivirus: welche Virenscanner sollen verwendet werden ➔ Scores (Kommazahlen) ➔ z.B. Default config: FORGED_SENDER (Absender in Envelope und From: unterschiedlich) Gewicht 0,30 ➔ Aktionen bei Gesamtscore X ➔ z.B. Default config: Greylisting ab Gesamtscore 4,0 ➔ Worker-Konfiguration ➔ z.B. Listen-Sockets, Skalierung ➔ Allgemeine Optionen ➔ z.B. Timeouts Austarieren dieser Stellschrauben entscheidet über Erfolg oder Misserfolg des gesamten Spamfilters! → Gereifte Default Config → Differentielle Anpassung
  11. Module: Kategorien 1. Module, die aufgrund Absender/Empfänger Domain/IP agieren 2.

    Module, die Nachrichtensignaturen überprüfen (gegen DNS- Einträge) oder selbst hinzufügen 3. Module, die Nachrichteninhalte gegen (DNS) Blacklisten prüfen 4. Module, die Nachrichten ohne DNS-Interaktion analysieren 5. Module, die Metadaten wie z.B. Absenderdomains an externe Datenbanken weiterleiten 6. Module, die statt Tests Aktionen implementieren 7. Sonstige Module Im Folgenden: Unterstrichen = eingebaute C Module; Rest = Lua
  12. Module (1/7) Module, die aufgrund Absender/Empfänger Domain/IP agieren: ➔ asn:

    Findet Autonomous System Number (ASN), Ländercode und Subnet von Absender IPs heraus ➔ ip_score: Trackt die Anzahl empfangener Nachrichten von einer IP, einem Subnet, einem ASN oder einem Land ➔ mx_check: Prüft, ob die Senderdomain im Envelope wenigstens einen erreichbaren MX hat (Standardconfig: aus) ➔ ratelimit: Begrenzt Mails von/für bestimmte Absender/Empfänger mittels Leaky Bucket-Methode ➔ rbl: Prüft Absender-IP gegen RBLs, Reverse DNS-Einträge, “Received:” Adressen und HELO/EHLO Parameter ➔ spf: Prüft die Sender Policy Framework (SPF) Policy der Absenderdomain
  13. Module (1/7) Module, die aufgrund Absender/Empfänger Domain/IP agieren: ➔ asn:

    Findet Autonomous System Number (ASN), Ländercode und Subnet von Absender IPs heraus ➔ ip_score: Trackt die Anzahl empfangener Nachrichten von einer IP, einem Subnet, einem ASN oder einem Land ➔ mx_check: Prüft, ob die Senderdomain im Envelope wenigstens einen erreichbaren MX hat (Standardconfig: aus) ➔ ratelimit: Begrenzt Mails von/für bestimmte Absender/Empfänger mittels Leaky Bucket-Methode ➔ rbl: Prüft Absender-IP gegen RBLs, Reverse DNS-Einträge, “Received:” Adressen und HELO/EHLO Parameter ➔ spf: Prüft die Sender Policy Framework (SPF) Policy der Absenderdomain .ru/.cn = Punktabzug? Komplex Einsatzszenario? Aber Vorsicht...
  14. Module (2/7) Module, die Nachrichtensignaturen überprüfen (gegen DNS- Einträge) oder

    selbst hinzufügen: ➔ arc: Prüft Authenticated Received Chain (ARC) Signaturen, die durch Mailrelays hinzugefügt wurden (ergänzt DKIM) ➔ dkim: Prüft/Ergänzt Domain Keys Identified Mail (DKIM) Signaturen (= ob Mail wirklich von der behaupteten Domain kommt) ➔ dmarc: Konsultiert DMARC TXT DNS-Einträge zum Verhalten bei fehlgeschlagenen DKIM/SPF-Checks ➔ mid: Unterdrückt negative Folgen fehlender “Message-Id” header für DKIM-signierter Mails bestimmter Domains (als Workaround für falsch konfigurierte Domains) ➔ whitelist: Erhöht/Reduziert Scores für Mails vertrauenswürdiger Quellen
  15. Module (2/7) Module, die Nachrichtensignaturen überprüfen (gegen DNS- Einträge) oder

    selbst hinzufügen: ➔ arc: Prüft Authenticated Received Chain (ARC) Signaturen, die durch Mailrelays hinzugefügt wurden (ergänzt DKIM) ➔ dkim: Prüft/Ergänzt Domain Keys Identified Mail (DKIM) Signaturen (= ob Mail wirklich von der behaupteten Domain kommt) ➔ dmarc: Konsultiert DMARC TXT DNS-Einträge zum Verhalten bei fehlgeschlagenen DKIM/SPF-Checks ➔ mid: Unterdrückt negative Folgen fehlender “Message-Id” header für DKIM-signierter Mails bestimmter Domains (als Workaround für falsch konfigurierte Domains) ➔ whitelist: Erhöht/Reduziert Scores für Mails vertrauenswürdiger Quellen Kenn bislang keine... Brauche ich bislang nicht... Kontrolle abgeben?
  16. Module (3/7) Module, die Nachrichteninhalte gegen (DNS) Blacklisten prüfen: ➔

    dcc: Konsultiert Distributed Checksum Clearinghouses (DCC), um festzustellen, ob Mail Spam ist ➔ emails: Extrahiert E-Mail Adressen und vergleicht sie gegen konfigurierte Listen oder DNS Blacklists ➔ fuzzy_check: Versucht Fuzzy Matching von Zeichenketten, um verschiedene Schreibweisen von typischen Formulierungen zu erwischen ➔ phishing: Versucht mittels OpenPhish-Dienst Phishing URLs in HTML-Mails zu finden ➔ surbl: Extrahiert URLs und Domains dieser URLs und prüft diese gegen Blacklists wie surbl.org, uribl.com, Spamhaus etc. (teils kommerziell) ➔ url_reputation: Experimentelles Modul, um URLs zu extrahieren und ihren Domains Reputationen zuzuweisen
  17. Module (3/7) Module, die Nachrichteninhalte gegen (DNS) Blacklisten prüfen: ➔

    dcc: Konsultiert Distributed Checksum Clearinghouses (DCC), um festzustellen, ob Mail Spam ist ➔ emails: Extrahiert E-Mail Adressen und vergleicht sie gegen konfigurierte Listen oder DNS Blacklists ➔ fuzzy_check: Versucht Fuzzy Matching von Zeichenketten, um verschiedene Schreibweisen von typischen Formulierungen zu erwischen ➔ phishing: Versucht mittels OpenPhish-Dienst Phishing URLs in HTML-Mails zu finden ➔ surbl: Extrahiert URLs und Domains dieser URLs und prüft diese gegen Blacklists wie surbl.org, uribl.com, Spamhaus etc. (teils kommerziell) ➔ url_reputation: Experimentelles Modul, um URLs zu extrahieren und ihren Domains Reputationen zuzuweisen Lizenzrestriktion & externer Daemon Gibt nützlichere Attribute in Mails Machtvoll, komplex, extra Worker, extra Learning, versuche es erstmal ohne... Aus gutem Grund experimentell?
  18. Module (4/7) Module, die Nachrichten ohne DNS-Interaktion analysieren: ➔ antivirus:

    Prüft Mails mittels externer Virenscanner wie clamav ➔ chartable: Bestraft auffällig viele Zeichencodierungswechsel (z.B. zwischen Latin und Chinese) ➔ maillist: Neutralisiert Regeln bei Nachrichten von Mailinglisten ➔ mime_types: Prüft MIME types und Inhalte von Archiven ➔ neural_networks: Experimentelles Modul, um neuronale Netze zur Mailklassifikation einzusetzen ➔ once_received: Tests für Mails mit nur einem Received Header ➔ regexp: Tests mit regulären Ausdrücken ➔ replies: Trackt Antworten auf eigenes Mails mittels Message-Id Header ➔ reputation: Experimentell, bislang undokumentiert ➔ trie: “Blitzschnelles” Durchsuchen nach Strings mit Aho-Corasick- Algorithmus
  19. Module (4/7) Module, die Nachrichten ohne DNS-Interaktion analysieren: ➔ antivirus:

    Prüft Mails mittels externer Virenscanner wie clamav ➔ chartable: Bestraft auffällig viele Zeichencodierungswechsel (z.B. zwischen Latin und Chinese) ➔ maillist: Neutralisiert Regeln bei Nachrichten von Mailinglisten ➔ mime_types: Prüft MIME types und Inhalte von Archiven ➔ neural_networks: Experimentelles Modul, um neuronale Netze zur Mailklassifikation einzusetzen ➔ once_received: Tests für Mails mit nur einem Received Header ➔ regexp: Tests mit regulären Ausdrücken ➔ replies: Trackt Antworten auf eigenes Mails mittels Message-Id Header ➔ reputation: Experimentell, bislang undokumentiert ➔ trie: “Blitzschnelles” Durchsuchen nach Strings mit Aho-Corasick- Algorithmus Lange verwendet, Nutzen vs. Aufwand bei kleinem MX “Heißer Scheiß” aber komplex Default expiry 24 hours zu kurz Experimentell, undokumentiert Was ist nicht versteh, brauch ich wohl nicht...
  20. Module (5/7) Module, die Metadaten wie z.B. Absenderdomains an externe

    Datenbanken weiterleiten: ➔ clickhouse: Leitet Daten an eine clickhouse.yandex Instanz weiter ➔ elastic: Leitet Daten an eine Elasticsearch-Instanz weiter ➔ history_redis: Speichert Historie in einer Redis-Instanz ➔ metadata_exporter: Exportiert Metadaten via Redis Publish/Subscribe-Channels, HTTP POST URLs und Mails ➔ metric_exporter: Exportiert Metriken an ein externes Monitoring-System (derzeit nur Graphite)
  21. Module (5/7) Module, die Metadaten wie z.B. Absenderdomains an externe

    Datenbanken weiterleiten: ➔ clickhouse: Leitet Daten an eine clickhouse.yandex Instanz weiter ➔ elastic: Leitet Daten an eine Elasticsearch-Instanz weiter ➔ history_redis: Speichert Historie in einer Redis-Instanz ➔ metadata_exporter: Exportiert Metadaten via Redis Publish/Subscribe-Channels, HTTP POST URLs und Mails ➔ metric_exporter: Exportiert Metriken an ein externes Monitoring-System (derzeit nur Graphite) Brauche ich alle nicht :)
  22. Module (6/7) Module, die statt Tests Aktionen implementieren: ➔ dkim_signing:

    Alternative zu dkims sign_condition (nicht wirklich eine Aktion da unabhängig von Score) ➔ force_actions: Erzwingt unabhängig von Message-Score eine Aktion, wenn bestimmte Symbole gefunden werden ➔ greylisting: Implementiert Greylisting (Temporäres Abweisen mit dem Ziel eines erneuten Zustellversuchs) ➔ milter_headers: Fügt Message Header wie x-spamd-bar und authentication-results hinzu
  23. Module (6/7) Module, die statt Tests Aktionen implementieren: ➔ dkim_signing:

    Alternative zu dkims sign_condition (nicht wirklich eine Aktion da unabhängig von Score) ➔ force_actions: Erzwingt unabhängig von Message-Score eine Aktion, wenn bestimmte Symbole gefunden werden ➔ greylisting: Implementiert Greylisting (Temporäres Abweisen mit dem Ziel eines erneuten Zustellversuchs) ➔ milter_headers: Fügt Message Header wie x-spamd-bar und authentication-results hinzu Einsatzszenario?
  24. Module (7/7) Sonstige Module: ➔ bayes_expiry: Entfernt veraltete Bayes Token

    ➔ multimap: Erlaubt es, Maps (z.B. Blacklists) dynamisch von URLs oder Dateien zu laden ➔ rspamd_update: Aktualisiert rspamd Regeln, Scores und Aktionen ohne rspamd-Neustart bzw. Upgrade ➔ spamassassin: Importiert SpamAssassin-Regeln ➔ url_redirector: Hilfsmodul für surbl, um Redirects in URL zu verfolgen ➔ url_tags: Experimentes Modul, dass “URL tags” in Redis cachet
  25. Module (7/7) Sonstige Module: ➔ bayes_expiry: Entfernt veraltete Bayes Token

    ➔ multimap: Erlaubt es, Maps (z.B. Blacklists) dynamisch von URLs oder Dateien zu laden ➔ rspamd_update: Aktualisiert rspamd Regeln, Scores und Aktionen ohne rspamd-Neustart bzw. Upgrade ➔ spamassassin: Importiert SpamAssassin-Regeln ➔ url_redirector: Hilfsmodul für surbl, um Redirects in URL zu verfolgen ➔ url_tags: Experimentelles Modul, dass “URL tags” in Redis cachet Brauchen wir das? Starten von Grund auf neu... Experimentell, kaum dokumentiert
  26. Installation ➔ CentOS 6/7, Fedora 21-25: ➔ yum Repos unter

    https://rspamd.com/rpm-stable/ ➔ CentOS-Pakete erfordern EPEL ➔ Debian/Ubuntu: ➔ apt Repos unter http://rspamd.com/apt-stable ➔ Debian-eigene Pakete “terribly outdated” ➔ openSUSE/SLES: ➔ zypper Repo unter https://download.opensuse.org/repositories/server:mail/ ➔ FreeBSD, OpenBSD: ➔ Ports collection ➔ Redis gleich mitinstallieren!
  27. /etc/rspamd ➔ common.conf, groups.conf und modules.conf: (Fast) nur Includes ➔

    metrics.conf: Deprecated! ➔ actions.conf: Aktionen und Gesamtscores ➔ statistic.conf: Derzeit nur Bayes classifier (eingebaut, kein Modul) ➔ composites.conf: Kombinationen von Symbolen → neue Symbole ➔ options.inc: Verschiedenes wie z.B. DNS timeouts, aber auch eingebaute Module via filters= Direktive ➔ logging.inc: Logging setup ➔ worker-*.inc: Worker setup, z.B. IP-Adressen
  28. /etc/rspamd/modules.d ➔ Modul-spezifische Konfigurationsdateien ➔ Inkludiert aus top-level modules.conf ➔

    Leider nur für Lua-Module ➔ Ein- und Ausschalten jeweils via enabled = true Zeile ➔ Teilweise Einbindung weiterer *.inc Dateien, die leider eine Ebene höher liegen, was etwas inkonsistent ist… ➔ Die meisten Module sind defaultmäßig aktiv ➔ Änderungen hieran schreien nach einem sed -i Job oder besser: Config Management ➔ redis.conf: Allgemeine Redis-Konfiguration
  29. /etc/rspamd/scores.d ➔ Mehr oder weniger thematisch sortierte Gruppen von Scores

    ➔ Inkludiert aus top-level groups.conf ➔ Leider nicht direkt erkennbar, welches Modul welche Gruppe bzw. welche Symbole verwendet ➔ Recht kryptische Symbolnamen wie z.B. HFILTER_HELO_4 ➔ Description hilft nicht immer weiter: “Helo host checks (hard)”
  30. https://www.0xf8.org/2018/05/an-alternative-introduction-to-rspamd-configuration-configuration-file-structure/ “Differentielle Anpassung” heißt: Ausgelieferte Konfigurationsdateien NICHT direkt ändern, sonst

    werden Updates unheimlich kompliziert! Stattdessen entweder rspamd.conf.local verwenden oder (besser): gleichnamige Kopie der jeweiligen Konfigurationsdatei anlegen in - /etc/rspamd/local.d (einzelne Direktiven; merge mit Original) - /etc/rspamd/overrides.d (ganze Blöcke; ersetzt Original). Beispiel /etc/rspamd/local.d/worker-controller.inc: password = $2$t4y… enable_password = $2$4y...
  31. Fazit ➔ Webinterface out-of-the-box, das nicht aussieht wie von 2000

    ➔ Out-of-the-box Konfiguration braucht kaum Anpassungen ➔ Zumindest für meine Minizwecke reduzierte Load nicht ausschlaggebend ➔ Dokumentation schon relativ gut ➔ Paar Merkwürdigkeiten bei Struktur der Konfigurationsdateien… geschenkt ➔ Aktives Projekt (GitHub-Tickets machen Sinn) ➔ rspamd ist schon toll!
  32. Ansible-Role (1/3) ➔ openSUSE server:mail-Repo hinzufügen ➔ rspamd installieren ➔

    override.conf stellt sicher, dass Redis vorher gestartet wird
  33. Ansible-Role (3/3) ➔ Bei Installation in einer neuen VM und

    noch ungeänderten externen DNS-Namen: Übernahme der rspamd-Daten der noch produktiven Instanz ➔ rspamd jetzt und beim Systemstart starten
  34. Ansible-Role nutzen ➔ controller worker: ➔ Bind Socket ➔ Passwörter

    ➔ proxy worker: ➔ Bind Socket ➔ Self Scan an ➔ normal worker: ➔ Aus wegen Self scan ➔ milter_headers: ➔ (Header, die wir wollen) ➔ Redis läuft lokal ➔ Logging: syslog / info ➔ That’s it!