Pentest sieci wewnętrznej i test segmentacji: metodologia

Pentest sieci wewnętrznej i test segmentacji mają sprawdzić, czy przejęcie jednego urządzenia naprawdę zostaje ograniczone do jego strefy. Sam diagram z VLAN-ami nie jest dowodem. Potrzebna jest walidacja rzeczywistych ścieżek: routingu, reguł zapór, dostępu administracyjnego, usług katalogowych, DNS, proxy, IPv6, sieci bezprzewodowej, systemów backupu i tożsamości używanych między segmentami.

Najbardziej wartościowy wynik nie brzmi „port był otwarty”, lecz: z jakiej strefy, dla jakiej tożsamości, do jakiego zasobu i procesu biznesowego prowadzi osiągalna ścieżka oraz która kontrola miała ją zatrzymać. Bezpieczny pentest potwierdza to nieszkodliwymi połączeniami i uzgodnionymi kontami testowymi. Nie wymaga zakłócania produkcji, łamania haseł na dużą skalę ani uruchamiania destrukcyjnych exploitów.

Co dokładnie powinien potwierdzić test segmentacji

Segmentacja działa wtedy, gdy wymusza najmniejszy potrzebny przepływ niezależnie od tego, czy urządzenie źródłowe jest poprawnie skonfigurowane. Test powinien zweryfikować co najmniej pięć właściwości:

izolację poziomą — stacja użytkownika nie łączy się swobodnie z innymi stacjami, drukarkami, IoT lub systemami OT;
izolację pionową — zwykły segment nie osiąga sieci zarządzającej, hypervisorów, backupu, systemów bezpieczeństwa i kontrolerów domeny poza udokumentowanymi usługami;
kontrolę kierunku — odpowiedź na dozwolone połączenie nie tworzy ogólnej ścieżki inicjowanej w przeciwną stronę;
kontrolę tożsamości i urządzenia — dostęp nie opiera się wyłącznie na adresie IP, jeśli ryzyko wymaga silniejszego kontekstu;
spójność kanałów alternatywnych — IPv6, VPN, Wi-Fi, chmura, sieć zapasowa, proxy i tunele administracyjne podlegają tym samym założeniom.

NIST SP 800-207 podkreśla, że lokalizacja sieciowa nie powinna sama tworzyć zaufania. Segmentacja pozostaje ważna, ale jest skuteczniejsza, gdy współpracuje z zasadami Zero Trust: ciągłą oceną tożsamości, urządzenia, celu i ryzyka sesji.

Model techniczny: strefa, przepływ, tożsamość, skutek

Przed testem trzeba zbudować model, który da się porównać z rzeczywistością. Każdy dozwolony przepływ powinien mieć właściciela i zapis:

Pole	Przykład znaczenia
Źródło	strefa użytkowników, serwery aplikacyjne, VPN dostawcy
Cel	konkretna usługa, VIP, host lub grupa zasobów
Protokół	TCP/UDP/ICMP, port, aplikacja i wersja TLS
Kierunek	kto inicjuje połączenie i jaki ruch zwrotny jest stanowy
Tożsamość	użytkownik, konto usługi, certyfikat, urządzenie lub workload
Cel biznesowy	dlaczego przepływ istnieje i kto go zatwierdził
Kontrola	firewall, ACL, microsegmentation, host firewall, proxy, NAC
Logowanie	gdzie powstaje zdarzenie i jak długo jest przechowywane
Krytyczność	skutek naruszenia poufności, integralności lub dostępności

Tak powstaje macierz przepływów, a z niej graf osiągalności. Pentest porównuje trzy stany: przepływy zaprojektowane, skonfigurowane i faktycznie możliwe. Rozbieżność między nimi jest często ważniejsza niż pojedyncza otwarta usługa.

Warstwy, które trzeba testować osobno

Warstwa 2: domeny rozgłoszeniowe i kontrola dostępu

VLAN separuje domeny rozgłoszeniowe, ale nie jest kompletną kontrolą bezpieczeństwa. Trzeba sprawdzić konfigurację portów access i trunk, nieużywane porty, native VLAN, sieci zarządzające przełączników, mechanizmy 802.1X/NAC oraz zachowanie urządzeń nieobsługujących uwierzytelnienia. Test nie powinien wykonywać agresywnych ataków destabilizujących STP, DHCP lub tablice CAM bez osobnego okna laboratoryjnego.

Bezpieczna walidacja polega na podłączeniu autoryzowanego urządzenia testowego do reprezentatywnego portu i obserwacji przydzielonej strefy, polityki NAC oraz dostępnych tras. Warto zweryfikować reakcję na nieznane urządzenie i na zmianę profilu, ale bez podszywania się pod realnego pracownika.

Warstwa 3 i 4: routing, ACL i firewalle

Tutaj mierzymy rzeczywistą osiągalność protokołów między strefami. Skan powinien mieć kontrolowaną szybkość, uzgodnione zakresy i listę usług wrażliwych na liczbę połączeń. Wynik musi rozróżniać open, closed, filtered, odrzucenie aktywne i timeout. Nie wolno automatycznie uznawać timeoutu za skuteczną blokadę — przyczyną może być routing asymetryczny, przeciążenie albo host firewall.

NIST SP 800-41 Rev. 1 opisuje politykę zapory jako implementację reguł wynikających z ryzyka i potrzeb organizacji. Test powinien wykryć reguły any-any, nadmierne zakresy źródłowe, całe podsieci zamiast nazwanych usług, tymczasowe wyjątki bez daty wygaśnięcia i ścieżki omijające centralny punkt kontroli.

Warstwa 7: proxy, DNS i bramy aplikacyjne

Otwarcie tylko portu 443 nie oznacza minimalnego dostępu. Jeżeli proxy pozwala połączyć się z dowolną nazwą, rozwiązywać wewnętrzne rekordy albo tunelować ruch, ścieżka może być szersza niż wskazuje firewall. Testujemy dozwolone hosty, metody, SNI, certyfikaty, politykę DNS, prywatne strefy i kontrolę egress. Dla ruchu administracyjnego sprawdzamy bastiony, PAM i rozdzielenie sesji od bezpośredniego routingu.

IPv6 i ścieżki nieudokumentowane

Środowisko może korzystać z IPv6 mimo projektu opartego na IPv4. Link-local, router advertisements, DHCPv6 i automatyczna konfiguracja tworzą odrębną powierzchnię. Pentest powinien ustalić, czy IPv6 jest zarządzane i filtrowane, czy jedynie „nieużywane”. Analogicznie oceniamy dodatkowe interfejsy hypervisorów, sieci storage, backup, klastry, tunele chmurowe i zdalne narzędzia wsparcia.

Active Directory jako część testu segmentacji

W sieci domenowej większość stacji musi osiągać DNS, Kerberos, LDAP, SMB lub inne usługi kontrolerów domeny. To uzasadnione przepływy, ale zwiększają wartość segmentacji administracyjnej. Test powinien ocenić, czy zwykła stacja może dotrzeć do interfejsów zarządzających, systemów tier 0, hostów administratorów, serwerów certyfikatów, synchronizacji tożsamości i backupu AD.

Sama blokada portu nie usuwa ryzyka, jeżeli uprzywilejowane poświadczenia są używane na niskozaufanej stacji. Dlatego wyniki sieciowe trzeba zestawić z bezpieczeństwem Active Directory, modelem tieringu oraz PAM dla dostępu uprzywilejowanego.

Bezpieczny test korzysta z kont o jasno określonych rolach i nie przeprowadza masowego password sprayingu. Można potwierdzić, że określona usługa jest osiągalna oraz że konto testowe nie powinno się do niej logować, bez pozyskiwania cudzych danych uwierzytelniających.

Metodologia pentestu według ryzyka

NIST SP 800-115 porządkuje testy techniczne w planowanie, wykonanie, analizę i działania po teście. Dla sieci wewnętrznej przekłada się to na następujący proces.

1. Ustal cele i zasady prowadzenia testu

Definiujemy lokalizacje, podsieci, strefy, systemy OT/medyczne, urządzenia legacy, godziny, limity ruchu, dane wyłączone i kontakt awaryjny. Zespół ustala, czy celem jest zgodność z macierzą przepływów, odporność po przejęciu laptopa, ocena dostępu dostawcy czy droga do wybranego „crown jewel”. Różnica między red teamem a pentestem powinna być jawna: test segmentacji ma kompletniej mierzyć kontrolę, a nie ukrywać się za wszelką cenę.

2. Umieść sensory w reprezentatywnych strefach

Jeden punkt testowy nie wystarcza. Potrzebne są kontrolowane źródła w sieci użytkowników, serwerów, gości, VPN, Wi-Fi, administracji i — jeśli dopuszczono — chmury lub oddziału. Każdy sensor musi mieć znany adres, właściciela i synchronizację czasu, aby korelować próby z logami.

3. Porównaj routing i osiągalność

Najpierw zbieramy trasy, DNS i podstawowe odpowiedzi. Następnie wykonujemy ograniczone testy do zatwierdzonych celów i portów, mierząc wynik z obu stron. Nie zakładamy, że brak odpowiedzi oznacza blokadę na właściwej kontroli; administrator wskazuje log firewalla, ACL lub hosta potwierdzający decyzję.

4. Waliduj kontrolę tożsamości

Dla dozwolonych ścieżek sprawdzamy, czy usługa nadal wymaga właściwej tożsamości, MFA, certyfikatu urządzenia lub pośrednictwa bastionu. Segmentacja sieciowa nie kompensuje anonymous access, współdzielonych kont i nieograniczonych kont serwisowych.

5. Potwierdź skutek minimalnym dowodem

Dowodem może być handshake TLS, poprawna odmowa aplikacyjna, odczyt nieszkodliwego pliku testowego albo logowanie kontem przeznaczonym wyłącznie do testu. Nie kopiujemy danych biznesowych i nie utrzymujemy dostępu. Jeżeli do oceny wpływu potrzebne jest bardziej inwazyjne działanie, wymaga ono osobnej zgody.

6. Retestuj z obu stron

Po zmianie reguły ponawiamy test z tego samego źródła, a następnie sprawdzamy przepływy zależne. Zbyt szeroka blokada może przerwać backup, monitoring lub uwierzytelnienie. Retest powinien więc potwierdzić zarówno usunięcie ścieżki, jak i działanie zaakceptowanej usługi.

Detekcja: jak udowodnić, że kontrola jest obserwowalna

Pentest powinien generować oznaczone zdarzenia, które SOC może odszukać. Źródła obejmują logi zapór, NetFlow/IPFIX, DNS, proxy, NAC, EDR, Windows Event Log, syslog urządzeń, VPN i systemy uwierzytelnienia. Kluczowa jest wspólna oś czasu oraz mapowanie adresu na urządzenie i użytkownika.

Alerty warto projektować dla:

prób połączeń z segmentu użytkowników do stref zarządzających;
skanowania wielu hostów lub portów z jednego źródła;
użycia protokołów administracyjnych poza bastionem;
wewnętrznego DNS dla rzadkich stref lub nazw infrastrukturalnych;
ruchu bocznego między stacjami, który nie występuje w normalnym profilu;
nowego urządzenia albo zmiany profilu NAC;
nietypowego IPv6 przy braku zarządzanego wdrożenia;
połączenia z backupem, hypervisorem lub kontrolerem domeny z niezatwierdzonej strefy.

Brak alertu nie zawsze oznacza brak logu. Raport powinien oddzielić: kontrola nie zablokowała, kontrola zablokowała bez telemetrii, telemetria istnieje bez detekcji oraz detekcja zadziałała bez procedury reakcji.

Hardening segmentacji i redukcja ruchu bocznego

Skuteczna poprawa zaczyna się od właściciela każdego przepływu. Reguły powinny być deny-by-default, ograniczone do źródła, celu, protokołu i uzasadnienia, z datą przeglądu. Dostęp administracyjny kierujemy przez bastion lub PAM, a stacje uprzywilejowane umieszczamy w oddzielnej strefie. Host firewalle i microsegmentation ograniczają ruch, którego firewall centralny nie widzi.

Warto również:

odseparować backup i systemy bezpieczeństwa od zwykłej domeny użytkowników;
zablokować bezpośredni ruch workstation-to-workstation, gdy nie jest potrzebny;
ograniczyć egress serwerów do nazwanych usług i repozytoriów;
zarządzać IPv6 albo wyłączyć je zgodnie z obsługiwaną konfiguracją, a nie przypadkowo;
wprowadzić 802.1X/NAC z bezpieczną strefą dla urządzeń nieznanych;
rozdzielić sieci klientów VPN według roli i stanu urządzenia;
usuwać tymczasowe reguły automatycznie;
testować politykę po zmianach routingu, chmury, SD-WAN i przejęciach firm.

Checklista testu sieci wewnętrznej

Jak powinien wyglądać raport

Każdy finding powinien zawierać strefę źródłową, strefę docelową, protokół, identity context, oczekiwaną politykę, rzeczywisty wynik, minimalny dowód, skutek i właściciela poprawki. Diagram osiągalności jest bardziej użyteczny niż tysiące portów ze skanera. Priorytet nadajemy ścieżkom prowadzącym do tier 0, backupu, paneli zarządzania, danych regulowanych i mechanizmów wdrożeniowych.

Organizacja powinna powtarzać test po dużych zmianach sieci, wdrożeniu SD-WAN lub ZTNA, migracji chmurowej, fuzji oraz zmianie modelu administracji. Segmentacja jest stanem dynamicznym, a nie projektem zamkniętym po wdrożeniu firewalli.

Nowe strefy, reguły i usługi warto projektować zgodnie z zasadą Secure by Design, aby bezpieczny przepływ był domyślnym wzorcem, a nie poprawką dodawaną po incydencie.