Madalas kong nabasa ang opinyon na ang pagpapanatiling bukas ng RDP (Remote Desktop Protocol) port sa Internet ay lubhang hindi ligtas at hindi dapat gawin. Ngunit kailangan mong magbigay ng access sa RDP alinman sa pamamagitan ng VPN, o mula lamang sa ilang "puting" IP address.
Pinangangasiwaan ko ang ilang Windows Server para sa maliliit na kumpanya kung saan ako ay naatasang magbigay ng malayuang pag-access sa Windows Server para sa mga accountant. Ito ang modernong uso - nagtatrabaho mula sa bahay. Medyo mabilis, napagtanto ko na ang pagpapahirap sa mga accountant ng VPN ay isang walang pasasalamat na gawain, at ang pagkolekta ng lahat ng mga IP para sa puting listahan ay hindi gagana, dahil ang mga IP address ng mga tao ay pabago-bago.
Samakatuwid, kinuha ko ang pinakasimpleng ruta - ipinasa ang RDP port sa labas. Upang makakuha ng access, kailangan na ngayon ng mga accountant na patakbuhin ang RDP at ilagay ang hostname (kabilang ang port), username at password.
Sa artikulong ito ibabahagi ko ang aking karanasan (positibo at hindi masyadong positibo) at mga rekomendasyon.
Mga panganib
Ano ang iyong nanganganib sa pagbubukas ng RDP port?
1) Hindi awtorisadong pag-access sa sensitibong data
Kung nahulaan ng isang tao ang password ng RDP, makakakuha sila ng data na gusto mong panatilihing pribado: status ng account, balanse, data ng customer, ...
2) Pagkawala ng data
Halimbawa, bilang resulta ng isang ransomware virus.
O sadyang aksyon ng isang umaatake.
3) Pagkawala ng workstation
Kailangang magtrabaho ng mga manggagawa, ngunit nakompromiso ang system at kailangang muling i-install/i-restore/i-configure.
4) Pagkompromiso ng lokal na network
Kung ang isang umaatake ay nakakuha ng access sa isang Windows computer, kung gayon mula sa computer na ito ay maa-access niya ang mga system na hindi naa-access mula sa labas, mula sa Internet. Halimbawa, upang mag-file ng mga pagbabahagi, sa mga printer sa network, atbp.
Nagkaroon ako ng kaso kung saan nakuha ng Windows Server ang isang ransomware
at ang ransomware na ito ay unang nag-encrypt ng karamihan sa mga file sa C: drive at pagkatapos ay nagsimulang i-encrypt ang mga file sa NAS sa network. Dahil ang NAS ay Synology, na may mga snapshot na na-configure, na-restore ko ang NAS sa loob ng 5 minuto, at muling na-install ang Windows Server mula sa simula.
Mga Obserbasyon at Rekomendasyon
Sinusubaybayan ko ang Windows Servers gamit , na nagpapadala ng mga log sa ElasticSearch. May ilang visualization si Kibana, at nag-set up din ako ng custom na dashboard.
Ang pagsubaybay mismo ay hindi nagpoprotekta, ngunit nakakatulong ito na matukoy ang mga kinakailangang hakbang.
Narito ang ilang mga obserbasyon:
a) Ang RDP ay magiging malupit na sapilitang.
Sa isa sa mga server, nag-install ako ng RDP hindi sa karaniwang port 3389, ngunit sa 443 - mabuti, itatago ko ang aking sarili bilang HTTPS. Malamang na sulit na baguhin ang port mula sa karaniwang isa, ngunit hindi ito makakabuti. Narito ang mga istatistika mula sa server na ito:
Makikita na sa loob ng isang linggo ay may halos 400 na hindi matagumpay na pagtatangka na mag-log in sa pamamagitan ng RDP.
Makikita na may mga pagtatangka na mag-log in mula sa 55 IP address (ang ilang mga IP address ay na-block ko na).
Direktang iminumungkahi nito ang konklusyon na kailangan mong itakda ang fail2ban, ngunit
Walang ganoong utility para sa Windows.
Mayroong ilang mga inabandunang proyekto sa Github na tila ginagawa ito, ngunit hindi ko pa nasubukang i-install ang mga ito:
Mayroon ding mga bayad na utility, ngunit hindi ko ito isinasaalang-alang.
Kung may alam kang open source na utility para sa layuning ito, mangyaring ibahagi ito sa mga komento.
Mga update: Iminungkahi ng mga komento na ang port 443 ay isang masamang pagpipilian, at mas mahusay na pumili ng matataas na port (32000+), dahil ang 443 ay mas madalas na na-scan, at ang pagkilala sa RDP sa port na ito ay hindi isang problema.
I-update: Iminungkahi ng mga komento na mayroong ganoong utility:
b) Mayroong ilang mga username na mas gusto ng mga umaatake
Makikita na ang paghahanap ay isinasagawa sa isang diksyunaryo na may iba't ibang pangalan.
Ngunit narito ang napansin ko: isang makabuluhang bilang ng mga pagtatangka ay gumagamit ng pangalan ng server bilang isang pag-login. Rekomendasyon: Huwag gumamit ng parehong pangalan para sa computer at sa user. Bukod dito, kung minsan ay mukhang sinusubukan nilang i-parse ang pangalan ng server kahit papaano: halimbawa, para sa isang system na may pangalang DESKTOP-DFTHD7C, ang karamihan sa mga pagtatangka na mag-log in ay may pangalang DFTHD7C:
Alinsunod dito, kung mayroon kang isang DESKTOP-MARIA na computer, malamang na susubukan mong mag-log in bilang user ng MARIA.
Isa pang bagay na napansin ko mula sa mga log: sa karamihan ng mga system, karamihan sa mga pagtatangka na mag-log in ay may pangalang "administrator". At hindi ito walang dahilan, dahil sa maraming bersyon ng Windows, umiiral ang user na ito. Bukod dito, hindi ito matatanggal. Pinapasimple nito ang gawain para sa mga umaatake: sa halip na hulaan ang isang pangalan at password, kailangan mo lamang hulaan ang password.
Siyanga pala, ang system na nakahuli ng ransomware ay mayroong User Administrator at ang password na Murmansk#9. Hindi pa rin ako sigurado kung paano na-hack ang system na iyon, dahil nagsimula akong magmonitor pagkatapos lang ng insidenteng iyon, ngunit sa tingin ko ay malamang na mag-overkill.
Kaya kung hindi matatanggal ang Administrator user, ano ang dapat mong gawin? Maaari mong palitan ang pangalan nito!
Mga rekomendasyon mula sa talatang ito:
- huwag gamitin ang username sa pangalan ng computer
- siguraduhin na walang Administrator user sa system
- gumamit ng malalakas na password
Kaya, ako ay nanonood ng ilang mga Windows Server sa ilalim ng aking kontrol na malupit-sapilitang para sa tungkol sa ilang taon na ngayon, at walang tagumpay.
Paano ko malalaman na hindi ito matagumpay?
Dahil sa mga screenshot sa itaas makikita mo na may mga log ng matagumpay na mga tawag sa RDP, na naglalaman ng impormasyon:
- galing saang IP
- saang computer (hostname)
- ΠΈΠΌΡ ΠΏΠΎΠ»ΡΠ·ΠΎΠ²Π°ΡΠ΅Π»Ρ
- Impormasyon sa GeoIP
At regular akong nagsusuri doon - walang nakitang anomalya.
Sa pamamagitan ng paraan, kung ang isang partikular na IP ay partikular na pinipilit, maaari mong harangan ang mga indibidwal na IP (o mga subnet) tulad nito sa 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 BlockSa pamamagitan ng paraan, ang Elastic, bilang karagdagan sa Winlogbeat, ay mayroon din , na maaaring subaybayan ang mga file at proseso sa system. Mayroon ding SIEM (Security Information & Event Management) application sa Kibana. Sinubukan ko pareho, ngunit wala akong nakitang malaking pakinabang - mukhang mas magiging kapaki-pakinabang ang Auditbeat para sa mga Linux system, at wala pang naipapakita sa akin ang SIEM na anumang bagay na mauunawaan.
Well, huling mga rekomendasyon:
- Gumawa ng regular na awtomatikong pag-backup.
- i-install ang Mga Update sa Seguridad sa isang napapanahong paraan
Bonus: listahan ng 50 user na madalas na ginagamit para sa mga pagtatangka sa pag-log in sa RDP
"user.name: Pababa"
Bilangin
dfthd7c (hostname)
842941
winsrv1 (hostname)
266525
ADMINISTRATOR
180678
administrador
163842
Administrador
53541
Miguel
23101
server
21983
steve
21936
john
21927
Paul
21913
pagtanggap
21909
mayk
21899
opisina
21888
scanner
21887
i-scan
21867
david
21865
Chris
21860
may-ari
21855
tagapamahala
21852
administrateur
21841
brian
21839
administrador
21837
markahan
21824
mga tauhan
21806
ADMIN
12748
Ugat
7772
ADMINISTrador
7325
SUPORTA
5577
SUPPORT
5418
USER
4558
admin
2832
PAGSUBOK
1928
Mysql
1664
Admin
1652
BISITA
1322
USER1
1179
PARA MAG-SCAN
1121
Malasin
1032
ADMINISTRATOR
842
ADMIN1
525
BACKUP
518
MySqlAdmin
518
TANGGAP
490
USER2
466
TEMP
452
SQLADMIN
450
USER3
441
1
422
MANAGER
418
MAY-ARI
410
Pinagmulan: www.habr.com