Port 135 – UDP, TCP – za co odpowiada?

Port 135 to jeden z najbardziej charakterystycznych portów w ekosystemie Microsoft Windows. Choć dla wielu administratorów stanowi oczywisty element infrastruktury sieciowej, jego rola, znaczenie i konsekwencje bezpieczeństwa są często niedoceniane lub całkowicie błędnie rozumiane. Ten artykuł stanowi kompleksowy przewodnik po porcie 135 – od jego technicznej funkcji jako RPC Endpoint Mapper, przez historyczne i współczesne wektory ataków, aż po praktyczne rekomendacje dotyczące zabezpieczania środowisk Windows.

Czym jest port 135 i za co odpowiada?

Port 135, działający zarówno w protokole TCP, jak i UDP, jest oficjalnie zarejestrowany w organizacji IANA jako EPMAP (Endpoint Mapper). W praktyce odpowiada za działanie usługi Microsoft RPC Endpoint Mapper, znanej również jako DCE/RPC Locator Service. Jest to fundamentalny komponent architektury Windows, umożliwiający komunikację między procesami zarówno lokalnie, jak i w sieci.

Główne zadanie tej usługi sprowadza się do pełnienia roli „książki telefonicznej” dla wszystkich usług RPC (Remote Procedure Call) działających na danym hoście Windows. Gdy aplikacja kliencka chce skomunikować się z konkretną usługą RPC na zdalnym serwerze, najpierw łączy się z portem 135, aby uzyskać informację, na którym dynamicznym porcie aktualnie nasłuchuje docelowa usługa.

Jak technicznie działa Endpoint Mapper?

Proces komunikacji przez port 135 przebiega według ściśle określonego schematu:

1. Klient inicjuje połączenie TCP (lub rzadziej UDP) z portem 135 na serwerze docelowym.
2. Wysyła zapytanie o konkretną usługę RPC, identyfikowaną przez unikalny UUID (Universally Unique Identifier).
3. Endpoint Mapper przeszukuje swoją wewnętrzną bazę zarejestrowanych usług RPC.
4. Zwraca klientowi informację o porcie dynamicznym, na którym dana usługa nasłuchuje (zwykle z zakresu 49152-65535 w nowszych systemach Windows).
5. Klient nawiązuje właściwe połączenie z usługą docelową na otrzymanym porcie dynamicznym.

Warto podkreślić, że port 135 sam w sobie nie obsługuje właściwej komunikacji aplikacyjnej – jego rolą jest wyłącznie pośrednictwo w nawiązaniu sesji. Bez działającego Endpoint Mappera komunikacja z większością usług RPC byłaby praktycznie niemożliwa, ponieważ klient nie miałby możliwości ustalenia, gdzie szukać konkretnej usługi.

TCP czy UDP – który protokół dominuje?

Port 135 jest zarejestrowany dla obu protokołów warstwy transportowej, jednak w praktyce ich znaczenie znacząco się różni. TCP jest protokołem dominującym i wykorzystywanym w zdecydowanej większości scenariuszy komunikacyjnych. Zapewnia niezawodne, połączeniowe dostarczanie danych, co ma kluczowe znaczenie dla wymiany informacji o endpointach.

UDP na porcie 135 jest dziś wykorzystywane sporadycznie, głównie w starszych implementacjach lub specyficznych scenariuszach broadcastowych. Microsoft od lat preferuje TCP jako podstawowy protokół dla usług RPC, co znajduje odzwierciedlenie w domyślnych konfiguracjach Windows Server.

Usługi Microsoft zależne od portu 135

Lista komponentów Windows wymagających funkcjonującego Endpoint Mappera jest imponująco długa. Port 135 stanowi krytyczny element infrastruktury dla:

• Active Directory – replikacja między kontrolerami domeny, uwierzytelnianie, operacje LDAP wymagające RPC
• Microsoft Exchange Server – komunikacja klient-serwer (szczególnie w starszych wersjach), MAPI over RPC
• Windows Management Instrumentation (WMI) – zdalne zarządzanie systemami, monitoring, automatyzacja
• DHCP Server – zarządzanie zakresami, replikacja konfiguracji
• DNS Server – zdalne zarządzanie strefami i rekordami
• WINS – replikacja i zarządzanie
• Distributed File System (DFS) – zarządzanie przestrzenią nazw
• Failover Clustering – komunikacja między węzłami klastra
• Microsoft Distributed Transaction Coordinator (MSDTC) – koordynacja transakcji rozproszonych
• Print Spooler – zdalne zarządzanie drukowaniem

W środowiskach Active Directory zablokowanie portu 135 między klientami a kontrolerami domeny prowadzi do natychmiastowych problemów z uwierzytelnianiem, replikacją i ogólną funkcjonalnością domeny. To właśnie dlatego port ten jest tak powszechnie otwarty w sieciach korporacyjnych.

Port 135 a dynamiczne porty RPC – kluczowa różnica

Jedno z najczęstszych nieporozumień dotyczy relacji między portem 135 a właściwymi portami komunikacji RPC. Port 135 to wyłącznie mapper – sam nie obsługuje wymiany danych aplikacyjnych. Właściwa komunikacja odbywa się na dynamicznie przydzielanych portach.

Domyślny zakres dynamicznych portów RPC w nowszych systemach Windows (od Windows Vista/Server 2008 wzwyż) to 49152-65535. W starszych wersjach (Windows 2000, XP, Server 2003) zakres ten obejmował porty 1024-5000. Ta różnica ma istotne implikacje dla konfiguracji firewalli i polityk bezpieczeństwa.

Ograniczanie zakresu portów RPC

Microsoft umożliwia ograniczenie zakresu portów dynamicznych RPC poprzez konfigurację rejestru lub narzędzia zarządzania. Pozwala to administratorom na precyzyjne sterowanie ruchem przez firewalle, zamiast otwierania całego domyślnego zakresu kilkudziesięciu tysięcy portów. Konfiguracja odbywa się w kluczu rejestru:

HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet

Definiując wartości Ports, PortsInternetAvailable oraz UseInternetPorts, można zawęzić zakres do konkretnego przedziału, na przykład 50000-51000.

Historia ataków na port 135

Port 135 ma długą i niechlubną historię jako wektor ataków. Otwarta na świat usługa Endpoint Mapper okazała się jednym z najpopularniejszych celów twórców złośliwego oprogramowania.

W32.Blaster.Worm – lekcja z 2003 roku

Sierpień 2003 roku zapisał się w historii bezpieczeństwa IT jako moment globalnej epidemii robaka Blaster (znanego również jako Lovsan lub MSBlast). Wykorzystywał on lukę w implementacji DCOM RPC (MS03-026), atakując właśnie port 135. W ciągu kilku dni zainfekował setki tysięcy komputerów na całym świecie, powodując restartowanie systemów, problemy z dostępnością usług i ogromne straty finansowe.

Blaster zapoczątkował serię podobnych zagrożeń – Welchia, Nachi, Mytob – z których wszystkie celowały w port 135. Łącznie historia zna ponad 20 znaczących robaków i exploitów wykorzystujących tę usługę.

Współczesne zagrożenia (2022-2025)

Wbrew obiegowym opiniom port 135 nie jest reliktem przeszłości w kontekście bezpieczeństwa. Współczesne techniki ataków, szczególnie w obszarze lateral movement, ponownie czynią z niego niezwykle istotny wektor.

W ostatnich latach pojawiły się nowe techniki PsExec-podobne, wykorzystujące wyłącznie port 135 do zdalnego wykonywania kodu, z całkowitym pominięciem tradycyjnego portu 445 (SMB). W testach penetracyjnych przeprowadzonych w 2025 roku przez specjalistów Pentera wykazano, że port 135 może być skutecznym wektorem RCE (Remote Code Execution) nawet w środowiskach, gdzie tradycyjne wektory SMB są zablokowane.

Z tego powodu specjaliści ds. bezpieczeństwa coraz częściej nazywają port 135 „nowym 445” w kontekście ataków bocznego ruchu w sieciach Windows. Atakujący, którzy zdobyli już przyczółek w sieci, mogą wykorzystać DCOM i WMI do propagacji bez generowania charakterystycznego ruchu SMB monitorowanego przez większość rozwiązań EDR.

Enumeracja przez port 135 – co widzi atakujący?

Połączenie z portem 135 dostarcza atakującemu cennych informacji rozpoznawczych. Poprzez zapytanie do Endpoint Mappera można uzyskać pełną listę zarejestrowanych usług RPC na danym hoście, wraz z ich UUID, opisami i portami nasłuchu. Narzędzia takie jak rpcdump z pakietu Impacket, Nmap ze skryptem msrpc-enum, czy klasyczny epdump pozwalają na szybką enumerację dostępnych usług.

Te informacje stanowią cenną wiedzę dla atakującego, ujawniając:

• Wersję i typ systemu operacyjnego
• Zainstalowane role serwerowe (kontroler domeny, Exchange, serwer DHCP itp.)
• Dostępne interfejsy RPC, które mogą zostać wykorzystane do dalszych ataków
• Potencjalne podatności związane z konkretnymi usługami

Port 135 a inne porty RPC w architekturze Windows

Aby w pełni zrozumieć rolę portu 135, warto porównać go z innymi portami związanymi z komunikacją RPC i SMB w środowisku Microsoft:

Port 593 – RPC over HTTP

Port 593 obsługuje protokół RPC over HTTP, wykorzystywany historycznie przez Outlook Anywhere oraz inne scenariusze, gdzie komunikacja RPC musiała przechodzić przez firewalle internetowe. W przeciwieństwie do portu 135, port 593 hermetyzuje ruch RPC w HTTP, co ułatwia routing przez infrastruktury z restrykcyjnymi politykami bezpieczeństwa.

Porty 139 i 445 – NetBIOS i SMB

Port 139 (NetBIOS Session Service) i 445 (SMB over TCP) obsługują głównie współdzielenie plików, drukarek oraz uwierzytelnianie. Choć są one funkcjonalnie różne od portu 135, w praktyce często współwystępują – wiele protokołów Microsoft wykorzystuje zarówno SMB, jak i RPC do różnych aspektów komunikacji.

Porty dynamiczne 49152-65535

Jak wspomniano wcześniej, są to faktyczne porty, na których działają usługi RPC po negocjacji przez Endpoint Mappera. Stanowią uzupełnienie portu 135 i bez nich pełna komunikacja RPC nie jest możliwa.

Najlepsze praktyki zabezpieczania portu 135

Zabezpieczenie portu 135 wymaga wielowarstwowego podejścia, łączącego ograniczenia sieciowe, hardening systemu i aktywny monitoring. Poniżej zestaw kluczowych rekomendacji.

1. Blokowanie na firewallach perymetrycznych

Pierwszą i absolutnie krytyczną zasadą jest całkowite zablokowanie portu 135 na firewallach brzegowych. Port ten nigdy nie powinien być dostępny z internetu publicznego. Skanowanie zasobów organizacji narzędziami takimi jak Shodan czy Censys regularnie ujawnia tysiące eksponowanych endpointów RPC, co stanowi otwartą furtkę dla atakujących.

2. Segmentacja sieci wewnętrznej

Wewnątrz sieci korporacyjnej należy stosować zasadę najmniejszych uprawnień również na poziomie sieciowym. Komunikacja na porcie 135 powinna być dozwolona wyłącznie tam, gdzie jest to faktycznie potrzebne – na przykład między klientami a kontrolerami domeny, ale niekoniecznie między stacjami roboczymi użytkowników końcowych.

3. RPC Filtering

Począwszy od Windows Server 2022 oraz Windows 11, Microsoft wprowadził mechanizm RPC Filtering, umożliwiający precyzyjną kontrolę nad tym, które interfejsy RPC są dostępne dla zdalnych klientów. Pozwala to na zablokowanie konkretnych, podatnych usług RPC bez konieczności wyłączania całego portu 135. Konfiguracja odbywa się przez narzędzie netsh rpc filter.

4. Hardening DCOM

Microsoft systematycznie zwiększa bezpieczeństwo DCOM, wprowadzając między innymi obowiązkowe uwierzytelnianie na poziomie pakietu (Packet Integrity). Po aktualizacjach z 2022-2023 roku DCOM domyślnie wymaga silniejszego uwierzytelniania, co utrudnia ataki typu DCOM hijacking. Administratorzy powinni zadbać o aktualność systemów oraz prawidłową konfigurację uprawnień DCOM przez dcomcnfg.

5. Ograniczenie zakresu portów dynamicznych

Konfiguracja statycznego, wąskiego zakresu portów RPC ułatwia kontrolę firewallową i redukuje powierzchnię ataku. Zamiast otwierać 16 tysięcy portów dynamicznych, można ograniczyć usługi RPC do zdefiniowanego przedziału kilkuset portów.

6. Monitoring i wykrywanie anomalii

Aktywny monitoring ruchu na porcie 135 stanowi kluczowy element wykrywania ataków lateral movement. Wskaźniki wymagające szczególnej uwagi to:

• Nietypowe wzorce połączeń między stacjami roboczymi (zwykle nie powinny komunikować się ze sobą przez RPC)
• Masowe enumeracje portu 135 z pojedynczego źródła
• Wywołania RPC do interfejsów typowo wykorzystywanych w atakach (np. ITaskSchedulerService, IWbemServices)
• Połączenia z portu 135 do dynamicznych portów RPC poza standardowymi wzorcami pracy

Rozwiązania EDR/XDR oraz narzędzia typu Sysmon z odpowiednią konfiguracją (event ID 3 – sieciowe połączenia) pozwalają na skuteczne wykrywanie podejrzanej aktywności.

7. Regularne aktualizacje

Historia podatności związanych z portem 135 i RPC jest długa, a producenci regularnie publikują łatki bezpieczeństwa. Utrzymywanie aktualnego stanu systemów Windows oraz monitorowanie biuletynów Microsoft dotyczących RPC i DCOM stanowi podstawową higienę bezpieczeństwa.

Diagnostyka i testowanie portu 135

Administratorzy systemowi często potrzebują zweryfikować poprawność działania Endpoint Mappera. Do najpopularniejszych narzędzi diagnostycznych należą:

• PortQry – narzędzie Microsoft do testowania dostępności portów, ze specjalnym wsparciem dla RPC (portqry -n serwer -e 135)
• rpcping – testowanie komunikacji RPC end-to-end
• Test-NetConnection w PowerShell – podstawowy test dostępności TCP
• Nmap ze skryptami msrpc-enum i rpc-grind – dla głębszej enumeracji

Te narzędzia pozwalają zarówno na weryfikację poprawności konfiguracji w środowiskach produkcyjnych, jak i na audyt bezpieczeństwa identyfikujący niepotrzebnie eksponowane usługi.

Czy można wyłączyć port 135?

Pytanie o możliwość całkowitego wyłączenia portu 135 pojawia się regularnie w kontekście hardeningu Windows. Odpowiedź brzmi: technicznie tak, ale w praktyce rzadko jest to wykonalne. Wyłączenie usługi RPC Endpoint Mapper (DcomLaunch lub RpcEptMapper) prowadzi do natychmiastowej awarii ogromnej liczby funkcji systemowych – od logowania domenowego, przez WMI, aż po zarządzanie usługami.

Realistycznym podejściem nie jest wyłączanie usługi, lecz ograniczanie jej ekspozycji poprzez segmentację sieci, filtrowanie RPC oraz ścisłą kontrolę dostępu na poziomie firewalli. Na izolowanych serwerach niedomenowych, niewymagających zdalnego zarządzania, można rozważyć blokadę portu 135 na lokalnym firewallu Windows.

Podsumowanie

Port 135 stanowi fundamentalny, choć kontrowersyjny element architektury Windows. Jako Microsoft RPC Endpoint Mapper umożliwia działanie kluczowych usług Microsoft – od Active Directory, przez WMI, aż po Exchange i całą gamę narzędzi zarządzania. Jednocześnie, ze względu na swoją centralną rolę i bogatą historię podatności, pozostaje jednym z najistotniejszych wektorów ataków w środowiskach Windows.

Współczesne zagrożenia, szczególnie w obszarze lateral movement, sprawiają że port 135 zyskuje na znaczeniu jako „nowy 445” – alternatywny wektor dla atakujących omijających tradycyjne mechanizmy detekcji ataków SMB. Skuteczna ochrona wymaga wielowarstwowego podejścia: blokady na perimetrach, segmentacji sieci wewnętrznej, wykorzystania nowoczesnych mechanizmów takich jak RPC Filtering, hardeningu DCOM oraz aktywnego monitoringu.

Zrozumienie roli i mechanizmów działania portu 135 powinno być obowiązkową wiedzą każdego administratora systemów Windows oraz specjalisty ds. bezpieczeństwa IT. Lekceważenie tego komponentu lub jego błędna konfiguracja może prowadzić do poważnych incydentów bezpieczeństwa, podczas gdy świadome zarządzanie nim stanowi jeden z filarów solidnej obrony środowisk Microsoft.