Teergrube (Informationstechnik)

Der Client baut eine Verbindung zum Server auf, die dieser entgegennimmt. 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, oder auf Anwendungsebene realisiert werden.

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

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.

Eine bekannte Implementierung davon ist „LaBrea“ (zur Namensgebung siehe hier), 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, d. h., 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 Drei-Wege-Handschlag abzuschließen. Schon dieses Paket wird von der Teergrube ignoriert. Da aus Sicht des „Angreifers“ nun eine etablierte Verbindung vorliegt, beginnt er, 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 eingehenden 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.

Der Linux-Paketfilter netfilter kann TCP-Verbindungen ohne zusätzliche Userspace-Software in eine Teergrube laufen lassen.
Das Target tarpit akzeptiert neue TCP-Verbindungen und setzt sie direkt in den persist-state. Durch die resultierende Fenstergröße von 0 wird es dem „Angreifer“ nicht erlaubt, Daten zu senden. Damit wird er gezwungen, alle 60 bis 240 Sekunden die Fenstergröße erneut abzufragen.
Des Weiteren werden Versuche des „Angreifers“, die Verbindung zu schließen, ignoriert, wodurch ein Auslaufen der Verbindung erzwungen wird. Dies dauert zwischen 12 und 24 Minuten. In dieser Zeit bleiben die verwendeten Ressourcen beim „Angreifer“ belegt.

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.

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-Handschlag 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, dieser aber erst nach einer Stunde Redens auf den Punkt kommt.

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-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 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 (z. B. 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.

• Honeypot

• 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: Rechtliche Zulässigkeit des Einsatzes von Teerfallen zur Blockade von Harvestern, Proceedings of DGRI Herbstakademie 2005, Freiburg, 2005
• Tobias Eggendorfer: Stopping Spammers' Harvesters using a HTTP tar pit, Proceedings of AUUG 2005, Sydney, 2005
• Tobias Eggendorfer: No Spam. Besser vorbeugen als heilen, Software und Support Verlag, Frankfurt am Main, 2005, ISBN 3-935042-71-X – 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
• Li Kang: Resisting Spam-Delivery by TCP-Damping, University of Georgia, Athens, GA, o. A.

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