Do czego wciąż może dotrzeć skompromitowana brama internetowa?
Brama internetowa ogranicza to, co otwiera odwiedzający, a nie to, do czego może dotrzeć skompromitowany host. Dwa przeglądy, tabela uprawnień i polecenia pomiaru zasięgu.
Załóżmy, że host bramy został skompromitowany, gdy jego certyfikat jest nadal ważny. Każda reguła określająca, które strony odwiedzający może żądać, pozostaje w mocy, a żadna z tych reguł nie ogranicza połączenia, które atakujący otwiera teraz z tego hosta w stronę podsieci bazy danych. Właśnie ta luka sprawia, że punkt wejścia tylko dla sieci web nie jest tym samym twierdzeniem co sieć segmentowana. Oba twierdzenia wymagają osobnych przeglądów, z różnych punktów wyjścia, zanim którekolwiek z nich można uczciwie postawić.
Dwa twierdzenia, i tylko jedno z nich zaczyna się u odwiedzającego
Pierwsze twierdzenie dotyczy osoby: odwiedzający z przeglądarką i ważną sesją może otworzyć jedną aplikację i nic więcej. Punkt wejścia tylko dla sieci web dobrze odpowiada na to twierdzenie, ponieważ odwiedzający otrzymuje stronę, a nie trasę. Ta odpowiedź jest warta zachowania i jest też jedynym twierdzeniem, które rejestruje większość diagramów.
Drugie twierdzenie dotyczy komponentu: zakłada się, że brama lub proces aplikacji za nią znajduje się pod kontrolą kogoś innego. Z tego założenia pytanie zmienia się z tego, które adresy URL są dozwolone, na to, do jakich celów i tożsamości proces wciąż może dotrzeć.
Oba twierdzenia mają różnych właścicieli, dają różne dowody i zawodzą niezależnie. Zespół tożsamości może wykazać pierwsze testem sesji; drugie wymaga polityki sieciowej, przeglądu konta usługi i kontroli hosta. Projekt, który rejestruje tylko połowę odwiedzającego, wygląda kompletnie na slajdzie przeglądu i cienko podczas incydentu, ponieważ kontrole istotne po kompromitacji nigdy nie były w zakresie. Nazwij, które twierdzenie wspiera każda kontrola, inaczej jedna reguła bramy zostanie zaliczona do obu.
Opracowany przykład usługi wydatków i dwa sposoby, w jakie przegrywa
Weźmy usługę wydatków: publiczna brama pod 10.60.4.10 uwierzytelnia pracowników i przekazuje zatwierdzone żądania do odbiornika aplikacji na porcie 8443, a ta aplikacja dociera do jednego odbiornika PostgreSQL pod 10.60.4.20:5432 jako rola expenses_app. Pracownicy nie mają otrzymywać ogólnego dostępu wewnętrznego. W normalnej pracy projekt rzeczywiście zapewnia wejście specyficzne dla aplikacji, nie publikując odbiornika bazy danych nigdzie. Adresy mają znaczenie, ponieważ każde późniejsze sprawdzenie w tym artykule je wymienia.
Teraz usuń bramę ze zbioru zaufanego. Do jakich celów może dotrzeć 10.60.4.10, gdy jego proces należy do atakującego? Filtr URL, który ograniczał odwiedzających, nic nie mówi o połączeniu, które host bramy otwiera w stronę podsieci bazy danych.
Usuń zamiast tego proces aplikacji, a uprawnienia zmieniają kształt: rola expenses_app, usługi, do których ten serwer może dotrzeć, i pliki, które to konto może czytać. W obu przypadkach frontowe drzwi mogą pozostać tylko webowe, podczas gdy granica backendu nie istnieje. Dlatego etykieta na frontowych drzwiach nie jest odpowiedzią na żadne z dwóch pytań.
Zmapuj uprawnienia, które każda strona faktycznie posiada
Umowa napisana jako zamierzone uprawnienia ma zwyczaj powtarzać projekt z powrotem. Napisz ją jako posiadane uprawnienie, kontrolę, która obala nadmiar, i właściciela tej kontroli, a każdy wiersz stanie się testowalny. Ta tabela jest propozycją dla powyższego przykładu, a nie twierdzeniem o produkcie:
| 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 |
Własność podąża za uprawnieniem. Zespół tożsamości posiada asercje, zespół platformy sieciowej posiada trasy, zespół aplikacji posiada rolę bazy danych, administrator bazy danych posiada odbiornik i jego reguły oparte na hoście, a właściciel platformy posiada płaszczyznę zarządzania. Odmowa bez właściciela to zdanie w dokumencie, a nie kontrola.
Podział zapobiega też podwójnemu liczeniu. Ograniczenie portu nie może wyrazić przywileju tabeli, a rola bazy danych nie może powstrzymać hosta przed otwarciem gniazda do niepowiązanej podsieci.
Wylicz, do czego brama może dotrzeć, zamiast to twierdzić
Twierdzenie o granicy jest tylko tak dobre, jak wyliczenie za nim. Na hoście bramy trzy polecenia obejmują wybór trasy, test na żywo i politykę wyjścia:
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter outputCzytaj wynik w tej kolejności. Trasa mówi, czy 10.60.4.20 jest w ogóle wybierany z tego hosta; test mówi, czy odbiornik odpowiada; lista reguł pokazuje, czy polityka zatrzymuje pakiet, czy w jego ścieżce nigdy nic nie było.
Powtórz wyliczenie z hosta aplikacji. Stamtąd strona bazy danych to jedno zapytanie uruchomione jako rola aplikacji:
psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'Udane połączenie pod rolą, która nie może czytać innego schematu, to inny wynik niż udane połączenie pod rolą właściciela. Tylko to drugie jest ustaleniem.
Zapisz odmowy, a następnie opatrz przegląd datą
Akceptacja jest zapisywana jako wyniki, a nie zamiary: sesja pracownika nie może dotrzeć do odbiornika, host bramy nie może dotrzeć do niepowiązanej podsieci, a rola aplikacji nie może utworzyć bazy danych. Każde z nich to osobna kontrola z nazwanym właścicielem i datą.
Utrzymuj monitorowanie, łatanie i odtwarzanie dostępne przez ścieżkę zarządzania zaprojektowaną dla nich. Granica, która blokuje także swojego właściciela, staje się awarią, a zwykłą pierwszą reakcją na tę awarię jest ponowne poszerzenie reguły. Wytyczne CISA dotyczące obwodu wymagają ograniczenia dostępu przychodzącego i wychodzącego do uzasadnionych portów i protokołów, w tym ruchu między sieciami wewnętrznymi, czyli kierunku inicjowanego przez backend, który większość diagramów pomija.
Opatrz przegląd datą i wskaż jego właściciela. Uruchom ponownie wyliczenie i zapytanie o uprawnienia po każdej zmianie obrazu bramy, tabeli routingu lub roli aplikacji.