Нередко я читал мнение, что держать RDP (Remote Desktop Protocol) порт открытым в Интернет — это весьма небезопасно, и делать так не надо. А надо доступ к RDP давать или через VPN, или только с определённых "белых" IP адресов.
Zarządzam kilkoma serwerami Windows dla małych firm, które zleciły mi zadanie zapewnienia zdalnego dostępu do Windows Server dla księgowych. To nowoczesny trend — praca z domu. Szybko zrozumiałem, że męczenie księgowych VPN to wdzięczne zajęcie, a zebranie wszystkich IP do białej listy jest niemożliwe, ponieważ adresy IP ludzi są dynamiczne.
Dlatego poszedłem najprostszą drogą — otworzyłem port RDP na zewnątrz. Teraz, aby uzyskać dostęp, księgowi muszą uruchomić RDP i wprowadzić nazwę hosta (wraz z portem), nazwę użytkownika i hasło.
W tym artykule podzielę się doświadczeniem (pozytywnym i nieco mniej) oraz rekomendacjami.
Ryzyka
Czym ryzykujesz otwierając port RDP?
1) Nieautoryzowany dostęp do wrażliwych danych
Если кто-то подберёт пароль к RDP, то он сможет получить данные, которые вы хотите держать приватными: состояние счетов, балансы, данные клиентов, …
2) Utrata danych
Na przykład w wyniku działania wirusa szyfrującego.
Lub celowego działania cyberprzestępcy.
3) Utrata stacji roboczej
Pracownicy muszą pracować, a system jest skompromitowany, trzeba go reinstalować / przywracać / konfigurować.
4) Kompromitacja lokalnej sieci
Jeśli cyberprzestępca uzyska dostęp do komputera z systemem Windows, to już z tego komputera uzyska dostęp do systemów, które są niedostępne z zewnątrz, z Internetu. Na przykład do udostępnionych folderów, drukarek sieciowych itp.
Miałem przypadek, kiedy serwer Windows złapał szyfrującego wirusa
i ten wirus najpierw zaszyfrował większość plików na dysku C:, a następnie zaczął szyfrować pliki na NAS w sieci. Ponieważ NAS był Synology z włączonymi migawkami, to NAS przywróciłem w 5 minut, a serwer Windows reinstalowałem od zera.
Obserwacje i Rekomendacje
Monitoruję serwery Windows za pomocą , które wysyłają logi do ElasticSearch. W Kibanie jest kilka wizualizacji, a ja dodatkowo skonfigurowałem sobie niestandardowy pulpit nawigacyjny.
Sam monitoring nie zapewnia ochrony, ale pomaga zdefiniować niezbędne kroki.
Oto niektóre obserwacje:
a) Port RDP będzie atakowany siłowo.
Na jednym z serwerów RDP ustawiłem na porcie 443 zamiast standardowego 3389, aby zamaskować się pod HTTPS. Zmiana portu na niestandardowy ma sens, ale niewielki. Oto statystyka z tego serwera:
Widać, że w ciągu tygodnia miało miejsce prawie 400 000 nieudanych prób logowania przez RDP.
Widać, że próby logowania pochodziły z 55 001 adresów IP (niektóre adresy już zablokowałem).
Narzeka się, że trzeba zainstalować fail2ban, ale
для Windows такой утилиты — нету.
Są kilka porzuconych projektów na GitHubie, które wydaje się to robią, ale nawet ich nie próbowałem instalować:
Są także płatne narzędzia, ale ich nie brałem pod uwagę.
Jeśli znasz otwarte narzędzie do tego celu — podziel się w komentarzach.
Update: W komentarzach zasugerowano, że port 443 to zły wybór, a lepiej wybrać porty wysokie (32000+), ponieważ 443 jest skanowany częściej, a zidentyfikowanie RDP na tym porcie nie stanowi problemu.
Aktualizacja: W komentarzach zasugerowano, że takie narzędzie istnieje:
b) Istnieją określone nazwy użytkowników, które preferują przestępcy
Widać, że próby logowania są oparte na słowniku z różnymi imionami.
Ale zauważyłem: znaczna część prób to używanie nazwy serwera jako loginu. Rekomendacja: nie używaj tej samej nazwy dla komputera i użytkownika. Czasami wydaje się, że nazwa serwera jest próbowana do rozpoznania: na przykład dla systemu o nazwie DESKTOP-DFTHD7C najwięcej prób logowania było z nazwą DFTHD7C:
Zatem, jeśli Twój komputer to DESKTOP-MARIA, to prawdopodobnie będą podejmowane próby logowania się jako użytkownik MARIA.
Ещё, что я заметил из логов: на большинстве систем, большинство попыток зайти — это с именем "administrator". И это неспроста, потому что во многих версиях Windows, это пользователь существует. Более того — его нельзя удалить. Это упрощает задачу для злоумышленников: вместо подбора имени и пароля нужно только подобрать пароль.
Zauważ, że system, który złapał szyfrującego miał użytkownika Administrator i hasło Murmansk#9. Nie jestem pewien, jak włamano się do tego systemu, ponieważ zacząłem monitorować to dopiero po tym incydencie, ale myślę, że atak słownikowy — jest prawdopodobny.
Jeśli użytkownika Administrator nie można usunąć, co tedy zrobić? Można zmienić jego nazwę!
Rekomendacje z tego punktu:
- nie używaj nazwy użytkownika w nazwie komputera
- upewnij się, że na systemie nie ma użytkownika Administrator
- używaj silnych haseł
W ten sposób obserwuję, jak kilka serwerów Windows jest brutalnie atakowanych przez około dwa lata, bezskutecznie.
Skąd wiem, że bezskutecznie?
Ponieważ na powyższych zrzutach ekranu widać, że są logi udanych prób dostępu przez RDP, w których znajdują się informacje:
- z jakiego IP
- z którego komputera (nazwa hosta)
- nazwa użytkownika
- informacje GeoIP
I regularnie tam zaglądam - żadnych anomalii nie stwierdzono.
Aha, jeśli z jakiegoś IP są szczególnie intensywne ataki bruteforce, to można zablokować konkretne IP (lub podsieci) w PowerShell w ten sposób:
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 BlockAha, u Elastic, oprócz Winlogbeat, jest też , który może monitorować pliki i procesy w systemie. Jest też aplikacja SIEM (Zarządzanie Informacjami i Zdarzeniami Bezpieczeństwa) w Kibanie. Próbowałem obu, ale większych korzyści nie zauważyłem - wydaje się, że Auditbeat będzie bardziej przydatny dla systemów Linux, a SIEM jak dotąd nic konkretnego mi nie pokazał.
I ostatnie zalecenia:
- twórz regularne automatyczne kopie zapasowe.
- na czas instaluj aktualizacje zabezpieczeń
Bonus: lista 50 użytkowników, którzy najczęściej próbowali zalogować się przez RDP
"user.name: Descending"
Liczba
dfthd7c (nazwa hosta)
842941
winsrv1 (nazwa hosta)
266525
ADMINISTRATOR
180678
administrator
163842
Administrator
53541
michael
23101
server
21983
steve
21936
john
21927
paul
21913
reception
21909
mike
21899
office
21888
scanner
21887
scan
21867
david
21865
chris
21860
owner
21855
manager
21852
administrateur
21841
brian
21839
administrador
21837
mark
21824
staff
21806
ADMIN
12748
ROOT
7772
ADMINISTRADOR
7325
SUPPORT
5577
SOPORTE
5418
USER
4558
admin
2832
TEST
1928
MySql
1664
Admin
1652
GUEST
1322
USER1
1179
SCANNER
1121
SCAN
1032
ADMINISTRATEUR
842
ADMIN1
525
BACKUP
518
MySqlAdmin
518
RECEPTION
490
USER2
466
TEMP
452
SQLADMIN
450
USER3
441
1
422
MANAGER
418
OWNER
410
Źródło: habr.com
