Wewnętrzny ALB z publiczną nazwą DNS: czy naprawdę jest wystawiony?

Uruchom publiczne zapytanie DNS do wewnętrznego load balancera, a możesz otrzymać prywatny adres, co wygląda na błąd konfiguracji, dopóki nie sprawdzisz, do czego służy rekord. AWS dokumentuje, że nazwy wewnętrznych load balancerów mogą być publicznie rozwiązywalne, choć ich węzły mają tylko prywatne adresy. Resolver odpowiedział, gdzie jest usługa; nie utworzył trasy, nie otworzył grupy zabezpieczeń ani nikogo nie uwierzytelnił. Czy ta odpowiedź jest problemem, zależy od faktów, które można sprawdzić po kolei.

Krok pierwszy: czytaj schemat, nie IP

Pole schematu to własne oświadczenie load balancera o jego granicy. aws elbv2 describe-load-balancers --names app-internal zwraca Scheme o wartości internal lub internet-facing, plus typ adresu dla IPv4 lub podwójnego stosu. Load balancer skierowany do internetu nadal może przekazywać do celów prywatnych, więc widok prywatnych adresów backendu niczego nie dowodzi o frontendzie.

Zapisz schemat, zanim spojrzysz na cokolwiek innego, bo każda późniejsza ocena od niego zależy. Mówi też, jakie kontrolki istnieją, od grup zabezpieczeń i reguł listenera po zestaw funkcji tego typu load balancera. Schemat skopiowany ze starego zrzutu konsoli jest gorszy niż brak notatki. Odczytaj go ponownie z API i wklej wartość do zgłoszenia.

Krok drugi: sprawdź, na co rozwiązuje się nazwa

Zapytaj spoza VPC za pomocą dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com i zanotuj, czy odpowiedzi mieszczą się w 10.0.0.0/8, 172.16.0.0/12 lub 192.168.0.0/16. Prywatna odpowiedź publicznego resolvera to oczekiwane zachowanie dla nazwy wewnętrznego load balancera; nie jest dowodem, że adres jest routowalny z internetu.

Rozwiąż tę samą nazwę od wewnątrz VPC i porównaj. Jeśli dwie odpowiedzi się różnią, widzisz nazewnictwo split-horizon, a ta różnica jest szczegółem projektu, nie wyciekiem.

Krok trzeci: wymień ścieżki, które mogą do niego dotrzeć

Prywatny adres jest osiągalny wszędzie, gdzie istnieje trasa i reguła zabezpieczeń. Wymień je świadomie: VPN między lokacjami, VPN klienta, VPC peering, połączenia transit gateway, Direct Connect oraz dowolne proxy lub bastion wewnątrz VPC. Jedna z nich jest zamierzoną ścieżką, a pozostałe to te, których szukałby atakujący.

Następnie sprawdź kontrolki na każdej ścieżce: grupy zabezpieczeń na load balancerze, sieciowe ACL na podsieciach i routing, który w ogóle tworzy ścieżkę. Większość zgłoszonych przypadków wystawionej usługi wewnętrznej rozwiązuje się tutaj: albo istniał niezamierzony peering, albo ścieżka była zamierzona, a aplikacja nie miała uwierzytelniania.

Krok czwarty: przetestuj listener i aplikację osobno

Spróbuj połączyć się z sieci, która nie powinna docierać do usługi, i potwierdź, że nie możesz. Następnie spróbuj z tej, która powinna, i potwierdź, że docierasz do listenera. Te dwa wyniki oddzielają osiągalność sieci od zachowania aplikacji i są jedynym dowodem, który liczy się w kwestii wystawienia.

Osiągalny listener to nie to samo co dostępna aplikacja. Sprawdź certyfikat TLS i politykę protokołu, a potem uwierzytelnianie i autoryzację samej aplikacji. Wewnętrzne narzędzie, które przyjmuje dowolnego wywołującego w firmowym VPN, jest wystawione na każdy zainfekowany laptop w tym VPN, co jest innym ryzykiem niż wystawienie do internetu, ale nadal ryzykiem.

Pamiętaj, że kontrolki różnią się w zależności od typu. Zapory warstwy aplikacji podłączają się do jednej rodziny load balancerów, a nie do drugiej, więc potwierdź, co jest rzeczywiście dostępne dla schematu i typu przed tobą, zamiast zakładać równość.

Krok piąty: zdecyduj, czy sama nazwa ma znaczenie

Publiczna rozwiązywalność może ujawnić nazwę usługi, region i zakres adresów. Traktuj to jako kwestię ujawnienia informacji z odpowiedzią polityki, a nie automatyczny incydent: trzymaj wrażliwe terminy biznesowe poza nazwami zasobów i odnotuj ujawnienie w rejestrze ryzyka, jeśli konwencja nazewnictwa zdradza więcej, niż chcesz.

Jeśli organizacja chce prywatnego nazewnictwa, prywatna strefa hostowana może udostępnić alias, który rozwiązuje się tylko w powiązanych VPC. To zmienia nazwę widoczną dla użytkowników; nie czyni nazwy generowanej przez dostawcę tajną i nie usuwa żadnej ścieżki sieciowej.

Nie próbuj przypinać adresów, aby ukryć odpowiedź. Adresy load balancera się zmieniają, przypinanie psuje nawyki walidacji TLS, a kontrolka, której naprawdę potrzebujesz, to kto może nawiązać połączenie i czego aplikacja od niego wymaga. Sprawdź cztery fakty, zapisz je, a pytanie przestaje być niejednoznaczne.