Lohnen sich Honeypot-Systeme auf den Servern eines kleinen Unternehmens wirklich?

Dass ihr zehntausende Requests pro Tag seht, liegt einfach an den üblichen automatisierten Scan-Bots im Netz. Wenn ihr einen Honeypot aufsetzt, tappen genau dieselben Bots rein und ihr erfahrt nur das, was ihr eh schon wisst: Im Internet wimmelt es von Bots. Selbst bei einem Low-Interaction-Honeypot könnt ihr den nicht im selben VLAN wie eure Produktivsysteme laufen lassen; das braucht ein eigenes Subnetz und strikte Firewall-Regeln.

Ergänzung: Wurde unten schon gefragt, die Antwort habe ich im zweiten Beitrag geschrieben.

Vergesst den Rat des Beraters erst mal. Standardports ändern, Passwort-Login abschalten und nur noch Key-Auth erlauben, dazu ein simples Tool, das fehlgeschlagene Versuche temporär blockiert – das killt 99 % dieser täglichen Scans sofort. Kostet null Euro und ist in zwei Stunden erledigt.

Wir haben letztes Jahr aus Neugier mal einen Open-Source-SSH-Honeypot auf einem ungenutzten Server aufgesetzt. Innerhalb von drei Tagen hatten wir über 140.000 Login-Versuche und 800 verschiedene Usernamen gesammelt. Ein Entwickler von uns hat dann wöchentlich 4 Stunden damit verplempert, diese sinnlose Datenflut auszuwerten. Nach einem Monat haben wir das Ding gekillt – Null Mehrwert für den Alltag.

Hat der Berater auch gesagt, wer die Logs überwachen soll, nachdem dieser Honeypot aufgesetzt ist? Haben Sie ein SOC das die Alarme verwaltet, oder soll das Ding einfach nur eingerichtet und dann vergessen werden? Wenn Sie kein Budget dafür eingeplant haben, die Berichte wöchentlich zu analysieren, was bringt dann so eine Falle überhaupt?

absolut unnötig mein lieber. der berater will euch wahrscheinlich nur das standard-template aus großkonzern-projekten andrehen... ssh-port nach außen dichtmachen oder hinter ein vpn klemmen reicht völlig. fürs logs wälzen reicht die lebenszeit eh nicht.

Ein Honeypot ist kein Verteidigungswerkzeug sondern dient der Threat Intelligence und Forschung. Unternehmen mit Hunderten Mitarbeitern und eigenem Security-Team nutzen so etwas, um neue Angriffsvektoren frühzeitig zu erkennen. Eine 12-köpfige Softwareschmiede hat schlicht nicht den operativen Luxus Angreiferprofile zu analysieren.

Die Sache ist ganz einfach. Ein Honeypot blockiert keinen Angriff, er dokumentiert ihn nur. Was Sie brauchen, ist keine Log-Analyse, sondern abgeschlossene Türen. Sobald Sie die Ports nach außen schließen und auf schlüsselbasierte Authentifizierung umstellen, lösen sich all diese Fragezeichen von selbst in Luft auf.

Meine Frage ist geklärt, vielen Dank. Kein Prozess ohne Dokumentation verbessert sich, weil man nicht weiß, was man verbessern soll.

Vergessene Testumgebungen sind häufiger das Einfallstor als das Live-System. Viel Erfolg.

Wenn ich dich richtig verstehe, meinst du Folgendes: Entscheidend ist nicht die Zahl, sondern worauf sie sich bezieht.

Nach diesem Erlebnis hat sich meine Sichtweise geändert. Das allein zu versuchen ist der teuerste Weg.

Das allein zu versuchen, ist der teuerste Weg.

Ich spreche mal aus der Gegenperspektive, ich bin auf der Lieferantenseite. Ein automatisierter Scan-Report ist kein Penetrationstest.

Viel Erfolg.

Ich probiere es aus.

Das wusste ich nicht.

nichts vergessen: Ein nicht getesstetes Backup ist kein Backup.

schaut zuerst, welche Daten ihr bei der Entscheidungsfindung zur Hand habt. halt wenn ihr das Ergbnis hier postet hilft es auch anderen.

Hier ist etwas zu beachten. Beginnt mit einem kleinen Test, bindet nicht gleich alles fest.

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

Ich fasse kurz zusammen, was bisher gesagt wurde. Wenn der Benachrichtigungsweg lang ist, kommen keine Benachrichtigungen; keine Benachrichtigung bedeutet spät erkannte Vorfälle.

Viel Erfolg.

Man sollte der Reihe nach vorgehen. also bei uns war der größte Zeitfresser die Unklarheit darüber, wer entscheidet.

Nur als Notiz könnte nützlich sein.

Ich werde das Gegenteil vertreten, bitte nicht böse sein. Nur weil alle es tun, heißt es nicht, dass es richtig ist.

Viel Erfolg.