Otwarte porty oraz usługi nasłuchujące na interfejsach sieciowych stanowią jeden z podstawowych elementów powierzchni ataku systemu operacyjnego. Każda usługa udostępniona za pośrednictwem sieci może potencjalnie stać się celem skanowania, ataku na podatność lub próby uzyskania nieautoryzowanego dostępu.
Sama obecność otwartego portu nie oznacza jeszcze występowania podatności.
Istotne jest jednak ustalenie nie tylko tego, jaka usługa korzysta z danego portu i pod jakim adresem nasłuchuje, lecz także tego, z jakich sieci można nawiązać z nią połączenie, a ponadto czy jej działanie jest rzeczywiście konieczne.
Kontrolę otwartych portów należy prowadzić zarówno na serwerach, jak i na stacjach roboczych, przy czym szczególną uwagę warto zwrócić na systemy wystawione do sieci niezaufanych, a także na te, które znajdują się w strefach DMZ lub pełnią funkcje infrastrukturalne.
Celem kontroli jest wykrycie niepotrzebnie dostępnych usług, nieautoryzowanych procesów nasłuchujących, błędnie skonfigurowanych interfejsów oraz rozbieżności pomiędzy rzeczywistą konfiguracją systemu a dokumentacją infrastruktury.
Znaczenie kontroli portów w cyberbezpieczeństwie
Port sieciowy jest punktem, przez który aplikacja lub usługa może komunikować się z innymi systemami.
Jeżeli serwer posiada aktywną usługę HTTP na porcie 80, SSH na porcie 22 oraz bazę danych na porcie 5432, każda z tych usług może stanowić potencjalny punkt wejścia do systemu.
Nie oznacza to oczywiście, że wszystkie takie usługi są niebezpieczne. Ryzyko zależy między innymi od:
- rodzaju usługi,
- wersji oprogramowania,
- poziomu aktualizacji,
- konfiguracji usługi,
- zakresu dostępności,
- zastosowanych mechanizmów uwierzytelniania,
- zabezpieczeń zapory,
- poziomu uprawnień procesu,
- znaczenia systemu dla organizacji.
Z tego względu audytor powinien traktować listę otwartych portów jako punkt wyjścia do dalszej analizy, a nie jako samodzielny dowód występowania podatności.
Port nasłuchujący a port dostępny z sieci
Podczas audytu należy rozróżnić dwie kwestie.
Pierwszą jest nasłuchiwanie usługi na systemie.
Drugą jest rzeczywista dostępność portu z określonej sieci.
Przykładowo usługa może nasłuchiwać na:
127.0.0.1:8080
W takim przypadku dostęp ogranicza się do lokalnego systemu.
Inna sytuacja występuje, gdy usługa nasłuchuje na:
0.0.0.0:8080
Może to oznaczać dostępność na wszystkich interfejsach IPv4, zależnie od konfiguracji zapory i pozostałych mechanizmów sieciowych.
Jeszcze innym przypadkiem jest nasłuchiwanie na konkretnym adresie:
10.10.10.20:8080
Wtedy usługa może być dostępna tylko przez określony interfejs.
Audytor powinien więc analizować nie tylko numer portu, ale również adres lokalny, na którym usługa nasłuchuje.
Zakres kontroli
Kontrola powinna obejmować:
- aktywne porty TCP,
- aktywne porty UDP,
- usługi nasłuchujące,
- adresy IP przypisane do nasłuchujących usług,
- interfejsy sieciowe,
- procesy wykorzystujące porty,
- użytkowników uruchamiających procesy,
- konfigurację zapory,
- usługi systemowe,
- usługi aplikacyjne,
- usługi uruchamiane automatycznie,
- usługi tymczasowe,
- usługi nieudokumentowane.
W przypadku serwerów należy dodatkowo zweryfikować, czy każdy otwarty port ma swoje uzasadnienie wynikające z roli systemu.
Kontrola portów w systemach Windows
W systemach Windows jednym z podstawowych narzędzi wykorzystywanych podczas audytu jest PowerShell.
Listę aktywnych połączeń TCP oraz portów nasłuchujących można uzyskać za pomocą:
Get-NetTCPConnection
Aby wyświetlić wyłącznie porty znajdujące się w stanie nasłuchiwania:
Get-NetTCPConnection -State Listen
Przydatne jest ograniczenie wyniku do najważniejszych informacji:
Get-NetTCPConnection -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
Wynik może wyglądać następująco:
LocalAddress LocalPort OwningProcess
------------ --------- -------------
0.0.0.0 80 4120
0.0.0.0 443 4120
10.10.10.20 3389 1104
127.0.0.1 8080 5216
Na tej podstawie audytor może określić:
- który port wykorzystuje,
- na jakim adresie systemu odbywa się nasłuchiwanie,
- który proces odpowiada za usługę.
Identyfikacja procesu
Sam identyfikator procesu nie zawsze jest wystarczający. Należy ustalić, jaki program lub usługa odpowiada za dane nasłuchiwanie.
Można wykorzystać:
Get-Process -Id 4120
lub:
Get-Process -Id 1104
W praktyce warto powiązać trzy informacje:
port
↓
PID
↓
proces / aplikacja / usługa
Pozwala to ustalić, dlaczego dany port jest otwarty.
Powiązanie procesu z usługą Windows
W przypadku procesów będących usługami systemowymi należy dodatkowo ustalić nazwę usługi.
Pomocne może być:
Get-CimInstance Win32_Service |
Select-Object Name, DisplayName, State, StartMode, ProcessId
Następnie można porównać ProcessId z identyfikatorem procesu uzyskanym podczas analizy portu.
Pozwala to stworzyć pełniejszy obraz:
TCP/3389
↓
PID 1104
↓
TermService
↓
Remote Desktop Services
Takie powiązanie jest istotne podczas oceny, czy dana usługa jest wymagana przez funkcję pełnioną przez system.
Narzędzie netstat w Windows
W starszych wersjach systemów Windows oraz podczas analizy istniejących procedur administracyjnych można wykorzystać również netstat.
Przykład:
netstat -ano
Opcja -a wyświetla połączenia oraz porty nasłuchujące, -n wymusza wyświetlanie adresów i portów w postaci numerycznej, natomiast -o pozwala uzyskać identyfikator procesu.
Do wyświetlenia portów nasłuchujących można wykorzystać:
netstat -ano | findstr LISTENING
Następnie PID można powiązać z procesem:
tasklist /FI "PID eq 1104"
netstat nadal może być użytecznym narzędziem podczas audytu, jednak w nowych środowiskach Windows PowerShell i polecenia Get-NetTCPConnection zapewniają bardziej natywny sposób analizy.
Kontrola portów UDP
Analiza nie powinna ograniczać się wyłącznie do TCP.
Porty UDP mogą być wykorzystywane między innymi przez:
- DNS,
- DHCP,
- NTP,
- SNMP,
- usługi VoIP,
- aplikacje multimedialne,
- mechanizmy VPN,
- usługi infrastrukturalne.
W systemach Windows można wykorzystać:
Get-NetUDPEndpoint
Przykładowo:
Get-NetUDPEndpoint |
Select-Object LocalAddress, LocalPort, OwningProcess
Audytor powinien następnie określić, jaki proces wykorzystuje dany port i czy komunikacja jest wymagana.
Kontrola portów w systemach Linux
W systemach Linux podstawowym narzędziem do analizy usług sieciowych jest obecnie ss.
Lista portów nasłuchujących TCP:
ss -lnt
Lista portów nasłuchujących TCP i UDP wraz z procesami:
sudo ss -lntup
Poszczególne opcje oznaczają między innymi:
-l– wyświetlenie gniazd nasłuchujących,-n– adresy i porty w formie numerycznej,-t– TCP,-u– UDP,-p– informacje o procesie.
Przykładowy wynik:
Netid State Local Address:Port
tcp LISTEN 0.0.0.0:22
tcp LISTEN 0.0.0.0:443
tcp LISTEN 127.0.0.1:8080
udp UNCONN 0.0.0.0:123
Audytor powinien zwrócić szczególną uwagę na wpisy:
0.0.0.0:PORT
[::]:PORT
Mogą one wskazywać, że usługa nasłuchuje na wszystkich interfejsach odpowiedniego stosu IP.
Identyfikacja procesów w Linux
Polecenie ss może również dostarczyć informacji o procesie:
sudo ss -lntup
Przykładowo:
tcp LISTEN 0 128 0.0.0.0:22
users:(("sshd",pid=1042,fd=3))
Audytor może następnie sprawdzić proces:
ps -fp 1042
lub wykorzystać:
sudo lsof -i -P -n
Aby znaleźć proces wykorzystujący konkretny port:
sudo lsof -i :22
Pozwala to ustalić, jaka aplikacja lub usługa odpowiada za dane nasłuchiwanie.
Powiązanie portu z usługą systemową
Po zidentyfikowaniu procesu należy ustalić, czy jest on związany z usługą systemową.
W systemach wykorzystujących systemd pomocne będzie:
systemctl status ssh
W zależności od dystrybucji nazwa usługi może być inna, np.:
sshd
ssh
nginx
apache2
postgresql
Można również sprawdzić listę aktywnych usług:
systemctl list-units --type=service --state=running
Audytor powinien ustalić, czy usługa jest:
- wymagana,
- aktywnie wykorzystywana,
- uruchamiana automatycznie,
- odpowiednio zabezpieczona,
- objęta aktualizacjami,
- uwzględniona w dokumentacji systemu.
Porównanie z konfiguracją zapory
Lista nasłuchujących portów powinna być analizowana razem z konfiguracją zapory systemowej.
Należy rozróżnić:
Usługa nasłuchuje
↓
Zapora zezwala
↓
Port może być dostępny z sieci
oraz:
Usługa nasłuchuje
↓
Zapora blokuje
↓
Brak dostępu z określonej sieci
Sam fakt nasłuchiwania usługi nie oznacza więc automatycznie, że jest ona dostępna z Internetu.
Z drugiej strony konfiguracja zapory zezwalająca na określony port nie oznacza, że na tym porcie rzeczywiście działa usługa.
Z tego względu oba elementy powinny być kontrolowane jednocześnie.
Weryfikacja z perspektywy sieci
W przypadku systemów o istotnym znaczeniu dla bezpieczeństwa warto przeprowadzić również test z zewnętrznego punktu sieciowego.
Można wykorzystać między innymi:
nmap -sT -p 22,80,443 10.10.10.20
lub dla określonego zakresu:
nmap -sT -p- 10.10.10.20
Zakres skanowania powinien być dostosowany do uprawnień audytora i uzgodnionego zakresu testu.
Wynik skanowania należy porównać z konfiguracją systemu.
Może się okazać, że:
- usługa nasłuchuje lokalnie, ale nie jest dostępna z sieci,
- usługa jest dostępna tylko z określonego segmentu,
- firewall blokuje dostęp zgodnie z założeniami,
- usługa jest dostępna z sieci, mimo że nie powinna być,
- dokumentacja nie odpowiada rzeczywistej konfiguracji.
Usługi dostępne na wszystkich interfejsach
Szczególną uwagę należy zwrócić na usługi nasłuchujące na wszystkich interfejsach.
Przykładem może być:
0.0.0.0:3306
oznaczający nasłuchiwanie MySQL na wszystkich interfejsach IPv4.
Jeżeli baza danych powinna być dostępna wyłącznie lokalnie lub z określonej sieci aplikacyjnej, taka konfiguracja może stanowić niepotrzebne zwiększenie powierzchni ataku.
Analogiczna sytuacja może występować dla:
- PostgreSQL,
- Redis,
- Elasticsearch,
- MongoDB,
- interfejsów administracyjnych,
- paneli aplikacyjnych,
- usług monitorowania.
Nie należy jednak automatycznie traktować nasłuchiwania na 0.0.0.0 jako podatności. Należy sprawdzić rzeczywistą architekturę oraz konfigurację zapory.
Usługi lokalne
Usługi nasłuchujące wyłącznie na:
127.0.0.1
lub odpowiednim adresie loopback IPv6 są zazwyczaj niedostępne bezpośrednio z innych systemów.
Może to być prawidłowa konfiguracja dla:
- lokalnych baz danych,
- backendów aplikacji,
- interfejsów administracyjnych,
- usług pomocniczych,
- lokalnych agentów.
Audytor powinien jednak upewnić się, czy aplikacja nie udostępnia tej usługi pośrednio poprzez inny komponent, reverse proxy lub mechanizm tunelowania.
Typowe nieprawidłowości
Podczas kontroli otwartych portów i nasłuchujących usług można spotkać między innymi:
Niepotrzebna usługa
Usługa jest uruchomiona, mimo że system nie wymaga jej do realizacji swojej funkcji.
Nieudokumentowany port
Na systemie działa usługa, której nie ma w dokumentacji infrastruktury.
Usługa dostępna na wszystkich interfejsach
Aplikacja nasłuchuje na 0.0.0.0 lub [::], mimo że powinna być dostępna tylko lokalnie lub z określonej sieci.
Nieograniczony dostęp do usługi administracyjnej
Port RDP, SSH, WinRM lub inny interfejs zarządzania jest dostępny z większej liczby sieci niż jest to konieczne.
Nieaktualna aplikacja
Otwarty port prowadzi do usługi wykorzystującej przestarzałą lub nieobsługiwaną wersję oprogramowania.
Pozostałość po wdrożeniu
Port został otwarty na potrzeby testów lub instalacji, ale nie został zamknięty po zakończeniu prac.
Nieznany proces
Audytor identyfikuje port nasłuchujący, ale administrator nie jest w stanie określić jego przeznaczenia.
Niespójność dokumentacji
Dokumentacja wskazuje jeden zestaw usług, podczas gdy rzeczywista konfiguracja systemu zawiera dodatkowe porty.
Ocena ryzyka
Ryzyko związane z otwartym portem powinno być oceniane w kontekście konkretnej usługi.
Największe znaczenie mają:
- dostępność z Internetu,
- rodzaj usługi,
- podatności aplikacji,
- sposób uwierzytelniania,
- poziom uprawnień procesu,
- znaczenie systemu,
- możliwość eskalacji uprawnień,
- możliwość dalszego przemieszczania się w sieci.
Przykładowo, otwarty port HTTP obsługujący prawidłowo zabezpieczoną aplikację internetową może być elementem wymaganej funkcjonalności systemu.
Ten sam poziom dostępności dla nieużywanej usługi administracyjnej może natomiast stanowić istotne zagrożenie.
Dlatego w raporcie audytowym należy wskazywać nie tylko numer portu, ale przede wszystkim usługę, zakres jej dostępności oraz uzasadnienie biznesowe.
Rekomendowane działania naprawcze
Organizacja powinna utrzymywać aktualną listę usług sieciowych wymaganych przez poszczególne systemy.
Niepotrzebne usługi powinny być wyłączane, a jeżeli nie są wymagane — również odinstalowywane.
Porty wykorzystywane przez wymagane usługi powinny być dostępne wyłącznie z niezbędnych segmentów sieci.
W przypadku usług wewnętrznych należy rozważyć ograniczenie nasłuchiwania do konkretnego interfejsu lub adresu IP zamiast wszystkich interfejsów.
Dostęp administracyjny powinien być ograniczony do wydzielonych sieci administracyjnych lub kontrolowanych mechanizmów dostępu.
Każdy nowy port otwierany na systemie produkcyjnym powinien mieć:
- właściciela,
- uzasadnienie,
- określony zakres dostępu,
- wskazanie wymaganej usługi,
- odpowiednią regułę zapory,
- dokumentację.
Zaleca się również okresowe skanowanie systemów z perspektywy sieci oraz porównywanie wyników z konfiguracją hosta.
Dowody audytowe
W systemach Windows dowodami mogą być między innymi:
Get-NetTCPConnection -State Listen
Get-NetUDPEndpoint
Get-Process
Get-CimInstance Win32_Service
Get-NetFirewallRule
W systemach Linux:
ss -lntup
sudo lsof -i -P -n
systemctl list-units --type=service --state=running
sudo nft list ruleset
sudo firewall-cmd --list-all-zones
Dodatkowo można wykorzystać:
- wyniki skanowania
nmap, - konfigurację zapory,
- dokumentację architektury,
- listę zatwierdzonych usług,
- CMDB,
- dokumentację aplikacji,
- zgłoszenia zmian,
- konfigurację systemów monitorowania.
Dowód powinien pozwalać jednoznacznie ustalić, jaki port jest otwarty, jaka usługa go wykorzystuje oraz dlaczego dostęp do niej jest wymagany.
Przykładowe ustalenie audytowe
Ustalenie: Nieudokumentowana usługa nasłuchująca na porcie TCP
Podczas kontroli serwera Linux zidentyfikowano usługę nasłuchującą na porcie TCP 8080 na wszystkich interfejsach sieciowych:
0.0.0.0:8080
Proces został zidentyfikowany jako aplikacja uruchomiona przez użytkownika systemowego.
Usługa nie została uwzględniona w dokumentacji serwera, a administrator nie przedstawił uzasadnienia biznesowego dla jej udostępnienia.
Dodatkowo analiza konfiguracji zapory wykazała możliwość komunikacji z tego segmentu sieci.
Ryzyko: średnie / wysokie — zależnie od funkcji i podatności aplikacji.
Potencjalne skutki:
- zwiększenie powierzchni ataku,
- możliwość wykorzystania podatności aplikacji,
- nieautoryzowany dostęp do funkcji aplikacji,
- możliwość wykorzystania serwera jako punktu wejścia do dalszego ataku.
Rekomendacja:
Ustalić właściciela i przeznaczenie usługi. Jeżeli usługa nie jest wymagana, należy ją wyłączyć i usunąć odpowiednią regułę zapory. Jeżeli jest wymagana, należy ograniczyć zakres jej dostępności do niezbędnych adresów i udokumentować konfigurację.
Powiązanie z innymi kontrolami
Kontrola otwartych portów jest bezpośrednio powiązana z innymi elementami audytu systemu operacyjnego.
Szczególnie istotne są:
- kontrola usług uruchamianych wraz z systemem,
- konfiguracja zapory systemowej,
- zarządzanie aktualizacjami,
- analiza zainstalowanego oprogramowania,
- zabezpieczenie RDP i SSH,
- kontrola kont i uprawnień,
- monitorowanie zdarzeń,
- hardening systemu.
W praktyce analiza powinna tworzyć spójny łańcuch:
otwarty port
↓
nasłuchujący proces
↓
usługa / aplikacja
↓
konto uruchamiające
↓
reguła zapory
↓
źródła mogące uzyskać dostęp
↓
uzasadnienie biznesowe
Dopiero analiza wszystkich tych elementów pozwala prawidłowo ocenić ryzyko.
Powiązanie z normami i dobrymi praktykami
Kontrola otwartych portów i nasłuchujących usług wspiera realizację wymagań dotyczących bezpiecznej konfiguracji systemów, zarządzania zasobami oraz ograniczania powierzchni ataku.
Kontrola może być powiązana między innymi z:
- ISO/IEC 27001:2022,
- ISO/IEC 27002:2022,
- NIST Cybersecurity Framework,
- CIS Controls v8,
- CIS Benchmarks dla systemów Windows i Linux.
Szczególnie istotne jest podejście zgodne z zasadą minimalizacji funkcjonalności systemu: system powinien udostępniać wyłącznie te usługi, które są rzeczywiście wymagane.
Podsumowanie
Kontrola otwartych portów i nasłuchujących usług pozwala określić rzeczywistą powierzchnię ataku systemu operacyjnego.
Najważniejszym celem audytora nie jest stworzenie samej listy portów, lecz ustalenie, dlaczego dany port jest otwarty, jaka usługa go wykorzystuje, na jakich interfejsach nasłuchuje i kto może się z nią połączyć.
Lista portów powinna być porównywana z dokumentacją systemu, konfiguracją zapory oraz wymaganiami biznesowymi.
Każda niepotrzebna usługa powinna zostać wyłączona, a dostęp do wymaganych usług powinien być ograniczony do niezbędnych sieci i użytkowników.
Regularne monitorowanie portów i usług, połączone z kontrolą konfiguracji zapory oraz procesem zarządzania zmianami, pozwala ograniczyć powierzchnię ataku i szybko wykrywać nieautoryzowane zmiany konfiguracji systemów Windows i Linux.
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:).
