Denn eines hat sich über die Jahre nicht verändert: WordPress läuft nach der Installation zunächst relativ träge. Dabei ist es für eine gute Nutzererfahrung und auch für Google wichtig, dass die Seite schnell lädt.

Zum Glück gibt es jedoch bewährte Methoden und Tipps, mit denen man seiner Webseite den nötigen Turbo-Boost verpassen kann. In diesem Blogbeitrag möchte ich euch zeigen, wie ihr eure WordPress Seite schneller machen könnt.

Verwendet nginx statt Apache

Ganz ehrlich: Ich bin mit Apache “groß geworden” und die Konfiguration dessen geht mir leicht von der Hand. Trotzdem muss ich ehrlich zugeben, dass der Webserver nicht der schnellste ist. Ich habe daher bei meinem neuen Projekt von Anfang an auf nginx gesetzt und dies alleine machte das zu dem Zeitpunkt noch jungfräuliche WordPress schon super schnell.

Es gibt auch zahlreiche Benchmark-Ergebnisse dazu, z.B. hier auf cyberpanel.net wird sehr ausführlich darüber berichtet.

Verwendet ein gutes Caching-Plugin

Ein Caching-Plugin rendert die dynamische Webseite vor und speichert sie als statisches HTML ab, sodass der Webserver sie einfach ausliefern kann. Dies kann einen riesen Unterschied machen.

Ich habe mir alle verfügbaren Caching-Plugins angesehen und finde WP Fastest Cache mit Abstand am besten. Es ist sehr einfach zu konfigurieren und hat die Ladezeiten gefühlt um 90% reduziert.

Die korrekte Funktion kann man mittels einem Kommentar im HTML der Website überprüfen:

Verwendet einen Redis Object Cache

Das WordPress-Plugin “Redis Object Cache” erweitert den standardmäßigen Object Cache und nutzt Redis, um Daten zwischen Anfragen zu speichern. Daher kann dieses Plugin nur genutzt werden, wenn Ihr Redis installiert habt bzw. installieren könnt.

Was ist Redis?

Redis ist ein Open-Source, in-memory Datenstrukturspeicher, der als Datenbank, Cache und Message Broker verwendet werden kann. Da sämtliche Daten im RAM liegen, ist er wahnsinnig schnell.

Unter Ubuntu 22.04 ist dieser super einfach via

apt-get install redis-server

zu installieren.

Er muss für eine simple lokale Installation nicht weiter konfiguriert werden. Der Dienst lauscht automatisch auf 127.0.0.1:6379 und ::1:6379 – ist also nur vom Server selbst zu erreichen.

Anschließend kann das WordPress-Plugin installiert und mit der lokalen Redis-Instanz verbunden werden.

Verwendet ein Bild-Kompressions-Plugin

Es gibt eine Reihe von Plugins, welche alle verwendeten Bilder automatisch richtig komprimieren, sodass nicht unnötig große Daten übertragen werden. Ich habe diesmal Smush verwendet und nutze aus dem Plugin auch die Lazy-Load Funktion, damit Bilder dynamisch und erst beim Scrollen nachgeladen werden.

Mit diesen Tipps solltet ihr eure Seite deutlich beschleunigen können. Nach diesen Optimierungen erreiche ich einen PageSpeed Insighs Wert von 96 für den Desktop.

Der Beitrag WordPress Seiten beschleunigen erschien zuerst auf SYN-FLUT.de.

Seit etwa 2015 weht frischer Wind im Bereich Open-Source Spamfilter für Linux. Lange Zeit gab es im Prinzip nur SpamAssassin. Eine millionenfach bewährte Software, die zuverlässig ihren Job tut. Auch ich war nach einigen Optimierungen damit sehr zufrieden. Dennoch kann ich mir gut vorstellen, dass Rspamd in den nächsten Jahren hier stark Marktanteile übernehmen wird. Warum?

Rspamd ist super einfach zu implementieren

Es integriert sich sehr einfach in viele verschiedene MTAs. Nach der Installation von Rspamd ist in Postfix genau eine Zeile Konfiguration notwendig:

smtpd_milters = inet:localhost:11332

Und schon ist Postfix um einen Spamfilter erweitert. Jedoch nicht *nur* um einen Spamfilter:

Rspamd ersetzt alles andere

Früher verwendete ich neben SpamAssassin für die reine Spamfilterung noch Postgrey fürs Greylisting, OpenDKIM für das Hinzufügen von DKIM-Signaturen und Amavis für die Anbindung von Virenscannern an Postfix.

All das kann Rspamd von Haus aus. Und noch viel mehr.

Rspamd wird als milter in den MTA integriert, deshalb bekommt Rspamd jeden Status des Mailempfangs mit und kann zu jedem Zeitpunkt manipulativ eingreifen oder dem MTA mitteilen, er möge die Mail temporär (Greylist) oder dauerhaft ablehnen.

Rspamd ist die modernere Software

Der Kern ist in C geschrieben, die Module in Lua. Zusätzlich kann Redis als Key-Value Datenbank im Backend verwendet werden.

Tipp: Redis sollte auch in jedem Fall als Backend Datenbank verwendet werden, sonst bleiben viele Features (z.B. Greylisting, Rate Limiting, Neuronales Netzwerk, u.v.m) deaktiviert. Ich schreibe demnächst hier einen Beitrag, wie eine Rspamd Installation um Redis erweitert werden kann. Dadurch kann die Rspamd Erkennungsrate wesentlich verbessert werden.

Außerdem bringt es ein schickes Webinterface mit vielen nützlichen Statistiken mit.

Die Entwickler arbeiten stark an der Weiterentwicklung von Rspamd. Es wird immer nur die aktuellste Version unterstützt. Außerdem wollen die Entwickler Anpassungen durch die Linux-Distributionen vermeiden. Die Installation erfolgt üblicherweise über ein 3rd-Party-Repository direkt von Rspamd, sodass automatisch immer die aktuellste Version installiert ist.

Rspamd ist schnell

Laut der offiziellen Webseite wurde Rspamd von Anfang an auf Geschwindigkeit hin optimiert und benötigt nur ein Bruchteil der Ressourcen im Vergleich zu SpamAssassin. Das ist für mich persönlich jedoch weniger wichtig, so viele Mails gehen bei meinen Servern nicht durch, als das ich hier ein Unterschied merken würde.

Rspamd filtert überragend

Nach meiner Migration zu Rspamd vor circa einen Monat kam bis heute tatsächlich keine einzige Spam-Mail mehr durch. Auf die Konfiguration gehe ich im nächsten Artikel näher ein.

Rspamd wird immer bekannter

Aktuell ist die Software noch etwas unbekannt. Sie hat z.B. noch keinen Wikipedia-Artikel. Dennoch merke ich einen starken Zulauf, vor allem in den letzten zwei Jahren. Zum Beispiel berichtete kürzlich die Freak Show darüber. Außerdem verwendet Christoph Haas in seinem bekannten und seit vielen Jahren bewährtem Mailserver-Tutorial ISPMail nun ebenfalls Rspamd. Selbiges macht auch Thomas Leister im nicht weniger guten Tutorial von ihm. Deutlich wird der Trend auch auf Google Trends:

Weitere Informationen

Findet ihr neben dem offiziellen Quick-Start-Guide auch in einer sehr guten Präsentation von Heinlein Support.

Der Beitrag Rspamd, das bessere SpamAssassin erschien zuerst auf SYN-FLUT.de.

Die meisten Tipps meines Artikels “SpamAssassin Erkennungsrate (deutlich) verbessern” sind auch für Plesk-Server interessant. Bei einigen Details muss man jedoch aufpassen, da Plesk gerne Konfigurationsdateien überschreibt und auch “Eigenkonsktrukte” einbaut. So ist z.B. der LDA (Local Delivery Agent) meines Wissens nach eine Eigenentwicklung von Plesk. Mit folgenden Maßnahmen habe ich gute Ergebnisse erzielt:

Verwendet einen lokalen Resolver

Wie ich bereits im Hauptartikel “SpamAssassin Erkennungsrate (deutlich) verbessern” näher erklärt habe, ist der wichtigste Schritt, einen lokalen DNS-Resolver zu verwenden. Die voreingestellten DNS-Server sind häufig bei vielen DNSBLs auf der Blacklist. Deshalb klappen viele Checks von SpamAssassin nicht und die Erkennungsrate von Spam lässt deshalb zu Wünschen übrig. Bei Ubuntu 16.04 reicht es aus, unbound zu installieren und diesen anschließend in der resolv.conf einzutragen.

apt update 
apt install unbound
nano /etc/resolv.conf
  # vorhandene DNS-Server auskommentieren
  # nameserver x.x.x.x
  # nameserver y.y.y.y

  # eigenen DNS-Resolver eintragen
  nameserver 127.0.0.1

Mehr sollte nicht nötig sein. Ich halte übrigens nichts davon, die zuvor eingestellten Nameserver weiterhin als “Backup” eingetragen zu lassen. Soweit mir bekannt schickt Linux DNS-Requests immer an alle DNS-Server gleichzeitig und verwendet dann die Antwort, die am schnellsten eingetroffen ist. Damit schießt man sich mitunter ins eigene Knie, wenn die externen Server Einträge bereits im Cache haben, die der lokale Unbound erst noch auflösen muss.

Zusatztipp: Bei OpenVZ-Basierten Servern wird die Datei /etc/resolv.conf bei jedem Boot mit der vom Provider gesetzten Standardkonfiguration überschrieben. Der Fehler passiert schnell und bleibt häufig unbemerkt. Bis auf den Umstand, dass noch immer viel Spam durchkommt. Im Zweifel Server durchbooten und prüfen, ob die Datei durch den Boot modifiziert wurde.

Abhilfe schafft hier das Sperren der Datei, sodass noch nicht mal mehr Root Schreibzugriff hat:

chattr +i /etc/resolv.conf

Falls man die Datei irgendwann wieder bearbeiten möchte, muss man sie zuvor mit dem Flag -i wieder entsperren.

Ich habe die Erfahrung gemacht, dass Plesk-basierte Server manchmal von Haus aus einen Bind9 DNS Server installiert haben, der bereits korrekt konfiguriert ist. Auch, wenn in den Service-Einstellungen von Plesk der “DNS-Service” deaktiviert ist. In einem Fall war der Service jedoch nach einem Neustart nicht mehr verfügbar. Deshalb habe ich mich lieber nicht drauf verlassen und Bind9 kurzerhand deaktiviert:

netstat -tulpen | grep :53 #check, ob ein Daemon auf Port 53 lauscht. Falls es named (Bind9) ist:
systemctl stop bind9.service
systemctl disable bind9

Verwendet Pyzor und Razor

Auch hier ist die Konfiguration nahezu identisch mit meiner Vorgehensweise aus dem Hauptartikel. Deswegen liste ich hier nur kurz die Kommandos für Ubuntu 16.04 auf:

# Zunächst installieren:
apt install pyzor razor

# Pyzor und Razor initialisieren:
pyzor --homedir /etc/mail/spamassassin discover
mkdir /etc/spamassassin/.razor
sudo razor-admin -home=/etc/spamassassin/.razor -register
sudo razor-admin -home=/etc/spamassassin/.razor -create
sudo razor-admin -home=/etc/spamassassin/.razor -discover

# Anpassungen in einer neuen Datei vornehmen.
# Wichtig: nicht in /etc/spamassassin/local.cf eintragen (wie in meinem Hauptbeitrag gezeigt)
# da diese Datei bei Plesk-Updates überschrieben werden könnte.

nano /etc/spamassassin/99_pyzor_razor.cf
	use_pyzor 1
	pyzor_options --homedir /etc/mail/spamassassin
	pyzor_path /usr/bin/pyzor
	use_razor2 1
	razor_config /etc/mail/spamassassin/.razor/razor-agent.conf

    # Anpassung der Scores, wie ich ebenfalls im Hauptartikel erläutere
	score RCVD_IN_BL_SPAMCOP_NET 0 5.246 0 5.347
	score RCVD_IN_BRBL_LASTEXT 0 5.246 0 5.347
	score URIBL_BLACK 0 5.7 0 5.7
	score URIBL_WS_SURBL 0 2.659 0 2.608
	score URIBL_MW_SURBL 0 2.263 0 2.263
	score URIBL_CR_SURBL 0 2.263 0 2.263
	score URIBL_GREY 0 2.084 0 1.424
	score URIBL_DBL_SPAM    0 4.5 0 4.5
	score URIBL_DBL_PHISH   0 4.5 0 4.5
	score URIBL_DBL_MALWARE 0 4.5 0 4.5
	score URIBL_DBL_BOTNETCC 0 4.5 0 4.5
	score URIBL_DBL_ABUSE_SPAM 0 4.0 0 4.0
	score URIBL_DBL_ABUSE_PHISH 0 4.5 0 4.5
	score URIBL_DBL_ABUSE_MALW  0 4.5 0 4.5
	score URIBL_DBL_ABUSE_BOTCC 0 4.5 0 4.5

Installiert das extremeshok-Plugin nach

Auch hier zeige ich nur die Kommandos und verweise auf den Hauptartikel.

cd /tmp
wget https://github.com/extremeshok/spamassassin-extremeshok_fromreplyto/archive/1.3.1.tar.gz
tar -zxvf 1.3.1.tar.gz
cd spamassassin-extremeshok_fromreplyto-1.3.1/
mkdir /etc/mail/spamassassin/plugins/
cp plugins/* /etc/mail/spamassassin/plugins/
cp 01_extremeshok_fromreplyto.cf /etc/mail/spamassassin
systemctl restart spamassassin.service

Verwendet zusätzliche Regeln

Um die Regeln von Heinlein Support nachzuinstallieren, habe ich auf Basis des original Cron-Scripts eine Variante dafür gebastelt. Dieses Script kann auch zur initialen Installation verwendet werden. Wenn es unter /etc/cron.daily liegt und ausführbar ist, führt es Ubuntu ab sofort selbständig aus.

nano /etc/cron.daily/61sa-update-heinlein

	#!/bin/bash

	sa_update()
	{
	        /usr/bin/sa-update --nogpg --channel spamassassin.heinlein-support.de
	        local rc="$?"
	        case $rc in
	                # Only restart spamd if sa-update returns 0, meaning it updated the rules
	                0) env PATH=/opt/psa/admin/sbin:/usr/local/psa/admin/sbin:$PATH spammng --condrestart ;;
	                # If sa-update returns 1 then there are no updates
	                1) exit 0 ;;
	        esac
	        return $rc
	}

	sa_update >> /var/log/sa-update.log 2>&1
	exit 0

# Datei ausführbar machen
chmod +x /etc/cron.daily/61sa-update-heinlein

# Einmal händisch ausführen, sodass die Regeln heruntergeladen werden
/etc/cron.daily/61sa-update-heinlein

# Und zum Schluss SpamAssassin durchstarten.
systemctl restart spamassassin.service

Lasst Plesk SpamAssassin trainieren

Plesk liefert praktischerweise eine eigene Funktion mit, die den SpamAssassin Bayes-Filter anhand der sich bereits in den Mailboxen befindlichen Mails trainiert. Dabei werden alle gelesenen Mails im Posteingang als “Ham” gelernt, alle Mails im Spam-Ordner hingegen als “Spam”. Die Besonderheit der Funktion ist, dass jede Mailbox seine eigene Bayes-Datenbank benutzt. Das lässt sich meines Wissens auch nicht (ohne großen Aufwand) ändern.

Ein Userbasiertes Training ist auf der einen Seite super, da es sehr genau ist und keine Probleme durch anderer User Mails entstehen können. Auf der anderen Seite werden für das Training eine Menge Mails benötigt. Diese Mails muss jeder Benutzer selbst im Postfach haben, sonst bleibt der Bayes-Filter für dasjenige Postfach einfach deaktiviert. Ich glaube erst nach 200 gelernten Ham-Mails und zusätzlich 200 gelernten Spam-Mails aktiviert sich das Bayes-Modul.

Laut der (etwas widersprüchlichen) Online-Hilfe von Plesk wird das Modul wohl nicht selbständig gestartet, deshalb habe ich vorsichtshalber ein Script unter /etc/cron.daily platziert:

nano /etc/cron.daily/80-spamtrain
	#!/bin/bash
	echo "spamtrain started at $(date)" >> /var/log/spamtrain.log
	plesk daily ExecuteSpamtrain >> /var/log/spamtrain.log 2>&1
	exit 0

# Datei ausführbar machen
chmod +x /etc/cron.daily/80-spamtrain

# Und einmal händisch laufen lassen
/etc/cron.daily/80-spamtrain

Setzt die max. Mailgröße hoch

Plesk ist im Standard so eingestellt, dass nur Mails bis zu einer Größe von 256kb überhaupt durch SpamAssassin überprüft werden. Größere Mails werden überhaupt nicht geprüft und landen direkt im Posteingang. Ein gefundenes Fressen für Spam-Mails mit größeren Bildern.

Entlarven kann man solche Mails an den fehlenden SpamAssassin-Zeilen im Mail-Header. Ich habe daher die maximale Dateigröße auf 15MB hochgesetzt, da jede Mail durch SpamAssassin geprüft werden soll, auch wenn das mehr Ressourcen kostet:

nano /etc/psa/psa.conf
	# folgenden Wert suchen und anpassen, sollte ganz unten in der Datei sein
	SA_MAX_MAIL_SIZE 15728640

Das waren meine Tipps, um die Spam-Erkennungsrate von SpamAssassin auf Plesk-Servern wesentlich zu steigern. Falls Ihr noch weitere Tipps auf Lager habt, lasst sie mich gerne in den Kommentaren wissen.

Der Beitrag SpamAssassin auf Plesk-Servern ideal einstellen erschien zuerst auf SYN-FLUT.de.

Wenn das passiert, wird ein “Fallback mode” verwendet, da auf die korrekten Zeichen nicht zugegriffen werden konnte. Zwei Dinge sind dafür üblicherweise verantwortlich:

Putty Zeichensatz und “terminal-type string”

Die Software ncurses ist für die Zeichnung von Boxen und Rahmen unter Linux zuständig. Diese wertet den “terminal-type string” aus, mit welchem sich der Client verbindet. PuTTY (und auch KiTTY) hat hier aus Kompatibilitätsgründen “xterm” eingestellt, das sollte durch “putty” ersetzt werden. Ebenso sollte UTF8 als Remote-Zeichensatz eingestellt sein.

Zeichensatz auf dem Server korrekt einstellen

Eventuell ist auch noch der Zeichensatz falsch eingestellt. Überprüft werden kann das mittels

locale

Beheben lässt sich es mit

export LC_ALL=en_US.utf8

Damit diese Einstellung auch bei der nächsten Verbindung noch vorhanden ist, muss sie in die .bashrc eingetragen werden. (Oder .zshrc, falls ihr zsh verwendet.)

echo "export LC_ALL=en_US.utf8" >> ~/.bashrc

Ab jetzt sollte PuTTY Rahmen ausgeben können:

Jetzt sollte die Zeichnung von Rahmen fehlerfrei funktionieren.

Der Beitrag QuickTipp: Rahmen statt “lqqk” in der PuTTY Shell erschien zuerst auf SYN-FLUT.de.

Vor kurzem habe ich einen Blog von Blogger zu WordPress migriert und möchte hier nun meine Erfahrungen teilen. Ich gehe im Folgenden davon aus, dass bereits eine funktionierende WordPress Installation vorliegt, oder die Migration in die WordPress-Cloud stattfindet. Eine gute Anleitung, wie WordPress auf eigenem Webspace installiert werden kann, findet sich hier: WordPress in 5 Minuten installieren

Backup des aktuellen Blogs

Damit nichts schief gehen kann, würde ich empfehlen, zunächst ein Backup vom “Live-Blog” auf Blogger zu erstellen. Damit kommt man im Falle des Falles jederzeit zum Ursprung zurück.

Import der Beiträge zu WordPress

Glücklicherweise gibt es für den Import ein tolles Plugin, welches die Hauptarbeit erledigt: Blogger Importer Extended

• Es importiert sämtliche Beiträge, inklusive Formatierung.
• Die Kategorien der einzelnen Beiträge werden ebenfalls richtig übernommen, allerdings im WordPress als Schlagwörter abgelegt. Dies werden wir nachher noch beheben.
• Ebenso werden alle statischen Seiten importiert.
• Die Kommentare (sogar verschachtelte Antworten) werden perfekt mitgenommen.
• Alle Bilder werden importiert und in der WordPress Mediathek abgespeichert.
• Sämtliche Blog-Internen Links (von einem Beitrag zum anderen) werden richtig umgeschrieben und übernommen. Dabei spielt es keine Rolle, welche Art von Permalinks im WordPress verwendet wurden.

Der Prozess klappte bei mir sehr gut. Das Layout passte auch bei den meisten Beiträgen. Allerdings waren jede Menge Styles im HTML der importierten Beiträge. Hier kam ich manchmal nicht drum rum, die Einträge händisch zu optimieren.

Schlagwörter zu Kategorien konvertieren

Das Importplugin macht einen super Job, allerdings werden die importierten “Tags” zu Schlagwörtern. Ich wollte lieber Kategorien haben, deswegen verwendete ich das Plugin “Kategorie-in-Schlagwort-Konverter“, welches selbsterklärend ist und auch in die andere Richtung funktioniert.

Anschließend sind alle Kategorien erstellt, allerdings noch nicht den Posts zugeordnet. Auch hier helfen wir uns mit einem Plugin: Batch-Move, welches für alle möglichen Batch-Aufgaben verwendet werden kann. Mit wenigen Klicks sind alle Posts in den entsprechenden Kategorien.

Weiterleitung vom alten zum neuen Blog

Wenn der neue WordPress Blog steht und alles importiert wurde, möchte man in der Regel den Besucherstrom und sein Google-Ranking nicht verlieren. Hier bietet sich das Plugin Blogger 301 Redirect an. Es erzeugt ein neues Blogger-Template, welches dann automatisch alle Besucher zum neuen Blog umleitet. Auf den neuen WordPress Blog bleibt das Plugin weiterhin aktiv, um in Echtzeit ein “Mapping” zwischen den alten und den neuen Einträgen zu machen. Somit wird wirklich jeder Link, egal ob Beitrag, Kategorie oder Kommentar, perfekt zum neuen Blog weitergeleitet. Weitere Informationen und viele Screenshots hat der Entwickler auf seiner Website bereitgestellt.

Mit diesen Mitteln habe ich kürzlich von Blogger auf WordPress migriert. Ich hoffe, dass euch die Tipps etwas weiterhelfen!

Der Beitrag Blogger zu WordPress Migration: so gehts erschien zuerst auf SYN-FLUT.de.

Im Folgenden beschreibe ich, wie bereits mit Postfix Antispam Maßnahmen eingeführt werden können. Dazu habe ich die relevanten Ausschnitte der Postfix Konfigurationsdatei /etc/postfix/main.cf beigefügt. Wichtig ist mir hierbei, dass die unten aufgeführten Einstellungen keineswegs einfach per Copy&Paste übernommen werden sollten. Die Konfiguration funktioniert bei mir sehr gut, trotzdem solltet ihr genau wissen, was ihr tut.

Die Konfiguration wurde unter Ubuntu 14.04 (Postfix 2.11) erstellt und getestet. Seit Postfix 2.10 wird für das (authentifizierte) Relayen von Mails die Konfiguration unter smtpd_relay_restrictions verwendet. In früheren Versionen wurden die Einstellungen unter smtpd_recipient_restrictions verwendet, was manchmal zu komischem Verhalten führte. Weitere Informationen dazu gibt es auf der Postfix Homepage.

Die Konfiguration

smtpd_sender_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_unknown_sender_domain,
  reject_non_fqdn_sender
smtpd_recipient_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_unauth_destination,
  reject_unauth_pipelining,
  check_client_access hash:/etc/postfix/client_checks,
  check_sender_access hash:/etc/postfix/sender_checks,
  reject_unknown_helo_hostname,
  reject_invalid_hostname,
  reject_non_fqdn_hostname,
  reject_non_fqdn_recipient,
  permit_dnswl_client list.dnswl.org,
  reject_rbl_client ix.dnsbl.manitu.net,
  reject_rbl_client zen.spamhaus.org,
  reject_rbl_client b.barracudacentral.org,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client psbl.surriel.com,
  reject_rbl_client noptr.spamrats.com,
  reject_rbl_client dyna.spamrats.com,
  reject_rbl_client dnsbl.sorbs.net

Die Einstellungen im Detail

smtpd_sender_restrictions

Hier wird Postfix mitgeteilt, welche Checks während des “MAIL FROM” Kommandos auszuführen sind. Alle weiteren Checks werden top-down, also von oben nach unten durchgeführt. Sobald ein Check anschlägt, sei es permit oder reject, wird diese Kette verlassen und keine weiteren Checks werden durchgeführt.

Mittels permit_mynetworks und permit_sasl_authenticated werden Mails von vertrauenswürdigen Netzen und authentifizierten Benutzern in jedem Fall durchgelassen.

Durch die Befehle reject_unknown_sender_domain sowie reject_non_fqdn_sender wird erstmal geprüft, ob der sendende MTA zumindest die RFC Basics eingehalten hat. Also ob hinter der Domain ein DNS A-Record steckt und ob es einen FQDN gibt.

smtpd_recipient_restrictions

Hier passiert die eigentliche “Magie”. Seit Postfix 2.10 und der Einführung der smtpd_relay_restrictions bin auch ich dazu übergegangen, eigentlich alle Checks hier aufzuführen. Genauere Informationen darüber gibt es auf der Postfix Website.

Die Einstellungen permit_mynetworks und permit_sasl_authenticated bewirken das Gleiche wie oben. Danach wird es interessanter. Der Punkt reject_unauth_destination ist vermutlich der wichtigste Befehl. Er legt fest, dass unauthentifizierte Benutzer nur Mails an die eigenen Domains senden dürfen und somit kein Open Relay entsteht.

RFC-Konforme Checks

Mittels check_client_access und check_sender_access könnten Whitelists erstellt werden. Dies kann hin und wieder nützlich sein, z.B. wenn fremde, legitime Mailserver falsch konfiguriert sind.

Die Punkte reject_unknown_helo_hostname und reject_invalid_hostname prüft, ob der Host im HELO einen (gültigen) DNS A oder MX Record hat. Falls nicht, wird die Mail abgelehnt.

Zu guter Letzt wird mittels reject_non_fqdn_hostname und reject_non_fqdn_recipient noch geprüft, ob die Empfängerdomain im FQDN-Format vorliegt. Also wieder ziemliche “Basics”. Trotzdem helfen diese Regeln, schon mal recht viele Mails von schlecht konfigurierten SPAM Mailservern abzulehnen.

Whitelist

Vor den ganzen DNSBLs habe ich einen Check zur bekannten Whitelist dnswl.org eingebaut. Falls eine sendende IP dort gelistet ist, durchläuft sie nicht die weiteren Checks der ganzen Blacklists. Dadurch kann ich etwas restriktivere Blacklists verwenden, ohne gleich Gefahr zu laufen, dass zu viele false-positives auftreten könnten. Hin und wieder sind beispielsweise einzelne IPs von United Internet (GMX und Co.) auf der Sorbs Blacklist gelistet. Da GMX aber in der Whitelist gelistet ist, brauche ich mir darüber keine Gedanken zu machen. Ich kann auch jedem Mailserver-Administrator empfehlen, sich dort auf dieser Whitelist einzutragen.

Postfix kann die DNS Whitelist ab Version 2.8 direkt mit dem Kommando permit_dnswl_client list.dnswl.org abfragen.

Blacklist

Der Befehl reject_rbl_client frägt die jeweilige DNS Blacklist ab und lehnt die Mail ab, wenn eine der Blacklists einen gelisteten Eintrag zurückgibt. Ich habe mich für die oben genannten acht Stück entschieden. Sie existieren allesamt relativ lange und waren bisher sehr zuverlässig. Hier sollte trotzdem regelmäßig ein Review stattfinden, denn manche DNSBLs geben, wenn sie eines Tages out-of-service gehen, immer “listed” zurück. Folglich würden dann alle Mails abgelehnt werden.

Der Beitrag Mit Postfix SPAM blockieren erschien zuerst auf SYN-FLUT.de.

Einleitung

Dieses Modul steht für Apache und Nginx zur Verfügung und wird hauptsächlich von Google entwickelt. Der Quellcode steht auf GitHub zur Verfügung. Mittels verschiedenster Techniken versucht es, die Seiten schneller an die Benutzer auszuliefern.

Funktionsweise

mod_pagespeed klinkt sich in den Apache Webserver ein und wendet sehr viele “Best Practices” auf den HTML Code, CSS, JavaScript und Bilder der auszuliefernden Webseiten an. Dabei werden die einmal erstellten, optimierten Seiten zusätzlich in einem Cache gehalten. Das ist Fluch und Segen zugleich: Änderungen an CSS oder Bildern werden womöglich erst verzögert sichtbar, wenn die Dateinamen gleich bleiben. Abhilfe schafft das Löschen des Caches. Dazu unten mehr.

Zum Beispiel werden Bilder (wo es sinnvoll ist) vor dem Ausliefern in das neue WebP Format konvertiert. Schriften werden z.B. direkt als Base64 Stream ins CSS eingebettet, anstatt sie als separate Datei zu laden, was wieder Zeit kostet. Ebenso werden Stylesheets und JavaScripts minimiert und soweit wie möglich zusammengefasst.

Das sind nur die Dinge, die mod_pagespeed in der Grundinstallation optimiert. Viele weitere Filter können in der Konfiguration aktiviert werden.

Da mein Blog noch keine Woche alt ist, kann ich damit noch ein wenig experimentieren. Die Implementation von mod_pagespeed brachte mir bisher rund 30% Zeitersparnis in der Ladezeit. Als ich den Cache dann komplett in den RAM meines Servers ausgelagert hatte, wurde die Seite nochmal etwas schneller. Bisher habe ich nur die standardmäßig aktivierten Filter in Verwendung. Vielleicht bekomme ich noch etwas mehr Performance raus, wenn ich daran noch etwas drehe. Ich werde den Beitrag dann entsprechend aktualisieren.

Installation unter Ubuntu 14.04

Glücklicherweise gibt es bereits fertige Pakete von Google, die gleichzeitig ein eigenes Repo mit installieren. Mod_Pagespeed wird somit automatisch über den Paketmanager aktuell gehalten.

Ich installiere hier bewusst die Beta-Version, da diese per default auch https-Seiten beschleunigt. In der aktuellen Stable müsste dies noch händisch aktiviert werden. Auf der verlinkten Seite gibt es dazu weitere Infos.

wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_amd64.deb
sudo dpkg -i mod-pagespeed-*.deb
sudo apt-get -f install

Das war’s schon, mod_pagespeed ist installiert und direkt als Apache Modul aktiviert. Nun muss noch der Webserver selbst durchgestartet werden, damit die neue Konfiguration aktiviert wird.

service apache2 restart

Ab sofort sollte mod_pagespeed bereits aktiv sein und eure Webseiten global optimieren. Wer das nicht will, sollte mod_pagespeed in der globalen Konfiguration erstmal deaktivieren und für einzelne Virtual Hosts wieder einschalten.

sudo nano /etc/apache2/mods-enabled/pagespeed.conf
     ModPagespeed off

sudo nano /etc/apache2/sites-enabled/yoursite.conf
     <VirtualHost ...>
     .   .   .
         ModPagespeed on
     </VirtualHost>

mod_pagespeed bringt noch ein kleines Webinterface mit, um Statistiken zu sehen. Standardmäßig ist das nur vom Server selbst zu erreichen. Hier könnte man entweder mit einem SSH-Tunnel arbeiten, oder die Website z.B. nur für die eigene IP freischalten. Um es einfach zu halten, hab ich bei mir erstmal das gemacht.

sudo nano /etc/apache2/mods-enabled/pagespeed.conf
    <Location /pagespeed_admin>
        Order allow,deny
        Allow from localhost
        Allow from 127.0.0.1
        Allow from <deine IP>
        SetHandler pagespeed_admin
    </Location>
    <Location /pagespeed_global_admin>
        Order allow,deny
        Allow from localhost
        Allow from 127.0.0.1
        Allow from <deine IP>
        SetHandler pagespeed_global_admin
    </Location>

Weitere Konfiguration ist erst mal nicht notwendig. Als nächstes könnte man wie oben beschrieben weitere Filter aktivieren.

Test von mod_pagespeed

Ihr braucht nur die optimierte Seite im Browser laden und euch den Quelltext anzeigen lassen. Anschließend mal nach “pagespeed” suchen. Die optimierten Bilder und CSS dürften diesen Namen im Dateinamen tragen.

Idealerweise habt ihr vor dem Aktivieren von mod_pagespeed einen Ladezeitentest, z.B. auf  https://www.pagespeed.de/ gemacht. Anschließend, mit aktiviertem Modul, sieht man recht schön die gewonnene Geschwindigkeit.

Tipps und Tricks

Auslagern des Cache in den RAM

dazu wird einfach eine tmpfs RAMDisk erstellt, die in den entsprechenden Ordner gehängt wird. Ich erkläre es hier wieder am Beispiel Ubuntu 14.04, bei anderen Distributionen ist die Vorgehensweise ähnlich. Bei mir ist sie 256MB groß. Der Speicher wird nur vom RAM allokiert, wenn er auch tatsächlich genutzt wird.

Folgendes wird in die /etc/fstab eingetragen:

tmpfs /var/cache/mod_pagespeed tmpfs size=256m,mode=0775,uid=www-data,gid=www-data 0 0

Anschließend wird die RAMDisk noch gemountet

mount /var/cache/mod_pagespeed

Cache löschen

Wenn ihr etwas am CSS eurer Seite ändert, ist es Sinnvoll, den Cache von mod_pagespeed zu löschen. Dadurch werden die Änderungen gleich sichtbar. Dies geht mit folgendem Befehl: (Wieder für Ubuntu)

touch /var/cache/mod_pagespeed/cache.flush

Ein Neustart von Apache ist nicht notwendig. Nach einem Reload der Website sollten die CSS-Änderungen sichtbar sein.

Der Beitrag mod_pagespeed: Installation und Konfiguration erschien zuerst auf SYN-FLUT.de.

Zusätzliche Signaturen

Die offiziellen Signaturen von ClamAV sind meiner Meinung nach nicht die besten. Auch Wochen nach bekanntwerden von Locky, erkannte ClamAV in meinem Test diesen Virus nicht. Fast wollte ich ClamAV wieder deinstallieren, dann jedoch habe ich nach zusätzlichen Signaturen gesucht. Das Ergebnis kann sich absolut sehen lassen. In meinem Test wurden alle Viren, die vorher durchflutschten, zuverlässig erkannt. Bisher gabs kein False-Positive, aber auch kein False-Negative.

Der große Nachteil an der Sache ist, dass ClamAV mit zusätzlichen Signaturen ein echter Speicherfresser ist. Bei mir verbraucht ClamAV knapp 800MB RAM.

Am einfachsten gelingt die Installation zusätzlicher Signaturen mit dem ClamAV Unofficial Signatures Updater, der auf Github von “extremeshok” weiter entwickelt wird. Die Installation ist dort super beschrieben und in wenigen Minuten erledigt. In der Konfiguration kann man verschiedene Quellen angeben, von welchen die Signaturen bezogen werden. Einige davon funktionieren nur mit vorheriger Registrierung. Ich habe mich mal bei allen angemeldet.

Wenn ich die Installation allerdings nochmal machen würde, würde ich auf diesen Schritt verzichten und nur die Signaturen von SaneSecurity beziehen, welche ohne Anmeldung geladen werden können. Bisher wurden alle gefundene Viren anhand Signaturen von SaneSecurity erkannt. Dadurch kann man sicherlich auch eine Menge RAM sparen.

Von folgenden Quellen ladet das Tool automatisiert die Signaturen runter und hält sie aktuell:

• SaneSecurity (ohne vorherige Anmeldung)
• SecuriteInfo
• Linux Malware Detect
• Malware Patrol

Wie gesagt, die Installation ist auf der Github Page von extremeshok super beschrieben, deswegen verzichte ich an dieser Stelle auf ein HowTo.

PS: ich seh grad, extremeshok hat auch ein SpamAssassin Plugin geschrieben. Vielleicht teste ich das demnächst mal.

Der Beitrag ClamAV Erkennungsrate verbessern erschien zuerst auf SYN-FLUT.de.

Bei mir war der Hauptgrund mein Mailserver. Manche DNSBLs arbeiten nach dem Freemium-Prinzip und lassen nur eine begrenzte Anzahl an Abfragen pro Source-IP durch. Da ich bis vor kurzem noch öffentliche DNS-Server benutzt habe, und letztlich ja diese bei den DNSBLs nachfragen, waren viele SpamAssassin Checks nicht erfolgreich. Nachzulesen hier: SpamAssassin Erkennungsrate (deutlich) verbessern

Ich gehe hier nur auf die Konfiguration des DNS-Resolver ein, sprich es werden nur Domains aufgelöst, nicht aber DNS Records für eigene Domains gehostet. Vielleicht mache ich das in Zukunft mal und berichte.

Update 07.05.2019: Mittlerweile bin ich auf unbound umgestiegen. Dieser funktioniert direkt nach der Installation ohne weiteres Zutun. Unter Ubuntu 16.04 / 18.04 reicht folgendes aus:

 apt install unbound 

Anschließend kann direkt mit Punkt Test des neuen DNS Resolvers dieser Anleitung fortgefahren werden.

Installation von bind9 auf Ubuntu 14.04

Unter Ubuntu 14.04 ist ein eigener DNS-Resolver schnell installiert:

apt-get update
apt-get install bind9 bind9utils bind9-doc

Nach der Installation wird Bind automatisch gestartet, außerdem wird ein Init-Script hinterlegt, sodass er auch nach einem Neustart des Servers automatisch wieder gestartet wird.

Damit Bind als Caching DNS-Resolver arbeitet, muss nur eine Konfigurationsdatei angepasst werden:

sudo nano /etc/bind/named.conf.options

Über den options Block wird folgendes hinzugefügt:

acl goodclients {
localhost;
};

options {
. . .

im options Block wird folgendes ergänzt:

options {
directory "/var/cache/bind";

recursion yes;
allow-query { goodclients; };
. . .

Damit wird Bind so konfiguriert, dass nur Anfragen von localhost erlaubt werden. Außerdem wird die Rekursion aktiviert. Das bedeutet, dass Bind selbst bei den DNS Root-Servern anfrägt und keinen weiteren DNS-Forwarder benutzt.

Falls man den DNS Resolver nicht nur für den eigenen Server nutzen möchte, werden einfach die entsprechend erlaubten IP-Bereiche in die ACL zusätzlich mit eingetragen:

acl goodclients {
localhost;
192.0.2.0/24;
};

Test des neuen DNS Resolvers

Um zu überprüfen, ob alles richtig funktioniert, könnt ihr mittels dig euren DNS Server etwas auflösen lassen:

dig heise.de @127.0.0.1

Achtet auf die Query time im Output des Befehls. Wenn dig erneut aufgerufen wird, sollte diese auf 0ms wandern, da die Domain eurem Nameserver bekannt ist.

Verwenden des eigenen DNS Resolvers

Nun muss euer DNS Server nur noch vom Betriebssystem verwendet werden. Unter Ubuntu 14.04 ist dazu folgendes notwendig:

sudo nano /etc/resolv.conf

In der Datei sucht ihr euch die Zeile, die mit nameserver beginnt. Dort ist die IP des aktuellen DNS Server eingetragen. Diese IP muss durch 127.0.0.1, also die Loopback-IP eures Servers, ersetzt werden. Falls der DNS Resolver für mehrere Computer dient, ist dort natürlich die echte IP des Servers einzutragen.

nameserver 127.0.0.1

Auslesen des Cache von bind9

Falls ihr wissen wollt, welche Daten euer DNS Resolver im Cache hat, geht das wie folgt:

# Der nächste Befehlt schreibt den Cache aus dem RAM nach (bei Ubuntu) /var/cache/bind/named_dump.db
sudo rndc dumpdb
# Jetzt kann die Datei aufgerufen werden
less /var/cache/bind/named_dump.db

Der Beitrag Caching DNS-Resolver mit bind9 erschien zuerst auf SYN-FLUT.de.

Einleitung

SpamAssassin ist ein sehr bekanntes und ausgezeichnetes Programm, das anhand von verschiedensten Tests jeder E-Mail einen “Score” zuweist. Je höher diese Punktzahl ist, desto wahrscheinlicher handelt es sich bei der Mail um SPAM.

Ich habe meine Mailserver alle auf Basis der sehr guten Anleitung von Christoph Haas (workaround.org) konfiguriert. Christoph schreibt diese Tutorials schon sehr lange, ich glaube ich habe um 2006 herum meinen ersten Server danach aufgesetzt.

Im Rahmen des Tutorials wird auch SpamAssassin installiert und aktuell direkt, früher mittels Amavis an Postfix angebunden. Ich bevorzuge nach wie vor die Anbindung über Amavis, da ich gerne auch ClamAV als Virenscanner einsetze. Die Erkennungsrate von ClamAV ist erstmal recht gering, auch hier können wir noch einiges rausholen. Dazu werde ich demnächst noch einen Beitrag schreiben.

Verwendet einen eigenen DNS Resolver

Zu Beginn gleich der vielleicht wichtigste Tipp, wie die SpamAssassin Erkennungsrate deutlich verbessert werden kann. SpamAssassin benutzt für viele dieser Tests sogenannte DNS Blacklists (DNSBL). Diese werden verwendet, um z.B. die IP-Adressen der SMTP Relays abzugleichen, oder auch um in der Mail enthaltene Links zu prüfen. Falls eine Domain in einem solchen Link in einer DNSBL bekannt ist, erhöht SpamAssassin folglich den Score und die Mail kann besser klassifiziert werden. Im umgedrehten Fall wird bei vertrauenswürdigen Links der Score verringert, somit sinkt auch die Chance auf eine fälschlicherweise als Spam markierte Mail.

Viele dieser DNSBLs arbeiten nach dem Freemium Prinzip, d.h. für kleinere Mailserver ist deren Benutzung kostenfrei, bei größeren Mailserver-Installationen verkaufen die Provider dieser Listen entsprechende Zugänge. Da die Listen DNS-Basiert arbeiten, wird also die Quell-IP des anfragenden DNS-Servers getrackt und limitiert.

Wenn euer Mailserver einen bekannten öffentlichen DNS-Server verwendet (z.B. Google DNS), frägt ja letztlich dieser DNS-Server bei der Liste nach. Da diese DNS-Server von vielen tausenden Benutzern verwendet werden, laufen sie schnell in das Rate-Limit der DNSBL-Provider.

Ersichtlich wird es im E-Mail Header, wenn SpamAssassin dort den Check URIBL_BLOCKED listet. Dieser wird mit 0.001 Punkten gewertet und soll nur ein Hinweis auf genau dieses Problem sein.

Abhilfe schafft die Verwendung eines eigenen (Caching) DNS-Resolvers. Dadurch frägt euer eigener DNS-Server bei den DNSBLs an und die Anfrage geht durch. Ich habe hier beschrieben, wie unter Ubuntu 14.04 bind als Caching DNS-Resolver installiert wird: Caching DNS-Resolver mit bind9

Allein diese Maßnahme hat die SpamAssassin Erkennungsrate bei mir deutlich verbessert.

Trainiert die Bayes-Datenbank

Auch mit folgendem Tipp kann die SpamAssassin Erkennungsrate verbessert werden. Das Programm verwendet eine integrierte Bayes-Datenbank, um Textphrasen zu klassifizieren und zu bewerten. Damit das Ganze funktioniert, muss diese Datenbank zunächst trainiert werden. Wichtig ist, dass der richtige Pfad zur Datenbank angegeben wird, sonst landet das ganze im .spamassassin Ordner des jeweiligen Benutzers. Dort schaut SpamAssassin (meines Wissens) allerdings nicht nach, wenn es über Amavis oder den spamd aufgerufen wird.

Spam Mail Quelle

Für das “Training” sind eine Menge Mails notwendig. Um genug Spam Mails zu bekommen, habe ich das aktuellste Monatsarchiv von http://untroubled.org/spam/ verwendet. Dieses habe ich mittels wget heruntergeladen, entpackt und anschließend das Tool sa-learn auf die Mails losgelassen. Falls SpamAssassin nicht über Amavis eingebunden ist, muss der Datenbank-Pfad angepasst werden.

Anschließend verfüttere ich auch noch alle Mails im “Junk” Ordner aller Postfächer an sa-learn

cd /tmp
wget http://untroubled.org/spam/2016-03.7z
7z x 2016-03.7z
sudo sa-learn --dbpath /var/lib/amavis/.spamassassin --progress --spam /tmp/2016/03
sudo sa-learn --dbpath /var/lib/amavis/.spamassassin --progress --spam /var/vmail/*/*/Maildir/.Junk

“Gute” Mails

Die Bayes-Datenbank sollte natürlich auch erwünschte Mails zu Gesicht bekommen. Hierzu verwende ich einfach alle gelesene Mails, die in allen vorhandenen Postfächern vorhanden sind.

sa-learn --dbpath /var/lib/amavis/.spamassassin --progress --ham /var/vmail/*/*/Maildir/cur

Dies kann (und sollte) man selbstverständlich via Cron-Job automatisieren.

Verwendet zusätzliche Signaturen

Peer Heinlein von Heinlein Support ist der Mann hinter mailbox.org – einem sicherlich nicht ganz unbekannten E-Mail Anbieter. Freundlicherweise stellt er kostenlos die von seinem Team entwickelten und beinahe täglich aktualisierten SpamAssassin Rulesets zur Verfügung. Eine Anleitung zum Einbinden in ein Debian/Ubuntu System findet ihr auf seinem Blog.

Im Wesentlichen werden diese Signaturen mittels dem bereits vorhandenen Cron-Job, der die SpamAssassin-eigenen Rulesets aktualisiert, zusätzlich geladen. Der Vollständigkeit halber anbei die modifizierte Version des Cron Bash-Scripts, unter Ubuntu 14.04 muss sie nach /etc/cron.daily/spamassassin. Die modifizierten Zeilen habe ich markiert. Neben dem eigentlichen Download prüft mein Script noch die Returncodes von beiden sa-update aufrufen. Wenn nur einer von beiden Aufrufen neue Signaturen gebracht hat, wird spamd bzw. Amavis neu gestartet. Ich habe diesen Code-Schnipsel (Zeile 70-76) aus den Kommentaren von o.g. Blog. Ist ziemlich quick’n’dirty, aber funktioniert für meine Ansprüche.

#!/bin/sh

# Duncan Findlay
# duncf@debian.org

# Daily cronjob for SpamAssassin updates. This isn't pretty but it
# should do the job.

CRON=0

test -f /etc/default/spamassassin && . /etc/default/spamassassin

test -x /usr/bin/sa-update || exit 0
test -x /etc/init.d/spamassassin || exit 0

if [ "$CRON" = "0" ] ; then
exit 0
fi

# If there's a problem with the ruleset or configs, print the output
# of spamassassin --lint (which will typically get emailed to root)
# and abort.
die_with_lint() {
su - debian-spamd -c "spamassassin --lint -D 2>&1"
exit 1
}

do_compile() {
# Compile rules if the required tools are available. Prior to version
# 3.3.2-8, there was an additional check to verify that an sa-compile
# run had previously been executed by hand. With sa-learn now
# distributed in a separate, optional, package, this check is no
# longer necessary.
if [ -x /usr/bin/re2c -a -x /usr/bin/sa-compile ]; then
su - debian-spamd -c "sa-compile --quiet"
# Fixup perms -- group and other should be able to
# read and execute, but never write. Works around
# sa-compile's failure to obey umask.
chmod -R go-w,go+rX /var/lib/spamassassin/compiled
fi
}

# Tell a running spamd to reload its configs and rules.
reload() {
# Reload
if which invoke-rc.d >/dev/null 2>&1; then
invoke-rc.d spamassassin reload > /dev/null
else
/etc/init.d/spamassassin reload > /dev/null
fi
if [ -d /etc/spamassassin/sa-update-hooks.d ]; then
run-parts --lsbsysinit /etc/spamassassin/sa-update-hooks.d
fi
}

# Sleep for up to 3600 seconds
RANGE=3600
number=`od -vAn -N2 -tu4 < /dev/urandom`
number=`expr $number "%" $RANGE`
sleep $number

# Update
umask 022
su - debian-spamd -c "sa-update --gpghomedir /var/lib/spamassassin/sa-update-keys"
retcode1=$?
su - debian-spamd -c "sa-update --nogpg --channel spamassassin.heinlein-support.de"
retcode2=$?

if [ $retcode1 -eq 0 ] || [ $retcode2 -eq 0 ]; then
retcode=0
elif [ $retcode1 -eq 2 ] || [ $retcode2 -eq 2 ]; then
retcode=2
else
retcode=$retcode2
fi

case $retcode in
0)
# got updates!
su - debian-spamd -c "spamassassin --lint" || die_with_lint
do_compile
reload
;;
1)
# no updates
exit 0
;;
2)
# lint failed!
die_with_lint
;;
*)
echo "sa-update failed for unknown reasons" 1>&2
;;
esac

Wenn alles funktioniert hat, müssten unter /var/lib/spamassassin/<version>/ einige Dateien mit “heinlein” im Namen liegen. Das sind die eigentlichen Rulesets. Anhand des Zeitstempels kann auch überprüft werden, wann das letzte Update kam.

Verwendet Pyzor und Razor

Pyzor und Razor sind Prüfsummenbasierte Netzwerke, um SPAM zu erkennen. Dabei wird eine Prüfsumme vom Body der erhaltenen Mail gebildet und an die Pyzor oder Razor Server gesendet. Falls die Prüfsummen von vielen Benutzern identisch sind (d.h. der Mailtext ist gleich), ist die Wahrscheinlichkeit, dass es sich bei der Mail um SPAM handelt höher.

Pyzor

Achtung: Pyzor verwendet den Port TCP 24441 für ausgehende Verbindungen zum Pyzor Server. Falls eine Firewall ausgehende Verbindungen blockiert, muss dieser Port entsprechend freigeschaltet werden. Folgende Schritte sind notwendig, um Pyzor unter Ubuntu 14.04 einzubinden:

sudo apt-get install pyzor
pyzor --homedir /etc/mail/spamassassin discover

Nun muss das noch SpamAssassin mitgeteilt werden. Dazu muss die Datei /etc/spamassassin/local.cf wie folgt editiert werden:

# die nächste Zeile dürfte schon auf 1 stehen. Falls nicht, dann anpassen.
use_pyzor               1
# die nächste Zeile kommt ans Ende der Datei
pyzor_options --homedir /etc/mail/spamassassin

Danach noch SpamAssassin oder Amavis neu starten, dann war’s das schon. Getestet werden kann es wie folgt:

cat /pfad/zu/ner/mail | spamassassin -D pyzor 2>&1 | less

Der Output sollte wie folgt aussehen:

Apr 1 14:40:43.038 [17306] dbg: pyzor: network tests on, attempting Pyzor
Apr 1 14:40:46.625 [17306] dbg: pyzor: pyzor is available: /usr/bin/pyzor
Apr 1 14:40:46.626 [17306] dbg: pyzor: opening pipe: /usr/bin/pyzor check < /tmp/.spamassassin17306kiOe9Ytmp
Apr 1 14:40:47.528 [17306] dbg: pyzor: [17308] finished: exit 1
Apr 1 14:40:47.528 [17306] dbg: pyzor: got response: public.pyzor.org:24441 (200, 'OK') 0 0

Razor

So wird Razor unter Ubuntu 14.04 installiert und konfiguriert:

sudo apt-get install razor
sudo razor-admin -home=/etc/spamassassin/.razor -register
sudo razor-admin -home=/etc/spamassassin/.razor -create
sudo razor-admin -home=/etc/spamassassin/.razor -discover

entsprechend muss analog zu Pyzor wieder die Datei /etc/spamassassin/local.cf angepasst werden:

# die nächste Zeile dürfte schon auf 1 stehen. Falls nicht, dann anpassen.
use_razor               1
# die nächste Zeile kommt ans Ende der Datei
razor_config /etc/mail/spamassassin/.razor/razor-agent.conf

Hier wüsste ich leider keinen Weg, wie man die Funktion von Razor direkt testen kann. Jedenfalls müsste ab jetzt der SpamAssassin Test RAZOR2_CHECK in Mails auftauchen. Überprüft werden kann das (nach ein paar Tagen) wie folgt:

grep -R RAZOR /pfad/zu/den/mails

Filtert nach Ländern

SpamAssassin bringt ein Plugin namens RelayCountry mit, mit welchem es möglich wird, die Länder der einzelnen SMTP Relays anhand der GeoIP Information zu bestimmen. Dies dient zum einen der Bayes-Datenbank. Sie bekommt also zusätzliche Informationen und wird künftig selbständig lernen, aus welchen Ländern viel Spam kommt. Ich habe bei mir noch “händische” Regeln hinzugefügt: Wenn eine Mail z.B. durch einen SMTP-Server in Vietnam relayed wurde, bekommt sie in meinem Fall zwei Punkte. Dieser Schritt hat auch nochmal gut geholfen, die SpamAssassin Erkennungsrate zu verbessern.

Folgende Schritte sind unter Ubuntu 14.04 als Vorbereitung notwendig:

apt-get install libgeo-ip-perl
mkdir /usr/share/GeoIP
wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz
wget http://geolite.maxmind.com/download/geoip/database/GeoIPv6.dat.gz
gunzip GeoIP.dat.gz
gunzip GeoIPv6.dat.gz
mv GeoIP.dat /usr/share/GeoIP/
mv GeoIPv6.dat /usr/share/GeoIP/

Damit wurde das notwendige Perl-Modul installiert, sowie mit der aktuellen GeoIP-Lite Datenbank von MaxMind ausgestattet. Das Plugin wird in der Datei /etc/spamassassin/init.pre aktiviert, dazu wird das Kommentarzeichen vor folgender Zeile entfernt:

loadplugin Mail::SpamAssassin::Plugin::RelayCountry

Jetzt können noch eigene Regeln geschrieben werden, um Mails aus bestimmten Ländern abzuwerten. Dazu muss ans Ende von /etc/spamassassin/local.cf folgendes:

ifplugin Mail::SpamAssassin::Plugin::RelayCountry
add_header all Relay-Country _RELAYCOUNTRY_
header RELAYCOUNTRY_BAD X-Relay-Countries =~ /(CN|RU|UA|RO|VN)/
describe RELAYCOUNTRY_BAD Relayed through spammy country at some point
score RELAYCOUNTRY_BAD 2.0

header RELAYCOUNTRY_GOOD X-Relay-Countries =~ /^(DE|AT|CH)/
describe RELAYCOUNTRY_GOOD First untrusted GW is DE, AT or CH
score RELAYCOUNTRY_GOOD -0.5
endif # Mail::SpamAssassin::Plugin::RelayCountry

Damit bekommt jede Mail, die durch ein SMTP-Relay in China, Russland, Ukraine, Rumänien oder Vietnam geroutet wurde, automatisch zwei Punkte. Im Gegenzug ziehe ich 0,5 Punkte ab, wenn das letzte Relay in Deutschland, Österreich oder der Schweiz stand.

Damit lässt sich das Ganze auch gut testen. Nach einem Neustart von SpamAssassin oder Amavis sollte bei jeder Mail, die aus Deutschland eintrudelt, folgender Check im Header stehen:

Im Gegenzug bei Mails aus den o.g. Ländern:

Verwendet zusätzliche Plugins

Ich habe kürzlich ein gutes SpamAssassin Plugin von eXtremeSHOK gefunden, welches die “From” und “Reply-To” Header vergleicht. Gibt es dort Unterschiede, bekommt die Mail direkt ein paar Punkte. Je nachdem, ob sich auch die Domain unterscheidet, sind es zwei bzw. direkt fünf Punkte. Bei meinem Test ist mir oft aufgefallen, dass bei Spam-Mails hier unterschiedliche Domains verwendet werden. Diesen Tipp habe ich persönlich erst zum Schluss entdeckt und eingebaut. Seitdem kam überhaupt kein SPAM mehr durch.

Die Installation ist unter Ubuntu 14.04 sehr einfach:

cd /tmp
wget https://github.com/extremeshok/spamassassin-extremeshok_fromreplyto/archive/1.3.1.tar.gz
tar -zxvf 1.3.1.tar.gz
mkdir /etc/mail/spamassassin/plugins/
cp plugins/* /etc/mail/spamassassin/plugins/
cp 01_extremeshok_fromreplyto.cf /etc/mail/spamassassin

Das war’s schon, anschließend muss noch Amavis oder der spamd neu gestartet werden. Getestet werden kann das Plugin, indem man sich selbst eine Mail schickt. Anschließend sollte der Check FROM_IS_TO im Mailheader auftauchen.

Modifiziert die Punktevergabe

Noch ein Kurztipp am Ende. Dieser Tipp ist relativ “advanced”, da man genau wissen sollte, was man verändert.

Mittels der Datei /etc/spamassassin/local.cf können die Standardwerte der Punktevergabe für Checks verändert werden. Ich habe bei mir die vergebenen Punkte erhöht, wenn eine Domain oder ein Link in einer DNSBL auftaucht:

score RCVD_IN_BL_SPAMCOP_NET 0 5.246 0 5.347
score RCVD_IN_BRBL_LASTEXT 0 5.246 0 5.347
score URIBL_BLACK 0 5.7 0 5.7
score URIBL_WS_SURBL 0 2.659 0 2.608
score URIBL_MW_SURBL 0 2.263 0 2.263
score URIBL_CR_SURBL 0 2.263 0 2.263
score URIBL_GREY 0 2.084 0 1.424
score URIBL_DBL_SPAM    0 4.5 0 4.5
score URIBL_DBL_PHISH   0 4.5 0 4.5
score URIBL_DBL_MALWARE 0 4.5 0 4.5
score URIBL_DBL_BOTNETCC 0 4.5 0 4.5
score URIBL_DBL_ABUSE_SPAM 0 4.0 0 4.0
score URIBL_DBL_ABUSE_PHISH 0 4.5 0 4.5
score URIBL_DBL_ABUSE_MALW  0 4.5 0 4.5
score URIBL_DBL_ABUSE_BOTCC 0 4.5 0 4.5

Der Beitrag SpamAssassin Erkennungsrate (deutlich) verbessern erschien zuerst auf SYN-FLUT.de.