Przejdź do treści

Usługi dostępne publicznie

Cel artykułu

Celem artykułu jest zaprezentowanie podejścia do usług wystawionych do internetu - od minimalizacji ekspozycji, przez zestawienie kategorii usług, które powinny i nie powinny być publiczne, po dobre praktyki ograniczania ekspozycji oraz zabezpieczania usług, które muszą pozostać publiczne.

Definicja

Usługa dostępna publicznie to usługa nasłuchująca na publicznym adresie IP, osiągalna bezpośrednio z internetu.

Znaczenie usług dostępnych publicznie

Publiczna przestrzeń adresowa organizacji jest nieustannie skanowana w pełnym zakresie portów, co czyni każdą nasłuchującą w niej usługę potencjalnym wektorem ataku.

Bezpieczeństwo przez ukrywanie (ang. security by obscurity)

Przeniesienie usługi administracyjnej na niestandardowy port (np. RDP z 3389 na 13389) nie jest zabezpieczeniem i nie powinno być traktowane jako mechanizm bezpieczeństwa, choć może zmniejszyć ruch sieciowy generowany przez najprostsze skanery. Natomiast te, które skanują cały zakres portów, wykryją usługę niezależnie od numeru portu.

Do incydentów prowadzą powtarzalne błędy konfiguracyjne: publicznie wystawiony pulpit zdalny (RDP) lub SSH wyłącznie z hasłem, baza danych (np. MySQL, PostgreSQL, MSSQL, MongoDB) dostępna z domyślnymi lub prostymi poświadczeniami, udostępnione publicznie protokoły udostępniania plików (SMB/CIFS, FTP), panele administracyjne urządzeń i usług, a także publiczne usługi z wersją oprogramowania zawierającą znaną podatność. W każdym z tych przypadków problem tkwi w usłudze, która nie powinna być dostępna publicznie albo występuje w błędnej konfiguracji.

Podstawą do oceny, jakie usługi dostępne są publicznie, jest inwentaryzacja wraz z mapą przepływów. Dokumentują one, które usługi mają uzasadnioną potrzebę przyjmowania połączeń z internetu, a które nie, i stanowią punkt odniesienia dla weryfikacji stanu rzeczywistego.

Które usługi powinny być publiczne?

Nie każda usługa musi być publiczna. Podział na usługi, które powinny być dostępne publicznie oraz te, które nigdy nie powinny być w ten sposób udostępnione, jest kluczowy dla ograniczenia powierzchni ataku.

Usługi publiczne

Niektóre usługi z założenia muszą być dostępne z poziomu sieci Internet, aby mogły poprawnie działać i spełniać swoje funkcje. Warto jednak pamiętać, że każda z nich wymaga ostrożności.

Najczęściej publicznie udostępniane są:

  • Serwery WWW i portale informacyjne (HTTP/HTTPS) - strona główna instytucji, Biuletyn Informacji Publicznej (BIP) lub inne systemy.
  • Serwery pocztowe - realizacja komunikacji z innymi serwerami pocztowymi.
  • Brama VPN (wirtualna sieć prywatna) - mechanizm umożliwiający bezpieczne szyfrowane połączenie pracowników z poziomu sieci internet do zasobów wewnętrznych organizacji.

Nawet jeśli powyższe usługi muszą być publiczne, często padają ofiarą ataków z powodu błędów konfiguracyjnych.

Częste błędy

  • Fakt, że strona urzędu musi być widoczna dla każdego, nie oznacza, że jej panel administracyjny (np. /wp-admin w przypadku WordPressa) również powinien być dostępny publicznie. Dostęp do panelu zarządzania stroną powinien być uniemożliwiony w ramach konfiguracji tej usługi i dostępny tylko dla wybranych adresów IP pochodzących z sieci wewnętrznej.

  • Poczta instytucji powinna być osiągalna spoza sieci wyłącznie po zalogowaniu do VPN. W przypadku konieczności dostępu do poczty z poza sieci, publiczny dostęp do poczty powinien wymagać weryfikacji dwuetapowej (MFA/2FA) - np. potwierdzenia logowania w aplikacji na telefonie.

  • Jeśli usługa udostępniona na zewnątrz ma komunikować się wyłącznie z konkretnym systemem, powinno się w zaporze sieciowej zezwolić na ruch wyłącznie z adresów IP tego systemu (ang. whitelisting).

  • Brama VPN udostępniana publicznie bez uwierzytelnienia wieloskładnikowego to częsty wektor ataku na sieć wewnętrzną.

Usługi, które nie powinny być publiczne

Poniższe kategorie usług są powtarzającym się wektorem ataku i nie powinny być publicznie osiągalne:

  • Protokoły zdalnego pulpitu i konsoli - RDP, VNC. Publicznie dostępny panel RDP to jeden z najczęstszych wektorów infekcji oprogramowaniem ransomware.
  • Bazy danych - takie jak: MySQL/MariaDB, PostgreSQL, Microsoft SQL Server, MongoDB, Redis. Żadna z nich nie powinna nasłuchiwać na publicznym interfejsie.
  • Serwery dostępu plików i druku - takie jak: SMB/CIFS, NetBIOS, FTP.
  • Panele administracyjne - interfejsy zarządzania routerami, zaporami, przełącznikami, hypervisorami, macierzami dyskowymi, systemami kopii zapasowych, a także interfejsy sprzętowe.
  • Rekursywne serwery DNS - rekursywne serwery DNS nie mogą być dostępne publicznie.

Usługi wewnętrzne bez publicznego dostępu

Usługi przeznaczone do użytku wewnętrznego lub administracyjnego nie mogą być wystawione bezpośrednio do internetu. Dostęp do nich powinien odbywać się wyłącznie z sieci lokalnej lub przez kanał VPN z uwierzytelnieniem wieloskładnikowym.

Ograniczanie ekspozycji

Zanim przejdzie się do zabezpieczania usług publicznych, należy zredukować ich liczbę do minimum. Każda usługa, której nie trzeba udostępniać, jest zbędnym ryzykiem. Zalecane jest:

  • Wyłączenie nieużywanych usług - każda działająca usługa musi mieć uzasadnienie. Usługi nieużywane należy wyłączyć lub odinstalować. Szczegóły w artykule Hardening infrastruktury.
  • Zasada domyślnej odmowy na zaporze brzegowej - reguły na zaporze zewnętrznej powinny domyślnie blokować ruch przychodzący, a przepuszczać wyłącznie świadomie dozwolone usługi. Każda reguła zezwalająca powinna precyzyjnie wskazywać port i cel.
  • Usługi wewnętrzne za VPN - RDP, SSH, panele administracyjne i bazy danych powinny być osiągalne wyłącznie z sieci wewnętrznej lub przez VPN z uwierzytelnianiem wieloskładnikowym, a nie publicznie. Więcej w artykule Bezpieczny dostęp zdalny.
  • Porównanie stanu faktycznego z udokumentowanym - regularna weryfikacja tego, jakie usługi nasłuchują na publicznie dostępnych adresach IP, względem tego, co znajduje się w inwentaryzacji.

Zabezpieczanie usług, które muszą pozostać publiczne

Usługa, która z założenia musi być publiczna (np. serwer WWW), wymaga szczególnej ochrony. Nie wystarczy ją udostępnić - należy ją utwardzić, odseparować i monitorować. Kluczowe działania w tym zakresie obejmują:

  • DMZ i odseparowanie od sieci wewnętrznej - publiczna usługa nie może mieć swobodnego dostępu do sieci LAN. Usługi publiczne takie jak serwer WWW powinny zostać umieszczone w strefie zdemilitaryzowanej, a połączenia między DMZ oraz siecią wewnętrzną powinny być ograniczone do minimum oraz monitorowane. Więcej w artykule Separacja sieci.
  • Reverse proxy / WAF - dostęp do publicznych aplikacji webowych powinien być realizowany za pośrednictwem serwera reverse proxy, najlepiej z zaporą aplikacji webowej (WAF) filtrującą ruch i blokującą znane wzorce ataków.
  • Uwierzytelnienie wieloskładnikowe dla publicznych paneli logowania - każdy publiczny interfejs z logowaniem powinien wymagać uwierzytelnienia wieloskładnikowego.
  • Rate limiting oraz ochrona przed brute-force - usługi powinny ograniczać liczbę prób logowania z jednego adresu lub sesji, wraz z rosnącą blokadą czasową.
  • Szyfrowany ruch sieciowy - publiczne usługi webowe powinny obsługiwać wyłącznie protokół TLS w wersji 1.2 lub 1.3, posiadać poprawne certyfikaty oraz wymuszać szyfrowanie za pomocą nagłówka HSTS (HTTP Strict Transport Security).
  • Aktualizacje - nieaktualne wersje usług dostępnych publicznie, dla których istnieją znane podatności, stanowią bezpośredni wektor ataku. Więcej informacji w artykule: Dobre praktyki - Aktualizacje.
  • Hardening systemu operacyjnego - stacja, na której uruchomiona jest usługa powinna zostać poddana hardeningowi, aby ograniczyć potencjalne luki bezpieczeństwa.

Weryfikacja i utrzymanie

Usługi dostępne publicznie wymagają ciągłej weryfikacji. Zmiany konfiguracji, nowe usługi oraz migracje powodują, że rzeczywisty stan sieci odchodzi od udokumentowanego.

  • Regularne skanowanie widoczności infrastruktury z zewnątrz - porównanie tego, co realnie nasłuchuje na publicznych adresach, z tym, co jest udokumentowane w inwentaryzacji.
  • Artemis i moje.cert.pl - CERT Polska prowadzi skanowanie publicznie dostępnych systemów. Usługa dostarcza powiadomienia o wykrytych podatnościach i błędach konfiguracyjnych, a w serwisie moje.cert.pl można przejrzeć pełną listę własnej publicznej infrastruktury.
  • Przegląd listy publicznych usług przy istotnych zmianach - każda zmiana architektury, wdrożenie nowej aplikacji, migracja lub wyłączenie usługi powinno skutkować aktualizacją mapy przepływów i listy publicznych usług.
  • Monitorowanie logów publicznych usług - logi publicznych usług powinny trafiać do centralnego systemu (np. SIEM), z alertami: nietypowy ruch, wiele nieudanych prób logowań lub próby dostępu do nieistniejących ścieżek na serwerze WWW. Więcej w artykule Hardening infrastruktury - Logowanie, monitorowanie i audyt.

Więcej informacji na temat zewnętrznej powierzchni ataku:

Więcej informacji na temat usług CERT Polska:

Dobre praktyki - podsumowanie

Zalecane praktyki ograniczania publicznej ekspozycji

  • Domyślnie żadna usługa nie powinna być dostępna publicznie.
  • Dostęp publiczny powinien być zrealizowany wyłącznie do dedykowanych, wyizolowanych serwisów.
  • Należy utrzymywać aktualną listę usług publicznych i weryfikować ją względem stanu faktycznego (skanowanie z zewnątrz vs inwentaryzacja).
  • Usługi wewnętrzne nigdy nie powinny być dostępne publicznie.
  • Usługi publiczne należy umieszczać w strefie zdemilitaryzowanej, odseparowanej od sieci wewnętrznej regułami zapory. Więcej w artykule Separacja sieci.
  • Należy aktualizować na bieżąco publiczne usługi - znana luka w publicznej usłudze to wektor ataku.
  • Uwierzytelnianie wieloskładnikowe powinno być wymagane dla publicznych paneli logowania.
  • Publiczne aplikacje webowe powinny być zabezpieczone przy użyciu Reverse Proxy oraz WAF (Web Application Firewall).

  1. Zalecane jest, aby panele logowania do poczty były dostępne wyłącznie z sieci wewnętrznej lub VPN. ↩

Ostatnia aktualizacja artykułu: 2026-09-02.