Jeśli ktokolwiek w Twojej firmie loguje się na biurkowy komputer „z domu po numerze IP" — czyli ktoś z IT kiedyś otworzył port 3389 na routerze — to nie masz pracy zdalnej. Masz zaproszenie dla ransomware z dwuletnim wyprzedzeniem.
To nie jest straszenie. To statystyka, którą widzimy u klientów co kilka miesięcy. RDP wystawiony na publiczny adres IP to od lat numer jeden wśród wektorów wejścia atakujących do polskich MŚP. Nie phishing, nie podpięty pendrive — RDP. I to nie dlatego, że ktoś używa hasła Lato2024!. Tylko dlatego, że całe rzesze botów skanują internet 24/7 w poszukiwaniu otwartego portu 3389 i próbują na nim wszystko, co kiedykolwiek wyciekło.
Ten artykuł jest o tym, jak wygląda dziś sensowny dostęp zdalny w firmie 10–50-osobowej. Bez przesady w stronę „enterprise", bez bagatelizowania ryzyka.
Skąd się wzięło RDP na publicznym IP
Schemat jest niemal zawsze ten sam. Firma kupuje 10–15 lat temu serwer Dell albo HP, stawia na nim Windows Server, instaluje ERP (najczęściej Comarch Optima albo Subiekt GT, czasem starszy enova). Kilka osób z księgowości i handlu loguje się przez RDP. Przez lata działa.
Potem przychodzi covid albo pierwsze dziecko handlowca i okazuje się, że ludzie muszą logować się z domu. Informatyk — własny albo z zewnątrz — pyta o budżet, słyszy „minimalny", więc otwiera port 3389 na routerze i pokazuje, jak wpisać nazwafirmy.dyndns.org:3389 w kliencie RDP. Wszystko działa. Trzy lata wszystko działa.
Aż któregoś dnia w sobotę rano ktoś nie może otworzyć żadnego pliku, bo wszystkie kończą się na .lockbit3 albo .akira. Drogą obowiązkową są wtedy backupy (jeśli są) i pięć dni przerwy w pracy.
Co tak naprawdę jest źle
Problem nie polega na tym, że RDP jest złym protokołem. Microsoft go aktywnie utrzymuje, jest szyfrowany. Problem polega na trzech rzeczach:
- Publiczna ekspozycja sesji autoryzacyjnej. Każdy bot świata może próbować się logować. Nawet jeśli masz długie hasła i konta zablokowane po 10 próbach, ataki credential stuffing (wycieknięte loginy z innych serwisów) skutecznie omijają takie zabezpieczenia.
- Bezpośredni dostęp do warstwy systemu operacyjnego. Atakujący po zalogowaniu od razu jest na serwerze, na którym stoi ERP, baza danych, udziały plikowe. Nie ma żadnej warstwy pośredniej, która mogłaby spowolnić jego ruch boczny.
- Brak MFA jako standardu. Goły RDP nie wymusza drugiego składnika. Da się to dorobić (Duo, Azure MFA dla RDP), ale w 9 na 10 przypadków, które oglądamy u klientów, nie jest dorobione.
Dla porównania — kiedy ktoś loguje się przez sensowny VPN albo ZTNA, najpierw musi przejść uwierzytelnienie do bramy (z MFA), dopiero potem widzi cokolwiek z sieci wewnętrznej. To dwie zupełnie różne ligi ryzyka.
Trzy ścieżki, które mają sens dla MŚP
Nie ma jednego dobrego rozwiązania. Są trzy, z różnym profilem kosztu, złożoności i jakości życia użytkownika.
Ścieżka 1 — klasyczny VPN do routera/firewalla. Najczęściej WireGuard albo OpenVPN postawiony na sensownym routerze brzegowym (Mikrotik, Fortigate, Sophos, pfSense, OPNsense). Użytkownik łączy klienta VPN, dostaje wewnętrzny adres IP, używa firmy „jakby siedział w biurze". Tanie, sprawdzone, w pełni pod Twoją kontrolą. Wymaga dyscypliny przy zarządzaniu kontami i kluczami — szczególnie przy odejściach pracowników.
Ścieżka 2 — ZTNA / mesh VPN (Tailscale, Cloudflare WARP, Twingate). Nowsze podejście, w którym nie wystawiasz w ogóle żadnego portu na świat. Każde urządzenie łączy się z dostawcą, autoryzuje się przez Twoje konto firmowe (Microsoft 365 / Google Workspace), i dopiero potem dostaje dostęp do konkretnych zasobów. Konfiguracja prostsza niż klasyczny VPN, MFA „za darmo" z poziomu IdP. Koszt zwykle 5–8 USD/użytkownika/miesiąc.
Ścieżka 3 — RD Gateway + MFA. Jeśli z różnych powodów musisz zostać przy RDP (np. kluczowy program legacy wymaga konkretnego ustawienia sesji), postaw przed serwerem maszynę z rolą Remote Desktop Gateway i wymuś MFA. Port 3389 zostaje zamknięty, użytkownicy łączą się na port 443 z certyfikatem TLS. To minimum przyzwoitości, jeśli RDP musi zostać.
W przeważającej większości firm 10–50-osobowych, które dziś budujemy od nowa, idziemy ścieżką 2 lub 1. Trzecia ma sens głównie tam, gdzie ktoś musi zostawić istniejącą infrastrukturę i zmiana ma być punktowa.
Przykład z życia
U jednego z naszych klientów — 28-osobowej firmy handlowej z branży elektrycznej, używającej Comarch Optima i kilku aplikacji magazynowych — sytuacja wyjściowa była podręcznikowa. Serwer w serwerowni-szafie pod schodami, port 3389 otwarty z dyndns-em w nazwie, dziesięcioro ludzi logowało się „z domu po piątkach", hasła ostatnio zmieniano w 2021.
Po włamaniu (LockBit, weekend, wszystko zaszyfrowane) odbudowa zajęła 6 dni, z czego pierwsze 36 godzin firma w ogóle nie wiedziała, czy backup jest sprawny — kopie były robione lokalnie na drugim dysku tego samego serwera, kopia offsite na NAS w siedzibie, którą atakujący też zaszyfrowali. Bezpośrednie straty (utracone marże, koszty pracy, koszty przywrócenia, klient, który odszedł) zamknęły się w okolicach 180 tysięcy złotych.
Przebudowa po incydencie kosztowała mniej. Zamknięcie portu 3389, postawienie Tailscale z autoryzacją przez Microsoft 365 i wymuszeniem MFA, backup w schemacie 3-2-1 z kopią immutable poza siedzibą — całość zamknęła się w 17 tysiącach złotych za prace projektowe i pierwszym rocznym koszcie subskrypcji rzędu 6 tysięcy złotych. Czas wdrożenia: 9 dni roboczych, w tym tydzień na płynne przejście użytkowników na nowy sposób logowania.
Można było to zrobić rok wcześniej. Wtedy by się też zwróciło, tylko bez nauki przez ból.
Co konkretnie zrobić w przyszłym tygodniu
Niezależnie od tego, którą ścieżką pójdziesz docelowo, te kroki możesz zrobić od razu:
- Zinwentaryzuj, co jest wystawione na świat. Sprawdź z zewnątrz (np.
shodan.iona publiczne IP firmy albo prosty skan portów), czy 3389, 5900 (VNC), 22 (SSH) nie świecą. Jeśli świecą — wyłącz dziś wieczorem. - Sprawdź, kto i jak loguje się zdalnie. Czy masz listę osób mających dostęp? Czy wiesz, co dokładnie robią — biuro? plik? cały serwer? To pierwszy krok do mądrego ograniczenia.
- Włącz MFA wszędzie, gdzie się da. Microsoft 365, Google Workspace, ERP w chmurze, bank. To 80% ochrony za 5% kosztu.
- Sprawdź backup po naszemu — testem odtworzenia, nie poleceniem „pokaż zieloną ikonę". Jeśli nigdy nie odtworzyłeś dokumentu z kopii, nie wiesz, czy ją masz.
Jeśli to brzmi jak rozmowa, którą warto przeprowadzić zanim, a nie po — możemy ją zacząć na trzydziestominutowym spotkaniu, bez obietnic, że „kupisz coś u nas".
RDP na publicznym IP to dziś nie jest „oszczędne rozwiązanie". To dług, który prędzej czy później oddasz w bardzo niewygodnym momencie.