Die Bürger von Karlsruhe wissen noch nicht, ob sie sich über dieses ungewöhnliche Phänomen freuen sollen (Touristenattraktion?) oder ärgern sollen (gefährlich!). In den Geschäften von Karlsruhe werden jedoch bereits deutliche Warnungen vor dem Rattenregen aufgehängt — so gesehen im Schaufenster eines E-Plus-Shops (pardon…: shop’s!) in der Karlsruher Innenstadt.

Ungeklärt jedoch ist noch, ob die Ratten bereits flach waren, als sie regneten, oder ob sie erst durch den unsanften Aufprall auf dem Karlsruher Kopfsteinpflaster flach wurden.

Dämonisierte Engines müssen sein

Das A und O eines performanten Anti-Viren-Filters auf einem Mailserver ist die Notwendigkeit, unbedingt einen dämonisierten Virenkiller einzusetzen. Leider bieten viele Hersteller jedoch keine eigenständig als Dämon laufenden Viren-Engines mehr an und möchten stattdessen gleich vollständige Komplettlösungen beim Kunden platzieren.

Unserer Ansicht nach kommen für eine enrsthafte Betrachung derzeit lediglich folgende Anbieter/Lösungen in Betracht:

• ClamAV
• Sophos
• Avira
• Kaspersky

Wobei Kaspersky anscheinend vom BSI eher ungerne für Behörden gesehen wird — Russland gehört nicht zur NATO und damit ist der Scanner wohl für die Verarbeitung von Dokumenten entsprechender Geheimhaltungsstufen nicht zugelassen.

Das SSSP-Protokoll ermöglicht den direkten Zugriff auf die Engine

Sophos bietet dankenswerterweise eine eigene Scan-Engine mit dokumentiertem Protokoll an: Über das SSSP-Protocol kann eine Drittsoftware die Scan-Engine performant und ohne Umwege über Hilfsprogramme ansprechen.

Für einen großen öffentlich-rechtlichen Kunden haben wir im Jahr 2009 zusammen mit Amavis-Autor Mark Martinec eine SSSP-Schnittstelle in Amavis gebracht. Seitdem kann Amavis mit der Scan-Engine von Sophos nativ und ohne Umwege über einen Unix-Socket oder einen TCP-Socket reden — genau wie Amavis das seit langem mit ClamAV bereits kann. Das macht den Einsatz von Sophos unter Amavis außerordentlich interessant — bei unseren Testaufbauten kamen wir damals auf phänomenale Durchsatzraten von 100 Mails pro Sekunde auf recht normaler Hardware.

Das Howto zu Installation

Ab Amavis 2.7.x ist die SSSP-Schnittstelle in Amavis enthalten.

Bei Sophos übernimmt die SSSP-Kommunikation der Dämon savdid — der ist nicht frei verfügbar, sondern nur für Systemintegratoren zu bekommen. im Normalen Download-Bereich wird man die notwendige Software (leider!) nicht finden können.

Notwendig sind die Pakete:

• Viren-Engine: linux.intel.libc6.tar.z (32 Bit), linux.amd64.glibc.2.3.tar.z (64 Bit)
• savdid: savdi-20-linux.tgz (32 Bit), savdi-20-linux-64bit.tgz (64 Bit)

Heinlein Support kann die Installationspakete dafür zur Verfügung stellen (=> Mail an support@heinlein-support.de). Und da wir aus den überzeugenden technischen Gründen bei vielen Kunden mittlerweile Sophos einsetzen, besorgen wir auf Wunsch die dafür passenden Lizenzen dazu…

Zunächst muß die eigentliche Viren-Engine installiert werden: tgz auspacken und Install-Script aufrufen. Anschließend finden sich unter /usr/local/sav die aktuellen Signature-Files und unter /usr/local/lib liegen die Dateien der libsavi.

Nun kann das Archiv vom savdid ausgepackt und das dortige Install-Script aufgerufen werden. Wenn das install_savdid.sh mit Verweis auf eine fehlende libsavi abbricht, so liegt das i.d.R. daran, daß unter 64 Bit eine 32-Bit-Version installiert worden ist (oder umgekehrt).

Am Ende muß nur noch der savdid-Dämon gestartet werden: Dessen Konfigurationsdatei liegt unter /usr/local/savdid/savdid.conf.  Dort kann einerseits eine unprivilegierte User-ID eingerichtet werden…

# User name and group for daemon to switch to for normal running
# savdi must be running as root for this to be useful
user: vscan
group: vscan

…andererseits muß dort noch ein spezielles Kommando freigeschaltet werden, mit dem Amavis Subdirectorys scannen lassen darf. Diese folgende Einstellung muß für den savdid vorgenommen werden:

    scanprotocol {
        type: SSSP

        # Do we allow the client to use SCANFILE?
        allowscanfile: SUBDIR

In der Amavis-Konfiguration sollte der Zugriff auf den savdid per TCP- statt per Unix-Socket vorgenommen werden, um Probleme mit Zugriffsrechten oder in chroot-Umgebungen zu vermeiden:

# ### http://www.sophos.com/
 ['Sophos-SSSP',
   \&ask_daemon, ["{}", 'sssp:[127.0.0.1]:4010'],
   qr/^DONE OK\b/m, qr/^VIRUS\b/m, qr/^VIRUS\s*(\S*)/m ],

Nach dem Start vermeldet Amavis bei log_level=3 auch den Fund des savdid auf Port 4010:

Jan  6 16:55:31 booster amavis[3629]: Using primary internal av scanner code for Sophos-SSSP

Und eine Test-Mail sollte problemlos versandt und gescannt werden.

Leider stellt Sophis hier keinen Client zur Verfügung, um Sigantur-Files zu aktualisieren . Diese müssen regelmäßig von http://www.sophos.com/downloads/ide/ geladen werden und damit der Inhalt von /usr/local/sav ersetzt werden. Ein laufender savdid muß reloaded werden (“kill -HUP” läßt grüßen).

Im Logfile finden sich dann genau ein Eintrag in den policyd-weight-Ergebnissen:

Sep 20 22:13:19 mail postfix/policyd-weight[1664]: weighted check:
NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5
IN_IPv6_RBL=4.25 CL_IP_EQ_HELO_IP=-2

Abhilfe schafft ein Update des policd-weight auf die aktuelle Version, wo diese IPv6-RBL nicht mehr per Default enthalten ist (http://www.policyd-weight.org).

Alternativ kann man die betroffene RBL aus seiner Config auch entfernen:

## DNSBL settings
my @dnsbl_score = (
#    HOST,                    HIT SCORE,  MISS SCORE,  LOG NAME
    'pbl.spamhaus.org',       3.25,          0,        'DYN_PBL_SPAMHAUS',
    'sbl-xbl.spamhaus.org',   4.35,       -1.5,        'SBL_XBL_SPAMHAUS',
    'bl.spamcop.net',         3.75,       -1.5,        'SPAMCOP',
    'dnsbl.njabl.org',        4.25,       -1.5,        'BL_NJABL',
    'ix.dnsbl.manitu.net',    4.35,          0,        'IX_MANITU'
 #'rbl.ipv6-world.net',     4.25,          0,        'IPv6_RBL'
#don't use, kept for testing failures!
);

Sollte ein großer Provider einmal auf einer RBL-Sperrliste stehen, so klären sich diese Dinge meistens binnen weniger Stunden und der Spuk ist vorbei. Nicht selten hat sich der jeweilige Provider tatsächlich etwas zuschulden kommen kassen und steht auch nicht zu unrecht auf den RBLs, weswegen erfahrene Postmaster häufig auch nicht gewillt sind, andere Provider zu whitelisten; sollen diese doch lieber ihre eigenen internen Probleme lösen.

Seit einer knappen Woche jedoch geistert T-Online wieder und wieder durch die Sperrlisten — und erstaunlicherweise dabei gleich auf mehreren Listen zeitgleich, nämlich den RBLs von Spamcop und Spamhaus.

Was anfangs noch nach einem kurzen Intermezzo aussah, das sich nach wenigen Stunden als Problem in Luft auflöst, schlägt mitterweile größere Wellen, schließlich geht dauert Blacklisting von T-Online schon mehrere Tagen an.

Die Leidtragen sind — wie so häufig — die anderen Provider, schließlich häufen sich dort Vorwürfe und Anfragen, warum man Mails von T-Online denn nicht mehr annehme. Dabei wird völlig ausgeblendet, daß es ganz im Gegenteil eigentlich Aufgabe von T-Online ist, seine Relays und Listings sauber zu halten und daß anscheinend T-Online es versäumt, hier seine eigenen Kunden über die derzeitige Lage aufzuklären. Eigentlich dürften sich sämtliche Beschwerden und Supportanfragen zu diesem Thema ausschließlich an T-Online richten…

Soll man T-Online also whitelisten?

Schwer zu sagen, kommt ganz drauf an.

• Wer die “harte Linie” fährt, dem ist total egal, ob T-Online ein großer oder ein kleiner Provider ist. Wer keine sauberen Relays hat, der darf nicht mitspielen und nicht versenden — und für große ISPs gibt’s keinen Bonus und keine Sonderregeln. Hier heißt die Entscheidung also: Weitermachen wie bisher und bei allen Kundenanfragen an den T-Online-Support verweisen. Die Vertreter der “harten Linue” können dabei zurecht darauf verweisen, daß Regeln nunmal für alle gelten und daß es auch wichtig ist, klare Regeln und eine strikte Filter-Politik zu betreiben, will man gut und zuverlässig Spam filtern.

Dazu muß man wissen, daß es sich beim T-Online-Blacklisting nicht etwa um einen Fehlalarm handelt, sondern daß in den letzten Wochen tatsächlich dermaßen viel Spam über gehackte T-Online-Accounts geschickt wurden, daß das Blacklisting berechtigt ist. Die Vertreter der “harten Linie” nehmen die geblocken T-Online-Mails also auch darum in Kauf, damit der Druck auf T-Online aufrecht erhalten wird, damit sich endlich etwas ändert.

• Die “Pragmatiker” haben sich hingegen die letzten Tage von dem Problem weichkochen lassen. Auch sie lehnen es eigentlich ab, andere Provider wegen deren persönlichen Problemen zu whitelisten. Andererseits ist offensichtlich, daß das T-Online-Problem weiter andauert und sich berechtigte oder unberechtigte Beschwerden über unzustellbare T-Online-Mails häufen.

Wer will kann also überlegen, ob er die Mailrelays von T-Online zumindest temporär für die nächsten Tage doch whitelisted und sie so von einer RBL-Spamprüfung ausnimmt.

Allerdings muß man sich dann auch klarmachen, daß man einen Teil des eigenen Spamschutzes opfert, sich selbst schlechter schützt und mehr Spam bekommt, nur weil T-Online seine Server und Kunden nicht im Griff hat.

Welcher Politik man hier folgen will, muß jeder mit sich selber ausmachen, ein klares “richtig” und “falsch gibt es hier nicht. Eine gute Variante dürfte es sein, angesichts der massiven aktuellen Probleme T-Online zu whitelisten — aber klar beschränkt auf einen Zeitraum von zwei Wochen. So erhält T-Online Zeit seine Gegenmaßnahmen zu ergreifen, gleichzeitig ist klar, daß die pure Größe des Unternehmens keineswegs einen Persilschein für Narrenfreiheit verschafft. Wenn anschließend T-Online immernoch (zu recht) auf den Blacklisten steht, dann müssen die T-Online-Kunden das mit ihrem eigenen Provider ausdiskutieren — andererseits dürfte sich bis dahin das Problem auch besser bei T-Online-Kunden rumgesprochen haben, so daß Kunden-Beschwerden nicht mehr so massiv bei unbeteiligten Dritten abgekippt werden.

In Postfix läßt sich ein T-Online-Whitelisting recht einfach erledigen: Hier stehen in der main.cf in den rstrictions (i.d.R. smtpd_recipient_restrictions, manchmal auch smtpd_client_restrictions) die Aufrufe der Spamcop- oder Spamhaus-RBL. Wer jetzt vor diesen “reject_rbl_client”-Einträgen ein “check_client_access” einbaut, kann die betroffenen T-Online-IPs leicht whitelisten.

smtpd_(client|recipient)_restrictions =
  [...]
  check_client_access cidr:/etc/postfix/access-client,
  reject_client_rbl bl.spamcop.net,
  reject_client_rbl zen.spamhaus.org,
  [...]

Und in der Datei access_client kann dann das ganze T-Online-Subnetz der Mailrelays gewhitelistet werden:

194.25.134.0/24    permit_auth_destination

Probleme mit Mailservern? Unser Team hilft im CompetenceCall gerne weiter.

Hintergrund: Das Paket dovecot-core ersetzt nun dovecot-common. Dieser Umstand kann beim Update zu Abhängigkeitsproblemen führen, die die Dovecot-Installation unbrauchbar machen, da benötigte Bibliotheken nicht mehr gefunden werden können.

Abhilfe:Dovecot komplett deinstallieren und neu einspielen

Sollte es beim Update bereits zu solchen Problemen gekommen sein, hilft daher ein

aptitude purge $(aptitude search dovecot | awk {'print $2'})

und die erneute Installation von Dovecot.

Achtung: Dabei können unter Umständen auch Config-Dateien in /etc/dovecot gelöscht werden! Also vorher sichern!

Wer noch nicht aktualisiert hat, sollte das Update gleich auf diesem Wege vornehmen.

Zwar lassen sich alternativ alte Kommandos auch mit CTRL-R durchsuchen, doch das ist nicht das gleiche. Ich persönlich mag diesen Mechanismus nicht: Zum einen sind mehr Tastendrücke notwendig und das anschließende durchblättern bei mehreren Suchergebnissen ist schwieriger. Kurzum: Das ist mir zu kompliziert, damit kann ich nicht zack-zack blind arbeiten.

Auf Debian-Systemen läßt sich History-Suche mittels Page-Up / Page-Down leicht einschalten: Dazu müssen lediglich zwei Zeilen in /etc/inputrc aktiviert werden (je nach Version ca. Zeile 36 oder Zeile 40):

# alternate mappings for "page up" and "page down" to search the history
"\e[5~": history-search-backward  
"\e[6~": history-search-forward

Gerade wenn man mehrmals hintereinander die gleichen Arbeitsschritte durchführt, lassen sich so sehr schnell und blind alte Kommandos wieder hochholen und erneut abfeuern, ohne hinschauen oder nachdenken zu müssen.

Problem 1: Diese Systeme sind Backscatter-Systeme.

Wer auf die gefälschten mißbrauchten Absender von Spam-Mails antwortet, der trifft unschuldige Dritte, die mit dem Spam-Versand nichts zu tun haben. Dieses Problem nennt man “Backscatter” (engl., zurückwerfen/zurückstreuen). Der arme unschuldige Dritte wird unter Umständen mit Millionen Rückantworten geflutet, so daß er seinerseits schnell mit seinen Mailservern in Schwierigkeiten gerät. -Für ihn ist das ein Distributed-Denial-of-Service, der freundlicherweise von seinen Postmaster-Kollegen anderer Systeme gegen ihn ausgeübt wird. Dieser DDoS kann hohe finanzielle Schäden verursachen und andere Systeme zusammenbrechen lassen.

Zurecht landen Backscatter-Mailserver selbst auf RBL-Sperrlisten, so daß andere Mailserver von diesen Systemen keine Mails mehr annehmen. Wer diese Backscatter-Mails zulasten unschuldiger Dritter versendet ist nicht besser, als der Spammer selber. Wer solche Systeme betreibt handelt wahlweise unwissend oder auch rücksichts- und verantwortungslos.

Spam- und Virenfilter dürfen auf Spam-Mails nie mit Bounces reagieren — und Challenge-Response-Systeme dürfen folgerichtig auch nicht an die (gefälschten!) Absender vermeindlicher Spam-Mails antworten.

Hersteller, die ihren Kunden derartige Systeme anpreise und verkaufen, riskieren am Ende den sicheren Mailbetrieb ihrer Kunden. Denn bei einem (berechtigten!) Blacklisting der Mailrelays ist der ausgehende E-Mail-Versand gestört — und damit führen derartige Spam-Systeme zum Denial-of-Service “gegen sich selbst”.

Problem 2: Legitime E-Mails gehen verloren

Das zweite Problem liegt zu einem Großteil in der menschlichen Kommunikation begründet: Diverse Absender werden die angefragte Bestätigung nicht ausführen, aber auch nicht ausführen können. Normale erwünschte Mailkommuniktion bleibt damit auf der Strecke.

• Viele Absender/Anwender verstehen die Anfrage nicht (die oft auch in Englisch ist)
• Oft werden diese Bestätigungsmails ihrerseits von anderen Spamfiltern aus dem Verkehr gezogen
• Viele Absender werden zurecht aus Angst und Misstrauen nicht ominöse URLs in ihrer INBOX anklicken und auf ominöse Webseiten irgendwelche Aufgaben lösen. Zumindest die Admins sind eigentlich daran interessiert ihren Nutzern beizubringen, genau solche Aktionen NICHT vorzunehmen, um sie gegen Phishing- und andere Attacken zu sensibilisieren. Hier wird die eigene Usererziehung konterkariert.
• Mailinglisten, Ticketsysteme, Buchungssysteme, Onlineshops und andere (legitime!) Webplattformen und e-Commerce-Dienste werden naturgemäß nie die angefragte Response-Aktion ausführen. Hier wird also absichtlich ein Großteil des erwünschten E-Mail-Verkehrs verhindert.
• Und am Ende belauern sich zwei Challence-Response-Systeme gegenseitig und verlangen wechselseitige Bestätigung, bevor sie die jeweilige andere Bestätigungsanfrage weiterleiten. Mit dem Erfolg: Der Absender erfährt noch nicht mal, daß seine E-Mail nicht angekommen ist, was bekanntermaßen auf interessante rechtliche Haftungsfragen auslösen kann.

Problem 3: 100% spamfreiheit ist natürlich unmöglich

Neben den aufgezeigten technischen und inhaltlichen Problemen die einen Einsatz solcher Lösung ganz klar verbieten, sind natürlich auch entsprechende Werbeaussagen über die “100%”ige spamfreiheit offensichtlich Unsinn und damit unseriös gegenüber den eigenen Kunden. Gerade wenn Spammer über Notnetze Spam versenden  und dabei auch zunehmend über die offiziellen Relays des Absenders gehen, können sie auf diesem Wege auch Challenge-Response-Systeme umgehen. Perfiderweise zwingt man Spammer durch solche Techniken geradezu, daß sie bevorzugt existierende Mailadressen als Absender nehmen — und man erzieht sich auf diese Art und Weise Spammer so, daß das Backscatter-Problem geradezu verstärkt wird. Jeder weiß: 100% gibt es nicht.

Weiterführende Links

• Challenge-Response Anti-Spam Systems Considered Harmful
• Why Challenge-Response is a Bad Idea

Es ist Pech und kommt plötzlich über einen herein: Aus aller Welt trudeln Bounce-Meldungen zu Spam- und Virenmails ein, die man selber gar nicht verschickt hat. Die Flut eingehender E-Mails kann grenzenlos sein: Große Spamwellen mit vielen Millionen E-Mails können auch Hunderttausende von Bounce-Rückläufern erzeugen, die in kürzester Zeit an den unschuldigen Absender zurückgesandt werden, dessen Domain oder Mailadresse mißbraucht wurde. Leider gibt es auch heute noch viele Systeme die eine Spam- und Virenprüfung nicht in Echtzeit durchführen und derartige Mails rejecten können. Ausreichend viele (zu viele) nehmen Mail-Müll nach wie vor an und Bouncen ihn dann an den gefakten Absender.

Als Gegenmittel ist eigentlich Bounce Address Tag Validation (BATV) erfunden wurden. Dieses System schreibt bei ausgehenden E-Mails den Envelope-Absender um und fügt eine kleine Markierung ein. Kommen nun reale E-Mail-Bounces zurück, so wird an dem Tag in der Zieladresse erkannt, daß es tatsächlich um eine E-Mail ging, die unser System einst verlassen hat. Spam-Bounces von Mails die aus anderen Quellen stammen und über Bullet-Proof-Server oder Botnetze der Spammer verschickt werden, besitzen diesen Bounce-Tag nicht und können  so erkannt und verworfen werden.

Im Prinzip funktioniert BATV, doch in der Praxis bereitet das System einige Schmerzen:

• Postfix und andere MTAs können BATV nicht nativ, so daß eine weitere Software eingebunden werden muß. Das erhöht Komplexität, Abhängigkeit und damit die Fehlerquote. “Prinzipiell” funktioniert das jedoch.
• Es muß sichergestellt sein, daß alle E-Mails mit der eigenen Domain als Absender wirklich stets BATV-codiert versandt werden. Das kann Probleme bei externen Dienstleistern (Buchungssystemen, Newslettern) geben, aber auch wenn Privatanwender in Foren schreiben, Artikel weiterleiten, Grußkarten versenden etc. etc. Die Idee, Mails mit dem eigene Absender können tatsächlich stets nur vom eigenen Mailserver kommen, ist weit verbreitet, aber falsch. Die dahinterstehenden Probleme haben wir ja bereits in unserem Vortrag zu SPF beleuchtet und treffen hier sehr vergleichbar zu.

Am Ende steigt durch die Einführung von BATV also das Risiko, daß Bounces von echten, erwünschten eigenen E-Mails in bestimmten Situationen ebenfalls verworfen werden und damit verloren gehen. An dieser Stelle wird die erwünschte Kommunikation zwischen echten Absendern/Empfängern riskiert, die über eine eventuelle Fehlzustellung Ihrer E-Mails nicht mehr informiert werden. Nicht zuletzt wirft sowas auch durchaus juristische Fragen auf, beispielsweise, ob ein irrtümliches Verwerfen derartiger erwünschter Bounces nicht ein Fall des §206 StGB, also der unbefugten Unterdrückung anvertrauter Nachrichten, darstellen könnte. Details dazu in unseren Vorträgen zu Rechtsfragen für Postmaster.

Bevor man also leichtfertig BATV einführt und die damit verbundenen Risiken und “Schmerzen” in Kauf nimmt, sollte also stets geprüft werden, ob es nicht ebenso wirksame andere Möglichkeiten gibt, die das Problem ebenfalls gut lösen und weniger/keine Nebenwirkungen und Risiken haben. -Und am Ende zu einfacheren und damit stabileren, sicheren und pflegbareren Systemen führen.

In fast allen Fällen ist man sehr, sehr selten Opfer einer solcher Backscatter-Bounces, das ganze entspricht dem 5er im Lotto.  Oft geht der Ansturm nach wenigen Tagen vorbei — und dann beruht de rganze Wirbel auf einer konkreten E-Mail oder einer konkreten Versandaktion eines Spammers. Sprich: Da 90% der Bounces Teile der Orginal-E-Mail enthalten finden sich sehr einfach markante Text-Pattern und andere Merkmale, um diese Bounces gezielt über die body-/header_checks von Postfix herauszufiltern. Dazu schaut man sich drei/vier/fünf dieser Bounces an um das gemeinsame Merkmal zu finden. Anhand dessen kann dann sehr schnell und sehr einfach fast die komplette Rückläuferwelle geblockt werden — und der Rest wird ausgesessen. Auch RBL-Listen von Spamhaus oder backscatterer.org helfen, die Mails fern zu halten.

Nur wer wirklich nicht nur im Einzelfall, sondern permanent Opfer dieser Backscatter-Bounces ist und nur wer bereit ist, deswegen auch Komplikationen, Risiken und andere Schmerzen mit in Kauf zu nehmen, sollte über eine BATV-Implementierung nachdenken, beispielsweise mit batv-proxy.pl von Ralph Babel.