Technologie Firewall

Zapory sieciowe i kontrola ruchu

Sieci firmowe i domowe wymieniają ruch z innymi sieciami, które mogą mieć odmienny poziom zaufania. Zapora sieciowa (firewall) jest urządzeniem lub programem, który stosuje politykę przepływu ruchu między takimi strefami. Reguły mogą odnosić się do adresów, portów, protokołów, stanu połączenia oraz danych rozpoznawanych przez określone funkcje inspekcji. W dokumentacji zapory trzeba wskazać kierunek, właściciela reguły, uzasadnienie, zakres i sposób testowania. Należy też opisać obsługę logów, błędów urządzenia i zmian konfiguracji.

Zapora ocenia ruch przychodzący i wychodzący zgodnie z kolejnością reguł oraz działaniem przyjętej polityki domyślnej. Może zezwolić na połączenie, odrzucić je, zarejestrować zdarzenie albo przekazać ruch do dalszej inspekcji. Skuteczność zależy od zakresu obserwowanego ruchu, precyzji reguł, aktualizacji oraz monitorowania decyzji. Polityka powinna mieć właściciela, uzasadnienie i okres przeglądu. Reguły tymczasowe wymagają terminu wygaśnięcia, aby nie pozostały aktywne po zakończeniu zadania. Dokumentacja zmian powinna łączyć regułę z wymaganiem usługi i wynikiem testu. Przegląd powinien obejmować reguły przesłonięte, nieużywane wyjątki, oczekiwany ruch powrotny, objętość logów i wpływ translacji adresów. Należy sprawdzić, czy logi nie ujawniają wrażliwego ładunku oraz czy odrzucony ruch pozostaje dostępny do analizy incydentu.

Zapory filtrujące pakiety

Filtr pakietów podejmuje decyzję na podstawie pól nagłówka. Nie analizuje pełnej treści aplikacji, dlatego może działać szybko i przewidywalnie przy prostych politykach.

Ten typ zapory analizuje nagłówki każdego pakietu. Decyzja o przepuszczeniu lub odrzuceniu opiera się na informacjach dostępnych w nagłówku, które mogą obejmować adresy, porty, protokół i flagi. Filtr może także uwzględniać interfejs wejściowy i wyjściowy oraz znacznik VLAN, zależnie od implementacji:

• Źródłowy adres IP: Adres nadawcy widoczny w pakiecie.
• Docelowy adres IP: Adres odbiorcy wskazany w pakiecie.
• Port źródłowy: Port użyty przez aplikację nadawcy, na przykład $49152$ na komputerze klienckim.
• Port docelowy: Port usługi odbiorcy, na przykład $443$ dla HTTPS.
• Protokół: Protokół transportowy lub sieciowy, na przykład TCP dla połączenia WWW albo UDP dla strumienia multimedialnego.

Zapora porównuje te informacje z regułami Listy Kontroli Dostępu (ACL). Przykładowa lista ACL może wyglądać tak:

W tym przykładzie reguła 1 zezwala dowolnemu źródłu na połączenie z serwerem HTTP pod adresem $192.168.1.10$ na porcie $80$. Reguła 2 jawnie blokuje Telnet na porcie 23. Reguła 3 odrzuca ruch, który nie pasuje do wcześniejszej reguły zezwalającej. W rzeczywistej sieci zakres źródeł oraz usługi powinny wynikać z wymaganej funkcji serwera. Kolejność reguł ma znaczenie, ponieważ pierwszy pasujący wpis może zakończyć ocenę. Każda reguła dopuszczająca powinna mieć ograniczony zakres adresów i portów oraz rejestrować decyzję odpowiednią do potrzeb audytu.

To podejście jest bezstanowe. Każdy pakiet jest oceniany niezależnie, bez pamięci o wcześniejszych pakietach tego samego przepływu. Reguły nie rozpoznają, czy pakiet należy do rozpoczętego połączenia, dlatego wymagają osobnego uwzględnienia ruchu powrotnego. Filtrowanie źródłowego adresu IP nie usuwa problemu podszywania się pod adres nadawcy, a rozbudowana polityka może stać się trudna do sprawdzenia.

Inspekcja stanowa

Zapora z inspekcją stanową utrzymuje informacje o przepływach przechodzących przez urządzenie. Ocenia nagłówki oraz kontekst połączenia, więc może odróżnić odpowiedź należącą do wcześniej zaakceptowanego przepływu od nowego ruchu przychodzącego. Dla TCP uwzględnia przejścia stanów i flagi, a dla UDP stosuje zwykle czas wygaśnięcia oraz parametry przepływu.

Podstawą jest tablica stanów. Po rozpoczęciu połączenia zapora zapisuje między innymi źródłowy i docelowy adres IP, porty, protokół, flagi oraz czas wygaśnięcia wpisu. Konkretne pola zależą od implementacji i protokołu.

Gdy wraca pakiet odpowiedzi, zapora porównuje jego parametry z wpisem w tablicy oraz nadal stosuje politykę bezpieczeństwa. Pakiet zgodny z aktywnym stanem może zostać przepuszczony. Ruch, który nie pasuje do istniejącego wpisu ani reguły dopuszczającej, jest odrzucany lub rejestrowany zgodnie z konfiguracją.

Inspekcja stanowa upraszcza obsługę typowych połączeń wychodzących i ogranicza nieoczekiwany ruch przychodzący. Nie zastępuje reguł dopuszczających, rejestrowania ani kontroli aplikacji. Działa głównie na warstwie sieciowej i transportowej, więc rozpoznaje przepływ oraz protokół, lecz zwykle nie interpretuje pełnej logiki aplikacji. Tablica stanów zużywa pamięć, dlatego wymaga limitów, ochrony przed zalewaniem połączeniami i obserwacji wpisów odrzuconych przez politykę. Aktualizacja reguł powinna być sprawdzona na ruchu reprezentatywnym i objęta planem wycofania. Administrator powinien sprawdzić limity czasu dla długich sesji, trasy asymetryczne, przełączanie awaryjne oraz synchronizację stanu między urządzeniami nadmiarowymi.

Zapory proxy na poziomie aplikacji

Zapora proxy działa na poziomie aplikacji i analizuje komunikaty obsługiwanego protokołu. Może rozumieć żądania HTTP lub komendy FTP, lecz zakres analizy zależy od dostępnego modułu oraz od szyfrowania ruchu.

Zapora proxy pośredniczy w ruchu i kończy połączenie klienta. Następnie, po sprawdzeniu żądania zgodnie z polityką, tworzy osobne połączenie z serwerem zewnętrznym:

1. Klient łączy się z modułem proxy zapory.
2. Moduł analizuje żądanie i sprawdza je względem polityki. Po akceptacji inicjuje oddzielne połączenie z serwerem zewnętrznym w imieniu klienta.

Pośrednictwo pozwala analizować polecenia i pola protokołu. Przykładowo moduł FTP może zezwolić na pobieranie plików, a zablokować przesyłanie lub usuwanie. Moduł HTTP może filtrować żądania według hosta, ścieżki albo metody. Przy HTTPS pełna treść wymaga jawnie skonfigurowanej inspekcji TLS i odpowiedniej polityki zaufania.

Proxy zwiększa koszt obsługi, ponieważ utrzymuje dwa połączenia i przetwarza komunikaty. Potrzebuje też osobnego wsparcia dla każdego protokołu, na przykład HTTP, FTP albo SMTP. Wydajność, możliwość skalowania i zakres kontroli zależą od implementacji oraz liczby analizowanych połączeń. Trzeba uwzględnić obsługę uwierzytelnienia, błędów, limitów czasu i dużych plików. Brak modułu dla danego protokołu może wymagać innego mechanizmu kontroli. Dokumentacja powinna rozróżniać ruch jawny od szyfrowanego oraz wskazywać, gdzie kończy się połączenie klienta.

Zapory nowej generacji (NGFW)

Zapora nowej generacji (NGFW) łączy funkcje zależne od konkretnego produktu. Zwykle zachowuje filtrację stanową, a dodatkowo może rozpoznawać aplikacje, analizować treść i współpracować z systemem IPS.

Typowe funkcje NGFW to:

• Funkcje podstawowe: NGFW wykorzystuje filtrowanie adresów, portów i protokołów oraz inspekcję stanową jako podstawę polityki.
• Rozpoznawanie i kontrola aplikacji: NGFW może klasyfikować ruch według aplikacji, portu i protokołu. Głęboka inspekcja pakietów (DPI) może wykorzystywać sygnatury i analizę protokołu. Przykładowa reguła może zezwalać na zatwierdzoną aplikację współpracy, a ograniczać udostępnianie plików. Szyfrowanie, zmiany protokołu i błędna klasyfikacja wpływają na skuteczność tej funkcji.
• Zintegrowany system zapobiegania włamaniom (IPS): Część NGFW zawiera moduł IPS, który porównuje ruch z regułami i sygnaturami oraz może zablokować dopasowanie. Sposób działania zależy od konfiguracji trybu inline, wyjątków i polityki obsługi błędów.
• Integracja z tożsamością użytkownika: NGFW może pobierać informacje z usług katalogowych, takich jak Microsoft Active Directory, i wiązać reguły z użytkownikiem albo grupą. Polityka może na przykład dopuścić wybraną usługę grupie administracyjnej, przy ograniczeniu dostępu pozostałych grup.
• Źródła informacji o zagrożeniach: Produkt może korzystać z kanałów informacji o zagrożeniach zawierających adresy, domeny, sygnatury albo reguły. Administrator powinien ocenić źródło, czas obowiązywania i wpływ wpisu, ponieważ aktualizacja wymaga weryfikacji oraz dopasowania do lokalnej polityki.

Zabezpieczanie serwerów publicznych: DMZ

Serwery WWW, pocztowe i DNS mogą być dostępne z Internetu, lecz ich położenie w tej samej strefie co systemy wewnętrzne zwiększa skutki ewentualnego przejęcia. Segment DMZ ogranicza połączenia między usługami publicznymi a siecią zaufaną.

Strefa zdemilitaryzowana (DMZ) jest fizycznym lub logicznym segmentem pomiędzy Internetem i siecią wewnętrzną. Izolacja ma sens tylko wtedy, gdy zapora oraz systemy w segmentach egzekwują precyzyjne reguły.

DMZ można wdrożyć przy użyciu zapory z co najmniej trzema interfejsami albo równoważnych stref logicznych. Reguły powinny jasno określać dozwolone kierunki i usługi. Powinny obejmować także administrację, monitorowanie, rozwiązywanie nazw i aktualizacje. Dostęp administracyjny powinien korzystać z ograniczonej ścieżki i odrębnych poświadczeń. Usługi publiczne wymagają poprawek, monitorowania i oddzielenia od interfejsów zarządzania:

• Ruch z Internetu do DMZ dopuszcza się tylko dla określonych usług, na przykład port $443$ serwera WWW.
• Ruch z Internetu do wewnętrznej sieci LAN powinien być domyślnie odrzucony, z wyjątkami wynikającymi z polityki. Wyjątki wymagają rejestrowania i okresowego przeglądu.
• Ruch z DMZ do Internetu wymaga ograniczenia do potrzebnych aktualizacji i usług oraz powinien być rejestrowany.
• Ruch z DMZ do wewnętrznej sieci LAN powinien być zablokowany albo ściśle ograniczony. W razie przejęcia serwera zmniejsza to możliwość dalszego ruchu. Dozwolone wyjątki powinny wskazywać konkretną usługę i kierunek.
• Ruch z wewnętrznej sieci LAN do DMZ dopuszcza się zgodnie z potrzebami użytkowników i administratorów.
• Ruch z wewnętrznej sieci LAN do Internetu powinien podlegać regułom wyjściowym, rejestrowaniu i ewentualnemu filtrowaniu.