Letztens hat Carlsen auf der bella-und-edward.de Seite einen iPod verlost. Es war ein einfaches Gewinnspiel; ein Formular mit einigen persönlichen Daten, inklusive E-Mail-Adresse, musste ausgefüllt werden und eine simple Frage beantwortet werden.

Die Teilnehmer wurden in einer csv-Datei gespeichert. Wir haben mit 1000 bis 2000 Mitspielern gerechnet, dabei aber die Rechnung ohne die Gewinnspiel-Meta-Seiten gemacht, die das Formular entdeckt und es ohne Rücksicht auf Verluste zugespammt haben. Irgendwann hatten wir 100.000 Einträge in der csv-Datei und mußten reagieren.

Nachdem wir einige Lösungsansätze diskutiert haben (Captchas, Referer untersuchen) haben wir uns für den Ansatz entschieden, Requests, die gehäuft von der selben IP-Adresse kommen, zu blocken. Captchas wären sicherlich auch ein guter Ansatz gewesen. Dass wir uns für den IP-Blocker entschieden haben, lag daran, dass wir einige Wochen vorher ein ähnliches Problem mit Bewertungsfunktionen hatten und wir hoffen, den IP-Blocker gegen beide Arten von Vigilanten einsetzen zu können.

Die Schwierigkeit, Requests von einer IP-Adresse zu loggen, lag natürlich darin, dass es sehr legitime Gründe dafür gibt, dass mehrere Requests von der selben IP-Adresse stammen können.

Einerseits können die IP-Adressen dynamischer IP-Pools häufiger auftauchen, da es zumindest theoretisch nicht ausgeschlossen ist, dass die IP-Adresse A einem Benutzer zugeordnet ist, der bei unserem Gewinnspiel mitmacht und irgendwann später einem anderen Benutzer zugewiesen wird, der in genau dieser Session ebenfalls das Gewinnspiel machen will. Bei 2000 erwarteten Teilnehmern ist das nicht sonderlich wahrscheinlich, aber es ist auch nicht auszuschliessen.

Und zweitens surfen häufig alle Mitarbeiter einer Firma nach aussen mit der selben IP-Adresse. Auch bei uns. Wenn ich also ein Gewinnspiel im Netz entdecke und es gleich den anderen im Büro sage, und die auch alle mitmachen, dann hat das Gewinnspiel sehr schnell einige Requests, die alle von der selben IP-Adresse stammen und in sehr kurzer zeitlicher Abfolge auftreten, aber vollständig legitim sind.

Unser IP-Blocker versucht mit dieser Situation umzugehen. Er implementiert ein dreistufiges Modell, wobei jede Stufe für eine verschärfte Behandlung einer IP-Adresse steht. Landet eine Adresse in Stufe 3 ist sie für einen bestimmten Zeitraum blockiert. Wie lange sie blockiert ist, hängt davon ab, warum sie in Stufe 3 gelandet ist.

Alle Requests, die das Formular ausgefüllt zurückschicken, landen im Eimer 1. Das ist eine LRUHashMap (aus commons-collections), die die IP-Adresse als Key und die Anzahl der Aufrufe als value speichert. Die Map ist auf 200 Einträge beschränkt. Für jeden Request wird die IP-Adresse in der Map nachgeschlagen. Ist die Adresse in der Map schon enthalten, wird der Zähler hochgezählt. Andernfalls wird die IP-Adresse in die Map aufgenommen.

Wenn der Zähler einer IP-Adresse einen Schwellenwert überschreitet, wird die Adresse auf Stufe 2 gehoben.

Stufe 2 ist ebenfalls eine Map, die zur IP-Adresse aber nicht nur einen Zähler speichert, sondern mehrere zeitbasierte Schwellenwerte. Diese Schwellenwerte können z.B. ausdrücken: “Nicht mehr als 40 Requests innerhalb einer Stunde” oder “nicht mehr als 60 Requests innerhalb von 3 Stunden”. Sobald eine IP-Adresse einen dieser Schwellenwerte überschreitet, wird sie in Stufe 3 geschoben.

Stufe 3 meint, dass sämtliche Requests dieser Adresse blockiert werden. Wie lange die IP-Adresse in Stufe 3 enthalten ist, richtet sich nach dem zeitlichen Aspekt der Schwelle. Wir haben fürs erste die dreifache Zeit der Schwellenzeit benutzt. Darf eine IP-Adresse also nicht häufiger als 40 x pro Stunde auftauchen und überschreitet sie diese Schwelle, so wird sie anschliessend für drei Stunden blockiert.

Anschliessend gilt neues Spiel, neues Glück für die überschrittene Schwelle, nicht aber für die nicht überschrittenen Schwellen.

geschrieben am 07.05.2009 um 16:05 in Netzgedanken von cf · RSS 2.0 feed.
Weder Pings noch Kommentare sind erlaubt.