Miesiąc: czerwiec 2021

Projektowanie infrastruktury

MPLS może być całkowitą zmianą w funkcjonowaniu sieci WAN, a także wprowadzać problemy związane z rozwiązywaniem problemów i bezpieczeństwem. Ponieważ sieć MPLS może zapewnić funkcjonalność kraty typu „dowolny z każdym”, trudniej jest rozwiązywać problemy z siecią. W topologii sieci WAN typu hub-and-spoke możliwe jest wdrożenie centralnie zlokalizowanych sond w celu monitorowania i rozwiązywania problemów z siecią WAN. Jest mało prawdopodobne, aby organizacje korzystające z MPLS w wielu lokalizacjach zainwestowały czas i pieniądze na wdrożenie tego typu monitorów we wszystkich lokalizacjach. Usługodawca może jednak być w stanie świadczyć dodatkowe usługi, które zapewniają tego typu możliwości rozwiązywania problemów za dodatkową opłatą. Sieci MPLS zwiększają również ogólne obciążenie związane z bezpieczeństwem sieci, wymagając zwiększenia liczby urządzeń zabezpieczających sieć w celu zapewnienia ochrony w każdym indywidualnym miejscu. Dzieje się tak głównie dlatego, że witryny mogą nawiązywać bezpośrednią komunikację zamiast najpierw iść do węzła. MPLS oddaje bezpieczeństwo infrastruktury WAN w ręce dostawcy usług.

Upewnij się, że dostawca MPLS ma solidną sieć i ścisłe procesy oddzielania sieci MPLS. Dodatkową ochroną przed błędami po stronie dostawcy jest wdrożenie zabezpieczenia routingu Border Gateway Protocol (BGP)23, w którym obie strony połączenia będą uwierzytelniać się, zanim staną się częścią tabeli routingu. Sieci VPN dla lokalizacji zdalnych stwarzają dodatkowe ryzyko, umieszczając Internet bezpośrednio w sieci wewnętrznej w lokalizacjach zdalnych. Jeśli Internet łączy się bezpośrednio z routerem witryny, istnieje kilka opcji ochrony. Lista ACL może ograniczyć komunikację do tego interfejsu tylko przez drugą stronę połączenia VPN w lokacji zdalnej. Inną opcją byłoby włączenie dodatkowych funkcji bezpieczeństwa na routerze. Może to jednak wymagać uaktualnienia kodu i zwiększyć wymagania dotyczące przetwarzania na routerze. Bezpieczniejszą, ale kosztowniejszą opcją byłoby wdrożenie GSD, który zapewnia usługi bezpieczeństwa i VPN, tworząc dodatkową kolejną warstwę ochrony między Internetem a siecią wewnętrzną. Wielopunktowe sieci VPN są również ważnym czynnikiem konstrukcyjnym. Tam, gdzie stało się to powszechne, jeśli nie jest to konieczne, w przypadku wysoce dostępnych, szerokopasmowych połączeń VPN, typowy projekt sieci VPN z lokalizacją centralną lub hub-and-spoke może nie być pożądany. Wiele projektów opiera się na punkcie centralnym w celu ustanowienia siatki połączeń VPN typu jeden-do-wielu. Jeśli jednak centralny punkt jest niedostępny, cała siatka VPN nie działa. Wielopunktowe sieci VPN usuwają zależność od centralnego punktu końcowego VPN. Jeśli centralny punkt końcowy stanie się tymczasowo niedostępny, inne punkty końcowe są w stanie komunikować się i negocjować połączenia między sobą bez obecności węzła centralnego (lub głównego). Dzięki temu pozostała część sieci VPN pozostaje operacyjna i przekierowuje ruch do innych punktów końcowych, które w innym przypadku byłyby niedostępne bez centralnego punktu końcowego.

Ponieważ sesje VPN przechodzą przez niekontrolowane sieci, złośliwi aktorzy mogą przechwycić zaszyfrowaną komunikację; jednak protokół datagramowy leżący u podstaw TCP/IP sprawia, że ​​przechwytywanie sekwencyjnych pakietów jest trudne wszędzie poza źródłem i miejscem docelowym sesji. Jeśli atakujący zdoła przechwycić strumień danych, coraz bardziej prawdopodobne jest, że złamią zaszyfrowaną komunikację przy użyciu rozproszonych środowisk obliczeniowych z przetwarzaniem masowo równoległym. Jednak bardziej praktyczną metodą jest atak MITM podczas ustanawiania sesji VPN. Zarówno sieci VPN IPsec, jak i TLS/SSL są potencjalnie podatne na ataki MITM. Ataki MITM zwykle rozpoczynają się od złośliwego aktora w tej samej sieci co ofiara i przeprowadzają atak zatruwający protokołem ARP (Address Resolution Protocol), aby cały ruch przepływał przez system aktora przed przekazaniem go do reszty sieci. Główny wektor IPsec MITM to klucz wstępny (zazwyczaj nazwa grupy i hasło) do uwierzytelniania samego połączenia IPsec. Ten klucz jest zazwyczaj łatwy do odzyskania z plików konfiguracyjnych klienta VPN, chociaż takie podejście wymaga od złośliwego aktora wykorzystania dostępu po stronie klienta w celu ustalenia tych informacji. Po ustaleniu nazwy grupy i hasła narzędzie takie jak Fiked będzie emulować urządzenie końcowe VPN, uwierzytelniać połączenie IPsec i gromadzić dane uwierzytelniające użytkownika podczas próby uwierzytelnienia w celu uzyskania dostępu do pełnego połączenia VPN. Chociaż ten krok nie narusza poufności danych w ruchu, zapewnia podmiotowi możliwość dowolnego łączenia się z siecią wewnętrzną za pomocą zebranych danych uwierzytelniających. Istnieje możliwość obrony przed tym atakiem przy użyciu certyfikatu klienta lub komputera do uwierzytelniania IPsec. Możliwość naruszenia poufności TLS/SSL ze względną łatwością stała się rzeczywistością w 2009 roku wraz z wprowadzeniem SSLStrip. SSLStrip wykorzystuje atak zatrucia ARP polegający na przechwyceniu żądań klientów w celu użycia TLS/SSL. Po przechwyceniu narzędzie nawiąże prawidłowe sesje TLS/SSL z serwerem i utworzy przepisaną, niezaszyfrowaną sesję HTTP z klientem. Ta metoda nie powoduje wyświetlenia komunikatu o błędzie certyfikatu, który może ostrzec użytkownika o problemie z połączeniem. Narzędzie korzysta również z favicon kłódki, aby oszukać użytkownika, aby uwierzył, że połączenie jest bezpieczne, mimo że adres URL w rzeczywistości korzysta z protokołu HTTP, a nie HTTPS. Możliwe jest złagodzenie tego ataku, zezwalając tylko na bezpośrednie połączenia TLS/SSL zamiast przekierowywania z HTTP na HTTPS. Ponadto wcześniej ustanowione sesje TLS/SSL nie są podatne na ten atak.

Szyfrowanie i odszyfrowywanie tuneli VPN wymaga odpowiedniej mocy obliczeniowej. Ten problem nasila się wraz ze wzrostem liczby klientów. W sytuacjach, w których jest tylko kilku klientów zdalnego dostępu, możliwe jest użycie routera do zakończenia połączeń VPN i świadczenia usług bezpieczeństwa. Im większa liczba klientów zdalnego dostępu, tym większe zapotrzebowanie na dedykowane urządzenia VPN (w tym GSD). Możliwe jest zainstalowanie sprzętowych akceleratorów szyfrowania w celu przeniesienia obliczeń kryptograficznych i zarządzania ze współdzielonego procesora na dedykowane urządzenie przetwarzające w routerze lub GSD, zmniejszając w ten sposób wymagania przetwarzania tych jednostek. Większe organizacje mogą mieć tysiące jednoczesnych użytkowników, co wymaga wielu urządzeń VPN.

Kontrola ruchu sieciowego odgrywa kluczową rolę w utrzymaniu bezpieczeństwa sieci wewnętrznej. Ponieważ celem sieci VPN jest zapewnienie bezpiecznego transportu danych, stanowi to przeszkodę przy próbie oceny przychodzącego, zaszyfrowanego ruchu. Inspekcja ruchu sieciowego może wystąpić na urządzeniu łączącym VPN lub po niezaszyfrowanej stronie prowadzącej do sieci wewnętrznej. Chociaż ruch sieciowy jest o krok bliżej sieci wewnętrznej, stanowi to ważny punkt kontroli, w którym można wykrywać i chronić przed złośliwym ruchem. Niektóre urządzenia VPN i GSD mogą umożliwiać przeglądanie danych w tunelu, ocenę ruchu sieciowego (zapewniając punkt rozwiązywania problemów) i sprawdzanie danych przed przekazaniem do sieci nieszyfrowanej. Jednak wykonanie całej inspekcji urządzenia VPN może mieć znaczący wpływ na wydajność

Bez dokładnej kontroli protokołów kryptograficznych VPN można wybrać kombinację, która stwarza dodatkowe ryzyko naruszenia bezpieczeństwa lub ujawnienia informacji. Siła i właściwa implementacja ochrony kryptograficznej tunelu VPN jest niezbędna do ochrony danych i musi być wystarczająca do spełnienia wymagań bezpieczeństwa organizacji. Wybór dostępnych protokołów kryptograficznych dla IPsec następuje podczas negocjacji IKE. Zestaw szyfrów określa, które protokoły kryptograficzne są dostępne do ochrony sesji VPN. Na przykład, jeśli 3DES i SHA1 są uważane za niewystarczającą ochronę, te i wszystkie inne słabsze alternatywy muszą zostać usunięte z negocjowalnych opcji IKE lub zestawu szyfrów. Gwarantuje to, że niekompatybilni klienci nie mogą się połączyć, a podczas sesji VPN używane są tylko wystarczające zabezpieczenia

Sedno możliwości świadczenia usług VPN kręci się wokół istniejącej infrastruktury bezpieczeństwa sieci i ma bezpośrednie implikacje dotyczące ochrony obwodu, ponieważ urządzenia łączące VPN muszą być skierowane do Internetu i do wewnątrz. Urządzenia te muszą również być zgodne z zewnętrzną strefą serwisową omówioną w rozdziale 26 niniejszego podręcznika. Samo urządzenie jest kolejną częścią ogólnego profilu bezpieczeństwa sieci. Ważne jest, aby usunąć wszystkie dodatkowe narażenia. Podstawową metodą ochrony jest skonfigurowanie zapory tak, aby zezwalała na dostęp tylko do niezbędnych portów na urządzeniu VPN. Wszystkie niepotrzebne protokoły, usługi i opcje konfiguracyjne powinny zostać wyłączone. Jeśli narzędzie do zarządzania siecią używa protokołu ICMP i/lub SNMP do monitorowania urządzenia VPN, reguły zapory lub wbudowane listy ACL powinny zezwalać na dostęp do tych protokołów tylko z określonego zestawu monitorujących hostów. Chociaż rozpoznanie sieci i ataki są nadal możliwe na tych portach, metoda ta drastycznie zmniejsza profil ataku. Dostęp do urządzeń administracyjnych nigdy nie powinien korzystać z niezabezpieczonych protokołów, takich jak Telnet, FTP lub HTTP. Zamiast tego administracja powinna odbywać się tylko przy użyciu odpowiednio skonfigurowanych zaszyfrowanych protokołów, takich jak Secure Shell (SSH) i Hypertext Transfer Protocol Secure (HTTPS). Dostęp administracyjny powinien być chroniony co najmniej nazwą użytkownika i silnym hasłem, a jeszcze lepiej dodać uwierzytelnianie dwuskładnikowe za pomocą certyfikatu lub tokena połączonego z kodem PIN lub hasłem. Aby zminimalizować dostęp administracyjny, tylko określone sieci lub hosty powinny mieć bezpośredni dostęp do Konsoli administracyjnej, a jeśli to możliwe, nigdy nie wolno im zezwalać na żadne interfejsy internetowe. Aby jeszcze bardziej zredukować narażenia administracyjne, możliwe jest użycie hosta przeskoku dla wszystkich administratorów. Jednak stwarza to możliwość pojedynczego punktu awarii administracyjnej, jeśli host skoku nie jest dostępny.

Administracja klientem odgrywa kluczową rolę w sukcesie rozwiązania VPN. Protokół IPsec wymaga użycia aplikacji po stronie klienta lub mechanizmu wbudowanego systemu operacyjnego. Główne implikacje tego obejmują konfigurowanie i utrzymywanie klienta. Zawiłości związane z instalacją na twardym kliencie obejmują konieczność uzyskania lokalnych uprawnień administracyjnych, potencjalną interakcję użytkownika i radzenie sobie z uszkodzoną aplikacją kliencką VPN. Podobnie jak w przypadku wszystkich innych aplikacji, aktualizacje są konieczne ze względu na nowe ulepszenia, nieobsługiwane starsze wersje i luki w zabezpieczeniach. Zgodnie z celem minimalizacji negatywnych doświadczeń użytkowników administratorzy potrzebują sposobu na aktualizację oprogramowania klienckiego bez interakcji z użytkownikiem lub bez skutków ubocznych. Jednym z podstawowych pytań jest ustalenie, czy dostawca VPN ma mechanizm wypychania konfiguracji i innych aktualizacji oprogramowania klienckiego podczas połączenia. Bez tej funkcjonalności trudniej jest zmienić parametry po stronie klienta. Na przykład sieć VPN korzystająca ze wstępnie udostępnionego klucza do uwierzytelniania VPN zostaje na stałe zakodowana w konfiguracji oprogramowania VPN. To sprawia, że ​​trudno jest go zmienić bez konieczności wprowadzenia przez użytkownika końcowego nowego klucza, a ponadto jest to droga do kompromisu, jeśli klucz można odzyskać. Klienci TLS/SSL VPN nie mają tych samych pułapek, co zarządzanie klientami IPsec. Zamiast twardego klienta TLS/SSL VPN zwykle używa małego dynamicznego klienta opartego na Javie lub ActiveX lub lekkiej instalacji specyficznej dla systemu operacyjnego. W niektórych systemach VPN administrator może mieć możliwość pozostawienia rezydenta dynamicznego klienta lub usunięcia go po rozłączeniu. Jeśli klient ulegnie uszkodzeniu, użytkownik może usunąć kontrolkę i zostanie ona automatycznie pobrana przy następnym udanym połączeniu. Pozostanie rezydentem dynamicznego klienta ma dwie zalety. Po pierwsze, może to zapewnić możliwość posiadania lokalnego, zaszyfrowanego obszaru roboczego do przechowywania dokumentów roboczych i innych plików lub zapewnienia dostępu do innych zasobów. Po drugie, dzięki temu system zdalny nie musi pobierać klienta przy każdym połączeniu. Klient TLS/SSL ma również tę zaletę, że zawsze sprawdza, czy klient rezydentny jest aktualny. Jeśli nie, system VPN wymusi pobranie najnowszego klienta, pomagając zminimalizować zarządzanie po stronie klienta. Niezbędne jest również odpowiednie monitorowanie zdalnych sieci VPN. Zhakowane połączenie VPN lub dane uwierzytelniające są niezwykle niebezpieczne i stają się coraz bardziej popularnym celem atakujących. Organizacje powinny monitorować dzienniki i połączenia pod kątem podejrzanej aktywności i mieć wdrożone procedury dotyczące takich problemów. . Na przykład, jeśli identyfikator użytkownika loguje się z głównego biura w Kalifornii, a mniej niż dwie godziny później ten sam identyfikator użytkownika loguje się z drugiego końca świata, prawdopodobnie drugie połączenie nie jest zamierzone lub legalne. Dotyczy to zwłaszcza środowisk z jednokrotnym logowaniem (SSO)

Ponieważ nie ma absolutnej kontroli, gdy systemy mobilne opuszczają granice sieci wewnętrznej, wierność urządzenia mobilnego jest problemem. Ryzyko naruszenia bezpieczeństwa na każdym poziomie — od fizycznego, przez system operacyjny, po aplikacje i nie tylko — może narazić sieć wewnętrzną na zwiększone ryzyko podczas sesji sieci VPN. ? ? ? ???? Istnieje kilka sposobów na zmniejszenie prawdopodobieństwa utraty wierności. Zabezpieczenia mogą obejmować dowolną kombinację oprogramowania zabezpieczającego opartego na hoście (np. zapora, ochrona przed złośliwym oprogramowaniem, zapobieganie włamaniom), aktualne poziomy poprawek i bezpieczne konfiguracje. Właściwe wdrożenie i konfiguracja tych środków ochrony pomoże zmniejszyć możliwość naruszenia bezpieczeństwa. Nawet jeśli wierność urządzenia jest akceptowalna podczas początkowego połączenia, nie gwarantuje to, że ten stan nie zmieni się w późniejszym czasie podczas połączenia. Inną metodą zapewnienia kondycji urządzenia jest kontrola dostępu do sieci (NAC). NAC zapewnia możliwość odpytywania łączącego się urządzenia przed i podczas połączenia w celu określenia takich informacji, jak poziomy poprawek, stan zabezpieczeń i złośliwe oprogramowanie rezydujące w pamięci . Niestety NAC to nie tylko propozycja typu plug-and-play. Istnieje wiele innych implikacji i wymagań, takich jak określenie, co należy ocenić i/lub wyegzekwować, wdrożenia wbudowane lub pasywne oraz rozwiązania oparte na kliencie lub rozwiązania bezklienckie, związanych ze skutecznym wdrażaniem NAC w dowolnym punkcie sieci.

Sieci VPN z dostępem zdalnym stwarzają największe ryzyko narastająco. Wszystkie niekontrolowane sieci zasługują na traktowanie jako niepewne, a przez to wrogie środowiska obliczeniowe. Ponieważ istnieje niepewność co do bezpieczeństwa sieci, z której system użytkownika końcowego będzie się łączyć, konieczne jest, aby host dysponował wystarczającymi mechanizmami samoobrony, aby zrekompensować utratę dodatkowych dostarczonych warstw ochrony w głąb przez sieć wewnętrzną. To zrozumienie będzie wymagało od administratorów bezpieczeństwa skupienia się na niezbędnych środkach ostrożności w celu ochrony wszystkich systemów organizacji.

 

Chociaż zdolność ludzi i zdalnych lokalizacji do łączenia się z zasobami wewnętrznymi zapewnia mobilność i zwiększa produktywność, organizacja musi dokładnie rozważyć zastrzeżenia związane z zapewnieniem informacji. Każda realizacja będzie miała swoją unikatowość wymagań, ale rozwiązanie głównych problemów przedstawionych w kolejnych sekcjach może zapewnić bardziej świadome decyzje.