Mi ofte legis la opinion, ke teni RDP (Remote Desktop Protocol) havenon malfermita al la Interreto estas tre nesekura kaj ne devus esti farita. Sed vi devas doni aliron al RDP aŭ per VPN, aŭ nur de certaj "blankaj" IP-adresoj.
Mi administras plurajn Vindozo-Servilojn por malgrandaj firmaoj, kie mi estis taskigita provizi foran aliron al Vindoza Servilo por librotenistoj. Ĉi tiu estas la moderna tendenco - labori de hejmo. Sufiĉe rapide, mi rimarkis, ke turmenti VPN-kontistojn estas sendanka tasko, kaj kolekti ĉiujn IP-ojn por la blanka listo ne funkcios, ĉar la IP-adresoj de homoj estas dinamikaj.
Tial mi prenis la plej simplan vojon - plusendis la RDP-havenon eksteren. Por akiri aliron, revizoroj nun devas ruli RDP kaj enigi la gastigan nomon (inkluzive de haveno), uzantnomon kaj pasvorton.
En ĉi tiu artikolo mi dividos mian sperton (pozitivan kaj ne tiel pozitivan) kaj rekomendojn.
Risoj
Kion vi riskas malfermante la RDP-havenon?
1) Neaŭtorizita aliro al sentemaj datumoj
Se iu divenas la pasvorton de RDP, ili povos akiri datumojn, kiujn vi volas konservi privatajn: konto-stato, saldoj, klientdatenoj, ...
2) Perdo de datumoj
Ekzemple, kiel rezulto de ransomware viruso.
Aŭ intenca ago de atakanto.
3) Perdo de laborstacio
Laboristoj devas labori, sed la sistemo estas kompromitita kaj devas esti reinstalita/restarigita/agordita.
4) Kompromiso de la loka reto
Se atakanto akiris aliron al Vindoza komputilo, tiam de ĉi tiu komputilo li povos aliri sistemojn neatingeblajn de ekstere, de Interreto. Ekzemple, al dosierpartoj, al retprintiloj, ktp.
Mi havis kazon kie Windows Server kaptis ransomware
kaj ĉi tiu ransomware unue ĉifris la plej multajn el la dosieroj sur la C:-disko kaj poste komencis ĉifri la dosierojn sur la NAS per la reto. Ĉar la NAS estis Synology, kun momentfotoj agordis, mi restarigis la NAS en 5 minutoj, kaj reinstalis Windows Server de nulo.
Observoj kaj Rekomendoj
Mi monitoras Windows Servers uzante , kiuj sendas protokolojn al ElasticSearch. Kibana havas plurajn bildigojn, kaj mi ankaŭ starigis laŭmendan instrumentpanelon.
Monitorado mem ne protektas, sed ĝi helpas determini la necesajn mezurojn.
Jen kelkaj observoj:
a) RDP estos krude devigita.
Sur unu el la serviloj, mi instalis RDP ne sur la norma haveno 3389, sed sur 443 - nu, mi maskos min kiel HTTPS. Verŝajne indas ŝanĝi la havenon de la norma, sed ĝi ne multe utilos. Jen la statistikoj de ĉi tiu servilo:
Oni povas vidi, ke en semajno estis preskaŭ 400 000 malsukcesaj provoj ensaluti per RDP.
Videblas, ke estis provoj ensaluti de 55 001 IP-adresoj (kelkaj IP-adresoj jam estis blokitaj de mi).
Ĉi tio rekte sugestas la konkludon, ke vi devas agordi fail2ban, sed
Ne ekzistas tia ilo por Vindozo.
Estas kelkaj forlasitaj projektoj sur Github, kiuj ŝajnas fari ĉi tion, sed mi eĉ ne provis instali ilin:
Estas ankaŭ pagitaj utilecoj, sed mi ne konsideris ilin.
Se vi konas malfermfontan ilon por ĉi tiu celo, bonvolu dividi ĝin en la komentoj.
Ĝisdatigu: La komentoj sugestis, ke haveno 443 estas malbona elekto, kaj estas pli bone elekti altajn pordojn (32000+), ĉar 443 estas skanita pli ofte, kaj rekoni RDP sur ĉi tiu haveno ne estas problemo.
b) Estas certaj uzantnomoj, kiujn atakantoj preferas
Videblas, ke la serĉado estas farata en vortaro kun malsamaj nomoj.
Sed jen kion mi rimarkis: signifa nombro da provoj uzas la servilan nomon kiel ensaluton. Rekomendo: Ne uzu la saman nomon por la komputilo kaj la uzanto. Krome, foje ŝajnas, ke ili iel provas analizi la servilnomon: ekzemple, por sistemo kun la nomo DESKTOP-DFTHD7C, la plej multaj provoj ensaluti estas kun la nomo DFTHD7C:
Sekve, se vi havas DESKTOP-MARIA-komputilon, vi verŝajne provos ensaluti kiel la MARIA-uzanto.
Alian aferon mi rimarkis el la protokoloj: ĉe la plej multaj sistemoj, la plej multaj provoj ensaluti estas kun la nomo "administranto". Kaj ĉi tio ne estas sen kialo, ĉar en multaj versioj de Vindozo, ĉi tiu uzanto ekzistas. Krome, ĝi ne povas esti forigita. Ĉi tio simpligas la taskon por atakantoj: anstataŭ diveni nomon kaj pasvorton, vi nur bezonas diveni la pasvorton.
Cetere, la sistemo, kiu kaptis la ransomware, havis la uzanton Administranto kaj la pasvorton Murmansk#9. Mi ankoraŭ ne certas kiel tiu sistemo estis hakita, ĉar mi komencis monitori tuj post tiu okazaĵo, sed mi pensas, ke tiu troo estas verŝajna.
Do se la Administranto-uzanto ne povas esti forigita, do kion vi faru? Vi povas renomi ĝin!
Rekomendoj de ĉi tiu alineo:
- ne uzu la uzantnomon en la komputilnomo
- certigu, ke ne ekzistas Administranto-uzanto en la sistemo
- uzu fortajn pasvortojn
Do, mi rigardas plurajn Vindozajn Servilojn sub mia kontrolo, kiuj estas krud-devigataj dum proksimume kelkaj jaroj, kaj sen sukceso.
Kiel mi scias, ke ĝi estas malsukcesa?
Ĉar en la supraj ekrankopioj vi povas vidi, ke estas protokoloj de sukcesaj RDP-vokoj, kiuj enhavas la informojn:
- de kiu IP
- de kiu komputilo (gastigantonomo)
- Uzantnomo
- Informoj pri GeoIP
Kaj mi kontrolas tie regule - neniu anomalio estis trovita.
Cetere, se aparta IP estas precipe malmola forte, tiam vi povas bloki individuajn IP-ojn (aŭ subretojn) kiel ĉi tion en 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 BlockCetere, Elastic, krom Winlogbeat, ankaŭ havas , kiu povas monitori dosierojn kaj procezojn en la sistemo. Ekzistas ankaŭ SIEM (Sekureco-Informo kaj Event Management) aplikaĵo en Kibana. Mi provis ambaŭ, sed ne vidis multe da utilo - ŝajnas, ke Auditbeat estos pli utila por Linuksaj sistemoj, kaj SIEM ankoraŭ ne montris al mi ion kompreneblan.
Nu, finaj rekomendoj:
- Faru regulajn aŭtomatajn sekurkopiojn.
- instalu Sekurecajn Ĝisdatigojn ĝustatempe
Gratifiko: listo de 50 uzantoj, kiuj plej ofte estis uzataj por RDP-ensalutprovoj
"uzanto.nomo: Devena"
Grafo
dfthd7c (gastigantonomo)
842941
winsrv1 (gastigantonomo)
266525
ADMINISTRANTO
180678
administranto
163842
Administrator
53541
michael
23101
servilo
21983
steve
21936
john
21927
paul
21913
akcepto
21909
mike
21899
oficejo
21888
skanilo
21887
skani
21867
david
21865
chris
21860
posedanto
21855
manaĝero
21852
administranto
21841
brian
21839
administranto
21837
markon
21824
kunlaborantaro
21806
ADMINO
12748
RADIKO
7772
ADMINISTRO
7325
SUBTENO
5577
SUBTENO
5418
USERO
4558
administristo
2832
TESTO
1928
mysql
1664
admin
1652
GASTO
1322
UZANTO1
1179
SKANILO
1121
SKANI
1032
ADMINISTRANTO
842
ADMINISTRO1
525
restaŭrkopion
518
MySqlAdmin
518
Ricevo
490
UZANTO2
466
TEMP
452
SQLADMIN
450
UZANTO3
441
1
422
ADMINISTRANTO
418
OWNER
410
fonto: www.habr.com