Často jsem četl názor, že udržovat port RDP (Remote Desktop Protocol) otevřený pro internet je velmi nebezpečné a nemělo by se to dělat. Musíte však poskytnout přístup k RDP buď prostřednictvím VPN, nebo pouze z určitých „bílých“ IP adres.
Spravuji několik Windows Serverů pro malé firmy, kde mám za úkol poskytovat vzdálený přístup k Windows Serveru pro účetní. To je moderní trend – práce z domova. Poměrně rychle jsem si uvědomil, že mučit účetní VPN je nevděčný úkol a shromažďování všech IP adres na bílou listinu nebude fungovat, protože IP adresy lidí jsou dynamické.
Proto jsem zvolil nejjednodušší cestu - předal RDP port ven. Aby účetní získali přístup, musí nyní spustit RDP a zadat název hostitele (včetně portu), uživatelské jméno a heslo.
V tomto článku se podělím o své zkušenosti (pozitivní i ne tak pozitivní) a doporučení.
Rizika
Co riskujete otevřením portu RDP?
1) Neoprávněný přístup k citlivým údajům
Pokud někdo uhodne heslo RDP, bude moci získat data, která chcete zachovat v soukromí: stav účtu, zůstatky, údaje o zákaznících, ...
2) Ztráta dat
Například v důsledku ransomwarového viru.
Nebo úmyslná akce útočníka.
3) Ztráta pracovní stanice
Pracovníci musí pracovat, ale systém je kompromitován a je třeba jej přeinstalovat/obnovit/konfigurovat.
4) Kompromis místní sítě
Pokud útočník získal přístup k počítači s Windows, pak z tohoto počítače bude mít přístup k systémům, které jsou zvenčí nepřístupné, z internetu. Například pro sdílení souborů, síťové tiskárny atd.
Měl jsem případ, kdy Windows Server zachytil ransomware
a tento ransomware nejprve zašifroval většinu souborů na disku C: a poté začal šifrovat soubory na NAS přes síť. Protože NAS byl Synology s nakonfigurovanými snímky, obnovil jsem NAS za 5 minut a přeinstaloval Windows Server od začátku.
Pozorování a doporučení
Monitoruji používání serverů Windows , které odesílají protokoly do ElasticSearch. Kibana má několik vizualizací a také jsem nastavil vlastní dashboard.
Monitoring sám o sobě nechrání, ale pomáhá určit potřebná opatření.
Zde jsou některé postřehy:
a) PRV bude hrubou silou.
Na jednom ze serverů jsem nainstaloval RDP ne na standardní port 3389, ale na 443 - no, budu se maskovat jako HTTPS. Asi se vyplatí změnit port ze standardního, ale moc užitku to nepřinese. Zde jsou statistiky z tohoto serveru:
Je vidět, že za týden bylo téměř 400 000 neúspěšných pokusů o přihlášení přes RDP.
Je vidět, že došlo k pokusům o přihlášení z 55 001 IP adres (některé IP adresy jsem již zablokoval).
To přímo naznačuje závěr, že musíte nastavit fail2ban, ale
Pro Windows takový nástroj neexistuje.
Na Githubu je několik opuštěných projektů, které to zřejmě dělají, ale ani jsem se je nepokusil nainstalovat:
Existují také placené nástroje, ale nezvažoval jsem je.
Pokud znáte open source nástroj pro tento účel, podělte se o něj v komentářích.
Aktualizace: Komentáře naznačovaly, že port 443 je špatná volba a je lepší zvolit vysoké porty (32000+), protože 443 je skenován častěji a rozpoznání RDP na tomto portu není problém.
b) Existují určitá uživatelská jména, která útočníci preferují
Je vidět, že vyhledávání probíhá ve slovníku s různými názvy.
Ale všiml jsem si toho: značný počet pokusů používá název serveru jako přihlašovací jméno. Doporučení: Nepoužívejte stejný název pro počítač a uživatele. Navíc to někdy vypadá, že se snaží nějak analyzovat název serveru: například u systému s názvem DESKTOP-DFTHD7C je nejvíce pokusů o přihlášení s názvem DFTHD7C:
Pokud tedy máte počítač DESKTOP-MARIA, pravděpodobně se budete snažit přihlásit jako uživatel MARIA.
Další věc, kterou jsem si všiml z protokolů: na většině systémů je většina pokusů o přihlášení s názvem „administrátor“. A to není bez důvodu, protože v mnoha verzích Windows tento uživatel existuje. Navíc to nejde smazat. To útočníkům zjednodušuje úkol: místo hádání jména a hesla stačí uhodnout heslo.
Mimochodem, systém, který ransomware zachytil, měl uživatele Administrator a heslo Murmansk#9. Stále si nejsem jistý, jak byl tento systém hacknut, protože jsem začal monitorovat těsně po tomto incidentu, ale myslím si, že je to přehnané.
Pokud tedy nelze odstranit uživatele Administrator, co byste měli dělat? Můžete to přejmenovat!
Doporučení z tohoto odstavce:
- nepoužívejte uživatelské jméno v názvu počítače
- ujistěte se, že v systému není žádný administrátor
- používat silná hesla
Takže už několik let sleduji, jak je několik Windows serverů pod mým ovládáním brutálně vynuceno, a bez úspěchu.
Jak poznám, že je neúspěšný?
Protože na snímcích výše vidíte, že existují protokoly úspěšných volání RDP, které obsahují informace:
- ze které IP
- z jakého počítače (název hostitele)
- имя пользователя
- GeoIP informace
A pravidelně tam kontroluji - nebyly zjištěny žádné anomálie.
Mimochodem, pokud je konkrétní IP adresa obzvláště tvrdě vynucena, můžete jednotlivé IP adresy (nebo podsítě) zablokovat takto v PowerShellu:
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 BlockMimochodem, Elastic kromě Winlogbeat má také , který může monitorovat soubory a procesy v systému. V Kibaně je také aplikace SIEM (Security Information & Event Management). Zkoušel jsem obojí, ale moc přínosů jsem neviděl – vypadá to, že Auditbeat bude užitečnější pro systémy Linux a SIEM mi zatím nic srozumitelného neukázal.
No, závěrečná doporučení:
- Provádějte pravidelné automatické zálohy.
- nainstalujte aktualizace zabezpečení včas
Bonus: seznam 50 uživatelů, kteří byli nejčastěji používáni pro pokusy o přihlášení k RDP
"user.name: Sestupně"
Počítat
dfthd7c (název hostitele)
842941
winsrv1 (název hostitele)
266525
SPRÁVCE
180678
správce
163842
Správce
53541
Michal
23101
Server
21983
Steve
21936
john
21927
paul
21913
recepce
21909
mikrofon
21899
kancelář
21888
skener
21887
skenovat
21867
david
21865
Chris
21860
majitel
21855
manažer
21852
administrateur
21841
Brian
21839
správce
21837
označit
21824
zaměstnanci
21806
ADMIN
12748
ROOT
7772
ADMINISTRÁTOR
7325
PODPORA
5577
PODPORA
5418
USER
4558
administrátor
2832
TEST
1928
MySql
1664
administrátor
1652
GUEST
1322
UŽIVATEL1
1179
SKENER
1121
SCAN
1032
ADMINISTRÁTOR
842
ADMIN1
525
BACKUP
518
MySqlAdmin
518
RECEPCE
490
UŽIVATEL2
466
TEMP
452
SQLADMIN
450
UŽIVATEL3
441
1
422
MANAGER
418
MAJITEL
410
Zdroj: www.habr.com