PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Wie Spam-Programme arbeiten



Mambo
24.05.2006, 21:04
Aufgrund der beständigen Mutmaßungen in diesem Bereich (wie arbeiten die Bots), zur Abwechslung mal ein paar Fakten ...

1. Man erwirbt ein Script mit bereits vorgefertigter Datenbank, basierend auf den gängigsten Systemen (Forensoftware, Gästebücher).
Diese Datenbank enthält in der Regel:
- einige zehn-/hunderttausend Opfer (je nach Preis, 70-500 US$)
- Angaben der am häufigsten verbreiteten Systeme

2. Dieses Script läßt sich bspw. automatisiert ausführen (Cron, Daemon) und ermittelt ebenfalls über verschiedene Suchmaschinen (neue) Opfer.

3. Man hat die Möglichkeit eigene Ziele zu bestimmen. Hierzu ist die Analyse des Quellcodes (HTML) notwendig, um die Datenbank mit entsprechenden Parametern zu füllen (Scriptname, Referer ja/nein usw.). (Bedeutet also: irgendjemand setzt sich per Hand an ein noch unbekanntes Gästebuch/Forum und testet ein paar Mal bis es klappt. Dann ist das Ding in der Datenbank und wird ggf. bei Updates der an weitere Käufer der Software übermittelt).
Mit einer Toleranz von ca. 50% ist dieser Vorgang zudem automatisiert (anhand der gängisten Parameter: value=email, value=message, value=title usw. usf.). Die Parameter zwischen den <form></form>-Tags werden automatisch ausgelesen und man muss unbekannte nur noch den eigenen zuweisen.

4. Die Eintragungen erfolgen meist über Proxies, die der Verbindung vorgeschaltet werden (kann man an- oder abschalten). Angaben wie Refer, User-Agent usw. sind gefakt und können rotieren.
Die Daten über die Verbindung werden in aller Regel gespeichert (Return-Code, Datum, benutzter Proxy usw.).

---

Möglichkeiten gegen Spam

1. mod_security (Apache) installieren und vor allem auf die eigenen Bedürfnisse anpassen ! (Wer das heutzutage nicht hat, handelt mehr als grob fahrlässig !)
2. Das Script nicht von Suchmaschinen indexieren lassen.
3. ggf. einige Parameter umbennen / ändern
4. Keinen HTML-Code zulassen
5. Badwords
usw.

Ergebnis, zumindest bei uns (ein kleiner Gästebuch-Service mit etwa 600 aktiven Usern): vor 4-5 Wochen hatten wir mal wieder ein paar Versuche unser System aufzunehmen, aber ansonsten innerhalb von ca. 2 Jahren vielleicht 20 (automatisierte) Spams ...
Gegen das, was per Hand eingegeben wird, hilft eh nur Kontrolle (Badwords usw.), aber das ist ja recht übersichtlich und gehört aufgrund der bescheidenen Rechtsprechung ohnehin zur Pflicht eines jeden Gästebuch-/Forenanbieters.

heinerle
25.05.2006, 12:12
Super Beschreibung.

Das spricht auf jeden Fall dafür, einige Parameter im Skript zu verwenden, die Zeit- und/oder IP-abhängig sind. Dann können die Bots auf jeden Fall nicht mit einmal (von Hand) ausgelesenen vorgefertigten Variablen kommen, sondern müssen diese evtl. jedes Mal wieder neu auslesen. Und wenn man dann die Variablennamen selber noch variabel gestaltet oder sogar den Skriptnamen mit mod_rewrite abhängig von Clientparametern macht, dann dürfte nicht mehr viel durchkommen. :)

Mambo
25.05.2006, 15:11
Korrekt.

Es sollte eigentlich schon fast reichen die IP/Uhrzeit per MD5 zu verschlüsseln, als Session zu speichern und diesen Wert bei der Eintragung wieder abzufragen.
Wenn man diesen Wert nun auf "gastbuch.script" erzeugt und auf "eintragen.script" wieder abfragt und prüft, ist die Geschichte eigentlich in trockenen Tüchern.
(Oder noch einfacher: auf "gastbuch.script" den Wert eintragen=true erzeugen und auf "eintragen.script" abfragen, Ergebnis ist das gleiche).

Und das schönste: der Wert muss noch nicht einmal im <form>-Teil übergeben werden ... Die paar Leute, die dann nichts schreiben können (Stichwort Cookies), sollten unter "ferner liefen" fallen.

Wichtig ist eigentlich nur, daß man diesen Wert selbst bestimmt und/oder dieser explizit an die Server-Variable "Session" geknüpft ist.

heinerle
25.05.2006, 15:41
...Und das schönste: der Wert muss noch nicht einmal im <form>-Teil übergeben werden
Ich habe lieber ein paar mehr Variablen im <form>, da kann ich im Empfangsskript besser testen, ob da überall eMail-Adressen oder Links drinstehen und entsprechend reagieren. Und wenn die Felder hidden sind füllt die ja auch kein echter Benutzer falsch aus.


Die paar Leute, die dann nichts schreiben können (Stichwort Cookies), sollten unter "ferner liefen" fallen...
Würde ich so nicht behaupten. Ich bläue allen Leuten ein, Cookies abzuschalten oder zumindest auf "Nachfragen" zu stellen und nur wenn eine Seite überhaupt nicht funktioniert die Blockade für diese rauszunehmen.

Halte ich insbesondere im Zeitalter von ivwbox- und doubleclick-Schnüffelei für wichtig.

Mambo
26.05.2006, 13:28
Ich habe lieber ein paar mehr Variablen im <form>, da kann ich im Empfangsskript besser testen, ob da überall eMail-Adressen oder Links drinstehen und entsprechend reagieren. Und wenn die Felder hidden sind füllt die ja auch kein echter Benutzer falsch aus.

Das ist sicherlich richtig. Ohne etwas im <form>-Teil kommt man ja auch nicht aus ;-) Das sollte ohnehin durch die Prüfung gejagt werden, schon aus Gründen der Sicherheit (Stichwort Injection). Aber jeder so wie es ihm beliebt. ;-)



Würde ich so nicht behaupten. Ich bläue allen Leuten ein, Cookies abzuschalten oder zumindest auf "Nachfragen" zu stellen und nur wenn eine Seite überhaupt nicht funktioniert die Blockade für diese rauszunehmen.

Halte ich insbesondere im Zeitalter von ivwbox- und doubleclick-Schnüffelei für wichtig.
Naja, in Sachen Session-Cookies wäre/bin ich nicht ganz so restriktiv. Ansonsten, was dauerhafte Cookies anbelangt, sind wir durchaus einer Meinung.

Aber wie dem auch sei: es gibt auf jeden Fall relativ einfache Möglichkeiten, wie man dem (automatisierten) GB-/Foren-/Blog-Spam begegnen kann. Ich denke mal, daß der Interessierte sich da im Zweifelsfall eine individuelle Lösung zurechtbasteln kann, was ja ohnehin Sinn machen würde. Würde schließlich die Wahrscheinlichkeit minimieren, den Spammer die Sache zu einfach zu machen, indem die sich mit nur einer und überall identischen Sicherungsmaßnahme beschäftigen müssten.