Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

<1997/09/15> Teergruben FAQ [German]

0 views
Skip to first unread message

Lutz Donnerhacke

unread,
Sep 15, 1997, 3:00:00 AM9/15/97
to

Archive-name: net-abuse-faq/teergrube-german-faq
Last-modified: 1997/09/15
Posting-Frequency: monthly
URL: http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.html
Version: 0.8


[1]Zurück [2]English version

Teergruben FAQ

_Was braucht der UBE Sender? Was verkauft er?_
Eine bestimmte Anzahl versendeter E-Mails pro Zeiteinheit. Das
ganze Produkt nennt er dann Unsolicited Bulk E-Mail
(Unverlangte Massen E-Mail).

_Wie kann man einem UBE Sender schaden?_
Indem man ihm seine Arbeitsmittel zerstört.

_Bitte?_
E-Mail Versand erfolgt über SMTP. Dabei wird eine TCP/IP
Verbindung zum MX Host des betreffenden Empfängers hergestellt.
Üblicherweise kann ein Rechner max. 65500 TCP/IP Verbindung
gleichzeitig offenhalten, in der Regel sind es weniger
(Ressourcenlimit, z.B. MAX_SOCKET, MAX_FILE_DESCRIPTOR).

Wenn es gelingt, einen Port bei der Mailauslieferung offen zu
halten, bspw. über mehrere Stunden, so reduziert sich die
Leistungsfähigkeit des UBE Senders. SMTP bietet dazu die
Fortsetzungszeilen, mit denen die SMTP Session offengehalten
werden kann, ohne daß ein Timeout zuschlägt.

Was eine Teergrube nun macht, ist einen genauso präparierten
MTA dazu zu bewegen, daß er eben (in Abhängigkeit vom
SMTP-Absender) den Prozeß auflaufen läßt.

_Wie sehen Fortsetzungszeilen des SMTP aus?_
Ein SMTP Host sendet als Antwort auf die Kommandos des Clients
Zeilen, die aus einem Fehlercode, einem Leerzeichen und einem
menschenlesbaren Text bestehen. Wird das Leerzeichen durch ein
Minuszeichen ersetzt, so bedeutet das, daß der Host noch nicht
mit der Antwort fertig ist. Das ganze kann dann so aussehen:

_help_
214-This is Sendmail version 8.8.5
214-Topics:
214- HELO EHLO MAIL RCPT DATA
214- RSET NOOP QUIT HELP VRFY
214- EXPN VERB ETRN DSN
214-For more info use "HELP <topic>".
214-To report bugs in the implementation send email to
214- sendma...@sendmail.org.
214-For local information send email to Postmaster at your site.
214 End of HELP info

Sendet man nun derartige Fortsetzungszeilen im Abstand von
Minuten, so verbraucht das fast keine Bandbreite und stoppt des
UBE Versenderhost wirksam.

_Wer hatte den zuerst diese Idee?_
In <54csin$m...@white.koehntopp.de> schreibt Kristian Köhntopp
die Idee Axel Zinser zu. Er erwähnt dort auch den nützlichen
Nebeneffekt, daß viele MTAs den kompletten SMTP Dialog
mitloggen, also bei Teergruben Gigabyte an Log zu verwalten
haben.

_Was ist, wenn der UBE Sender nun andere Hosts zum relay benutzt?_
Dann zieht es diesen mißbrauchten Relayhost zu. Der
entsprechende Admin bemerkt die Funktionsunfähigkeit seines
Systems und macht es so dicht, wie notwendig. Er hatte es ja
sowieso falsch konfiguriert...

_Wenn nun UBE-Sender das erkennen und keine UBE mehr an diese
Teergruben versenden, damit ihre Maschine freibleibt zum
weiterspammen?_
Think about it. Das war das Ziel: Mailauslieferung ist möglich,
UBE nicht.

_Wie erkennt eine Teergrube, daß am anderen Ende ein Spammer sitzt?_
Es müssen IP Bereiche definiert werden, aus denen der Spam
kommt. Beispielsweise ist der AGIS (All you Get Is Spam = Apex
Global Information Systems/Service) die IP-Bereiche
204.137.128/18, 204.137.192/19, 205.137.48/18, 205.164.64/17,
205.254.160/22, 205.254.176/21, 207.142/16, 209.14/16
zugewiesen worden.

Beim Verbindungsaufbau erhält er sofort die IP Nummer der
Gegenstelle.

_Wie bekommt man die IP Bereiche heraus?_
Im Falle von AGIS: 'whois NETBLK-AGIS...' Analog für die
anderen Spammer.

_Wie verhindert man, daß sie auch normale Mailer, die einen erreichen
wollen, schädigt?_
Wird ein normaler Mailer zufällig mit von der Teergrube
erwischt, so ist das in der Regel nicht weiter dramatisch, da
es auf beiden Systemen nur einen Port zuzieht. Die
Mailauslieferung erfolgt in jedem Fall, nur dauert es länger
als üblich.

_Muß die Teergrube auch viele Sockets offenhalten?_
Sie benötigt ein bis zehn Ports. Der Spammer dagegen für jede
Teergrube ein bis zehn. Der Vorteil der Verteidiger liegt ihn
ihrer Dezentralität. Beim Spammer läuft es zentral auf. Je mehr
Teergruben, desto besser.

_Was ist, wenn der UBE Sender seinerseits über hunderte von Maschinen
verfügt? Jede mit 65000 Ports. Oder über bulk-mail-Software mit
spezial TCP-Stacks die diese Obergrenze nicht kennen (Virtuelle
Interfaces pp.)?_
Dann muß der Spammer auch für diesen Aufwand zahlen. Die Frage
ist dann nur noch wer zuerst aufgibt: Der Spammer mit
Technikeinkauf oder die vielen Admins mit
Softwareinstallationen.

Ob das bisschen Knete, dass er mit UBE machen kann diese
Hardware, deren Anschluss und Unterhaltung wiedereinbringt?

Die Nutzung von Wegwerf-Einwähl-Accounts für Spammer ist auch
ausgeschlossen. Man kann den ISP anrufen und ihm sagen: "Ihr
Kunde auf Leitung ... spammt gerade. Bitte klemmen Sie ihn ab
und verklagen Sie ihn. Danke."

_Was ist, wenn der UBE Sender seinerseits auf meiner Machine alle
verfügbaren ports aufmacht (und damit meine mail Versorgung
zu?)?_
Alles, was er tun kann, ist Dir den Mailport 25 zu belegen, bis
Deine sonstigen Ressourcen aufgebraucht sind. Mit einem
non-forking Mailer dauert das sehr lange. Es ist sehr
unwahrscheinlich, daß ein Spammer Zeit und Ressource für diese
Art der "Rache" aufbringt.

Darüberhinaus kann man ihn auf diese Aktion verklagen.

_Ist es nicht paradox, eine Netzanbindung künstlich langsamer machen
zu müssen, damit sie nutzbar bleibt?_
Ja. Aber es hilft.

_Das klingt kompliziert, warum kann man die UBE-Spammer nicht einfach
abweisen?_
Einige hundert Teergruben machen das Versenden von UBE weltweit
schwierig bis unmöglich, ohne den normalen E-Mail Transport zu
gefährden. Es kann ja sein, daß bei einem spammerfreundlichen
Provider (z.B. AGIS) auch normale Menschen angeschlossen sind,
zu denen Kontakte bestehen sollen! Blockt man komplett,
verhindert man Kommunikation komplett. Das ist unerwünscht.

Abgesehen davon kann ein Blocking zwar den Anweder des
Blockings schützen, jedoch hilft es den anderen Netzbewohnern
nicht im geringsten. Es ist ein Selbstschutz jedoch kein echter
UBE-Schutz.

_Was muß man sein, um Teergruben laufen zu lassen? Postmaster?_
Admin auf der Maschine, die den MX Host fährt. Ist man das
nicht, so sollte man den betreffenden Admin kontaktieren.

_Wo gibt's fertige Teergruben?_
[3]http://www.de.spam.abuse.net/webland/spam/ und insbesondere
Axel Zinsers eigener Patch auf
[4]ftp://ftp.hiss.han.de/pub/sendmail/. Für Systeme, die
definitiv keine Post empfangen können, eignet sich ein
[5]Perl-Script der Boston Business Computing.

Bei [6]mir gibt es einen allgemeinen [7]Wrapper für beliebige
MTAs. Großes Umkonfigurieren entfällt.

_Wieviele Teergruben gibt es schon und werden diese irgendwo gelistet?_

Unbekannt. Wer mag kann sich melden.

_Gibt es Erfahungen mit Teergruben?_
Axel hat einen Spammer für mehr als zwei Tage online gehalten.
Ich habe ähnliche Resultate.

_Geht das auch mit Usenet News via NNTP?_
Nein. Usenet News werden ausschließlich über Verbindungen
zwischen gegenseitig bekannten Nachbarn ausgetauscht. Wollte
man Spam auf diese Art und Weise teergruben, so würde es die
gutnachbarschaftlichen Beziehungen zerstören, ohne den
Injektionspunkt, den Spammer, überhaupt zu treffen.

_Wie heißt eigentlich das englische Verb für diese Technik?_
To teergrube. Ie: My host is teergrubing UBE from or via AGIS.

References

1. http://www.iks-jena.de/mitarb/lutz/usenet/
2. http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html
3. http://www.de.spam.abuse.net/webland/spam/
4. ftp://ftp.hiss.han.de/pub/sendmail/
5. ftp://ftp.iks-jena.de/pub/mitarb/lutz/teergrube/dead.end.pl
6. mailto:lu...@iks-jena.de
7. http://www.iks-jena.de/mitarb/lutz/usenet/antispam.html

0 new messages