Więcej miejsc do posłuchania:
WERSJA TEKSTOWA
Cześć. Witam Cię w dzisiejszym odcinku mojego podkastu. Dzisiejszy temat to zmiana na Firewallach w kontekście analizy ruchu http/https. Co się zmienia? Przede wszystkim jest teraz nowa zmiana, implementacja z HTTP2.0 do HTTP3. Czym jest podyktowana ta nowość? Przede wszystkim problem, który jest do rozwiązania to jest zmniejszenie czasu opóźnień pomiędzy wywołaniem danej strony internetowej a wyświetleniem się tej strony internetowej. W przypadku HTTP1.1 i HTTP2.0 to opóźnienie może wynosić nawet 0,5 sekundy. To jest dość dużo. Jest to dość zauważalne z punktu widzenia użytkownika. Prace nad tym, żeby zminimalizować ten czas trwają już dość długo. Czyli możemy spokojnie powiedzieć, że przez ostatnie 10 lat próbowano w ramach współpracy protokołu w tradycyjny sposób na warstwie TCP zmniejszyć ten czas. Nie za bardzo się to udało w związku z tym podjęto nową próbę podejścia do tematu zmniejszenia opóźnienia pomiędzy wywołaniem strony internetowej a jej wyświetleniem poprzez modyfikację protokołu. Zdecydowano się na wejście w protokół UDP wersji HTTP3.0 i wykorzystanie wyższej warstwy aplikacyjnej, czyli protokołu QUIC do tego, żeby skrócić czas negocjacji pomiędzy urządzeniami.
Teraz na chwilę możemy się zatrzymać i zastanowić, co tak naprawdę jest wykonywane w momencie, kiedy próbujesz otworzyć stronę. Zakładamy oczywiście w dzisiejszym środowisku, że ta strona jest zabezpieczana TLS-em. Czyli jeżeli popatrzysz sobie najpierw na protokół HTTP2.0 to używamy protokołu IP oczywiście, potem TCP a następnie TLS-a i dopiero później protokołu HTTP, który jest chroniony przez to szyfrowanie TLS-owe. TCP zawiera konieczność negocjowania, czyli jest to protokół połączeniowy pomiędzy stronami. Pomiędzy klientem i serwerem. Protokół TLS również negocjuje pomiędzy serwerem a klientem. Parametry szyfrowania, uwierzytelnianie, potwierdzanie tożsamości, tego typu atrybuty. Dopiero mamy tą warstwę HTTP, czyli protokołu, który nam faktycznie przesyła wartość informacji i jest w stanie z tej informacji zbudować stronę internetową w naszej przeglądarce. Całość tych procesów, jeżeli popatrzymy na wykonywanie w poszczególnych krokach, jest dość długa w kontekście przynajmniej specyfiki sieciowej. Czyli wspomniane wcześniej pół sekundy – 500 milisekund – to jest dość długi okres.
W przypadku, gdy chcielibyśmy skrócić ten element, to co możemy zrobić? Możemy oczywiście próbować wyeliminować ten protokół TCP, czyli przełączyć się na UDP i to właśnie zostało zrobione w kontekście tego HTTP3.0 i RFC, które były załączone jakby do tej specyfikacji. Natomiast nie samo to znacząco przyśpiesza sytuację, tylko uwalnia nas od pewnych ograniczeń protokołu TCP. Następnie w protokole QUIC, czyli warstwę wyżej zaimplementowano podobne mechanizmy jak w TCP, czyli połączeniową strukturę. Klient z serwerem sobie może wynegocjować to połączenie. Na to oczywiście nakładamy TLS-a, czyli mamy możliwość zaszyfrowania tego ruchu.
To co dodatkowo chciano już zrobić od 10 lat, ale ponieważ protokół TCP jest bardzo wiekowy i dużo implementacji jest już zainstalowanych, to trudno jest tego typu protokół modyfikować. To zajmuje bardzo dużo czasu. Implementacja tych zmian w protokole również zajmuje bardzo dużo czasu, bo producenci poszczególnych rozwiązań muszą zaimplementować pewne rozszerzenia, chociażby do TCP. W związku z tym uproszczenie tej warstwy czwartej, czyli przejście na UDP a realizowanie połączeniowej struktury w QUIC-u jest optymalizacją. Optymalizacją, którą można szybciej wdrożyć i w kolejnej wersji przeglądarki już obsługiwać nowszy sposób przetwarzania informacji. Co pozwala składać te różne sesje ze sobą, czyli jeżeli masz UDP, które jest bezpołączeniowe, następnie masz QUIC-a, który wykonuje pewne negocjacje połączeniowe, na to masz TLS-a, który też wykonuje pewne połączeniowe negocjacje, to wykonywanie tych negocjacji równolegle, skraca ten czas opóźnienia. O to generalnie chodzi, to jest ta optymalizacja, docelowo w przypadku HTTP3.0. Możemy skrócić znacząco opóźnienie wyświetlania stron pomiędzy użytkownikami.
Teraz zastanówmy się chwilę jaki to ma wpływ na nasze Firewalle, czyli co to tak naprawdę zmienia dla infrastruktury. Jeżeli chodzi o Firewalle to mamy tutaj oczywiście dwie takie generacje. Starsza, która działa na warstwie trzeciej, czwartej, czyli możemy pisać reguły dotyczące IP i portu. Mamy też Firewalle aplikacyjne, które są w stanie rozkładać informacje wyższych warstw i analizować ten payload, czyli tą zawartość i na przykład strukturę tego protokołu HTTP. Na tej podstawie starać się zabezpieczać, analizować, blokować jakie akcje tam skonfigurujemy. Teraz jeżeli chodzi o Firewalle takie klasyczne, warstwy trzeciej i czwartej, to one nadal tą samą funkcję mogą nam zapewnić i tą samą wersję dostarczać. One się nam sprawdzają tylko na poziomie zapewniania koncepcji, czy takich ograniczeń komunikacji pomiędzy tym jakie zasoby np. dana grupa urządzeń o danym adresie IP ma dostęp do jakich serwerów i w jakich podsieciach. Ten element możemy realizować, natomiast to co ja widzę dzisiaj to to, że mamy coraz więcej możliwości realizowania tego typu prostych reguł opartych o IP i ewentualnie porty, na urządzenia, które nie są sesyjne, np. na przełącznikach. Gdy połączymy to z uwierzytelnianiem, czyli z jakimś rozwiązaniem NAC-owym, z jakąś polityką, którą przypisujemy to swobodnie możemy realizować ograniczenia na poziomie IP warstwy czwartej na urządzeniach dostępowych, co ma konkretne zalety.
Po pierwsze nie musimy wysyłać całego ruchu do Firewalla centralnie, żeby móc proste reguły wymuszać. Druga rzecz jest taka, że mamy to wymuszanie na brzegu, czyli nie ma możliwości przejść już od urządzenia brzegowego dalej, jeżeli nie spełnia to urządzenie danych wymagań polityki bezpieczeństwa. To jest rzecz, która się cały czas dzieje od lat, to nie jest nic nowego.
Przejdźmy teraz do tej drugiej grupy Firewalli aplikacyjnych. Mają one jeden podstawowy problem. To szyfrowanie, którego używamy standardowo, czyli dzisiaj TLS 1.3, oznacza, że Firewall czy jakiekolwiek inne urządzenie, nie widzi zawartości tej sesji. Jeśli chcielibyśmy ją analizować, to musimy tą sesję terminować na Firewallu, na Load Ballancerze, zdjąć to szyfrowanie i wtedy możemy analizować to co jest w środku, w tym naszym pakiecie zaszyfrowanym. To jest element, który też od lat jest problematyczny i rozwiązuje się go na dwa sposoby. Jeżeli masz sytuację taką, że masz tego Firewalla i te zasoby, które udostępniasz po swojej stronie, w swoim data center, to najczęściej terminujesz tą sesję wystawiając certyfikat tego serwera na Firewallu, tak żeby z punktu widzenia klienta końcowego wyglądało to tak, że on sobie sesję TLS-ową zestawia z serwerem. To samo najczęściej się robi na Load Ballancerach . Jest to jedna z opcji oczywiście, ale tak się często robi, ponieważ zakładamy, że jeżeli tą strukturę naszą Data Center kontrolujemy, to zapewnienie takiego bezpiecznego połączenia pomiędzy Firewallem czy Load Balancer a serwerem, który stoi najczęściej w tej samej komorze data center albo w racku obok albo nawet w tym samym racku to nie jest dla nas zagrożenie, bo my kontrolujemy fizycznie to środowisko. Natomiast jeżeli mówimy teraz o HTTP3.0 to pod tym kątem się nie zmieniło nic, może jedna rzecz. W 2.0 była możliwość używania HTTP w wersji nieszyfrowanej, czyli bez TLS-a, co praktycznie nie było implementowane w klientach, czyli tych przeglądarkach. W przypadku wersji 3.0 to już jest jedyna możliwość, czyli nie mam opcji zestawiania połączenia HTTP3.0 pomiędzy klientem a serwerem bez szyfrowania. W związku mamy tą konieczność deszyfrowania. To jest jedna opcja, jeśli mamy te serwery po naszej stronie w naszej serwerowni.
Gdy te nasze zasoby, które wystawiamy, np. strona publiczna jest najczęściej kupowana w jakiejś usłudze chmurowej lub hostingowej. Gdzieś na zewnątrz, gdzie nie mamy wpływu na tą infrastrukturę fizyczną i nie możemy sobie tak łatwo zadecydować o terminacji sesji TLS wcześniej. Pozostaje nam opcja SWG (Security Web Gateway), czyli tego webowego Gateway-a. To jest koncepcja bardzo podobna do terminowania sesji TLS-owej na Firewallu w wersji w naszej serwerowni. Tyle tylko, że to jest taka usługa, najczęściej w chmurze dla zasobów chmurowych. Czyli jeżeli chcemy zabezpieczyć naszych użytkowników w ten sposób, że analizujemy ich sesje, które przechodzą np. HTTPS do jakiś nieznanych nam zasobów w Internecie, ale chcielibyśmy monitorować ten ruch, np sprawdzać jakie tam są skrypty uruchamiane, czy jest tam zastosowana jakaś fragmentacja. Generalnie takie typowe techniki atakowana różnych urządzeń, to musimy ten ruch deszyfrować. Tak się właśnie robi. Mamy jakiegoś klienta, który nam szyfruje ruch do naszego Secure Web Gateway i on w naszym imieniu odpytuje dany zasób. Odpowiedź, która wraca również jest zaszyfrowywana od strony serwera na Software Web Gateway jest odszyfrowywana, żeby móc ją przeanalizować. Następnie znowu jest szyfrowana i przesyłana do klienta. Jak widzisz ma to oczywiście swoje konsekwencje wydajnościowe. Nie ma co się oszukiwać, jeżeli muszą być pewne procesy wykonane to zwiększamy to wymaganie na moc obliczeniową, ale zwiększamy też opóźnienie. Więc zawsze jest coś za coś. Tutaj ewidentnie za dużo innych opcji nie mamy. Możemy rozważyć jeszcze jedną rzecz pod kątem widzenia ruchu, który jeszcze nie jest zaszyfrowany TLS-em – mianowicie stronę stacji końcowej. Tu w zależności od aplikacji, jeśli mamy możliwość ingerencji w warstwę aplikacyjną, która zawiera pewne dane i dopiero jest przekazywana do szyfrowania do TLS-a to tu też jest jakiś obszar, który moglibyśmy wykorzystać do analizy przed zaszyfrowaniem tego ruchu. To nie jest trywialne, nie jest proste, dlatego, że to zależy od aplikacji. Weźmy sobie tą przeglądarkę wspomnianą za przykład. Gdy otwiera ona stronę i chce to zapytanie, które idzie do serwera www zaszyfrować to robi to na swojej warstwie aplikacyjnej, czyli bardzo wysoko. Jak byśmy chcieli ingerować w ten poziom informacji to musimy ingerować w ten sposób działania czy wysyłania informacji od przeglądarki co generalnie jest bardzo trudne do wykonania.
Sytuacja z punktu widzenia bezpieczeństwa się zmienia, ale oznacza to też, że komplikuje nam to nasze dotychczasowe sposoby tego jak zabezpieczamy daną infrastrukturę, dane połączenie, Endpointa. Nakłada nam to nowe ograniczenia i nowe wyzwania. To co się najczęściej robi w takich przypadkach to oczywiście dba się o tego Endpointa na zasadzie nakładania polityki co klient może zrobić, jakie pliki może otworzyć albo czy te pliki są zeskanowane najpierw zanim je otwiera. Ostatnio też popularne funkcjonalności, czyli przykrywania URL-i, żeby ktoś nie wszedł na stronę przypominającą prawdziwy serwis a odpowiednio przygotowaną do zhakowania przeglądarki. URL-e są weryfikowane zanim użytkownik może w nie kliknąć. Np dostajesz takiego maila z URL-em i już jest on podmieniony w taki sposób, że najpierw jest testowana nazwa domenowa – czyli ten URL zanim będziesz mógł go otworzyć. Staramy się pewne możliwości monitoringu i zabezpieczania stacji końcowej implementować (oczywiście antywirus). Robimy wszystko, co możemy na stacji końcowej, ponieważ wiadomo, że dziś najsłabszym punktem wszystkich naszych instalacji są punkty końcowe i użytkownicy końcowi. To jest coś co jest najczęściej celem ataku dlatego, że dużo łatwiej jest zabezpieczyć centralne zasoby, gdzie mamy jakiegoś gateway-a, gdzie możemy kontrolować ten ruch, gdzie możemy go odszyfrowywać i powiedzieć, że w przypadku, gdy nie da się zrobić tego co chcemy to ruch ten odrzucamy. To jest dużo łatwiej zrobić. Natomiast na Endpoincie, jak ten profil wykorzystania przez użytkownika jest bardzo różny, teoretycznie moglibyśmy to nadal zrobić, tylko znam też takie przypadki implementacji zabezpieczenia stacji końcowej do takiego poziomu, że to jest później bardzo trudne w używaniu. Użytkownicy minimalizują swój zakres pracy. Używają laptopa firmowego tylko minimalnie do tego, co potrzebują. Jak nie da się tego zrobić na laptopie firmowym, to nie robią tego wcale albo robią sobie to na innym urządzeniu. Użytkownik obchodzi te ograniczenia i trudności, które ma w użytkowaniu w związku z tym, że ten poziom bezpieczeństwa i reguł na stacji końcowej jest bardzo wysoko podniesiony. Więc jest to zawsze bardzo ważna kwestia wyważenia pomiędzy tą używalnością i bezpieczeństwem tego naszego rozwiązania.
Mam nadzieję, że było to dla Ciebie ciekawe, jeżeli masz jakieś pytania co do poszczególnych aspektów to zapraszam do zadania ich w komentarzu. Na dziś to tyle, dziękuję Ci za uwagę i do usłyszenia już za tydzień.
