Tar pit (information technology)
A Teergrube (engl. Tarpit , dt. Also Teerfalle ) illustrates a method, be slowed artificially with the undesired network connections and the connection partner is blocked as long as possible. Tar pits are mainly used in the field of spam and worm control. In principle, tar pits can be implemented on any layer of the OSI model . Tar pits are typical on the IP , TCP and application layers .
Working principle
The client establishes a connection to the server , which the server accepts. The connection is processed by the server with massive delays, however, the response data trickle only very slowly over the line. The client has to constantly wait for the response from the server, which means that it has to maintain the connection to the server for as long as required. This delay can be implemented at lower layers of the network, for example IP or TCP, or at the application level.
IP tar pits
IP tar pits use the possibilities at IP level, i. that is, they keep the packet size to a minimum and send out the packets very slowly.
TCP tar pits
TCP tar pits operate one layer higher on the network stack, but basically work with the same techniques as IP tar pits. They also minimize the packet size, forget response packets, report connection errors, etc.
Examples
LaBrea
A well-known implementation of this is "LaBrea" (for naming see here ), which can protect an entire network with a single tar pit service.
The tar pit computer listens for unanswered ARP requests (usually an unused address) and answers queries to them, i. i.e., it pretends to have the IP address you are looking for. If he then receives the initializing SYN packet from the attacker (often a port scanner ), he only sends a SYN / ACK response, then nothing. No socket is opened for this connection and no "real" connection is established. The tar pit does not save any data of the connection after the SYN / ACK sent. The tar pit therefore does not need any of its own resources such as computing time, sockets, memory or network bandwidth.
The computer on the remote side (the “attacker”) then sends its ACK packet to complete the three-way handshake required to establish the connection . Even this package is ignored by the tar pit. Since the "attacker" now sees an established connection, he begins to send his data, which does not reach anyone.
Since a confirmation is provided for each packet in the TCP , the connection is usually interrupted after a certain period of time due to a timeout . Until then, however, the sending machine remains in a state that is designed to maintain the connection to a potential actual communication partner whenever possible. This communication costs time and computing power, depending on the type of network stack (number of repetitions, back-off, retransmit, etc.) often even a great deal.
Newer versions of LaBrea have been expanded to include the ability to later react to such incoming packets with nonsensical responses. Raw data ( RAW IP packets ) are used for this, so that no sockets or other resources of the tar pit server are used. These packets cause the sending server to maintain the connection and in turn waste even more time and computing power pointlessly.
In addition to LaBrea, there are numerous other TCP tar pits such as TCP damping.
netfilter
The Linux - packet filter netfilter can TCP connections without additional user space to run software in a tar pit.
The target tarpitaccepts new TCP connections and sets them directly in the persist state. The resulting window size of 0 means that the “attacker” is not allowed to send data. This forces him to query the window size again every 60 to 240 seconds.
Attempts by the “attacker” to close the connection are also ignored, which forces the connection to expire. This takes between 12 and 24 minutes. During this time, the resources used remain occupied by the "attacker".
Application level tar pits
Application-level tar pits use application protocol capabilities to artificially slow a connection. This in turn ranges from the simulation of lost inquiries and error status to particularly detailed but meaningless answers.
SMTP and HTTP tar pits are mainly used against spam.
SMTP tar pits
The working principle of the e-mail tar pit is based on the fact that SMTP sessions are artificially slowed down or delayed by, for example, adding small delays in the SMTP handshake, which are intended to block mail servers sending mass spam .
In addition, so-called SMTP continuation lines are inserted into the server's responses. These continuation lines enable the server to return a multi-line answer that the client has to wait for - similar to a conversation in which you ask the other person a specific question, but he only gets to the point after an hour of talking.
With normal mail traffic, this delay does not lead to any major restrictions, depending on the implementation and aggressiveness of the tar pit. However, if a large number of mails are sent from a server at the same time, as is usually the case with e-mail spam, the sending mail server is blocked. The number of TCP sessions that it can process simultaneously is limited. If all available sessions are stuck in a tar pit , he can only send further mails when one of the open sessions is closed or canceled.
Another way of working is that viruses and servers optimized for sending spam often abort the sending, even if there are short delays, without starting a new attempt later. This means that such transmitters can be slowed down through the use of tar pits or non-performing servers. The tar pit does not block the sending server, but protects the recipient from email spam and malware .
However, this is exactly what makes the tar pit quite uneconomical: Spammers terminate the connection immediately, normal senders are captured. That is just not the desired effect. The OpenBSD spamd implemented as whitelisting and greylisting to identify spammers and protect decent shipper.
In the past, a saving in traffic was often cited as an argument, but this is becoming less and less important since the volume costs are constantly falling and the size of normal mails as well as the bandwidth are constantly increasing.
Large providers and newsletter senders are also blocked with such a classic tar pit, which is why this method is not welcomed there. This problem is mitigated by only subjecting SMTP sessions from suspicious hosts (see RBL ) to tarpitting and possibly also maintaining a whitelist for large providers.
HTTP tar pits
HTTP tarpits try to knock spammers off the track one level earlier by blocking spammers' harvesters . Harvesters are programs that search web pages like spiders from search engines (e.g. Googlebot ) - but not for search terms, but for the e-mail addresses of potential spam victims.
This type of tar pits delivers websites much more slowly and packs numerous links to itself on the generated websites, so that the harvester falls into the trap again and again.
See also
literature
- Tobias Eggendorfer: Harvest no, thank you. Setting a trap for email address hunters on websites in: Linux-Magazin 06/2004, p. 108 ff, Linux New Media, Munich HTML version
- Tobias Eggendorfer: Legal admissibility of the use of tar traps to block harvesters , Proceedings of DGRI Autumn Academy 2005, Freiburg, 2005
- Tobias Eggendorfer: Stopping Spammers' Harvesters using a HTTP tar pit , Proceedings of AUUG 2005, Sydney, 2005
- Tobias Eggendorfer: No Spam. Better prevention than cure , Software and Support Verlag, Frankfurt am Main, 2005, ISBN 3-935042-71-X - introduces an HTTP tar pit in PHP
- Tobias Eggendorfer: Comparing SMTP and HTTP tar pits in their efficiency as an anti-spam measure , Proceedings of MIT SpamConference 2006
- Li Kang : Resisting Spam-Delivery by TCP-Damping , University of Georgia, Athens, GA, o.A.