Není neobvyklé číst názory, že mít RDP (Remote Desktop Protocol) port otevřený na Internetu je velmi nebezpečné, a že by se to dělat nemělo. Přístup k RDP by měl být poskytován buď přes VPN, nebo pouze z určitých "bílých" IP adres.
Administruji několik Windows Serverů pro malé firmy, kde bylo mým úkolem zajistit vzdálený přístup k Windows Serveru pro účetní. Takovýto moderní trend – práce z domova. Poměrně rychle jsem pochopil, že potrápit účetní VPN je nevděčné, a že se mi nepodaří shromáždit všechny IP adresy pro bílý seznam, protože adresy lidí jsou dynamické.
Proto jsem zvolil nejjednodušší cestu – přesunul jsem port RDP ven. Nyní pro přístup potřebují účetní 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 zkušenosti (pozitivní i negativní) a doporučení.
Rizika
Jaké riziko podstupujete otevřením portu RDP?
1) Neautorizovaný přístup k citlivým údajům
Pokud někdo uhádne heslo k RDP, může získat údaje, které chcete mít soukromé: stavy účtů, zůstatky, údaje o klientech, …
2) Ztráta dat
Například v důsledku činnosti ransomware.
Nebo cíleného jednání útočníka.
3) Ztráta pracovního stanice
Zaměstnanci musí pracovat, a systém je kompromitován, je třeba ho přeinstalovat / obnovit / konfigurovat.
4) Kompromitace lokální sítě
Pokud útočník získal přístup k Windows počítači, pak z tohoto počítače může mít přístup k systémům, které nejsou přístupné zvenčí, z Internetu. Například k sdíleným složkám, síťovým tiskárnám atd.
Měl jsem případ, kdy Windows Server chytil ransomware
a tento ransomware nejprve zašifroval většinu souborů na disku C:, a pak začal šifrovat soubory na NAS přes síť. Protože NAS byl Synology, s nastavenými snapshoty, tak jsem NAS obnovil za 5 minut, zatímco Windows Server jsem musel přeinstalovat od začátku.
Pozorování a Doporučení
Monitruji Windows Servery pomocí , které posílají logy do ElasticSearch. V Kibana je několik vizualizací a já jsem si také nastavil vlastní dashboard.
Sám monitoring nechrání, ale pomáhá určit potřebná opatření.
Zde jsou některá pozorování:
a) RDP se budou bruteforce.
Na jednom ze serverů jsem RDP nastavil na port 443 místo standardního 3389 — abych se tak říkajíc zamaskoval jako HTTPS. S změnou portu z standardního asi stojí za to, ale moc to nepomůže. Tady jsou statistiky z tohoto serveru:
Vidíte, že za týden bylo téměř 400 000 neúspěšných pokusů o připojení přes RDP.
Bylo zaznamenáno pokusy o připojení z 55 001 IP adres (některé IP adresy jsem už zablokoval).
Nabízí se závěr, že je třeba nasadit fail2ban, ale
pro Windows takový nástroj neexistuje.
Existuje pár opuštěných projektů na GitHubu, které to prý dělají, ale ani jsem je nezkoušel instalovat:
Jsou také placené nástroje, ale těmi jsem se nezabýval.
Pokud znáte nějaký otevřený nástroj pro tento účel — podělte se o něj v komentářích.
Aktualizovat: V komentářích mě upozornili, že port 443 je nešťastná volba, lepší je zvolit vyšší porty (32000+), protože 443 je častěji skenován a identifikovat RDP na tomto portu není problém.
Update: V komentářích mě informovali, že takový nástroj existuje:
b) Existují určité uživatelské jména, která útočníci upřednostňují
Vidíte, že probíhá slovníkový útok s různými jmény.
Ale co jsem si všiml: značné množství pokusů používá název serveru jako přihlašovací jméno. Doporučení: nepoužívejte stejné jméno pro počítač a pro uživatele. Navíc, někdy se zdá, že se název serveru pokouší nějak rozebrat: například pro systém 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ě budou probíhat pokusy o přihlášení pod uživatelským jménem MARIA.
Další věc, kterou jsem si všiml z logů: na většině systémů je většina pokusů o přihlášení s jménem "administrator". A to není náhoda, protože v mnoha verzích Windows tento uživatel existuje. Navíc ho nelze odstranit. To usnadňuje úlohu útočníkům: místo podávání jména a hesla je třeba jen uhádnout heslo.
Mimochodem, ten systém, který chytil ransomware, měl uživatele Administrator a heslo Murmansk#9. Stále nejsem jistý, jak se ten systém dostal do problémů, protože jsem začal sledovat až po této události, ale myslím, že slovníkový útok je pravděpodobný.
Pokud tedy uživatele Administrator nelze odstranit, co s tím dělat? Může se přejmenovat!
Doporučení z této části:
- nepoužívejte jméno uživatele v názvu počítače.
- Ujistěte se, že na systému není uživatel Administrator
- Používejte silná hesla
Takhle už několik let sleduji, jak jsou moje Windows servery brutálně napadány, a bez úspěchu.
Odkud vím, že bez úspěchu?
Protože na výše uvedených snímcích obrazovky jsou vidět úspěšné pokusy o přihlášení přes RDP, v nichž jsou informace:
- z jaké IP adresy
- z jakého počítače (hostname)
- uživatelské jméno
- informace GeoIP
A pravidelně se na to dívám – anomálie nebyly zjištěny.
Mimochodem, pokud je z nějaké IP adresy brutální útok zvlášť vytrvalý, lze jednotlivé IP (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 sledovat soubory a procesy na systému. Ještě je zde aplikace SIEM (Security Information & Event Management) v Kibana. Zkoušel jsem oboje, ale neviděl jsem výrazný přínos – zdá se, že Auditbeat bude užitečnější pro Linux systémy, zatímco SIEM mi zatím nic jasného neukázal.
A konečné doporučení:
- provádějte pravidelné automatické zálohy.
- včas instalujte bezpečnostní aktualizace.
Bonus: seznam 50 uživatelů, kteří byli nejčastěji používáni pro pokusy o přihlášení přes RDP
"user.name: Sestupně"
Počet
dfthd7c (hostname)
842941
winsrv1 (hostname)
266525
ADMINISTRATOR
180678
administrator
163842
Administrator
53541
michael
23101
server
21983
steve
21936
john
21927
paul
21913
reception
21909
mike
21899
office
21888
scanner
21887
scan
21867
david
21865
chris
21860
vlastník
21855
manager
21852
administrateur
21841
brian
21839
administrador
21837
mark
21824
staff
21806
ADMIN
12748
ROOT
7772
ADMINISTRADOR
7325
SUPPORT
5577
SOPORTE
5418
UŽIVATEL
4558
admin
2832
TEST
1928
MySql
1664
Admin
1652
GUEST
1322
USER1
1179
SCANNER
1121
SCAN
1032
ADMINISTRATEUR
842
ADMIN1
525
BACKUP
518
MySqlAdmin
518
RECEPTION
490
USER2
466
TEMP
452
SQLADMIN
450
USER3
441
1
422
MANAGER
418
OWNER
410
Zdroj: habr.com
