Pogosto sem prebral mnenje, da je ohranjanje odprtih vrat RDP (Remote Desktop Protocol) za internet zelo nevarno in tega ne bi smeli storiti. Vendar morate omogočiti dostop do RDP prek VPN-ja ali samo z določenih "belih" naslovov IP.
Administriram več strežnikov Windows za mala podjetja, kjer sem bil zadolžen za zagotavljanje oddaljenega dostopa do strežnika Windows za računovodje. To je sodobni trend – delo od doma. Kar hitro sem spoznal, da je mučenje računovodij VPN nehvaležna naloga in zbiranje vseh IP-jev za beli seznam ne bo šlo, saj so IP-naslovi ljudi dinamični.
Zato sem ubral najpreprostejšo pot - posredoval vrata RDP navzven. Za dostop morajo računovodje zdaj zagnati RDP in vnesti ime gostitelja (vključno z vrati), uporabniško ime in geslo.
V tem članku bom delil svoje izkušnje (pozitivne in manj pozitivne) in priporočila.
Tveganja
Kaj tvegate z odpiranjem vrat RDP?
1) Nepooblaščen dostop do občutljivih podatkov
Če nekdo ugane geslo RDP, bo lahko pridobil podatke, ki jih želite ohraniti zasebne: stanje na računu, stanja, podatke o strankah, ...
2) Izguba podatkov
Na primer zaradi virusa ransomware.
Ali namerno dejanje napadalca.
3) Izguba delovne postaje
Delavci morajo delati, vendar je sistem ogrožen in ga je treba znova namestiti/obnoviti/konfigurirati.
4) Ogromnost lokalnega omrežja
Če je napadalec pridobil dostop do računalnika z operacijskim sistemom Windows, bo s tega računalnika lahko dostopal do sistemov, ki so nedostopni od zunaj, iz interneta. Na primer v skupno rabo datotek, v omrežne tiskalnike itd.
Imel sem primer, ko je Windows Server ujel izsiljevalsko programsko opremo
in ta izsiljevalska programska oprema je najprej šifrirala večino datotek na pogonu C: in nato začela šifrirati datoteke na NAS prek omrežja. Ker je bil NAS Synology, sem s konfiguriranimi posnetki obnovil NAS v 5 minutah in znova namestil Windows Server iz nič.
Opažanja in priporočila
Strežnike Windows spremljam z uporabo
Spremljanje samo po sebi ne ščiti, ampak pomaga določiti potrebne ukrepe.
Tukaj je nekaj opažanj:
a) RDP bo brutalno vsiljen.
Na enem od strežnikov sem RDP namestil ne na standardna vrata 3389, ampak na 443 - no, prikril se bom kot HTTPS. Verjetno se splača zamenjati vrata s standardnega, vendar ne bo veliko koristilo. Tukaj je statistika s tega strežnika:
Razvidno je, da je bilo v tednu dni skoraj 400 neuspešnih poskusov prijave preko RDP.
Vidi se, da je bilo poskusov prijave s 55 IP naslovov (nekatere IP naslove sem že blokiral).
To neposredno nakazuje sklep, da morate nastaviti fail2ban, vendar
Za Windows ni takega pripomočka.
Na Githubu je nekaj opuščenih projektov, za katere se zdi, da to počnejo, vendar jih nisem niti poskusil namestiti:
Obstajajo tudi plačljive komunalne storitve, vendar jih nisem upošteval.
Če poznate odprtokodni pripomoček za ta namen, ga delite v komentarjih.
Nadgradnja: Komentarji so predlagali, da so vrata 443 slaba izbira in da je bolje izbrati visoka vrata (32000+), ker se 443 pogosteje pregleduje in prepoznavanje RDP na teh vratih ni problem.
b) Napadalci imajo raje določena uporabniška imena
Vidi se, da se iskanje izvaja v slovarju z različnimi imeni.
Ampak tukaj sem opazil: veliko število poskusov uporablja ime strežnika kot prijavo. Priporočilo: Ne uporabljajte istega imena za računalnik in uporabnika. Poleg tega je včasih videti, kot da poskušajo nekako razčleniti ime strežnika: na primer, za sistem z imenom DESKTOP-DFTHD7C je največ poskusov prijave z imenom DFTHD7C:
V skladu s tem, če imate računalnik DESKTOP-MARIA, se boste verjetno poskušali prijaviti kot uporabnik MARIA.
Še ena stvar, ki sem jo opazil iz dnevnikov: v večini sistemov je večina poskusov prijave z imenom "administrator". In to ni brez razloga, saj ta uporabnik obstaja v mnogih različicah sistema Windows. Poleg tega ga ni mogoče izbrisati. To poenostavi nalogo za napadalce: namesto ugibanja imena in gesla morate samo uganiti geslo.
Mimogrede, sistem, ki je ujel izsiljevalsko programsko opremo, je imel uporabnika Administrator in geslo Murmansk#9. Še vedno nisem prepričan, kako je prišlo do vdora v ta sistem, ker sem začel spremljati takoj po tem incidentu, vendar mislim, da je verjetno pretiravanje.
Če torej uporabnika Administrator ni mogoče izbrisati, kaj morate storiti? Lahko ga preimenujete!
Priporočila iz tega odstavka:
- ne uporabljajte uporabniškega imena v imenu računalnika
- poskrbite, da v sistemu ni skrbniškega uporabnika
- uporabljajte močna gesla
Tako sem že približno nekaj let opazoval več strežnikov Windows pod mojim nadzorom, ki so bili nasilni in brez uspeha.
Kako naj vem, da je neuspešno?
Ker na zgornjih posnetkih zaslona vidite, da obstajajo dnevniki uspešnih klicev RDP, ki vsebujejo informacije:
- s katerega IP-ja
- iz katerega računalnika (ime gostitelja)
- uporabniško ime
- GeoIP informacije
In tam redno preverjam - nobenih nepravilnosti ni bilo.
Mimogrede, če je določen IP zelo težko vsiljen, lahko blokirate posamezne IP-je (ali podomrežja), kot je ta v lupini 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
Mimogrede, Elastic ima poleg Winlogbeata tudi
No, končna priporočila:
- Izdelujte redne samodejne varnostne kopije.
- pravočasno namestite varnostne posodobitve
Bonus: seznam 50 uporabnikov, ki so bili najpogosteje uporabljeni za poskuse RDP prijave
"user.name: padajoče"
Grof
dfthd7c (ime gostitelja)
842941
winsrv1 (ime gostitelja)
266525
ADMINISTRATOR
180678
skrbnik
163842
skrbnik
53541
michael
23101
strežnik
21983
steve
21936
john
21927
paul
21913
sprejem
21909
mike
21899
urad
21888
skener
21887
skeniranje
21867
david
21865
chris
21860
Lastnik
21855
upravitelj
21852
Administrateur
21841
Brian
21839
Skrbnik
21837
znamka
21824
Osebje
21806
ADMIN
12748
ROOT
7772
ADMINISTRATOR
7325
podpora
5577
PODPORA
5418
UPORABNIK
4558
admin
2832
TEST
1928
Mysql
1664
admin
1652
GOST
1322
UPORABNIK1
1179
SKENER
1121
SCAN
1032
ADMINISTRATOR
842
SKRBNIK1
525
REZERVA
518
MySqlAdmin
518
SPREJEM
490
UPORABNIK2
466
Temp
452
SQLADMIN
450
UPORABNIK3
441
1
422
MANAGER
418
LASTNIK
410
Vir: www.habr.com