Open-Source Attack Surface Management: Wie weit darf man Scans auf eigene Faust durchführen?

Beim aktiven Scannen unbedingt auf die Rate Limits achten. Wenn ihr da mit Vollgas hunderte Pakete pro Sekunde raushaut, riegeln die IDS-Systeme des Rechenzentrums die IP sofort ab. Immer brav Single-Threaded scannen und Pausen zwischen die Requests packen.

Mit Open-Source-Scannern seht ihr meist nur ob die Tür offen steht. Wie man an die Daten dahinter rankommt oder welche Lücken entstehen wenn zwei Dienste kombiniert werden verraten einem solche Tools nicht. Man sollte sich da keiner falschen Sicherheit hingeben.

Letztes Jahr hab ich auf unserem Server in Berlin so einen ähnlichen Open-Source-Scanner laufen lassen. Eine Stunde später kam die Warnung vom Hoster wegen bösartiger Aktivität und unser Server-Traffic wurde gesperrt. Bis wir das erklärt hatten waren unsere Systeme einen halben Tag down.

Fangt als ersten Schritt mit passiven Recon-Tools an. Ohne auch nur ein einziges Paket an irgendeinen Server zu schicken könnt ihr allein aus öffentlichen Internet-Registern dutzende vergessene Subdomains und alte Testseiten aufspüren. Macht die erstmal dicht.

ich sag mal so, startet kein aggressives Scanning, ohne vorher dem Rechenzentrum Bescheid zu geben und eure eigenen IPs auf die Whitelist setzen zu lassen sonst hängt ihr nachher mit der Abuse-Abteilung rum.

Sind die Server, die ihr nutzt, komplett euch gehörende dedizierte Server oder geteilte Cloud-Maschinen? In geteilten Umgebungen sind die Regeln wegen des Risikos, andere Kunden im selben IP-Block zu beeinträchtigen, deutlich strenger.

Auch wenn es euer eigener Besitz ist, führt aktive Schwachstellen-Scans auf Netzwerkebene nicht durch ohne eurem Rechenzentrum eine offizielle Meldung zu machen.

Ich schreibe mal meine Erfahrung auf. Die Antwort hängt stark von der Branche ab, es gibt keine allgemeine Regel.

Scheut euch nicht zu fragen, wer nicht fragt, zahlt am Ende mehr. Das war's, entschuldige, wenn ich zu lang war.

Ich möchte etwas fragen. Dass das Backup im gleichen Netzwerk und mit derselben Identität erreichbar ist, macht es zum Teil des Ziels.

Das wusste ich nicht. Die Antwort hängt stark von der Branche ab es gibt keine allgemeine Regel.

Ich bin in derselben Situation deshalb frage ich. ehrlich gesagt fehler auf der angriffsfläche open source-Seite sind meist rückgängig zu machen, aber teuer.

An deiner Stelle würde ich so vorgehen.

Man sollte der Reihe nach vorgehen. Sicherheit ist nicht absolut; es bedeutet, den Angriff so aufwendig zu machen, dass er sich nicht lohnt.

Änderungen an Zahlungsdaten werden niemals über den Kanal bestätigt, über den sie eingehen. Das war's, entschuldige, wenn ich zu lang war.

An diesem Punkt widerspreche ich dir. Dass das Backup im gleichen Netzwerk und mit derselben Identität erreichbar ist, macht es zum Teil des Ziels.

Schreibe bei Entscheidungen auch das Worst-Case-Szenario auf, nicht nur das Beste. Aus Erfahrung weiß ich das.

Absolut. Wenn ich noch etwas hinzufügen darf: Wenn Genehmigung und Umfang nicht schriftlich vorliegen, darf der Test nicht starten.

Wenn ich dich richtig verstehe meinst du Folgendes: Fehler auf der angriffsfläche open source-Seite sind meist rückgängig zu machen, aber teuer.

Richtig.

Ich fasse das Thema mal zusammen da es mehrere unterschiedliche Antworten gab... ehrlich gesagt sicherheit ist nicht absolut; es bedeutet den Angriff so aufwendig zu machen, dass er sich nicht lohnt.

Aus Erfahrung weiß ich das.

Bei uns war es so. Die meisten Vorfälle beginnen nicht mit einer Schwachstelle, sondern mit einem geleakten Passwort.

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