Zapory sieciowe, które chronią sieci firmowe, odgrywają bardzo ważną rolę w systemie bezpieczeństwa IT. Na osobach, które administrują tymi firewallami, leży duża odpowiedzialność, aby przepuszczać tylko odpowiedni rodzaj ruchu sieciowego, a blokować ten niechciany, stanowiący zagrożenie. Stawka jest wysoka, a przestrzeń na błędy niewielka. Co roku przygotowywany przez Verizon raport Data Breach Investigations pokazuje, że błędna konfiguracja urządzeń jest głównym źródłem podatności, które umożliwiają przeprowadzanie włamań. Potwierdza to Gartnera – według analityków aż 95% włamań przechodzących przez firewalle jest spowodowanych właśnie błędami w konfiguracji.

Mając to na uwadze, warto przyjrzeć się popularnym wyzwaniom w konfiguracji tych urządzeń oraz sposobom, jak unikać pomyłek czy innych problemów, które powodują, że firewall nie wypełnia należycie swojej misji. W skrócie, należy:

• Stale porównywać zmiany wprowadzane w konfiguracji zapór sieciowych z korporacyjnymi zasadami bezpieczeństwa oraz wymogami prawnymi.
• Usuwać zbędne reguły.
• Eliminować reguły powodujące konflikty.
• Stosować spójne procedury wnioskowania o zmiany w konfiguracji firewalli. To samo dotyczy wprowadzania tych zmian.
• Deweloperzy lub zespół DevOps powinni być w bliskim kontakcie z administratorami firewalli.

Zasady bezpieczeństwa

W większości dużych i średnich firm jest osoba odpowiedzialna za zarządzanie bezpieczeństwem lub przestrzeganie obowiązujących przepisów prawnych. Rzadziej ta osoba ma możliwość ustalania obowiązujących zasad i odpowiada, w jakimś stopniu, za przestrzeganie tych zasad w całym przedsiębiorstwie. Bardzo często ten menedżer bezpieczeństwa nie ma wglądu, co administratorzy robią przy zaporach sieciowych, konfigurujących ich reguły. Tymczasem reguły te mogą być sprzeczne z korporacyjnymi zasadami.

Zobacz również:

• Palo Alto wzywa pilnie użytkowników jej zapór sieciowych, aby jak najszybciej zaktualizowali zarządzające nimi oprogramowanie
• Firewall as a Service - nowy trend w cyberbezpieczeństwie

Przykładowo, administrator serwera może otworzyć porty, aby przepuszczać rozmaity ruch do firmowej sieci. Takie działanie może być ryzykowne i sprzeczne z którąś z ogólnych zasad bezpieczeństwa organizacji. Menedżer bezpieczeństwa powinien być informowany, jeśli reguły firewalli są modyfikowane i przez kogo, aby mieć możliwość sprawdzenia, czy zmiany są zgodne z obowiązującymi zasadami. Można to zrobić po prostu wysyłając wiadomość e-mail lub umożliwiając dostęp do konsoli zarządzania w celu przeglądania zmian w konfiguracji zapór sieciowych. Jeśli wprowadzona zmiana nie wygląda dobrze lub narusza firmowe zasady, menedżer bezpieczeństwa i administrator firewalli powinni przedyskutować jej biznesowe przeznaczenie.

Usuwanie nieużywanych reguł

Setki czy nawet tysiące reguł w konfiguracji firewalla, które nie są już potrzebne, to wcale nie jest rzadka sytuacja. Tymczasem nieużywane reguły mogą stwarzać zagrożenie. Przykładowo, przyjmijmy że otwarto port do komunikacji HTTP lub HTTPS pomiędzy siecią firmową a aplikacją w chmurze publicznej. Dział biznesowy, który korzystał z tej aplikacji, rezygnuje z niej, ale nie informuje administratora portu, że powinien zamknąć port. Hakerzy mogą wykryć otwarty port i wykorzystać go, np. do wysyłania danych poza sieć firmową. Są narzędzia do zarządzania firewallami, które mogą monitorować ruch sieciowy i określać, czy są otwarte porty, które nie były używane w zdefiniowanym okresie. Administrator firewalla może otrzymywać powiadomienia o wyglądających na nieużywane portach, aby następnie zbadać sytuację, czy faktycznie straciły już swoje zastosowanie biznesowe. Usunięcie zbędnych reguł, oprócz zwiększenia bezpieczeństwa, przyczynia się również do poprawy wydajności firewalla.

Eliminowanie konfliktowych reguł

Wiele zapór sieciowych ma tak złożony system reguł, że administratorzy czasem nie wiedzą, czy wprowadzana właśnie nowa reguła jest sprzeczna z którąś z dotychczasowych reguł. Taka sytuacja powoduje, że reguły mogą kompletnie nie spełniać swojego przeznaczenia, ponieważ zapora sieciowa działa na zasadzie pierwszego dopasowania. Wykonuje pierwszą regułę w łańcuchu, która spełnia kryteria dla danego ruchu. Usunięcie konfliktowych reguł jest trudnym zadaniem do ręcznego przeprowadzenia. Dobrze jest wykorzystać do tego celu odpowiednie narzędzia.

Procedury wprowadzania zmian

Reguły firewalli często nie są odpowiednio dokumentowane. Bez dobrej dokumentacji trudno stwierdzić, kto wnioskował o wprowadzenie określonej reguły i kto jest jej właścicielem z perspektywy biznesowej. To utrudnia spełnianie wymagań nakładanych przez regulacje prawne, ponieważ trudno wykazać, że dana reguła jest potrzebna. Jeśli przez połączenie przechodzi ruch sieciowy, wyzwaniem staje się określenie, czyj to jest ruch i jakim zastosowaniom służy.

Aby zapobiec takim problemom, nie wystarczy stosowanie prostych narzędzi. Wymagane jest zdefiniowanie firmowych procedur, które będą realizowane za każdym razem, kiedy pojawi się konieczność wprowadzenia zmian w konfiguracji zapór sieciowych.

Taki proces biznesowy powinien obejmować przedstawiciela biznesu, który wnioskuje o jej wprowadzenie, osobę, która zweryfikuje zgłoszenie i na koniec administratora, który wprowadzi te zmiany. Wprowadzane zmiany należy dokumentować i korelować z potrzebami biznesowymi. Mając na uwadze przyszłe porządki w konfiguracji firewalli, takie informacje pokażą kontekst biznesowy, a administrator firewalli będzie wiedział, z kim się skontaktować, aby ustalić, czy utworzona kilka lat wcześniej reguła jest jeszcze potrzebna.

Bliska współpraca

Często o utworzenie nowych reguł wnioskują osoby zajmujące się rozwojem aplikacji lub dostarczaniem nowych usług. Jak żadna inna grupa, ci ludzie posługują się własnym, technicznym żargonem, który dla administratorów firewalli może być trudny do zrozumienia (i vice versa). Innymi słowy, może upłynąć kilka iteracji, zanim nowa reguła firewalla zostanie właściwie skonfigurowana, ponieważ obie strony wzajemnie nie rozumieją się z należytą precyzją.

Na rynku są narzędzia, które usprawniają tę komunikację. Można nazwać je technicznymi tłumaczami. Deweloperzy aplikacji mogą określić reguły biznesowe dla swoich programów, używając języka, który jest na wyższym poziomie i bardziej abstrakcyjny, a system wykorzystując różne mechanizmy analityczne przetłumaczy je na poziom szczegółowości wymagany przy technicznej implementacji. Taki szczegółowy opis umożliwi administratorowi skonfigurowanie reguł. Mogą one zostać wdrożone nawet automatycznie. Taki techniczny tłumacz pomaga wyeliminować lub ograniczyć błędy w konfiguracji oraz oszczędza czas potrzebny na wprowadzenie zmian.

Optymalizacja konfiguracji zapory

Unikanie błędów w konfiguracji zapór sieciowych to jedno. Warto również przyjrzeć się zasadom, których przestrzeganie przy konfigurowaniu reguł zapewni wysoki poziom bezpieczeństwa i optymalną wydajnością.

Tworząc reguły bezpieczeństwa, należy nadawać minimalne uprawnienia spełniające wymagania. W firewallach często wprowadza się reguły o bardzo szerokim zasięgu, które zezwalają na przepuszczanie ruchu między różnymi lokalizacjami docelowymi i źródłowymi. Tak dzieje się, jeśli administrator sieci nie zna dokładnie wymagań. Wtedy na początek tworzy regułę o szerokim zasięgu, a później uszczegóławia ją. Jednak w praktyce presja czasu lub inne czynniki sprawiają, że często nie wraca się do raz utworzonych reguł, pozostawiając sieć wystawioną na zagrożenia. Dlatego należy przestrzegać zasady nadawania minimum uprawnień użytkownikom lub usługom, potrzebnych do prawidłowego funkcjonowania. W ten sposób ogranicza się ryzyko udanego włamania. Należy również dokumentować reguły, a najlepiej mapować przepływy sieciowe wymagane przez poszczególne aplikacje, zanim przydzieli się im dostęp. Dobrym pomysłem jest regularne przeglądanie reguł firewalla, aby sprawdzić trendy wykorzystania łącza przez aplikacje, wykryć nowe aplikacje i rodzaj łączności, której one wymagają.

W zaporach sieciowych należy uruchamiać tylko wymagane usług. Często zdarza się, że na tych urządzeniach działają usługi, które przestały być potrzebne, np. dynamicznych routing, którego nie należy włączać na urządzeniach służących bezpieczeństwu. W zaporze sieciowej może również działać serwer DHCP, zakłócający przyznawanie adresów IP przez właściwy serwer. Zaskakuje również, jak często zapory sieciowe są zarządzane z użyciem nieszyfrowanych protokołów, jak Telnet, mimo że ten protokół ma już ponad 30 lat.

Rozwiązaniem jest uszczelnienie konfiguracji urządzeń i zapewnienie, że ich konfiguracja jest zgodna z normami i regulacjami prawnymi, zanim takie urządzenie przejdzie do środowiska produkcyjnego. Jest to problem, z którym boryka się wiele firm. Konfigurując zapory sieciowe tak, aby ograniczyć ich funkcje do minimum spełniającego wymagania oraz pamiętając o zasadzie przydzielania minimum uprawnień, można znacznie podnieść poziom bezpieczeństwa i ograniczyć ryzyko, że stwarzająca zagrożenia usługa będzie działać w zaporze sieciowej.

Zaleca się również standaryzację mechanizmów uwierzytelniania. Bywa, że w urządzeniach sieciowych administratorzy korzystają z uwierzytelniania innego, niż standard w ich firmach. W przedsiębiorstwach mających zdalne oddziały dochodzi też do tego, że w centrali stosuje jeden mechanizm uwierzytelniania, a w oddziałach inny. Nie używając jednolitego uwierzytelnia, naraża się na ryzyko funkcjonowania kont użytkowników ze słabymi hasłami czy różnymi limitami blokady konta po nieudanych próbach logowania.

Zawsze trzeba rejestrować zdarzenia związane z bezpieczeństwem. Wprawdzie może to być kosztowne, ale koszty włamań czy braku możliwości śledzenia przebiegu ataku są znacznie wyższe. Nie przechowywanie plików logów z urządzeń bezpieczeństwa lub rejestrowanie zdarzeń na zbyt dużym poziomie ogólności to jedna z najgorszych rzeczy, jakie można zrobić, jeśli chodzi o bezpieczeństwo sieci. W takiej sytuacji bowiem nikt nie zostanie powiadomiony, gdy dojdzie do ataku, ale również nie będzie możliwości przeprowadzenia analizy powłamaniowej. Dbanie o rejestrowanie zdarzeń i ich przechowywanie przełoży się w przypadku ataku na znaczne oszczędności i umożliwi ustalenie, co zaszło w sieci.

Nie można zapominać o stosowaniu odpowiednich zabezpieczeń danych używanych w testach. Firmy z reguły stosują dobrą zasadę izolowania środowiska testowego od produkcyjnego. Natomiast często nie wymusza się oddzielenia systemów testowych od danych produkcyjnych. Osoby prowadzące testy uważają bowiem, że takie dane umożliwiają przeprowadzenie najtrafniejszych testów. Jeśli jednak umożliwi się systemom testowym zbieranie danych produkcyjnych, znacznie obniża się bezpieczeństwo danych. Tymczasem mogą to być bardzo wartościowe dane czy podlegające regulacjom prawnym. Jeśli więc dane produkcyjne trafiają do systemów testowych, należy te systemy odpowiednio zabezpieczyć.