Zabezpieczenie RDP

Remote Desktop Protocol

Wiemy. Wiemy co sobie można pomyśleć… co za kretyn wystawia RDP? A już publicznie do internetu?? Kretyn do kwadratu. To się nie godzi. To nawet bezpieczne nie jest. Tak – my to wiemy i rozumiemy, jednak czasem… nie ma innego wyjścia. Poza tym – wirtualne maszyny w Azure – też są wystawiane publicznie do internetu i jakoś jeszcze świat się nie zawalił. Tak więc – czy RDP da się zabezpieczyć, aby zminimalizować ilość ataków?

RDP JEST NAJMNIEJ BEZPIECZNYM SPOSOBEM UZYSKANIA DOSTĘPU DO ZDALNEGO HOSTA PRACUJĄCEGO POD KONTROLĄ SYSTEMU WINDOWS. WYSTAWIENIE DOSTEPU DO HOSTA PRZEZ RDP DO INTERNETU ZAWSZE NELEŻY TRAKTOWAĆ JAKO OSTATECZNĄ OSTATECZNOŚĆ. ABSOLUTNIE NIE POLECAMY. JEŚLI JEDNAK NIE MA INNEJ MOŻLIWOŚCI OTO KILKA PORAD JAK EFEKTYWNIE ZABEZPIECZYĆ RDP CHOĆBY W MINIMALNY SPOSÓB.

Od czego zacząć zabezpieczanie RDP?

Od zadania sobie pytania – czy na pewno RDP musi zostać udostępnione publicznie? Czy nie można tego poprzedzić podłączeniem się do VPNa? Jeśli jednak wystawienie RDP do publicznego Internetu jest konieczne, to należy dołożyć wszelkich starań do tego, aby RDP był jak najlepiej zabezpieczony. Będzie to proces złożony, uzależniony od zasobności portfela i woli walki z zagrożeniami.

Zacząć trzeba od najprostszych rzeczy i najbardziej oczywistych rzeczy – zaktualizowania systemu operacyjnego do możliwie najnowszego, a najlepiej do najnowszego. Tak, wiem bywają poprawki, które więcej psuja niż naprawiają, jednak nadal – poprawki z Windows Update to podstawa. Warto je wykonywać za każdym razem gdy Microsoft wypuszcza nowe poprawki – czyli każdy drugi wtorek miesiąca, a czasem także czwarty wtorek w danym miesiącu. Jeśli poprawki zostały zainstalowane, a serwer szczęśliwie podniósł się po restarcie – pora na kolejny podstawowy krok: zmiana domyślnego portu usługi RDP – 3389 na inny. Eliminuje to około 90% domorosłych script kiddies i tyleż samo skanerów portów. Oczywiście, warto założyć, że te pozostałe 10% skanuje i tak wszystkie porty także pod kątem dostępności RDP. Jednak zmiana portu to drugi stopień do zminimalizowania liczby ataków.

Zmiana domyślnego portu RDP nie jest zbyt trudna i wymaga zmiany wpisu w rejestrze systemu Windows – gdzie szukamy następującej ścieżki:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tdp

Znajdziemy tam wartość PortNumber, którą należy zmienić z domyślnego 3389 na coś innego. Oczywiście jest też wersja dla normalnych administratorów – one-liner w PowerShell:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name PortNumber -Value 43389

Czy Windows Firewall działa?

A pewnie, jeszcze jak! Można śmiało powiedzieć, że jest tak samo skuteczny jak każdy inny firewall jaki znamy 😉 Zmiana portu na którym działa usługa RDP niesie za sobą kilka innych potrzebnych akcji właśnie po stronie wbudowanego firewalla:

  • wyłączenie domyślnej reguły firewall dla RDP:
    Tu już nie będziemy dużo kombinować i zrobimy to jak ludzie w PowerShellu:
    Disable-NetFirewallRule -DisplayGroup "Remote Desktop"
  • stworzenie nowej reguły ze zmienionym portem:
    New-NetFirewallRule -DisplayName "RDP_43389" -Direction "Inbound" -Action "Allow" -Protocol TCP -LocalPort 43389

Najlepszym oczywiście sposobem będzie ustawienie powyższej reguły pozwalającej na połączenie się z RDP tylko z jednego konkretnego adresu IP (wystarczy podać prawidłowy adres IP w miejsce ADRES.IP):

New-NetFirewallRule -DisplayName "RDP_43389" -Direction "Inbound" -Action "Allow" -Protocol TCP -LocalPort 43389 -RemoteAddress ADRES.IP

Tak działa idealny świat – każdy ma stałe IP i jesteśmy w stanie przygotować odpowiednie reguły dla takich adresów. Niestety – rzeczywistość jest bardzo odległa od takiego stanu rzeczy. Nadal dynamiczne publiczne adresy są oczywiście bardzo popularne i gdy nasi użytkownicy korzystają z takich rozwiązań – trzeba przygotować coś odpowiedniego. Dodam tylko iż najczęstszym atakiem oczywiście będzie próba zgadywania nazwy użytkownika oraz jego hasła.

Skoro już o użytkownikach mowa – dość rozsądnym wydaje się pozbycie nazwy domyślnego administratora komputera – konta o swojsko brzmiącej nazwie „Administrator”. Nie jest głupim pomysłem także wyłączenie tego konta, ale nie jego usunięcie. Kto zgadnie dlaczego?

Rename-LocalUser -Name "Administrator" -NewName "FoxMulder"
Disable-LocalUser -Name "FoxMulder"

Warto zaznaczyć, że dla routera – RDP jest „bezstanowy” – żaden router bez zaawansowanych narzędzi typu IDS/IPS nie wykryje nieudanych prób logowania. Czy można sobie z tym jakoś poradzić? Oczywiście – Windows ma przecież wbudowany firewall, który jest tak samo skuteczny jak każdy inny firewall. Niestety – trzeba tutaj trochę zakasać rękawy, ale czego się nie robi dla poprawy bezpieczeństwa. Zaczniemy od stworzenia reguły odrzucającej połaczenia z niechcianych IP. Zanim jednak przejdziemy dalej – jeśli w regule zezwalającej na łączenie się ze zmenionym portem podaliśmy jedno konkretne zdalne IP – musimy ten adres w tym momencie uwzględnić. Reguła bowiem będzie wyglądać inaczej dla sytuacji gdy mamy do czynienia ze stałym adresem IP klienta/użytkownika, a inaczej gdy musimy zezwolić wszystkim, a blokować tylko atakujących:

New-NetFirewallRule -DisplayName "BlackList" -Direction Inbound -Action Block -LocalPort Any -RemotePort Any

Teraz potrzebny będzie automat wykrywający nieudane próby logowania i dokładania adresu IP adwersarzy do reguły stworzonej poprzednio. Chcemy jednak aby automat był najbardziej skuteczny jak to tylko możliwe. Windows niestety nie posiada narzędzia jakiego potrzeba do zrywania połączeń TCP/IP. Będziemy się więc posiłkować narzędziem CurrPorts od NirSoft, które doskonale nadaje się do zamykania połączeń sieciowych bezpośrednio z linii komend, a tego właśnie potrzebujemy. Jako automat proponuję prosty skrypt w PowerShellu, który zrobi co trzeba i wyśle maila (oczywiście opcjonalnie) gdzie trzeba:

$CheckEvent = $null
$ReportTime = Get-Date -format "dd-MMM-yyyy HH:mm"
$MailFrom = "rdp_blocker@spece.it"
$MailTo = "noc@spece.it"
$MailSubject = "IP that tried to brute force RDP " + $ReportTime
$SmtpServer = "IP.SMTP"
$CheckEvent = Get-WinEvent -FilterHashTable @{ logname='Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational'; id=140 } -MaxEvents 1 | Select TimeCreated, Message
$MessageEvent = $CheckEvent.Message.ToString()
$IP = $MessageEvent.Split(' ')[11]
$drop_args = ' /RunAsAdmin /close * * ' + $IP + ' *'
$drop_exe = 'Path\To\cports.exe'
$drop_command = $drop_exe + $drop_args
Invoke-Command -ScriptBlock {$drop_command}
$BlackList = @((Get-NetFirewallRule -DisplayName "BlackList" | Get-NetFirewallAddressFilter).RemoteAddress)
$AddIP = $BlackList + $IP
Set-NetFirewallRule -DisplayName "BlackList" -RemoteAddress $AddIP
$MailBody = "Following IP was added to Balcklist on RDP " + $IP
Send-MailMessage -To $MailTo -From $MailFrom -Subject $MailSubject -Body $MailBody -SmtpServer $SmtpServer

To jednak nie wszystko, ponieważ powyższy skrypt trzeba jeszcze przypiąć do odpowiedniego zdarzenia w systemie. Zaglądamy więc do Event Viewer odszukujemy Windows Logs -> Security i tam przypinamy wywołanie powyższego skryptu do zdarzenia z Event ID 4625 „Audit Failure”.

Pewnie da się to zrobić jeszcze lepiej, więc jeśli masz jakieś uwagi i pytania to wiesz co robić.

Piotr Berent

Piotr Berent od 2002 w pocie czoła pracujący w środowisku IT, obecnie freelancer - Inżynier Systemowy. Entuzjasta wirtualizacji, automatyzacji i rozwiązań opartych o narzędzia open-source.

7 komentarzy

  1. Geronimo pisze:

    A ja właśnie w ten sposób udostępniam pracę zdalną naszym technicznie niestety słabo zaawansowanym pracownikom (pozdrawiam Humanistów ;)). Z tym, że pracownik najpierw musi mi podać z rana swój zewnętrzny adres IP i wpuszczam ruch na RDP w firewallu całej sieci tylko dla tego adresu.

    • Piotr Berent pisze:

      I to jest słuszna droga – jednak i tak polecam stosowanie VPNa – niebawem przedstawię kilka rozwiązań darmowych lub za małe pięniądze 🙂

  2. Geronimo pisze:

    Co do VPN… będą też wersje dla typowych humanistów? 😉

    • Piotr Berent pisze:

      Zawsze staramy się pisać nasze porady jak najbardziej prosto z możliwie dokładnie opisaniem całego procesu, aby nawet niewprawnego czytelnika poprowadzić „za rączkę” 🙂

  3. Marcin pisze:

    No o pięknie

  4. samsabat pisze:

    Dzięki za informację. Przystępnie.

  5. Leszek pisze:

    niebawem przedstawię kilka rozwiązań darmowych lub za małe pieniądze – Czekam na Pana propozycję

Leave a Reply