Open RDP verbinding zonder VPN onveilig

[Verwijderd]

Sommige onder ons zetten nog steeds zomaar poortje 3389 naar hun server open
zodat heel de buitenwereld bij hun server kan.
Echter vroeg ik me laatst af wat er exact zo gevaarlijk aan is.
Data wordt niet gecodeerd verstuurd, dus deze is eventueel uit te lezen.
Maar wat voor programma's kunnen dit? Ik ben namelijk van het 'eerst zien' dan geloven :-)

Is een 2008 server die RDP naar de buitenwereld heeft openstaan echt zo makkelijk te hacken?

[To_Tall]

Verwijderd schreef op maandag 29 maart 2010 @ 10:45:
Sommige onder ons zetten nog steeds zomaar poortje 3389 naar hun server open
zodat heel de buitenwereld bij hun server kan.
Echter vroeg ik me laatst af wat er exact zo gevaarlijk aan is.
Data wordt niet gecodeerd verstuurd, dus deze is eventueel uit te lezen.
Maar wat voor programma's kunnen dit? Ik ben namelijk van het 'eerst zien' dan geloven :-)

Is een 2008 server die RDP naar de buitenwereld heeft openstaan echt zo makkelijk te hacken?

Ze kunnen zo bij je server. Waarna ze met hacks op je server kunnen komen.

http://www.google.nl/sear...8&startIndex=&startPage=1

via die poort heeft de hele wereld direct toegang tot je machine. Dat is niet iets wat je wilt delen met de hele wereld..

[Martine]

En wat als er direct achter het modem gewoon een windows xp machine staat, waarop 3389 ingeschakeld staat voor remote desktop?

[DiedX]

To_Tall schreef op maandag 29 maart 2010 @ 10:49:
[...]

http://www.google.nl/sear...8&startIndex=&startPage=1

Sorry, maar uit welke van deze links blijkt dat dit onveilig is?

De verbinding zelf is wel gecrypt (dus: niet iedereen kan het verkeer afluisteren tussen de client en de server), maar het is mogelijk om te gaan bruteforcen qua gebruikersnamen en wachtwoorden.

Oplossingen:

* Niet doen;
* Server 2008 (volgens mij?) ondersteund certificaten;
* Verdomd sterke wachtwoorden kiezen (zie ook: Niet doen)

[CherandarGuard]

Martine schreef op maandag 29 maart 2010 @ 10:51:
En wat als er direct achter het modem gewoon een windows xp machine staat, waarop 3389 ingeschakeld staat voor remote desktop?

Dan staat die dus open.
Wat is je punt?

[To_Tall]

DiedX schreef op maandag 29 maart 2010 @ 10:52:
[...]

Sorry, maar uit welke van deze links blijkt dat dit onveilig is?

Daar gaat het alleen niet om. Hiermee laat ik zien dat het mogenlijk is om RDP sessie te hacken. en dus met een bruteForce toegang tot je computer kan worden verkregen.

Daarnaast nogmaals NIET DOEN ;-)

[DiedX]

To_Tall schreef op maandag 29 maart 2010 @ 10:58:
[...]


Daar gaat het alleen niet om. Hiermee laat ik zien dat het mogenlijk is om RDP sessie te hacken. en dus met een bruteForce toegang tot je computer kan worden verkregen.

Daarnaast nogmaals NIET DOEN ;-)

Hiermee laat je een rij google-links zien, en niets met RDP Sessie hacken oid. Geef nu eens een concrete link als je wilt??

[MrHarry]

afgezien van het feit dat het niet aan te raden is kan je dit gewoon wel doen, echter moet je rekening ermee houden dat ze je een keer kunnen hacken, een brute force gaat mega lang duren want ze moeten gebruikersnaam/wachtwoorden zien te brute forcen, als je een niet standaard login naam hebt en een complex wachtwoord komen ze er niet zomaar in. Uiteraard is het dus aan te raden om een vpn te gebruiken voor rdp. Als je toch via rdp zonder vpn bereikbaar wilt zijn verander dan de rdp poort naar een hoog nummer om zo niet uit de standaard scans naar voren te laten komen....en uiteraard hoe kritisch is de server/omgeving die je open witl zetten? is dit een groot/klein bedrijf dan raad ik het ernstig af...voor thuis gebruik is het je eigen keuze.

[ajhaverkamp]

Wijzig in ieder geval de RDP poort.

"Security through obscurity", alle beetje helpen.

[Vicarious]

ajhaverkamp schreef op maandag 29 maart 2010 @ 11:16:
Wijzig in ieder geval de RDP poort.

"Security through obscurity"

Een methode waar ik geen fan van ben. Met een willekeurige portscan kunnen ze zo achterhalen welke poorten openstaan. Daarna even wat bekende services naar die poort laten connecten (ftp, sftp, ssh, telnet, http en https, rdp, ica) en je weet zo wat erachter zit.

Conclusie: niet doen. Gewoon een VPN opzetten om je server via RDP te benaderen.

[Paul]

"gewoon een VPN opzetten"

Wat is het verschil tussen het bruteforce van de username/password bij de VPN-login en bij de remote-desktop login?

Op beiden kun je lockout policies zetten of met 3rd party dingen in de weer om het ip te blocken.

Wij hebben een sterk wachtwoord op de Administrator user en een alternatieve poort. Af en toe de logs bekijken maar daar staan nooit inlogpogingen in. Op FTP des te meer, maar good luck met user Administrator bruteforcen, deze bestaat niet

[DiedX]

Paul Nieuwkamp schreef op maandag 29 maart 2010 @ 12:22:
"gewoon een VPN opzetten"

Wat is het verschil tussen het bruteforce van de username/password bij de VPN-login en bij de remote-desktop login?

Mijn VPN-Verbinding is geen Microsoft-product, en niet gekoppeld aan je AD-Account Mocht je VPN-Software van MS gebruiken, dan heb je gelijk...

[Powermage]

Dus omdat jou VPN oplossing niet op MS is gebasseerd wil dat direct zeggen dat je password niet te brute forcen is zonder enige lockout policy?

[Verwijderd]

Maar dat bruteforcen lukt toch niet zomaar... je moet dan eerst een enorme lijst met passwords aanmaken en dan maar hopen dat daar de juiste tussen zit. Bijv. H!u1s als password wordt dus nooit gehacked?

[Verwijderd]

Je TS direct van buiten benaderbaar aanbieden lijkt me vragen om problemen. Er hoeft maar 1 account geraden te worden (of via social engineering, trojan etc) om je TS volledig over te leveren aan buitenstaanders.

Ik zou er een of meerdere laagjes tussen zetten. Misschien iets in de trant van: http://technet.microsoft..../cc771530%28WS.10%29.aspx

Hier kan je ook nog het een en ander vandaan halen: http://www.windowsecurity...08-Terminal-Services.html

Het is dan niet een antwoord op WAAROM je iets niet moet doen. Wel HOE je het (kan) doen.
Overigens lijkt het me redelijk evident dat je niet wil dat 'anderen' toegang hebben tot jouw systeem(en)

[ Voor 8% gewijzigd door Verwijderd op 29-03-2010 12:47 ]

[LuckY]

Wil je het naar de buitenwereld opzetten maak dan inderdaad gebruik van een Lockoutpolicy, die na X logons account voor x tijd locked. Tevens moet je de Administrator account renamen naar een lang obscuur ding, die heb je toch niet nodig alleen in geval van nood. want op dit account gelden de restricties van de lockout policy niet. Tevens kan je nog met de standaard ms firewall gebruik maken van whitelisting van de cliënt. Dus alleen ip XXX mag connecten of iprange C.
Tevens moet je dan ook nog een goed wachtwoord hebben die Niet in een woordenboek staat, ,minimaal 3 van de 4 groepen bevat en het liefst boven de 8 karakters. Tevens gewoon van TLS en certificaten gebruik maken (al dan niet gesigned) tevens ook gebruik maken als functies zoals NLA. (alle kleine betjes helpen om het iets moeilijker te maken, echter is het nog goed mogelijk dat dit binnen een paar weken met een botnet is gekraakt).


Maar het belangrijkste blijft auditing, zelf de logon events in de gaten houden
Dit stond dus ook in het het bovenstaande artikel
Echter kan je het beste gebruik maken van de VPN oplossingen zoals hierboven aangekaart.

Verwijderd schreef op maandag 29 maart 2010 @ 12:46:
Je TS direct van buiten benaderbaar aanbieden lijkt me vragen om problemen. Er hoeft maar 1 account geraden te worden (of via social engineering, trojan etc) om je TS volledig over te leveren aan buitenstaanders.

Ik zou er een of meerdere laagjes tussen zetten. Misschien iets in de trant van: http://technet.microsoft..../cc771530%28WS.10%29.aspx

Hier kan je ook nog het een en ander vandaan halen: http://www.windowsecurity...08-Terminal-Services.html

Het is dan niet een antwoord op WAAROM je iets niet moet doen. Wel HOE je het (kan) doen.
Overigens lijkt het me redelijk evident dat je niet wil dat 'anderen' toegang hebben tot jouw systeem(en)

En de TS gateway is niet te bruteforcen ?

Verwijderd schreef op maandag 29 maart 2010 @ 12:42:
Maar dat bruteforcen lukt toch niet zomaar... je moet dan eerst een enorme lijst met passwords aanmaken en dan maar hopen dat daar de juiste tussen zit. Bijv. H!u1s als password wordt dus nooit gehacked?

Hoezo, niet een rainbowtable kan je gewoon aanlaten maken op basis van ascii.
Het kost tijd,storage en cpu kracht. echt je kan gewoon dingen laten autogenereren.

Paul Nieuwkamp schreef op maandag 29 maart 2010 @ 12:22:
"gewoon een VPN opzetten"

Wat is het verschil tussen het bruteforce van de username/password bij de VPN-login en bij de remote-desktop login?

Op beiden kun je lockout policies zetten of met 3rd party dingen in de weer om het ip te blocken.

Daar is ook geen verschil tussen, je moet ook iets toevoegen zoals een token, die je een extra coden mee geeft ter authenticatie.

Want dan moeten ze 3 dingen bruteforcen, een account naam, een password en een token die om de x minuten veranderd.

offtopic:
(ok, token is ook niet heilig want met bepaalde een bepaalde "2 bijbelsefiguren tools" kan je als je 2 opvolgende codes weet van je token de rest laten generen. "

[ Voor 58% gewijzigd door LuckY op 29-03-2010 13:23 ]

[Vicarious]

Paul Nieuwkamp schreef op maandag 29 maart 2010 @ 12:22:


Wat is het verschil tussen het bruteforce van de username/password bij de VPN-login en bij de remote-desktop login?

Omdat je met het rechtstreeks aanbieden van je Terminal Server niet alleen kwetsbaar bent voor brute force aanvallen, maar ook voor alle eventuele leaks en exploits die in het RDP protocol of de implementatie daarvan kunnen zitten.

[Paul]

Vicarious schreef op maandag 29 maart 2010 @ 13:36:

Dat argument gaat op voor _alles_ dat je aanbiedt, of dat nu RDP of VPN is

DiedX schreef op maandag 29 maart 2010 @ 12:25:
[...]

Mijn VPN-Verbinding is geen Microsoft-product, en niet gekoppeld aan je AD-Account Mocht je VPN-Software van MS gebruiken, dan heb je gelijk...

Zelfs geen RADIUS/IAS ? Maak je het jezelf dan niet veel moeilijker voor een klein beetje extra? Nu moet je op 2 plaatsen je wachtwoord aanpassen / users aanmaken, en ik gok zo dat 80% van je users 'dan maar handmatig' beide wachtwoorden gelijk trekken.

[Equator]

Move naar Netwerken

Dit is natuurlijk niets voor PNS.

Edit: Aliassed in Beveiliging & Virussen

[ Voor 29% gewijzigd door Equator op 29-03-2010 13:51 ]

[Vicarious]

Paul Nieuwkamp schreef op maandag 29 maart 2010 @ 13:43:
[...]
Dat argument gaat op voor _alles_ dat je aanbiedt, of dat nu RDP of VPN is

Klopt.

1. Wie vertrouw je meer: Microsoft die RDP heeft ontwikkeld, eigenlijk puur voor intern gebruik en weinig rekening houdend met security, of een partij die een gespecialiseerde VPN oplossing ontwikkeld heeft die er juist VOOR GEMAAKT is om secure te zijn en werken met certificaten, SSL-verbindingen etc.

2. Als er al een lek/exploit in het VPN protocol zit, zit diegene alleen nog maar aan de buitenkant van je firewall of op zijn ergst in je DMZ waar je VPN-oplossing staat. In dit geval zou diegene direct op een server in het interne netwerk zitten waardoor hij die server zelf en alle andere servers in het netwerk in theorie om zeep kan helpen.

[Paul]

Vicarious schreef op maandag 29 maart 2010 @ 14:20:
1. Wie vertrouw je meer
2.buitenkant van je firewall of op zijn ergst in je DMZ

1. is in beide gevallen Microsoft in mijn geval, die hebben zowel RDP als RRAS geprogrammeerd.
2. Wat heb je dan aan je VPN? Het is toch juist de bedoeling dat je naar binnen kunt? Er lijken me dus gaten in te zitten waardoor je alsnog "iets" kunt.

Maar ik lees al dat jij in compleet andere omgevingen werkt dan ik Ik / wij hebben een 50 klanten die ieder een 'Speedtouch' en één Small Business Server hebben.

De 'firewall' is de NAT-router met port forwards, de DMZ bestaat niet. Indien de klant het vraagt (en er voor betaald) zetten we VPN op (met RRAS en AD-accounts, geen tokens oid), dus de meerwaarde ervan is nihil in ons geval, terwijl het wel nadelen heeft (zeker als je dan, dit topic in het achterhoofd, de port forward voor RDP uitzet; lastiger beheer want iedereen moet 50 VPNs opzetten in Windows, als 1 beheerder bij een klant bezig is kan een andere klant er niet bij omdat de GRE-forward niet met poorten werkt oid etc)

[DiedX]

Paul Nieuwkamp schreef op maandag 29 maart 2010 @ 13:43:
[...]
Dat argument gaat op voor _alles_ dat je aanbiedt, of dat nu RDP of VPN is

[...]
Zelfs geen RADIUS/IAS ? Maak je het jezelf dan niet veel moeilijker voor een klein beetje extra? Nu moet je op 2 plaatsen je wachtwoord aanpassen / users aanmaken, en ik gok zo dat 80% van je users 'dan maar handmatig' beide wachtwoorden gelijk trekken.

Ook geen RADIUS/IAS. Een losse CA opzetten is niet zo lastig hoor OpenVPN met RSA certificaten...

[j0rDy]

leuk onderwerp! de pluim gaat echter al naar onze eigen BOFH in opleiding

nee, Remote Desktop is idd niet veilig. misschien is het verkeer wel encrypted, maar zover ik weet gaat je wachtwoord gewoon in plaintext over het lijntje (correct me if im wrong?) daarbij is brute force prima mogelijk (al dan wel dmv rainbowtables, ik denk echter dat een goede passwordlist in de meeste gevallen genoeg is.) Het verkeer kan altijd gesniffed worden (evt. via wireshark) en wat kan je er aan doen om het moeilijker te maken voor de aanvaller? (let op moeilijker, voorkomen kan immers nooit) sterke wachtwoorden, poort wijzigen (alhoewel dit weinig indruk zal maken). lockout policy (ik denk dat hier de grootste winst te behalen valt) en gebruik maken van een VPN verbinding.

[Equator]

Nee, bij RDP gaat er geen username of wachtwoord in plain-text over de lijn.

Er is echter wel een manier om het te achterhalen mocht je de stream hebben kunnen capturen. Dit gaat overigens alleen op voor de oudere versie van RDP.

Op youtube loopt wel een filmpje van Marcus Murray die live de rdp stream bekijkt die hij net heeft kunnen capturen door een switch te besmetten met ARP poisioning.

De nieuwere versies van RDP gaan gewoon over TLS/SSL waarbij er dus een veilig kanaal wordt gebruikt. Tot hoever dit veilig is is een discussie waar ik me nu niet aan ga wijden, maar voor thuisgebruik lijkt het me meer dan voldoende

[LuckY]

j0rDy schreef op maandag 29 maart 2010 @ 15:17:
leuk onderwerp! de pluim gaat echter al naar onze eigen BOFH in opleiding

nee, Remote Desktop is idd niet veilig. misschien is het verkeer wel encrypted, maar zover ik weet gaat je wachtwoord gewoon in plaintext over het lijntje (correct me if im wrong?) daarbij is brute force prima mogelijk (al dan wel dmv rainbowtables, ik denk echter dat een goede passwordlist in de meeste gevallen genoeg is.) Het verkeer kan altijd gesniffed worden (evt. via wireshark) en wat kan je er aan doen om het moeilijker te maken voor de aanvaller? (let op moeilijker, voorkomen kan immers nooit) sterke wachtwoorden, poort wijzigen (alhoewel dit weinig indruk zal maken). lockout policy (ik denk dat hier de grootste winst te behalen valt) en gebruik maken van een VPN verbinding.

Nee, het wordt niet plaintext gestuurd, tenminste ik kon het net niet vinden

Wikipedia: Remote Desktop Protocol

Vandag RD client 6.1 kan er gebruik worden gemaakt van RDP 7.0. Hierin zit TLS 1.0 (SSL ) in verwerkt. deze wordt direct negotiated voordat het wachtwoord over de lijn gaat, daarna voer je de credentials in en accepteer je het certificaat (wat eigenlijk voor je login zou moeten).

Edit: spuit11 voortaan is research doen voor op reageren te beuken

[ Voor 4% gewijzigd door LuckY op 29-03-2010 16:02 ]

[Vicarious]

Equator schreef op maandag 29 maart 2010 @ 15:50:
maar voor thuisgebruik lijkt het me meer dan voldoende

Daar sluit ik me dan weer wel volledig bij aan.

Altijd geldt dat je de beveiligingsmaatregelen die neemt moet afzetten tegen o.a. :
- De data die je probeert te beveiligen
- Het risico van inbraak (valt er wat te halen of ben je geen interessant target?)
- Budget dat beschikbaar is
- Wat is de schade als er inderdaad ingebroken wordt?

@ Paul Nieuwkamp: inderdaad, andere omgevingen. Wij hebben dan weer 1 groot datacenter waar we al onze klantservers hosten. Die wil je niet allemaal rechtstreeks aan het internet hebben hangen. Buiten het feit dat het een hels karweitje wordt om al die portforwards te maken is het ECHT minder veilig