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.

Interessanter Traffic

zunächst wird eine Access-Liste erstellt, die den aufzuzeichnenden Traffic beschreibt. Wichtig ist, dass der Hin- und Rückweg beschrieben wird. In meinem Beispiel will ich sämtlichen Traffic aufzeichnen, der vom oder zum Host mit der IP 192.168.10.22 geht.
Die Nummer der Access-Liste sollte natürlich in eurer Konfiguration noch unbenutzt sein.

conf t
access-list 144 permit ip host 192.168.10.22 any
access-list 144 permit ip any host 192.168.10.22
exit

Erstellen eines Capture Buffer

Nun wird ein Capture Buffer erstellt, der unsere mitgeschnittenen Pakete speichern wird. Im Beispiel heißt er C-BUFFER. Der Name spielt jedoch keine Rolle. Anschließend wird er mit der oben erstellten Access-Liste verknüpft. Im Beispiel werden maximal 2 MB Daten im Buffer gehalten. Aktuelle Router können bis zu 10MB speichern. Mittels dem Kommando max-size wird die Paketgröße festgelegt. Das linear steht für einen linearen Buffer. Mittels circular könnte man den Buffer auch überschreiben, wenn er voll läuft.

monitor capture buffer C-BUFFER size 2048 max-size 1518 linear
monitor capture buffer C-BUFFER filter access-list 144

Erstellen eines Capture Point

Nun muss noch ein Capture Point erstellt und mit dem oben erstellten Buffer verknüpft werden. Wir wollen den Traffic in beiden Richtungen mitschneiden, deswegen das Keyword both. Hier gibt es noch einen kleinen Fallstrick: Beim Erstellen des Capture Points muss zwischen cef (Cisco Express Forwarding) und process-switched Paketen unterschieden werden. Jedes Paket, das den Router durchläuft und nicht fragmentiert wird, wird heutzutage normalerweise mittels cef geroutet. Dazu solltet ihr bereits das Kommando “ip cef” in eurer Konfiguration haben. Process-switched sind nur noch die Pakete, die direkt an den Router gesendet werden. Im Zweifel einfach ausprobieren, das Kommando für process-switched habe ich auskommentiert drin.

monitor capture point ip cef C-POINT all both
!monitor capture point ip process-switched C-POINT both
monitor capture point associate C-POINT C-BUFFER

Starten des Captures

mittels nachfolgendem Kommando wird der Traffic Capture gestartet. Anschließend kann der aufzunehmende Traffic produziert werden.

monitor capture point start C-POINT

Stoppen des Captures

Wenn der Traffic “im Kasten” ist, muss der Capture wieder gestoppt werden. Anschließend werden die Daten im pcap Format via tftp exportiert, sodass sie zur Analyse mit z.B. Wireshark geöffnet werden können.

monitor capture point stop C-POINT
monitor capture buffer C-BUFFER export tftp://1.2.3.4/filename.pcap

Aufräumen

Der Traffic ist im Kasten und exportiert. Zeit, die Konfiguration wieder aufzuräumen:

!no monitor capture point ip process-switched C-POINT both
no monitor capture point ip cef C-POINT all both
no monitor capture buffer C-BUFFER
conf t
no access-list 144
exit

Die gesamte Konfiguration

Für alle, die das Prinzip schon kennen und nur “schnell” die Kommandos brauchen:

conf t
access-list 144 permit ip host 192.168.10.22 any
access-list 144 permit ip any host 192.168.10.22
exit
monitor capture buffer C-BUFFER size 2048 max-size 1518 linear
monitor capture buffer C-BUFFER filter access-list 144
monitor capture point ip cef C-POINT all both
!monitor capture point ip process-switched C-POINT both
monitor capture point associate C-POINT C-BUFFER
monitor capture point start C-POINT
!---
! Traffic produzieren
!---
monitor capture point stop C-POINT
monitor capture buffer C-BUFFER export tftp://1.2.3.4/filename.pcap
!----
!no monitor capture point ip process-switched C-POINT both
no monitor capture point ip cef C-POINT all both
no monitor capture buffer C-BUFFER
conf t
no access-list 144
exit

Der Beitrag Cisco IOS Netzwerkverkehr mitschneiden erschien zuerst auf SYN-FLUT.de.