Wij onderhandelen niet met terroristen.

RDP open over het publieke internet? Dan mis je een basis.

Hoezo, is RDP niet veilig dan om over internet te gaan? Waarom ssh/https/Citrix/VNC etc. etc. wel maar RDP niet? Kijk, unencrypted protocollen snap ik wel maar feitelijk zou je alle encrypted protocoillen over internet moeten kunnen gebruiken.

Het is genaamd REMOTE Desktop Protocol maar je mag/kan het niet gebruiken over internet omdat Microsoft weer eens heeft nagelaten hun huiswerk te doen qua beveiliging? Man, man, man! Ik gebruik wel gewoon ssh!

Microsoft heeft wel degenlijk zijn huiswerk gedaan. RDP is heel goed te beveiligen over het internet. Echter als je als beheerder het gewoon standaard openzet, en geen goed wachtwoordbeleid hebt...... Dan is het vragen om problemen.... Heel veel problemen....

Dat is gewoon exact het zelfde als ssh met admin:admin op het Internet aanbieden.... Er zit dan namelijk niet veel verschil in. Beide zijn onveilig te gebruiken, als je er niet goed over nadenkt..

Conclusie is dus: Beheerder heeft zijn huiswerk niet gedaan. En The FOSS heeft dit gewoon even gekopieerd.

RDP ondersteunt TLS en laat zich prima over een VPN gebruiken. Het laat zich trouwens ook prima tunnelen over SSH. Het probleem is niet dat Microsoft hier iets niet goed heeft gedaan, het probleem is dat de configuratie van dat disctrict kwetsbaar was. Let even op het woord open dat karma4 in zijn reactie gebruikte.

Dat meer dan 70 servers versleuteld zijn suggereert dat er wel wat meer mis was dan alleen dit.

En het voegt weinig toe om dat te constateren. Overal waar iets zo grootschalig uit de hand loopt is het duidelijk dat men zich daar onvoldoende tegen had beschermd. Dit is gewoon een symptoom van dat technologische ontwikkelingen, en met name IT, zo stormachtig snel gaan. De mensheid is nog druk bezig om te leren ermee om te gaan. En ook al zijn er mensen die weten hoe het beter moet, die kennis en goede gewoontes op dat vlak zijn domweg nog lang niet verankerd in onze samenlevingen. En zo lang de ontwikkelingen razendsnel blijven gaan en minimaal een keer per decennium iets radicaal anders moet omdat de huidige verdienmodellen van hypes afhankelijk zijn blijft het dwijlen met de kraan open.

Jammer dit:


Als je het financiële aspect naar buiten brengt... wordt erop geanticipeerd!
Het schijnt mij daarom verstandiger toe openheid van zaken minder gedetailleerd te brengen, door bijvoorbeeld niet te spreken over financiële overwegingen die een rol spelen in de beslissing om tot betaling over te gaan. Dat is ook nergens voor nodig; niemand eist zo'n verklaring.

Oh, RDP over internet is dus veilig, zwakke wachtwoorden zijn dat niet. Dan moet Karma4 niet lullen en roepen dat je een basis mist als je RDP over internet laat lopen.

ALs je RDP SSH voor gebruik en nog erger niet over VPN en dan met een dichtgetimmerde bedrijfslaptop of een remote VM laat lopen dan hang je je omgeving open aan het publieke internet.

Dat je alles open wilt hebben (auditable) wil niet zeggen dat alles open moet zetten. Dat is de basis die gemist wordt.
Heel eenvoudig fundamenteel maar voor te veel kennelijk nog te lastig om tussen de oren te krijgen.
Daarmee gaat het signaal naar het management dat ICT niets voorstelt kun goedkope krachten op zetten of uitbesteden onder het mom als het maar werkt.

Dank je eens met die symptoom vaststelling. Je zou ook kunnen zeggen dat men zo snel achter andere technologie aan loopt dat de basis vergeten wordt.

Dat met die 70 servers is een fraai punt. Ooit deed men het met een machine met vele applicaties. Nu lijkt het er op dat elke applicatie zijn eigen machinepark moet krijgen. Ik lees een gebied van 163.000 inwoners. Als ik ruim schat 15.000 ambtenaren van allerlei soort. Voor Een kantoor met 1400 man waar dan 100 man ICT. Het zijn de getallen die wie hier voor gemeentes zien. Dan zijn er 70 servers getroffen en dan zullen er nog vele andere servers naast staan (eg Oracle).
Dan is de Applicatie beheerder (ICT) tevens de admin en de technisch beheerder. Dat wringt, specialistisch werk moet je aan specialisten over laten.

@Karma4

Probeer nou eens simpel te antwoorden op mijn vraag:

Is RDP veilig om gebruikt te worden waar het voor ontworpen is namelijk Remote Desktop?
Er vanuit gaande dat er een voldoende sterk wachtwoord gebruikt wordt.

(te vinden in tekst achter blauwe link "Samsam-ransomware" in eerste regel van tweede alinea)

Zie antwoord anoniem 19:02. "Om toegang tot de RDP-systemen van organisaties te krijgen maakt de groep gebruik van bruteforce-aanvallen" Alles wat je open en bloot aan het publieke internet hangt heeft het risico van gehackt kunnen worden. Je aanname van voldoende sterk wachtwoord toont meteen de zwakte, ook dat kan omvallen.
Vandaar zet het achter een VPN met een geisoleerde machine fysiek/VM. Daar boven op doe aan functiescheiding netwerkscheiding zodat als er ergens iets omvalt het niet omvalt als een rij dominostenen.

Aha, dus RDP is niet beschermd tegen bruteforce-aanvallen! Je kan blijkbaar probleemloos wachtwoorden uitproberen, zonder dat je met zaken als een automatische vertraging of lockout te maken krijgt. Lekker gedaan weer, Microsoft!

Wat maakt die andere internet facing protocollen dan wel veilig en RDP niet?

Je mist de hele taak van een verantwoord ICT beheer inrichten. Dat is niet de taak van Microsoft. Alleen als je bezig bent als zolderkamerhobbyist met je eigen doosje kan ik begrijpen dat je het niet ziet omdat er geen bedrijf / organisatie is.

Laten we het stap voor stap proberen met welke doelen een bedrijf / organisatie zou moeten invullen.
We gaan er van even snel uit dat het om mogelijk gevoelige data gaat (dataclassificatie) die niet voor het open publiek is.

Doel A1/
Je wilt niet dat anderen meekijken / kunnen zien wat er voor gegevens over de lijn gaan.
Het risico dat met een wireshark van alles openbaar wordt wil je uitsluiten.

Oplossingen:
- Lijnencryptie https ssh sftp en veel meer doen dat.
Het nadeel van deze dat de sleutel van de encryptie zelf niet altijd jou apart toegewezen sleutel is. Dan kan het gebeuren dat er met een man in het midden aanval (MITM) de boel alsnog open ligt.
- Een VPN (Virtueel Private Netwerk) zet het veel meer gesloten met eigen sleutels op.
Het doel is immers om een VPN aansluiting zo nee te zetten dat het lijkt alsof het een eigen intern netwerk is.
Als je het VPN op eigen apparatuur laat inrichten met sleutels en software die je apart overhandigd dan kan dat alsnog gelekt worden en komen er mogelijk onbekenden op jou VPN binnen.

Ik heb dit gezien als een optie voor wifi gebruik voor tijdeljjk gecontroleerd gebruik voor bezoekers in een apart netwerksegment. Je ziet dan een lijst voorwaarden en controles bij gebruik in gevoelige omgevingen en je kan nog nergens bij van interne systemen. Voor een offerte analyse waar je met anderen wel iets gevoeligs vastlegt een goede zeer optie.

Doel A2/
Je zit nog met het ongecontroleerd benaderen vanuit onbekende apparaten.
Wie zijn dat, wat doen ze, waarmee wordt er gewerkt.

Oplossingen:
- Gebruik geen persoonlijke apparatuur.
Dan zijn alle apparaten bekend, weet je wie het doet is beperkt waarmee gewerkt kan worden.
- Gebruik persoonlijke apparatuur alleen via een VM (remote veilige verbinding).
Je hebt nu ook cadeau gekregen aan wie je een RDP gebruik toestaat.
Ik ga er wel vanuit dat een IAM (Identity Access Management) op orde is. Daarmee heb je vastliggen wie wat mag doen onder welke condities.

Een remote desktop zoals Citrix wordt heel vaak gebruikt omdat men (de IT nerds) problemen heeft applicaties op desktops behoorlijk in te richten. Een ander is dat men het idee heeft dat data op eigen intern beheerde desktops te makkelijk zou lekken. Geef het beheer van de Citrix omgeving aan een externe verwerker en die zien ineens alle data en kunnen zelfs zeggen dat het hun data is omdat hun software die verwerkt.


Doel A3/
Functiescheiding Netwerkscheiding
Hier zit een andere uitdaging dan enkel het technische. Je moet de applicatie/technische beheerdersrollen (admin:admin) duidelijk maken en isoleren van het applicatieve gebruik.
Oplossingen:
- Gebruik aparte beheerderaccounts en service accounts voor de applicaties.
Gebruik in ieder geval niet het normale persoonlijke account voor de hoogst gevoelige beheersactiviteiten.
Dit betekent dat één persoon meerdere persoonlijke accounts toegewezen kan hebben.
Een shared beheerdersaccount is gangbare praktijk maar heeft het risico van algemeen bekend worden.
- Met netwerkscheiding heb je het lokale netwerk in segmenten waarbij bepaalde server/ machines niet bereikbaar zijn vanuit andere segmenten. https://en.wikipedia.org/wiki/DMZ_(computing)

Dat kan vrij uitgebreid en zwaar gecontroleerd onder change management (Itil) dan wel licht gemonitored in een devops.
Daar hoort een risico inschatting bij van wat indien er iets mis gaat met een DR (Disaster Recovery) overweging. Moet het binnen minuten/seconden weer werkend zijn of is het goed genoeg als er na 2 weken iets het weer doet.

Pas als je A1, A2 en A3 allemaal invult heb je een redelijk veilige situatie.
Bedenk, aanvallers kunnen ook internen zijn.

Als je nu hoort een RDP dat open staat op het publieke internet dan is er inderdaad mogelijk gedacht.
"Het verkeer is encrypted en die RDP is wel handig voor de leverancier dan wel thuiswerker. Wat kan er fout gaan?"
- Met een DMZ zou de impact nooit verder mogen lopen dan dat deel en geen interne processen raken. Teruggrijpen naar pen en papier geeft aan dat zoiets ook niet op orde is.
- Niet weten wanneer alles in de lucht is geeft aan dat DR plan kennelijk ontbreekt.

RDP is absoluut niet iets wat je over het Internet moet aanbieden zonder een juiste goede basis neer te zetten. Juist precies wat Karma4 roept. Doe je dat niet, dan krijg je dit.

Lekker bezig The FOSS, je komt meestal met betere argumenten, wat dit slaat natuurlijk helemaal nergens op. En dat snap je zelf ook. Het is namelijk exact het het zelfde met SSH.
RDP is niet verantwoordelijk voor account lockouts. Dat is authenticatie provider, of ActiveDirectory of het lokaal account beleid. Richt je dat niet goed is.... Dan is RDP net zo onveilig als SSH.


Wat is simpel.... Is het veilig JA, al is een sterk wachtwoord niet voldoenden.
Is het gewenst NEE.

Ik zou het nooit maar dan ook nooit zomaar direct over het publieke Internet aanbieden.

Je zal nog het 1 en ander moeten configureren:
TLS forceren: https://technet.microsoft.com/en-us/library/ff458357.aspx,
Account lockout Policies,
Liefst alternatieve port e
Je zal je eventlogs in de gaten moeten houden op (structuele) inbraak pogingen.
Regelen welke accounts RDP mogen doen doen, zodat niet ieder "test" account RDP zomaar mag doen.

SSH wordt door experts gebruikt (meestal FOSS, Linux) die weten waarmee ze bezig zijn. Die hoef je niet bij het handje te nemen en alles voor te doen. Dat geldt niet voor $CSS, Windows gebruikers, die moeten duidelijkheid hebben en zo weinig mogelijk keuzemogelijkheden. Integratie van accountmanagement, e.d. is een must voor deze groep van gebruikers.

Als je het over de security faals van linux beheerders wilt hebben, dat is echt leuk. Totaal gebrek aan security besef ze staan met de oren te klapperen als de richtlijnen doelen zoals iso 27002 n'en 7510 langs komen. IAM met rbac is iets wat voor anderen is, admin:admin werkt toch.
Hebben niet os beheerders dan wel analisten ssh nodig dam blokkeer je dat toch. SSH is veel te gevaarlijk als het door anderen gebruikt zou kunnen worden.

Je krijgt dan het advies om maar Windows servers met citric en een heel park er achter in te richten Linux beheerders die weten wat ze doen, dat is echt niet de praktijk integendeel.
Vervolgens zie je ook nog als vlucht cloudservices uitbesteding en shadow ict en heb je zowat alle ict ellende in beeld.

Intussen heb je de managers die er niets van snappen maar wat meest gemaakte keuzes (best practices) volgen. De neerwaartse spiraal in kwaliteit. Kom aub niet met een heilig verklaring van linux goeroes.

Misschien in alleen jouw omgeving. Maar de ervaring is ook heel anders. Hoeveel Hosting providers bieden bijvoorbeeld SSH gewoon met UserID / Password aan? Hoeveel gewone SSH servers hangen er wel niet aan het Internet. Zat.....
Daarnaast heb ik hier waar ik momenteel werk, een heel hoop experts die SSH gebruiken, maar echt totaal niet snappen van IT. Wachwoord hangt gewoon op een papiertje bij de monitor.
Vallen deze personen ook onder jouw experts?

Correct. Heb jij wel eens ervaringen gehad met de "gewone" gebruiker? Die echt helemaal niets weten van een computer? Die de helpdesk in paniek bellen, als het icoontje er al anders uit zien? Dat zijn de gebruikers die werken op de desktop. Daar moet alles uitgewerkt worden. Welkom in de echte wereld.... Blijkbaar heb jij daar niet zoveel ervaring mee.

Nee. Ook hier snap je duidelijk het punt niet. Dit is een must bij ieder bedrijf. AccountManagement moet je overal uitvoeren ongeacht OS of applictie of toegangs methode. Als iemand uit dienst is... Moet direct overal zijn account gedisabled worden.
Als een account misbruikt wordt, moet dit snel gedetecteerd kunnen worden. En dit moet je centraal inregelen.
Mooie van Windows is, dat dit gemakkelijk kan, het zit er helemaal standaard in.
Als je dit niet centraal bij Unix inregelt heb je een heeeeeeeel hoop werk te doen op alle servers. Gelukkig kan dit ook, maar..... Je moet er wel het 1 en ander voor neer zetten.
Een goede Unix beheerder koppelt dit dus ook aan een centraal account database. En laat dat nu juist vaak een ActiveDirectory zijn bij grote bedrijven (al zijn er zat die dit op andere database laten landen)......
Maar bij veel is dit ook helemaal niet ingeregeld. Zie nog vaak genoeg wat men een nieuw account aanvraag, eerst als alle servers moet gaan, om lokaal accounts aan te maken op servers of applicaties. En dat zijn dan niet de Windows servers. Die gebruiken gewoon standaard AD. Maar als je geluk hebt, wordt LDAP ondersteund.

Maar juist deze opmerking van je, laat zien dan je eigenlijk geen idee hebt hoe dit soort processen in elkaar zitten en moeten zitten, nog afgezien je duidelijk geen ervaring hebt met de "gewone" gebruikers.

wat is het robleem. Incmpetentie op de werkvloer? slechte opleidingen en incompetent management? slecht geconfigureerde infrastructuur en tekort aan TIN staf? Zeg het maar...

Alle remote access protocollen hebben zwakke plekken. Wanneer je SSH open zet voor de hele wereld loop je ook risico.

RDP kun je gewoon configureren client side certificaten te gebruiken of je zet de firewall alleen open voor bepaalde IP adressen van waar er verbinding gemaakt zou mogen worden. Er zijn mogelijkheden zat, je moet ze wel benutten.

Natuurlijk moet je niet op 1 obstakel vertrouwen maar dat is een heel ander verhaal dan botweg te roepen dat je een basis mist als je RDP over internet laat lopen.

Overigens staat bij mij ssh wel open voor de hele wereld maar wel alleen toegang met ssh key, andere zaken staan open voor bepaalde adressen en weer andere zaken met een GEOIP blokkade erop.

Bij Google hebben ze Windows in de ban gedaan en Linux verplicht gesteld. Ook andere echt grote spelers nemen steeds meer afstand van Windows en de bijbehorende ellende. Als je dat in een hoekje van 'mijn omgeving' wil stoppen, is goed hoor.

Allemaal zware ICT bedrijven, die om diverse redenen oa geen Windows meer toestaan. En ja, het klopt dat er meer zijn en dat dit aantal groeiende is. Daar is toch niets mis mee? Als dat voor een bedrijf mogelijk is, waarom niet?

Het over grote gedeelte van de bedrijven doet dit echter niet. Ook misschien met een redenen?

[quote[Als je dat in een hoekje van 'mijn omgeving' wil stoppen, is goed hoor.[/quote]Op basis van je opmerkingen, kan je een bepaalde ervaring er uithalen. Dat dit misschien wel eens heel ver van de werkelijkheid en praktijk ligt, is een heel ander verhaal. Dat jij dat niet kan/wilt zien, zegt ook weer iets over jou.

Ligt het bij Windows nou aan Microsoft of aan de gebruikers? En dacht je echt dat bij SSH nooit logins met usernaam/wachtwoord worden toegestaan en dacht je echt dat daar geen zwakke wachtwoorden voorkomen?

FOSS, je kraamt onzin uit. Met vrienden zoals jij heeft open source geen vijanden nodig.

Ik heb Windows-experts meegemaakt die er uitstekend in slaagden netwerken met Windows-werkstations en -servers robuust en goed performend te laten draaien. Ik heb Solaris-beheerders (Unix dus) meegemaakt die root-accounts met schokkend zwakke wachtwoorden met elkaar deelden. Dat weet ik omdat ik als ontwikkelaar die wat op die systemen moest doen geen eigen user kreeg maar tot mijn schrik die root-wachtwoorden kreeg medegedeeld.

Er bestaan Windows-omgevingen van rammelend tot robuust, er bestaan Linux-omgevingen van rammelend tot robuust en dat geldt voor elk besturingssysteem. Al die systemen hebben hun sterkere en zwakkere kanten, en bij al die systemen ben je blij met de sterkere kanten terwijl je voor de zwakkere kanten maatregelen moet nemen, maar de kwaliteit van het beheer is bij al die systemen een doorslaggevende factor.

Voor de duidelijkheid: op mijn eigen systemen gebruik ik al 18 jaar Linux, omdat dat me om een scala aan redenen aanzienlijk beter bevalt dan Windows. Ik voel me alleen niet geroepen om met kulargumenten aan te tonen dat je met Linux verder piest dan met Windows of dat soort onzin. Dat vind ik net zo ergerniswekkend als iemand die doet alsof alle open sourceomgevingen slecht beheerd worden of dat één type user-interface voor iedereen de beste oplossing is. We dragen ook niet allemaal dezelfde maat schoenen, mensen verschillen van elkaar en voor verschillende mensen zijn verschillende oplossingen de beste. En dat geldt ook voor organisaties.

Blijf vooral enthousiast over open source en Linux, FOSS, daar is reden genoeg voor. Maar snap alsjeblieft dat "goed" en "slecht" niet in één dimensie te vangen zijn, daarvoor zijn die systemen veel te complex en daarvoor verschillen de behoeftes van mensen en organisaties te veel.

En snap dat een besturingssysteem of een licentiemodel niet de piemel is die je gebruikt in een wedstrijdje verpissen.

Jemig... als je zo graag MS wil bashen, doe dan een beetje je best om je te verdiepen in de materie... RDP hoeft niks tegen bruteforce te doen, dat doet Windows voor je... Of Windows lokaal, of Active Directory als het systeem in een domain hangt. Daar kan je lockout-policies en wachtwoord-policies configureren, en als je een beetje bij de tijd bent draai je Advanced Threat Analytics en kan je brute-force pogingen (en allerlei andere narigheid) actief detecteren.

Dan is het wel erg vreemd dat de hackers brute force methodes hebben kunnen gebruiken, nietwaar?

De gangbare iot faal is ook aan redhat en Linus Torvald toe te schrijven. Hebben we het grootkapitaal naast gafa waar de schade doir iot verhaald kan woensdag toch.

Als je niet wilt snappen hoe een veilige infrastructuur opgezet kan worden dan blijft het aanmodderen.

Nee, hoe kom je daar nou toch weer bij? De IoT-faal heeft helemaal niets met Linus of Linux te maken.


Pilletje?


Daar heb je blijkbaar nogal wat ervaring mee opgedaan, met maar wat aanmodderen. Omdat je het gewoon niet begrijpt, het niet kan vatten, het te hoog gegrepen is, enz.,enz.

Als de omgeving niet goed in gericht is, dan is dit inderdaad niet vreemd. Dat is geen fout van RDP, Windows, Microsoft of Active Directory. dat is gewoon een fuckup van de beheerder. Niets meer en minder.
Exact het zelfde als je SSH openzet met admin/admin of test/test of verzin het.

Net zoals het hele RDP statement wat je hier probeer te maken, dat is namelijk exact het zelfde.
Als je iets slecht neerzet, is het vragen om problemen. Het OS staat daarbij helemaal los van.

Je hebt een bepaalde dienst die je aanbied, en als je die dienst niet goed inricht, dan heb je een probleem. Waar het opdraait staat hier helemaal los van.

Wat is het verschil tussen een SSH Linux machine aan het Internet te hangen, met geen goede beveiliging vs een Windows desktop icm RDP op het internet aanbieden? Beide zijn zo ver te nemen als je een account test/test aanmaakt.

[/quoteHeb je het nu over je zelf of niet? Want ik krijg nu niet het geval je dat enig idee hebt, hoe de wereld er nu in elkaar zit of hoe de echte grote mensen wereld werkt.

Heb jij het over jezelf? karma4 = Tha Cleaner?

Dat moet je maar eens onderbouwen. Wel Nederlands graag. Voorlopig weer karma FUD.

https://www.security.nl/posting/551264/Lek+in+52_000+babycamera%27s+kan+aanvaller+laten+meekijken
"Verder is de wachtwoordresetfunctie kwetsbaar voor bruteforce-aanvallen, wordt er een zwak standaardwachtwoord gebruikt, is het mogelijk om gebruikersaccounts te achterhalen en maakt de camera gebruik van verouderde software met bekende kwetsbaarheden, waaronder BusyBox, OpenSSL en Linux."

Dan hoef ik niet eens de massa datalekken onder mongodb er bij te halen.
https://www.google.nl/search?&q=mongodb+site%3Adatabreaches.net&oq=mongodb+site%3Adatabreaches.net
Daar zijn de gegevens van complete naties mee gelekt.

http://www.zdnet.com/article/equifax-blames-open-source-software-for-its-record-breaking-security-breach/
Het is in ieder geval FUD dat omdat je Linux gebruikt je niets aan informatieveiligheid hoeft te doen.
RedHat is een miljardenbedrijf en Linus krijgt miljoenen. Beide zeggen niets van doen te hebben met deze faalhouding.
AWS (Amzon) met Jeff Bezos als rijkste man ter wereld laat ondernemingen in hun cloud ten onder gaan als hacked is eigen schuld. https://www.theregister.co.uk/2014/06/18/code_spaces_destroyed/

Het is zo'n houding dat omdat het gratis is en iedereen de code kan zien dus je hoeft niet zelf na te denken.
Een nare oorzaak van gebrek aan security is. Onderbouwing genoeg.
Gaarne van de Linux adepten de verandering en houding dat ze wel voor een deugdelijke security willen gaan ipv zichzelf proberen beter te laten lijken door met bashing bezig te gaan.

@karma4 Wat een gelul! Niets van dat alles heeft met Linux te maken! Sterker nog, indien Windows gebruikt zou zijn, in plaats van Linux in wat jij beschrijft, dan zou je pas echt een rampenscenario hebben gehad! Een waar armageddon!