Reguła EC2 tylko dla VPN: każda dołączona grupa zabezpieczeń musi się zgodzić

Dodajesz jedną regułę przychodzącą dla puli klientów VPN, niczego nie usuwasz, a usługa nadal jest osiągalna z internetu. Nic nie jest zepsute. Grupa zabezpieczeń nie ma nadpisania, priorytetu ani ostatecznego zakazu, przeciwko którym wąska reguła mogłaby wygrać. Każda grupa dołączona do instancji dokłada własne zezwolenia do jednego połączonego zbioru, a szeroka reguła, o której zapomniałeś, nadal jest w tym zbiorze. Uczynienie instancji tylko-VPN oznacza audyt wszystkich grup, a nie dodanie lepiej brzmiącej reguły do jednej z nich.

Zapisz usługę, zanim napiszesz regułę

Zacznij od dokładnego celu, protokołu i portu oraz interfejsu sieciowego, na którym usługa naprawdę nasłuchuje. Instancja z wieloma interfejsami lub wieloma usługami na jednym porcie wymaga audytu dla każdego interfejsu, ponieważ dołączone grupy mogą się różnić. Następnie ustal jaki adres źródłowy ten interfejs naprawdę otrzymuje dla użytkownika VPN, a nie adres, który klient pokazuje we własnym oknie połączenia.

Te dwa adresy rozchodzą się częściej, niż ludzie oczekują, gdy w grę wchodzi translacja i routing.

Trzy modele źródła, trzy różne reguły

Przy prywatnym dostępie routowanym instancja otrzymuje pulę klientów lub zakres firmowy, zależnie od tego, jak ścieżka jest routowana i tłumaczona. Przy publicznym punkcie końcowym osiąganym przez wyjście firmowe instancja widzi zamiast tego firmowy adres NAT, i tylko jeśli ten cel naprawdę korzysta ze ścieżki VPN, ponieważ tunelowanie dzielone może pozostawić go na połączeniu domowym. Przy zarządzanym punkcie końcowym Client VPN obowiązuje udokumentowany model skojarzenia i sieci docelowej, a adres klienta pochodzi ze skonfigurowanego CIDR klienta.

Nie działa odwoływanie się do bramy VPN jako źródła grupy zabezpieczeń. Odwołania do grup pasują do elastycznych interfejsów sieciowych wewnątrz VPC lub sieci połączonej, a brama przekazująca pakiety nie jest jednym z nich.

Przeczytaj sumę we wszystkich dołączonych grupach

Otwórz instancję, znajdź jej interfejs sieciowy i wylistuj każdą dołączoną do niego grupę zabezpieczeń. Dla każdej sprawdź każdą regułę obejmującą twój protokół i port, w tym szerokie zakresy portów i obie rodziny adresów. Reguła IPv4 z 0.0.0.0/0 nie zwalnia cię ze sprawdzenia ::/0, a reguła zezwalająca na cały ruch całkowicie ukrywa kwestię portu. Dopiero po tym spisie możesz powiedzieć, jakie jest rzeczywiste uprawnienie dla usługi.

Dokumentacja reguł AWS opisuje grupy zabezpieczeń jako tylko-zezwalające i stwierdza, że reguły ze wszystkich dołączonych grup są agregowane, i to jest cały mechanizm stojący za tą awarią.

ACL sieciowe to osobna, bezstanowa polityka z uporządkowanymi wpisami zezwalającymi i zakazującymi, oceniana na podsieci, a nie na instancji.

Nie odpowiadaj ścianą zakazów

Dodanie zakazu NACL na całą podsieć, aby naśladować zaporę, do której przywykłeś, to niewłaściwe narzędzie i ryzykowne. Wpisy NACL są uporządkowane i bezstanowe, więc zakaz umieszczony nad istniejącym zezwoleniem po cichu psuje niezwiązany ruch, w tym ścieżkę powrotną dla sesji, które próbowałeś zachować. Napraw szerokie zezwolenie grupy zabezpieczeń w grupie, która je posiada, a następnie zostaw ACL w spokoju, chyba że naprawdę jest częścią projektu.

Usunięcie publicznego adresu z instancji to mocniejsza gwarancja, a także zmiana architektoniczna z konsekwencjami administracyjnymi i aplikacyjnymi, a nie pole wyboru na liście dozwolonych.

Testuj z nową sesją i zachowaj drogę wejścia

Zanim wycofasz jakiekolwiek istniejące zezwolenie, potwierdź zatwierdzoną niezależną ścieżkę administracyjną, ponieważ reguła, którą zamierzasz usunąć, może być tą, od której zależy odzyskanie sesji. Następnie przetestuj nowe dozwolone połączenie z VPN i nowe odrzucone połączenie z autoryzowanej ścieżki testowej poza VPN. Istniejące śledzone sesje przeżywają zmiany reguł w sposób, który czyni stare otwarte powłoki bezużytecznymi jako dowód akceptacji.

Na koniec zachowaj własną autoryzację aplikacji. Przetłumaczone wyjście firmowe może reprezentować setki osób, a wejście do sieci nigdy nie zidentyfikowało pojedynczego użytkownika ani jego urządzenia.