RDS performance-problemen oplossen

Performance problemen met Remote Desktop (RDS) servers komen vaak voor, met name bij grotere RDS-servers. Dit is voor een groot deel het gevolg van instellingen binnen Windows Server die Microsoft automatisch levert, maar lang niet altijd geoptimaliseerd zijn voor virtuele machines.
In dit artikel laten we twee van de meest voorkomende oorzaken zien en leggen we uit hoe je die kan oplossen.

Windows Power Settings
De eerste grote boosdoener, zijn de stroominstellingen in Windows Server. De specifieke instellingen waar het hier om gaat zijn niet terug te zien wanneer je via Windows-start > Edit Power Plan de instellingen aanpast. Het gaat hier specifiek om twee opties:

TL;DR: Windows Server probeert waar mogelijk energie te besparen door de CPU-clockfrequentie en het CPU-voltage te verlagen. Daarnaast worden waar mogelijk cores in slaapstand geplaatst.
Ga naar stap 1 om deze opties uit te schakelen.

Voltage en CPU-frequentie van de CPU aanpassen
Processors schakelen tussen performance states (P-states). Deze P-states beheren het voltage en de CPU-frequentie van de CPU. Als je Windows-Server inschat dat er performance bespaart kan worden, zorgt deze optie er voor dat er minder stroom naar de processor gaat en de clockfrequentie omlaag wordt geschaald.
Voor de laagst mogelijke latency, maximale CPU-frequentie en simpelweg de hoogste performance, kun je je Windows-Server instellen met een 100% minimum processor performance. Het voltage en de CPU-frequentie van je processor worden dan niet meer naar beneden aangepast.

Dynamisch aanpassen van beschikbare CPU cores (core parking)
De processor power management (PPM) engine en de Windows scheduler passen samen dynamisch het aantal cores aan dat beschikbaar is om processen uit te voeren. In de praktijk kan dit ertoe leiden dat (doorgaans tijdelijk) je Windows Server bijvoorbeeld inschat dat 2 van de cores genoeg zijn. Heeft je VPS er 8, dan worden de andere 6 ‘geparkeerd’.
Cores die geparkeerd worden, krijgen geen processen toegewezen en droppen in een zeer lage stroom state wanneer ze geen andere taken zoals interrupts verwerken (interrupts zijn verzoeken van een hardware component aan een andere hardware component). Het doel van deze functionaliteit is om zoveel mogelijk stroom te besparen.
Voor maximale performance van je server kun je simpelweg deze functionaliteit uitzetten.

Overige opties
Er zijn meer finetuning opties beschikbaar wanneer je tussen besparing en performance wil balanceren. We laten in dit artikel enkel zien wat nodig is om voor 100% CPU-performance te kiezen.

Hoe pas je deze opties aan?

Stap 1
De hierboven besproken opties beheer je via Powershell.
Verbind via Remote Desktop met je Windows Server en start Powershell als administrator (Start > Powershell > Rechter muisknop > Uitvoeren als administrator).

 

Stap 2
Voer de onderstaande commando’s uit:

Powercfg -setacvalueindex scheme_current sub_processor PROCTHROTTLEMIN 100
Powercfg -setacvalueindex scheme_current sub_processor CPMINCORES 100
Powercfg -setactive scheme_current

Toelichting
• Powercfg -setacvalueindex scheme_current sub_processor PROCTHROTTLEMIN 100:
Deze optie zorgt ervoor dat de processor performance op minimaal 100% staat. Er wordt dan geen verlaging van de CPU-clockfrequentie of CPU-voltage meer toegepast.
• Powercfg -setacvalueindex scheme_current sub_processor CPMINCORES 100:
Alle cores blijven paraat en worden niet meer weg geparkeerd in een energiebesparende stand.
• Powercfg -setactive scheme_current:
Verwerk de bovenstaande wijzigingen. Er is geen herstart van je VPS nodig.

Wil je zien welke opties allemaal op je huidige powerplan worden toegepast? Gebruik dan het commando:

powercfg /query scheme_current

Let wel op dat niet alle waardes overeenkomen met percentages. 0x00000000 – 0x00000064 is een bereik van 0-100%
That’s it! Je CPU is nu geconfigureerd voor 100% performance. Dat brengt ons bij de volgende bottleneck:

Windows Firewall

TL;DR: Windows Firewall maakt voor iedere nieuwe RDS-verbinding dezelfde 11 firewall regels aan. De regels worden niet verwijdert maar wel elke keer ingeladen, waardoor inloggen via RDS steeds trager wordt.
Ga naar stap 1 om automatisch de regels te laten verwijderen na het verbreken van een RDS-sessie.

Wanneer je via Remote Desktop met je Windows Server verbindt, maakt Windows Firewall 11 regels aan voor die specifieke gebruiker. Die regels worden echter niet verwijdert wanneer je je RDS-verbinding verbreekt. Het gevolg hiervan is dat telkens dezelfde regels opnieuw worden aangemaakt, terwijl die eigenlijk al bestaan.

Op servers met meerdere RDS-gebruikers kan dit ervoor zorgen dat je op een gegeven moment duizenden, zo niet tienduizenden firewall regels hebt, die compleet overbodig zijn, maar wel worden ingeladen wanneer je verbindt via RDS. Je ziet dit terug doordat na het inloggen via RDS je enige tijd een zwart scherm te zien krijgt.

De oplossing hiervoor is om bestaande regels die op deze manier zijn aangemaakt te verwijderen, de betreffende registry keys op te schonen en een patch van Microsoft via het register in te schakelen.

Voor Windows Server 2016 moet update KB4467684 geïnstalleerd zijn en voor Windows Server 2019 update KB4490481. Deze zijn automatisch geïnstalleerd als alle recente Windows updates op je server zijn geïnstalleerd.

Stap 1
Verbind via Remote Desktop met je Windows Server en start Powershell als administrator (Start > Powershell > Rechter muisknop > Uitvoeren als administrator).

Stap 2
Voer het volgende commando uit:

reg delete “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System” /va /f

 

Stap 3
Sluit Power Shell niet af, maar druk op de Windows Start-knop, zoek op ‘Regedit’ en klik op ‘Registry Editor’ in de resultaten.

Stap 4
Kopieer en plak in het zoekveld bovenaan de waarde
‘HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy’,
Klik met de rechter muisknop op een lege plek aan de rechterkant en selecteer ‘New’ > ‘DWORD (32 bit) Value’.

Stap 5
Verander de naam van de nieuwe registry key naar ‘DeleteUserAppContainersOnLogoff’, dubbelklik er op en verander de waarde naar 1.

Stap 6
Keer terug naar PowerShell en kopieer en plak daar de onderstaande code in (let op de scrollbalk). Deze zullen over meerdere regels worden uitgevoerd en voor de laatste regel moet je nog een keer op ‘Enter’ drukken.

$FWInboundRules = Get-NetFirewallRule -Direction Inbound |Where {$_.Owner -ne $Null} | sort Displayname, Owner
$FWInboundRulesUnique = Get-NetFirewallRule -Direction Inbound |Where {$_.Owner -ne $Null} | sort Displayname, Owner -Unique
Write-Host “# inbound rules : ” $FWInboundRules.Count
Write-Host “# inbound rules (Unique): ” $FWInboundRulesUnique.Count
if ($FWInboundRules.Count -ne $FWInboundRulesUnique.Count) {
Write-Host “# rules to remove : ” (Compare-Object -referenceObject $FWInboundRules -differenceObject $FWInboundRulesUnique).Count
Compare-Object -referenceObject $FWInboundRules -differenceObject $FWInboundRulesUnique | select -ExpandProperty inputobject |Remove-NetFirewallRule }

$FWOutboundRules = Get-NetFirewallRule -Direction Outbound |Where {$_.Owner -ne $Null} | sort Displayname, Owner
$FWOutboundRulesUnique = Get-NetFirewallRule -Direction Outbound |Where {$_.Owner -ne $Null} | sort Displayname, Owner -Unique
Write-Host “# outbound rules : : ” $FWOutboundRules.Count
Write-Host “# outbound rules (Unique): ” $FWOutboundRulesUnique.Count
if ($FWOutboundRules.Count -ne $FWOutboundRulesUnique.Count) {
Write-Host “# rules to remove : ” (Compare-Object -referenceObject $FWOutboundRules -differenceObject $FWOutboundRulesUnique).Count
Compare-Object -referenceObject $FWOutboundRules -differenceObject $FWOutboundRulesUnique | select -ExpandProperty inputobject |Remove-NetFirewallRule}

 

PS: Let in de output vooral ook op het aantal verwijderde regels. Op deze testserver is dit een klein aantal. Zie je hier een absurd hoog getal terug en merk je een verschil? We horen het graag van je!

Stap 7
Reboot tot slot je VPS en geniet van je verbeterde RDS-performance!

Daarmee zijn we aan het eind gekomen van deze handleiding voor het verbeteren van de performance van Remote Desktop binnen Windows Server.
Mocht je aan de hand van dit artikel nog vragen hebben, aarzel dan niet om ons te bellen/mailen/appen. Alle gegevens om ons te bereiken vind je onderaan deze pagina.

Twee derde aanvallen gebruiken brute force of ongepatchte kwetsbaarheid. Gemiddelde aanval duurt 90 dagen. Drie basisstappen om veilig te blijven.

Kasperksy heeft onderzoek gedaan naar cyberaanvallen en ontdekt dat bij zes op de tien aanvallen password brute force en vulnerability exploitation werden gebruikt om binnen te komen. Het bedrijf concludeert dat met patch management en goed wachtwoordbeleid de kans om gehackt te worden 60 procent lager is.

“Hoewel het belang van regelmatige patches en updates en het gebruik van sterke wachtwoorden, algemeen bekend is bij eenieder die ook maar klein beetje verstand heeft van cyberbeveiliging, blijven deze aspecten zwakke punten in een groot aantal organisaties en bieden ze een manier voor kwaadwillenden om het systeem van een bedrijf binnendringen,” zegt Kaspersky. “Als gevolg hiervan vormen beveiligingsproblemen met wachtwoorden en niet-gepatchte software de overgrote meerderheid van initiële toegangsvectoren tijdens aanvallen.”

Het onderzoek laat zien dat het aantal brute force-aanvallen het afgelopen haar bijna verdrievoudigt is en nu een derde van het aantal aanvallen omvat. Net zo groot is het aandeel van vulnerability exploitation. Erger is dat slechts bij een paar incidenten gebruik werd gemaakt van kwetsbaarheden uit 2020: veel vaker werden oudere, ongepatchte kwetsbaarheden gebuikt, “zoals CVE-2019-11510, CVE-2018-8453 en CVE-2017-0144.”

Aanvaller heeft geduld

Interessant is ook dat aanvallen lang duren. “Meer dan de helft van alle aanvallen die begonnen met kwaadaardige e-mails, brute force en misbruik van externe applicaties, werden gedetecteerd binnen een paar uren (18 procent) of dagen (55 procent),” aldus het bedrijf. “Echter, sommige van deze aanvallen duurden veel langer, met een gemiddelde duur van maximaal 90,4 dagen.” Het rapport laat zien dat aanvallen met een brute force-initialvector in theorie gemakkelijk te detecteren zijn, maar in de praktijk werd slechts een fractie geïdentificeerd, voordat ze een impact veroorzaakten.

“Zelfs als de IT-beveiligingsafdeling haar best doet om de veiligheid van de bedrijfsinfrastructuur te waarborgen, leiden factoren zoals het gebruik van legacy-besturingssystemen, low-end apparatuur, compatibiliteitsproblemen en menselijke factoren vaak tot beveiligingsinbreuken die de beveiliging van een organisatie in gevaar kunnen brengen.”

Tips om veilig te blijven

Drie tips van Kaspersky, naast het gebruiken van goede securitysoftware

1. Implementeer een robuust wachtwoordbeleid, inclusief multifactor-authenticatie (MFA) en tools voor identiteits- en toegangsbeheer.
2. Zorg ervoor dat patchbeheer of compensatiemaatregelen voor openbare toepassingen een nultolerantie hebben. Regelmatige updates van kwetsbaarheidsdetails van softwareleveranciers, het scannen van het netwerk op kwetsbaarheden en patchinstallaties zijn cruciaal voor de beveiliging van de infrastructuur van een bedrijf.
3. Zorg voor een hoog beveiligingsbewustzijn bij medewerkers. Het uitvoeren van uitgebreide en effectieve trainingsprogramma’s is een goede manier om de IT-afdeling tijd te besparen en goede resultaten te behalen.

De afgelopen dagen kwamen heftige koppen voorbij in het nieuws. Tienduizenden bedrijven zouden risico lopen door grote kwetsbaarheden in Microsoft Exchange Server. Die kwetsbaarheden zou bovendien actief misbruikt worden. Maar wat is er nu echt aan de hand en wat zijn de risico’s?

Op 2 maart 2021 bracht Microsoft een beveiligingsupdate uit voor Exchange Server 2019, 2016, 2013 en 2010. Deze update was opvallend, aangezien Microsoft normaal gesproken alleen beveiligingsupdates uitbrengt op de tweede dinsdag van de maand, ook wel bekend als Patch Tuesday. Deze patch wijkt af van die updatecadans. Ook bijzonder is dat Exchange Server 2010 ook nog een patch kreeg: de ondersteuning van deze elf jaar oude versie liep afgelopen oktober af.

Wat bleek: de patch dicht vier kwetsbaarheden die aanvallers toegang kunnen geven tot het volledige netwerk waar Exchange Server op geïnstalleerd is. Dit was een enorm probleem, aangezien tienduizenden, zo niet honderdduizenden bedrijven wereldwijd gebruikmaken van Exchange om hun e-mail- en kalenderdiensten mee te hosten. Deze kwetsbaarheden werden ook daadwerkelijk uitgebuit door hackers. Daarmee zijn deze kwetsbaarheden gemakkelijk het grootste cybersecurity-incident te noemen in zeker drie maanden. Dat klinkt misschien niet als veel, maar dat komt omdat we pas net het SolarWinds-debacle achter de rug hebben.

Zo werkt de hack

Microsoft heeft de hack uitgelegd in een blogpost. In totaal gaat het om vier kwetsbaarheden: CVE-2021-26855, CVE-2021-26857, CVE-2021-26858 en CVE-2021-27065. De aanvalsmethode, die Microsoft Hafnium noemt, maakt gebruik van een combinatie van deze vier kwetsbaarheden om binnen te dringen op het netwerk waar de Exchange-server op is aangesloten. Met de eerste kwetsbaarheid kon de aanvaller toegang tot de Exchange-server krijgen. Vervolgens gebruikten de aanvallers de tweede kwetsbaarheid om eigen code te draaien op de gekraakte machine. De derde en vierde kwetsbaarheden gaven de hacker schrijfrechten in elke map op de server.

Door de bovengenoemde kwetsbaarheden uit te buiten, kregen de hackers volledige toegang tot een Exchange-server. Met die toegang bouwden de hackers een zogenaamde web shell, waarmee de aangetaste server op afstand kon worden bestuurd. Aan de hand van die volledige toegang konden de hackers vervolgens gegevens vanaf het netwerk van een organisatie stelen.

De Taiwanese beveiligingsonderzoeker Cheng-Da Tsai en de leden van zijn team DEVCORE waren de kwetsbaarheden, die ze zelf ProxyLogon noemen, al sinds december op het spoor. Op de website die de beveiligingsonderzoeker over de kwetsbaarheden heeft gepubliceerd, vertelt hij dat hij Microsoft op 5 januari heeft ingelicht. Ondertussen hadden kwaadwillenden de kwetsbaarheden echter ook al gevonden.

De aanvallers

Microsoft heeft de aanvallers en hun exploit dus de naam Hafnium gegeven. Maar wie zitten er eigenlijk achter de aanval? Volgens verschillende experts gaat het om Chinese aanvallers. De aanvallers begonnen volgens beveiligingsbedrijf Volexity begin januari met het uitbuiten van de kwetsbaarheden. Microsoft en de Amerikaanse regering denken dat de aanvallers worden gesteund door de Chinese overheid, maar een woordvoerder van China ontkent deze beschuldigingen.

Waarschijnlijk zijn er inmiddels meer groepen actief, aangezien in de loop van februari de omvang van de aanval een stuk groter werd. Dit kon volgens experts twee dingen betekenen: of de aanvallers hadden hun tactiek gewijzigd, of er is een tweede groep die misbruik maakt van de kwetsbaarheden. In de tussentijd blijft de omvang van de aanvallen groeien, naarmate meer aanvallers op de kwetsbaarheden springen. Volgens ESET is het aantal hackergroepen die de kwetsbaarheden uitbuiten inmiddels tot boven de tien gestegen.

Op wie hebben de aanvallers het gemunt?

Aanvankelijk leken de aanvallen beperkt van omvang en alleen gericht op wat Reuters beschrijft als ‘klassieke doelwitten’. Aangenomen dat het inderdaad staatsgesteunde Chinese hackers waren, liggen overheidsorganisaties en grote bedrijven voor de hand. Veel van dergelijke grotere organisaties maken echter niet meer gebruik van een zelfbeheerde on-premise Exchange-server, maar zijn overgestapt naar een alternatief in de cloud, zoals Microsoft 365.

Exchange Server wordt echter nog breed gebruikt bij kleinere bedrijven en lokale overheidsorganisaties. Wereldwijd maken honderdduizenden organisaties gebruik van Exchange, en alle servers die simpelweg als mailserver zijn aangesloten op het internet en nog niet gepatcht zijn, zijn kwetsbaar. Meestal hebben dergelijke organisaties niet genoeg capaciteit om bovenop de ontwikkelingen in cyberbeveiliging te zitten. Daar maken aanvallers nu gretig gebruik van.

Inmiddels zou de web shell al op meer dan 5000 e-mailservers in meer dan 115 landen geïnstalleerd zijn, schrijft Threatpost. Vanuit verschillende hoeken en landen komen meldingen binnen van bedrijven en overheidsinstanties waarbij de Exchange-kwetsbaarheden uitgebuit zijn.

Ransomware-aanvallen

Kleinere organisaties hebben voor de aanvallers niet altijd boeiende informatie om te stelen. Ze zijn echter wel kwetsbaar, dus is het niet onlogisch dat de Exchange-hack leidt tot een golf van ransomware-aanvallen. Dergelijke kleine organisaties lopen niet alleen vaak achter met hun beveiliging, maar ze hebben ook hun back-ups vaak niet op orde. Dat maakt het waarschijnlijker dat ze toch betalen wanneer ze door ransomware geraakt worden.

Inmiddels zijn er al verschillende soorten ransomware opgedoken die inhaken op de ProxyLogon-kwetsbaarheden. BleepingComputer schrijft over een recente nieuwe vorm, genaamd DearCry. De software versleutelt alle bestanden op de getroffen computer tot .CRYPT-bestanden. Wanneer de ransomware alle bestanden heeft versleuteld, verschijnt er een tekstbestand genaamd readme.txt op het bureaublad. Daarin staan instructies over hoe het slachtoffer contact met de hacker kan opnemen. BleepingComputer meldt dat er in één geval 16.000 dollar aan losgeld gevraagd werd. Dat is ongeveer 13.500 euro.

Patch installeren mogelijk niet genoeg
Om er zeker van te zijn dat je geen kans loopt om slachtoffer te worden van een ransomware-aanval, is het van belang om onmiddellijk de patch te installeren die Microsoft op 2 maart heeft uitgebracht. Met die patch zijn de kwetsbaarheden opgelost en zijn nieuwe aanvallen niet meer mogelijk. De patch kan via Windows Update worden geïnstalleerd, maar de kwetsbaarheden kunnen ook direct opgelost worden met een script dat Microsoft op GitHub heeft gepubliceerd.

Als het niet op korte termijn haalbaar is om de patch te installeren, is het van belang om zo snel mogelijk de server af te sluiten van het internet. Een andere oplossing is alleen vertrouwde verbindingen met de server toestaan of de server achter een VPN te plaatsen.

Het oplossen van de kwetsbaarheden in Exchange sluit echter niet uit dat je alsnog geraakt wordt door een ransomware-aanval. Als de aanvaller er al in is geslaagd om binnen te dringen en de webshell te installeren, dan heeft hij een vrijuit bruikbare backdoor tot je systeem. Die backdoor wordt niet verwijderd door de patch.

Het verwijderen van dergelijke backdoors is uiteindelijk de taak van antivirussoftware op je systeem. Microsoft heeft een lijst met indicators of compromise (IoC’s) gepubliceerd die antivirusbedrijven kunnen gebruiken om mogelijke aanvallers op te sporen en uit te schakelen. Uiteraard kan de Defender-antivirussoftware van Microsoft zelf ook deze backdoors opsporen. Zorg er dus voor dat je antivirussoftware up-to-date is en je er zeker van bent dat die onlangs nog een virusscan heeft uitgevoerd. Het is overigens niet zeker dat Microsoft alle IoC’s heeft gevonden, dus blijf alert op mogelijk afwijkend gedrag van je server.

Ook is het van groot belang om een back-up van je belangrijke software te hebben waar een aangetaste server geen directe toegang tot heeft. Word je dan onverhoopt toch geraakt door ransomware, is de urgentie om te betalen lager.

Belang van goede cyberbeveiliging nogmaals onderstreept

De omvang van de Exchange-hack en het feit dat dit zo kort op de ontwikkelingen rond de SolarWinds-hack volgt, onderstrepen nogmaals het belang om altijd goed op je hoede te zijn op het gebied van cyberbeveiliging. Alhoewel gebruikers van Exchange Server weinig hadden kunnen doen om een directe aanval te vermijden, zijn er tal van maatregelen waarmee de impact geminimaliseerd kan worden.

In dit geval is vooral het belang van het snel installeren van updates en het opzetten van een goed back-upbeleid overduidelijk. Ook met een slimme indeling van het bedrijfsnetwerk kan worden voorkomen dat één gekraakte server je hele bedrijf platlegt.

De grootste winst is echter te behalen in het creëren van bewustzijn onder de kleinere organisaties die het wat minder nauw nemen met hun beveiliging. In dit soort gevallen kan een dergelijke kostenbesparing zomaar duizenden euro’s schelen.

Wireguard, de toekomst voor VPN-protocollen?

WireGuard is een nieuw VPN-protocol op basis van open source dat als doel heeft om het proces voor het versleutelen van gegevens eenvoudiger te maken. Naar eigen zeggen is het protocol sneller en flexibeler dan OpenVPN en IKEv2. Over het algemeen worden deze twee beschouwd als de beste protocollen die er beschikbaar zijn.

WireGuard heeft met aanzienlijk lagere pingtijden (een maatstaf voor de totale netwerksnelheid) en stabielere verbindingen dan OpenVPN tijdens tests al positieve resultaten opgeleverd.

Fans van WireGuard voorspellen zelfs dat dit “protocol van de toekomst” alle huidige opties voor VPN-tunneling voorbij zal streven. Maar het protocol staat nog aan het begin van de ontwikkelingsfase en er moeten nog een aantal problemen worden opgelost voordat het op grote schaal kan worden gebruikt.

Bedenker Jason Donenfeld heeft een indrukwekkend cv op het gebied van online beveiliging. Hij is de eerste om toe te geven dat er nog geen stabiele versie van WireGuard is. Maar volgens hem kan het uitgroeien tot een protocol dat de VPN-branche zal veranderen.

In het vervolg van dit artikel zullen we je meer inzicht in de voor- en nadelen van WireGuard geven en de huidige status, ontwikkeling en implementatie van het protocol bespreken.

Waarom het nieuwe protocol van WireGuard belangrijk is

De verschillende protocollen die door VPN’s worden gebruikt hebben allemaal een aantal voor- en nadelen. (Zo gaat snelheid bijvoorbeeld vaak ten koste van veiligheid). Maar WireGuard kan in potentie zeer veel voordelen bieden.

WireGuard wil vooral gebruiksgemak bieden en tijdens tests is gebleken dat het protocol hogere snelheden dan OpenVPN en het zeer snelle IPSec-protocol behaalt. Als het protocol op grote schaal wordt geïmplementeerd, is het de bedoeling dat zelfs handmatige netwerkconfiguratie vrij eenvoudig is uit te voeren.

De efficiënte manier voor het versleutelen van gegevens is een van de redenen waarom het protocol zeer snel en gebruiksvriendelijk is.

Het komt erop neer dat WireGuard in tegenstelling tot de meeste andere VPN’s geen gebruik van zeer lange kant-en-klare methoden voor versleuteling gebruikt. In plaats daarvan voegen de ontwikkelaars van WireGuard de elementen waaruit deze algoritmen bestaan (“primitieven” genoemd) op nieuwe manieren samen. Het doel is om de snelheid te bevorderen zonder dat dit ten koste van de veiligheid gaat.

WireGuard is met slechts 4000 regels met code ook veel minder omslachtig dan OpenVPN. Deze efficiënte manier van versleuteling wordt regelmatig gecontroleerd en verbeterd waardoor WireGuard minder kwetsbaarheden dan andere protocollen bevat.

Potentiële risico’s wanneer je WireGuard nu gebruikt

Ondanks de vele voordelen, zul je er goed over moeten nadenken als je WireGuard nu meteen wilt gebruiken. Zelfs de bedenker van het protocol zegt immers dat WireGuard zich nog in een experimentele fase bevindt.

Vanwege potentiële problemen op het gebied van stabiliteit is het daarom mogelijk dat WireGuard niet de indrukwekkende snelheden kan bieden die tijdens de snelheidstests worden behaald. En momenteel zijn er nog een aantal beveiligingsproblemen die moeten worden opgelost.

Private Internet Access (PIA) is een van de grootste voorstanders van het nieuwe protocol, maar de provider maakt op dit moment nog geen WireGuard-clients beschikbaar omdat er te weinig Windows-stuurprogramma’s voor zijn.

Donenfeld zelf waarschuwt VPN-gebruikers om nog niet volledig naar het nieuwe protocol over te schakelen omdat hij weet dat er nog veel werk te doen is voordat er een stabiele versie beschikbaar kan worden gemaakt.

Op dit moment zijn er ook te weinig partijen die geld in WireGuard willen investeren. Daarom willen we je aanraden om nog even te wachten voordat je het protocol uitprobeert, vooral omdat het gaat om opensourcesoftware waar geen technische ondersteuning voor is.