Open Source im professionellen Einsatz

E-Mail-Adressenjägern auf Webseiten eine Falle stellen

Ernte - nein danke

Tobias Eggendorfer

Spammer ernten die Mailadressen ihrer Opfer am liebsten von Webseiten. Ziel sollte also sein, diese Harvester lahm zu legen. Das hier beschriebene PHP-Skript lässt die Spammer in eine Falle tappen und zeigt dabei, wie in PHP die Interprozesskommunikation über Semaphore funktioniert.

Spam ist lästig, kostet Bandbreite und Zeit und stört die Kommunikation. Wer nicht erst auf den elektronischen Briefmüll warten will, um ihn dann mühsam auszusortieren, bekämpft das Übel schon bei der Entstehung. Zum Beispiel indem er Mailadressen auf seiner Homepage so tarnt[2], dass die Spammer mit ihren automatischen Sammelprogrammen[1] sie glatt übersehen. Website-Betreiber können diese Spider, Roboter oder Harvester genannten Programme zusätzlich ärgern und sie in Teergruben festsetzen (siehe Kasten "Teergruben und Honigtöpfe").

Teergruben und Honigtöpfe
Honigtöpfe und Teergruben sind das Internet-Pendant zu mit Bier gefüllten Schalen in zahllosen Schrebergärten: Sie dienen als Falle für unerwünschte Gäste. Spammer, Cracker und ähnliches Gesindel bleiben kleben und sind aus dem Verkehr gezogen. Beide Begriffe werden heute meist synonym verwendet. Ursprünglich sollten Honeypots Angreifer anlocken, um sie zu beobachten und zu erforschen. In Teergruben soll das virtuelle Ungeziefer dagegen stecken bleiben, ähnlich den Schnecken in den Bierschalen der Hobbygärtner. Viele Anwendungen für das Funktionsprinzip Die Begriffe bezeichnen nur ein Funktionsprinzip und keine konkrete Umsetzung. Beispielsweise untersucht Richard Stevens[7] Honeypots als Ergänzung für Netzwerk-basierte Intrusion Detection Systeme (NIDS), etwa Snort. Lutz Donnerhacke[8] verwendet ähnlich wie Daniel Rehbein[9] eine Teergrube, um den Versand von Spam zu erschweren. Der vorliegende Artikel zeigt, wie eine Teerfalle die Harvester von Spammern in die Irre führt. Ein Honeypot wirkt auf Angreifer einladend, wenn viele Ports offen stehen und ältere Softwareversionen installiert sind. Damit stehen zahlreiche Sicherheitslöcher mit bekannten Exploits zur Auswahl. Dies simuliert der Honeypot nur und stellt sicher, dass er nicht als solcher erkennbar ist. Der Übeltäter weiß nicht, dass er einen Honigtopf vor sich hat, und versucht das Zielsystem zu kompromittieren. Aus seinen Aktionen lernen die Admins für die Abwehr künftiger Attacken[10]. Honeyd simuliert 65000 Systeme Honeyd[11] kann verschiedene Systeme simulieren, indem er die passenden Serverantworten gibt und die TCP-Fingerprints imitiert. Honeyd muss in einem Netz mit öffentlichen IP-Adressen laufen, nur so kann der Daemon mehrere Systeme realistisch simulieren. Er erhält meist alle im Netzbereich freien IP-Adressen. Das System soll in der Lage sein, mehr als 65000 verschiedene Computer auf einer Hardware zu simulieren. Legitime Clients haben mit den unbenutzten IP-Adressen nichts zu schaffen, daher ist jeder Zugriff auf den Honeyd verdächtig. Er könnte der Beginn eines bislang unbekannten Angriffs sein. Einer Gefahr setzt sich der Admin aber aus: Der Honeypot ist eventuell nicht völlig sicher, der Rechner könnte kompromittiert werden. Er darf daher nicht auf einem Produktivsystem laufen, sondern besser auf einem dedizierten Rechner. Forschungs-Honeypots stehen meist außerhalb der Firewall-Grenzen. Neben den Forschungssystemen etablieren sich auch Produktiv-Teerfallen. Sie verzögern bekannte Angriffe und schützen damit Dritte. Zum Beispiel bremst Labrea Tarpit[12] den Code-Red-Wurm. Labrea öffnet auf freien IP-Adressen den Port 80. Es setzt die maximale Größe der Datenpakete auf ein Minimum und antwortet nur verzögert, wenn überhaupt. So blockiert jede Teerfalleninstanz beim Gegenüber einen Port und bremst die Ausbreitungsgeschwindigkeit des Wurms. Produktiv-Honeypots als Schutzsystem Besonders trickreich geht Labrea vor, um freie IP-Adressen zu ermitteln: Es protokolliert alle ARP-Requests im Netzsegment (siehe Titelthema dieses Hefts). Bleibt ein ARP-Request unbeantwortet, nimmt Labrea an, dass keine Maschine die IP verwendet, und meldet sich selbst als Besitzer der Adresse. Auch Honeyd lässt sich zur Wurmkur nutzen. Laurent Oudot beschreibt[13], wie der Daemon den Msblast-Schädling bekämpft. Dass man Spammer auch beim Ausliefern ihres Mülls behindern kann, zeigt Daniel Rehbein[9]: Er nutzt einen präparierten Mailserver.

Teergruben und
Honigtöpfe

Honigtöpfe und Teergruben sind das Internet-Pendant zu mit Bier gefüllten Schalen in zahllosen Schrebergärten: Sie dienen als Falle für unerwünschte Gäste. Spammer, Cracker und ähnliches Gesindel bleiben kleben und sind aus dem Verkehr gezogen. Beide Begriffe werden heute meist synonym verwendet. Ursprünglich sollten Honeypots Angreifer anlocken, um sie zu beobachten und zu erforschen. In Teergruben soll das virtuelle Ungeziefer dagegen stecken bleiben, ähnlich den Schnecken in den Bierschalen der Hobbygärtner.

Viele Anwendungen für das Funktionsprinzip

Die Begriffe bezeichnen nur ein Funktionsprinzip und keine konkrete Umsetzung. Beispielsweise untersucht Richard Stevens[7] Honeypots als Ergänzung für Netzwerk-basierte Intrusion Detection Systeme (NIDS), etwa Snort. Lutz Donnerhacke[8] verwendet ähnlich wie Daniel Rehbein[9] eine Teergrube, um den Versand von Spam zu erschweren. Der vorliegende Artikel zeigt, wie eine Teerfalle die Harvester von Spammern in die Irre führt.

Ein Honeypot wirkt auf Angreifer einladend, wenn viele Ports offen stehen und ältere Softwareversionen installiert sind. Damit stehen zahlreiche Sicherheitslöcher mit bekannten Exploits zur Auswahl. Dies simuliert der Honeypot nur und stellt sicher, dass er nicht als solcher erkennbar ist. Der Übeltäter weiß nicht, dass er einen Honigtopf vor sich hat, und versucht das Zielsystem zu kompromittieren. Aus seinen Aktionen lernen die Admins für die Abwehr künftiger Attacken[10].

Honeyd simuliert 65000 Systeme

Honeyd[11] kann verschiedene Systeme simulieren, indem er die passenden Serverantworten gibt und die TCP-Fingerprints imitiert. Honeyd muss in einem Netz mit öffentlichen IP-Adressen laufen, nur so kann der Daemon mehrere Systeme realistisch simulieren. Er erhält meist alle im Netzbereich freien IP-Adressen. Das System soll in der Lage sein, mehr als 65000 verschiedene Computer auf einer Hardware zu simulieren. Legitime Clients haben mit den unbenutzten IP-Adressen nichts zu schaffen, daher ist jeder Zugriff auf den Honeyd verdächtig. Er könnte der Beginn eines bislang unbekannten Angriffs sein.

Einer Gefahr setzt sich der Admin aber aus: Der Honeypot ist eventuell nicht völlig sicher, der Rechner könnte kompromittiert werden. Er darf daher nicht auf einem Produktivsystem laufen, sondern besser auf einem dedizierten Rechner. Forschungs-Honeypots stehen meist außerhalb der Firewall-Grenzen.

Neben den Forschungssystemen etablieren sich auch Produktiv-Teerfallen. Sie verzögern bekannte Angriffe und schützen damit Dritte. Zum Beispiel bremst Labrea Tarpit[12] den Code-Red-Wurm. Labrea öffnet auf freien IP-Adressen den Port 80. Es setzt die maximale Größe der Datenpakete auf ein Minimum und antwortet nur verzögert, wenn überhaupt. So blockiert jede Teerfalleninstanz beim Gegenüber einen Port und bremst die Ausbreitungsgeschwindigkeit des Wurms.

Produktiv-Honeypots als Schutzsystem

Besonders trickreich geht Labrea vor, um freie IP-Adressen zu ermitteln: Es protokolliert alle ARP-Requests im Netzsegment (siehe Titelthema dieses Hefts). Bleibt ein ARP-Request unbeantwortet, nimmt Labrea an, dass keine Maschine die IP verwendet, und meldet sich selbst als Besitzer der Adresse.

Auch Honeyd lässt sich zur Wurmkur nutzen. Laurent Oudot beschreibt[13], wie der Daemon den Msblast-Schädling bekämpft. Dass man Spammer auch beim Ausliefern ihres Mülls behindern kann, zeigt Daniel Rehbein[9]: Er nutzt einen präparierten Mailserver.

Kostenkontrolle

Ziel ist es, die Sammelgeschwindigkeit zu reduzieren, um den Harvester zu bremsen. Es wäre auch möglich, die Kosten des Adressensammelns durch höheren Bandbreitebedarf zu steigern. Allerdings schädigt das den Falschen - den Betreiber der Website. Der E-Mail-Harvester sollte sich besser in einer Endlosschleife verfangen, die nur sehr langsam neue Daten ausliefert. Dabei muss die Webseite ständig neue Inhalte generieren, um den Spider zu täuschen und ihn möglichst lange zu binden.

Das lässt sich zum Beispiel per PHP-Skript erledigen. Es gibt eine HTML-Seite aus, die n-mal unter verschiedenen URLs auf sich selbst verweist und so eine Endlosschleife erzeugt. Dabei ist einiges zu beachten:

Anständige Spider (etwa Googlebot) sollen nicht in die
Falle tappen.
Die generierten Links (die wieder zum Skript führen)
dürfen sich nicht nur in ihren Parametern unterscheiden,
sondern müssen unterschiedliche Dateinamen tragen. Viele
Spider ignorieren Parameter, um sich nicht von Session-IDs in die
Irre führen zu lassen.
Der Server soll nicht unter der Last der gefangenen Harvester
zusammenbrechen.

Der letzte Punkt ist schwierig, denn es gilt, die Zahl der parallel laufenden Prozesse zu begrenzen. Apache bietet zwar ein solches Limit, nur gilt es für alle Serverinstanzen. Das Skript braucht aber eine eigene Grenze. In der »ps«-Ausgabe kann es nicht erkennen, wie oft es schon gelaufen ist: Der Interpreter ist in Apache eingebettet. Lockfiles[3] verwenden wäre zwar möglich, aber durch die Zugriffe auf das Dateisystem wenig performant und zudem fehleranfällig. Besser geeignet sind Semaphore[4]. Sie verhindern, dass zu viele parallele Prozesse gleichzeitig einen kritischen Abschnitt betreten.

Ein kritischer Abschnitt ist etwa der Zugriff auf den Drucker: Drucken zwei Prozesse gleichzeitig, wäre das Ergebnis ein Werk für die Tonne. Beim Drucken setzt Linux zwar auf komplexere Mechanismen (unter anderem Warteschlangen), jedoch illustriert diese Anwendung die Aufgabe von Semaphoren: Prozesse dürfen sich bei bestimmten Aktionen nicht gegenseitig stören.

Bitte warten

Als Markierung für den kritischen Abschnitt dienen die Dijkstra-Operationen P(s) und V(s). P(s) kennzeichnet den Beginn des Abschnitts (Prüfen), V(s) verlässt ihn, s bezeichnet den Semaphor.

P prüft, ob der Semaphor einen Wert größer null hat. Wenn ja, dekrementiert sie s und das Programm kann den kritischen Abschnitt betreten. Andernfalls wartet der Prozess, bis der Semaphor wieder einen Wert größer null annimmt. Analog inkrementiert V(s) den Semaphor um eins. Beide Operationen sind atomar, also nicht unterbrechbar.

Ein binärer Semaphor nimmt nur die Werte 0 und 1 an. Es gibt jedoch auch Semaphore mit einem beliebigen, positiv-ganzzahligen Ausgangswert n. Es können dann n Prozesse gleichzeitig den kritischen Abschnitt betreten - die Harvester-Falle setzt sich eine Obergrenze der parallel laufenden Instanzen. Das System kümmert sich um die Limits sowie um die Aufräumarbeiten: Sollte der Prozess, der den Semaphor hält, abstürzen, gibt Linux die Sperre wieder frei. Das ist ein großer Vorteil gegenüber Lockfiles, die stehen bleiben.