Een lezer vroeg me:
Vorige week gaf een van onze thuiswerkers aan niet meer in te kunnen loggen in ons ERP systeem dat we bij een derde afnemen. Het werkt op basis van remote app, oftewel bij activatie wordt op de achtergrond een remote desktop gestart. Na veel testen bleek de internetprovider van deze werknemer remote desktop categorisch tegen te houden. Zo kan zij niet werken! Staat de provider in zijn recht om dit zo te doen, zonder het zelfs maar te overleggen?Hoofdregel uit de wet is dat een internetprovider geen inkomend of uitgaand netwerkverkeer van haar klanten mag blokkeren. Dat volgt uit het beginsel van netneutraliteit en is in Europa in de wet verankerd (Verordening 2015/2120). Artikel 3 hiervan bepaalt:
1. Eindgebruikers hebben het recht om toegang te krijgen tot informatie en inhoud en deze te delen, toepassingen en diensten te gebruiken en aan te bieden, en gebruik te maken van de eindapparatuur van hun keuze, ongeacht de locatie van de eindgebruiker of de aanbieder, en ongeacht de locatie, herkomst of bestemming van de informatie, inhoud, toepassing of dienst, via hun internettoegangsdienst.Het gebruik van een remote desktop dienst om een systeem op afstand af te nemen valt hier onder, ook als je dit voor je werk doet terwijl het een consumentenabonnement is.
Dat wil echter niet zeggen dat een provider nooit ook maar enige byte tegen mag houden. De wet noemt een aantal uitzonderingen:
- Handelen op basis van een wettelijk verbod of gerechtelijk bevel
- Beschermen van de integriteit en de veiligheid van het netwerk
- Netwerkcongestie voorkomen of beperken
Ik vermoed dat deze provider door heeft dat het remote desktop protocol misbruikt wordt, onder meer door DDoS aanvallen te versterken of door bij onoplettende gebruikers van slecht geconfigureerde computers binnen te dringen. Omdat er (in ieder geval tot het begin van het coronathuiswerken) weinig mensen waren die op een consumentenlijn via RDP werken, is het dan logisch om deze poort dicht te zetten vanuit veiligheidsoverwegingen.
Nu is de situatie natuurlijk iets anders, hoewel het me wel verbaast dat de vraagsteller er nu pas achter komt. Mogelijk is de provider recent tot filteren overgegaan omdat ze een aanval te verduren hebben gehad. De juridische discussie of de poort dan weer open moet, en welke maatregelen de werknemer moet nemen, lijkt me dan een hele lastige. Ik zou dus eerder kijken of je de RDP toegang over een VPN kunt faciliteren, dat lijkt me sowieso een veiliger idee.
Arnoud
Ja maar VPN wordt ook misbruikt door hackers zelf. Dus die zetten ze ook dicht. En wist je hoeveel virus-infecties er plaats vinden via porno-sites? Blocked! En sowieso video over internet, dat vraagt om congesties. Magnietmeer.
Laat het duidelijk zijn; ik vind het geen lastige discussie. Als de klant dus niet gehackt was, maar legitiem gebruik maakt van RDP, dan is de ISP dus niet de integriteit of veiligheid van het netwerk aan het beschermen.
Wat je als ISP kunt doen is wat XS4all bijvoorbeeld deed: je filtert alles wat gevaarlijk is, maar geeft de klanten de optie om de filters stuk voor stuk uit te zetten.
Ik lees dat het misbruik van het remote desktop protocol te maken heeft met UDP. Als dat het geval is, lijkt het me voldoende om UDP poort 3389 te blokkeren, maar kan TCP poort 3389 open blijven. Voor zover ik weet werkt RDP prima met alleen TCP.
Los daarvan is het probleem met UDP juist aan de serverkant. Dus alleen als je een RDP server aan het internet hangt, is er een probleem. Ik begrijp dat de betreffende werknemer vanuit thuis een RDP server in de cloud probeert te bereiken, dan zou de internetprovider van die werknemer daar al helemaal geen probleem mee moeten hebben. In het artikel lees ik dat in het geval van thuiswerken, de werknemers ook vaak remote desktop aanzetten zodat systeembeheer kan inloggen op de pc van de werknemer in het geval van problemen. Dat is natuurlijk wel relevant voor de internetprovider van de werknemer.
Een meer generiek probleem met remote desktop is dat servers vaak slecht geconfigureerd/beveiligd zijn. Zoals een slecht wachtwoord op het administrator account. In dat opzicht kan ik me ook voorstellen dat internet providers de standaard RDP poorten voor ingaand verkeer blokkeren, ook TCP. Iemand die weet hoe je een remote desktop server veilig maakt, weet ook wel dat je het poortnummer kunt veranderen. Zolang de ISP geen deep packet inspection doet, heb je daarmee al het probleem van de blokkade omzeilt. Nog beter is het natuurlijk om RDP via een SSH tunnel te laten gaan.
Wanneer de ISP verkeer naar zijn klant-IP’s controleert op RDP verkeer, dan zou het logisch zijn om te controleren (zoals opgemerkt, dit is een laagdrempelige aanvalsvector voor malafide actoren), maar wanneer het om out-bound verkeer gaat (van de klant, naar een andere locatie), is er zelden echt iets aan de hand.
Waarom? RDP gebruikt ook gewoon SSL (TLS).
Ik heb hier maar beperkt verstand van, maar je gaat dan nog steeds over het boze internet en je bent dan bijvoorbeeld kwetsbaar voor ARP poisoning waarbij je op een andere server uitkomt. Ook is het toegang reguleren via VPN iets makkelijker dan wanneer je werknemers vanaf willekeurige IP-adressen bij je servers uit kunnen komen. Een IP-whitelist is vaak niet goed mogelijk als mensen vanaf consumenten-ISP’s internet op gaan met dynamic IP adressen. Maar ik sta graag gecorrigeerd.
Voor ARP poisoning moet je toegang tot een lokaal endpoint hebben, ofwel aan de client kant, of aan de server kant. Bovendien zal je ook een geldig certificaat voor die hostname moeten hebben. TLS zorgt niet alleen voor encryptie, het zorgt ook voor authenticatie van de webserver richting de gebruiker.
Dat verplaatst het probleem toch alleen maar naar de VPN gateway? Bovendien voeg je complexiteit toe en dus grotere kans op problemen.
IP-whitelists zijn ook erg 1995. Waarom zou je dat doen? Er is een login met 2FA die niet alleen afdoende autorisatie biedt maar ook de achterliggende infrastructuur afschermt voor (d)DoS aanvallen.
EDIT: excuus, ik zie nu pas het antwoord van “lezer”. Dit is wel wat mosterd na de maaltijd zo.
RDP gebruikt certificaten net zoals HTTPS dat doet zodat de gebruiker bij een MITM-aanval wordt gewaarschuwd (met deze popup). Met de optie authentication level:i:1 voorkom je dat een gebruiker de waarschuwing kan wegklikken en toch verbinding kan maken.
Hiermee verplaats je het probleem van de RDP-server naar de VPN-server. Dat kan wenselijk zijn als je naast de RDP-server nog andere services hebt, maar het is onzinnig om een VPN op te zetten enkel om RDP te faciliteren.Dank je, dat helpt. Ik denk dat dan alleen nog overblijft dat als je meerdere diensten op afstand wilt aanbieden aan je werknemers, dat dan een VPN handiger is als centrale toegangscontrole. Anders moet je bij elke dienst apart sterke authenticatie invoeren want je moet aannemen dat iedere dienst apart aangevallen wordt. Maar wie door de supersterk beveiligde VPN tunnel binnenkomt, zal wel een werknemer zijn.
(En natuurlijk het argument van deze ISP dat RDP verkeer heel vaak kwaadwillend is, dus door RDP over VPN te doen vergemakkelijk je de bestrijding van inbraken op computers via RDP.)
Maar je hebt al je bedrijfsapplicaties toch netjes achter SSO op je Active Directory hangen? Bovendien moet je nog steeds bij elke dienst authenticeren / autoriseren, anders geef je carte blanche aan iedereen op je VPN, ongeacht wat voor soort gebruiker het is.