Ik heb vaak de mening gelezen dat het openen van de RDP (Remote Desktop Protocol) poort naar het internet zeer onveilig is, en dat je dat niet zou moeten doen. Je zou RDP-toegang alleen via een VPN of alleen vanaf bepaalde "witte" IP-adressen moeten geven.
Ik beheer verschillende Windows Server voor kleine bedrijven, waar ik de taak heb gekregen om afstandstoegang tot de Windows Server voor accountants te bieden. Dit is de moderne trend: werken vanuit huis. Al snel realiseerde ik me dat het een moeilijke taak is om accountants met een VPN te werken, en het zou niet lukken om alle IP-adressen voor de whitelist samen te stellen, omdat de IP-adressen van mensen dynamisch zijn.
Daarom nam ik de eenvoudigste route ā ik opende de RDP-poort naar buiten. Nu hoeven accountants alleen maar RDP te starten en de hostnaam (inclusief poort), gebruikersnaam en wachtwoord in te voeren om toegang te krijgen.
In dit artikel deel ik mijn ervaringen (zowel positieve als minder positieve) en aanbevelingen.
Risico's
Wat riskeer je door de RDP-poort te openen?
1) Onautoriseerde toegang tot gevoelige gegevens
Als iemand het wachtwoord voor RDP achterhaalt, kan hij toegang krijgen tot gegevens die je privƩ wilt houden: rekeningstatussen, saldi, klantgegevens, ...
2) Gegevensverlies
Bijvoorbeeld als gevolg van het werk van ransomware.
Of door weloverwogen acties van een aanvaller.
3) Verlies van de werkstation
Werknemers moeten kunnen werken, maar het systeem is gecompromitteerd, het moet opnieuw worden geĆÆnstalleerd / hersteld / geconfigureerd.
4) Compromittering van het lokale netwerk
Als een aanvaller toegang krijgt tot een Windows-pc, kan hij vanaf die computer toegang krijgen tot systemen die vanuit het internet niet toegankelijk zijn. Bijvoorbeeld netwerkshares, netwerkprinters, enzovoort.
Ik heb een geval gehad waarin een Windows Server ransomware te pakken kreeg
en deze ransomware versleutelde eerst de meeste bestanden op schijf C:, en begon toen bestanden op de NAS via het netwerk te versleutelen. Aangezien de NAS een Synology was, met ingestelde snapshots, kon ik de NAS in 5 minuten herstellen, terwijl ik de Windows Server vanaf nul opnieuw moest installeren.
Observaties en Aanbevelingen
Ik monitor Windows Servers met behulp van , die logs naar ElasticSearch versturen. In Kibana zijn er verschillende visualisaties, en ik heb nog een aangepaste dashboard ingesteld.
De monitoring zelf beschermt niet, maar helpt bij het bepalen van de nodige maatregelen.
Hier zijn enkele observaties:
a) RDP zal worden gebruteforced.
Op een van mijn servers heb ik RDP niet op de standaardpoort 3389 gezet, maar op 443 - zodat het lijkt op HTTPS. Het is misschien de moeite waard om van de standaardpoort te veranderen, maar dat biedt niet veel voordelen. Dit is de statistiek van deze server:
Het is duidelijk dat er in een week tijd bijna 400.000 mislukte pogingen waren om via RDP toegang te krijgen.
Het is duidelijk dat de pogingen om in te loggen afkomstig waren van 55.001 IP-adressen (sommige IP-adressen waren al door mij geblokkeerd).
Hier ligt de conclusie voor de hand dat je fail2ban moet installeren, maar
er is geen dergelijke tool voor Windows.
Er zijn een paar verlaten projecten op GitHub die dit blijkbaar proberen, maar ik heb ze nog niet geprobeerd:
Er zijn ook betaalde tools, maar die heb ik niet overwogen.
Als je een open tool voor dit doel kent, deel deze dan in de reacties.
Bijwerken: In de reacties werd gesuggereerd dat poort 443 een ongunstige keuze is, en het beter is om hoge poorten (32000+) te kiezen, omdat 443 vaker gescand wordt, en het geen probleem is om RDP op deze poort te herkennen.
Update: In de reacties werd gesuggereerd dat er zo'n tool bestaat:
b) Er zijn bepaalde gebruikersnamen die aanvallers liever gebruiken.
Het is duidelijk dat de brute-force aanvallen gebaseerd zijn op een woordenlijst met verschillende namen.
Maar wat ik opmerkte: een aanzienlijk aantal pogingen gebruikt de naam van de server als login. Aanbeveling: gebruik niet dezelfde naam voor de computer en de gebruiker. Bovendien proberen ze soms de naam van de server op de een of andere manier te parseren: bijvoorbeeld voor een systeem met de naam DESKTOP-DFTHD7C zijn de meeste pogingen om in te loggen met de naam DFTHD7C:
Dus als je een computer DESKTOP-MARIA hebt, is de kans groot dat er pogingen komen om in te loggen als gebruiker MARIA.
Daarnaast viel het me op uit de logs: op de meeste systemen zijn de meeste inlogpogingen met de naam "administrator". En dat is geen toeval, omdat deze gebruiker in veel versies van Windows bestaat. Sterker nog - je kunt hem niet verwijderen. Dit vergemakkelijkt de taak voor aanvallers: in plaats van te raden naar naam en wachtwoord, hoeven ze alleen maar het wachtwoord te raden.
Overigens had het systeem dat slachtoffer werd van de ransomware de gebruiker Administrator en het wachtwoord Murmansk#9. Ik ben er nog steeds niet zeker van hoe dat systeem werd gehackt, omdat ik pas begon te monitoren na dat voorval, maar ik denk dat brute-forcing waarschijnlijk is.
Dus als de gebruiker Administrator niet verwijderd kan worden, wat te doen? Je kunt hem hernoemen!
Aanbevelingen uit dit punt:
- gebruik geen gebruikersnaam in de computernamen
- Zorg ervoor dat er geen gebruiker met de naam Administrator op het systeem is.
- Gebruik betrouwbare wachtwoorden.
Op deze manier zie ik al een paar jaar hoe verschillende Windows-servers onder mijn controle gebruteforced worden, en zonder succes.
Hoe weet ik dat het zonder succes is?
Omdat op de screenshots hierboven te zien is dat er logs zijn van succesvolle RDP-toegang, waarin informatie staat:
- van welk IP
- van welke computer (hostname)
- gebruikersnaam
- GeoIP-informatie
En ik kijk daar regelmatig naar ā geen anomalieĆ«n gevonden.
Overigens, als er vanaf een bepaald IP hard gebruteforced wordt, kun je specifieke IP's (of subnetten) zo blokkeren in 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 BlockTrouwens, behalve Winlogbeat heeft Elastic ook nog , dat kunnen volgen naar bestanden en processen op het systeem. Er is ook een SIEM (Security Information & Event Management) applicatie in Kibana. Ik heb beide geprobeerd, maar zag er niet veel nut in - het lijkt erop dat Auditbeat nuttiger zal zijn voor Linux-systemen, terwijl SIEM me nog niets betekenisvols heeft laten zien.
En een paar laatste aanbevelingen:
- maak regelmatig automatische back-ups.
- installeer beveiligingsupdates tijdig.
Bonus: een lijst van 50 gebruikers die vaker zijn gebruikt bij RDP-inlogpogingen.
"user.name: Descending"
Aantal
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
owner
21855
manager
21852
beheerder
21841
brian
21839
administrador
21837
mark
21824
staff
21806
ADMIN
12748
ROOT
7772
ADMINISTRADOR
7325
SUPPORT
5577
SOPORTE
5418
USER
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
Bron: habr.com
