'Steeds meer ddos-aanvallen via udp-amplification op Remote Desktop Protocol'

Criminelen gebruiken steeds vaker het Remote Desktop Protocol op Windows voor het uitvoeren van ddos-aanvallen. Voor het uitvoeren van amplification- en reflection-aanvallen wordt steeds vaker gezocht naar computers waar dat protocol open staat.

Ddos-aanvallers scannen steeds vaker naar rdp-poorten die open staan, schrijft beveiligingsbedrijf Netscout in een rapport. De aanvallers sturen daarmee udp-packets naar de udp-poorten van servers waarop het Remote Desktop Protocol open staat. Rdp wordt volgens de onderzoekers alleen uitgebuit als udp-poort 3389 open staat op de server. Door het protocol aan te vallen wordt een ddos-aanval versterkt, wat ook wel een amplification-aanval wordt genoemd. Bij zulke aanvallen kan een klein pakket worden gebruikt om alsnog veel verkeer te genereren.

Volgens Netscout heeft een amplification-aanval via rdp een versterkingsfactor van 85,9. Ter vergelijking is een dns-amplification-aanval er een met een factor 180, en een ntp-amplification er een met een factor 550.

De onderzoekers zeggen dat rdp-amplifications zijn toegevoegd aan bekende booters, die voor weinig geld te koop zijn. Met dergelijke ddos-as-a-service-pakketten kunnen aanvallers makkelijk ddos'en uitvoeren zonder zelf de infrastructuur te hoeven regelen. Netscout zegt dat wereldwijd zeker 14.000 rdp-servers hun udp-poort 3389 open hebben staan. Het beveiligingsbedrijf raadt bedrijven aan de systemen offline te halen of achter een vpn te zetten.

Reacties (202)

[henkkeumus]

Of al het verkeer naar die poort dichtgooien en alleen 'whitelisted' IP adressen toelaten over de betreffende RDP poort. Of is dit ook weer te omzeilen, dacht het niet toch.

[Reactie gewijzigd door henkkeumus op 24 juli 2024 11:19]

[Tadango]

Zo hebben wij onze stand alone machines in de cloud beveiligd. Je moet er toch via RDP naar toe maar van slechts enkele adressen. Dat zou veilig genoeg moeten zijn. Als je al om de firewall heen kan door de afzender van het packet te faken, dan nog vindt je de server met een scanner niet tenzij je weet welke bron ip's toegestaan zijn. Naast het scannen van de poorten op de ip's zou je dit dan ook nog eens moeten doen vanaf alle mogelijk ip's.... dat maakt het een heel stuk onwaarschijnlijker.

[The Zep Man]

Zo hebben wij onze stand alone machines in de cloud beveiligd. Je moet er toch via RDP naar toe maar van slechts enkele adressen.

Of via een VPN.

RDP verkeer direct over het internet blijft een slecht idee, onder andere omdat Microsoft's RDP server keer op keer onveilig bleek. Een IP whitelist kan wel, maar wat als de andere kant gecompromitteerd is? Verder is een whitelist ook ondehoudsgevoelig. Los het dan meteen goed op op netwerkniveau.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 11:19]

[Tadango]

VPN moet dan wel mogelijk zijn, en dat is het niet. Het zijn stand alone machines he. Gewoon een doos op internet waar een doorgeef luikt systeem op draait. Er staat geen data op dus security noodzaak is laag. RDP beheer is prima voor onderhoud en je gaat voor zoiets echt geen hele infrastructuur met VPN opzetten.

[The Zep Man]

VPN moet dan wel mogelijk zijn, en dat is het niet. Het zijn stand alone machines he. Gewoon een doos op internet waar een doorgeef luikt systeem op draait.

Dan zet je er een VPN endpoint voor. En als het een RDP server draait, dan kan het ook een VPN server of client draaien.

Er staat geen data op dus security noodzaak is laag.

Die machines hebben kennelijk een functie. Anders bestonden zij niet. Data is niet alles.

RDP beheer is prima voor onderhoud en je gaat voor zoiets echt geen hele infrastructuur met VPN opzetten.

Dat doe ik wel, ook voor non-repudiation. En zie wie er wel en wie er geen peentjes zweet als de volgende Microsoft RDP-gebaseerde kwetsbaarheid langskomt.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 11:19]

[Tadango]

Klopt, op die manier kan VPN prima maar ook de VPN oplossing is te hacken. Waarom zou dat veiliger zijn dan RDP via een firewall?

RDP is inderdaad zelf erg kwetsbaar en onveilig, maar een firewall is de beveiliging, niet het RDP inlog systeem (dat vertrouw ik ook 0,0)

[The Zep Man]

Klopt, op die manier kan VPN prima maar ook de VPN oplossing is te hacken.

De kans dat een VPN oplossing gehackt wordt is kleiner dan dat MS RDP server (opnieuw) gehackt wordt. Alleen al de hoeveelheid regels code en de integratie met het besturingssysteem maken al een groot verschil.

RDP is inderdaad zelf erg kwetsbaar en onveilig, maar een firewall is de beveiliging,

Totdat ransomware via een RDP RCE kwetsbaarheid jouw klant compromitteert, en via de computer van jouw klant jouw systeem wordt gecompromitteerd (want die stond in de favorietenlijst).

Een firewall beschermt niet tegen verkeer dat toegestaan is. Bij VPN oplossingen kan je gebruikersaanwezigheid afdwingen (bijvoorbeeld via een uitgegeven Yubikey) en daarmee het aanvalsoppervlak voor geautomatiseerde aanvallen beperken.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 11:19]

[defixje]

Heb jij hier een bron van? Ben erg benieuwd.

[citegrene]

https://packetstormsecurity.com/search/?q=vpn

[anboni]

Ik heb in het verleden dit soort dingen wel opgelost door een SSH server op die machine te draaien (cygwin, destijds) en daar m'n RDP overheen te tunnelen.

[GeroldM]

Denk dat 'Apache Guacamole' voortborduurt op je concept.

[FriXion]

Er staat geen data op dus security noodzaak is laag.

Elk botnet is opgebouwd uit computers waar "Geen data op staat en beveiliging geen prio is". Het gaat er niet altijd alleen om of er iets belangrijks op een netwerkapparaat staat.

[hasseroderman]

Of een oplossing als https://www.zerotier.com/

[ictert]

Een hele infrastructuur met vpn?
Een simpele doch veilige OpenVPN installatie is voldoende.

Heb onlangs nog een script geschreven om op een simpele wijze een OpenVPN server te installeren incl. het maken van client configs, deze is hier te vinden: https://github.com/arjansturing/Auto-OVPN-2.0

[Core2016]

En die dan over TCP443 en alle niet vpn pakketten forwarden naar een webserver.
Zo heb ik op de meest beperkende netwerken een VPN tot stand kunnen brengen met redelijke snelheid dat anders niet werkte. Niet overal is 1194 mogelijk.

[Verwijderd]

Beveiliging werkt in lagen, des te meer lagen, des te veiliger.
IP toegang lijsten helpen je om de eerste golf aanvallers af te slaan. Echter bieden ze geen enkele beveiliging. Dat doe je bijvoorbeeld met MFA aan de gebruikerszijde en Intrusion Detection Systems (IDS) / Intrusion Prevention Systems (IPS) aan de beheer zijde.

[Tadango]

Het aantal lagen is afhankelijk van de data / impact. In ons geval is de server expendable en bevat deze geen data. In dat geval is het prima om deze alleen zo te beveiligen. Daarover wordt alleen vaak niet gesproken behalve dat RDP over internet onveilig is. In veel gevallen kan het prima en hoeft het echt niet beter.

[Verwijderd]

Gezien jouw server misbruikt kan worden om verdere schade aan andere mensen te veroorzaken zie ik dit niet als 'prima en hoeft het echt niet beter'.

[rookie no. 1]

En waar hangt die machine in dat hij misbruikt kan worden om verder dat netwerk in te hoppen?

[Fiander]

Als de remote server gecompromitteerd is, en jij maakt verbinding, dan is jou werkplek dat vanaf dat moment ook. Ga je daarna verder naar andere systemen, dan zijn die vanaf dat moment ook gecompromitteerd.

ELKE laag doet er toe, en als jij vele lagen omzeilt door op een onveilige server in te loggen, dan doe je dat (onbewust) daarna ook naar andere servers.

RDP is geen één richting verkeer. Je kunt wanneer jij verbinding hebt met de server, vanaf de server de verbinding misbruiken om naar jou toe te gaan.

Ik zou de server zoals die er nu staat, afschrijven, en opnieuw beginnen.

[henkkeumus]

Precies hoe "wij" 't doen op werk. Een 'RHOST' object aanmaken en de klant zijn of haar WAN adres even laten noteren en doorgeven aan ons. Dat object voegen we toe aan een VLAN waar de gevirtualiseerde server of instance staat waar naartoe verbonden moet worden inderdaad.

[gabba25]

Nee. Maar je kan nog verder gaan; country filter en custom rdp poort. Of een rds gateway in een dmz gebruiken.

[-DEVON-]

Een country filter heeft niet veel nut, het klinkt mooier dan het in de praktijk werkt. Aangezien er tegenwoordig vaak vanuit westerse landen, maar ook Nederland zelf gewoon de aanvallen worden uitgevoerd.

Dat hebben wij laatst ook gezien toen er massaal geprobeerd werd toegang te krijgen tot onze klant servers. De hoeveelheid verkeer viel op, maar het kwam gewoon uit de USA.

[Gardibaldi]

Lijkt me moeilijk of onmogelijk te omzeilen, echter niet heel gebruiksvriendelijk, als een eindgebruiker thuis of op een andere locatie werkt, of zijn ip adres is gewijzigd kan deze niet inloggen.

[Tadango]

Dat mag nooit een argument zijn. Goede security is per definitie niet gebruikers vriendelijk. Al die token apps en andere zaken werken best goed, maar we vinden het gebruikers vriendelijk omdat we er aan wennen. Je kan dus ook prima wennen aan het doorgeven van het publieke IP van een nieuwe werkplek. Zoveel zullen dat niet zijn. En als dat wel zo is is het wellicht ook niet gewenst om op die manier te verbinden.

[The Zep Man]

Dat mag nooit een argument zijn. Goede security is per definitie niet gebruikers vriendelijk.

Mr. Dictator IT has spoken!

Beveiliging en gebruiksvriendelijkheid hoeven niet twee uitersten te zijn. Een goed ontwerp dat met alle aspecten rekening houdt en een slecht ontwerp dat slechts naar één aspect kijkt zijn dat wel.

[Fiander]

Gebruiksvriendelijk slaat niet alleen op de gebruikers, maar ook op de beheerders.

Het opzetten van een VPN, bijhouden certificaten, goede ACL bijhouden, 2FA en al het andere is per definitie minder vriendelijk dan alles open zetten. En hoe meer lagen veiligheid je toevoegt, das te meer beheerders en / of eindgebruikers moeten doen.

[ramonfincken]

Daar VPN toch voor ?

[Tadango]

En al je leveranciers die VPN oplossing laten installeren? RDP wordt vaak gebruikt om leveranciers applicatie beheer te laten uitvoeren op servers. Je moet als leverancier dan ook voor elke klant weer een andere VPN oplossing hebben zeker. In theorie prima, in de praktijk werkt dit niet vanwege al het gedoe er omheen.

[Fiander]

Als jij voor elke leverancier een aparte server neerzet, wat is er dan op tegen om de leverancier te dwingen een VPN te gebruiken? Niks lijkt mij. Maar er is ( omdat het aparte servers zijn ) ook niks op tegen om elke leverancier zijn eigen VPN te laten gebruiken. Zolang er maar (contractueel ) wordt afgesproken om ook deze VPN software up to date te houden.

Leveranciers hoeven dus helemaal niet voor elke klant aparte VPN software te installeren. Alleen de benodigde certificaten is voldoende.

Als dit al teveel gedoe is, dan neemt de leverancier de veiligheid van de klant dus niet serieus.

[henkkeumus]

Daarvoor kun je bijvoorbeeld een DDNS service gebruiken .

[cricque]

Ja maar hangt af van hoe die klant zijn internetconnectie is. Ik heb hier telenet. Hier zijn zelfs al een paar x werken geweest de afgelopen maanden, en ik denk dat ik al bijna 3 jaar hetzelfde ip adres heb. En ik betaal hier niet voor ofzo en zit ook niet in mijn abonnement. Dus in vele gevallen zal dit reeds tamelijk stabiel zijn

[DefaultError]

En toewijzen met macadres als het nog beter moet.

[henkkeumus]

Dan loop je wel tegen bovengenoemde restricties op zoals @Gardibaldi hierboven noemt.
Niet persé locatie, maar wel device.

Echter zoals @Tadango zegt mag dat nooit een issue zijn als het om beveiligen van bedrijfsdata gaat. En ik denk ook dat een directeur liever een paar honderd euro extra uitgeeft aan security/ dergelijke werkstations of laptops dan de AVG boete die men kan ontvangen na een hack of lek van bedrijfsgegevens .

[DefaultError]

Wel handig is om je poorten te bewaken met een script. Veel activiteit = raportage en mogelijk budget voor beveiliging.

[Verwijderd]

RDP moet je niet open hebben staan naar het internet maar VPN gebruiken. Apparaten die wel connecties ontvangen, zoals een website of mail server, zou ik in een aparte netwerk zetten.

[Andreplusplus]

Wel es gehoord van IP spoofing?

[henkkeumus]

Goed punt. Klopt, dat kan inderdaad misbruikt worden.

[Vorkie]

Hebben ze nog UDP3391 niet ontdekt? Die zet je default open op een RDS gateway

https://www.itpromentor.com/rds-performance-boost/

Je hebt dan HTTPS/443 open en UDP/3391

[Gert]

Bij ons had dit juist een negatief effect (oudere clients) en staat het uit., alleen TCP over 443 nu.

[er0mess]

Misschien is het handig om erbij te vertellen hoe je als leek kan checken of die open staat en/of dicht kan doen!?

[oscar oscar]

Hier kan je bvb je open poorten checken, je publiek IP adres is al ingevuld normaal:

https://www.yougetsignal.com/tools/open-ports/

Rechts zie je de lijst van services met hun normale poort. Je kan op die poort klikken en dan doet hij automatisch een check op die poort (of klik op Scan All Common Ports voor alle poorten). Als die poort dan open staat, en je bent zeker dat je die service niet nodig hebt (vanaf het internet), dan sluit je die best. Dat sluiten kan op verschillende manieren en ga je verder moeten opzoeken.

Veruit de meeste poorten zouden gesloten moeten zijn voor particulieren. Als je daar veel open poorten zie en je kan niet verklaren waarom (bvb je draait je eigen mailserver) zou ik daar toch iets aan doen.

[Reactie gewijzigd door oscar oscar op 24 juli 2024 11:19]

[RGAT]

Zulke sites zijn vaak vrij nutteloos, aangezien ze alleen maar TCP poorten testen (ondanks dat een aantal typische UDP poorten rechts in het lijstje als voorbeeld staan...).
Net even getest met die website en zoals gewoonlijk test het alleen TCP, RDP kan zowel TCP als UDP gebruiken en is dus niet goed te testen hiermee, vooral omdat de kwetsbaarheid voor DDoS amplification hier om UDP draait

[D0phoofd]

Als je de poort kan open zetten, dien je ook te weten wat er de gevolgen van kunnen zijn.
Dus nee, als je niet weet hoe je het kan checken, zet je de poort dicht.

[Rataplan_]

Als je in 2021 machines met RDP zo kaal aan internet hebt hangen, moet je écht een andere IT-club zoeken.. Jantje om de hoek zal het niet zo aan internet knopen en als je dit als bedrijf zo inregelt... Dan heb je het niet begrepen.

[418O2]

Wie zegt dat dit zakelijke machines zijn? Denk dat dit gewoon willekeurige pc's van willekeurige mensen zijn

[glennoo]

Maar waarom zou je een DDOS uitvoeren op willekeurige mensen?

[musiman]

Wanneer de aanvaller via RDP een heel klein pakketje stuurt naar iemand die de RDP poort open heeft staan, dan zal die een pakket terug sturen dat meer data bevat dan het oorspronkelijke pakket. De aanvaller gaat echter het source ip adres veranderen naar dat van het slachtoffer. De computer die het RDP poortje open heeft, zal het grotere pakketje dus niet terugsturen, maar juist naar dat slachtoffer sturen.
Hierdoor hoeft de aanvaller niet over veel internet bandbreedte te beschikken om toch meer data te genereren richting het slachtoffer. Een RDP amplification attack.

[Mieske666]

Het gaat om een amplification attack. Dus die willekeurige mensen worden dan gebruikt voor een DDOS.

[Mezz0]

de DDOS wordt uitgevoerd via die willekeurige mensen/pc's

[pennywiser]

Dat zie je toch niet aan het IP adres?

[Verwijderd]

Meeste mensen hebben thuis een router van de ISP, die doen alles via NAT en dus hangt RDP niet "zo maar" open en bloot aan internet....

[Verwijderd]

NAT is not a firewall. Wanneer gaan mensen dat eindelijk eens leren? Gelukkig hebben de meeste routers wel een ingebouwde firewall die deze poorten standaard dichthoudt naar de buitenwereld toe.

[Verwijderd]

NAT is ook geen firewall, maar het zorgt op zijn minst dat je niet zomaar dingen onbedoeld aan internet hangt.
Wat port-forwarding gaat niet automagisch

(En liefste zie ik NAT verdwijnen, samen met heel IPv4.... maar denk dat consumenten en IPv6 nog een issue gaat worden)

[dingo35]

"maar denk dat consumenten en IPv6 nog een issue gaat worden"

In de VS zit vrijwel iedereen op IPv6, en ik merk daar helemaal niets van consumenten die dat een issue vinden. De meesten hebben geen flauw idee, die hebben niet eens een ethernet kabel in hun modem/router maar doen alles via wifi, en de default settings van Comcast...

[Verwijderd]

Als die router default alles aan forwarding door laat kan dat nog leuk worden hoor
Dus te hopen dat de ISP dat niet doet (maar wel mogelijk maakt)

Helaas lopen we in Nederland nog eeuwen achter, want Ziggo kan het nog altijd niet leveren hier

[Verwijderd]

Nogmaals, daar hebben al die routers een firewall voor die dat verkeer tegenhoudt tenzij je een poort expliciet openzet. IPv4 of IPv6 maakt daarin geen enkel verschil. Daarnaast luisteren services bij mijn weten standaard alleen naar het link local adres dus zelfs zonder firewall op de router en op de client betekent een publiek IPv6 adres niet meteen dat de hele wereld erop kan inloggen.

[418O2]

maar dan nog; niet de hele wereld zit op hetzelfde niveau als wij he. Er zullen vast genoeg landen zijn die op een hobbybob manier verbonden zijn met het internet

[dingo35]

Sterker nog, vergeleken met de VS zitten wij (qua IPv4 vs IPv6) op een hobbybob manier verbonden met het internet.....

Nederlanders hebben het idee dat wij op vrijwel alle aspecten het beste land van de wereld zijn. Als je wat vaker, wat langer in het buitenland verblijft merk je dat dat nergens op gestoeld is....

[pe0mot]

Alle nieuwe /ziggo consumenten zitten op IPV6 en daar hoor ik ze niet klagen.
Ook bij mij werkte het prima.
(IPv4 wordt getunneld, ook een soort NAT :-) )

[Reactie gewijzigd door pe0mot op 24 juli 2024 11:19]

[Verwijderd]

Modem in routed mode: dan wel. (Dualstack lite, dus geen eigen IPv4 adres meer, daar gaat je VPN)
Bridge mode: geen IPv6 mogelijk.

Vraag ze er pas 20 jaar ofzo om, maar het is nog zulke nieuwe techniek....
Nee, dan moest ik maar een zakelijke lijn nemen, dan kan het wel.

[pe0mot]

Totdat ik bridge liet instellen werkte het prima, niks mis mee.
En ja, niet voor Tweakers omdat je geen vast ipv4 hebt.

Ik heb ipv6 nu via 4:6 tunnel, werkt prima.

[Reactie gewijzigd door pe0mot op 24 juli 2024 11:19]

[Septillion]

Mij hoor je klagen. Door de brakke IPv4 tunnel kon ik geen VPN gebruiken. Misschien ondertussen opgelost. Maar tweede issue is dat IPv6 alleen werkt als je niet in bridge draait.

[pe0mot]

Ziggo heeft en nieuwe ipv6 en oude ipv4 omgeving.
Bridge kan inderdaad alleen op de oude ipv4 omgeving. Dus moet zelf gaan je tunnelen voor ipv6.
Heb je de nieuwe omgeving dan is het standaard ipv4 tunnelen. Bij mij werkte dat prima met OpenVPN, maar ja het is NAT dus er zal vast wel iets omvallen bij de een of ander.
Helaas is ipv6 VPN nog niet gebruikelijk (waarom?).

Beiden omgevingen zijn niet super dus, maar je kan zelf de keuze maken

[Septillion]

Mja, iets met human malware en thuiswerken. Verder al even niet meer in verdiept of Ziggo de configuratie nu wel op orde heeft. Echt open zijn ze dat helaas niet over.

[Blokker_1999]

Meeste IPv6 routers gaan net alle inkomend verkeer blokkeren en daar moet je wel expliciet poorten openzetten om tot aan interne systemen te geraken.

[2cents]

Wat port-forwarding gaat niet automagisch

*zwaait* UPnP

edit: URL opmaak aangepast

[Reactie gewijzigd door 2cents op 24 juli 2024 11:19]

[Verwijderd]

Zijn er mensen die dat aan durven zetten? 🤦‍♂️😱

[2cents]

Stond in het verleden op heel veel firewalls standaard aan

[walteij]

NAT is ook geen firewall, maar het zorgt op zijn minst dat je niet zomaar dingen onbedoeld aan internet hangt.
Wat port-forwarding gaat niet automagisch

(En liefste zie ik NAT verdwijnen, samen met heel IPv4.... maar denk dat consumenten en IPv6 nog een issue gaat worden)

Tenzij je natuurlijk upnp aan hebt staan op je router, dan gaat het alsnog mis.
Verder volledig eens met je laatste zin. Ik zit overigens al een jaar of 10 ipv6 thuis in gebruik. Lang leve XS4All die dat sinds 2012 standaard aanbieden en daarvoor als een experimentele dienst.
Dat zouden meer providers moeten doen.

[Verwijderd]

XS4ALL doet dat inderdaad heel goed, jammer dat die hier alleen een prut lijn van 35mbit kunnen leveren
Heb het op mijn vorige adres jaren gehad, experimenteel, maar dat werkte gewoon super.

[telenut]

hier op het werk hebben ze zonet alle IPV6 uit gezet... niet enkel consumenten en IPv6 zijn een probleem dus

[CAPSLOCK2000]

Zoek dekking.
In mijn ervaring wordt IPv6 vooral uitgezet door mensen die het niet snappen en het daarom op de verkeerde manier uitschakelen. IPv6 uitschakelen is namelijk best lastig op een modern (Windows) systeem. Het wordt onder water namelijk op heel wat plekken gebruikt en is daarom niet makkelijk uit te schakelen. De meeste mensen denken dat het genoeg is dat ze geen IP-adres instellen of het vinkje "autoconfiguratie" weghalen.
Al die systemen zijn echter gewoon bereibkaar vanuit het lokale netwerk. Steker nog, ze gaan proberen om zelf een tunnel naar buiten op te zetten om toch maar IPv6 te kunnen spreken.

Je komt tegenwoordig niet meer weg met ipv6 "uitschakelen". Als je het wil beveiligen zal je het moeten configureren zodat je controle hebt. Als je geen verstand van zaken hebt maak je het probleem alleen maar groter door te proberen IPv6 uit te schakelen.

[telenut]

een pen tester is eens langs geweest en liet weten dat dit een zwakheid was, dus hebben ze hier beslist dit onlangs uit te schakelen via: HKLM\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters\DisabledComponents=255
Ik doe de security niet hier :-)

[CAPSLOCK2000]

Dat hebben ze dan in ieder geval wel op de juiste manier gedaan. Nog steeds niet ideaal maar ik heb erger gezien.

[Andreplusplus]

is ook zo ingewikkeld... Back to the old days?

[P-e-t-j-e]

Upnp? Volgens mij tegenwoordig al veel minder ondersteund/ingeschakeld op routers...
-edit- spuit 3843 zie ik... op mobiel toch minder makkelijk vooruitlezen

[Reactie gewijzigd door P-e-t-j-e op 24 juli 2024 11:19]

[Brahiewahiewa]

Meeste mensen hebben thuis een router van de ISP, die doen alles via NAT en dus hangt RDP niet "zo maar" open en bloot aan internet....

Ja, maar hier gaat het dus om mensen die een portforward op RDP hebben gemaakt

[Verwijderd]

Een willekeurige moet wel heel veel moeite doen om z'n Windows-PC aan de wereld te hangen. Dus dan hebben we het over een subgroep mensen die genoeg weten over port forwarding en hun router om dit te bewerkstelligen.

[Dennism]

Daar is natuurlijk exact hetzelfde van toepassing, ook die machines horen niet 'open en bloot' naar het internet open te staan. Ook daar hoort gewoon een firewall voor te zitten die RDP verkeer afvangt.

[Mezkeijou]

PC's van mensen thuis zitten toch meestal achter een firewall? Deze firewall zit in de modem/router van de internetprovider neem ik aan. Of zie ik dat verkeerd?

[w3news]

Waarschijnlijk zijn het vaak ook bedrijven die zelf de remote desktop opzetten ipv dat een IT-club het voor ze doet.
Door gebrek aan kennis zien ze daarvan niet het risico.

[Power2All]

Vaak helaas wel.
Zie ook vaak genoeg "systeem beheerdertjes" de MySQL poort open laten staan.
Moet daar vaak die mensen ook op aanspreken, eerst doen ze nog moeilijk met "maar wat is het probleem dan, ik blokkeer op basis van IP enzo in de hosts", tot je ze laat zien hoe je die SQL server plat kan bombaderen... Dan nemen ze alles terug.. zucht...

[kamerplant]

Kun je dat eens toelichten dan? Omdat je een source IP kunt spoofen en daarmee zo'n server kunt overbelasten?

[Power2All]

RDP kan TCP en/of UDP zijn.
Sessie begint als TCP, en - tenzij dat uitgezet is, of dicht gegooid is - overschakelen naar UDP.
Dit kun je ook uitzetten, en alle UDP traffic letterlijk en figuurlijk in een zwart gat laten spoelen.
Met UDP kun je inderdaad spoofen, maar met TCP wordt dat al een heel apart iets.
DNS reflection attacks (heb ze vaker gehad) is over het algemeen een UDP gat, dus gewoon zo min mogelijk UDP services hosten ?

Omtrent de MySQL open poort ding, je kan er gewoon ontiegelijk veel traffic naar MySQL port sturen, ondanks dat het er niks mee doet, maar als je heel veel connecties opzet, waardoor MySQL overbelast raakt (tenzij apps puur sockets intern gebruiken, maar dat is niet van toepassing als deze luistered op TCP), en je apps die proberen te connecten, kunnen dan niet meer connecten. MySQL staat zover ik weet, standaard op 100 connecties max, en accepteert daarna niet meer.

[Reactie gewijzigd door Power2All op 24 juli 2024 11:19]

[wica]

Is het niet aan het RDP-protocol om te controleren of het source adres overeen komt, met wat gezegd wordt naar wat je het moet sturen?

Ik zie niet de toegevoegde waarde dat computer A, kan zeggen stuur het verkeer maar terug naar computer B.

[hackerhater]

Zoek even op hoe het TCP protocol werkt

[wica]

"udp-amplification" Zoek eens uit hoe UDP werkt.

[hackerhater]

Same issue. Er is een source adres in de package en daar wordt het heen gestuurd.
En dat adres kan vervalst worden.

[Pietervs]

Een server ontvangt een RDP request van een adres en geeft daar antwoord op (bijvoorbeeld een drop als het IP adres niet op de whitelist staat). Het antwoord zal altijd gaan naar het meegezonden source adres: hoe moet de ontvangende server controleren of dat dat source adres wel of niet legitiem is?

Voor normale gebruikers heeft het verkeer sturen naar een server met een vals source adres inderdaad geen enkele toevoeging. Voor kwaadwillenden wel.

[CAPSLOCK2000]

Als je in 2021 machines met RDP zo kaal aan internet hebt hangen, moet je écht een andere IT-club zoeken.. Jantje om de hoek zal het niet zo aan internet knopen en als je dit als bedrijf zo inregelt... Dan heb je het niet begrepen.

Of andere software of beter beheer want dit is een kl*te situatie. Het hele doel van RDP is verbinding maken op afstand. Het is toch niet onredelijk om te verwachten dat je het veilig kan gebruiken als het een standaard onderdeel van je OS is?

Ik weet dat de realiteit is dat de meeste mensen hun PC niet goed patchen, geen goed wachtwoord hebben en zo nog wat meer problemen, maar daar kan RDP niks aan doen. Je kan er wel een of andere firewall of zo voor zetten maar als je die net zo slecht beheert dan levert dat ook niet veel op. Als je er voor kan zorgen dat je systemen netjes worden bijgewerkt is dat beter.

Het hele idee dat je systemen niet "direct" aan internet mag hangen, maar dat er een of andere blackbox tussen moet staat me een beetje tegen. Zo'n beetje al firewalls en security gateways bestaan uit een gewone (meestal verouderde) Linux-distributie met wat software er op die de meeste mensen toch niet kunnen bedienen en al helemaal niet snappen. In de handen van een professional kan dit soort gereedschap veel waard zijn, maar in de handen van een amateur maakt het de zaken alleen maar onduidelijk.
Die dozen zijn zelf ook niet zonder risico. Je concentreert veel gevoelige informatie op 1 plek/kanaal. Als iemand daar in weet te breken dan is er direct ook brede toegang tot heel veel datastromen.
Een beperking is dat ze alleen "van buiten" naar het verkeer kijken. Ze hebben veel minder informatie over de situatie dan de end-points. De (bv) PC van de gebruiker weet op welke knopjes de gebuiker heeft gedrukt en wat er dan moet gebeuren. Welke protocollen er gesproken gaan worden en wat voor reactie je kunt verwachten.

Ik hoop dat we als maatschappij (voor de duidelijkheid, dit is geen anti-MS-rant, hetzelfde kun je over meer software zeggen er voor kunnen zorgen dat software zo veel veiliger en betrouwbaarder wordt dat we niet meer afhankelijk zijn van externe middelen voor basale veiligheid. Een extra doos voor extra veiligheid zal altijd een goed idee blijven, maar het zou geen vereiste moeten zijn.

[Rataplan_]

MS stelt ook dat het niet de bedoeling is om je systemen met RDP zo aan internet te hangen, maar middels ren RD Deployment, waar een RD Gateway een verplicht onderdeel van is. En die tunnelt je RDP verkeer als een soort reverse proxy over HTTPS. Dat is al een heel stuk beter.

Je moet de spullen gebruiken zoals de fabrikant voorschrijft, dat moet je met je auto ook doen.

[CAPSLOCK2000]

MS stelt ook dat het niet de bedoeling is om je systemen met RDP zo aan internet te hangen, maar middels ren RD Deployment, waar een RD Gateway een verplicht onderdeel van is. En die tunnelt je RDP verkeer als een soort reverse proxy over HTTPS. Dat is al een heel stuk beter.

Als dat beter is, waarom hebben ze dat dan niet ingebouwd?
Wat doet zo'n RD Gateway dat fundamenteel niet Windows zelf kan?
Waarom gebruikt RDP nog steeds UDP als dat zo onveilig is, in plaats van HTTPS het standaard protocol te maken?

Je moet de spullen gebruiken zoals de fabrikant voorschrijft, dat moet je met je auto ook doen.

En fabrikanten moeten spullen maken die bruikbaar zijn en niet misleidend. We weten dat mensen de handleiding niet lezen. Dat is geen excuss, maar er is ook geen excuus om er geen rekening mee te houden. Dat ze de oude functionaliteit niet verwijderen snap ik vanuit het oogpunt van backwards compatibility. Maar dat je een extra product moeten kopen(?) om gebruik te kunnen maken van standaard functionaliteit vind ik gek en onwenselijk.

[Mentox]

Het is ingebouwd en onderdeel van Windows Server, je kunt het zien als een soort Proxy. Het is helaas niet iets wat je effe vlug installeert.

[CAPSLOCK2000]

Weer wat geleerd.
Maar het zit dus niet in de desktop variant van Windows?
Dat was een beetje het punt. Ze leveren iets dat blijkbaar niet compleet is en niet bruikbaar is zonder een extra product in te zetten dat op een ander systeem moet draaien. Dat het niet makkelijk te installeren is vind ik geen excuus maar juist een verzwarende factor.

[Mentox]

In de desktop variant zit het enkel in de Pro versie.

Veel enterprise software is niet makkelijk te installeren, daardoor hebben veel mensen op deze site een baan

[CAPSLOCK2000]

Veel enterprise software is niet makkelijk te installeren, daardoor hebben veel mensen op deze site een baan

Er is werk genoeg in de IT, we hoeven het niet moeilijker te maken dan nodig om bezig te blijven. Ik heb liever dat we onze kostbare IT'ers laten nadenken over echte problemen in plaats van dat ze hun tijd verdoen aan het aanpassen van een slechte standaardconfiguratie.

Als RDP echt zo moeilijk is dat je het niet aan amateurs over kan laten dan moet je het ook niet standaard aanbieden in een OS dat op consumenten gericht is. Ik zou juist verwachten dat de Pro versie er van uit gaat dat het systeem wordt beheerd door een professional, niet de Home versie.

Owja, voor de duideljkheid, ik heb het vooral over de default configuratie. Ik vind het prima dat ze veel features in de home versie stoppen, ook als die niet geschikt zijn voor de meeste gebruikers. Ik zou ook niet willen dat ze features gaan verwijderen om "domme gebruikers" te beschermen of zo iets. Het gaat me er om dat functionaliteit waarvan je kan verwachten dat veel mensen die willen gebruiken (zoals remote desktop) geen valkuil moet vormen voor mensen die minder handig zijn met computers.

Van normale mensen kan je echt niet verwachten dat ze weten dat je RD Gateway moeten configureren en dat ze daarvoor (blijkbaar) eerst hun Home editie moeten upgraden naar Pro.

Wellicht ten overvloede, maar de hele IT industrie heeft last van dit verschijnsel, niet alleen RDP/Windows/Microsoft, maar RDP is wel een belangrijk deel van het probleem. De grote uitzondering is (alweer) OpenBSD. Dat systeem levert ontzettend veel functionaliteit, maar by default staat alles uit. Applicaties gaan pas werken nadat de beheerder ze heeft geconfigureerd.

[Reactie gewijzigd door CAPSLOCK2000 op 24 juli 2024 11:19]

[Andreplusplus]

Nee, zo zit het niet helemaal. Elke windows variant heeft de remote desktop client (mstsc.exe).
Daarmee kun je naar andere windows systemen connecten. Standaard hebben de versies die dit ondersteunen een (ongebouwde) RDS server voor 2 connecties. Met RDS server kun je dat uitbreiden. Dat is niet iets technisch, maar een licentiekwestie. Verder ondersteunt RDS (S van services, P van protocol) o.a. de RD gateway, zodat je met https uit de voeten kunt van client naar gw. Handig door proxies, firewalls en zo. Maar ook een connection broker en meerdere session hosts o.a.

Dus niet "iets wat is ingebouwd in een OS voor consumenten"

Maar we dwalen af... Het artikel gaat over het misbruik dat je kan maken van RDProtocol teneinde UDP amplification te bereiken, net als bijv DNS en NTP. Klein berichtje in, groot bericht terug. En het onderliggende UDP en TCP maken het mogelijk om de afzender te vervalsen, zodat dat lange antwoord naar een aan te vallen systeem gaat.

[Mentox]

Het is niet beschikbaar voor consumenten en het staat by default uit in de versies die voor bedrijven/professionals bedoelt is.

RDP moet gewoon niet beschikbaar zijn vanaf het internet hetzelfde voor heel veel andere services. Vrijwel elke firewall blokkeert inbound traffic en het is een bewuste actie om dit open te zetten. De gewone consument heeft geen idee hoe dit werkt en is dit probleem een non-issue.

[Rataplan_]

Het IS ingebouwd. En in tegenstelling tot wat Mentox zegt, je hoeft het maar als role aan te zetten en een certificaat aan te wijzen en dan ben je er in de basis al.

[Fiander]

[...]
Waarom gebruikt RDP nog steeds UDP als dat zo onveilig is,
in plaats van HTTPS het standaard protocol te maken?
[...]

eerste: performance. Met UDP kun je dom je beeldinfo sturen, zonder te wachten op responce. hier TCP gebruiken heeft geen zin. Wanneer een netwerkpakketje verloren gaat, komt die beeld info vanzelf opnieuw zodra er een key packet ( mp4) verstuurt wordt. Wanneer TCP ipv UDP gebruikt zou worden, zou de latencie heel erg toenemen. en je scherm veel lag vertonen.

HTTP(s) is een data protocol, en geen netwerk protocol.
Dus neem ik aan dat ipv HTTPS je TCP met een ssl tunnel bedoelt?
Dat is RD Gateway.

[Reactie gewijzigd door Fiander op 24 juli 2024 11:19]

[CAPSLOCK2000]

Je hebt vast gelijk over HTTPS versus een SSL-tunnel over TCP, ik weet zelf niks van RDP en reageer op wat er voor mij gezegd werd. Maar het exacte protocol doet er niet toe. Het gaat er om dat de default keuze blijkbaar niet veilig (genoeg) is.

Lage latency vind ik geen goed argument.. MS adviseert blijkbaar zelf om RD Gatway te gebruiken. Dan moet het dus snel genoeg zijn. Dat kan dus niet de reden zijn om het niet standaard aan te bieden.
Overigens kun je ook SSL/TLS over UDP doen, en HTTP/3 loopt ook via UDP. Het probleem is dus niet UDP zelf, maar het protocol dat er bovenop is gebouwd.

[Fiander]

Nee, standaard werkt het voor iedereen, ook in een thuis netwerk of bij het mkb.
Wil je veilig, dan zul je RD Gateway + een geldig certificaat moeten toevoegen.

Vooral dat certificaat is een dingetje wat voor afgeschermde kleine omgevingen soms niet te doen is.

Lage latency sloeg op UDP vs TCP. UDP werkt ook via SSL, en heeft ook daar een lage latencie.

[CAPSLOCK2000]

Nee, standaard werkt het voor iedereen, ook in een thuis netwerk of bij het mkb.
Wil je veilig, dan zul je RD Gateway + een geldig certificaat moeten toevoegen.

Dat vind ik tegenwoordig dus de verkeerde keuze, dat is niet meer van deze tijd.
Systemen horen out-of-the-box veilig te zijn. Als dat bij bepaalde funcionaliteit niet kan, dan moet die functionaliteit uitgeschakeld blijven tot iemand het goed inricht.

Vooral dat certificaat is een dingetje wat voor afgeschermde kleine omgevingen soms niet te doen is.

Afgeschermde kleine omgevingen zijn de uitzondering, niet de regel. In die zeldzame gevallen zal er ook altijd een systeembeheerder zijn om de configuratie aan te passen, of een eigen CA op te zetten of zoiets. Daarom blijf ik er bij dat de default moet zijn dat het veilig is.

Ik snap dat het verkrijgen van "echte" SSL-certificaten lastig kan zijn, maar dat vind ik geen excuus. Iedere website heeft tegenwoordig zo'n certificaat, aan remote desktop moeten we toch minstens dezelfde eisen stellen.
Maar we hoeven ons ook niet vast te staren op "echte" SSL-certificaten van een "echte" CA als enige oplossing. We hebben tegenwoordig voldoende middelen om verbindingen te beveiligen. Zo zou je een lokaal SSL-certificaat kunnen aanmaken en dat via een QR code aan de gebruiker laten zien zodat die dat certificaat op z'n telefoon kan zetten en vanaf daar doorgeven aan andere systemen die RDP willen doen.

We hebben de afgelopen jaren enorme stappen genomen op het vlak van ad-hoc security, trust on first use en het aanmaken en verspreiden van digitale sleutels.

Onveilige defaults zijn tegenwoordig niet meer acceptabel. Als het echt niet anders kan dan moet een systeembeheerder kunnen kiezen voor een onveilige oplossing, maar dat moet niet de standaard zijn.

[Reactie gewijzigd door CAPSLOCK2000 op 24 juli 2024 11:19]

[Roxsman]

Maar waar staat dan dat MS RDP adviseert als internet tool?
Je moet tenslotte poorten open gaan zetten om het over internet werkend te krijgen. Je gaat toch ook niet SMB op je firewall doorzetten naar je Windows bak? Dat is ook default aanwezig.
RDP is bedoeld om gebruikt te worden in een secure omgeving, net als talloze andere protocollen in Windows.
Dat kun je jammer vinden maar er zijn genoeg veilige alternatieven, zelfs van MS zelf zoals hierboven al aangegeven.

[Andreplusplus]

Waarmee je hebt bewezen er geen verstand van te hebben. Dan kun je beter in RDS verdiepen dan op deze draad te antwoorden...

[Snow_King]

Exact. OpenSSH kan je gewoon aan het internet hangen. Password auth uit, enkel keys toe staan en vervolgens zorgen dat je je updates in orde hebt.

iptables/ip6tables om daar waar nodig eventueel nog de brute-forces te blokkeren, maar verder kan dat gewoon.

En RFC1918 IPv4 space. Wat een horror is dat.

[CAPSLOCK2000]

Exact. OpenSSH kan je gewoon aan het internet hangen. Password auth uit, enkel keys toe staan en vervolgens zorgen dat je je updates in orde hebt.

Eerlijk gezegd vind ik dat ook niet goed genoeg meer. We roepen al jaren dat (alleen) password authentication niet verstandig is. Wat mij betreft wordt dat by default uitgeschakeld.

Als je in staat bent om een wachtwood in te stellen dan ben je ook in staat om een ssh-key aan te maken of TOTP of een andere vorm van MFA in te stellen, of desnoods om wachtwoord authenticatie weer in te schakelen als het echt niet anders kan.

Hetzelfde geldt voor automatische updates. Die zouden overal standaard aan moeten staan. Het moet niet nodig zijn dat een gebruiker dat zelf doet. Ik snap dat er situaties zijn waarin automatische updates ongwenst zijn, maar in die gevallen moet de beheerder ze maar uitschakelen.

[Andreplusplus]

Hetzelfde geldt voor automatische updates. Die zouden overal standaard aan moeten staan.

Sorry, maar *kuch*. Dat ligt iets genuanceerder. Zie bijv. supply chain attacks als Solorigate ( Sunburst) en de event-stream open source library.

Verify what's happening on your box.

[Reactie gewijzigd door Andreplusplus op 24 juli 2024 11:19]

[Gijs007]

Leg eens uit. Het klinkt nu net alsof RDP een inherent onveilig protocol is.

[pennywiser]

Dat zijn de oudere versies zeker. Vaak is het nog een SBS 2008 wat nog ergens staat te draaien en upgrade al jaren is uitgesteld. Want het werkt toch. Huidige en bijgewerkte versies zijn secure. Maar überhaupt als poort 3389 ontdekt wordt op jouw netwerk is dat natuurlijk heel interessant.

[Andreplusplus]

Huidige en bijgewerkte versies zijn secure.

Keep dreaming

[pennywiser]

Goed verhaal, lekker kort ook.

[Andreplusplus]

Says it all

[DarkMagician]

Ik heb mijn VPS met RDP aan het internet hangen maar de firewall staat alleen RDP toegang toe vanaf mijn thuis IP adres. Waarom zou dat minder veilig zijn dan een VPN of waarom zou ik een VPN “moeten” hebben?

[GeroldM]

Dan heb je veel vertrouwen in je firewall. Is je firewall een losstaand systeem? Of denk je dat je Windows firewall al afdoende is?

Alhoewel de Windows firewall op zichzelf geen slechte firewall is (mits strikt geconfigureerd), een losstaand systeem met OpenBSD/FreeBSD als besturingssysteem voorzien van een firewall is een stuk veiliger dan een firewall die draait op het systeem dat je gebruikt om te internetten. Kan je vergelijken met het bouwen van een huis in een moerasgebied. Onmogelijk? Nee. Verstandig? Zeker niet.

Een VPN is beter als je met vertrouwelijke gegevens bezig bent over het internet. Het is een extra beveiligingslaag. Per laag word je steeds minder aantrekkelijk voor de (relatief) gemakkelijk ingestelde "script-kiddies" en soortgelijke lieden.

Je hoeft het niet te hebben, maar omdat jij het niet hebt en alle anderen wel...dat maakt jou automatisch het makkelijkste doelwit. In hoeverre je daar vrede mee hebt, kan ik en wil ik niet voor jou bepalen.

[DarkMagician]

Neen ik snap niet best wat je bedoelde.. het was mij onduidelijk en ik was oprecht geïnteresseerd of “mijn” oplossing veilig genoeg was.

[Keypunchie]

Het is een behoorlijke 'bad practice' om een RDP-poort open naar het internet te zetten. Die wil je achter een firewall of VPN.

Doe het ook niet thuis, maar dan op een hogere poort, dat is security through obscurity en gaat je niet redden van kwaadwillende scanners.

[FreqAmsterdam]

Of een remote desktop gateway, dan RDP je over HTTPS.

[Bose321]

Hoe moet het dan wel? Ik heb een W10 HTPC die ik best vaak wil benaderen van een externe locatie om wat dingen te regelen in het netwerk thuis of voor andere redenen. Hoe kan ik er dan wel veilig bij? Ik hoop dat er naast VPN een goede optie is, dat kan nogal omslachtig zijn soms.

[synoniem]

Activeer SSH-server op je W10 HTPC (optionele software), schakel inloggen met wachtwoord uit en sta alleen gebruik van ssh keys toe. Installeer op je externe pc Bitvise Tunnelier (gratis voor privégebruik), voeg de ssh key toe, bij de connectie je externe IP of domein van je HTPC en voor Remote desktop je interne IP nummer. Je moet uiteraard net als met RDP waarschijnlijk de ssh port forwarden op je modem/router en een ander extern nummer dan standaard 22 kiezen scheelt iets in de inlogpogingen.

[pennywiser]

SSH welke poort dan ook naar buiten is net zo not done.

[synoniem]

Zolang je geen root acces en geen password access toestaat is er weinig mis met SSH. Uiteindelijk is het voor veilige communicatie gemaakt. Uiteraard is het meest veilige om de netwerkadapter uit je pc te halen en dan nog loop je risico's via je usbpoorten etc. 100 procent veilig bestaat niet.

[pennywiser]

Certificate based vpn komt dichtbij. Wat straal je uit denk je als je in het zakelijke verkeer zegt valt wel mee, zet SSH maar gewoon open naar buiten.

[synoniem]

In een zakelijke omgeving heb je beter schaalbare oplossingen. Maar dan nog kun je ook ssh icm certificaten gebruiken of ldap based access met certificaten en ssh keys. In tegenstelling tot rdp gebruikt ssh wel echte encryptie.

[Keypunchie]

Hoe kan ik er dan wel veilig bij?

Thuis een VPN draaien.

Ik hoop dat er naast VPN een goede optie is, dat kan nogal omslachtig zijn soms.

Oh, dan is het antwoord: niet. Dan kan je er *niet* veilig bij komen.

Wel onveilig, uiteraard en dat kan, net als onveilige sex, of onveilig rijden, heel lang goed gaan.

Maar ja, beveiliging doe je niet voor de happy flow.

[Reactie gewijzigd door Keypunchie op 24 juli 2024 11:19]

[3raser]

Ik doe dat ook en heb mijn PC een andere poort gegeven om mee te communiceren. Standaard poortscanners gaan nooit alle 65535 poorten scannen dus zet je RDP ergens op 42981 ofzo en de kans dat hij gevonden wordt is al flink verkleint. Bovendien heb je naar mijn idee helemaal geen UDP nodig om te verbinden met je desktop dus zorg ervoor dat alleen TCP wordt doorgelaten in je firewall. Dan is deze amplification aanval ook weer afgewend. Dit is overigens geen handleiding voor succes maar enkel om het risico iets te verkleinen.

[3raser]

Ik heb een RDP open staan voor het internet (niet via de standaard poort) en heb deze alleen open staan voor het TCP protocol. Waarom heb je UDP nodig voor RDP?

[Marctraider]

Omdat TCP helemaal niet efficient is voor remote desktoping.

Sterker nog TCP is eigenlijk gewoon een verouderd protocol.

[3raser]

Het is een oud protocol, maar verouderd? Welk protocol is er beter dan TCP dan? TCP is blijkbaar wel een stuk veiliger als het om DDoS amplification gaat.

[pennywiser]

Dat laatste moet je even uitleggen, aan iedereen die het probeert te begrijpen. Verouderd =/= oud.

[Fiander]

Omdat TCP helemaal niet efficient is voor remote desktoping.

Eens, daarom ook UDP, het is niet nodig dat voor elk ontvangen netwerkpakket bevestiging gestuurd word.

Sterker nog TCP is eigenlijk gewoon een verouderd protocol.

Oke? welke andere is er dan nieuwer welke je kunt gebruiken?
waarop zouden we moeten we overstappen?

[GeroldM]

TCP is een protocol dat is ontworpen voor een ander doel dan hoe het tegenwoordig op het internet word gebruikt.

Voor dat doel is het nog altijd een uitstekend protocol. Het doel is om relatief betrouwbare verbindingen op te zetten tussen meerdere nodes met zeer verschillende netwerkvormen. Snelheid was daarbij het het spreekwoordelijke "roodharige stiefkind".

Dat TCP een (erg) oud protocol is, betwist ik niet.

Het UDP protocol geeft geen snars om betrouwbaarheid, waardoor het automatisch een flink stuk sneller is dan TCP. Dat het daarom veruit te preferen valt voor RDP verbindingen betwist ik ook niet.

Het gebruik van internet is echter zodanig veranderd dan destijds voorzien. Dat maakt TCP niet automatisch goed of slecht. Om dus zogenaamd blind te stellen dat TCP verouderd is, dat is een beetje te kort door de bocht.

[Fluttershy]

Laat RDP naar poort 22 luisteren.

En SSH naar poort 3389.

Ben je meteen van 95% van alle mafkezen verlost.

[RGAT]

Of stel het goed in en zet SSH en RDP niet naar internet open...
Poorten omgooien is leuk om een deel van automatische pogingen nutteloos te maken maar zoals altijd: jij moet 100% succesvol zijn, een aanvaller hoeft maar 1 keer geluk te hebben, poorten omgooien is dus hooguit een aanval even uitstellen, er een VPN voor opzetten zoals het hoort voorkomt het een stuk beter.

Overigens zat exploitkits die hier ook automatisch prima doorheen prikken, maakt dan niet uit of je SSH op poort 22, 8080 of 1337 hebt open staan...

[pennywiser]

Inderdaad SSH is naar buiten ook niet doen. De TCP header is gewoon uit te lezen.

[Terrestrial]

Die letterlijk miljarden servers ter wereld die ssh port 22 publiek beschikbaar hebben moeten dat dus maar niet meer doen?

[RGAT]

Noem er eens een paar als het er miljarden zijn volgens jou, van een fatsoenlijke partij dus niet 'Barry Beunhaas Hosting BV' ?

En ja, die zouden ze niet open moeten hebben, zoals ik al zei.

[Terrestrial]

Joh ga zelf even met shodan kijken of zo. Ik denk dat jij moet beseffen dat een VPN server ook gewoon een service is die op een host draait en luistert op een open poort.

Als jij de boel geüpdatet houdt en dat kun je automatiseren. En een goede manier van authentiseren gebruikt en bijv. fail2ban is SSH net zo acceptabel als een VPN server om publiekelijk beschikbaar te houden.

Dat wil niet zeggen dat het niet nog beter kunt beveiligen natuurlijk, alleen is het niet zoals jij doet voorkomen.

[RGAT]

Tja je stelt dat er 'letterlijk miljarden servers' zijn maar je kan er geen eens 1 aanwijzen?...

Ik zei dat poortjes omgooien geen beveiliging is, je SSH op poort 22 wordt net zo goed geprobed als wanneer je poort 1337 of 666 zou gebruiken. Daar reageer jij op dat er letterlijk miljarden servers ter wereld zijn die poort 22 open zetten, ten eerste niet erg relevant en ten tweede gewoon onwaar, Shodan vindt voor 'SSH' 19,311,901 resultaten...
Even door de calculator gehaald en dan geef ik je nog een voordeel door maar met 2 miljard te rekenen maar je zit er een factor 103,5 naast, als je SSH beveiliging net zo 'goed' is ben ik blij beveiliging een stukje serieuzer te nemen dan er 103 naast te zitten onder het mom van 'aanname is goed genoeg'...

[Terrestrial]

Ik hoef jou niks te bewijzen, ik zeg ook niet dat je ze allemaal met shodan gaat vinden, jij wou een voorbeeld, ik zeg ga zelf even kijken met shodan ofzo. Shodan heeft er dus schijnbaar al 19 miljoen geïndexeerd, dat wil niet zeggen dat er niet veel meer zijn en ze kunnen ook op andere poorten draaien. Met mijn servers deed ik dat ook een andere port omdat ik geen zin had in dat continue proben op port 22, dan heb je 99% van de shit al uitgesloten, de rest vangt fail2ban op en keypair authenticatie.

Het gaat er om dat SSH een geaccepteerde vorm van veilig remote management is en wordt standaard publiekelijk aangeboden. Praktisch alle hosters groot of klein leveren jou een vps of server met public beschikbare SSH oplossing. Je kunt dat natuurlijk zelf verder afschermen, goed voor jou! maar dat is niet de gewoonte en daar gaat het om.

[RGAT]

Praktisch alle hosters groot of klein raden ook aan, en de betere vereisen het zelfs, dat je daarvoor IPs whitelist dus 'public open' is het dan niet als er alsnog een firewall voor staat...

Anyway, poortjes omgooien is symbolisch maar geen beveiliging, als je dat wel denkt zou ik aanraden even eens de logs door te lezen, noem dan ook eens 1 server die het zo draait of kom eens met 1 argument ipv 'ik vindt SSH op 22 goet!'...

[Terrestrial]

Je leeft in een droomwereld, niemand vereist wat en whitelisten wordt vaak als onhandig beschouwd. ik was al vooruitstrevend door SSH op een andere port te draaien. Kom jij is met een overtuigend argument waarom het niet moet doen dan.

Heb jij ooit gehoord dat de SSH service gehackt was? dus niet binnenkomen op basis van een slecht wachtwoord. Ik zeg niet dat het niet kan als er een kwetsbaarheid opduikt maar men beschouwd SSH in het algemeen als "veilig" Je gaat je VPN server ook niet met een whitelist gebruiken, ja alles kan maar niemand doet dat.

En om je een voorbeeld te geven, XS4ALL draait al 25 jaar een shell server waar je als klant op kan inloggen gewoon op poortje 22.

[RGAT]

Zou zeggen lees de eerste reactie waar je op reageerde nog een keer goed door, staat het al in beschreven...
Daarna gebruik jij als argument voor een andere poort gebruiken dat er 'miljarden SSH servers zijn' waar je geen onderbouwing voor brengt behalve Shodan, die je punt zelfs onderuit haalt en dan nog is het raar dat je punt is dat poortjes wisselen goed is omdat volgens jou niemand het doet (want miljarden draaien op poort 22 volgens jou, dus niet een andere poort)...

Zat hosters die het wel vereisen, zou zeggen koop eens een maandje een VPSje ergens, gewoon leuk om e.a. mee te leren en niet erg duur, kan je gelijk zien hoe e.a. werkt, inclusief het whitelisten

Je gaat je VPN server ook niet met een whitelist gebruiken? Eh ja, zat VPN oplossingen die dat standaard zelfs al hebben, ja je OpenVPN servertje thuis op je Raspberry Pi heeft het niet maar in de echte omgevingen is het vrij normaal, wil niet zeggen dat het de meerderheid is maar een groot deel heeft dat dus wel...

Leuk trouwens dat je XS4ALL noemt, een van hun servers werd jaren terug al gehackt dankzij de SSH service

Ik zou zeggen ga eens een keer spelen met een VPS, leer de stof en kom dan terug om uit te leggen waar jouw 'miljarden servers' met poort 22 te vinden zijn en waarom jij dat als argument wil gebruiken dat het veranderen van de poort goed zou zijn

Er is overigens niet 'de SSH service', er zijn meerdere tools die een SSH server draaien, door verschillende fabrikanten, handig om te weten

[Terrestrial]

Grappig dat je mij aanraad een VPS server te nemen terwijl je dat beter zelf kan doen. Ik beheer al 20+ jaar public faced servers. En de XS4ALL hack waar jij aan refereert, ik moest ff zoeken was op basis van een exploit die ze gebruikt hebben toen ze al binnen waren om de rechten te eleveren op een oud bsd systeem.

Nogmaals SSH wordt gezien als een veilige manier om servers te beheren en ik vermoed niet dat dit op korte termijn veranderd, dat je het verder beveiligd vind ik prima maar dat wil niet zeggen dat het je niet publiekelijk mag draaien.

Ik draai op een ander poortje omdat het less obvious is, niet wat jij er van maakt. Maar ik maak me niet druk over beveiliging want bij geklooi wordt je automatisch geblokkeerd door de firewall dankzij fail2ban en dat werkt makkelijker dan een whitelist. En ook VPN oplossingen werken zelden met een whitelists. Ben benieuwd hoe jij het aanpakt als je 100+ man met wisselende IP's moet laten inloggen. En je kunt zelfs nog over een SSH verbinding tunnelen.

anyways laatste reactie. betere dingen te doen.

[Fiander]

Wil me niet in de ssh\vps discussie mengen, MAAR....
Ook ik maak vaak genoeg mee dat mensen met het argument komen : "Dat doe ik al x jaar zo, en gaat altijd goed."

stevast mijn antwoord op die dooddoener : Dan doe je het al x jaar fout.

Wie beweerd, die bewijst. Dus mogen de beheerders bij wie het al "jaren goed gaat" dat ook bewijzen.
Bewijs maar dat de server veilig is, en er niemand opzit die er niet op thuis hoort.

Wie beweerd dat er miljarden... Die bewijst dat er miljarden. Niet het uitzoek werk dan bij de andere partij leggen. Hoewel dat natuurlijk wel het perfecte voorbeeld in dit artikel is.

Jij schreeuwt iets ( kleine zin, kost weinig tijd ), en de ontvanger moet de bewijsvoering doen ( veel werk, veel tijd ). Perfect voorbeeld van hoe amplification in de praktijk werkt. En de oplossing is altijd, leg de bewijslast waar die hoort. Dan heb je dit soort "Bugs" ook niet.

[Andreplusplus]

En shodan is volledig ... not!

[GekkePrutser]

Nou, alle nieuwe servers van Scaleway en DigitalOcean bijvoorbeeld. Openen altijd standaard poort 22 maar wel met enkel key authenticatie. Niettemin is die poort inderdaad wel het eerste dat ik verander.

Is op zich niet zo veel mis mee vind ik. Het voordeel daarvan is dat je er altijd nog bij kan als je VPN het opgeeft.

[Reactie gewijzigd door GekkePrutser op 24 juli 2024 11:19]

[Power2All]

Wanna-be Windows systeem beheerders ?
RDP sowieso inderdaad aan internet hebben is vragen om gehacked te worden.
Er is een reden waarom ik een VPN als tussen blok heb zitten voor remote access naar mijn servers.

[Frogmen]

Waarschijnlijk beheerders wiens baas het toch allemaal al zo duur vinden en het verder niet snappen en geen tijd willen besteden aan het ontvangen van uitleg. Bazen waar niemand voor wil werken eigenlijk maar bij gebrek aan beter iedere keer toch weer personeel krijgen.
Dit komt vaker voor dan dat we denken, waarschijnlijk dezelfde die mensen nu nog verplichten naar kantoor te komen.

[theduke1989]

tja we leven nu eenmaal ook in een tijd dat alles via het netwerk hoort, en dan ook nog eens thuis etc, alles wordt over de cloud gedaan. Vroeger brak je in fysiek nu doe je het over het WWW. niks nieuiws aan denk ik zo.

[xavalon]

Criminelen gebruiken steeds vaker het Remote Desktop Protocol op Windows voor het uitvoeren van ddos-aanvallen.

Criminelen of kwaadwillenden? ... nogal een verschil.

[Reactie gewijzigd door xavalon op 24 juli 2024 11:19]

[Verwijderd]

Als je anderen DDOSt bent je volgens mij sowieso een crimineel, tenzij je het op je eigen resources probeert voor testdoeleinden.

[Keypunchie]

Criminelen of kwaadwillenden? ... nogal een verschil.

Elke crimineel is kwaadwillend, maar niet elke kwaadwillende is per se een crimineel. Zoiets, bedoel je?

[Zomaareenmening]

Inderdaad, als je zo een criminele website platlegt zou dat op kunnen gaan.. Soort koekje van eigen deeg..