Tarpit

Eine Teergrube (engl. Tarpit, dt. auch Teerfalle) stellt ein Verfahren dar, mit dem unerwünschte Netzwerkverbindungen künstlich verlangsamt werden und der Verbindungspartner möglichst lange blockiert wird. Teergruben kommen vor allem im Bereich der Spam- und Wurm-Bekämpfung zum Einsatz. Teergruben können prinzipiell auf jeder Schicht des OSI-Modells implementiert werden. Typisch sind Teergruben auf der IP-, TCP- und der Anwendungs-Schicht.

Funktionsprinzip

Der Client baut eine Verbindung zum Server auf, die dieser entgegen nimmt. Die Verbindung wird vom Server jedoch massiv verzögert bearbeitet, die Antwortdaten tröpfeln nur sehr langsam über die Leitung. Der Client muss laufend auf die Antwort des Servers warten, wodurch er theoretisch beliebig lange die Verbindung zum Server aufrechterhalten muss. Diese Verzögerung kann auf niedrigeren Schichten des Netzes, zum Beispiel IP oder TCP realisiert werden – oder auf Anwendungsebene.

IP-Teergruben

IP-Teergruben nutzen die Möglichkeiten auf IP-Level. Das heißt, sie reduzieren die Paketgröße auf ein Minimum und senden die Pakete sehr langsam aus.

TCP-Teergruben

TCP-Teergruben setzen eine Schicht höher auf dem Netzwerkstack ein, arbeiten aber im Prinzip mit den gleichen Techniken wie IP-Teergruben. Auch sie minimieren die Paketgröße, vergessen Antwortpakete, melden Verbindungsfehler etc.

Beispiele

Eine bekannte Implementierung davon ist „LaBrea“, welches ein ganzes Netzwerk mit einem einzigen Teergruben-Dienst schützen kann.

Der Teergruben-Computer lauscht auf unbeantwortete ARP-Requests (normalerweise eine unbenutzte Adresse) und beantwortet Anfragen an diese, das heißt er täuscht vor, die gesuchte IP-Adresse zu besitzen. Wenn er daraufhin das initialisierende SYN-Paket des Angreifers (häufig ein Portscanner) erhält, sendet er nur noch eine SYN/ACK-Antwort, danach nichts mehr. Für diese Verbindung wird kein Socket geöffnet und keine „echte“ Verbindung eingerichtet. Die Teergrube speichert keine Daten der Verbindung nach dem gesendeten SYN/ACK. Somit braucht die Teergrube keinerlei eigene Ressourcen wie Rechenzeit, Sockets, Speicher oder Netzwerkbandbreite.

Der Computer der Remote-Seite (der „Angreifer“) sendet daraufhin sein ACK-Paket, um den für den Verbindungsaufbau nötigen 3-way-handshake abzuschließen. Schon dieses Paket wird von der Teergrube ignoriert, da aus Sicht des „Angreifers“ bereits eine etablierte Verbindung vorliegt. Er beginnt seine Daten zu senden, die jedoch niemanden erreichen.

Da im TCP eine Bestätigung für jedes Paket vorgesehen ist, wird die Verbindung in der Regel nach einer Zeit durch ein Timeout unterbrochen. Bis dahin verharrt die sendende Maschine jedoch in einem Zustand, der darauf ausgelegt ist, die Verbindung zu einem potentiellen tatsächlichen Kommunikationspartner nach aller Möglichkeit aufrechtzuerhalten. Diese Kommunikation kostet Zeit und Rechenleistung, je nach Art des Netzwerkstacks (Anzahl der Wiederholungen, back-off, retransmit usw.) oft sogar sehr viel.

Neuere Versionen von LaBrea sind um die Fähigkeit erweitert, später noch auf solche eingehende Pakete mit unsinnigen Antworten zu reagieren. Dafür werden Rohdaten (RAW IP packets) verwendet, damit keine Sockets oder andere Ressourcen des Teergrubenservers verwendet werden. Diese Pakete bringen den sendenden Server dazu, die Verbindung aufrechtzuerhalten und so wiederum noch mehr Zeit und Rechenleistung sinnlos zu verschwenden.

Neben LaBrea gibt es zahlreiche weitere TCP-Teergruben, wie zum Beispiel TCP-Damping.

Application-Level-Teergruben

Teergruben auf der Anwendungsebene nutzen Möglichkeiten des Anwendungsprotokolls, um eine Verbindung künstlich zu verlangsamen. Das reicht wiederum von der Simulation verlorengegangener Anfragen über Fehlerstatus bis hin zu besonders ausführlichen, aber sinnlosen Antworten.

Gegen Spam kommen vor allem SMTP und HTTP-Teergruben zum Einsatz.

SMTP-Teergruben

Das Funktionsprinzip der E-Mail-Teergrube beruht darauf, dass SMTP-Sitzungen künstlich verlangsamt oder verzögert werden, indem beispielsweise kleine Verzögerungen in den SMTP-Handshake eingebaut werden, wodurch Massenspam-versendende Mailserver blockiert werden sollen.

Zudem werden sogenannte SMTP-Continuation-Lines in die Antworten des Servers eingefügt. Diese Continuation-Lines ermöglichen es dem Server, eine mehrzeilige Antwort zurückzugeben, die der Client abwarten muss. Ähnlich wie bei einem Gespräch, in dem man dem Gegenüber eine konkrete Frage stellt, der aber lange und breit um den heißen Brei herumredet, um dann nach einer Stunde auf den Punkt zu kommen.

Bei normalem Mailverkehr führt diese Verzögerung je nach Implementation und Aggressivität der Teergrube zu keinen größeren Einschränkungen. Werden jedoch sehr viele Mails gleichzeitig von einem Server aus verschickt, wie das bei E-Mail-Spam meist der Fall ist, wird der sendende Mailserver blockiert. Die Anzahl der TCP/IP-Sitzungen, die er gleichzeitig bearbeiten kann, ist begrenzt. So kann er, wenn alle verfügbaren Sitzungen in einer Teergrube festsitzen, erst weitere Mails versenden, wenn eine der offenen Sitzungen abgeschlossen oder abgebrochen wird.

Eine weitere Wirkungsweise besteht darin, dass Viren und auf Spam-Versand optimierte Server den Versand häufig selbst bei kurzen Verzögerungen abbrechen, ohne später einen neuen Versuch zu starten. Damit lassen sich solche Sender durch den Einsatz von Teergruben oder unperformanter Server ausbremsen. Die Teergrube blockiert hier zwar nicht den sendenden Server, schützt aber den Empfänger vor E-Mail-Spam und Malware.

Genau das macht jedoch die Teergrube ziemlich unwirtschaftlich: Spammer beenden die Verbindung sofort, normale Versender werden gefangen genommen. Das ist gerade nicht der gewünschte Effekt. Der OpenBSD spamd implementiert zum Beispiel Whitelisting und Greylisting, um Spammer zu identifizieren und anständige Versender zu schützen.

In der Vergangenheit wurde oft auch eine Ersparnis von Traffic als Argument angeführt, was aber, da die Volumenkosten ständig sinken und die Größe der normalen Mails wie auch die Bandbreite ständig steigen, immer weniger ins Gewicht fällt.

Große Provider und Newsletter-Versender werden mit einer solchen klassischen Teergrube ebenfalls blockiert, weshalb dieses Verfahren dort nicht gerne gesehen wird. Entschärft wird dieses Problem, indem man nur SMTP-Sitzungen von suspekten Hosts (vgl. RBL) dem tarpitting unterwirft und evtl. zusätzlich eine Whitelist für große Provider pflegt.

HTTP-Teergruben

HTTP-Teergruben versuchen Spammer eine Ebene früher aus der Bahn zu werfen, indem sie die Harvester der Spammer blockieren. Harvester sind Programme, die wie Spider von Suchmaschinen, zum Beispiel der Googlebot, Webseiten durchsuchen – jedoch nicht nach Suchbegriffen, sondern nach E-Mail-Adressen potentieller Spamopfer.

Diese Art Teergruben liefert Webseiten deutlich verlangsamt aus und verpackt auf den generierten Webseiten zahlreiche Links auf sich selber, so dass der Harvester immer wieder in die Falle tappt.

Literatur

• Tobias Eggendorfer: No Spam. Besser vorbeugen als heilen, Software und Support Verlag, Frankfurt am Main, 2005, ISBN 393504271X – stellt eine HTTP-Teergrube in PHP vor
• Tobias Eggendorfer: Comparing SMTP and HTTP tar pits in their efficiency as an anti-spam measure, Proceedings of M.I.T. SpamConference 2006
• Tobias Eggendorfer: Ernte nein danke. E-Mail-Adressenjägern auf Webseiten eine Falle stellen in: Linux Magazin 06/2004, S. 108 ff, Linux New Media, München HTML-Version
• Tobias Eggendorfer: Stopping Spammers' Harvesters using a HTTP tar pit, Proceedings of AUUG 2005, Sydney, 2005
• Tobias Eggendorfer: Rechtliche Zulässigkeit des Einsatzes von Teerfallen zur Blockade von Harvestern, Proceedings of DGRI Herbstakademie 2005, Freiburg, 2005
• Li Kang: Resisting Spam-Delivery by TCP-Damping, University of Georgia, Athens, GA, o. A.

Weblinks

• http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.html Teergruben-FAQ