Zapora systemowa stanowi jeden z podstawowych mechanizmów ochrony systemu operacyjnego przed nieautoryzowanym dostępem do usług sieciowych. Odpowiada za kontrolowanie ruchu przychodzącego oraz wychodzącego zgodnie z określonymi regułami bezpieczeństwa. Prawidłowo skonfigurowana zapora pozwala ograniczyć możliwość wykorzystania usług, które zostały przypadkowo uruchomione, błędnie skonfigurowane lub nie powinny być dostępne z określonych segmentów sieci.
W systemach Windows funkcję zapory realizuje przede wszystkim Windows Defender Firewall with Advanced Security. W środowiskach Linux za filtrowanie ruchu odpowiadają mechanizmy Netfilter, którymi można zarządzać między innymi za pomocą nftables oraz firewalld.
Celem kontroli jest sprawdzenie, czy zapora systemowa pozostaje aktywna, została prawidłowo skonfigurowana oraz czy jej reguły ograniczają komunikację sieciową do niezbędnego minimum. Audyt powinien również potwierdzić, że dostęp do usług administracyjnych i aplikacyjnych jest ograniczony do wymaganych sieci i adresów.
Konfiguracja zapory systemowej stanowi istotny element procesu hardeningu systemów Windows i Linux. Nawet jeśli infrastruktura organizacji jest chroniona przez centralne firewalle sieciowe, zabezpieczenia wdrożone bezpośrednio na serwerze lub stacji roboczej zapewniają dodatkową warstwę ochrony.
Znaczenie zapory systemowej w cyberbezpieczeństwie
System operacyjny może udostępniać wiele usług sieciowych. Służą one użytkownikom, aplikacjom, systemom monitorowania, mechanizmom zarządzania oraz innym serwerom działającym w infrastrukturze organizacji.
Każda usługa nasłuchująca na porcie sieciowym zwiększa powierzchnię ataku. W przypadku występowania podatności w usłudze lub jej nieprawidłowej konfiguracji osoba atakująca może próbować wykorzystać ją do uzyskania dostępu do systemu.
Zapora systemowa umożliwia ograniczenie dostępu do takich usług. Administrator może określić między innymi:
- dostępne porty,
- adresy IP, z których można nawiązywać połączenia,
- interfejsy sieciowe, za pośrednictwem których można uzyskać dostęp do usług,
- dozwolone protokoły,
- kierunek filtrowanego ruchu — przychodzącego lub wychodzącego,
- profile lub strefy, w których obowiązują określone reguły,
- programy lub usługi, dla których dopuszcza się komunikację.
Szczególne znaczenie ma ochrona usług administracyjnych. Protokoły takie jak RDP, SSH i WinRM oraz inne mechanizmy zarządzania serwerem powinny być dostępne wyłącznie z uprawnionych sieci i adresów IP, a nie z całej sieci bez uzasadnionej potrzeby ani bezpośrednio z Internetu.
Zapora systemowa nie zastępuje jednak centralnego firewalla sieciowego. Stanowi dodatkową warstwę ochrony, zgodną z zasadą defense in depth, która zakłada stosowanie wielu uzupełniających się mechanizmów zabezpieczeń.
Zakres kontroli audytowej
Kontrola obejmuje konfigurację zapory systemowej na serwerach oraz stacjach roboczych z systemami Windows i Linux.
W systemach Windows audyt obejmuje przede wszystkim mechanizm Windows Defender Firewall oraz jego konfigurację w ramach następujących profili sieciowych:
- Domain,
- Private,
- Public.
Analizie podlegają zarówno reguły dotyczące ruchu przychodzącego, jak i wychodzącego.
W systemach Linux kontrola obejmuje mechanizmy filtrowania pakietów oraz sposób zarządzania ich konfiguracją. W zależności od wykorzystywanej dystrybucji i przyjętej architektury analizie podlegają reguły nftables lub konfiguracja firewalld, który zarządza regułami filtrowania ruchu w oparciu o Netfilter.
Audyt obejmuje w szczególności:
- stan zapory systemowej,
- domyślną politykę filtrowania ruchu,
- reguły zezwalające na komunikację,
- reguły blokujące komunikację,
- otwarte porty sieciowe,
- dozwolone adresy źródłowe,
- profile sieciowe lub strefy zapory,
- konfigurację filtrowania ruchu przychodzącego,
- konfigurację filtrowania ruchu wychodzącego,
- wyjątki dodane przez aplikacje,
- reguły tymczasowe,
- reguły nieużywane lub zbędne,
- sposób zarządzania zmianami w konfiguracji zapory.
Zasada minimalizacji dostępu sieciowego
Jedną z podstawowych zasad bezpiecznej konfiguracji zapory jest ograniczenie dostępu sieciowego do niezbędnego minimum.
Jeżeli aplikacja wymaga komunikacji tylko z określonym serwerem, nie ma potrzeby zezwalania na komunikację z całą siecią.
Analogicznie, jeżeli usługa administracyjna powinna być dostępna wyłącznie z wydzielonej sieci administracyjnej, reguła zapory powinna ograniczać możliwość połączenia do tej sieci.
Przykładowo dostęp:
10.10.10.0/24 → TCP/22 → Allowjest bardziej restrykcyjny niż:
Any → TCP/22 → AllowJeszcze większe znaczenie ma ograniczenie dostępu do usług administracyjnych takich jak RDP, SSH czy WinRM.
Reguły typu Any/Any należy stosować wyłącznie w uzasadnionych przypadkach biznesowych lub technicznych.
Domyślna polityka zapory
Istotnym elementem audytu jest sprawdzenie zachowania zapory w sytuacji, gdy dla danego połączenia nie istnieje żadna reguła.
W przypadku ruchu przychodzącego preferowanym rozwiązaniem jest domyślne blokowanie połączeń i jawne zezwalanie wyłącznie na wymagany ruch.
W systemach Windows można sprawdzić konfigurację za pomocą PowerShell:
Get-NetFirewallProfile |
Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundActionAudytor powinien zwrócić szczególną uwagę na ustawienie:
DefaultInboundActionW środowisku Linux analogiczną kontrolę należy przeprowadzić poprzez analizę polityk łańcuchów nftables lub konfiguracji odpowiednich stref firewalld.
Domyślną politykę należy oceniać w kontekście całej konfiguracji. W niektórych środowiskach organizacja może świadomie przyjąć inną politykę dla określonego typu systemu. Takie odstępstwo wymaga udokumentowania i zgodności z przyjętym modelem bezpieczeństwa.
Co powinien sprawdzić audytor?
Podczas kontroli zapory systemowej audytor powinien odpowiedzieć na szereg pytań dotyczących konfiguracji ruchu sieciowego.
Czy zapora systemowa jest aktywna?
Czy wszystkie profile Windows mają odpowiednio skonfigurowaną zaporę?
Czy domyślnie blokuje się ruch przychodzący?
Czy istnieją reguły zezwalające na ruch z dowolnych adresów?
Czy każda reguła zezwalająca posiada uzasadnienie?
Czy otwarte porty odpowiadają rzeczywiście wykorzystywanym usługom?
Czy dostęp do RDP, SSH i innych usług administracyjnych ograniczono do wymaganych sieci?
Czy reguły ograniczają źródłowe adresy IP tam, gdzie jest to możliwe?
Czy występują nieużywane lub historyczne reguły?
Czy aplikacje mogą samodzielnie tworzyć wyjątki w zaporze?
Czy konfiguracja zapory podlega centralnemu zarządzaniu?
Czy rejestruje się zmiany konfiguracji?
Czy konfiguracja zapory jest zgodna z polityką bezpieczeństwa organizacji?
Czy przeprowadza się okresowe przeglądy konfiguracji zapory?
Czy system posiada dodatkowe mechanizmy ochrony, takie jak EDR lub XDR, monitorujące nietypową komunikację sieciową?
Metody prowadzenia kontroli
Audyt rozpoczyna się od ustalenia mechanizmu zapory wykorzystywanego przez badany system.
W przypadku Windows należy zweryfikować stan Windows Defender Firewall oraz konfigurację poszczególnych profili sieciowych.
Przykładowe polecenie:
Get-NetFirewallProfileNastępnie należy przeanalizować aktywne reguły:
Get-NetFirewallRule |
Where-Object Enabled -eq 'True'Szczególnej uwagi wymagają reguły zezwalające na ruch przychodzący:
Get-NetFirewallRule |
Where-Object {
$_.Enabled -eq 'True' -and
$_.Direction -eq 'Inbound' -and
$_.Action -eq 'Allow'
}Kolejnym etapem jest porównanie konfiguracji zapory z rzeczywistymi usługami nasłuchującymi na systemie.
Można wykorzystać:
Get-NetTCPConnection -State ListenPozwala to określić, jakie porty są aktualnie wykorzystywane przez procesy systemowe i aplikacyjne.
W systemach Linux należy rozpocząć od sprawdzenia aktywnego mechanizmu filtrowania.
Dla nftables pomocne będzie:
sudo nft list rulesetAudytor powinien przeanalizować przede wszystkim łańcuchy odpowiedzialne za ruch przychodzący i wychodzący oraz obowiązujące polityki.
W przypadku firewalld należy sprawdzić aktywne strefy:
sudo firewall-cmd --get-active-zones
oraz szczegóły konfiguracji:
sudo firewall-cmd --list-all-zones
Dodatkowo warto sprawdzić otwarte porty:
sudo firewall-cmd --zone=public --list-ports
oraz dozwolone usługi:
sudo firewall-cmd --zone=public --list-services
Konfigurację zapory należy następnie porównać z wynikami poleceń pokazujących usługi sieciowe, na przykład:
ss -lntup
Pozwala to ustalić, czy istnieją usługi nasłuchujące, które nie powinny być dostępne z określonych sieci.
Narzędzia wykorzystywane podczas kontroli
W systemach Windows podczas audytu zapory mogą być wykorzystywane między innymi:
- Windows Defender Firewall with Advanced Security,
- PowerShell,
Get-NetFirewallProfile,Get-NetFirewallRule,Get-NetFirewallPortFilter,Get-NetFirewallAddressFilter,Get-NetTCPConnection,- Windows Event Viewer,
- Group Policy Management,
- Microsoft Defender for Endpoint.
W systemach Linux wykorzystywane są między innymi:
nft,firewall-cmd,ss,ip,systemctl,journalctl,tcpdump,nmap,iptables– w środowiskach, w których nadal jest wykorzystywany,- narzędzia zarządzania konfiguracją.
W dużych środowiskach konfiguracja zapory może być również zarządzana centralnie za pomocą Group Policy, systemów zarządzania konfiguracją lub narzędzi automatyzujących wdrażanie konfiguracji.
Informacje dotyczące zmian i nietypowej komunikacji mogą być dodatkowo analizowane przez systemy klasy SIEM, EDR oraz XDR.
Typowe niezgodności wykrywane podczas audytu
Jednym z najczęściej spotykanych problemów jest wyłączona zapora systemowa. Może to być wynikiem celowego działania administratora, błędnej konfiguracji lub działania oprogramowania instalowanego na komputerze.
Kolejnym problemem są zbyt szerokie reguły zezwalające na ruch.
Przykładem może być reguła umożliwiająca dostęp do RDP:
Any → TCP/3389 → Allow
Jeżeli administracja powinna odbywać się wyłącznie z wydzielonej sieci, reguła taka znacząco zwiększa powierzchnię ataku.
Podobnym problemem jest pozostawienie otwartych portów po odinstalowaniu aplikacji. Reguła zapory może nadal istnieć, mimo że usługa, dla której została utworzona, nie jest już wykorzystywana.
Audytorzy mogą również spotkać reguły utworzone przez aplikacje podczas instalacji. Oprogramowanie może automatycznie dodać wyjątek umożliwiający komunikację przychodzącą. Jeżeli administrator nie zweryfikuje takiej zmiany, może dojść do niezamierzonego zwiększenia powierzchni ataku.
W systemach Linux dodatkowym problemem może być nieprawidłowe przypisanie interfejsu do strefy firewalld albo pozostawienie zbyt wielu usług dostępnych w strefie publicznej.
Ocena ryzyka
Nieprawidłowa konfiguracja zapory systemowej może prowadzić do nieautoryzowanego dostępu do usług działających na systemie operacyjnym.
Poziom ryzyka zależy przede wszystkim od rodzaju udostępnionej usługi, jej podatności, zakresu dostępności oraz poziomu uprawnień procesu.
Najwyższe ryzyko występuje w przypadku usług administracyjnych dostępnych z niezaufanych sieci lub bezpośrednio z Internetu. Dotyczy to między innymi RDP, SSH, WinRM oraz innych interfejsów zarządzania.
Szczególnie niebezpieczne są również reguły typu Any/Any oraz konfiguracje umożliwiające dostęp do wielu usług z nieograniczonego zakresu adresów.
Skutkiem wykorzystania takiej konfiguracji może być uzyskanie nieautoryzowanego dostępu, przejęcie konta, eskalacja uprawnień, instalacja złośliwego oprogramowania lub dalsze przemieszczanie się osoby atakującej w infrastrukturze.
Rekomendowane działania naprawcze
Organizacja powinna zapewnić, aby zapora systemowa była aktywna na wszystkich systemach, dla których stanowi wymagany element ochrony.
Reguły powinny być projektowane zgodnie z zasadą najmniejszych uprawnień. Należy zezwalać wyłącznie na wymagany ruch, a dostęp do usług powinien być ograniczany do niezbędnych adresów, sieci, interfejsów i portów.
Szczególną uwagę należy poświęcić usługom administracyjnym. RDP, SSH, WinRM i podobne mechanizmy powinny być dostępne wyłącznie z odpowiednio zabezpieczonych sieci administracyjnych lub za pośrednictwem kontrolowanych mechanizmów dostępu.
Niepotrzebne reguły należy usuwać po potwierdzeniu, że nie są już wymagane. Reguły tymczasowe powinny posiadać określony termin obowiązywania lub zostać usunięte po zakończeniu prac.
Zaleca się również prowadzenie dokumentacji reguł zawierającej co najmniej:
- przeznaczenie reguły,
- właściciela,
- źródło ruchu,
- cel,
- port i protokół,
- uzasadnienie biznesowe,
- datę utworzenia,
- informacje dotyczące zmiany.
W większych środowiskach warto centralizować zarządzanie konfiguracją zapór. W systemach Windows można wykorzystać między innymi Group Policy, natomiast w systemach Linux rozwiązania automatyzujące konfigurację infrastruktury.
Konfiguracja powinna być również regularnie porównywana z rzeczywistym stanem usług i wymaganiami architektury sieciowej.
Powiązanie z normami i dobrymi praktykami
Kontrola konfiguracji zapory systemowej wspiera realizację wymagań związanych z bezpieczną konfiguracją systemów, kontrolą dostępu oraz ochroną komunikacji sieciowej.
Jest zgodna z podejściem stosowanym w ramach ISO/IEC 27001:2022, NIST Cybersecurity Framework 2.0 oraz CIS Controls v8.
Istotne znaczenie mają również zalecenia CIS Benchmarks dotyczące bezpiecznej konfiguracji systemów Windows i Linux.
Prawidłowa konfiguracja zapory wpisuje się także w koncepcję defense in depth, w której bezpieczeństwo systemu nie jest uzależnione od pojedynczego mechanizmu ochronnego.
Podsumowanie
Zapora systemowa jest jednym z podstawowych mechanizmów ograniczających powierzchnię ataku systemów Windows i Linux. Jej prawidłowa konfiguracja pozwala ograniczyć dostęp do usług sieciowych oraz zmniejszyć prawdopodobieństwo wykorzystania niepotrzebnie udostępnionych portów.
Skuteczny audyt nie powinien ograniczać się do sprawdzenia, czy zapora jest włączona. Należy przeanalizować również wszystkie reguły zezwalające, politykę domyślną, profile i strefy, otwarte porty oraz zakres adresów, z których możliwe jest nawiązanie połączenia.
Szczególnie istotne jest stosowanie zasady najmniejszych uprawnień. Usługi powinny być dostępne wyłącznie z tych sieci i adresów, które rzeczywiście wymagają komunikacji.
Regularny przegląd konfiguracji Windows Defender Firewall, nftables oraz firewalld, połączony z kontrolą rzeczywiście działających usług, pozwala ograniczyć powierzchnię ataku i stanowi ważny element hardeningu systemów operacyjnych.
Kolejnym etapem audytu systemów operacyjnych będzie kontrola uprawnień do plików i katalogów, której celem będzie ocena, czy użytkownicy oraz procesy posiadają wyłącznie uprawnienia niezbędne do realizacji swoich zadań.
Dziękuję Ci, za poświęcony czas na przeczytanie tego artykułu. Jeśli był on dla Ciebie przydatny, to gorąco zachęcam Cię do zapisania się na mój newsletter, jeżeli jeszcze Cię tam nie ma. Proszę Cię także o “polubienie” mojego bloga na Facebooku oraz kanału na YouTube – pomoże mi to dotrzeć do nowych odbiorców. Raz w tygodniu (niedziela punkt 17.00) otrzymasz powiadomienia o nowych artykułach / projektach zanim staną się publiczne. Możesz również pozostawić całkowicie anonimowy pomysł na wpis/nagranie.
Link do formularza tutaj: https://beitadmin.pl/pomysly
Pozostaw również komentarz lub napisz do mnie wiadomość odpisuję na każdą, jeżeli Masz jakieś pytania:).
