Bartels SMTPFILTER

5.a

Input

5.b

Sektionen

5.c

Reporting

5.d

Statistik

5.e

BGP Connection

5.f

SMTP AUTH

5.g

Gegenmaßnahmen

8.a

ACTIONS

8.b

CONSTVARS

8.c

VARS

8.d

RULES

8.d.i

Mathematische Regeln

8.d.ii

CONTAINS Regeln

8.d.iii

IN Regeln

8.d.iv

MATCH Regeln

8.d.v

Funktionsaufrufe in Regeln

8.d.vi

Tricks mit Regeln

Die Grundidee von SMTPFILTER besteht darin, nicht eine Mail aufgrund von einzelnen Schlüsselwörtern oder Phrasen zu kategorisieren sondern für bestimmte Eigenschaften der Mail Punkte zu vergeben. Diese Punkte können mit beliebiger Mathematik zu einem Endergebnis kombiniert werden und lösen dann eine oder mehrere Aktionen aus.

Um als zentraler Server zur Verfügung zu stehen, werden mehrere unterschiedliche Konfigurationen gleichzeitig verwaltet, die automatisch auf Basis der Domain des Empfängers selektiert werden.

Da auch die Versender von SPAM Mails um die Schlüsselwortsuchmaschinen wissen, werden Schlüsselwörter häufig verstümmelt, absichtlich falsch geschrieben oder kunstvoll auseinandergezerrt. Dagegen wird durch zwei unabhängige Methoden vorgegangen: zum einen können verschiedene Wortschreibweisen in Listen zusammengefasst werden, innerhalb der Regeln wird nur noch die Liste erwähnt. Zum anderen wird eine spezielle Worterkennungs- und Vergleichsengine verwendet, die speziell auf Wildcards und auf verstümmelte Worte optimiert ist.

Da Massenemails typischerweise an viele Anwender gesendet werden, wird aus jeder Mail eine Kette von Kennzahlen errechnet und diese in einer Liste vorgehalten. Jede Mail wird nun mit jeder Mail aus dieser Liste über die Kennzahlen verglichen und bei hoher Ähnlichkeit eine Ähnlichkeits- und Wiederholungszahl errechnet und in einer Variablen zur Verfügung gestellt, die innerhalb der Regeldatei ausgewertet werden kann. Auf diese Weise kann eine immer gleiche Mailflut mit geringen Abweichungen (SPAM Versender setzen z.B. den Namen des Mailaccounts in den Betreff oder die Anrede ein) erkannt und blockiert werden.

Da SPAM Versender meist den gleichen Internetprovider nutzen, wird eine Statistik geführt, wie viel SPAM aus dem gleichen Providernetz stammt und daraus eine Kennzahl errechnet. Je höher die Kennzahl, desto wahrscheinlicher, dass weiterer E-Mail Verkehr vom gleichen Provider wieder SPAM ist. Diese Kennzahl steht dem Regelsystem zur Verfügung und kann dort ausgewertet werden.

Weitere Features:

• Decodierung von base64 Nachrichten
• HTML Syntaxinterpreter. Der Filter lässt sich nicht durch HTML Kommentare o.ä. überlisten
• Wortstatistik zur Vermeidung von falschen Löschungen.

Der Filter arbeitet rein als SMTP Filter und gibt den Eingangsdatenstrom transparent an den einzustellenden Empfänger durch. Dabei kann zusätzlich ein Frontend eingesetzt werden, wenn spezielle Features am Frontend benötigt werden, die SMTPFILTER nicht bietet. SMTPFilter kann nur SMTP Protokoll ausgeben, so dass das Backend zwingend ist.

Sendmail ist dabei nicht in irgend einer Art bevorzugt, da nur das SMTP Protokoll gefiltert wird, es kann auch ein beliebiger anderer SMTP Handler als Front- oder Backend eingesetzt werden.

Hier wird beschrieben, welche Aktionen zur Verfügung stehen. Die Aktionen können beliebig kombiniert werden. Welche Kombination für welche Punktestände definiert werden, wird in der Sektion für die Regeldatei beschrieben

Zusätzlich wird in jedem Mailheader das Attribut X-SPAMPOINTS: <Punkte> eingeführt. Es besteht also die Möglichkeit, alle Mails mit TTRANSFER zu versehen und im Mailclient entsprechend zu filtern.

Weitere Aktionen werden durch die Goodbadlist direkt ausgeführt, bevor die Mail überhaupt gescannt wird und die Aktion wird entsprechend dem Befehl TTRANSFER oder TTRASH ausgeführt.

Die Worterkennung teilt die Zeichen in folgende Bereiche auf:

• Tatsächliches Zeichen
• Eventueller Worttrenner
• Sicherer Worttrenner
• Wildcard

Die tatsächlichen Zeichen werden so zusammengefasst, dass Groß/Kleinschreibung ignoriert wird und dass nicht durch besondere Zeichen, die visuelle zusammengehörig sind, Wörter nicht erkannt werden (z.b. á und a).

Solange Wörter nur durch eventuelle Worttrenner (z.b. Leerzeichen oder -) getrennt werden, werden alle Kombinationen, die sich aus dem Wort ergeben können getestet, soweit die einzelnen Segmente nicht mehr als 2 zusammenhängende Zeichen haben. Es wird also bei

t e s t

sowohl te als auch test als auch es und die restlichen möglichen Kombinationen erkannt. Trifft der Scanner auf ein Wildcard (z.b. ? oder $), so wird dieses durch jeden möglichen Buchstaben erkannt: t$st wird dabei also zu test tost trst tmst t1st usw. Der Wortscanner liefert die Eingabe für den Satzscanner, wie er bei der Regeldatei beschrieben ist. Außerdem werden spezielle Zeichenverwandtschaften erkannt. (z.b. 0 zu o oder i zu e) Dabei wird die Trefferwahrscheinlichkeit für das Wort reduziert, was zu einer Minderung des Regelwertes führt.

Das Programm kann mit folgenden Parametern gestartet werden:

In der Konfigurationsdatei werden zunächst einige generelle Angaben gemacht, anschließend können in mehreren Sektionen verschiedene Maildomains konfiguriert werden. Schlüsselworte, die mit einem $ versehen sind (bitte nicht mit $ eingeben), sind nur in der globalen Sektion zugelassen. Schlüsselworte, die mit & versehen sind, sind innerhalb einer Sektion oder im globalen Abschnitt zugelassen, alle anderen sind nur innerhalb einer Sektion zugelassen. Sektionen werden mit

[sektion1]

eingeleitet, Kommentare mit einem # (Leerzeichen und Tabulatoren sind erlaubt). Alle anderen Zeilen müssen als <Schlüsselwort> ’=’ <Wert> angegeben werden. Schlüsselworte, die von einem * gefolgt werden, können mehrfach angegeben werden.

Wird die Konfiguration geändert, so kann man den smtpfilter Stammprozess ein SIGHUP senden, damit dieser die neue Konfiguration einliest, der Prozess muss nicht neu gestartet werden.

Abhängig von der Domain des Empfängers wird die entsprechende Sektion ausgewählt, die sowohl die Regeln als auch die Goodbadlist bestimmt

Das Reporting besteht darin, dass jeder Mailuser einmal pro Tag einen Report zugesandt bekommt, der ihn darüber Informiert, welche Mails gefiltert wurden. Wird in der Regeldatei die Aktion TREPORT mit angegeben, so wird die entsprechende Mail in den Report mit aufgenommen. Wurden keine Mails mit TREPORT angetroffen, so wird auch kein Report versendet.

Das Schlüsselwort REPORTTIME gibt die Tageszeit in Sekunden an, zu der der Report versandt werden soll. Dies könnte z.B. 1 Stunde vor Arbeitsende passieren, damit der Benutzer noch auf falsch gescannte Mails reagieren kann.

Dieses Feature ist nicht zwingend, wird kein BGP Server angegeben, so wird auch keine BGP Verbindung aufgebaut. Da viele Spammails von den immer gleichen ISP’s versendet werden, wird mittels der IP Adresse der ISP identifiziert und eine Statistik geführt, wie viel SPAM von diesem Provider ausging. Über das BGP Protokoll werden einzelne Netznummern IP Adressbereichen zugeordnet. Um die notwendige Verbindung aufbauen zu können, sind folgende Parameter nötig:

Wenn der Filter als Frontend eingesetzt wird, kann es wünschenswert sein, dass sich die Benutzer authentifizieren, bevor sie Mails versenden können. Dazu werden von SMTPFILTER die Authentifzierungsmechanismen PLAIN und LOGIN unterstützt. Folgende Konfigurationsparameter sind möglich:

Wenn sich SPAM Versender eindeutig identifizieren lassen, so können Gegenmaßnahmen ergriffen werden, die es dem Versender erschweren, seinen Maildurchsatz zu erreichen. Dabei werden nach Zufallsprinzip 2 unterschiedliche Maßnahmen ergriffen:

1. Durchsatzsenden: Dabei wird eine große Textdatei als Protokollantwort versendet. Dies blockiert den Sender, soweit dieser nur einen schmalbandigen Zugang hat. Diese Methode ist nur sinnvoll, wenn der SMTPFILTER eine größere Bandbreite ohne Probleme nutzen kann.
2. Als Antwort im Protokoll wird langsam eine sehr lange Zeichenkette ausgegeben, deren Versenden bis zu 2 Stunden dauert. Dabei werden Prozessressourcen beim SPAM Versender belegt.

Da mit Sicherheit jeder Benutzer auch Mails bekommt, die zwar verdächtigen Inhalt haben, aber durchaus erwünscht sind, können über die Goodbadlist einzelne Sender gezielt freigeschalten oder gesperrt werden. Damit hierzu nicht der Administrator bemüht werden muss, wird eine Mail unter folgenden Umständen als Goodbadlist Kommando betrachtet:

• Die E-Mail Adresse von Empfänger und Sender stimmen exakt überein.
• Die Mail wird nur an den Sender adressiert.
• Der Sender ist durch seine IP Adresse authentifiziert
• Das Subject beginnt mit einem : und wird gefolgt von einem Zeichen aus :+-#

Es sind folgende Kommandos möglich:

Dabei kann auch die Domain mail.com komplett abgelehnt werden, der Benutzer [email protected] jedoch freigeschaltet werden.

Ist die Absenderadresse in der Sektion des Benutzers auch als Admin eingetragen, so kann der Sender auch globale Einträge hinzufügen, die für alle Benutzer dieser Liste gelten. Auf diese Weise kann die Chefsekretärein die wichtigsten Geschäftskontakte generell von der Filterung ausnehmen. Globale Einträge werden dadurch identifiziert, dass die Betreffzeile mit zwei Doppelpunkten beginnt. Aus :-- yahoo.com wird dann ::-- yahoo.com

Wenn die Nachricht erfolgreich verarbeitet wurde, erhält der Sender nicht die Originalnachricht wieder, sondern eine Nachricht mit dem gesendeten Befehl und der Meldung „message command accepted“ oder „message command rejected“.

Der Reset für eine ASN Statistik kann nur als Admin ausgeführt werden.

Jede Mail wird Wort- und Phrasenweise einer statistischen Bewertung unterzogen. Dabei wird ein Hash Algorithmus verwendet, was den Datenbestand einerseits anonymisiert und andererseits eine hohe Geschwindigkeit sicherstellt. Dabei wird die Anzahl gezählt, wie häufig der, aus dem Wort / der Phrase berechnete Wert, in guten und in schlechten Mails vorkommt und daraus eine Wahrscheinlichkeit errechnet. Damit die Statistik sinnvolle Ergebnisse erzielen kann, müssen entsprechend gute und schlechte Mails gelernt werden. Dies kann einerseits über das AUTOLEARNHASH Schlüsselwort erfolgen oder direkt vom User durchgeführt werden.

Damit eine Mail als gut / schlecht gelernt wird muss sie von einem authentifzierten Benutzer an einen der Pseudoaccounts mit dem Namen good oder bad gesendet werden. Alternativ kann auch im Header der Email das Attribut X-LEARNGOOD oder X-LEARNBAD spezifiziert werden. Der Benutzer muss aber in jedem Fall authentifizert sein.

Als Ausgabe können die Variablen statisticquality und statisticresult ausgewertet werden. Solange nicht in jeder Hashtabelle mindestens 100 Mails gelernt wurden, wird die Qualität immer mit 0 ausgegeben.

Das Gerüst von Regeldateien sieht wie folgt aus:

%%ACTIONS
…
%%CONSTVARS
…
%%VARS
…
%%RULES
…
%%

Die einzelnen Sektionen sind in den Unterpunkten beschrieben. Jede dieser Sektionen muss angegeben werden, auch wenn sie leer bleibt. Alle Schlüsselwörter sind nicht von Groß/Kleinschreibung abhängig.

Unter diesem Punkt werden einzelnen Punktebereichen die auszuführenden Aktionen zugewiesen. Der Bereich, der als erster eingelesen wird, ist der Standardbereich, wenn sonst kein passender Bereich gefunden wird. Jede Zeile hat folgendes Format:

<unterer Punktestand> - <oberer Punktestand> Aktion1 .. Aktion n

Beispiel:

0 – 150 TTRANSFER
150 – 200 TTRANSFER TWARN
200 – 400 TTRASH TREPORT
400 – 100000 TNOTHING

Wenn sich mehrere Bereich überlappen, so wird der erste passende genutzt. Da mehrere Regeldateien in einer Konfiguration angegeben werden können, muss nur in einer dieser Dateien die Sektion ACTIONS gefüllt sein.

In dieser Sektion können Variablen deklariert und initialisiert werden. Es stehen dazu folgende Datentypen zur Verfügung:

Jede Zeile besteht aus dem Datentyp, dem Variablennamen und einer Initialisierung (die Initialisierung ist in dieser Sektion Pflicht).

Die einzelnen Listenelemente werden einfach in Anführungszeichen hintereinander geschrieben und können dabei noch durch Komma getrennt werden. Werden mehrere Wörter von Leerzeichen getrennt in Anführungszeichen geschrieben, so gilt das als eine Wortphrase. Dazu später mehr unter der Sektion RULES

In dieser Sektion können wie auch die Sektion CONSTVARS Variablen deklariert und initialisiert werden. Wenn die Variablen nicht initialisiert werden, sind sie im wesentlichen Wertlos. Des Sektion ist für Erweiterungen gedacht, wenn Funktionen Referenzparameter übergeben werden.

Folgende Variablen sind implizit deklariert und vor dem Scan passend initialisiert:

Jeder Regelkopf besteht mindestens aus dem Schlüsselwort rule, dem Namen der Regel und einem Doppelpunkt. Jede Regel ist implizit mit ihrem Namen als ein Integer deklariert und kann daher in mathematischen Ausdrücken verwendet werden. Hier ein paar Beispiele für die Einleitung einer Regel:

Es gibt mehrere Arten von Regeln: CONTAINS, MATCH, IN und mathematische Regeln, die im Folgenden genauer erläutert sind.

Für mathematische Regeln stehen folgende Operatoren zur Verfügung:

Für mathematische Regeln gilt die Punktzahl der Regel als Obergrenze, ansonsten entspricht das Ergebnis der Operation. Übersteigt die Punktzahl die Obergrenze, so wird diese Obergrenze zugewiesen. Die Ergebnisse von Vergleichen sind immer 0 oder 32000, was anschließend auf das Maximum der Regel reduziert wird. Ist der Regel eine negative Punktzahl zugeordnet und der Absolutbetrag des Ergebnisses liegt darüber, so wird der negative Betrag zugeordnet.

CONTAINS Regeln bestehen aus einer Variablenliste, die zu durchsuchen ist, dem Schlüsselwort CONTAINS und anschließend einer Wortphrase.

Es gelten folgende Regeln:

• Es können vor dem CONTAINS mehrere Variablen stehen, die mit Komma getrennt werden.
• Jeder Text wird in Anführungszeichen angegeben, wobei auch einfache Hochkomma genutzt werden können.
• Nach dem CONTAINS können mehrere Worte stehen. Mit eckigen Klammern oder mit Tilden kann angegeben werden, wie viele Worte zwischen den gesuchten Schlüsselwörtern auftreten dürfen.
• Wenn innerhalb der Anführungszeichen mehrere Worte stehen, so entsteht daraus eine feste Wortphrase, die ohne Abstand definiert ist.
• Statt einzelner Wörter können auch Listen benutzt werden, wobei ein beliebiges Wort aus Liste1 mit einem beliebigen Word aus Liste2 verknüpft mit dem definierten Abstand einen Treffer ergibt.
• Es können spontane Listen genutzt werden, indem die zu suchenden Wörter in Klammern mit Kommata getrennt geschrieben werden. Auch in Listen können mehrere Wörter hintereinander innerhalb eines Strings stehen.
• In einem String kann ein Fragezeichen auftauchen, dann können die beiden Wörter, die durch das Fragezeichen getrennt sind, wahlweise zusammen oder getrennt stehen. Die Trennung kann ein beliebiges „nicht Text Zeichen“ sein.
• Die Variablen, die vor dem CONTAINS stehen, können auch Listen sein, wobei jeder einzelne Wert der Liste gescannt wird.
• Alle Werte, die rechts von CONTAINS verwendet werden, müssen konstante Werte sein.
• Jedes Wort, nach dem gescannt wird, kann durch ein * beendet werden.

Das Schlüsselwort CONTAINS ist in den folgenden Beispielen mit CT abgekürzt ist. Es wird angenommen, dass in der CONSTVAR Sektion folgende Variablen deklariert wurden:

STRING var1 = “Fisch“
LIST var2 = “Fahrrad” “Auto”
LIST var3 = “Fahrrad” “Lenkrad” “rotes Auto”

Beispiele:

Bei IN Regeln wird ein String in einer Liste gesucht, es können aber beliebige Kombinationen aus Strings und Listen verwendet werden. Die Regel trifft zu, sobald ein Element aus der ersten Variable in der zweiten Variable auftritt. Der Vergleich ist dabei nicht Groß/Kleinschreibungsabhängig.

Die Syntax lautet:

<var1> IN <var2>

Beispiel:

realrcpt IN torcpt

Prüft, ob mindestens ein Empfänger in der TO Liste auftaucht.

Mittels MATCH können reguläre Ausdrücke verarbeitet werden. Die Syntax lautet:

<var> MATCH <regulärer Ausdruck>

Der reguläre Ausdruck muss dabei in Anführungszeichen oder Hochkommata stehen.

Beispiel:

sender MATCH ".*[0-9]{2,}.*@"

Erkennt, ob mindestens 2 Ziffern hintereinander im Namen des Senders enthalten sind.

Für jede Variable kann auch ein Funktionsaufruf stehen, der auf Basis anderer Variablen einen Wert ermittelt.

Beispiel:

stringinmap(„X-MSMail-Priority“, headerlist) CONTAINS „high“	

Ruft die Funktion stringinmap auf, welche nach dem Text „X-MSMail-Priority“ in der headerlist sucht und den zugewiesenen Wert ermittelt. Enthält dieser Wert das Wort high, so wurde die E-Mail mit hoher Priorität versendet. Folgende Funktionen stehen zur Verfügung:

Ziel: Mailaccounts, die auf einer offiziellen Webseite stehen, werden häufig in Spam mit einbezogen. Da dort möglichst keine Mail verloren gehen sollen, soll die Toleranzschwelle aber erweitert sein. Hier wird gezeigt, wie man bestimmte Regeln für spezielle Accounts umgewichten kann.

# Diese Regel erhält 50 Punkte, wenn ein officieller Account der Empfänger ist
rule officialaccount 50 : realrcpt contains („info“, „pr“, „sales“)
# Diese Regel erhält 1 Punkt, wenn besonders unerwünschte Regeln getroffen wurden.
rule officialdenyrules 1 : sexwords + unsubcribe
# diese Regel emmitiert –50 Punkte für offizielle Accounts oder +50, wenn auf dem
# offiziellen Account spezielle Regeln getroffen wurden
rule EMIT officialemit 200: officialdenyrules * 100 * officialaccount / 50 – officialaccount

Ziel: Sobald eine Mail das dritte mal eintrifft, sollen schnell wachsend viele Strafpunkte vergeben werden, ansonsten soll die Ähnlichkeit ignoriert werden.

# Diese Regel erhält 1 Punkt, wenn der Cachewert auf 15 oder mehr steht
rule repetitivehelper 1: cachevalue > 14
# Diese Regel wird erst aktiv, wenn repetitivehelper gesetzt ist, und liefert für die
# ersten 2 übereinstimmungen keine Strafpunkte, ab der dritten werden ca. 40 Punkte
# pro Regel übergeben
rule EMIT repetitive 300: repetitivehelper * (cachevalue - 8) * 10

Ziel: einige Regeln sollen zusammen nicht über eine bestimmte Punktzahl aufsummieren können, da sie zu wenig aussagekräftig sind.

# Diese Regel prüft, ob aus dem ASN früher viel Spam kam
rule asnspam 110: asnspamcount * 2
# Diese Regel prüft, ob viele HTML Farben vorhanden sind
rule htmlcolored 100: htmlfontcolorcount * 20
# Diese Regel stellt sicher, dass asnspam und htmlcolored
# zusammen nicht alleine die Mail als spam qualifizieren
rule emit non_content_rules 140: asnspamcount + htmlcolored

Bartels SMTPFILTER
© 2024 Bartels System GmbH • Aktualisiert: 11. October 2010, 10:54 [UTC]