Нярэдка я чытаў меркаванне, што трымаць 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 няўдалых спроб зайсці па RDP.
Відаць, што спробы зайсці былі з 55 IP адрасоў (некаторыя IP адрасы ўжо былі заблакаваныя мной).
Тут прама напрошваецца выснова аб тым, што трэба ставіць fail2ban, але
для Windows такой утыліты – няма.
Ёсць пара закінутых праектаў на Гітхабе, якія быццам бы гэта робяць, але я нават не спрабаваў іх ставіць:
Яшчэ ёсць платныя ўтыліты, але я іх не разглядаў.
Калі вы ведаеце адкрытую ўтыліту для гэтай мэты - падзяліцеся ў каментарах.
абнаўленне: У каментарах падказалі, што порт 443 - няўдалы выбар, а лепш выбіраць высокія парты (32000+), таму што 443 скануецца часцей, і распазнаць RDP на гэтым порце - не праблема.
b) Ёсць пэўныя username, якія зламыснікі аддаюць перавагу
Відаць, што перабор ідзе па слоўніку з рознымі імёнамі.
Але вось што я заўважыў: значная колькасць спроб - гэта выкарыстанне імя сервера, як лагіна. Рэкамендацыя: не выкарыстоўвайце аднолькавае імя для кампутара і для карыстальніка. Прычым, часам падобна імя сервера спрабуюць неяк распарсіць: напрыклад для сістэмы з імем 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 (Security Information & Event Management) дадатак у Kibana. Я спрабаваў і тое і іншае, але карысці асоба не ўбачыў - падобна Auditbeat будзе больш карысны для Linux сістэм, а SIEM нічога выразнага мне пакуль не паказаў.
Ну і фінальныя рэкамендацыі:
- рабіце рэгулярныя аўтаматычныя бэкапы.
- своечасова стаўце Security Updates
Бонус: спіс з 50 карыстальнікаў, якія часцей выкарыстоўваліся для спроб уваходу па RDP
"user.name: Descending"
Лічыць
dfthd7c (hostname)
842941
winsrv1 (hostname)
266525
Адміністратара
180678
адміністратар
163842
адміністратар
53541
Майкл
23101
сервер
21983
Стыў
21936
Джон
21927
падлогу
21913
прыём
21909
мікрафон
21899
офіс
21888
сканар
21887
сканаванне
21867
Дэвід
21865
Крыс
21860
ўладальнік
21855
менеджэр
21852
Administrateur
21841
Браян
21839
адміністратар
21837
пазначыць
21824
персанал
21806
ADMIN
12748
ROOT
7772
АДМІНІСТРАДАР
7325
ПАДТРЫМКА
5577
ПАДТРЫМКА
5418
USER
4558
адмін
2832
TEST
1928
MySql
1664
адміністратар
1652
ГАСЦЯВАЯ
1322
КАРЫСТАЛЬНІК1
1179
СКАНЕР
1121
SCAN
1032
АДМІНІСТРАТАР
842
ADMIN1
525
BACKUP
518
MySqlAdmin
518
ПРЫЯМ
490
КАРЫСТАЛЬНІК2
466
TEMP
452
SQLADMIN
450
КАРЫСТАЛЬНІК3
441
1
422
Менеджэр
418
УЛАДАЛЬНІК
410
Крыніца: habr.com