Origin-IP hinter einem CDN: wie sie leckt und wie Sie sie sperren

Die Vordertür und die Hintertür

Ein CDN oder eine Cloud-WAF sitzt vor dem Server und bedient den Hostnamen. Richten Sie einen Scanner auf diesen Hostnamen, und die Anfrage geht an das Edge: das TLS des Edge, die Header des Edge, die Rate-Limits und Regeln des Edge. Ein grüner Bericht ist ein Bericht über das Edge. Der Origin, der eigentliche Server, wurde von diesem Scan nicht berührt, und was er direkt exponiert, bleibt für jeden exponiert, der ihn über die Adresse statt über den Namen erreicht.

Wo der Origin leckt

Die Adresse ist selten gut versteckt, weil die Domain sie zu anderen Zwecken veröffentlicht. Der SPF-Eintrag ist der häufige Fall. Eine SPF-Richtlinie, die den Mechanismus a verwendet, autorisiert den eigenen A-Eintrag der Domain zum Versand von E-Mail, und dieser A-Eintrag ist der Origin hinter dem CDN. Der Mechanismus mx zeigt auf die Mail-Hosts, die oft im selben Bereich liegen. Ein wörtliches ip4: schreibt sie aus.

$ dig +short TXT example.com
"v=spf1 a mx ip4:<address> include:_spf.<mail-provider> ~all"
$ dig +short MX example.com
$ dig +short A mail.example.com ftp.example.com staging.example.com origin.example.com

Jenseits von SPF: Subdomains, die nie hinter das CDN gestellt wurden (mail, ftp, ein Control Panel, staging, ein nackter Origin-Host) und direkt auf den Server auflösen. Certificate-Transparency-Logs, die jedes für einen Namen ausgestellte Zertifikat aufzeichnen, einschließlich dessen auf dem Origin-Host. Passive-DNS-Datenbanken, die den A-Eintrag aus der Zeit vor Einführung des CDN aufbewahren. Die Received-Header jeder E-Mail, die der Webserver versendet, die den Host nennen, von dem sie kam. Und Anwendungsfunktionen, die den Server auf Anfrage nach außen verbinden lassen, wie Pingbacks und Webhook-Tests, die dem Empfänger des Aufrufs die verbindende Adresse zeigen.

Den Origin pinnen und scannen, was ein Angreifer scannt

Sobald die Adresse bekannt ist, bringen Sie die Werkzeuge dazu, das CDN zu ignorieren. curl kann das pro Anfrage. Scanner, die es nicht können, bekommen einen Eintrag in der hosts-Datei. Führen Sie das von einer Maschine aus, die weder in Ihrem eigenen Netzwerk noch auf einer Allowlist steht, der der Origin vertraut, denn ein Scan von einer vertrauenswürdigen Adresse berichtet, was vertrauenswürdige Adressen sehen.

# per request, no hosts-file change
$ curl --resolve example.com:443:<address> -sI https://example.com/

# for tools without --resolve
$ echo "<address>  example.com" | sudo tee -a /etc/hosts

Führen Sie im Ergebnis zwei Spalten. Die Infrastrukturspalte: welche Ports antworten, welche TLS-Versionen akzeptiert werden, ob Banner Softwarenamen preisgeben. Die Anwendungsspalte: nicht authentifizierte Endpoints, die Benutzer aufzählen, Debug- oder Logdateien, die im Web-Root lesbar sind, administrative Pfade, die ohne zweiten Faktor erreichbar sind, Komponenten hinter ihrem aktuellen Release. Eine gehärtete Maschine, die eine offene Anwendung ausliefert, ist keine sichere Site, und die beiden Spalten werden nicht zu einem Urteil verrechnet.

Den Origin auf das CDN sperren

Die strukturelle Korrektur findet am Origin statt, nicht am Edge. Die Web-Ports antworten nur noch den veröffentlichten Adressbereichen des CDN, alles andere wird standardmäßig abgewiesen. Auf einem Host mit firewalld:

# load the CDN's published ranges into an ipset, then allow only them on 443
$ firewall-cmd --permanent --new-ipset=cdn-v4 --type=hash:net
$ firewall-cmd --permanent --ipset=cdn-v4 --add-entries-from-file=cdn-ranges-v4.txt
$ firewall-cmd --permanent --zone=public --remove-service=http
$ firewall-cmd --permanent --zone=public --remove-service=https
$ firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source ipset="cdn-v4" port port="443" protocol="tcp" accept'
$ firewall-cmd --reload
$ firewall-cmd --ipset=cdn-v4 --get-entries

Zwei Details entscheiden, ob das hält. Die Bereiche des CDN ändern sich, also wird die Datei nach Zeitplan aus der veröffentlichten Liste des CDN aufgefrischt und das ipset damit neu geladen. Und jedes Präfix in einer Allowlist wird nach dem Laden zurückgelesen: Eine um ein Zeichen vertippte Präfixlänge lässt einen großen Teil des Internets herein und sieht in der Datei normal aus.

Adressbereiche sind das erste Schloss, nicht das einzige. Die meisten CDNs können ihre Pulls zum Origin mit einem Client-Zertifikat authentifizieren. Verlangen Sie es am Webserver, damit eine Anfrage aus einem CDN-Bereich, die das Zertifikat nicht vorlegt, trotzdem abgewiesen wird. Beseitigen Sie dann die verbleibenden Lecks: ein SPF-Eintrag, der nur die Hosts nennt, die E-Mail versenden, keine Subdomains ohne Proxy, die auf den Origin zeigen, und, wo praktikabel, eine neue Origin-Adresse, sobald das Schloss sitzt, denn die alte bleibt auf unbestimmte Zeit im Passive DNS.

Von außen verifizieren

Führen Sie den gepinnten Scan vom selben nicht vertrauenswürdigen Standpunkt erneut aus. Der Origin verweigert die Verbindung auf 443, und der Hostname wird weiterhin über das CDN ausgeliefert. Wiederholen Sie das nach jeder Änderung an den Bereichen oder an der Webserver-Konfiguration. Wie daraus eine ständige Prüfung statt einer einmaligen Aktion wird, ist das Thema von Beweisen Sie von außen, dass zu ist.

$ curl --resolve example.com:443:<address> -m 5 -sI https://example.com/ ; echo "exit $?"
exit 28
# a timeout (28) or a refused connection (7) is the correct answer from the locked origin