Serverseitige Maßnahmen zur Bek¨ampfung von E-Mail-Spam

Transcrição

Serverseitige Maßnahmen zur Bekämpfung von
E-Mail-Spam
7. Juni 2004
Rechtlicher Hinweis
Dieser Beitrag ist lizensiert unter der GNU Free Documentation License.
Zusammenfassung
Eine der bedeutendsten Internet-Anwendungen, das Medium E-Mail, wird von skrupellosen Geschäftemachern
mit Milliarden lästiger Spam-Mails kaputt getrampelt. Die Schmerzschwelle ist bei fast allen Internetnutzern
so weit überschritten, dass sie mit technischen Maßnahmen vor der Flut an Datenmüll geschützt werden wollen.
Der wichtigste Faktor in der Spam-Bekämpfung ist, die Funktionsweise des Mediums E-Mail zu kennen
und Tricks zu verstehen, mit denen Spammer versuchen, unerkannt möglichst viele Empfänger auf ihre Produkte und Dienstleistungen aufmerksam zu machen. Administratoren von E-Mail-Infrastruktur haben gute
Möglichkeiten, die Benutzer ihrer Systeme wirkungsvoll vor Spam zu schützen. Dazu möchte ich neben einem Grundverständnis für die Verarbeitung von E-Mail einen Überblick über die verschiedenen prinzipiellen
Abwehrmaßnahmen geben. Außerdem können Tricks, mit denen Spammer versuchen, sich an Filtern vorbei
zu mogeln, erkannt werden und genau den gegenteiligen Effekt bewirken.
Zielgruppe des Vortrags sind neben betrieblichen Postmastern vor allem Betreiber sogenannter ”Rootserver”, die auf gemieteten oder eigenen bei einem Hosting-Provider stehenden Rechnern neben WWWAnwendungen meist auch ihre E-Mail-Versorgung abwickeln und dabei ”direkt an der Front”der Spam-Flut
ausgeliefert sind.
Serverseitige Maßnahmen zur Bekämpfung von E-Mail-Spam
1
Technische Grundlagen
Wir betrachten die technischen Schritte und Stationen einer E-Mail vom Versender bis zum Empfänger.
Nachdem der Absender seine Nachricht im Mail User Agent “ (oft als Mailclient“ bezeichnet) verfasst
”
”
hat, sendet er diese an den Mailserver seines Providers oder Arbeitgebers, der sich um die Weiterleitung ins
Internet kümmert. Der Einfachheit halber betrachten wir nur die Arbeitsweise dieses Systems, das direkt mit
dem Internet kommuniziert.
1.1
Domain Name System (DNS)
Bevor ein Absendersystem eine E-Mail zustellen kann, muss es wissen, welcher Host dafür zuständig ist, Mail
für eine bestimmte Domain oder Subdomain anzunehmen. Auskunft gibt das Domain Name System “ (DNS):
”
der Empfänger hat für jede Domain einen oder mehrere MX-Einträge “ ( Mail eXchange“) konfiguriert, die
”
”
Hostnamen der für E-Mail zuständigen Systeme nennen. Über DNS-Lookups können MX-Einträge abgefragt
werden:
$ host -t MX docsnyder.de
docsnyder.de mail is handled by 10 mx2.docsnyder.de.
E-Mails an die Domain docsnyder.de “ werden anschließend dem Host mx2.docsnyder.de “ zugestellt.
”
”
1.2
Mail Transport Agent (MTA)
Der Mail Transport Agent “ nimmt E-Mails aus dem Internet entgegen. Als Türsteher“ hat er die Möglichkeit,
”
”
den Empfang zuzulassen oder abzulehnen.
Über eine Netzwerkverbindung zum TCP-Port 25 des Zielsystems werden E-Mails mittels dem Simple
”
Mail Transfer Protocol “ (SMTP) übertragen:
$ nc mx2.docsnyder.de 25
220 mail.mxrecord.de ESMTP Postfix (No UBE/UCE please!)
EHLO home.docsnyder.de
250-mail.mxrecord.de
250-PIPELINING
250-SIZE 50000000
250-ETRN
250 8BITMIME
MAIL From:<
[email protected]
>
250 Ok
RCPT To:<
[email protected]
>
250
Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Testmail
Date: Tue, 27 Apr 2004 12:40:41 +0200
From: "Florian L. Klein" <
[email protected]
>
To: "Postmaster" <
[email protected]
>
Dies ist eine Testmail.
.
250
Ok: queued as CB8741ED
QUIT
221 Bye
Diese E-Mail wurde erfolgreich angenommen, im Gegensatz zu der folgenden:
$ nc mx2.docsnyder.de 25
220 mail.mxrecord.de ESMTP Postfix (No UBE/UCE please!)
EHLO home.docsnyder.de
250-mail.mxrecord.de
250-PIPELINING
250-SIZE 50000000
250-ETRN
250 8BITMIME
MAIL From:<
[email protected]
>
250 Ok
RCPT To:<
[email protected]
>
550
<[email protected]>: User unknown in local recipient table
QUIT
221 Bye
Die erste Ziffer der dreistelligen Zahl am Anfang der Antwortmeldung entscheidet über Erfolg oder Fehler:
2xx : in Ordnung - E-Mail kann zugestellt werden 4xx : temporäres Problem - ein späterer Versand ist
möglich 5xx : permanentes Problem - auch ein erneuter Versuch wird fehlschlagen
1.3
Mail Delivery Agent (MDA)
Nachdem der Mail Transport Agent“ eine Mail aus dem Internet angenommen hat, stellt er diese in eine
”
Warteschlange ( Queue“). Aus dieser gelangt die Nachricht an den Mail Delivery Agent “ (MDA), der die
”
”
Mail in ein Benutzerpostfach einsortiert, aus dem sie der Empfänger abrufen kann. Dabei hat der MDA die
Möglichkeit, den Inhalt der Mail zu überprüfen und Spam oder Viren zu erkennen.
2
Allgemeine Sicherheitsmaßnahmen
Ein falsch konfigurierter oder schlecht gewarteter Mailserver kann im Internet enorme Schäden anrichten.
Viele Spammer suchen nach Systemen, die E-Mails von beliebigen Absendern weiterleiten ( offene Relays “)
”
und für den Versand von Spam missbraucht werden können. Ein kompetenter und verantwortungsvoller
Administrator ist deshalb die wichtigste Voraussetzung für den Betrieb eines Mailservers.
2.1
Sicheres Grundsystem
Diese Richtlinien gelten nicht nur für E-Mail-Server, sondern generell für alle Rechner, die im Internet Dienste
anbieten:
Compiler und Buildsysteme haben auf einem Internetserver nichts verloren! Diese werden oft von eingeschleuster Trojanersoftware oder Rootkits vorausgesetzt, um diese an das Zielsystem anzupassen.
Software, die nicht oder erst in ferner Zukunft benötigt wird, macht das System nicht sicherer, als wenn sie
nicht installiert ist.
Benutzerleserechte für /var/log sind keine gute Idee. Abgesehen von datenschutzrechtlichen Problemen
können Benutzer sehr leicht lokale Schwachstellen finden und ausnutzen.
Brachliegende Benutzeraccounts bieten vermeidbare Angriffspunkte.
Der Root-Account sollte niemals direkt von außen (per SSH-Login) zugänglich sein, sondern nur über
lokale, nichtprivilegierte Accounts.
2.2
Sichere Konfiguration des Mail Transport Agent (MTA)
Aktuelle MTA-Software ist zwar bereits in ihrer Standardkonfiguration recht sicher, jedoch müssen einige
Punkte vor der Inbetriebnahme des Mail-Dienstes sowie nach größeren Konfigurationsänderungen überprüft
werden, um keine Zeitbombe zu betreiben:
2.2.1
E-Mail-Weiterleitung (Relaying)
Für die Weiterleitung von E-Mail muss zwischen lokalen und externen Absendern und Empfängern unterschieden werden. Maßgeblich dafür ist niemals die beliebig fälschbare E-Mail-Adresse des Absenders, sondern
ausschließlich die IP-Adresse des Einlieferers.
Externe Absender dürfen E-Mail nur an lokale Benutzer zustellen, aber nicht an Empfänger, für die das
System nicht zuständig ist! Falls diese Funktionalität benötigt wird, um z. B. Außendienstmitarbeitern zu
ermöglichen, ihre E-Mail über den Unternehmens-Mailserver zu versenden, muss dies über eine mit Benutzerkennung und Passwort authentifizierte SMTP-Sitzung ( SMTP AUTH “) erfolgen, die möglichst mit TLS
”
verschlüsselt übertragen wird. Jeder gänge Mailclient bietet die dazu nötigen Voraussetzungen.
Pflicht-Kontaktadressen postmaster@ “ und abuse@ “
”
”
Gemäß RFC 2142 müssen für jede Domain die Adressen postmaster@ “ und abuse@ “ existieren und re”
”
gelmäßig überprüft werden. Dies ist im eigenen Interesse zu empfehlen, da Administratoren auch nur Menschen sind und durchaus Sicherheitslücken übersehen können, die später für Netzmissbrauch ausgenutzt werden. Ignorierte Benachrichtigungen führen nicht nur zur unnötigen Vergrößerung der angerichteten Schäden,
sondern auch zu möglichen Eskalationen an vorgeschaltete Provider sowie zu Einträgen auf schwarzen Lis”
ten“.
2.2.2
2.3
Staugefahr und Leistungsengpässe erkennen und beheben
Nachdem der MTA E-Mails angenommen hat, werden diese in einer Warteschlange ( Queue “) gesammelt,
”
bis sie der MDA weiter verarbeitet und in Postfächer einsortiert. Je nach Auslegung des Systems und Komplexität hinterlegter Spamfilterregeln kann der MDA relativ viel Rechenleistung und Zeit für die Verarbeitung
benötigen. Als Faustregel sollte der MDA nicht länger als 10, in seltenen Fällen maximal 20 Sekunden mit einer
E-Mail beschäftigt sein.
Liefert nun der MTA E-Mails schneller an, als diese vom MDA verarbeitet werden können, entsteht ein
Stau in der Queue. Dieser kann zu sehr unerwünschten Wirkungen in Form zahlreicher Bounce-Mails führen,
wenn die Festplattenpartition voll läuft oder eine maximale Bearbeitungszeit (oft auf eine Stunde eingestellt)
überschritten wird.
Deshalb müssen im MTA Limits konfiguriert werden, die die Anzahl der eingelieferten E-Mails auch bei
massiven Spam-Zustellungen so begrenzen, dass der MDA diese verarbeiten kann:
Als maximale Anzahl gleichzeitig möglicher SMTP-Verbindungen reicht meist ein Wert zwischen 5 und
20 aus. Dieser sollte lieber am Anfang etwas zu niedrig gewählt und später vorsichtig erhöht werden.
Sind alle Verbindungen belegt, warten neue Zusteller so lange, bis eine Session beendet wird.
Der Idle-Timeout , nach dessen Überschreitung inaktive Zustellsessions beendet werden, wird entsprechend kurz eingestellt. Viele Spam-Würmer und offene Proxies machen sich nicht die Mühe, die Verbindung
ordnungsgemäß zu beenden, weshalb oft alle gleichzeitig möglichen SMTP-Sessions belegt sind und legitime
Absender unnötig lange warten müssen. Zwei Minuten Idle-Timeout sind ausreichend.
Für die Anzahl maximal gleichzeitig aktiver MDA-Instanzen kann ein sehr geringer Wert, etwa drei bis
fünf, gewählt werden. Die Verarbeitungskapazität verbessert sich bei höherer Parallelität nicht. Bei einem zu
geringen Wert ist das System oft nicht augelastet, da etwa auf DNS-Anfragen gewartet werden muss.
3
Merkmale von Spam
Spammer werden im Internet nicht gerade geliebt - weder von Empfängern noch von Anbietern, deren Dienste
sie nutzen. Adressaten versuchen zunehmends, sich mit Filtern vor der Spam-Flut zu schützen. Die meisten
Internetprovider dulden Spammer und deren beworbene WWW-Sites nicht und sperren diese. Der Spammer
kann dann nicht von seiner Werbeaktion profitieren.
Deshalb versuchen Spammer mit oft erheblichem Aufwand, sich zu verstecken. Sie gestalten ihre SpamMails so, dass sie empfängerseitig nicht ausgefiltert werden, und betreiben beworbene WWW-Sites bei speziellen Anbietern, die die Bewerbung per Spam explizit erlauben ( bulletproof hosting “). Für die Einliefe”
rung benutzen Spammer unsicher konfigurierte oder über Wurmprogramme trojanisierte Systeme Dritter,
die die tatsächlichen Versender verbergen. HELO-Angaben und E-Mail-Adressen werden ohnehin fast immer
gefälscht.
Die Kunst der Spam-Bekämpfung besteht darin, den Spammer mit seinen eigenen Waffen zu schlagen. Versuche, sich zu verstecken oder Spamfilter auszutricksen, sind fast immer zweifelsfrei als solche zu erkennen.
Deshalb kann ein Programm, das E-Mails auf derartige Merkmale untersucht, dann erst recht zuschlagen. Provider, die per Spam beworbene Angebote bewusst tolerieren, sind nicht nur in Spammerkreisen bekannt. Auch
zahlreiche schwarze Listen“ im Internet geben Auskunft über spamfreundliche Anbieter. So handelt es sich
”
bei E-Mails, die auf WWW-Sites verweisen, welche beim chinesischen Anbieter Chinanet betrieben werden,
fast ausnahmslos um Spam.
4
Spam-Abwehrmaßnahmen
Im Folgenden werden prinzipielle Möglichkeiten vorgestellt, wie man die Zustellung von Spam verhindern
oder eingelieferte E-Mails als Spam erkennen kann:
4.1
Inhaltsbasierte Filter
Im MDA aufgerufene Filterprogramme wie SpamAssassin untersuchen E-Mails auf bestimmte Eigenschaften
in den Kopfzeilen ( Header“) sowie im Text ( Body“). Diese werden einzeln bewertet, wie wahrscheinlich
”
”
sie bei unerwünschten oder legitimen Mails auftreten. Überschreitet die Summe dieser Bewertungen einen
bestimmten Schwellwert, deklariert das System die Mail als Spam, wonach sie z. B. in einen Spam-Ordner
einsortiert werden kann.
Auch im MTA sind grobe inhaltsbasierte Filterungen möglich, um z. B. E-Mail-Würmer oder auffällige
Spam-Mails zu erkennen und schon die Einlieferung zu verhindern.
4.2
Sessionbasierte Abwehr
Im Gegensatz zu inhaltsbasierten Filtern, die eine bereits angenommene Mail mit relativ großem Aufwand
analysieren, ist eine Abweisung in der SMTP-Session mit Angabe einer Fehlermeldung sehr ressourcenschonend. Dabei versucht man, schon vor dem Empfang der eigentlichen E-Mail Eigenschaften zu erkennen, die
auf eine große Spam-Wahrscheinlichkeit schließen lassen.
Viele Spammer missbrauchen für die Zustellung fremde Infrastruktur - meist offene Proxies oder virenverseuchte PCs. Erstere bedienen jedoch nicht nur Spammer und landen deshalb recht schnell auf schwar”
zen Listen“. Trojanisierte PCs sind oft über private DSL-Zugänge mit dem Internet verbunden, die als nicht
”
vertrauenswürdig“ für den Direktversand von E-Mail gelten und deshalb auf so genannten Dialup-Listen“
”
(DUL) zu finden sind.
Einige Spammer halten sich für besonders schlau und geben als HELO-Meldung die IP-Adresse oder den
Hostnamen des Empfängersystems an. In der eingelieferten Spam-Mail werden Headerdaten derart geschickt
gefälscht, dass der Bespammte seinen eigenen Server als Verursacher vermutet und deshalb zukünftig von
Spam-Beschwerden absieht. Da jedoch kein legitimer Absender Angaben des Empfängers im HELO angibt,
können damit etwa 20 - 30 % aller Spam-Mails abgewiesen werden.
In anderen Spam-Läufen werden HELOs oder Absender-Domains benutzt, die bei allen Spams dieser Werbeaktion ganz oder teilweise gleich bleiben. Ist der Administrator schnell und wachsam, kann er mit einer
einzigen Regel seine Benutzer vor der ganzen Spamwelle schützen.
5
Die Rolle des Domain Name Service (DNS) bei der Abwehr und Bekämpfung
unerwünschter Spam-Mails
Wenn der Spammer meinen Server gar nicht erst findet...
...bleibt er auf seinem Spam sitzen, ohne mich belästigen zu können.
...beschränkt sich die übertragene Datenmenge auf einen winzigen DNS-Request und dessen Rückantwort.
...muss ich dem Spammer keine Rechenleistung schenken.
5.1
Verwendung von Subdomains für E-Mail
Wenn man seinen eigenen Nameserver betreibt oder einen entsprechend konfigurierbaren Dienst des Providers nutzt, hat man die Möglichkeit, Subdomains zu verwenden. Diese bieten sich vor allem für den E-MailVerkehr an.
Im Gegensatz zu Domains, deren DNS-Einstellungen über die Richtlinien des jeweiligen Domainverwalters (z. B. DeNIC) bestimmten Einschränkungen unterliegen, hat man bei der Verwaltung von Subdomains
sehr weit reichende Möglichkeiten, sich gegen Spam zu wehren. Eine große Rolle dabei spielen Verfallszeiten.
Clientseitig werden DNS-Informationen oft in einem Cache zwischengespeichert, um die Anzahl der Zugriffe
zu minimieren und die Verarbeitung zu beschleunigen. Die von vielen Domainverwaltern als Minimum geforderte Verfallszeit von einem Tag (86400 Sekunden) ist für die Aufklärung von Spam viel zu lang. Ein viel
kürzerer Wert von einer Stunde (3600 Sekunden) zwingt den Spammer dazu, relativ häufig DNS-Requests
abzusetzen, die wie wir später sehen verraten können, wo sich ein Spam-Versender versteckt.
Auch können Subdomains unbürokratisch und schnell aktiviert, verändert und gelöscht werden. Da man
dafür nur einen Nameserver benötigt und nicht wie für Domains mindestens zwei, kann man Subdomains mit
einem einzigen Server kontrollieren. Bei dessen Nichtverfügbarkeit wird Mail verzögert und später zugestellt.
5.2
Temporäre Subdomains
Beim Betrieb einer Internetpräsenz ist fast immer die Angabe einer E-Mail-Adresse als Kontaktinformation
nötig. Auch wenn man sich aktiv an Diskussionen im Usenet oder in WWW-Foren beteiligt, ist es nur eine
Frage der Zeit, bis Spammer die verwendeten E-Mail-Adressen finden und mit Werbung für zweifelhafte Produkte und Dienstleistungen überschütten. Diese Spam-Flut lässt sich nur stoppen, indem man diese Adressen
irgendwann stilllegt und durch neue ersetzt, was in der Praxis nicht immer möglich ist.
Mit einer Subdomain, die ein für den menschlichen Benutzer deutlich sichtbares Verfallsdatum enthält und
monatlich, vierteljährlich oder jährlich gewechselt wird, kann man die Spam-Flut vorzeitig bremsen. Dabei
wird die Subdomain nach dem Ablauf ihrer Gültigkeit aus dem Nameserver entfernt, wonach der Spammer
den Mailserver des Opfers gar nicht mehr findet.
Beispiel: fk.lt@ expires-200412 .docsnyder.de
Etwas weniger deutlich und deshalb vor allem für persönliche Kontakte besser geeignet ist ein verstecktes
Verfallsdatum, das z. B. aus einem Buchstabenkürzel bestehen kann: fk.lt@ ld .docsnyder.de
Als Nachteil dieser Methode entsteht jedoch ein Arbeitsaufwand, um regelmäßig in WWW-Foren und
News-Clients seine E-Mail-Adressen zu aktualisieren.
5.3
DNS-Logdateien verraten Spammer
Aus unerklärlichen Gründen werden zwar für fast jede Anwendung - WWW-Server, Proxy, MTA, Datenbank - Logdateien im System geführt, aber nicht für den DNS-Dienst. Im Gegensatz zu häufig geäußerten
Befürchtungen erzeugt ein Nameserver, der sämtliche Abfragen in eine Datei protokolliert, nicht mehr Logaufkommen als ein MTA oder Proxy - eher sogar deutlich weniger, da DNS-Informationen clientseitig sehr
lange zwischengespeichert werden.
Generell wichtig ist eine exakte Zeitsynchronisation über das Network Time Protocol“ (NTP), sofern
”
MTA und DNS auf unterschiedlichen Hosts betrieben werden. Damit kann man Zusammenhänge zwischen
Nameserver- und Mailserver-Logdateien erkennen und zuordnen.
Bei der Verwendung von BIND 8 oder 9 genügen folgende Zeilen in /etc/bind/named.conf “:
”
logging {
channel "query_log" {
file "/var/log/named_queries.log";
severity info;
print-time yes;
};
category "queries" { "query_log"; };
category "unmatched" { "null"; };
category "default" { "default_syslog"; "default_debug"; };
};
Wie alle Logdateien sollte auch die des Nameservers regelmäßig rotiert“ werden, um zu verhindern, dass
”
die Logpartition vollläuft. Dazu weist /etc/logrotate.d/named “ den Logrotate-Dienst an, das Nameserver-Log
”
beispielsweise wöchentlich zu aktualisieren, dabei die Zugriffsrechte korrekt zu setzen und den Nameserver
neu zu starten, damit er in die neue Datei loggt:
/var/log/named_queries.log {
weekly
missingok
rotate 4
compress
delaycompress
notifempty
create 640 root adm
postrotate
/etc/init.d/bind9 restart > /dev/null
endscript
}
Wenn man mit zwei parallelen xterm-Konsolen Nameserver- und MTA-Log nebeneinander betrachtet,
sieht man sehr schnell Zusammenhänge zwischen DNS-Requests und Spam-Einlieferungsversuchen.
5.4
Dem Spam-Versender auf der Spur
Wir betrachten als Beispiel einen Spam-Lauf, der über offene Proxies zugestellt wird und ein Gewinnspiel
bewirbt.
Apr 25
15:25:41
.197 client
66.98.15.145
#48716: query:
spamtrap.docsnyder.de
IN
MX
Apr 25
15:33:03
.762 client
216.114.194.21
#58145: query: muelltonne.spamtrap.docsnyder.de IN A
Apr 25
15:42:15
.720 client
66.225.137.180
Apr 25
15:53:01
.462 client
61.86.6.5
Kurz bevor der Spammer über mehrere offene Proxies SMTP-Sessions eröffnet, ist im DNS-Log eine MXAnfrage zu sehen, die in diesem Fall von 66.98.15.145 kommt. Anschließend erfolgen einige Host-Anfragen
aus völlig anderen Bereichen des Internet. Diese oder benachbarte Adressen finden wir im Mail-Log als offene
Proxies, die verzweifelt versuchen, Spam einzuliefern:
Apr 25
15:33:11
annie postfix/smtpd[12154]: 5F4D61F2: reject: RCPT from 216.114.194.21.hickorytech.net[
216.114.194.21
]: 550 Service unavailable; Client host [216.114.194.21] blocked using xbl.spamhaus.org; ht
> proto=SMTP helo=<yahoo.com>
Apr 25
15:42:43
annie postfix/smtpd[12135]: CEA7E1FB: reject: RCPT from ptr-66-225-137-161.ptr.terago.ca[
66.225.137.161
]: 550 Service unavailable; Client host [66.225.137.161] blocked using client.dnsbl.docsnyd
Apr 25
15:53:52
annie postfix/smtpd[12462]: 4AFC11F3: reject: RCPT from cap002-245.kcn.ne.jp[
61.86.33.245
]: 550 Service unavailable; Client host [61.86.33.245] blocked using xbl.spamhaus.org; http
Schön zu sehen sind das konstante HELO yahoo.com “ (die offiziellen Yahoo-Mailserver benutzen ande”
re HELOs) sowie das teilkonstante From sofortverlosung[a-z]*@yahoo.com <mailto:sofortverlosung*@
”
yahoo.com> “, wodurch ein schnell reagierender Administrator mit zwei Filterregeln (doppelt hält besser)
den ganzen Spam-Lauf abwehren kann.
Proxyserver sind bekanntlich dafür geschaffen worden, um Zugriffe auf WWW-Seiten zu beschleunigen.
Für Direktverbindungen zwischen Browser und Server, beispielsweise um per SSL-Verschlüsselung sensible
Daten zu übertragen, kann der Proxy außerdem TCP-Netzwerkverbindungen tunneln“ - je nach Konfigura”
tion nicht nur zu sicheren Webangeboten, sondern auch zu beliebigen anderen Netzwerdiensten, etwa Port 25
für SMTP. Dies missbraucht der Spammer, um unerkannt Spam zustellen zu können.
Der Proxy weiß jedoch nicht, wie E-Mail-Zustellung funktioniert, da er nur die reine Verbindung weiterleitet. Er besitzt keine Funktionalität, um per MX-Request den für einen Empfänger zuständigen Mailserver zu
erfragen.
Deshalb bleibt dem Spammer nichts Anderes übrig, als seinen eigenen DNS oder den seines Providers nach
MX-Informationen seiner Opfer zu befragen, der sich seinerseits an den Nameserver des Opfers wendet. Dort
ist diese Anfrage im DNS-Log zu sehen.
Wenn man viel Glück hat, benutzt der Spammer für seine beworbene WWW-Infrastruktur einen Server,
dessen IP-Adresse in unmittelbarer Nähe der Herkunft der MX-Anfragen liegt oder sogar damit identisch ist.
Dieser konkrete Spammer betrieb zum Zeitpunkt der Zustellung unter 66.98.15.145 nicht nur seinen Nameserver, sondern auch eine Datenbank, was ein überlastetes Bestellskript auf dem beworbenen WWW-Site verriet.
5.5
DNS-Views trennen den Spammer vom offenen Proxy
Verfolgt man DNS- und MTA-Logs während mehrerer Spam-Zustellungen, stellt man schnell fest, dass relativ
wenige Spammer für eine große Menge an Spam-Mails verantwortlich sind. Da BIND 9 die Möglichkeit bietet,
mittels Views“ Teilen des Internet unterschiedliche Informationen zu liefern, kann man den Spammer vom
”
offenen Proxy trennen und damit die Spam-Zustellung vereiteln.
Dazu definiert man zwei Views: blackhat“ für Netzbereiche, aus denen häufig MX-Anfragen für Spam”
Zustellungen kommen, und whitehat“ für das restliche Internet. Als zuständige Mailserver hinterlegt man
”
Hostnamen, die nur von derselben View aus in eine IP-Adresse aufgelöst werden können. Erfolgen MX- und
Host-Anfrage aus unterschiedlichen Views, so bekommt der offene Proxy keine IP-Adresse des Opfers und
findet dessen Mailserver nicht.
In der Konfigurationsdatei /etc/bind/named.conf “ teilen wir das Internet in zwei Views auf:
”
acl blackhat {
// Beispiele fuer Netze, in denen sich oft Spammer tummeln
200.46.208.0/25;
66.98.0.0/18;
168.95.0.0/16;
};
view "blackhat" {
match-clients { blackhat; };
include "rootzones.conf";
zone \glqq{}expires-200412.docsnyder.de\grqq{} {
type master;
file "master/for/sub.docsnyder.de.blackhat";
notify no;
};
};
view "default" {
match-clients { any; };
include "rootzones.conf";
zone \glqq{}expires-200412.docsnyder.de\grqq{} {
type master;
file "master/for/sub.docsnyder.de.whitehat";
notify no;
};
};
Um den beiden Views unterschiedliche Informationen zuzuordnen, sind separate Zonendefinitionen nötig.
Als Mail-Exchange (MX) weisen wir Subdomains der View whitehat “ den Hostnamen mail-from-whitehats “
”
”
zu:
; /etc/bind/master/for/sub.docsnyder.de.whitehat
;
$TTL
86400
@
IN
SOA
docsnyder.de.
hostmaster.docsnyder.de. (
2004040200
; Serial
2H
; Refresh
1H
; Retry
1D
; Expire
8H )
; Negative Cache TTL
;
@
IN
NS
ns1.docsnyder.de.
;
@
IN
MX
10
mail-from-whitehats
;
mail-from-whitehats
IN
A
213.239.199.73
Subdomains der View blackhat “ bekommen als MX den Hostnamen mail-from-blackhats “ zugewiesen.
”
”
Die jeweiligen MX-Hosts der anderen Views bleiben unbelegt und können deshalb nicht von Clients außerhalb
ihrer View in IP-Adressen aufgelöst werden:
; /etc/bind/master/for/sub.docsnyder.de.blackhat
;
$TTL
86400
@
IN
SOA
docsnyder.de.
hostmaster.docsnyder.de. (
2004040200
; Serial
2H
; Refresh
1H
; Retry
1D
; Expire
8H )
; Negative Cache TTL
;
@
IN
NS
ns1.docsnyder.de.
;
@
IN
MX
10
mail-from-blackhats
;
mail-from-blackhats
IN
A
213.239.199.73
Im DNS-Zugriffsprotokoll ist die Verzweiflung eines Spammers, einen zustellfähigen offenen Proxy zu
finden, deutlich zu erkennen:
Mar 26 21:52:47.875 client
200.46.208.3
#53: query:
IN
MX
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
26
26
26
26
26
26
26
26
26
26
26
26
26
26
26
26
26
26
26
26
26
21:52:49.082
21:57:11.364
22:00:47.488
22:01:24.531
22:01:33.582
22:01:51.751
22:02:46.104
22:03:28.760
22:03:28.827
22:04:08.838
22:05:37.823
22:05:39.650
22:06:45.013
22:23:20.938
22:48:59.994
22:49:02.307
23:11:45.326
23:13:30.705
23:14:33.391
23:15:07.759
23:20:31.489
client
client
client
client
client
client
client
client
client
client
client
client
client
client
client
client
client
client
client
client
client
68.113.206.10#53: query: blackhat.spamtrap.docsnyder.de IN A
Mit der Anzahl der Views sollte man sich zurückhalten, vor allem bei DNS-Installationen, die recht viele
Domains und Subdomains verwalten. Jede zusätzliche View vergrößert den Hauptspeicherverbrauch deutlich.
6
Zusammenfassung
Der Betrieb eines eigenen Internetservers erfordert ein großes Maß an Verantwortung und Kompetenz, ermöglicht
jedoch wirkungsvolle Abwehrmaßnahmen gegen das immer stärker zunehmende Spam-Problem.
Der Kampf gegen Spam ist und bleibt jedoch ein Katz-und-Maus-Spiel, da nicht nur Empfänger, sondern
auch Spammer immer tiefer in die Trickkiste greifen. Die langfristige wirkungsvollste Waffe gegen Spam ist
jedoch immer noch ein schnell reagierender Administrator, der seine E-Mail-Infrastruktur vor Missbrauch
schützt und die Wirkung aktueller Spam-Tricks in ihr Gegenteil verkehrt.
Neben den weit verbreiteten Maßnahmen auf SMTP-Ebene sowie inhaltsbasierten Filtermethoden kann
viel Spam bereits abgewehrt werden, bevor der Spammer den Server des Opfers überhaupt kontaktieren kann,
da er ihn gar nicht findet. Spam-Prävention und -Bekämpfung auf DNS-Ebene ist gegenwärtig noch wenig
verbreitet und deshalb sehr effektiv.
Am meisten empfehlenswert ist eine Kombination möglichst vieler unterschiedlicher Spam-Abwehrmaßnahmen,
selbst solcher mit begrenzter Wirkung. Diese decken in der Summe eine große Bandbreite an typischen SpamMerkmalen ab und ermöglichen deshalb gute Filterquoten.

Serverseitige Maßnahmen zur Bek¨ampfung von E-Mail-Spam

Transcrição

Documentos relacionados

Strategien gegen Spam

Spam - LUG Erding

10 Tricks, mit denen Spammer arbeiten

Download: Badereise an Spaniens Costa Brava

wintipps 09/2009 - luck

61 Montage- und Entriegelungsschlüssel MC4 und

7. Übung

Intelligente Antennen-Arrays optimieren 802.11n - Horus-Net

Rechnernetze Referat: eDonkey2000

PCtipp 05/2004 - Internet. Werbemails (S. 26-31)

Praktikum IT-Sicherheit 241 die von der Umstellung betroffenen