RDP beveiligen: Windows Server beschermen tegen aanvallen

Een Windows-server die met poort 3389 open het internet op gaat, wordt niet ooit een keer aangevallen, maar binnen enkele minuten. De scanners draaien permanent, kennen elk IPv4-bereik en proberen stug gebruikersnamen en wachtwoorden uit. Bijna elk ransomware-incident op kleine servers begint precies op dit punt: een account met de naam Administrator, een wachtwoord dat iemand goed genoeg vond, en geen vergrendeling na de duizendste mislukte poging.

Deze handleiding loopt de maatregelen door op volgorde van hun werkelijke effect, niet op de volgorde waarin ze in de meeste artikelen staan. Alle commando's draaien in een PowerShell-sessie met administratorrechten, op Windows Server 2016 tot en met 2025.

Waarom RDP de meest aangevallen ingang is

RDP is geen slecht protocol. Het probleem is dat het een volwaardig aanmeldformulier op het open internet zet en dat Windows dat formulier standaard onbeperkt vaak laat invullen. Een aanvaller heeft geen kwetsbaarheid nodig, alleen geduld en een wachtwoordenlijst.

Hoe zwaar uw server het te verduren krijgt, ziet u met één regel. Tel de mislukte aanmeldingen van de afgelopen 24 uur:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)} -ErrorAction SilentlyContinue | Measure-Object | Select-Object -ExpandProperty Count

Een interne server zonder bereikbaarheid vanaf het internet zit doorgaans op enkele tientallen per dag, meestal vergeten wachtwoorden en oude serviceaccounts. Een server met een open 3389 zit al snel op vier- tot vijfcijferige aantallen. Dat getal is uw meetlat: na de maatregelen hieronder hoort het ordes van grootte lager te liggen. Antwoordt Get-WinEvent met de melding "Er zijn geen gebeurtenissen gevonden die overeenkomen met de opgegeven selectiecriteria", dan legt uw server mislukte aanmeldingen helemaal niet vast. Dat repareren wij verderop.

Vóór de eerste wijziging: de weg terug veiligstellen

Elk van de volgende maatregelen kan u buitensluiten. Bij een server die u alleen via RDP bereikt, is dat het einde van de sessie en het begin van een lange avond. Drie voorzorgsmaatregelen kosten vijf minuten en voorkomen precies dat.

Ten eerste: Controleer of u een console hebt die los van RDP werkt. Bij de KVM-rootservers van KernelHost vindt u in het klantenpaneel een VNC-console die rechtstreeks op het beeldscherm van de virtuele machine kijkt. Die werkt ook nog als firewall, netwerk en de RDP-service tegelijk stuk zijn. Open hem één keer bij wijze van test voordat u iets wijzigt, niet erna.

Ten tweede: Maak een tweede beheerdersaccount aan, zodat een vergrendeld account niet hetzelfde betekent als een verloren server. De groepsnamen zijn taalafhankelijk, daarom werken wij met de vaste SID's (S-1-5-32-544 is de lokale groep Administrators, S-1-5-32-555 de groep voor de gebruikers van extern bureaublad):

New-LocalUser -Name 'kh-adm' -Password (Read-Host -AsSecureString -Prompt 'Wachtwoord') -FullName 'Onderhoudsaccount' -PasswordNeverExpires
Add-LocalGroupMember -SID 'S-1-5-32-544' -Member 'kh-adm'
Add-LocalGroupMember -SID 'S-1-5-32-555' -Member 'kh-adm'

De derde regel is strikt genomen overbodig, omdat leden van de lokale groep Administrators sowieso via RDP binnenkomen. Kwaad kan hij niet, en hij maakt de bedoeling zichtbaar mocht u het account later uit de groep Administrators halen.

Ten derde: Laat de RDP-sessie waarin u werkt tijdens de hele omzetting openstaan en test elke wijziging met een tweede, nieuwe verbinding. Een bestaande sessie wordt door nieuwe firewallregels niet meteen verbroken, een nieuwe verbinding mislukt daarentegen direct. Zo merkt u de fout op zolang u hem nog kunt terugdraaien.

Verificatie op netwerkniveau afdwingen

Zonder verificatie op netwerkniveau (Engels: Network Level Authentication, kortweg NLA) bouwt de server eerst een sessie op, tekent hij een aanmeldscherm en vraagt hij daarna pas om de inloggegevens. Elke anonieme verbindingspoging kost zo werkgeheugen en CPU, en de complete code achter dat aanmeldscherm is al bereikbaar vóór enige authenticatie. Precies daar zaten de zware RDP-kwetsbaarheden uit het verleden.

Met NLA controleert de server de inloggegevens via CredSSP, nog voordat er ook maar een sessie ontstaat. Een bot zonder geldige gegevens krijgt niets anders dan een geweigerde TLS-verbinding.

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value 1
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'SecurityLayer' -Value 2

SecurityLayer op 2 dwingt TLS af voor de onderhandeling. De waarde 1 (onderhandelen) laat een client desnoods terugvallen op de oude RDP-beveiligingslaag, 0 is die oude laag zonder TLS. Controleren:

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' | Select-Object UserAuthentication, SecurityLayer

Een herstart is niet nodig, de waarden gelden voor elke nieuw opgebouwde verbinding. Bestaande sessies lopen ongewijzigd door, wat handig is als u net bezig bent een client buiten te sluiten.

Als er daarna niemand meer binnenkomt

Na het inschakelen van NLA duiken er regelmatig twee foutbeelden op.

"Voor de externe computer is verificatie op netwerkniveau vereist, die door uw computer niet wordt ondersteund. Neem voor hulp contact op met de systeembeheerder of met de technische ondersteuning." De client is te oud of spreekt geen CredSSP. Actuele Windows-clients kunnen dit al jaren. Onder Linux vraagt FreeRDP om de schakelaar /sec:nla en Remmina om het beveiligingsprotocol op NLA, en zeer oude macOS-clients lopen sowieso vast. De oplossing is altijd de nieuwere client, nooit het uitschakelen van NLA.

Het inloggen mislukt terwijl het wachtwoord klopt. Dat is de valkuil die de meeste handleidingen verzwijgen: staat bij een account "Gebruiker moet wachtwoord wijzigen bij volgende aanmelding" aan of is het wachtwoord verlopen, dan kan dat account met NLA actief helemaal niet meer inloggen. CredSSP kent geen wachtwoordwijziging, dat is zo bedoeld. Afhankelijk van de versie meldt de server een verificatiefout of gewoon onjuiste inloggegevens. De uitweg loopt via de console in het klantenpaneel, of u zondert onderhoudsaccounts uit van de vervaltermijn:

Set-LocalUser -Name 'kh-adm' -PasswordNeverExpires $true

Accountvergrendeling: de effectiefste losse instelling

Een sterk wachtwoord beschermt tegen raden, een accountvergrendeling beschermt tegen onbeperkt raden. Zonder vergrendeling mag een aanvaller miljoenen pogingen per week doen, met vergrendeling zijn het er tien per kwartier. Zet de drempelwaarde, de vergrendelingsduur en het observatievenster in één aanroep, anders weigert Windows de duur zolang de drempelwaarde nog op 0 staat:

net accounts /lockoutthreshold:10 /lockoutduration:15 /lockoutwindow:15

De vergrendelingsduur moet altijd groter zijn dan of gelijk aan het observatievenster. Het resultaat controleren:

net accounts

Nieuwere Windows-versies brengen al een standaardwaarde in deze orde van grootte mee, oudere installaties en veel images van aanbieders niet. Controleren kost niets.

Het ingebouwde Administrator-account meenemen

Historisch was juist het account dat elke aanvaller als eerste probeert, uitgezonderd van de vergrendeling. Daarvoor bestaat het beleid "Vergrendeling van Administrator-account toestaan". Dat vereist echter een nieuwere build, namelijk Windows 11 22H2 respectievelijk Windows Server 2025. Op een Windows Server 2022 (build 20348) bevat de export van het beveiligingsbeleid de regel AllowAdministratorLockout helemaal niet, in de sectie [System Access] staan daar alleen waarden als LockoutBadCount en MinimumPasswordLength. Controleer daarom eerst wat uw systeem werkelijk exporteert:

secedit /export /cfg C:\secpol.inf
Select-String -Path C:\secpol.inf -Pattern 'AllowAdministratorLockout'

Komt daar geen treffer uit, dan kent uw build het beleid niet en is deze paragraaf voor u afgehandeld. Precies hier ligt de valkuil die de meeste handleidingen veroorzaken: de gebruikelijke oneliner met -replace vervangt een tekenreeks die helemaal niet in het bestand staat, maar meldt geen fout, en het daaropvolgende secedit /configure bevestigt netjes met succes. U denkt daarna dat de vergrendeling van Administrator actief is, terwijl er niets is veranderd.

Op een build die het beleid wel kent, wijzigt u de regel als die er staat en voegt u hem anders toe. Deze versie dekt beide gevallen af:

$c = Get-Content C:\secpol.inf
if ($c -notmatch 'AllowAdministratorLockout') { $c = $c -replace '(LockoutBadCount = \d+)', "`$1`r`nAllowAdministratorLockout = 1" } else { $c = $c -replace 'AllowAdministratorLockout = 0','AllowAdministratorLockout = 1' }
$c | Set-Content C:\secpol.inf -Encoding Unicode

De -Encoding Unicode is verplicht en geen detail: het INF-bestand moet UTF-16 LE met byte-order-mark zijn. Set-Content schrijft in Windows PowerShell 5.1 anders ANSI weg, en secedit weigert het bestand dan. Vóór het terugschrijven controleert secedit /validate C:\secpol.inf het bestand, daarna:

secedit /configure /db C:\Windows\security\local.sdb /cfg C:\secpol.inf /areas SECURITYPOLICY

En lees daarna beslist na, want een geslaagde secedit-run bewijst op dit punt niets. Exporteer het beleid opnieuw naar een tweede bestand en kijk of de waarde er werkelijk met 1 in staat.

Op een domeincontroller hebben deze lokale instellingen geen effect. Daar hoort het vergrendelingsbeleid in de Default Domain Policy, onder Computerconfiguratie, Windows-instellingen, Beveiligingsinstellingen, Accountbeleid.

De keerzijde en hoe u weer binnenkomt

Een accountvergrendeling is ook een wapen tegen u: wie uw gebruikersnaam kent, kan het account permanent vergrendeld houden door elke 15 minuten tien foute wachtwoorden te sturen. Juist daarom is de vergrendeling pas de tweede verdedigingslinie, de eerste is de IP-beperking uit de volgende paragraaf.

Is een lokaal account vergrendeld, dan meldt de client zoiets als "Het account waarnaar wordt verwezen, is momenteel vergrendeld en kan niet worden gebruikt om aan te melden". De eenvoudigste weg terug is afwachten, want na afloop van de vergrendelingsduur ontgrendelt Windows het account vanzelf. Wie niet wil wachten, ontgrendelt via de console:

$u = [ADSI]"WinNT://./kh-adm,user"; $u.IsAccountLocked = $false; $u.SetInfo()

In Active Directory kan het korter met Unlock-ADAccount -Identity kh-adm.

Wachtwoorden die een vergrendeling pas zinvol maken

Tien pogingen per kwartier zijn alleen een horde als het wachtwoord niet op plek drie van elke lijst staat. De minimumlengte en de complexiteit stelt u zo in:

net accounts /minpwlen:14

De complexiteitsregel zit opnieuw in het beveiligingsbeleid, sectie [System Access], sleutel PasswordComplexity = 1. De weg ernaartoe is dezelfde als hierboven met secedit.

Twee punten uit de praktijk. Ten eerste levert een gedwongen wachtwoordwissel elke 30 dagen aantoonbaar weinig op en veroorzaakt hij in combinatie met NLA precies het aanmeldprobleem uit de vorige paragraaf. Lange wachtwoorden die u één keer instelt en in een wachtwoordmanager bewaart, werken beter. Ten tweede geldt het beleid alleen voor nieuw ingestelde wachtwoorden. Een bestaand wachtwoord van zes tekens blijft geldig totdat u het wijzigt.

Toegang beperken tot bekende IP-adressen

Dit is de maatregel die het aanvalsverkeer werkelijk beëindigt, en wel volledig. Alle regels uit de groep voor extern bureaublad laten zich tot een adreslijst beperken. Gebruik de taalneutrale groepsaanduiding, zodat het script ook op Engelstalige installaties werkt:

Get-NetFirewallRule -Group '@FirewallAPI.dll,-28752' | Select-Object Name, DisplayName, Enabled, Profile

Set-NetFirewallRule -Group '@FirewallAPI.dll,-28752' -RemoteAddress @('203.0.113.10','198.51.100.0/24')

Verwacht daarbij meer treffers dan u regels verwacht. -Group raakt alle regels van de groep aan, op een testsysteem waren dat er zes, inclusief de schaduwregels en extra kopieën met een GUID als naam in het profiel Public. Dat is zo bedoeld en ook juist, want anders zou een van die kopieën open blijven staan. De opsomming met Get-NetFirewallRule hierboven laat u vooraf zien wat er geraakt wordt.

Controleren welke adressen er werkelijk zijn opgeslagen:

Get-NetFirewallRule -Group '@FirewallAPI.dll,-28752' | Get-NetFirewallAddressFilter

Hebt u de poort gewijzigd, dan werken de ingebouwde regels niet meer, want die zitten vast aan 3389. Dan hebt u een eigen regel nodig:

New-NetFirewallRule -DisplayName 'RDP beperkt' -Direction Inbound -Protocol TCP -LocalPort 34567 -RemoteAddress '203.0.113.10' -Action Allow -Profile Any

Het reddingsanker tegen uw eigen firewallregel

Wie zijn IP-adres verkeerd overtypt of een dynamisch adres invult, sluit zichzelf gegarandeerd buiten. Maak daarom vooraf een taak aan die de beperking na tien minuten vanzelf terugdraait:

Set-Content -Path C:\rdp-redding.ps1 -Value "Set-NetFirewallRule -Group '@FirewallAPI.dll,-28752' -RemoteAddress Any"

Register-ScheduledTask -TaskName 'RDP-Redding' -Action (New-ScheduledTaskAction -Execute 'powershell.exe' -Argument '-ExecutionPolicy Bypass -File C:\rdp-redding.ps1') -Trigger (New-ScheduledTaskTrigger -Once -At (Get-Date).AddMinutes(10)) -User 'SYSTEM' -RunLevel Highest

Werkt de nieuwe verbinding, dan verwijdert u de taak weer:

Unregister-ScheduledTask -TaskName 'RDP-Redding' -Confirm:$false

Hebt u geen vast IP-adres, dan is de nette oplossing om RDP helemaal niet op het internet te zetten, maar via een VPN te bereiken. Hoe u dat opzet, leest u in onze handleiding over de WireGuard-VPN-server. De server luistert dan alleen nog op het VPN-adres, en poort 3389 verdwijnt volledig van het internet.

De poort wijzigen en wat dat werkelijk oplevert

Een andere poort is geen beveiligingsmaatregel, maar een maatregel tegen de ruis. De grote massa bots scant uitsluitend 3389 en vindt u daarna niet meer, wat uw 4625-aantal doorgaans drastisch verlaagt en de gebeurtenislogboeken weer leesbaar maakt. Wie gericht zoekt, vindt de dienst alsnog: zoekmachines voor open diensten herkennen RDP aan de vingerafdruk van het protocol, ongeacht de poort, en een volledige poortscan over 65535 poorten duurt seconden.

De poortwissel is dus zinvol als aanvulling, maar nooit als vervanging van NLA, accountvergrendeling en adresbeperking. De praktische uitvoering, inclusief het deel dat vrijwel alle handleidingen fout doen (namelijk zonder herstart), hebben wij apart beschreven: RDP-poort wijzigen zonder herstart. Denk er in elk geval aan om voor de nieuwe poort een firewallregel aan te maken voordat u de dienst omzet.

Aanmeldlogboeken uitlezen

Eerst moet de logging natuurlijk wel ingeschakeld zijn. De namen van de subcategorieën van auditpol zijn vertaald, waardoor een Engelstalig commando op een Nederlandstalig systeem mislukt met "Fout 0x00000057 opgetreden: De parameter is onjuist." De GUID werkt daarentegen op elke taalversie:

auditpol /set '/subcategory:{0CCE9215-69AE-11D9-BED3-505054503030}' /success:enable /failure:enable

auditpol /get '/subcategory:{0CCE9215-69AE-11D9-BED3-505054503030}'

De enkele aanhalingstekens om de hele parameter zijn geen schoonheidsfoutje, maar dwingend nodig. PowerShell leest de accolades anders als een scriptblok en verwijdert ze, uit één argument worden er drie, en auditpol breekt af met Fout 0x00000057 opgetreden: De parameter is onjuist. en exitcode 87, gevolgd door de helptekst. In cmd.exe werkt de schrijfwijze zonder aanhalingstekens, in PowerShell niet. Mét aanhalingstekens lopen beide door met exitcode 0, en de controlevraag antwoordt dan met Aanmelden Geslaagd en mislukt.

Onder vuur rolt het beveiligingslogboek binnen enkele uren om en overschrijft het precies de vermeldingen die u nodig hebt. Geef het meer ruimte:

wevtutil sl Security /ms:1073741824

Daarna de meest voorkomende bronadressen van de afgelopen week, gesorteerd op aantal. De variant via de XML-structuur is de robuuste, omdat die niet van de veldvolgorde afhangt:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-7)} -ErrorAction SilentlyContinue | ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data | Where-Object { $_.Name -eq 'IpAddress' } | Select-Object -ExpandProperty '#text' } | Group-Object | Sort-Object Count -Descending | Select-Object -First 15 Count, Name

De -ErrorAction SilentlyContinue hoort bij elk van deze aanroepen. Get-WinEvent breekt met een rode fout af zodra er in de periode geen enkele passende gebeurtenis is: "Er zijn geen gebeurtenissen gevonden die overeenkomen met de opgegeven selectiecriteria." Op een net beveiligde server is dat juist het normale geval, het commando mislukt dus uitgerekend bij het succes waar deze handleiding op mikt.

De beslissende vraag is echter niet wie het geprobeerd heeft, maar of het iemand gelukt is. Geslaagde aanmeldingen via extern bureaublad dragen gebeurtenis-ID 4624 met aanmeldingstype 10 (RemoteInteractive):

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddDays(-7)} -ErrorAction SilentlyContinue | Where-Object { $_.Properties[8].Value -eq 10 } | Select-Object TimeCreated, @{n='Gebruiker';e={$_.Properties[5].Value}}, @{n='Bron';e={$_.Properties[18].Value}} | Format-Table -AutoSize

Staat daar een gebruikersnaam of een bronadres dat u niet kunt thuisbrengen, dan heeft iemand een geldig wachtwoord gevonden. Dan helpt het aanscherpen van het beleid niet meer, dan hoort de server opnieuw opgezet te worden.

Daarnaast loont een blik in het eigen RDP-logboek. Gebeurtenis 1149 noemt de gebruiker, het domein en het bronadres van elke geautoriseerde verbinding op één regel:

Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational' -FilterXPath '*[System[EventID=1149]]' -MaxEvents 25 | Format-List TimeCreated, Message

Administrator hernoemen, beter nog uitschakelen

Het ingebouwde Administrator-account is de enige gebruikersnaam die elke aanvaller zeker kent. Hernoemen kost niets:

Rename-LocalUser -Name 'Administrator' -NewName 'kh-svc'

Wees u wel bewust van de beperking daarvan: de SID van het account eindigt nog steeds op -500, en elke geauthenticeerde toegang kan de nieuwe naam daarmee opzoeken. Tegen massale bots werkt het hernoemen, tegen een gerichte aanvaller die al ergens een voet tussen de deur heeft niet. Zo vindt u het account ondanks de nieuwe naam:

Get-LocalUser | Where-Object { $_.SID.Value -like '*-500' } | Select-Object Name, Enabled

Duidelijk effectiever is het om het ingebouwde account helemaal uit te schakelen, nadat uw eigen beheerdersaccount uit de paragraaf "De weg terug veiligstellen" aantoonbaar werkt. Test het inloggen met het nieuwe account in een tweede sessie, en pas dan:

Disable-LocalUser -Name 'kh-svc'

Beperk de RDP-toegang bovendien tot de personen die hem nodig hebben. Standaard mag elk lid van de lokale groep Administrators via RDP naar binnen, ook serviceaccounts die dat nooit zouden moeten doen. Wie er op dit moment mag, laat dit zien:

Get-LocalGroupMember -SID 'S-1-5-32-555'

Waaraan u ziet dat het werkelijk gelukt is

Afvinken in plaats van hopen. Deze vijf controles vertellen u of de omzetting is aangekomen:

1. NLA: Get-ItemProperty op RDP-Tcp levert UserAuthentication : 1 en SecurityLayer : 2 op. Een nieuwe verbinding vraagt nu vóór het opbouwen van de verbinding om de inloggegevens, niet pas op een aanmeldscherm in het venster.
2. Vergrendeling: net accounts toont een vergrendelingsdrempel die niet "Nooit" is. Tegentest met een wegwerpaccount: na het elfde foute wachtwoord moet de client de vergrendelingsmelding tonen, niet meer de melding over onjuiste inloggegevens.
3. Firewall: Get-NetFirewallAddressFilter toont uw adressen in plaats van Any. Een verbindingstest vanaf een vreemd adres moet uitlopen op een time-outfout, niet op een aanmeldverzoek. Controleer dat van buitenaf met Test-NetConnection -ComputerName uwserver -Port 3389, het resultaat moet TcpTestSucceeded : False luiden.
4. Logboeken: auditpol /get meldt voor de subcategorie geslaagd en mislukt.
5. Het getal: Tel de 4625-gebeurtenissen 24 uur na de omzetting opnieuw. Het moet duidelijk lager liggen. Blijft het hoog, dan werkt een van uw regels niet, meestal omdat er een tweede, ruimere firewallregel voor poort 3389 bestaat die een image van een aanbieder of een software-installatie heeft aangemaakt. Dit commando spoort hem op: Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 3389 } | Get-NetFirewallRule | Select-Object DisplayName, Enabled, Profile, Action. De volgorde in de pijplijn is met opzet zo gekozen. Draait u hem om en stuurt u eerst alle firewallregels door Get-NetFirewallPortFilter, dan duurt de aanroep gemeten ongeveer 12 seconden in plaats van één, en ontbreekt vooral de naam van de regel in de uitvoer: u ziet dan vier treffers zonder te weten welke regels dat zijn.

Bent u toch al bezig een server nieuw op te zetten, werk deze punten dan meteen aan het begin af in plaats van ze achteraf in te bouwen. Voor Linux-systemen geldt hetzelfde patroon met SSH in plaats van RDP, beschreven in SSH beveiligen en aanmelden met een sleutel instellen, en de volgorde van de eerste stappen vindt u in onze checklist voor nieuwe rootservers.

Wat RDP-hardening niet afdekt

De maatregelen hierboven beschermen tegen aanmeldpogingen. Ze beschermen niet tegen volume-aanvallen die de server via de uplink onbereikbaar moeten maken. Daartegen helpt alleen filtering in het netwerk ervoor. Hoe die aanvallen werken, leest u in Wat is een DDoS-aanval, en welke voorzorgen aan de serverkant zinvol blijven in Server tegen DDoS-aanvallen beschermen. Alle servers van KernelHost staan in het datacenter maincubes in Frankfurt am Main achter een filtering die aanvalsverkeer al vóór de server wegvangt.

En ze vervangen geen back-up. Een server waarop iemand met succes heeft ingelogd, is niet meer te vertrouwen, hoe snel u het wachtwoord daarna ook wijzigt. De enige betrouwbare weg terug is een back-up van vóór het incident.