Was kann ein kompromittiertes Web-Gateway noch erreichen?
Ein Web-Gateway begrenzt, was ein Besucher öffnet, nicht was ein kompromittierter Host ansprechen kann. Zwei Prüfungen, eine Befugnistabelle und Befehle zur Reichweitenmessung.
Angenommen, der Gateway-Host wird kompromittiert, während sein Zertifikat noch gültig ist. Jede Regel, die festlegte, welche Seiten ein Besucher anfordern darf, bleibt in Kraft, und keine dieser Regeln beschränkt die Verbindung, die der Angreifer jetzt von diesem Host aus in Richtung des Datenbank-Subnetzes öffnet. Genau diese Lücke ist der Grund, warum ein reiner Web-Einstiegspunkt nicht dieselbe Aussage ist wie ein segmentiertes Netz. Die beiden Aussagen erfordern getrennte Prüfungen, von unterschiedlichen Ausgangspunkten aus, bevor eine von ihnen ehrlich getroffen werden kann.
Zwei Aussagen, und nur eine beginnt beim Besucher
Die erste Aussage betrifft eine Person: Ein Besucher mit Browser und gültiger Sitzung kann eine Anwendung öffnen und sonst nichts. Ein reiner Web-Einstiegspunkt beantwortet diese Aussage gut, weil der Besucher eine Seite statt einer Route erhält. Diese Antwort ist es wert, und sie ist zugleich die einzige Aussage, die die meisten Diagramme festhalten.
Die zweite Aussage betrifft eine Komponente: Vom Gateway oder dem Anwendungsprozess dahinter wird angenommen, dass er unter fremder Kontrolle steht. Aus dieser Annahme verschiebt sich die Frage von erlaubten URLs zu den Zielen und Identitäten, die der Prozess noch erreichen kann.
Die beiden Aussagen haben unterschiedliche Eigentümer, liefern unterschiedliche Nachweise und scheitern unabhängig. Ein Identitätsteam kann die erste mit einem Sitzungstest belegen; die zweite braucht Netzwerkrichtlinien, eine Überprüfung des Dienstkontos und Host-Kontrollen. Ein Entwurf, der nur die Besucherhälfte festhält, wirkt auf einer Prüfungsfolie vollständig und während eines Vorfalls dünn, weil die Kontrollen, die nach einer Kompromittierung zählen, nie im Umfang waren. Benennen Sie, welche Aussage jede Kontrolle stützt, sonst wird eine Gateway-Regel beiden zugeschrieben.
Ein durchgerechnetes Ausgabendienst-Beispiel und die zwei Arten, wie es verliert
Nehmen wir einen Ausgabendienst: Ein öffentliches Gateway auf 10.60.4.10 authentifiziert Mitarbeiter und leitet genehmigte Anfragen an einen Anwendungs-Listener auf Port 8443 weiter, und diese Anwendung erreicht einen PostgreSQL-Listener auf 10.60.4.20:5432 als Rolle expenses_app. Mitarbeiter sollen keinen allgemeinen internen Zugang erhalten. Im Normalbetrieb liefert der Entwurf tatsächlich einen anwendungsspezifischen Einstieg, ohne den Datenbank-Listener irgendwo zu veröffentlichen. Die Adressen zählen, weil jede spätere Prüfung in diesem Artikel sie benennt.
Nehmen Sie nun das Gateway aus der vertrauenswürdigen Menge. Welche Ziele kann 10.60.4.10 erreichen, sobald sein Prozess einem Angreifer gehört? Der URL-Filter, der Besucher beschränkte, sagt nichts über eine Verbindung, die der Gateway-Host in Richtung des Datenbank-Subnetzes öffnet.
Entfernen Sie stattdessen den Anwendungsprozess, und die Befugnisse ändern ihre Form: die Rolle expenses_app, die Dienste, die dieser Server erreichen kann, und die Dateien, die dieses Konto lesen kann. In beiden Fällen kann die Vordertür reines Web bleiben, während die Backend-Grenze fehlt. Das Etikett an der Vordertür ist daher keine Antwort auf eine der beiden Fragen.
Abbilden, welche Befugnisse jede Partei tatsächlich besitzt
Ein als beabsichtigte Berechtigungen geschriebener Vertrag neigt dazu, den Entwurf an Sie zurückzugeben. Schreiben Sie ihn als gehaltene Befugnis, als Prüfung, die den Überschuss widerlegt, und als Eigentümer dieser Prüfung, dann wird jede Zeile testbar. Diese Tabelle ist ein Vorschlag für das obige Beispiel, keine Produktaussage:
| Component | Authority it actually holds | Check that proves the denial | Owner of the check |
|---|---|---|---|
| Identity provider | Issues assertions and session cookies, and holds no network path of its own | A request to the application URL without a session is redirected to the login page | Identity team |
| Public gateway host | TCP reachability to whatever its routing table and egress rules permit | An egress rule drops 10.60.4.20:5432 and the probe reports the port filtered | Network platform team |
| Application role | SQL privileges granted to expenses_app inside the expenses database | A privilege query shows no ownership or create right on any other schema | Application team |
| Database listener | Accepts connections only from the source ranges named in its host-based rules | A connection from an unlisted address is refused before authentication | Database administrator |
| Management path | Administrative access reserved for patching, monitoring and recovery | A staff workstation cannot reach the administrative port or jump through it | Platform owner |
Eigentum folgt der Befugnis. Das Identitätsteam besitzt Assertions, das Netzwerkplattformteam besitzt Pfade, das Anwendungsteam besitzt die Datenbankrolle, der Datenbankadministrator besitzt den Listener und seine hostbasierten Regeln, und der Plattform-Eigentümer besitzt die Managementebene. Eine Ablehnung ohne Eigentümer ist ein Satz in einem Dokument statt einer Kontrolle.
Die Aufteilung verhindert auch Doppelzählung. Eine Portbeschränkung kann kein Tabellenprivileg ausdrücken, und eine Datenbankrolle kann nicht verhindern, dass ein Host einen Socket zu einem unrelated Subnetz öffnet.
Aufzählen, was das Gateway erreichen kann, statt es zu behaupten
Eine Grenzaussage ist nur so gut wie die Aufzählung dahinter. Auf dem Gateway-Host decken drei Befehle die Routenauswahl, eine Live-Sonde und die Egress-Richtlinie ab:
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter outputLesen Sie die Ausgabe in dieser Reihenfolge. Die Route sagt, ob 10.60.4.20 von diesem Host überhaupt ausgewählt wird; die Sonde sagt, ob der Listener antwortet; die Regelliste zeigt, ob die Richtlinie das Paket stoppt oder ob nie etwas in seinem Pfad war.
Wiederholen Sie die Aufzählung vom Anwendungshost aus. Von dort ist die Datenbankseite eine Abfrage, die als Anwendungsrolle ausgeführt wird:
psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'Eine erfolgreiche Verbindung unter einer Rolle, die kein anderes Schema lesen kann, ist ein anderes Ergebnis als eine erfolgreiche Verbindung unter einer Eigentümerrolle. Nur die zweite ist ein Befund.
Die Ablehnungen festhalten, dann die Prüfung datieren
Akzeptanz wird als Ergebnisse geschrieben, nicht als Absichten: Eine Mitarbeitersitzung kann den Listener nicht erreichen, der Gateway-Host kann kein unrelated Subnetz erreichen, und die Anwendungsrolle kann keine Datenbank erstellen. Jede ist eine eigene Prüfung mit benanntem Eigentümer und Datum.
Halten Sie Überwachung, Patchen und Wiederherstellung über den dafür vorgesehenen Managementpfad erreichbar. Eine Grenze, die auch ihren Eigentümer blockiert, wird zu einem Ausfall, und die übliche erste Reaktion auf diesen Ausfall ist, die Regel wieder zu erweitern. Die CISA-Perimeterempfehlung verlangt, eingehenden und ausgehenden Zugang auf begründete Ports und Protokolle zu beschränken, einschließlich Verkehr zwischen internen Netzen, also die vom Backend ausgehende Richtung, die die meisten Diagramme auslassen.
Datieren Sie die Prüfung und benennen Sie ihren Eigentümer. Führen Sie die Aufzählung und die Privilegienabfrage nach jeder Änderung am Gateway-Image, an der Routentabelle oder an der Anwendungsrolle erneut aus.