Jeśli spojrzeć na współczesne centrum danych, składa się ono głównie z wirtualnych maszyn. Poszczególne serwery połączone są najczęściej okablowaniem 10 GB/s, a w rdzeniu sieci używa się również 40 GB/s. Komunikacja między lokalizacjami odbywa się z użyciem światłowodów i MPLS czy szybkich połączeń VPN. Dane są przenoszone między serwerami oraz między serwerami a urządzeniami klienckimi. Położenie zmieniają aplikacje i maszyny wirtualne. Patrząc na ten krajobraz, pojawia się pytanie, gdzie umieścić zabezpieczenia sieciowe, aby jednocześnie zapewnić bezpieczeństwo, mobilność oraz wysoką wydajność?

W centrum danych mamy do czynienia z dwoma rodzajami ruchu: północ-południe (między serwerami i urządzeniami klienckimi) oraz wschód-zachód (między serwerami). Ten drugi rodzaj ruchu często bywa ignorowany, ponieważ przez lata stanowił niewielki odsetek ruchu sieciowego w centrach danych. W ostatnich latach zaczyna jednak narastać, przez co wymaga większej uwagi. Odpowiedzią na to wyzwanie jest rozproszony firewall.

Zobacz również:

• Palo Alto wzywa pilnie użytkowników jej zapór sieciowych, aby jak najszybciej zaktualizowali zarządzające nimi oprogramowanie
• Dzięki tej umowie polska policja zyska wiedzę i narzędzia zapobiegające cyfrowym zagrożeniom

Bezpieczeństwo bez granic

Gdyby środki finansowane nie stanowiły bariery, topologia sieci i zabezpieczeń z pewnością byłaby inna i wyglądała prawdopodobnie tak. Każdy serwer w centrum danych byłby bezpośrednio podłączony do potężnej zapory sieciowej. Każdy pakiet byłby analizowany z użyciem reguł uwzględniających stan połączeń, zanim zostałby przepuszczony dalej. Poza tym każdy pakiet odbierany przez serwery byłby analizowany przez ostateczną regułę, zanim dotarłby do bufora danego interfejsu sieciowego. Firewall nie musiałby uwzględniać adresu IP serwera, ponieważ maszyny byłyby połączone ze sobą bezpośrednio. Reguły wyglądałyby więc mniej więcej tak: ten serwer na tym porcie może komunikować się z tamtym serwerem na porcie X protokołu TCP. Poza tym firewall miałby bardzo szczegółowe informacje o podłączonych do niego serwerach, co umożliwiałoby tworzenie reguł wykorzystujących wiele dodatkowych parametrów. Na koniec, te wszystkie operacje byłyby realizowane bez utraty wydajności.

To piękna, lecz nierealna wizja. Pieniądze niestety stanowią barierę, ale dzisiejsze technologia sprawia, że nawet w takich warunkach można pokusić się o zbudowanie „wszechobecnego” firewalla. Można by to zrealizować na trzy sposoby. Pierwszy zakłada zbudowanie dużej maszyny pracującej z szybkością interfejsów i wyposażoną w tysiące portów liniowych. Tu pojawia się problem – jak uporządkować ogromną ilość okablowania prowadzącego do takiej maszyny? Co więcej, potrzebne są dwie takie maszyny, aby zapewnić redundancję. Taka zapora sprawdzałaby się świetnie tylko w warstwach L2 i L3. Ponadto wcześniej czy później skończyłyby się wolne porty.

Druga koncepcja mówi o zbudowania zapór sieciowych zastępujących przełączniki typu Top of Rack. W efekcie w centrum danych pracowałyby dziesiątki takich firewalli, wymagających stałego zarządzania i konfigurowania. Tym musieliby się zająć administratorzy sieciowi, opiekujący się dotąd przełącznikami. Dlatego te dwa sposoby w praktyce nie mają szans na realizację w praktyce. Niestety, koncepcje ulepszenia zabezpieczeń często stoją w opozycji do efektywnego działania sieci. Pozostaje jeszcze trzecie rozwiązanie, o którym w dalszej części artykułu.

W świecie rzeczywistym mamy firewalle, które powinny zapewniać nam bezpieczeństwo. Jednak ten rodzaj zabezpieczeń nie jest wszechobecny, jak również nie daje gwarancji pełnego bezpieczeństwa. Zamiast tego mamy firewalle (fizyczne i wirtualne) podłączone w różnych miejscach do sieci i analizujące przechodzące przez nie pakiety. Administrator może więc tylko po cichu liczyć, że sieć została poprawnie skonfigurowana i właściwy ruch jest analizowany przez właściwe reguły.

Fizyczne zapory sieciowe

Ten rodzaj zabezpieczenia jest dobrze znany administratorom. Fizyczne firewalle często są wyposażone w specjalizowane układy sprzętowe, które dobrze radzą sobie z ochroną sieci i oferują określoną wydajność mierzoną szybkością przesyłania danych lub liczbą pakietów czy sesji analizowanych w ciągu sekundy. Do rozwiązań z górnej półki zaliczamy modele pracujące przynajmniej z szybkością 10 GB/s i są to kosztowne urządzenia. Nie mają one wystarczającej liczby portów, aby bezpośrednio podłączyć do nich serwery. Zamiast tego serwery podłącza się do przełączników i wdraża takie konfiguracje, które sprawią, że ruch zostanie przepuszczony przez zapory sieciowe.

W przypadku ruchu typu wschód-zachód (komunikacja między serwerami) takie podejście prowadzi do powstawania wąskich gardeł, które próbuje się niwelować poprzez wdrażanie wydajniejszych i mających większą liczbę portów firewalli. To oznacza koszty, na pokrycie których nie zawsze są środki.

Fizyczne firewalle nie są podłączone bezpośrednio do serwerów. W konsekwencji, reguły bezpieczeństwa są tylko tak dobre, jak informacje, które można wydobyć z przesyłanych pakietów, np. adres IP czy numery portów TCP/UDP. Wokół tych informacji są budowane reguły, np. dany adres IP może komunikować się z innym adresem IP na porcie TCP o numerze X. W momencie wdrażania nowej aplikacji osoby odpowiedzialne za zabezpieczenia muszą otrzymać opis tej aplikacji, zawierający, m.in. adres IP serwera i numery używanych przez nią portów TCP/UDP. Ponadto zadaniem administratorów sieci będzie modyfikacja ustawień tak, aby odpowiednio przekazywać ruch danej aplikacji do właściwego firewalla. Gdy z czasem aplikacja przestanie być potrzebna i zostanie usunięta, dotyczące ją reguły raczej nie zostaną skasowane i będą zaśmiecać firewall.

Po ustaleniu, który firewall będzie chronić tę aplikację, odpowiednie reguły zostaną dodane do istniejącej listy reguł, która może składać się nawet z kilku tysięcy reguł. Wiele z tych reguł będzie przestarzałych i zbędnych. Takie reguły są potencjalnym przyczynkiem do wrogiego ataku. Przykładowo, na prośbę użytkownika zostaje otwarty port w celu przepuszczania ruchu HTTP czy nawet HTTPS pomiędzy siecią korporacyjną a aplikacją działającą w chmurze. Kiedy aplikacja zostanie w przyszłości skasowana, z dużym prawdopodobieństwem użytkownik nie poinformuje administratora o możliwości zamknięcia danego portu. Włamywacz może odkryć pozostawioną lukę i użyć je do wykradania danych (wysyłania poza sieć korporacyjną). Wprawdzie są narzędzia do zarządzania regułami firewalli, ale nie są dostępne za darmo.

Jeszcze większe wyzwania zaczynają się przy wdrażaniu zwirtualizowanego środowiska wyposażonego w mechanizmy automatyzujące tworzenie maszyn wirtualnych i instalowanie w nich aplikacji. Fizyczne firewalle nie realizują dobrze swoich zadań w takim otoczeniu. To prowadzi do wniosku, że wirtualne aplikacje mogą potrzebować wirtualnych firewalli.