Wprowadzenie
Sieć to miejsce, w którym znajdują się kluczowe zasoby przedsiębiorstwa, które przekształciło się w zdecentralizowane, rozproszone oraz coraz bardziej złożone i podatne na zagrożenia środowisko. To sprawia, że wyzwaniem jest zabezpieczenie tak szerokiej powierzchni ataku oraz połączeń między użytkownikami a zasobami oraz samymi zasobami. Wiele dotychczasowych metod zabezpieczeń nie jest już wystarczających, pozostawiając drzwi szeroko otwarte dla napastników.
Jednym z przykładów jest pukanie portów, które jest poprzednikiem autoryzacji pojedynczych pakietów (SPA). Jest to mechanizm, który zewnętrznie otwiera porty na firewallu poprzez tworzenie prób połączenia na zestawie zamkniętych portów. Po otrzymaniu autoryzowanej sekwencji prób połączenia, reguły zapory są dynamicznie modyfikowane i host wysyłający otrzymuje pozwolenie na połączenie przez określone porty.
Ale pukanie portów jest całkowicie zależne od solidności demona pukania portów. Jeśli demon zawiedzie, dostęp zostanie odmówiony wszystkim użytkownikom, a to tworzy pojedynczy punkt awarii. Demon monitorujący procesy musi być wykorzystany do ponownego uruchomienia niedziałającego lub zatrzymanego procesu demona port knocking.
Innym wyzwaniem związanym z port knocking jest wykorzystanie go bez kryptograficznych haseł. Może to sprawić, że sieci będą podatne na ataki typu spoofing adresu IP/denial-of-service (DoS).
Ponadto, sieci z dużym opóźnieniem mogą mieć problemy z port knocking, ponieważ opierają się na pakietach przychodzących w prawidłowej kolejności. Czas może nie być zgodny z protokołem kontroli transmisji (TCP), który łączy nieuporządkowane pakiety w jedną całość pakietów w poprawną sekwencję. Oznacza to, że klient może być zmuszony do ponownego wysłania poprawnej sekwencji, aż w końcu zostanie ona rozpoznana przez serwer. SPA, który używa pojedynczego tajnego puknięcia i nie opiera się na sekwencji autoryzacji, został stworzony w celu wyeliminowania wielu nieodłącznych podatności związanych z port knockingiem. SPA ukrywa odsłonięte porty protokołu przed rozpoznaniem przez operatora zagrożenia za „drzwiami ochronnymi”, które można otworzyć tylko za pomocą autoryzowanych kluczy i tokenów.
Jak działa SPA
– Urządzenie lub użytkownik może odblokować drzwi ochronne i wejść w interakcję z określonymi zasobami docelowymi tylko po autoryzacji za pomocą SPA.
– Podstawowym założeniem SPA jest to, że wszystkie połączenia na port 443 wymagają wysłania unikalnej i kryptograficznie zabezpieczonej wiadomości do odpowiedniego miejsca docelowego, aby się z nim skomunikować. Wiadomość ta może być wysłana za pomocą jednego z protokołów warstwy 4 (L4), TCP lub UDP. Oprócz danych związanych z SPA, komunikat zawiera informacje na temat usługi, do której połączenie chce uzyskać dostęp.
– Krytycznym czynnikiem jest to, że wiadomość autoryzacyjna jest szyfrowana symetrycznym kluczem 256-bitowym, znanym tylko przez nadawcę i konkretne miejsce przeznaczenia. W rezultacie, urządzenie może odszyfrować wiadomość i sprawdzić, czy żądanie dostępu do usługi jest legalne.
– SPA dodaje ważną, dodatkową warstwę bezpieczeństwa. Na przykład, bez SPA, każdy może zobaczyć że port 443 jest otwarty i że przyjmuje wiadomości „TLS ClientHello”. W związku z tym, napastnik mógłby znaleźć ten port i spróbować wykorzystać jakąś znaną lub zerową lukę w OpenSSL, aby naruszyć system. W przypadku SPA-TCP, atakujący nie ma pojęcia o istnieniu takiej usługi, a w przypadku SPA-UDP nie może nawet zobaczyć, że jakikolwiek port jest otwarty. Każda opcja protokołu ma zalety i pożądane możliwości.
Jak Appgate SDP ulepsza standard SPA
Appgate SDP, wiodące w branży rozwiązanie Zero Trust Network Access (ZTNA), przenosi SPA na zupełnie nowy poziom dzięki unikalnej implementacji, która zawiera kilka kluczowych korzyści odróżniających ją od innych.
Appgate SDP posiada zastrzeżony mechanizm TCP/UDP SPA, który wykorzystuje najlepsze cechy obu protokołów i może zatwierdzić, kto w sieci jest w stanie zobaczyć drzwi do swoich ważnych zasobów.
Pełna weryfikacja autoryzacji. Gdy rzekomo ważne źródło SPA lub klient żąda dostępu od urządzenia Appgate SDP, nie odpowie ono informacją usługi lub informacji o porcie protokołu, chyba że nadawca zostanie zweryfikowany jako zaufane i autoryzowane źródło. Bez niezbędnej weryfikacji klucza, urządzenie i chronione przez nie krytyczne zasoby, które chronią, są całkowicie ukryte przed wścibskimi oczami.
2. Działa za translacją adresów sieciowych (NAT). Większość implementacji SPA jest ograniczona ponieważ nie ma rozróżnienia między urządzeniami za bramą NAT. Innymi słowy, jeśli jeden użytkownik siedzący za NAT może dostarczyć niezbędnych kluczy dostępu, aby otworzyć drzwi do pożądanego miejsca docelowego, to inni mogą na tym skorzystać i również zostać wpuszczeni do środka, narażając tym samym na szwank system. Implementacja SPA w Appgate SDP rozpoznaje i zezwala na dostęp tylko pojedynczym użytkownikom na dostęp z sieci NAT’d na podstawie indywidualnie zweryfikowanych kluczy autoryzacyjnych i tokenów.
3. Ochrona przed spoofingiem (przydział klucza zmiennego).
Inną ważną zaletą podejścia Appgate SDP SPA w stosunku do typowej implementacji SPA jest fakt, że nie wykorzystuje ona statycznych kluczy dla żądań autoryzacji. W przypadku kluczy statycznych, zły aktor może sfałszować pakiet SPA i uzyskać dostęp do krytycznego zasobu, o którym mowa. Implementacja SPA w ramach Appgate SDP używa klucza zmiennego, co oznacza, że w ciągu kilku sekund generowany jest nowy klucz a sfałszowany pakiet SPA otrzymuje odmowę dostępu, ponieważ sfałszowany klucz jest przestarzały.
4. Izolowana dystrybucja klucza. Appgate SDP również stosuje całościowo ochronny system dystrybucji kluczy, który wykorzystuje określone klucze dla każdej interakcji. Istnieją klucze używane przez klientów do interakcji z kontrolerami, a klucze te są unikalne w stosunku do kluczy używanych do komunikacji z bramami w obrębie danego obiektu. Podobnie, interakcje między urządzeniami, jak: Kontrolerami, Bramami i innymi urządzeniami są chronione unikalnymi kluczami SPA.
5. Zapewnienie dostawy SPA. Jednym z problemów we wczesnych wersjach SPA było to, że korporacyjne zapory sieciowe mogły kończyć się odrzucaniem wiadomości SPA (TCP lub UDP), ponieważ silniki firewalli nie rozpoznawały ich. Nowsze wydania Appgate SDP rozwiązały ten problem poprzez enkapsulację wiadomości SPA wewnątrz innych znanych protokołów warstwy 5, dzięki czemu zapory sieciowe będą je dopuszczać.
6. Ochrona replikacji. Każda wiadomość Appgate SPA jest również spreparowana w specjalny sposób, aby złośliwi użytkownicy nie mogli go odtworzyć, powtórzyć lub wykonać innych działań, które mogłyby zagrozić każdej interakcji autoryzacyjnej.
Całościowy diagram pokazujący połączenie z Appgate SDP Client do Zasobu/Aplikacji
Oryginał tekstu w postaci pliku PDF można pobrać stąd.
Comentários