10 błędów w konfiguracji firewalli, których należy unikać

Źle skonfigurowany firewall to prawie tak, jakby go wcale nie było. Zebraliśmy 10 błędnych ustawień zapory sieciowej, które umożliwią łatwe włamanie się do firmowej sieci, choć może wydawać się, że jest ona dobrze zabezpieczona.

Firewalle są głównym środkiem obrony przed różnorodnymi typami ataków sieciowych. Jednak nawet po latach badań i doświadczeń wiele organizacji wciąż popełnia błędy konfiguracyjne, które narażają ich sieci na kradzież danych i inne zagrożenia. Prezentujemy więc przegląd dziesięciu ustawień i praktyk, których za wszelką cenę należy unikać w przypadku firewalli.

Mając na uwadze opisane problemy z konfiguracją zapór sieciowych, firmy mogą szybko podnieść poziom bezpieczeństwa i radykalnie zmniejszyć ryzyko udanego włamania. Osoby odpowiedzialne za bezpieczeństwo IT w firmach znaczną część czasu spędzają, zajmując się ochroną przed lukami i podatnościami w aplikacjach. Tymczasem z badań Gartnera wynika, że aż 95% włamań dochodzi do skutku dzięki błędom w konfiguracji zapór sieciowych.

Zobacz również:

1. Niedostosowanie konfiguracji firewalli do zabezpieczeń działających w chmurze

Firewalle są obecnie jednym z wielu elementów rozproszonego systemu bezpieczeństwa. Organizacje łączące centra danych z poszczególnymi oddziałami i pracownikami mobilnymi wymagają ciągłego zdalnego dostępu. Tymczasem aplikacje i dane są szybko przenoszone na platformy IaaS i SaaS. Większość firm już pracuje lub niebawem będzie pracować, wykorzystując środowisko chmury hybrydowej. Ochrona takiej infrastruktury wymaga czegoś więcej niż zwykłych firewalli. Dzisiejsze rozwijające się i rozproszone środowiska wymagają wielowarstwowego podejścia do ochrony sieci, w którym firewalle współpracują z resztą systemu bezpieczeństwa.

2. Błędne stosowanie reguł przekierowania portów dla zdalnego dostępu

Stosowanie reguł przekierowania portów w celu uzyskania zdalnego dostępu do komputera wewnątrz sieci LAN bez uprzedniego ograniczenia źródłowych adresów IP nigdy nie jest dobrym pomysłem. Jest to wygodny sposób na skonfigurowanie zdalnego dostępu, ale znacznie zwiększa ryzyko naruszenia bezpieczeństwa. Udostępnione w ten sposób urządzenia może zostać łatwo zhakowane przez nieupoważnione osoby wykorzystujące tę dziurę w zabezpieczeniach. W dalszej kolejności to urządzenie może zostać wykorzystane przez hakera do ataku na inne urządzenia lub zasoby, do których zaufane urządzenie ma dostęp.

3. Nierejestrowanie próśb o udostępnienie zasobów

Aby zredukować do minimum przerwy w świadczeniu usług, wiele firm na początku uruchamia zapory sieciowe bez szczegółowego filtrowania ruchu. Następnie, gdy zajdzie taka potrzeba, krok po kroku zaostrzają politykę dostępu. To zły pomysł. Nie określając od samego początku potrzeb dostępu, firmy narażają się na złośliwe ataki przez dłuższy czas. Zamiast zaczynać od polityki otwartego dostępu, która powoli jest ograniczony, zaleca się działanie odwrotne. Chodzi o dokonanie inwentaryzacji najważniejszych aplikacji i usług, których firma potrzebuje, aby niezawodnie obsługiwać codzienne operacje, a następnie dostosowanie konfiguracji firewalli, która uwzględni zebrane wymagania (źródłowy adresy IP, docelowy adresy IP czy numery portów).

4. Nieskonfigurowanie firewalli do filtrowania ruchu wychodzącego

Większość administratorów ma przynajmniej podstawową wiedzę na temat tego, w jaki sposób firewalle poprawiają bezpieczeństwo poprzez filtrowanie danych wejściowych. Takie podejście uniemożliwia przychodzącym połączeniom internetowym docieranie do wewnętrznych usług sieciowych, do których nieupoważnieni użytkownicy zewnętrzni nigdy nie powinni mieć dostępu. Jednak stosunkowo niewielu administratorów stara się dba także o filtrowanie ruchu wychodzącego, które ogranicza rodzaje połączeń sieciowych nawiązywanych przez użytkowników wewnętrznych. Większość konfiguracji firewalli posiada ogólne zasady wychodzące, które zasadniczo pozwalają użytkownikom wewnętrznym robić w Internecie wszystko, co chcą.

Firmy które nie korzystają z filtrowania na wyjściu z sieci, pozostawiają otwartą furtkę dla hakerów, co znacznie obniża ogólny poziom bezpieczeństwa.

5. Brak dokumentacji

Zapory są często konfigurowane zgodnie z otwartą polityką zezwalającą na ruch z dowolnego źródła do dowolnego miejsca docelowego. Dzieje się tak, ponieważ zespoły IT na początku nie znają szczegółowych wymagań, pozostawiając ich zebranie na później. W praktyce z powodu presji czasu lub po prostu nie traktowania tego jako priorytetu, nigdy nie przystępują do tego zadania, a w konsekwencji nie definiują reguł firewalli, pozostawiając sieć w stanie permanentnego narażenia na ataki.

To pokazuje, że potrzebna jest odpowiednia dokumentacja - najlepiej odwzorowanie przepływów wymaganych przez aplikacje przed przyznaniem dostępu. Firmy powinny postępować zgodnie z zasadą przydzielania minimalnych uprawnień - to znaczy zapewniać minimalny poziom uprawnień, żeby użytkownik lub usługa mogły normalnie funkcjonować. Ograniczając się w ten sposób potencjalne szkody spowodowane atakami. Dobrym pomysłem jest także regularne przeglądanie konfiguracji firewalla w celu sprawdzenia trendów użytkowania aplikacji i zidentyfikowania nowych aplikacji używanych w sieci oraz tego, jakiej łączności faktycznie potrzebują.

6. Zbędne usługi działające w zaporze sieciowej

Kolejnym błędem są usługi, które niepotrzebnie pozostają uruchomione na zaporze. Dwoma głównymi winowajcami są tutaj routing dynamiczny, który zwykle nie powinien być włączany na urządzeniach bezpieczeństwa oraz zbędne serwery DHCP w sieci dystrybuujące adresy IP, co może potencjalnie prowadzić do problemów z dostępnością w wyniku konfliktów adresów IP. Zaskakuje również liczba urządzeń, które nadal używają niezaszyfrowanych protokołów, takich jak Telnet, mimo że ten protokół ma ponad trzydzieści lat!

Rozwiązaniem jest uszczelnianie konfiguracji urządzeń przed wprowadzeniem ich do środowisk produkcyjnych. Jest to problem, z którym zmaga się wiele firm. Konfigurując urządzenia w oparciu o funkcję, którą faktycznie mają spełniać, i przestrzegając zasady najmniejszego możliwego dostępu - przed ich wdrożeniem - możliwa jest poprawa bezpieczeństwa i eliminacja zagrożenia polegającego na przypadkowym pozostawieniu ryzykownej usługi działającej w zaporze sieciowej.

7. Niestandardowe mechanizmy uwierzytelniania

Firmy często korzystają z routerów, które nie są zgodne z korporacyjnym standardem dotyczącym uwierzytelniania. Przykładem może być duży bank, w którym wszystkie urządzenia w głównych centrach danych były kontrolowane przez centralny mechanizm uwierzytelniania, ale w jego zdalnym biurze nie korzystały z tego samego mechanizmu. Nie egzekwując korporacyjnych standardów uwierzytelniania, personel w oddziale zdalnym mógł uzyskiwać dostęp do kont lokalnych przy użyciu słabych haseł i miał inne limity błędów logowania przed zablokowaniem konta.

Taki scenariusz zmniejsza bezpieczeństwo i tworzy więcej możliwości dla atakujących, ponieważ łatwiej jest im uzyskać dostęp do sieci korporacyjnej za pośrednictwem zdalnego biura. Organizacje powinny zatem zapewnić, aby wszystkie zdalne biura stosowały ten sam centralny mechanizm uwierzytelniania, co reszta firmy.

8. Testowanie systemów przy użyciu danych produkcyjnych

Większość organizacji ma wytyczne dotyczące zarządzania, które stwierdzają, że systemy testowe nie powinny łączyć się z systemami produkcyjnymi i gromadzić danych produkcyjnych, ale w praktyce często nie jest to egzekwowane. W rzeczywistości osoby pracujące przy testowaniu postrzegają dane produkcyjne jako najlepszy, najdokładniejszy sposób testowania. Trzeba jednak pamiętać, że zezwalając systemom testowym na zbieranie danych z produkcji często przenosi się bardzo wrażliwe dane do środowiska o znacznie niższym poziomie bezpieczeństwa. Tak więc korzystając z danych produkcyjnych w środowisku testowym należy mieć pewność, że korzysta się z odpowiednich środków kontroli bezpieczeństwa wymaganych przez klasyfikację danych.

9. Brak logowania zdarzeń

Ostatnim problemem jest to, że firmy nie analizują rejestru zdarzeń (logów) ze swoich urządzeń zabezpieczających lub nie robią tego z wystarczającą szczegółowością. Jest to jedna z najgorszych rzeczy, które można zrobić pod względem bezpieczeństwa sieci, co skutkować może brakiem ostrzeżenia w przypadku ataku. Systemy do rejestrowania są drogie i trudne do wdrożenia, analizy oraz utrzymania. Jednak koszty ataku do sieci, o którym nie zabezpieczenia nie powiadomią i dadzą możliwości śledzenia, są z pewnością znacznie wyższe.

10. Dobrze skonfigurowany firewall nie zapewni pełnego bezpieczeństwa

W czasach, gdy atakujący stają się coraz bardziej sprytni, ochrona brzegu sieci wymaga coraz bardziej złożonych zabezpieczeń. Hakerzy mogą teraz atakować korporacyjne sieci Wi-Fi, routery, przeprowadzać kampanie phishingowe, a nawet konstruować żądania API, aby przekazywać ataki skryptowe do backendu. Po uzyskaniu dostępu do sieci osoby atakujące mogą eskalować swoje działania i uzyskać dostęp do wewnętrznych systemów, które są chronione tylko poprzez zabezpieczenia na brzegu sieci. Dlatego ważne jest przyjęcie podejścia zerowego zaufania, ponieważ wszystko może stać się celem ataku: aplikacje mobilne, urządzenia konsumenckie i pracownicze oraz sieci wewnętrzne.

Należy projektować warstwowe zabezpieczenie sieci, tak żeby firewall był kluczową, ale nie jedyną ochroną. Wskazane jest zablokowanie każdej warstwy i umożliwienie komunikacji na poziomie zapewniającym tylko wymaganą komunikację.

Bezpieczeństwo interfejsów API, aplikacji, projektów integracyjnych i systemów musi zaczynać się od fazy projektowania. Na każdym etapie: projektowania, rozwoju, testowania, wdrażania – mechanizmy bezpieczeństwa muszą być uruchamiane automatycznie, aby mieć pewność, że każdy element lub system jest bezpieczny, nawet jeśli ewoluuje i zmienia się.


TOP 200