Често съм чувал мнения, че откритият RDP (Remote Desktop Protocol) порт в интернет е доста несигурен и не трябва да се прави така. Достъпът до RDP трябва да се предоставя или чрез VPN, или само от определени "бели" IP адреси.
Администрирам няколко Windows Server за малки фирми, при които задачата ми е да осигуря отдалечен достъп до Windows Server за счетоводителите. Това е съвременната тенденция - работа от вкъщи. Бързо разбрах, че да тормозя счетоводителите с VPN не е благодарно начинание и не мога да събера всички IP за белия списък, тъй като IP адресите на хората са динамични.
Затова тръгнах по най-простия път - отворих RDP порта извън мрежата. Сега за достъп счетоводителите трябва просто да стартират RDP и да въведат името на хоста (включително порта), потребителското име и паролата.
В тази статия ще споделя опит (положителен и не много) и препоръки.
Рискове
Какви са рисковете при отваряне на RDP порт?
1) Неоторизиран достъп до чувствителни данни
Ако някой познае паролата за RDP, той ще може да получи данните, които искате да запазите частни: състояние на сметките, баланси, данни на клиенти и др.
2) Загуба на данни
Например в резултат на работата на вирус-шифровач.
Или целенасоченото действие на злонамерен потребител.
3) Загуба на работна станция
Работниците трябва да работят, а системата е компрометирана, необходимо е преинсталиране / възстановяване / конфигуриране.
4) Компрометиране на локалната мрежа
Ако злонамерен потребител получи достъп до Windows компютър, той вече ще може да има достъп до системи, недостъпни от външната страна, от интернет. Например до файлови споделяния, мрежови принтери и т.н.
Имах случай, при който Windows Server улови шифровач
и този шифровач първо криптираше повечето файлове на диск C:, а след това започна да криптира файловете на NAS в мрежата. Тъй като NAS беше Synology, с настроени snapshots, възстанових NAS за 5 минути, а Windows Server преинсталирах от нулата.
Наблюдения и Препоръки
Мониторирам Windows Servers с помощта на , които изпращат логовете в ElasticSearch. В Kibana има няколко визуализации, а аз също си настроих персонализиран табло.
Самото наблюдение не защитава, но помага да се определи какви мерки са необходими.
Ето някои наблюдения:
a) RDP ще бъде брутално атакуван.
На един от сървърите, които имам, RDP е настроен не на стандартния порт 3389, а на 443 — така че да се замаскира под HTTPS. Смяната на стандартния порт вероятно е разумно, но от това не става много. Ето статистиката от този сървър:
Ясно е, че през седмицата е имало почти 400 000 неуспешни опити за влизане по RDP.
Ясно е, че опитите за влизане са били от 55 001 IP адреси (някои IP адреси вече бяха блокирани от мен).
Тук директно извира изводът, че трябва да се постави fail2ban, но
за Windows такава утилита — няма.
Съществуват няколко забравени проекта в GitHub, които уж правят това, но дори не съм ги пробвал:
Също така има платени утилити, но не съм ги разглеждал.
Ако знаете за отворена утилита за тази цел — моля, споделете в коментарите.
Актуализация: В коментарите ми подсказаха, че порт 443 — не е добър избор, а е по-добре да се избират високи портове (32000+), защото 443 се сканира по-често и няма проблем да се разпознае RDP на този порт.
Актуализация: В коментарите ми подсказаха, че такава утилита съществува:
b) Има определени имена на потребители, които злонамерените лица предпочитат.
Ясно е, че опитите за влизане стават чрез речник с различни имена.
Но ето какво забелязах: значителен брой опити — това е използването на името на сървъра като логин. Препоръка: не използвайте еднакво име за компютъра и за потребителя. Всъщност, понякога името на сървъра се опитват да се парснат: например за система с име DESKTOP-DFTHD7C, най-много опити за влизане има с името DFTHD7C:
Съответно, ако имате компютър DESKTOP-MARIA, вероятно ще има опити за влизане с потребителя MARIA.
Още нещо, което забелязах от логовете: на повечето системи, по-голямата част от опитите за влизане — това е с името "administrator". И това не е случайно, защото в много версии на Windows, този потребител съществува. Освен това — не може да бъде изтрит. Това улеснява задачата на злонамерените лица: вместо да се опитват да познаят името и паролата, те трябва само да подберат паролата.
Между другото, системата, която улавяше криптографа, имаше потребител Administrator и парола Murmansk#9. Все още не съм сигурен как е била хакната тази система, защото започнах да я наблюдавам точно след този случай, но мисля, че подбиране — е вероятно.
Така че, ако потребителят Administrator не може да бъде изтрит, какво да правим? Може да бъде преименуван!
Препоръките от тази точка:
- не използвайте името на потребителя в името на компютъра
- Убедете се, че системата не съдържа потребителя Administrator
- Използвайте надеждни пароли
По този начин наблюдавам как няколко Windows Server под моя контрол са обект на брутфорс атаки вече около два години, без успех.
Откъде знам, че без успех?
Защото на екранните снимки по-горе е видно, че има записи на успешни влизания по RDP, в които има информация:
- от кой IP
- от кой компютър (hostname)
- потребителско име
- GeoIP информация
И аз редовно проверявам там - не са открити аномалии.
Между другото, ако от някой IP брутфорсят особено настоятелно, можете да блокирате отделни IP (или подмрежи) по следния начин в 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 BlockТака също в Elastic, освен Winlogbeat, има и , който може да следи файловете и процесите в системата. Има и приложение SIEM (Управление на информацията и събитията в сигурността) в Kibana. Опитах и двете, но не видях особена полза - изглежда, че Auditbeat ще бъде по-полезен за Linux системи, а SIEM засега не ми показа нищо смислено.
И накрая, финални препоръки:
- правете редовни автоматични резервни копия.
- време на време инсталирайте Security Updates
Бонус: списък от 50 потребители, които най-често са използвани за опити за влизане по RDP
"user.name: Descending"
Брой
dfthd7c (hostname)
842941
winsrv1 (hostname)
266525
ADMINISTRATOR
180678
administrator
163842
Administrator
53541
michael
23101
сървер
21983
steve
21936
john
21927
paul
21913
reception
21909
mike
21899
office
21888
scanner
21887
scan
21867
david
21865
chris
21860
собственик
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
админ
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
Източник: habr.com
