Wie Websites wirklich kompromittiert werden, und wie Sie nicht das leichte Ziel sind.
In der Sicherheit lautet die vermutete Ursache meist «nichts ist falsch». So werden Websites wirklich kompromittiert, warum die Spitze dieser Liste vermeidbar ist, und wie von außen bewiesen wird, dass eine Korrektur die Tür geschlossen hat.
In diesem Artikel 4 Abschnitte
- In der Sicherheit lautet die vermutete Ursache «nichts ist falsch». Die meisten wissen nicht, dass sie kompromittiert wurden.
- Unser Monitoring und unsere Threat-Intelligence-Feeds sind so verdrahtet, dass sie das Ticket öffnen, deshalb kommt die erste Nachricht meist von uns. Es als Erster zu bemerken, ist die Aufgabe.
- Websites werden auf langweilige Weise kompromittiert. Veraltete Software und Dinge, die unbeabsichtigt offen geblieben sind, führen die Liste an, und genau beides fangen ein Audit vor dem Go-live und kontinuierliches Patchen ab.
- Den Einbruch zu finden, ist nur die Hälfte. Wenn wir einen schließen, beweisen wir, dass die Tür zu ist, indem wir von einer Adresse aus erneut angreifen, der wir nicht vertrauen. Kommen wir noch durch, ist es nicht behoben.
In jedem Sicherheitsgespräch gibt es ein verräterisches Zeichen. Die vermutete Ursache auf Kundenseite ist meist die schlimmste, die es gibt: nichts ist falsch. Die Kunden haben nicht angerufen, weil etwas seltsam aussah. Sie haben angerufen, weil wir es ihnen gesagt haben. Bis ein Einbruch für den Betreiber der Website sichtbar wird, ist er in der Regel längst geschehen.
In der Sicherheit lautet die vermutete Ursache «nichts ist falsch»
“quote: In der Sicherheit lautet die vermutete Ursache auf Kundenseite meist «nichts ist falsch». Sie wussten nicht, dass sie kompromittiert waren. attribution: EUROVPS SECURITY”
Das ist der ganze Unterschied. Nicht, dass es keine Einbrüche gäbe. Es gibt sie, auf jeder Plattform, bei jeder Art von Website. Der Unterschied ist, wer sie zuerst sieht: eine Erkennungsschicht, die auf die Signaturen einer Kompromittierung achtet, oder ein Threat-Intelligence-Feed, der Datenverkehr markiert, den es nicht geben dürfte, während das Dashboard der Website selbst noch grün zeigt. Unser Monitoring und diese Feeds sind so verdrahtet, dass sie das Ticket öffnen, und deshalb kommt die erste Nachricht meist von uns.
Wie Websites wirklich kompromittiert werden
Lässt man die Kinoversion weg, sind die Wege, auf denen Websites wirklich kompromittiert werden, langweilig, und sie wiederholen sich. Hier ist die Rangfolge, der häufigste zuerst. Nichts an der Spitze dieser Liste ist raffiniert.
Veraltete Software oder Software am Ende ihres Lebenszyklus
Der mit Abstand häufigste Weg hinein. Eine Anwendung mit einer öffentlich bekannten Schwachstelle, dem Internet ausgesetzt, Jahre im Patch-Rückstand. Dem Internet ausgesetzt und Jahre im Patch-Rückstand, mehr braucht es nicht. Der Exploit liegt fertig im Regal. Raffinesse ist nicht erforderlich.
Etwas, das unbeabsichtigt offen geblieben ist
Kein Exploit nötig. Die Tür stand einfach offen. Ein Datenspeicher, der ohne Authentifizierung an jede Netzwerkschnittstelle gebunden ist. Eine für alle lesbare Konfigurations- oder Debug-Datei. Ein CMS, das seine Benutzernamen über eine offene API preisgibt. Eine vergessene Staging-Subdomain, die noch antwortet. Niemand ist eingebrochen. Man ist hineinspaziert.
Der Origin hinter dem CDN erreichbar
Die Website sitzt hinter einem CDN, aber der echte Server antwortet weiterhin direkt, wenn man ihn findet, und seine Adresse steht oft im Mail-DNS der eigenen Domain. Die Vordertür wird bewacht, während die Hintertür aufgestellt ist.
Brute-Force auf Zugangsdaten ohne Schutz auf Layer 7
Eine Anmeldeseite, vor der auf der Anwendungsebene nichts steht, bearbeitet, bis etwas nachgibt. Eine Firewall auf Layer 3/4 lässt das glatt durch: Für einen Portfilter sieht es aus wie normaler Verkehr auf einem Port, der offen bleiben muss.
Schwache, wiederverwendete oder offengelegte Zugangsdaten ohne MFA
Ein Passwort, das anderswo durchgesickert ist, hier wiederverwendet, ohne zweiten Faktor, der es wertlos machen würde. Das Schloss war in Ordnung. Der Schlüssel war bereits kopiert.
Ausgehender Spam von einem bereits kompromittierten Konto
Oft das erste nach außen sichtbare Zeichen eines Einbruchs, der bereits geschehen ist. Das Konto ist nicht das Ziel. Es ist die Startrampe, und der Spam ist der Rauch, nicht das Feuer.
Phishing und Social Engineering
Die menschliche Ebene. Kein Softwarefehler beteiligt. Jemand wurde schlicht überzeugt, die Schlüssel herauszugeben.
Sehen Sie sich die ersten beiden an. Veraltete Software und Dinge, die unbeabsichtigt offen geblieben sind. Keines von beiden ist ein raffinierter Angriff. Beides ist genau das, was ein diszipliniertes Audit vor dem Go-live und kontinuierliches Patchen abfangen, bevor jemand die Klinke probiert. Das ist das gesamte Argument für Managed Security. Bei den meisten Einbrüchen wird nicht eingebrochen. Es wird hineinspaziert. Und das Hineinspazieren ist vermeidbar.
Es als Erster zu bemerken, ist die Aufgabe. Zu beweisen, dass es zu ist, ist der Unterschied.
Den Einbruch zu finden, ist die halbe Arbeit. Die Hälfte, die fast niemand macht, ist zu beweisen, dass die Korrektur tatsächlich gehalten hat. Wenn wir eine Kompromittierung schließen, verlassen wir uns nicht auf das Wort des Dashboards, dass der Port zu ist. Wir greifen den Origin erneut an, so wie es ein Angreifer tun würde: von einer Maschine in einem anderen unserer Rechenzentren, über einen Egress, dem die Firewall nie zu vertrauen gelernt hat. Kommt unser eigener Scanner noch durch, ist es nicht behoben. Erst wenn die Tür von außen zu ist, von einer Adresse, der wir nicht vertrauen, nennen wir sie geschlossen.
“quote: Die Aufgabe ist nicht nur, den Einbruch zu beheben. Sie ist, ihn als Erster zu bemerken und dann von außen zu beweisen, dass die Tür zu ist. attribution: EUROVPS SECURITY”
Diese Methode, den eigenen Origin von einem nicht vertrauenswürdigen Standpunkt aus erneut anzugreifen und zu bestätigen, was ein Angreifer tatsächlich sehen würde, ist eine eigene Disziplin und bekommt ihren eigenen Beitrag. Wie wir vor dem Go-live beweisen, dass die Tür zu ist geht das vollständige Playbook durch.
Sieben Wege, nicht das leichte Ziel zu sein
Nichts an der Spitze dieser Rangfolge braucht einen genialen Angreifer. Das heißt, das meiste davon ist vermeidbar, indem Sie nicht das leichte Ziel sind. Sieben Gewohnheiten, in der Reihenfolge, in der sie sich auszahlen.
Patchen oder abschalten
Was dem Internet ausgesetzt und ungepflegt ist, ist ein Risiko. Aktualisieren Sie es oder nehmen Sie es vom Netz. Eine dritte Option, die gut ausgeht, gibt es nicht.
Gehen Sie davon aus, dass der Origin gefunden wird
Beschränken Sie ihn auf die IP-Bereiche des CDN, sodass nur das CDN ihn erreichen kann, und hören Sie auf, seine Adresse in Ihrem Mail-DNS preiszugeben. Ein versteckter Origin ist nicht versteckt, wenn Ihr eigenes DNS ihn ankündigt.
Eine L3/4-Firewall ist keine WAF
Portfilterung liest keine Anfragen. Brute-Force, Injection und Missbrauch auf Anwendungsebene kommen alle über Ports herein, die Sie offen lassen müssen. Sie brauchen einen Schutz, der Layer 7 inspiziert.
Prüfen Sie, bevor Sie etwas für fertig erklären
«Es funktioniert» ist nicht «es ist zu». Prüfen Sie, was exponiert ist, was für alle lesbar ist, was noch an das öffentliche Internet gebunden ist, vor dem Go-live, nicht nachdem die Meldung eintrifft.
Gehen Sie davon aus, dass Zugangsdaten durchsickern. Machen Sie sie außerhalb der Whitelist wertlos.
MFA überall, und binden Sie die sensiblen Pfade an bekannte Adressen. Ein gestohlenes Passwort sollte für sich allein nichts öffnen.
Überwachen Sie den Wächter
Monitoring, das blind wird und weiter grün meldet, ist schlimmer als kein Monitoring, weil es falsche Ruhe erkauft. Vergewissern Sie sich, dass der Detektor tatsächlich sehen kann.
Beweisen Sie die Korrektur von außen
Der einzige Test, der zählt, ist der Blick des Angreifers. Greifen Sie von einer Adresse aus erneut an, der Sie nicht vertrauen, und bestätigen Sie, dass die Tür zu ist.
Klare Antworten
Wie werden Websites im Managed Hosting tatsächlich gehackt?+
Meist auf zwei langweilige Arten. Veraltete Software oder Software am Ende ihres Lebenszyklus mit einer öffentlich bekannten Schwachstelle, dem Internet ausgesetzt, und Dinge, die unbeabsichtigt offen geblieben sind: ein Datenspeicher ohne Authentifizierung, eine für alle lesbare Konfigurationsdatei, eine vergessene Staging-Subdomain. Raffinierte Exploits stehen weit unten auf der Liste. Bei den meisten Einbrüchen wird hineinspaziert.
Wie würde ich überhaupt erfahren, dass meine Website kompromittiert wurde?+
Oft gar nicht, und genau das ist der Punkt. Unser Monitoring und unsere Threat-Intelligence-Feeds sind so verdrahtet, dass sie das Ticket öffnen, deshalb kommt die erste Nachricht über eine Kompromittierung meist von uns. Die vermutete Ursache auf Kundenseite lautet meist «nichts ist falsch». Ausgehender Spam oder eine Meldung von Dritten ist häufig das erste nach außen sichtbare Zeichen, und dann ist es bereits geschehen.
Ist mein Server sicher, wenn er eine Firewall hat?+
Eine Firewall auf Layer 3/4 filtert Ports. Sie liest keine Anfragen. Brute-Force auf Zugangsdaten, Injection und Missbrauch auf Anwendungsebene laufen alle über Ports, die Sie offen lassen müssen, und sehen für sie deshalb wie normaler Verkehr aus. Eine Firewall ist keine WAF. Um das zu stoppen, braucht es einen Schutz, der Layer 7 inspiziert.
Können Angreifer meinen Origin-Server finden, wenn er hinter einem CDN steht?+
Häufig ja. Das CDN hilft nur, wenn der Origin nicht direkt erreichbar ist, und die echte Adresse des Origin steht oft im Mail-DNS der eigenen Domain. Beschränken Sie den Origin auf die IP-Bereiche des CDN und hören Sie auf, ihn im DNS anzukündigen, sonst hat die bewachte Vordertür eine aufgestellte Hintertür.
Wer ist im Managed Hosting für das Patchen meiner Anwendungen verantwortlich?+
Die Plattform und die Anwendung sind zwei verschiedene Aufgaben, und in der Lücke dazwischen werden Websites kompromittiert. Wir halten die Plattform gehärtet und prüfen vor dem Go-live. Eine Anwendung am Ende ihres Lebenszyklus mit einer bekannten Schwachstelle ist aber ein geteiltes Risiko. Der Wert des Managed-Ansatzes ist, dass ein diszipliniertes Audit vor dem Go-live und kontinuierliches Patchen das meiste abfangen, bevor jemand die Klinke probiert.
Nicht sicher, was exponiert ist? Fragen Sie, bevor es jemand anderes herausfindet.
Bringen Sie es zu einem Ingenieur, nicht in eine Ticket-Warteschlange. Wir prüfen, was von außen erreichbar ist, sagen Ihnen klar, was zu schließen ist, und beweisen dann, dass es zu ist.
Mit einem Ingenieur sprechenSie haben das Ende erreicht.
Setzen Sie das Gelesene um
Was betreiben Sie?
Erzählen Sie uns von Workload, Traffic und Anforderungen an die Wiederherstellung. Beginnen Sie mit dem Server-Konfigurator oder besprechen Sie die Details mit einem Ingenieur.
Geschrieben von den Ingenieuren, die die beschriebene Infrastruktur bauen und betreiben.Mit einem Ingenieur sprechen