De vragen om te stellen:
- Waarom staat er een RDP naar de buitenwereld open?
- Een RDP heeft gewoonlijk eigen rechten nodig voor de escalatie boven die van de gebruiker.
Waarom staart een niet afschermde user (dus admin) open op de betreffende machine?
Eén situatie waar dat voorkomt is bij het uitbesteden van de ICT aan een externe partij. Dan wordt dat met de serviceverlening gemanaged dat die externe partij wel overal bij moet kunnen.

In dit geval van een teruggehackte encruptie en een bedrag van 540 euro (echt zo weinig?) is er weinig reden tot een cultuurverandering.

Indien je dan toch RDP toegang vanaf het Internet wil, gebruik dan altijd 2FA.

Wanneer het alleen voor leverancierstoegang is, gebruik altijd een IP accesslist die alleen toegang geeft vanaf de source IP's van die leveranciers.

Maar, in alle gevallen: 2FA en uiteraard kwetsbaarheden direct verhelpen.

Vroegahh....toen ik nog Windoos had werd RDP als eerste uitgezet.

Ik mis iets. Brute force geeft aan dat de aanvaller op zijn/haar gemak wachtwoorden heeft kunnen uitproberen, dat heeft de RDP/PPTP/gateway/broker/weetikveel server van het ziekenhuis toch in de gaten? Of waren de wachtwoorden ZO makkelijk dat het niet opviel?
Lijkt me toch reden voor in elk geval verandering van een paar instellingen. Of upgrade van RDP versie.

Klopt ph-cofi eens met je, ik mis dat ook. SecGuru_OTX zit ook met de directe server toegang met strikt toezicht op toegang met de bron. Ik zag laat een post van SecGuru_OTX met een kwaliteit dat ik niets meer te zeggen had. :<)

Ik zie wel veel RDP gebruik voor support naar werkplekken dat gaat op initiatief naar de helpdesk waarna je als werkplekgebruiker tijdens telefonisch contact nog een paar keer toestemming moet verlenen. Brute Force werkt dan echt niet. Een RDP naar een server is nodig omdat die dingen (virtueel) in afgeschermde ruimtes (of buiten de deur) staan waar je als OS beheerder gewoonlijk niets meer te zoeken hebt.

Sorry anoniem 11:02 voor je machientje thuis, in de professionele wereld gaat het er echt anders aan toe.

Heel nuttig in een beperkt aantal situaties. Ik denk aan (s)ftp connecties met vermijden user/password in files en een grid benadering waar je de service-accounts deelt over virtuele machines. Je zult dan ook wel iets met NSF doen. Het zijn de zaken met Linux waar je dat onder Windows niet eens merkt omdat er een domain technologie met trust filosofie bestaat. Dat is een wezenlijk verschil iets wat bij Linux niet eens echt bestaat (ja LDAP in de basis).

De werkelijkheid is veel weerbarstiger. Een systeem en applicatie landschap kent vele services met een boel functies. Wil je dat goed scheiden dan krijg je vele functionele accounts. (service administrators test rol-eigenaren). Het is iets waar -Nix beheerders een broertje dood aan hebben omdat ze dat veel te lastig vinden.

Rlogin login rsh er zijn met Linux nogal wat remote varianten naaste de gewone. https://linux.die.net/man/1/rlogin rssh is weer wat anders https://linux.die.net/man/1/rssh. Een X11 sessie doet een outbound call naar een X-server op een desktop. Het beheer voor Linux servers is nogal command-line minded, dat is wat anders dan een remote desktop.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Securing_Services.html


Waar heb ik problemen mee? Nou dat is het verschil tussen het login en rlogin attribuut met shell gebruik voor gebruikers.
Sinds de PDP tijd is de boel gevirtualiseerd en zijn de begrippen lastiger uit te leggen. Alles is tegenwoordig remote (putty-ssh) en zou heel dogmatisch verboden zijn omdat remote logins gevaarlijk zijn.

Terug naar je private key in je lokale putty omgeving (ssh). Stel het werk is geoutsourced dan heb je voor een bepaald service account een onbekend aantal ingehuurde externe personen. Als die onderling allemaal de private key gaan delen omdat het dan werkt dan heb je het equivalent van een sticky note op een terminal. Zoiets is niet controleerbaar.
Wat je wel kunt doen is een gecontroleerde externe verbinding open zetten enkel op vezoek/incident waarna een restricted user via sudo extra privileges krijgt voor de betreffende taak.

(het wat schimmige deel van het citaat is vervangen door ...)
Bij gebruik van SSH kan wel degelijk worden onderscheiden wie op één specifiek account een shell opent. Bij gebruik van public keys autenticeert de SSH daemon (server) de client op basis van diens sleutel waardoor meerdere gebruikers kunnen middels een eigen sleutel onder een bepaald account inloggen. De daemon kan een log bijhouden van de gebruikte identiteit op basis van de gebruikte sleutel. Dus meerdere gebruikers elk met eigen sleutel kunnen onder één en hetzelfde account opereren waarbij de SSH server logt wie wanneer het account heeft gebruikt (en kan nog veel meer loggen, eventueel i.c.m. PAM). Ontzegging van toegang tot het account kan eenvoudig door verwijdering van de publieke sleutel van de gebruiker.

In een eenvoudige opzet worden de public keys voor een account opgeslagen in het bestand ~/.ssh/authorized_keys, maar het gebruik van een directory server is ook zeer goed mogelijk (behalve AD nog vele, vele andere).

Ja je hebt gelijk. Met enkel het ssh/sftp inzetten is dat inderdaad zo mogelijk. En voor kleine groepjes beheerders voor wat high privileged accounts is het te doen als is de administratielast afwijkend en arbeidsintensief.

Wil je de acties kunnen bijhouden die onder zo'n high privileged account plaatsvinden (gangbaar bij root) dan vervalt dat.
Heb vele gebruikers die zo onder een enkele account werken dan is het werk wie wat doet niet echt meer traceerbaar.
De lastigste is een aparte service die wel de login(PAM) en shell kan gebruiken maar niet de SSH daemon gebruikt.