Często spotykałem się z opinią, że utrzymywanie portu RDP (Remote Desktop Protocol) otwartego na Internet jest bardzo niebezpieczne i nie powinno się tak robić. Musisz jednak zapewnić dostęp do RDP albo przez VPN, albo tylko z określonych „białych” adresów IP.
Administruję kilkoma serwerami Windows Server w małych firmach, gdzie powierzono mi zadanie zapewnienia księgowym zdalnego dostępu do systemu Windows Server. To nowoczesny trend – praca z domu. Dość szybko zdałem sobie sprawę, że dręczenie księgowych VPN jest niewdzięcznym zadaniem, a zbieranie wszystkich adresów IP do białej listy nie powiedzie się, ponieważ adresy IP ludzi są dynamiczne.
Dlatego wybrałem najprostszą drogę - przekierowałem port RDP na zewnątrz. Aby uzyskać dostęp, księgowi muszą teraz uruchomić protokół RDP i wprowadzić nazwę hosta (łącznie z portem), nazwę użytkownika i hasło.
W tym artykule podzielę się swoimi doświadczeniami (pozytywnymi i mniej pozytywnymi) oraz rekomendacjami.
Ryzyko
Czym ryzykujesz otwierając port RDP?
1) Nieuprawniony dostęp do danych wrażliwych
Jeśli ktoś odgadnie hasło RDP, będzie mógł uzyskać dane, które chcesz zachować dla siebie: stan konta, salda, dane klientów, ...
2) Utrata danych
Na przykład w wyniku wirusa ransomware.
Lub celowe działanie napastnika.
3) Utrata stanowiska pracy
Pracownicy muszą pracować, ale system jest zagrożony i należy go ponownie zainstalować/przywrócić/skonfigurować.
4) Kompromis w sieci lokalnej
Jeśli atakujący uzyska dostęp do komputera z systemem Windows, to z tego komputera będzie mógł uzyskać dostęp do systemów niedostępnych z zewnątrz, z Internetu. Na przykład do udziałów plików, drukarek sieciowych itp.
Miałem przypadek, w którym system Windows Server złapał oprogramowanie ransomware
i to oprogramowanie ransomware najpierw zaszyfrowało większość plików na dysku C:, a następnie rozpoczęło szyfrowanie plików na serwerze NAS przez sieć. Ponieważ serwerem NAS była firma Synology ze skonfigurowanymi migawkami, przywróciłem serwer NAS w 5 minut i ponownie zainstalowałem system Windows Server od zera.
Obserwacje i zalecenia
Monitoruję serwery Windows za pomocą , które wysyłają logi do ElasticSearch. Kibana ma kilka wizualizacji, skonfigurowałem także niestandardowy dashboard.
Sam monitoring nie chroni, ale pomaga określić niezbędne środki.
Oto kilka obserwacji:
a) RDP będzie brutalnie wymuszony.
Na jednym z serwerów zainstalowałem RDP nie na standardowym porcie 3389, ale na 443 - cóż, przebiorę się za HTTPS. Pewnie warto zmienić port ze standardowego, ale niewiele to da. Oto statystyki z tego serwera:
Widać, że w ciągu tygodnia odbyło się prawie 400 000 nieudanych prób zalogowania się poprzez RDP.
Widać, że były próby logowania z 55 001 adresów IP (niektóre adresy IP były już przeze mnie blokowane).
To bezpośrednio sugeruje wniosek, że musisz ustawić Fail2ban, ale
Nie ma takiego narzędzia dla systemu Windows.
Na Githubie jest kilka porzuconych projektów, które wydają się to robić, ale nawet nie próbowałem ich instalować:
Istnieją również płatne narzędzia, ale nie brałem ich pod uwagę.
Jeśli znasz narzędzie typu open source służące do tego celu, udostępnij je w komentarzach.
Aktualizacja: W komentarzach sugerowano, że port 443 to zły wybór i lepiej wybierać porty wysokie (32000+), ponieważ 443 jest skanowany częściej, a rozpoznanie protokołu RDP na tym porcie nie stanowi problemu.
b) Istnieją pewne nazwy użytkowników preferowane przez atakujących
Można zauważyć, że wyszukiwanie odbywa się w słowniku o różnych nazwach.
Ale oto, co zauważyłem: znaczna liczba prób wykorzystuje nazwę serwera jako login. Zalecenie: Nie używaj tej samej nazwy komputera i użytkownika. Co więcej, czasami wygląda to tak, jakby próbowali w jakiś sposób przeanalizować nazwę serwera: na przykład w przypadku systemu o nazwie DESKTOP-DFTHD7C najwięcej prób logowania odbywa się za pomocą nazwy DFTHD7C:
W związku z tym, jeśli posiadasz komputer DESKTOP-MARIA, prawdopodobnie będziesz próbował zalogować się jako użytkownik MARIA.
Kolejna rzecz, którą zauważyłem w logach: w większości systemów większość prób logowania odbywa się pod nazwą „administrator”. I nie dzieje się tak bez powodu, ponieważ w wielu wersjach systemu Windows taki użytkownik istnieje. Co więcej, nie można go usunąć. Upraszcza to zadanie atakującym: zamiast zgadywać nazwę i hasło, wystarczy odgadnąć hasło.
Nawiasem mówiąc, system, który przechwycił ransomware, miał użytkownika Administrator i hasło Murmańsk#9. Nadal nie jestem pewien, w jaki sposób doszło do zhakowania tego systemu, ponieważ zacząłem monitorować zaraz po tym incydencie, ale myślę, że przesada jest prawdopodobna.
Jeśli więc nie można usunąć użytkownika Administrator, co należy zrobić? Możesz zmienić jego nazwę!
Zalecenia z tego akapitu:
- nie używaj nazwy użytkownika w nazwie komputera
- upewnij się, że w systemie nie ma użytkownika Administrator
- używaj silnych haseł
Tak więc od około kilku lat obserwuję, jak kilka serwerów Windows znajdujących się pod moją kontrolą było poddawanych brutalnemu wymuszeniu, ale bez powodzenia.
Skąd mam wiedzieć, że się nie udało?
Ponieważ na powyższych zrzutach ekranu widać, że znajdują się logi udanych wywołań RDP, które zawierają informacje:
- z którego IP
- z jakiego komputera (nazwa hosta)
- имя пользователя
- Informacje o GeoIP
A zaglądam tam regularnie – żadnych nieprawidłowości nie stwierdziłem.
Nawiasem mówiąc, jeśli konkretny adres IP jest szczególnie mocno wymuszany metodą brute-force, możesz zablokować poszczególne adresy IP (lub podsieci) w ten sposób w PowerShell:
New-NetFirewallRule -Direction Inbound -DisplayName "fail2ban" -Name "fail2ban" -RemoteAddress ("185.143.0.0/16", "185.153.0.0/16", "193.188.0.0/16") -Action BlockNawiasem mówiąc, Elastic, oprócz Winlogbeat, ma również , który może monitorować pliki i procesy w systemie. W Kibanie dostępna jest również aplikacja SIEM (Security Information & Event Management). Wypróbowałem oba, ale nie widziałem zbyt wielu korzyści - wygląda na to, że Auditbeat będzie bardziej przydatny w systemach Linux, a SIEM nie pokazał mi jeszcze niczego zrozumiałego.
Cóż, ostateczne zalecenia:
- Wykonuj regularne automatyczne kopie zapasowe.
- instaluj aktualizacje zabezpieczeń w odpowiednim czasie
Bonus: lista 50 użytkowników, którzy najczęściej byli wykorzystywani do prób logowania RDP
„nazwa użytkownika: malejąco”
Liczyć
dfthd7c (nazwa hosta)
842941
winsrv1 (nazwa hosta)
266525
ADMINISTRATOR
180678
administrator
163842
Administrator
53541
michael
23101
serwer
21983
steve
21936
Jan
21927
Paul
21913
recepcja
21909
mikrofon
21899
biuro
21888
Skaner
21887
skanować
21867
david
21865
chris
21860
właściciel
21855
kierownik
21852
administrateur
21841
Brian
21839
administrator
21837
znak
21824
personel
21806
ADMIN
12748
ROOT
7772
ADMINISTRATOR
7325
WSPIERAJ
5577
WSPARCIE
5418
USER
4558
Admin
2832
TESTOWANIE
1928
MySql
1664
Admin
1652
GOŚĆ
1322
UŻYTKOWNIK1
1179
SKANER
1121
SCAN
1032
ADMINISTRATOR
842
ADMINISTRATOR 1
525
BACKUP
518
Administrator MySql
518
ODBIÓR
490
UŻYTKOWNIK2
466
TEMP
452
SQLADMIN
450
UŻYTKOWNIK3
441
1
422
MANAGER
418
WŁAŚCICIEL
410
Źródło: www.habr.com