{"id":41229,"date":"2020-02-06T20:43:00","date_gmt":"2020-02-06T17:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/opasno-li-derzhat-otkrytym-rdp-v-internete"},"modified":"2020-02-06T20:43:00","modified_gmt":"2020-02-06T17:43:00","slug":"opasno-li-derzhat-otkrytym-rdp-v-internete","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/opasno-li-derzhat-otkrytym-rdp-v-internete","title":{"rendered":"Is het gevaarlijk om RDP open te houden op het internet?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ik heb vaak de mening gelezen dat het openhouden van de RDP (Remote Desktop Protocol) poort op het internet behoorlijk onveilig is en dat je dit niet moet doen. Je zou toegang tot RDP alleen via een VPN moeten verlenen, of alleen vanaf bepaalde 'witte' IP-adressen.<\/p>\n

<\/p>\n

Ik beheer verschillende Windows Server voor kleine bedrijven, waar ik de taak heb gekregen om afstandstoegang tot de Windows Server voor accountants te bieden. Dit is de moderne trend: werken vanuit huis. Al snel realiseerde ik me dat het een moeilijke taak is om accountants met een VPN te werken, en het zou niet lukken om alle IP-adressen voor de whitelist samen te stellen, omdat de IP-adressen van mensen dynamisch zijn.<\/p>\n

<\/p>\n

Daarom nam ik de eenvoudigste route \u2014 ik opende de RDP-poort naar buiten. Nu hoeven accountants alleen maar RDP te starten en de hostnaam (inclusief poort), gebruikersnaam en wachtwoord in te voeren om toegang te krijgen.<\/p>\n

<\/p>\n

In dit artikel deel ik mijn ervaringen (zowel positieve als minder positieve) en aanbevelingen.<\/p>\n

<\/a><\/noindex><\/p>\n

Risico's<\/h3>\n

<\/p>\n

Wat riskeer je door de RDP-poort te openen?<\/p>\n

<\/p>\n

1) Onautoriseerde toegang tot gevoelige gegevens<\/b>
\nAls iemand het wachtwoord voor RDP weet te raden, kan hij toegang krijgen tot gegevens die je priv\u00e9 wilt houden: rekeningsaldi, balances, klantgegevens, \u2026<\/p>\n

<\/p>\n

2) Gegevensverlies<\/b>
\nBijvoorbeeld als gevolg van het werk van ransomware.
\nOf door weloverwogen acties van een aanvaller.<\/p>\n

<\/p>\n

3) Verlies van de werkstation<\/b>
\nWerknemers moeten kunnen werken, maar het systeem is gecompromitteerd, het moet opnieuw worden ge\u00efnstalleerd \/ hersteld \/ geconfigureerd.<\/p>\n

<\/p>\n

4) Compromittering van het lokale netwerk<\/b>
\nAls een aanvaller toegang krijgt tot een Windows-pc, kan hij vanaf die computer toegang krijgen tot systemen die vanuit het internet niet toegankelijk zijn. Bijvoorbeeld netwerkshares, netwerkprinters, enzovoort.<\/p>\n

\nIk heb een geval gehad waarin een Windows Server ransomware te pakken kreeg<\/b><\/p>\n

en deze ransomware versleutelde eerst de meeste bestanden op schijf C:, en begon toen bestanden op de NAS via het netwerk te versleutelen. Aangezien de NAS een Synology was, met ingestelde snapshots, kon ik de NAS in 5 minuten herstellen, terwijl ik de Windows Server vanaf nul opnieuw moest installeren.<\/p>\n

<\/p>\n

Observaties en Aanbevelingen<\/h3>\n

<\/p>\n

Ik monitor Windows Servers met behulp van Winlogbeat<\/a><\/noindex>, die logs naar ElasticSearch versturen. In Kibana zijn er verschillende visualisaties, en ik heb nog een aangepaste dashboard ingesteld.
\nDe monitoring zelf beschermt niet, maar helpt bij het bepalen van de nodige maatregelen.<\/p>\n

<\/p>\n

Hier zijn enkele observaties:
\na) RDP zal worden gebruteforced.<\/b>
\nOp een van mijn servers heb ik RDP niet op de standaardpoort 3389 gezet, maar op 443 - zodat het lijkt op HTTPS. Het is misschien de moeite waard om van de standaardpoort te veranderen, maar dat biedt niet veel voordelen. Dit is de statistiek van deze server:<\/p>\n

\n\"Is<\/p>\n

Het is duidelijk dat er in een week tijd bijna 400.000 mislukte pogingen waren om via RDP toegang te krijgen.
\nHet is duidelijk dat de pogingen om in te loggen afkomstig waren van 55.001 IP-adressen (sommige IP-adressen waren al door mij geblokkeerd).<\/p>\n

<\/p>\n

Hier ligt de conclusie voor de hand dat je fail2ban moet installeren, maar <\/p>\n

\nVoor Windows bestaat er zo'n tool niet.<\/b><\/p>\n

Er zijn een paar verlaten projecten op GitHub die dit blijkbaar proberen, maar ik heb ze nog niet geprobeerd:
\nhttps:\/\/github.com\/glasnt\/wail2ban<\/a><\/noindex>
\nhttps:\/\/github.com\/EvanAnderson\/ts_block<\/a><\/noindex><\/p>\n

<\/p>\n

Er zijn ook betaalde tools, maar die heb ik niet overwogen.<\/p>\n

<\/p>\n

Als je een open tool voor dit doel kent, deel deze dan in de reacties.<\/p>\n

<\/p>\n

Bijwerken<\/strong>: In de reacties werd gesuggereerd dat poort 443 een ongunstige keuze is, en het beter is om hoge poorten (32000+) te kiezen, omdat 443 vaker gescand wordt, en het geen probleem is om RDP op deze poort te herkennen.<\/p>\n

<\/p>\n

Update:<\/strong> In de reacties werd gesuggereerd dat er zo'n tool bestaat:
\nhttps:\/\/github.com\/digitalruby\/ipban<\/a><\/noindex><\/p>\n

<\/p>\n

b) Er zijn bepaalde gebruikersnamen die aanvallers liever gebruiken.<\/b>
\nHet is duidelijk dat de brute-force aanvallen gebaseerd zijn op een woordenlijst met verschillende namen.
\nMaar wat ik opmerkte: een aanzienlijk aantal pogingen gebruikt de naam van de server als login. Aanbeveling: gebruik niet dezelfde naam voor de computer en de gebruiker. Bovendien proberen ze soms de naam van de server op de een of andere manier te parseren: bijvoorbeeld voor een systeem met de naam DESKTOP-DFTHD7C zijn de meeste pogingen om in te loggen met de naam DFTHD7C:<\/p>\n

\n\"Is<\/p>\n

Dus als je een computer DESKTOP-MARIA hebt, is de kans groot dat er pogingen komen om in te loggen als gebruiker MARIA.<\/p>\n

<\/p>\n

Wat ik nog opmerkte uit de logs: op de meeste systemen is de meerderheid van de inlogpogingen met de gebruikersnaam 'administrator'. En dat is niet voor niets, want in veel versies van Windows bestaat deze gebruiker. Bovendien kan hij niet worden verwijderd. Dit vergemakkelijkt de taak voor kwaadwillenden: in plaats van zowel een naam als een wachtwoord te raden, hoeven ze alleen maar het wachtwoord te raden.
\nOverigens had het systeem dat slachtoffer werd van de ransomware de gebruiker Administrator en het wachtwoord Murmansk#9. Ik ben er nog steeds niet zeker van hoe dat systeem werd gehackt, omdat ik pas begon te monitoren na dat voorval, maar ik denk dat brute-forcing waarschijnlijk is.
\nDus als de gebruiker Administrator niet verwijderd kan worden, wat te doen? Je kunt hem hernoemen!<\/p>\n

<\/p>\n

Aanbevelingen uit dit punt: <\/p>\n

<\/p>\n