Bezpieczeństwo pracy zdalnej
VPN bez tajemnic
(03.06.2020)

— Dawid Zięcina —
O VPN obecnie mówi się bardzo dużo, zarówno w kraju jak i na świecie. Dane za zeszły miesiąc mówią o pracy zdalnej około 30% osób zatrudnionych w kraju, co przy ponad 15 milionach zatrudnionych osób, daje nam około 5 milionów Polaków korzystających z VPN. Zastanówmy się przez chwilę czy ten VPN to tylko urządzenia/oprogramowanie, czy każde rozwiązanie ma szerokie możliwości zapewnienia przedsiębiorstwu bezpieczeństwa informacji, zarówno tych informacji które są wykorzystywane przez pracowników zdalnych, jak i tych, które pozostają w firmie. Postaram się przedstawić nie tylko ten aspekt technologiczny, ale opowiedzieć też Państwu o tym na co należy według mnie zwrócić uwagę oraz jakie zagrożenia obserwujemy w modelu pracy zdalnej. Zastanówmy się teraz, gdzie kończy się ta umowna granica, która stanowi zabezpieczenie naszej sieci wewnętrznej na styku z siecią zewnętrzną (niezaufaną), czyli z Internetem. Jeszcze nie tak dawno była to bardzo widoczna granica LAN-u z WAN-em, chroniona przez firewalla bądź UTM-a. W momencie, w którym ktoś przyszedł do informatyków i mówił „chłopaki powiedzcie mi gdzie tak naprawdę jest ta granica pomiędzy tym 'złym’ Internetem, a naszą zabezpieczoną siecią wewnętrzną”, wtedy informatyk brał klucze, zabierał do ciemnej piwnicy w której było dużo różnych, dziwnych szaf, otwierał jedną z nich, wskazywał na prostokącik z wesoło mrugającymi lampkami i mówił „tu jest ta granica pomiędzy złem a bezpieczeństwem naszej firmy”. Było to jedno urządzenie, które można było rzeczywiście wskazać jako ten perimeter pomiędzy siecią zabezpieczoną, a Internetem. W ostatnich tygodniach nastąpił dynamiczny wzrost zapotrzebowania na pracę zdalną, który spowodował, że większość firm świadomie przesunęła granicę do lokalizacji z których łączą się ich pracownicy. Nie ma już tego jasnego podziału, granicy. Teraz granica przesunęła się w to miejsce, z którego pracują użytkownicy zdalni. Wcześniej też oczywiście tak było, natomiast na o wiele mniejszą skalę, zatem nie był to tak dotkliwy problem i nie dotyczył on tak wielu przedsiębiorstw i firm. Z punktu widzenia polityk bezpieczeństwa firmy, samo zestawienie VPN-a powinno być analizowane przede wszystkim na płaszczyźnie zapewnienia ochrony swoich informacji w sposób efektywny, spójny i jednolity, bez względu na fizyczną lokalizację pracownika – czy jest on w domu, czy na stacji benzynowej i korzysta z otwartego Wi-Fi – taka sama jednolita granularność i polityka powinna obowiązywać takiego pracownika jak i pracownika, który pracuje wewnątrz firmy.

5:53
Jest to bardzo duże wyzwanie dla osób odpowiedzialnych za bezpieczeństwo w firmie. Obecnie jednym z takich głównych modeli bezpieczeństwa, który reprezentuje też Palo Alto Networks, jest model „zero trust” i rozszerzenie koncepcji granicy styku naszej sieci wewnętrznej z Internetem, czyli Software Defined Perimeter. Jest to w odróżnieniu od wcześniej omawianego przeze mnie podejścia Network Perimeter, gdzie można było wskazać te urządzenie, które jest na styku. Są to obecnie bardzo modne pojęcia, które zostały zdefiniowane w 2008 roku przez Johna Kindervaga, który jest obecnie jednym z dyrektorów w Palo Alto Networks. Jeżeli chodzi o podejście właśnie do tych przedstawionych koncepcji, to tutaj nie będzie pewnie dla większości z Państwa zaskoczeniem, że koncepcja ta mówi o tym by nigdy nie ufać, zawsze weryfikować i chronić wszystko, zawsze i wszędzie. Większość z Państwa powie, że przecież to jest znane od lat podejście. Mało kto je jednak stosuje, ponieważ wymaga bardzo dużego nakładu pracy ze strony służb IT i ludzi od bezpieczeństwa, co jest bardzo niewygodne i ograniczające, jeżeli chodzi o swobodę prac. Takie podejście skutecznie wzmacnia jednak ochronę użytkowników mobilnych przed zagrożeniami na jakie są narażeni. Decydując się na narzędzie do realizacji VPN, częstym wyzwaniem osób odpowiedzialnych za uruchomienie, jest wyznaczenie granicy pomiędzy obostrzeniami ograniczającymi swobodę działań użytkowników zdalnych, a ich komfortem pracy. Technologia ma według mnie wspierać zarówno bezpieczeństwo, jak i komfort pracy i nie rezygnować z jednego na rzecz drugiego. Jeżeli już trzeba z czegoś zrezygnować, to lepiej zrezygnować z komfortu na rzecz bezpieczeństwa.

8:20
Istnieje szerokie spektrum zagrożeń jakie czyhają na pracowników zdalnych. Takim typowym scenariuszem prowadzącym do incydentu jaki możemy obserwować w ramach świadczenia naszych zaawansowanych usług bezpieczeństwa, jest, gdy brama/koncentrator VPN stanowi pojedynczą granicę pomiędzy siecią zewnętrzną (niezaufaną), a całą siecią wewnętrzną. Czyli tak naprawdę użytkownik po weryfikacji jedynie nazwy użytkownika i hasła, otrzymuje dostęp do wszystkich zasobów w LANie i to na poziomie sieci. Wystawiając zasoby użytkownikom pracującym zdalnie, warto spojrzeć na architekturę pod kątem pewnych podatności, zagrożeń i ryzyk z nimi związanych wniesionych przez te obce elementy względem naszej infrastruktury. Czy to będzie sprzęt użytkownika w modelu „bring you own device”, czy też elementy sieciowe jak router czy nawet sam dostęp lokalny do Internetu u zdalnego pracownika, to też może być nasz firmowy sprzęt, który powierzyliśmy pracownikowi, ale wykorzystywany przez niego niewłaściwie, do celów prywatnych. Jest to bardzo powszechne zjawisko, które prowadzi do licznych incydentów. To samo dotyczy umieszczania danych w środowisku chmurowym, w tym przetwarzających je aplikacjach w modelu SaaS do których nasi zdalni pracownicy mogą się łączyć bezpośrednio, pomijając naszą zabezpieczoną sieć firmową. Jak minimalizować takie ryzyko związane z powiększającą się powierzchnią ataków, pokażemy w dalszej części prezentacji i w demo, które pokaże Marcin. Kolejnym często obserwowanym przez nas incydentem, jest atak wymierzony na kradzież loginu i hasła. Skala zjawiska i prostota tego narzędzia, stwierdza konieczność uruchomienia takich technologii realizujących usługę VPN, które ten etap autentykacji realizują w oparciu nie tylko o login i hasło, ale także o certyfikaty oraz uwierzytelnienie dwuetapowe. To co powinien przedstawiać produkt, który wykorzystujemy do zestawienia usługi VPN i nie tylko, to powinna być podstawowa ochrona na poziomie mechanizmu, który wykrywałby próby wyprowadzenia takich danych jak login i hasło przez naszego pracownika w sposób nieświadomy, czyli wprowadzając np. swoje dane logowania do specjalnie spreparowanego formularza. Mam tu na myśli specjalnie przygotowaną stronę np. do złudzenia przypominającą panel logowania Ofiice’a 365 czy też strony logowania jednego z naszych systemów firmowych. Warto tutaj zauważyć, że koncepcja jaką posiada Palo Alto Networks w swoim rozwiązaniu, spełnia w zasadzie wszystkie takie wymagania stawiane tym elementom, dzięki czemu skutecznie możemy zaadresować te zagrożenia i zminimalizować ryzyko związane z wykorzystaniem tej bardzo popularnej metody ataku, która jest niezwykle prosta do przeprowadzenia, a tym bardziej w sytuacji pracy zdalnej w środowisku, które jest zupełnie poza naszą kontrolą.

12:25
Nasz zespół w EXATEL, w ramach działań poincydentalnych, realizuje zarówno forensic, wsteczną analizę oprogramowania, jak i analizę malware’u. Eksperci w naszym zespole często potwierdzają, że to malware był narzędziem użytym właśnie do infiltracji zasobów firmy. Jest to bardzo popularna metoda ataku, dlatego też powinniśmy zabezpieczyć się przed możliwością wykorzystania malware’u jako narzędzia do ataku na nasze zasoby. W takim modelu pracy zdalnej, złapanie malware’u możliwe jest w wielu punktach, dlatego poza samym skanowaniem ruchu generowanego przez użytkownika zdalnego, należy też zadbać o właściwe zabezpieczenie komputera użytkownika i weryfikowanie jego stanu zanim zostanie udzielony dostęp do naszych zasobów. Mam tu na myśli taki mechanizm, który będzie mógł automatycznie podjąć decyzję np. o zablokowaniu dostępu, gdy nie zostaną spełnione odpowiednie kryteria związane z komputerem i systemem użytkownika, czyli np. sprawdźmy najpierw jaki jest stan aktualizacji maszyny, jakie ma zainstalowane oprogramowanie oraz jaki jest poziom aktywności ochrony antywirusowej. Dopiero po przeanalizowaniu tych kryteriów można podjąć decyzję, czy dana maszyna i dany użytkownik zalogowany na niej, może być dopuszczony do połączenia VPN. Sam proces identyfikacji złośliwego kodu nie powinien bazować jedynie na znanych sygnaturach i zagrożeniach. Skuteczne rozwiązanie antymalware’owe to m.in. weryfikacja zachowania samego kodu i określenie w jakim stopniu działania oprogramowania mogą być negatywne dla naszych zasobów. Jedną z popularnych technik podłączenia pracownika zdalnego do koncentratora VPN, jest przyjmowanie do tunelu jedynie części ruchu generowanego przez użytkownika i jego system. Czyli definiujemy co ma wpadać do naszej sieci zabezpieczonej i to zazwyczaj odbywa się na poziomie odpowiedniej modyfikacji tablicy routingu endpointa, a reszta trafia bezpośrednio do sieci publicznej (Internetu). Otrzymujemy zatem system częściowo zapięty do VPN. Mamy jednak do czynienia z ekspozycją takich zasobów do Internetu, skąd w przypadku skompromitowania takiego endpointa, osoba dokonująca ataku może bez większego problemu przedostać się do naszych chronionych zasobów po drugiej stronie VPN (czyli z Internetu przez hosta i z hosta po VPN do naszych zasobów). Jest to spore ryzyko, dlatego split-tunel dobrze jest zastosować w metodzie odwróconej logiki względem tego co powiedziałem przed chwilą, czyli wypuśćmy bokiem tylko ściśle określony przez nas typ ruchu generowanego przez dokładnie zidentyfikowaną i określoną aplikację. To może zostać wykazane dzięki np. usłudze testów penetracyjnych jaką mamy dostępną w portfolio cyberusług EXATEL, to możliwość wykorzystania i zastosowania takich metod ataku na Państwa infrastrukturę rozwiązania VPN jak „man in the middle”, bardzo popularny i spotykany przez nas typ ataku, który jest bardzo łatwy do zrealizowania, szczególnie przy split-tunelingu, dlatego też tym komplementarnym rozwiązaniem powinna być ochrona komputera lokalnie przy wykorzystaniu oprogramowania typu endpoint protection.

16:15
Drugim bardzo popularnym i wychwytywanym przez nas typem ataku jest DNS hijacking. Również jest to bardzo popularny wektor ataku przy split-tunelingu, dlatego tak ważnym elementem środowiska VPN powinny być też mechanizmy weryfikujące interakcje systemu z zasobami zewnętrznymi na zewnątrz naszej firmy już na bazie zapytań DNS. Wiele zagrożeń wiąże się z takim modelem, jednak mając na uwadze ograniczone zasoby jakimi dysponuje firma, czy to wydajność łącza, czy też wydajność platformy koncentratora VPN itd., jest to nadal częsty wybór administratorów. Dlatego dobierając pewne rozwiązania, które budują nam architekturę VPN, warto doposażyć się w takie elementy, które będą mitygowały pewne zagrożenia, które i ja częściowo wskazałem i które są też popularne w przypadku split-tuneli. Kolejnym popularnym modelem jest „Client to Side”. W takim modelu VPN, możemy albo częściowo przepuszczać ruch albo w całości. Jeżeli przepuszczamy cały ruch przez centralę, to jest to model „na bogato”, ponieważ musimy mieć dużą wydajność łącza i platformy. Proszę zauważyć, że wtedy klienci cały swój ruch, który generują, przepuszczają przez łącze i przez platformę np. jakiegoś firewalla, który ma uruchomiony moduł VPN i ten ruch może się dwukrotnie zawinąć. Przykład: YouTube nie będzie trafiał bezpośrednio do naszych zasobów wewnątrz sieci – będzie on wychodził na zewnątrz. Co dzieje się ze streamingiem? Użytkownik zdalny uruchamia sobie YouTube’a lub Netflixa, cały ruch po VPN zapinany jest przez nasze łącze do jakiejś platformy, która świadczy usługi VPN, tam jest podejmowana decyzja o wypchnięciu go na zewnątrz i znowu jest taka sama ilość ruchu, wypychana jest na zewnątrz, tym samym łączem, przez tę samą platformę. Mamy więc tutaj dwukrotne zużycie i zutylizowanie tych cennych często zasobów, które pracują poniżej tak naprawdę swoich potrzeb, szczególnie w tak dynamicznie zmieniających się potrzebach, jak w ostatnim czasie to obserwujemy. Dobrze jest więc mieć taką możliwość konfiguracji, która bez zbędnej utraty poziomu bezpieczeństwa, jest w stanie optymalizować ruch tak, aby nie obciążać zbędnie naszej platformy, na której realizujemy VPN.

19:07
GlobalProtect jest produktem, który realizuje VPN na platformie Palo Alto Networks. Jest to element kompleksowej platformy, wspierany przez Palo Alto Cortex Endpoint Protection, który adresuje poruszone przeze mnie problemy związane z efektywnym dostępem po VPN, przy zachowaniu odpowiednich standardów bezpieczeństwa. Palo Alto Networks ładnie grupuje pewne funkcjonalności w ramach dedykowanych modułów i tak jak np. w zakresie Threat Prevention otrzymujemy ochronę przed malwarem, IPS, blokowaniem podejrzanych DNS-ów, to jest mocno wspierane przez rozbudowane funkcjonalności takich dedykowanych modułów do filtrowania URL-i. W ramach platformy dostępny jest mechanizm deszyfrowania. Widoczność ruchu drastycznie wzrasta. Jeżeli coś jest puszczone https-em – z reguły rozwiązania bardzo popularne opierane tylko na koncentratorze VPN – to niestety tutaj będzie musiało być wspierane przez jakiś deszyfrator, żeby można było zobaczyć co za ruch tak naprawdę do nas trafia, czy to nie jest ruch podejrzany. Sama weryfikacja ruchu bez kontekstu związanego z kontrolą aplikacji, nie jest w pełni efektywna, dlatego taki moduł jak App-ID pozytywnie wpływa na synergię zaadaptowanych rozwiązań. Palo Alto Networks daje nam do dyspozycji potężną platformę do automatycznego badania podejrzanego kodu w celu wykrycia malware’u. Całość dopina moduł Threat Intelligence, który może być również powiązany z informacjami napływającymi z rozwiązania endpointowego firmy Palo Alto Networks, zainstalowanego na Państwa endpointach. Widać więc, że ta struktura daje nam pełen obraz i wiele możliwości co do płynnego zarządzania usługami, ale jednocześnie bez utraty wydajności tego środowiska do zapewnienia bezpieczeństwa na bardzo wysokim poziomie.

— Marcin Szewczuk —
21:48
Zacznę od trzech elementów wymienionych poniżej na slajdzie, czyli DAG, DUG i HIP. Agent Palo Alto Networks i gateway Palo Alto Networks w oparciu o informacje zebrane z hosta (Host Information Profile), są w stanie zidentyfikować czy dany host spełnia kryteria korporacyjne w ramach dostępu do sieci. Funkcjonalność HIP potrafi przypisać go do odpowiedniej reguły i w ramach tej reguły poinformować użytkownika – który łączy się tunelem VPN – czy spełnił wymagania. Taki komunikat oczywiście nie musi być wyświetlany, jeżeli użytkownik spełnia wymagania, ale jeżeli nie spełnia wymagań jak np. zaszyfrowany dysk, posiadanie aplikacji korporacyjnej, posiadanie aktualnego systemu antywirusowego/antymalware’owego czy też DLP zainstalowanego na hoście, wówczas HIP poinformuje o tym, że polityka firmy nie pozwala mu na dopuszczenie takiego urządzenia do środowiska korporacyjnego i w tym momencie poprosi o zainstalowanie odpowiednich aplikacji lub paczek oprogramowania, aby te wymagania spełnić. O ile HIP działa kontrolując hosta przed połączeniem VPN, to warto też wspomnieć o dynamicznych grupach adresowych i dynamicznych grupach użytkowników, które są w stanie na bieżąco zmieniać politykę stosowaną do adresów IP lub użytkowników identyfikowanych w ruchu na firewalllach Palo Alto Networks. Działa to w ten sposób, że jesteśmy w stanie ruch identyfikowany w oparciu o odpowiednio sparsowane logi, przypisywać do tagów, np. jeśli użytkownik połączył się z jakąś złośliwą domeną DNS, jesteśmy w stanie taki ruch otagować i na podstawie tego taga wrzucić użytkownika lub jego adres, albo do DAG-a albo do DUG-a i w ten sposób przypisać mu politykę bezpieczeństwa, która posiada w sobie dynamiczną grupę adresową albo dynamiczną grupę użytkowników, co spowoduje, że np. zablokujemy jego dostęp i poinformujemy go o tym za pomocą jakiejś strony blokującej albo wymusimy na nim (jeżeli to działanie nie jest przez nas w pełni zidentyfikowane jako złośliwe, np. przypadkowa próba odwiedzenia strony phishingowej) – jeżeli posiadamy w swoim środowisku – uwierzytelnianie typu multi-factor authentication do zasobów krytycznych, do których będzie się próbował w naszym środowisku dostać. Jeżeli chodzi natomiast o implementację samych firewalli, to możemy je implementować w naszym środowisku korporacyjnym, jak również jest też możliwość zaimplementowania gateway’i dla GlobalProtecta w środowisku typu publiczna lub prywatna chmura, gdzie mogą być one punktem dostępowym (point of presence), jeżeli środowisko naszego klienta jest wystarczająco duże albo potrzebuje większej ilości gateway’i żeby zapewnić dostęp użytkowników zdalnych do zasobów zarówno korporacyjnych, jak i zasobów typu aplikacji SaaS i zapewnić im po prostu bezpieczny dostęp do Internetu. Jeżeli chodzi o porównanie tradycyjnego dostępu VPN z GlobalProtect, to tradycyjny dostęp VPN zapewnia tak naprawdę zdalny dostęp do środowiska korporacyjnego i zaszyfrowane połączenie do tego środowiska. Najczęściej był implementowany w stylu split-tunelingu ze względu na pewne ograniczenia architektoniczne tych środowisk. W przypadku Palo Alto Networks, jesteśmy w stanie przez przepuszczanie odpowiedniego ruchu od użytkownika przez firewalle Palo Alto Networks, zapewnić mu ochronę przed zagrożeniami z Internetu w ramach korzystania z aplikacji SaaS przed phishingiem związanym z kradzieżą poświadczeń, w sposób korporacyjny, czyli na odpowiednio wysokim poziomie. Oczywiście taki użytkownik będzie realizował swoje połączenia w ramach odpowiednio skonfigurowanych polityk bezpieczeństwa, w oparciu zarówno o jego User ID, jak i aplikację, content który przesyła i oczywiście informacje o hoście. Jeżeli nie ma zrealizowanego hosta, to HIP wymusi na nim odpowiednie działania, zanim uzyska dostęp do sieci korporacyjnej. Co jeszcze ważne – mamy możliwość implementowania GlobalProtecta na hardwarze przez nas oferowanym, w chmurze publicznej i prywatnej. Nasze rozwiązania typu PA-Series mają naprawdę wiele możliwych integracji.

— Dawid Zięcina —
27:55
Za chwilę Marcin pokaże jak bez dogłębnej wiedzy w zakresie konfiguracji GlobalProtecta, można w kilku krokach, skorzystać z gotowych szablonów dla tych z Państwa, którzy już są szczęśliwymi posiadaczami takiego urządzenia lub w najbliższym czasie planują zakup i nie za bardzo mają czas zgłębiać dokładnie tę technologię ze względu na proces implementacji ważniejszych elementów tej architektury. Dla tych z Państwa, którzy nie chcą ponosić kosztów związanych z inwestycją w platformę, poświęcać tego czasu na naukę o której mówiłem i na bieżącą administrację platformą, mam tutaj dobrą wiadomość, bo w ramach usług jakie świadczy EXATEL, mamy model Firewall as a Service. To Managed Firewall realizowany na platformie Palo Alto Networks. Usługę świadczymy zarówno w modelu multi tenant, jak i możemy zainstalować u Państwa dedykowane pudełko. Całością – od planowania i wdrożenia, po utrzymanie – zajmuje się wykwalifikowany zespół specjalistów EXATEL To co jeszcze chciałem powiedzieć na koniec swojej części, to że tyle wiemy o naszym VPN, ile go sprawdzono. Żeby sprawdzić czy nasze środowisko i mechanizmy związane z VPN działają na odpowiednio wysokim poziomie bezpieczeństwa, dobrze jest po prostu powiedzieć „sprawdzam”. Dlatego rekomendujemy usługę rekonesansu bezpieczeństwa. Usługa ta zawiera w sobie zarówno komponenty pracy pentesterskiej, gdzie nasi pracownicy w ściśle określonym czasie starają się różnymi metodami odnaleźć jak najwięcej podatności Państwa infrastruktury z możliwością ich ewentualnej eksploitacji, a jednocześnie drugi zespół prowadzi weryfikację procesowo- proceduralną w wybranych obszarach Państwa przedsiębiorstwa. Zdobyta w ten sposób wiedza, jest następnie analizowana przez naszych ekspertów z Security Operation Center i udostępniana Państwu w ramach raportu i rekomendacji związanych z wykrytymi nieprawidłowościami i – w ograniczonym poznawczo zakresie – możliwymi następstwami tych nieprawidłowości.

— Marcin Szewczuk —
30:55
Demo: Zacznijmy od tego co w naszym środowisku mamy. Jeżeli chodzi o nasze środowisko, to mamy użytkownika mobilnego w strefie niezaufanej, który będzie się łączył z adresu 192.168.55.63. Nasz gateway w strefie niezaufanej ma adres z końcówką 55.20. Default gateway’em do którego będzie się komunikował firewall Palo Alto Networks, jest gateway z końcówką 55.2. Interfejs zaufany po stronie Palo Alto Networks, czyli nasza sieć korporacyjna, kończy się poprzez pozostałe dwa oktety w ramach sieci 45.20 i w ramach tejże sieci jest serwer Active Directory, który ma końcówkę 45.65. Tak naprawdę nie jest to jakieś wybitnie trudne środowisko, więc od razu może przejdźmy do połączenia się z firewallem. Z firewallem będę łączył sie poprzez interfejs managementowy, który nie był tam pokazany, natomiast jest on również w sieci wewnętrznej, tak żebym mógł się połączyć bezpośrednio z przeglądarki. Od razu mówię, że już wcześniej została zaimplementowana rekomendowana polityka co do ustawień bezpieczeństwa samego systemu, tzw. iron skillet, dlatego też nie ma tutaj nazwy admin, tylko już konkretna nazwa użytkownika. Admin nie jest dopuszczalny w ramach iron skilleta. Zanim przejdziemy do endpointa to chciałbym jeszcze Państwu pokazać, że będziemy dzisiaj korzystali z narzędzia, które nazywa się Docker. Na Dockerze postawiona jest aplikacja, którą wykorzystamy do zaimplementowania polityki dla GlobalProtecta. Zanim będziemy korzystać z aplikacji, która pomoże nam w konfiguracji, to włączmy ją. W drugiej kolejności chciałbym szybko przejść gateway’a i pokazać Państwu co jest skonfigurowane. Na samym gateway’u mamy konfigurację rekomendowanych najlepszych praktyk, bez żadnych reguł bezpieczeństwa, które powinny być zaimplementowane między trustem i untrustem. Mamy więc trzy reguły blokujące. Dobre praktyki Palo Alto Networks dla Internet Gateway’a, też będą tam dostępne. Jeżeli chodzi o NAT to mamy tylko i wyłącznie outbound dla sieci „serwer”, która w tym momencie nie jest wykorzystywana dla naszej sieci trust do untrusta. Nie ma tutaj nic związanego z połączeniem VPN. Jeżeli chodzi o deszyfrację, to mamy stworzoną deszyfrację dla trusta do untrusta. Są to dwie reguły – jedna niedeszyfrująca odpowiednie kategorie w URL-u w filteringu, a druga deszyfrująca cały pozostały ruch. Jeżeli chodzi o ustawienia sieciowe, nie ma tu zdefiniowanego dla GlobalProtecta ani portalu do którego powinien się zalogować użytkownik, ani gatewaya do którego będzie realizował już swoje połączenie Client to Side VPN.

35:00
Zostawiamy tego firewalla tak jak jest i przechodzimy do aplikacji Panhandler. Aplikacja ta jest dostępna z mojego hosta ze względu na to, że korzystam z Docker Desktop, dlatego wpisuję tutaj adres local host. Loguję się w ramach tzw. credentiali defaultowych – nie zmieniałem już tego ze względu na to, że aplikacja jest postawiona na moim hoście więc czuję się w miarę bezpiecznie. I teraz może krótka historia. „Pan” to skrót od garnka, iron skillet (czyli rekomendowane dobre praktyki dla całego rozwiązania, dla profili bezpieczeństwa, dla dostępu do rozwiązania) to żelazna patelnia, natomiast „Panhandler” – aplikacja która pozwala nam na zaimplementowanie skilletów – to po prostu uchwyt do patelni i stąd nazwa aplikacji. Panhandler to aplikacja, która pomaga nam wykorzystywać skillety dostępne na GitHubie. Możemy je importować i zobaczyć jaką grupę skilletów już posiadamy. Ja te skillety zaimportowałem wcześniej i w ramach tychże mamy rekomendowane najlepsze praktyki (iron skillety), które podnoszą poziom bezpieczeństwa naszego rozwiązania do poziomu rekomendowanego przez nas. Mamy cztery skillety dla GlobalProtecta – dwa z nich są związane z ustawieniami pre-logon dla VPN, a kolejne dwa z ustawieniami user-logon dla VPN. My wykorzystamy ustawienia user-logon dla wersji PAN-OS 9.0, czyli naszego systemu operacyjnego. Na starcie Panhandler pyta się nas jaki rodzaj certyfikatu chcemy, żeby był podpisem dla GlobalProtect Portalu. Pozostawiamy te dane jak są, ze względu na to, że to jest tylko i wyłącznie demo, poza tym nie mam żadnej dostępnej domeny i przypisanego do niej adresu IP mojego gateway’a. Jedyne co to musimy wyedytować i sprawdzić czy dobrze wpisane są nasze interfejsy. Widzę, że zony są wpisane źle, więc poprawiam ich nazwy. Następnie Panhandler pyta się jak nazwać naszą sieć VPN – pozostańmy przy „corp-vpn”. Zapisuję sobie tę konfigurację i podaję adres IP naszego gateway’a – jest to adres IP managementowy – i credentiale, którymi muszę się połączyć. Robimy Commit i czekamy na to aż ten Commit się zainstaluje i będziemy mieć komunikat w Panhandlerze, że nasza konfiguracja została zapisana. W międzyczasie przygotowuję się do otwarcia okna klienta. Mamy informację, że konfiguracja została wepchnięta i nastąpił sukces zainstalowania tejże konfiguracji. Zanim przejdziemy do Klienta to jeszcze chciałem zweryfikować czy rzeczywiście tak nastąpiło. Odświeżę sobie informacje na temat portalu i rzeczywiście pojawił mi się portal dla GlobalProtecta, pojawił się dla niego gateway i wszystko jest skonfigurowane. Przejdę sobie do certyfikatów – sprawdzę, czy pojawiły się certyfikaty o których wspomniał nam GlobalProtect Skillet – rzeczywiście, są dwa certyfikaty. Przy politykach deszyfracyjnych nic się nie zmieniło, więc tutaj musielibyśmy dodać zonę korporacyjnego VPN. Możemy ją dodać od razu, ponieważ akurat polityka deszyfracyjna nie jest w zakresie tego skilleta implementowana. Jeżeli chodzi o NAT, pojawiła nam się druga reguła, tzw. Outbound. Gdybyśmy mieli regułą o takiej nazwie to pewnie zostałaby nad to nadpisana, natomiast widać, że w tej regule pojawił się kod VPN to untrust, czyli notowanie prywatnych adresów do adresu na zewnątrz.

40:42
Wszystko jest dobrze więc powinniśmy mieć dostęp na zewnątrz. Pojawiły się dwie reguły – „Outbound Access”, gdzie pojawił się kod VPN i trust na zewnątrz i „VPN to trust”, czyli połączenie VPN od naszego hosta do naszego środowiska korporacyjnego. Nie będę tutaj zmieniał nic w ramach tych polityk, ponieważ na chwilę obecną interesuje mnie tylko czy będzie to działało. Warto tutaj jednak wspomnieć, że w momencie, gdy już taki VPN został zaimplementowany, to należy się skupić na odpowiednim ucięciu horyzontu ataku dla hakera i wpisaniu odpowiednich aplikacji, profili bezpieczeństwa, żeby takie połączenie było bezpieczne. Loguję się na swojego użytkownika, czyli Sheldon. Zapomniałem jednak o jednej ważnej rzeczy. Nasz skillet tworzy gateway’a z uwierzytelnianiem lokalnym użytkowników, więc chciałbym dodać uwierzytelnianie domenowe. Mam już przygotowaną integrację z Active Directory, więc zajmuje mi to dosłownie chwilę. Wyedytowałem ustawienia dla portalu, teraz wyedytuję ustawienia dla gateway’a i zainstaluję politykę bezpieczeństwa. W momencie kiedy polityka bezpieczeństwa się instaluje, możemy to ukryć i podglądać w tzw. task menadżerze działania, które są realizowane na gateway’u. Poczekajmy aż będzie 99%, wówczas będziemy mogli przeskoczyć już na samego hosta i edytować sobie w nim ustawienia. Możemy już przeskoczyć na hosta i na hoście mamy po pierwsze Cortex XDR preventa zainstalowanego, czyli nasze rozwiązanie Advanced Endpoint Protection i również mamy zmianę w pliku hosts. Ze względu na to, że nie mam domeny dopisanej do adresu prywatnego więc po prostu zmieniłem plik host tak, żeby był identyfikowany ten wpis domenowy. Połączymy się przez przeglądarkę Google Chrome do serwisu, na którym powinien stać GlobalProtect Portal. Wyśmienicie, mamy błąd o certyfikacie, ponieważ nie mamy zaimplementowanego GlobalProtect CA certyfikatu. Wpisujemy naszego użytkownika już domenowego z jego hasłem i Sheldon jak widać ma dostęp do pobrania klienta GlobalProtect. Wybieramy wersję odpowiednią dla jego systemu operacyjnego. Jeżeli chodzi o klientów mobilnych, to muszą oni sobie pobrać wersję GlobalProtecta z AppStore lub Google Play, żeby móc zainstalować taką aplikację i z niej korzystać.

44:50
W następnym etapie następuje instalacja klienta GlobalProtect i postaramy się połączyć tunelem VPN do środowiska korporacyjnego. Sheldon nie ma ustawień local admina, więc nie jest w stanie instalować aplikacji. Oczywiście GlobalProtect możemy wypchnąć w ramach ustawień GPO w naszym środowisku i wówczas użytkownicy nie będą musieli realizować tego kroku wspólnie z supportem. Czekamy aż aplikacja GlobalProtect ze wszystkimi swoimi usługami się uruchomi, wówczas powinniśmy otrzymać okienko logowania. I rzeczywiście mamy okno logowania, wpisujemy znowu nazwę portalu, która w tym przypadku akurat jest także nazwą gateway’a, bo ta sama maszyna wirtualna go wystawia, więc tutaj nie ma żadnej zmiany. I próbujemy się połączyć. Pojawia się informacja na temat certyfikatu, akceptujemy go, wpisujemy credentiale i mamy sukces – połączyliśmy się do naszego środowiska korporacyjnego zaledwie w kilka minut. Jeżeli chodzi o możliwości konfiguracji split-tunelingu to dla ustawień agenta mamy możliwość zweryfikowania client settings i w tych ustawieniach możemy definiować kryteria dla samych użytkowników, z czego się łączą, z jakich adresów, z jakich systemów operacyjnych, natomiast mamy też informację na temat split-tunelingu. Gdy dostaniemy się do tej informacji, to ciekawostka jest taka, że możemy to robić w klasycznym wydaniu po odpowiednich podsieciach, ale jeżeli korzystamy z wersji tunelowania całego ruchu przez GlobalProtecta do naszego firewalla, to możemy to również robić w poddomenie i aplikacji. Ciekawostka: jeżeli chcielibyśmy aplikację typu Zoom ustawić w ten sposób, żeby tylko i wyłącznie per aplikacja, per domeny dla niej dostępne, ten ruch nie był tunelowany do naszego środowiska korporacyjnego, a był tunelowany na zewnątrz ze względu na to, że jest to aplikacja, która wymaga niewielkich opóźnień, wymaga dosyć dużej przepustowości, nie przepuszczania tego dookoła świata. Otworzę sobie przykład, jak można Zooma w czterech krokach uruchomić w ramach podziału domenowego i podziału per aplikacja na firewallu Palo Alto Networks. Po pierwsze dodajemy tzw. domeny do exclude’a i to są dwie domeny w przypadku Zooma – cloudfront.net i zoom.us – wildcard na początku oczywiście ze względu na to, że mogą tam być zawarte subdomeny. Dodaję porty, które są wymagane dla tych domen. Drugim elementem jest dodanie samej aplikacji i jej źródła, tak jak ona pobiera się dla naszego użytkownika w ramach hosta, w ramach którego on będzie tę sesję prowadził. Dodaję więc dwa programy, które są potrzebne do tego, żeby ich nie tunelować i w ten sposób poprzez prostą konfigurację dla excludowanych domen i aplikacji, jestem w stanie robić split-tuneling, który nie jest klasycznym split-tunelingiem, czyli tylko i wyłącznie dla aplikacji, które zdecydujemy, że chcemy wypuścić, które zdecydujemy, że są bezpieczne i w miarę szyfrowane, to jest aplikacje o odpowiednich poziomach certyfikacji zewnętrznych jako SaaS. Ta aplikacja w ten sposób może zostać ustawiona i zacommitowa. Jest jeszcze jedna ciekawostka dla GlobalProtecta – możemy pewne aplikacje typu Video Traffic, wyrzucić z naszego tunelu, np. jeżeli nasi użytkownicy korzystają z YouTube streamingu, Vimeo albo Netflixa, to możemy takie aplikacje dorzucić i w ten sposób odciążyć nasz tunel VPN tylko i wyłącznie do tego co jest krytyczne, do aplikacji, które chcemy kontrolować dla naszego użytkownika, do aplikacji, które nie są korporacyjnie znane jako te które potrzebują małych opóźnień i szybkiego łącza. Mam nadzieję, że udało mi się wytłumaczyć jakąś część tego, jak skonfigurować GlobalProtecta i jak z niego korzystać. Serdecznie polecam narzędzie Panhandler i przećwiczenie sobie z nim pewnych configów, ze względu na to, że te narzędzie daje nam w ciągu jednego dnia bardzo dobrą, gotową konfigurację, nie tylko dla GlobalProtecta, ale też dla pozostałych funkcjonalności firewalli Palo Alto Networks.

— Pytania —

52:11
„Jak mam innego producenta, to czy muszę przepisywać u was wszystko na nowo?”
Dawid: Nie trzeba przepisywać wszystkiego na nowo, ponieważ Palo Alto Networks posiada dedykowane narzędzie do przenoszenia konfiguracji, z którego można skorzystać. W sytuacji, gdy robi to EXATEL, to poza samym przenoszeniem konfiguracji, możemy też przeprowadzić analizę czy dana konfiguracja odpowiada Państwa rzeczywistym potrzebom i czy jest zgodna z best practice. Dodam, że poza samą platformą, Palo Alto Networks ma mocno rozbudowaną ofertę narzędzi wspomagających, np. Panhandler. Są też narzędzia, które umożliwiają wykorzystanie machine learningu, który podpowiada jakie polityki powinniśmy utworzyć np. w sytuacji, gdy spora część naszego ruchu generowana jest przez VPN. Marcin: Wspomniałeś o machine learningu – w momencie gdy migrujemy politykę, jesteśmy w stanie ją zmigrować 1:1 z rozwiązania konkurencyjnego (oczywiście naszych głównych konkurentów na rynku), natomiast w momencie kiedy ta konfiguracja jest przeniesiona, mamy już na samym firewallu coś co nazywa się Policy Optimizer. Policy Optimizer jest o tyle dobry, że w momencie kiedy już firewall Palo Alto Networks stoi z tą konfiguracją w środowisku klienckim, jesteśmy w stanie w przeciągu tygodnia/dwóch zaobserwować sobie jakie aplikacje wpadają do jakich reguł i w tym momencie jesteśmy w stanie zawęzić ten horyzont zdarzeń, który będzie dla nas istotny, czyli dopisać od razu politykę aplikacyjną dla reguł, zobaczyć które reguły są aktywne, a które nie istnieją ze względu na hit county, które pojawiają się przy regułach i oczywiście zweryfikować sobie tę konfigurację, bo może się okazać, że niektóre reguły w momencie w którym będziemy dodawać aplikacje, staną się regułami powtarzającymi się. Fajne, przyjazne narzędzie, w WebUI – bardzo szybko się konfiguruje wówczas polityki w oparciu o aplikacje. Oczywiście tych polityk trochę przyrośnie. Nie oszukujmy się – nie każdy użytkownik do każdej aplikacji powinien mieć dostęp. Jeżeli chodzi o GlobalProtecta, to oprócz iron skilletów, mamy jeszcze inną opcję automatyzacji. Jeżeli ta polityka zostanie stworzona dla VPN to również podchodzi ona pod Policy Optimizera, tam też jesteśmy w stanie dla każdego użytkownika VPN otworzyć odpowiednie polityki per aplikacja, żeby nie było tak, że nasi użytkownicy przez naszą sieć korporacyjną widzieli content, którego nie chcemy, żeby widzieli w ramach swoich dostępów. Expedition jest bardzo przyjemny pod tym kątem, że oprócz rzeczywiście machine learningu, i przenoszenia konfiguracji, możemy się do niego podpiąć samym firewallem jeszcze nie skonfigurowanym po API. Jak już jesteśmy gotowi wypchnąć tę politykę, to nie robimy tego przez przerzucanie plików, wgrywanie ich znowu na firewalla, tylko wypuszczamy, commitujemy to tak, jak zrobiłem to z GlobalProtect skilletem, który był wypuszczany przez Panhandlera. To samo możemy zrobić z Expedition jeżeli firewall jest podłączony i później weryfikować sobie tę konfigurację na firewallu. Expedition jest o tyle fajny, że możemy również robić konfigurację między firewallami Palo Alto Networks, np. między starszym a nowszym modelem, między modelem mniejszym a większym, jeżeli aktualizujemy rozwiązanie u siebie.

57:48
„Co jeśli mam łącze od innego operatora niż EXATEL? Czy taka usługa firewalla też może być u mnie?”
Dawid: To jest tak, że jeżeli nie są Państwo klientami usługi telekomunikacyjnej z EXATEL, to oczywiście Managed Firewall też może być dla Państwa i też nim zarządzamy w 100%. Generalnie nie ma tutaj przywiązania co do infrastruktury operatorskiej. W tym modelu oczywiście nie można skorzystać z multi tenanta i dajemy wtedy dedykowane pudełko ale jest ono zapięte do naszych mechanizmów zarządzania, tj. panorama Palo Alto Networks do której podpinany jest Państwa firewall, który u Państwa pracuje i w ten sposób mamy bieżące zarządzanie i monitoring takim rozwiązaniem. Oczywiście dla tych, którzy mają łącza operatorskie od EXATEL, bądź też zastanawiają się nad taką opcją, to są tutaj dwie możliwości: albo multi tenant (jeżeli są to mniejsze wymagania), albo całe pudełko, które jest skalowane w zależności od Państwa potrzeb i instalowane u Państwa przez nas.

59:00
„Jest jakiś schemat postępowania żeby ocenić czy moja konfiguracja jest w porządku, ale niezależnie od tego skąd mam VPN?”
Dawid: Tych schematów jest wiele, natomiast żeby tak z wielu perspektyw spojrzeć na Państwa obecną konfigurację, potrzeby i wykorzystanie potem tej konfiguracji przez użytkowników, bądź ewentualnie wskazanie następstw tej konfiguracji, to tutaj dobrze wpisuje się właśnie nie tylko ta techniczna część, ale taki rekonesans bezpieczeństwa i wtedy też będzie część pentesterska, podczas której będzie możliwość konfiguracji, ale też ludzie którzy znają się od tej części procesowej, którzy widzą pewne inne zagrożenia i mogą podpowiedzieć, że niekoniecznie wszyscy użytkownicy muszą mieć dostęp do tych samych aplikacji pracując zdalnie czy też nie wszystkie dane muszą być dostępne w przypadku połączenia VPN. Są to też pewnego rodzaju ryzyka, które jesteśmy w stanie zidentyfikować. Marcin: Jeżeliby to było Palo Alto Networks, to zdecydowanie musimy wyjść od trzech koronnych założeń firmy, czyli: identyfikacja użytkowników, identyfikacja aplikacji z których korzystają użytkownicy i każdy ruch dopuszczony chronimy pod kątem odpowiednich profili bezpieczeństwa. Oczywiście u nas jest to o tyle łatwe, że mamy narzędzie Policy Optimizer, które jest zarządzane w oparciu o zbierane logi, czyli w momencie kiedy zbierzemy logi w naszym środowisku, widzimy jakie aplikacje dla jakich użytkowników się pojawiają i wtedy możemy tworzyć odpowiednie grupy VPN dla tych użytkowników z dostępem VPN. Warto też skorzystać z naszego narzędzia, które jest dostępne na stronie supportowej dla każdego klienta, który korzysta z naszych rozwiązań i to jest best practice assessment, który pozwala nam na przejrzenie skonfigurowanych polityk bezpieczeństwa pod kątem tzw. heatmap, czyli tego czy każda polityka bezpieczeństwa posiada w sobie odpowiednie funkcjonalności, czy ma zdefiniowane odpowiednie profile bezpieczeństwa i na jakim poziomie. Mamy wówczas taką wysoko poziomową ocenę każdej z reguł. Co więcej, jeżeli przejdziemy od heatmap do rekomendowanych najlepszych praktyk, to raport poinformuje nas o tym czy wszystkie konfiguracje związane z samym GlobalProtectem są dobre, czyli tak naprawdę czy nie zostawiliśmy jakiejś dziury, czy za bardzo nie otworzyliśmy tego dostępu dla naszych użytkowników, czy coś jest nie tak z naszymi gateway’ami, które otworzyliśmy w ramach tej instancji.

Dawid Zięcina, Kierownik Projektu, EXATEL S.A. Marcin Szewczuk, Systems Engineer, Palo Alto Networks