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.

Einfache Variante mit tail -f und grep

Zunächst verwendete ich schlicht und einfach tail -f und grep. Das tail zeigt die letzen paar Zeilen einer Datei, die Option -f weist an, die Datei fortlaufend zu monitoren und Änderungen in Echtzeit anzuzeigen. Damit mir auch die nicht-matchenden Zeilen angezeigt werden, verwende ich einfache regular expressions.

tail -f /var/log/mail.log | egrep "CLEAN|removed|$"

| steht hier für “oder”, das $ steht für Zeilenende, also jede Zeile. Dadurch zeigt grep auch die nicht-matchenden Zeilen (unfarbig) an.

Falls die Farben nicht sichtbar sein sollten, fehlt vermutlich der entsprechende Alias in der .bashrc:

alias egrep='egrep --color=auto'

PS: wenn color=auto in color=always verändert wird, bleiben die Farben auch dann erhalten, wenn die Ausgabe von grep in eine Pipe geschickt wird, z.B. so:

tail -f /var/log/mail.log | egrep --color=always "CONNECT|$" | egrep --color=always "Disconnected|$"

Leider kommt man hier schnell an die Grenze, da grep meines Wissens nach nur eine Farbe unterstützt. Außerdem sind die Kommandos etwas mühselig.

Mehr Farben und Funktionen mit multitail

multitail sollte meiner Meinung nach auf keinem Linux-Server fehlen. In erster Linie soll es das bekannte tail um viele Funktionen ergänzen. Es basiert auf ncurses und kann mehrere Dateien gleichzeitig überwachen und Keywords farbig darstellen. Die Installation ist auf einem Debian / Ubuntu Server denkbar einfach:

apt-get update
apt-get install multitail

ein Aufruf sieht zum Beispiel so aus:

multitail /pfad/zur/datei1 /pfad/zur/datei2

Man sieht, es können mehrere Dateien angegeben werden, die zur gleichen Zeit überwacht werden. Das schönste daran sind allerdings die verschiedenen Farben, welche zentral über die Datei /etc/multitail.conf konfiguriert werden. Dort können mittels Regular Expressions auch eigene Regeln definiert werden.

Speziell um die Logdatei meines Mailservers zu überwachen, habe ich den Bereich für postfix wie folgt editiert und um Einträge für dovecot und amavis ergänzt:

colorscheme:postfix:www.postfix.org
cs_re:cyan::
cs_re:yellow:status=sent
cs_re:magenta:queue.active
cs_re:green:from=.*>
cs_re:red:to=.*>
cs_re:blue|blue,,bold:^... .. ..:..:..
cs_re:green:\[
cs_re:green:\]
cs_re:red:NOQUEUE:.*
cs_re:green:<[a-zA-Z0-9_\@\.\-]+> -> <[a-zA-Z0-9_\@\.\-]+>
cs_re:red:INFECTED
cs_re:green:CLEAN
cs_re:yellow:BAD_HEADER
cs_re:cyan:dovecot:.*
cs_re:magenta:Hits: [-0-9\.]+
cs_re:blue,,bold:amavis.*

Damit dieses Farbschema auch verwendet wird, rufe ich multitail wie folgt auf:

multitail -cS postfix -n 1000  /var/log/mail.log

Mittels -cS wird das Farbschema angegeben, das -n 1000 bedeutet, dass die letzten 1000 Einträge in den Puffer geladen werden. Dies ist für das Zurückblättern nützlich. Zu guter letzt gebe ich den Pfad zur überwachenden Datei an. Das Ergebnis sieht super aus, wie ich finde. Alle relevanten Ereignisse stechen hervor:

Damit ich nicht jedes Mal das lange Kommando eingeben muss, habe ich mir folgenden Alias in die .bashrc eingetragen:

alias mlg='multitail -cS postfix -n 1000 /var/log/mail.log'

Somit reicht ein einfaches mlg auf der Konsole aus.

Zurückblättern

Während Multitail läuft, kann mit der Taste B in der Datei zurückgeblättert werden. Mit der Taste E kann gefiltert werden, und mit / kann man nach Keywords suchen. Damit macht meiner Meinung nach das Logdateien monitoren Spaß.

Der Beitrag Logdateien monitoren – mit multitail erschien zuerst auf SYN-FLUT.de.