Ich verwalte eine kleine Firmen-Website. Hab die Logs zum ersten Mal richtig durchgeschaut und war schockiert.
Tausende Requests pro Tag: auf Adressen wie /wp-admin, /.env, /phpmyadmin, /.git/config. Wir haben nicht mal WordPress.
Ist das ein gezielter Angriff auf uns oder ist das bei jedem so? Was soll ich tun?
Erstmal entspannen: Das ist kein gezielter Angriff auf euch, sondern das Grundrauschen, das jede öffentliche IP-Adresse bekommt. Automatische Scanner durchsuchen ständig alle IP-Bereiche und testen bekannte Schwachstellen-Adressen. Die wissen nicht, was eure Seite ist, und ist denen auch egal.
Jetzt zum skeptischen Teil, denn "normal" heißt nicht "egal". Unterscheidet bitte folgendes:
Automatisches Rauschen: Requests, die auf zufällige Adressen mit 404 antworten, von verschiedenen IPs, wiederkehrende Muster. Das ist nur Lärm.
Worauf ihr achten solltet: Versuche auf eure echten Adressen. Aneinanderreihende Passwort-Versuche auf der Login-Seite, Zugriffsversuche auf das Admin-Panel, Manipulationen an Parametern. Das bedeutet, dass sich jemand eure Seite wirklich angesehen hat.
Zu tun, nach Priorität: Lasst das Admin-Panel nicht öffentlich, setzt Rate-Limits auf Login-Versuche, haltet eure Software aktuell, macht Backups und testet diese, indem ihr sie wiederherstellt.
Der letzte Punkt wird am häufigsten ignoriert. Ein nicht getestetes Backup ist kein Backup.
Als Ergänzung aus technischer Sicht vom SOC.
Den Versuch, dieses Rauschen komplett zu blockieren (z.B. jede IP auf die Blacklist setzen), ist meist vergebene Liebesmüh. IPs ändern sich ständig, die Liste wird riesig und irgendwann sperrt ihr eure eigenen User aus.
Filtert stattdessen das Rauschen raus, damit ihr die echten Vorfälle seht. Praktischer Weg: Schreibt die 404-Requests in einen separaten Kanal, im Haupt-Log-Stream sollten nur 200er und 500er bleiben. Führt außerdem einen separaten Zähler für fehlgeschlagene Login-Versuche.
Als Alarm-Regel empfehle ich: Viele fehlgeschlagene Logins von einer einzigen Quelle in kurzer Zeit. Das ist das Muster, das sich wirklich vom Rauschen abhebt und Eingreifen erfordert.
Und vergesst nicht: Die häufigsten echten Vorfälle starten nicht durch Brute-Force von außen, sondern durch Login mit geleakten Passwörtern. Deshalb ist es genauso wichtig, 2FA zu aktivieren, wie Logs zu checken.
Eine Frage: Ihr sagt, ihr habt die Logs zum ersten Mal richtig durchgesehen. Wie weit könnt ihr denn vorher zurückblicken?
Der Grund für das Problem: Auf den meisten Servern ist die Log-Aufbewahrungsdauer standardmäßig kurz. Wer bei einem Vorfall zurückblicken will, läuft gegen dieselbe Wand: keine Logs.
Als jemand, der Beweise braucht, ein konkreter Rat: Checkt eure Log-Aufbewahrungsdauer und stellt sie auf mindestens 90 Tage. Der Speicherplatz ist gering, der Wert im Ernstfall riesig. Speichert die Logs außerdem nicht nur auf dem Server selbst, sondern auch woanders; wenn der Server gehackt wird, sind Logs das Erste, was gelöscht wird.
Als Hosting-Anbieter gebe ich euch eine Zahl, keine Schätzung, das ist das Muster, das wir regelmäßig in unserem eigenen Panel sehen.
Selbst eine neu registrierte, nie beworbene Domain, die nirgends verlinkt ist, bekommt innerhalb der ersten Woche solche automatischen Versuche. Der Grund ist simpel: Die Certificate Transparency Logs sind öffentlich, neue Domains sind dort auch sichtbar.
Es gibt also keinen Sicherheitsstatus wie "meine Seite ist klein, das kennt keiner". Klein sein macht euch nicht unsichtbar, es reduziert nur die Wahrscheinlichkeit gezielter Angriffe.
Bin Student, hab ne Frage, sorry falls sie dumm klingt.
Warum suchen diese Browser nach der /.env-Datei? Was ist da drin, dass es so wertvoll ist?
Gar nicht albern, sehr berechtigte Frage.
Die .env-Datei ist eine Textdatei, die die Einstellungen der App enthält (environment, also Umgebungsvariablen). Darin stehen meist die Datenbank-Adresse und das Passwort, die API-Keys von Drittanbieter-Services und der Schlüssel zur Sitzungsverschlüsselung.
Für einen Angreifer heißt diese Datei also: Statt die Tür aufzubrechen, einfach den Schlüssel finden. Deshalb probieren Scanner das zuerst aus; der Aufwand ist eine einzige Anfrage, der Ertrag ist alles.
Normalerweise sollte diese Datei außerhalb des Ordners liegen, den der Webserver ausliefert. Bei falscher Konfiguration bleibt sie im public-Ordner und ist über den Browser lesbar. Dasselbe gilt für /.git/config: Wenn das Projekt-Repo versehentlich online ist, kann man den kompletten Quellcode herunterladen.
Das Prüfen ist easy: Schreib einfach /.env an deine Adresse und schau, was passiert. Bekommst du eine 404, ist alles gut. Siehst du Inhalte, sofort dichtmachen und alle Keys in der Datei rotieren. Sperren reicht nicht, man muss davon ausgehen, dass sie geleakt sind.
Als Doki-Team wollen wir noch einen Hinweis ergänzen, weil dieser Thread ein oft diskutiertes Thema gut zusammenfasst.
Das oben beschriebene Bild sehen wir auch: Jede öffentlich erreichbare Ressource wird gescannt, auch wenn sie nicht beworben wird. Deshalb empfehlen wir unseren Kunden als Erstes, ein Asset-Inventar zu erstellen – welche Domains, Subdomains und Server gehören wirklich zu uns und welche sind noch versehentlich online?
In der Praxis ist die häufigste Sicherheitslücke vergessene Testumgebungen. Das Live-System ist gut geschützt, aber ein vor zwei Jahren aufgesetzter Testserver zeigt immer noch auf dieselbe Datenbank.
Die Beiträge hier sind nur zur allgemeinen Info; wir empfehlen, für euer System eine definierte Bewertung durchführen zu lassen.
Betrachtet man den Prozess, ändert sich das Bild. Wenn die Zwei-Faktor-Authentifizierung aktiv ist, reicht ein gestohlenes Passwort allein nicht aus.
Wenn die Zwei-Faktor-Authentifizierung aktiv ist, reicht ein gestohlenes Passwort allein nicht aus. Wenn ihr das Ergebnis hier postet, hilft es auch anderen.
Ich stimme zu, möchte das sogar besonders betonen. Wenn der Benachrichtigungsweg lang ist, kommen keine Benachrichtigungen; keine Benachrichtigung bedeutet spät erkannte Vorfälle.
Wenn es jemand anders macht, würde mich das auch interessieren.
Da ist mir noch ein Punkt unklar. Überstürzte Entscheidungen sind oft solche die man sechs Monate später korrigieren muss.
Viel Erfolg.
Kurzfassung für Neueinsteiger: Je schwerer es ist, eine Entscheidung rückgängig zu machen, desto langsamer solltet ihr sie treffen.
Jeder nicht schriftlich festgehaltene Punkt ist einer, an den sich beide Parteien später unterschiedlich erinnern. Viel Erfolg.
Danke fürs Schreiben, das ist genau richtig. Wenn Genehmigung und Umfang nicht schriftlich vorliegen, darf der Test nicht starten.
Das ist meine Meinung, ich behaupte nicht, dass es absolut richtig ist.
Ich habe mich lange damit beschäftigt. Der meiste Zeitverlust entsteht durch Arbeiten, die auf Freigaben warten.
Fehler auf der log-Seite sind meist rückgängig zu machen, aber teuer. Ich hoffe, das hilft dir weiter.
Wie habt ihr das Problem gelöst? Das allein zu versuchen, ist der teuerste Weg.
Fehler auf der log-Seite sind meist rückgängig zu machen, aber teuer. Das ist meine Meinung, ich behaupte nicht, dass es absolut richtig ist.