Wir haben den Traffic mit einem Honeypot-Checker kontrolliert, können wir uns auf die Risikoergebnisse verlassen und was sollen wir tun?

Mit statischem IP-Blocking kommt man gegen Bots nicht an, weil Botnetze ständig die IPs wechseln. Richten Sie lieber auf Ihrem Webserver ein vernünftiges Rate Limiting ein. Wer mehr als fünf Anfragen pro Sekunde an Warenkorb- oder Suche-Endpunkte schickt, wird temporär ausgebremst oder in eine Browser-Prüfung (Challenge) geschickt.

Diese kostenlosen Check-Tools hängen mit ihren Datenbank-Updates meistens meilenweit hinterher. Selbst eine Rechenzentrums-IP, die schon vor drei Monaten bereinigt wurde, gilt da oft noch als bösartig. Wenn man da stur nach Liste sperrt, sperrt man sich ganz schnell potenzielle Kunden aus Mobilfunknetzen aus.

Die schnellste Lösung: Gehen Sie in die Verwaltung Ihrer Domain, drehen Sie das Sicherheitslevel eine Stufe höher und schalten Sie für verdächtige Länder automatisierte Browser-Challenges vor. Echte Nutzer kommen problemlos durch, einfache Scraper-Bots bleiben sofort hängen.

Die sinnvolle Reihenfolge wäre grob gesagt: 1) Server-Logs nach auffälligen User-Agent-Mustern durchforsten. 2) Auf Seiten, die Suchmaschinen nicht crawlen sollen, versteckte Honeypot-Links setzen und IPs, die da reinlaufen, für 24 Stunden sperren. 3) Kasse- und Warenkorbseiten mit striktem Rate Limiting absichern.

wir haben auch mal in panik 50 ips gesperrt, am ende wars das büronetz von nem großkunden. die dachten die seite ist down und haben woanders bestellt statisches blocken ist echt super riskant.

Letzten Monat hatten wir einen ähnlichen Scan mit 3.000 verschiedenen IPs auf unserem Server. In externen Tools sahen 1.200 davon riskant aus, aber bei genauerem Hinsehen haben effektiv nur 75 davon wirklich Daten gescrapt. Ohne das tatsächliche Verhalten zu analysieren, rein nach IP zu blocken, ist reine Zeitverschwendung.

Bringen diese Requests die CPU ans Limit oder müllen sie einfach nur die Access-Logs zu? Und kommen die Anfragen in bestimmten Zeitfenstern mit festem Muster oder verteilt sich das völlig chaotisch über den ganzen Tag?

Im Großen und Ganzen richtig, aber ein Punkt fehlt. Die Zeit, die ihr braucht, um ein Problem zu erkennen, bestimmt direkt dessen Kosten.

Nur als Notiz, könnte nützlich sein.

Dieser Ansatz hat seinen Preis, der aber nicht thematisiert wird. Schreibe bei Entscheidungen auch das Worst-Case-Szenario auf, nicht nur das Beste.

Entscheidend ist nicht die Zahl, sondern worauf sie sich bezieht. Korrigiert mich, falls ich falsch liege.

Meine Frage klingt vielleicht etwas naiv, entschuldigt bitte. Menschen verteidigen nicht den Prozess, sondern die Gewohnheit. Der Widerstand kommt daher.

Ein automatisierter Scan-Report ist kein Penetrationstest. Korrigiert mich, falls ich falsch liege.

Ich stimme voll und ganz zu. Wenn du das nicht von Anfang an schriftlich festhältst gibt es später Streit.

Meine Frage ist geklärt, vielen Dank.

Ein Thema, das gerade aktuell ist. Schreibe bei Entscheidungen auch das Worst-Case-Szenario auf, nicht nur das Beste.

Nur als Notiz, könnte nützlich sein.

Ich habe keinerlei Erfahrung mit honeypot kontroll tool, deshalb frage ich. Bei uns war der größte Zeitfresser die Unklarheit darüber, wer entscheidet.

Wenn ihr es zum ersten Mal macht, fangt klein an, die Skalierung kommt später.

Ich würde sagen, lass uns nichts überstürzen. Ein nicht getestetes Backup ist kein Backup.

Beginnt mit einem kleinen Test, bindet nicht gleich alles fest. Ich hoffe, das hilft dir weiter.

Bei uns war es so. Wenn du zu einem Thema drei verschiedene Antworten bekommst, war die Frage falsch gestellt.

In den ersten drei Monaten läuft alles gut, die Probleme tauchen im vierten Monat auf.

Da stimme ich zu. Wenn man Fehlalarme anschreit, meldet sich danach niemand mehr.

Ich hoffe, das hilft dir weiter.

Bei uns war es so. Bei uns war der größte Zeitfresser die Unklarheit darüber, wer entscheidet.

Wenn deine Situation anders ist, ändert sich das natürlich.