Wie wir vor dem Go-live beweisen, dass die Tür zu ist.
Vor dem Go-live beweisen wir, dass die Tür zu ist: Wir greifen Ihren echten Origin von einer Maschine außerhalb des Netzwerks an, der die Firewall nie vertraut hat, und sehen, was ein Fremder sieht. Eine geschlossene Tür antwortet mit connection refused, nicht mit einer Login-Seite.
In diesem Artikel 7 Abschnitte
- Vor jedem Go-live, und nach jeder Änderung am Edge, stellen wir eine Frage: Was sieht ein Fremder im Internet tatsächlich? Wir beantworten sie von einer Maschine in einem anderen unserer Rechenzentren, über einen Egress, dem unsere eigene Firewall nie zu vertrauen gelernt hat.
- Wir finden den echten Origin so, wie ein Angreifer es täte (meist leckt er im eigenen Mail-DNS der Domain), pinnen jedes Werkzeug auf den nackten Origin statt auf das CDN und lassen die komplette Prüfreihe noch einmal laufen.
- Wir scannen alle 65.535 Ports von diesem Standpunkt außerhalb des Netzwerks, damit wir positiv sagen können, was geschlossen ist. Die dauerhafte Korrektur sperrt den Origin auf die veröffentlichten Bereiche des CDN, gestützt von einer echten Layer-7-WAF und gemeinsamen Sperrlisten.
- Und dann nehmen wir die Korrektur nicht auf Treu und Glauben. Wir greifen den nackten Origin erneut von außen an, und eine geschlossene Tür antwortet mit connection refused, nicht mit einer Login-Seite. Das ist ein Beweis, kein Versprechen.
Die häufigste Art, wie eine Hardening-Aufgabe endet, ist, dass jemand eine Einstellung ändert, die Seite neu lädt, sieht, was er erwartet hat, und weitergeht. Das ist Patchen und Hoffen. Es beweist das Symptom, das man angesehen hat. Es beweist nichts über die Tür. Was folgt, ist die Methode, die unsere Ingenieure stattdessen fahren, vor jedem Go-live und nach jeder Änderung am Edge. Sie hat eine Regel, die über allem steht: Jede Prüfung läuft von außen, von einem Standpunkt, der kein besonderes Vertrauen genießt, denn die einzige Frage, die zählt, ist, was ein Fremder im Internet tatsächlich erreichen kann. Die erste Hälfte davon könnten Sie heute Abend gegen Ihre eigene Site laufen lassen. Der Grund, es uns zu übergeben, ist, wer die ganze Prüfreihe fährt, und von wo.
h2 (#stranger-sees): Die einzige Frage, die zählt: Was sieht ein Fremder tatsächlich?
Wir fahren den Scan von einer dedizierten Maschine in einem anderen unserer Rechenzentren, über eine Egress-IP, der unsere eigene Firewall nie zu vertrauen gelernt hat. Sie bekommt keinen Eintrag in einer Allowlist, keine Ausnahme, keine Höflichkeit. Sie sieht genau das, was das Internet sieht.
Das funktioniert nur, wenn der Standpunkt echt ist und außerhalb Ihrer Vertrauensgrenze liegt, weshalb es eine Maschine in einem anderen unserer eigenen Rechenzentren ist, in unserem eigenen AS, kein gemieteter Scanner. Es ist derselbe Grund, aus dem das Eigentum am Netzwerk überhaupt zählt. Mehr dazu in Ihnen gehört Ihr Netzwerk nicht.
Von diesem Standpunkt aus hören drei Dinge auf, Behauptungen zu sein, und werden Messungen. Ob Ihr CDN wirklich vor Ihrem Origin steht. Ob die Ports, die Sie für geschlossen halten, geschlossen sind. Und, nach einer Korrektur, ob die Tür, die Sie gerade geschlossen haben, tatsächlich zu ist. Der Rest beschreibt, wie wir jedes davon lesen.
h2 (#find-origin): Den echten Origin finden, wie ein Angreifer es täte
Der Origin leckt meist im eigenen Mail-DNS der Domain, weil der SPF-Eintrag, der Ihre E-Mail autorisiert, genau den Host nennt, der sie versendet. Sobald der echte Origin bekannt ist, pinnen Sie den Hostnamen direkt darauf, damit jedes Werkzeug den nackten Origin trifft statt das CDN, und lassen die komplette Prüfreihe dagegen noch einmal laufen.
# the origin usually leaks in the domain's own mail DNS
scanner$ dig +short TXT origin.example # the SPF record often names the sending host
scanner$ dig +short MX origin.example
# pin the hostname straight to the origin so nothing touches the CDN
scanner$ curl --resolve origin.example:443:<origin-ip> https://origin.example/
# now re-run the full battery against the naked origin, not the edge
scanner$ <scan battery> --target <origin-ip>Der Punkt, den das beweist, ist einfach. Wenn der Origin auf den gepinnten Scan genauso antwortet wie der öffentliche Hostname, dieselben Seiten ausliefert, dasselbe Login-Formular, dann werden das CDN und die WAF davor umgangen. Jede Anfrage, die ein Angreifer senden will, kann an ihnen vorbei.
h2 (#all-ports): Jeden Port scannen, dann sagen, was geschlossen ist
Vom Standpunkt außerhalb des Netzwerks scannen wir alle 65.535 Ports.
# from the box on an egress the firewall doesn't trust: every port, not a shortlist
scanner$ <port-scanner> -p 1-65535 <origin-ip>Ein Scan der gesamten Oberfläche ist nicht nur ein Ja oder Nein pro Port. Was antwortet, und wie, nimmt einen Fingerabdruck der Maschine. Drei Anzeichen kehren immer wieder.
a mismatched TLS cert on a production subnet -> a forgotten host, fingerprinted
an absurdly low firewall hit-count -> traffic isn't flowing the way you think
a DNS server answering REFUSED -> good: you are not an open resolverh2 (#firewall-not-waf): Eine Firewall ist keine WAF
Brute Force auf das Login ist auf Layer 3/4 unsichtbar, also lebt die Verteidigung am Edge, auf Layer 7.
Rate-Limit am Edge, dort, wo die Logins sind
: Zählen Sie Login-Fehlversuche pro Quelle auf der HTTP-Ebene, dem einzigen Ort, an dem sie sichtbar sind, und sperren Sie eine Quelle, die die Grenze überschreitet. Die Firewall hat den Angriff nie gesehen. Das Edge sieht nichts anderes.
Eskalation auf das Subnetz nach zwei Treffern
: Eine einzelne gesperrte Adresse ist trivial zu wechseln. Nach einem zweiten Treffer aus derselben Nachbarschaft weitet sich die Sperre auf das betroffene Subnetz aus, damit der Angreifer nicht einfach eine IP weiterrücken kann.
Wir sprechen den unbequemen Teil laut aus: Eine Subnetz-Sperre kann einen legitimen Benutzer treffen, der sein Passwort zweimal falsch eingegeben hat, von einer geteilten Adresse, einem Firmen-NAT, einem Campus, einem Café. Das sind echte Kosten, kein Rundungsfehler. Deshalb wird die Regel mit einem dokumentierten Überdruckventil für geteilte IPs ausgeliefert, nicht als dauerhafte Mauer.
h2 (#durable-fix): Die dauerhafte Korrektur: den Origin auf das CDN sperren, dann erneut angreifen
Die Korrektur besteht darin, den Origin per Firewall auf die veröffentlichten Bereiche des CDN zu beschränken. Dann dieselbe gepinnte Sonde, von derselben nicht vertrauenswürdigen Maschine:
# BEFORE: pin the naked origin, it serves the login page around the CDN
scanner$ curl --resolve origin.example:443:<origin-ip> https://origin.example/login
HTTP/1.1 200 OK # the origin answered. the CDN was bypassed.
# AFTER: origin firewalled to accept only the CDN's published ranges
scanner$ curl --resolve origin.example:443:<origin-ip> https://origin.example/login
curl: (7) Failed to connect to <origin-ip> port 443: Connection refusedHinter der Origin-Sperre sitzt die eigentliche Layer-7-WAF, das, was die Anfragen inspiziert, die das CDN tatsächlich weiterleitet, und eine gemeinsame Sperrliste: Ein Angreifer, der beim Abtasten eines Kunden erwischt wird, ist bei allen gesperrt, sodass die Aufklärung, die eine Site kartiert, bei jeder anderen Maut zahlt.
h2 (#we-fix-you-fix): Was wir beheben, und was wir an Sie zurückgeben
Wenn die Prüfung etwas findet, teilt sich die Arbeit in zwei Spalten. Die eine gehört uns, und wir erledigen sie in derselben Sitzung: härten am Edge der Infrastruktur, sofort. Die andere liegt in Ihrer Anwendung, und wir fassen Ihren Code nicht an. Wir geben Ihnen den genauen Befund und schirmen ihn in der Zwischenzeit ab, damit Sie nicht exponiert sind, während Sie ihn beheben.
| Was wir in derselben Sitzung beheben | Was wir Ihnen zum Beheben übergeben (in der Zwischenzeit abgeschirmt) |
|---|---|
| Den Origin auf die veröffentlichten Bereiche des CDN sperren | Das verwundbare Plugin, CMS oder die App aktualisieren oder entfernen |
| Layer-7-Brute-Force-Abwehr am Edge aufbauen | Geteilte oder voreingestellte Zugangsdaten rotieren |
| Exponierte Datenspeicher per Firewall auf das private Netzwerk beschränken | MFA auf den Konten aktivieren, die zählen |
| Die Informationslecks am Webserver abstellen | Die Exposition auf Anwendungsebene in Ihrem eigenen Code beheben |
h2 (#re-attack): Dann greifen wir erneut an, und beweisen, dass zu ist
Jede Korrektur oben endet auf dieselbe Weise: Wir gehen zurück zu der Maschine, der die Firewall nie zu vertrauen gelernt hat, lassen die Prüfreihe, die das Problem gefunden hat, erneut laufen, und bestätigen, dass dieselbe Messung jetzt geschlossen zurückkommt. Der gepinnte Origin liefert connection refused. Der Port, der geantwortet hat, ist dunkel. Der Befund, den wir Ihnen übergeben haben, verweigert sich, sobald Sie ihn geschlossen haben, auch uns.
Dieselbe Haltung, gerichtet auf die Frage, ob wir das Netzwerk, über das Ihr Traffic läuft, überhaupt kontrollieren, steht in Ihnen gehört Ihr Netzwerk nicht.
Klare Antworten
Wie beweisen Sie, dass eine Sicherheitskorrektur tatsächlich funktioniert hat?+
Wir vertrauen dem Patch nicht. Wir greifen den echten Origin von einer Maschine an einem Egress erneut an, dem unsere Firewall nie zu vertrauen gelernt hat, sodass sie sieht, was das Internet sieht. Wenn die Tür zu ist, antwortet ein gepinnter Scan des nackten Origin mit connection refused, nicht mit einer Login-Seite. In diesem Fall ist es ein Beweis, kein Versprechen.
Wie kann ein Angreifer ein CDN oder eine WAF umgehen und den Origin direkt treffen?+
Der Origin leckt meist im eigenen Mail-DNS der Domain, weil der SPF-Eintrag, der Ihre E-Mail autorisiert, den Host nennt, der sie versendet. Mit der echten Origin-Adresse pinnen Sie den Hostnamen direkt darauf, sodass jedes Werkzeug den nackten Origin trifft statt das CDN. Wenn der Origin genauso antwortet wie der öffentliche Hostname, werden CDN und WAF umgangen: Sie sind nur wirksam, wenn der Origin auf sie gesperrt ist. Die dauerhafte Korrektur besteht darin, den Origin per Firewall nur Traffic aus den veröffentlichten Bereichen des CDN annehmen zu lassen, wonach dieselbe Sonde connection refused bekommt.
Wie prüfen Sie, dass ein Port von außen wirklich geschlossen ist?+
Sie scannen alle 65.535 Ports von einem Standpunkt außerhalb des Netzwerks, nicht die üblichen paar, damit Sie positiv feststellen können, dass alles, was Sie nicht exponieren wollten, geschlossen ist. Ein vollständiger Scan fördert auch Anzeichen zutage: Ein unpassendes TLS-Zertifikat verrät einen vergessenen Host, eine absurd niedrige Trefferzahl der Firewall bedeutet, dass der Traffic nicht so fließt, wie Sie denken, und ein DNS-Server, der REFUSED antwortet, bestätigt, dass Sie kein offener Resolver sind.
Was beheben Sie, und was müssen wir selbst beheben?+
In derselben Sitzung härten wir am Edge der Infrastruktur: Wir sperren den Origin auf die Bereiche des CDN, bauen Brute-Force-Abwehr am Edge auf, beschränken exponierte Datenspeicher per Firewall auf das private Netzwerk und stellen Informationslecks am Webserver ab. Dann übergeben wir Ihnen den genauen Befund und schirmen ihn in der Zwischenzeit ab: das verwundbare Plugin, CMS oder die App aktualisieren oder entfernen, geteilte oder voreingestellte Zugangsdaten rotieren, MFA aktivieren und die Exposition auf Anwendungsebene in Ihrem eigenen Code beheben.
Wir schließen nicht einfach das Ticket. Wir beweisen, dass die Tür zu ist.
Sprechen Sie mit einem Ingenieur, der Ihren Origin von einer Maschine aus erneut angreift, die wir nie auf eine Allowlist gesetzt haben, und Ihnen das connection refused zeigt, das beweist, dass die Tür geschlossen ist.
Mit einem Ingenieur sprechenWenn Sie die Haltung wollen, die unter alledem liegt, beginnt sie damit, dass Ihnen das Netzwerk gehört, von dem aus Sie verteidigt werden: Ihnen gehört Ihr Netzwerk nicht.
Sie 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