Das sind böse Bots im Internet, die versuchen Dein Passwort zu erraten.
Schnelle, aber wirklich keine gute Lösung: Gibt dem Admin Benutzer einen anderen Namen.
Bessere Lösung: Benutze die Netcup Firewall und lasse RDP Verbindungen nur von einer (festen) IP von Dir zu. Im gleichen Zug am besten auch alle anderen Ports zu nageln, ein Windows Rechner ohne Firewall im Internet ist nie eine gute Idee.
Beste Lösung: installiere wireguard und schließe alle eingehenden Ports in der Netcup Firewall bis auf wg. Da dies UDP ist, ist das ein bisschen ein gebastel, da stateless. Suche mal im Forum danach. Dann ein wg Tunnel aufmachen und RDP darüber ist dann auch sinnvoll verschlüsselt.
Die absolut sinnvollste Lösung wäre, das public Interface komplett zu deaktivieren. Als Gateway für den Windows Server nutzt du einen kleinen Linux Server per vlan. Im Idealfall verbindest du dich dann per VPN z.b WireGuard mit dem Linux Sever und baust so die RDP Verbindung auf. Alles andere ist absolut nicht zu empfehlen und hoch risikoreich.
Das ist eine Default Einstellung bei einem Default Windoof. Beim roten H hatte ich das Problem nicht da die einstellung der Sperre Default aus war, da war ich aber auch so dumm, RDP komplett offen zu lassen, dafuer aber mit einem extrem langen Passwort. Naja, man lernt dazu und verbessert seine Sicherheit; zum Glueck nutze ich keinen Windoof Server mehr.
Am besten, wie bereits gesagt wurde: Anderen Username, starkes Passwort und vielleicht noch einen Jumphost, also RDP nur ueber einen vertrauenswuerdigen Linux Server zum Windoof Server... 
Und am besten sogar noch den RDP-Port aendern. Windoof Server sind sehr grosse Zielscheiben im Internet.
Windows Server, die im Internet hängen mit offenem RDP Port werden PERMANENT mit Brute Force Attacken bombardiert (schau mal in Deine Logs). Folgende Schritte wären nicht nur empfehlenswert, sondern aus Sicherheitsgründen dringend wichtig:
- Neuen Adminuser erstellen (neuen, nicht leicht erratbaren Benutzer erstellen - als nicht "Admin" - in Admingruppe hinzufügen), als dieser einloggen, Standard "Administrator" deaktivieren. Schon mal RIESIGES Scheunentor zu
- https://tailscale.com/ oder einen anderen VPN Client installieren, Login über VPN versuchen und sicherstellen dass es geht
- Netcup Firewall im Servercontrolpanel konfigurieren, eine Regel "41641 UDP eingehend offen" einrichen und ansonsten alles eingehend zu machen (Standard bei Aktivierung, außer SSH). Dadurch fallen alle Brute Force Attacken auf den RDP Port 3389 weg und der Zugang ist sicher.
Wenn Du das befolgst, hast Du alle o.g. Probleme nicht mehr und bist DEUTLICH sicherer unterwegs, auch später gegen versehentliche offene Ports.
RDP Port (Security by Obscurity) ändern ist imho nur gegen low effort und automatisierte Angriffe sinnvoll, ein Portscan wird selbstverständlich den RDP Port auch woanders finden.
So sollte es aus Sicherheitsgründen auch sein. Alles zu und nur was benötigt wird selektiv und restriktiv manuell auf.
Oder brauche ich das nicht?
Doch - vermutlich für NTP- und DNS-Antworten (sofern Du nicht ausschließlich die netcup DNS-Server benutzt) und ggf. weitere von Dir benutzte Dienste, die per UDP arbeiten.
Erst mal https://www.netcup.com/de/helpcenter/…server/firewall . Dann fragen.
Trotz Aufwand bei der Einrichtung ist es extrem empfehlenswert, die externe Firewall korrekt und mit minimaler Öffnung zu konfigurieren.
Mein Tip: im SCP bei rechts oben Optionen -> dann links "Firewall Policies". Dort pro Dienst eine Policy erstellen, auch ggfalls mit mehreren Bestandteilen / Ports. Und dann zum Server gehen und die benötigte Policy zuweisen (Pfeil nach rechts).
Trotzdem geht es nicht
Konkrete Fehlerbeschreibung oder ein Screenshot der Firewall Konfiguration wäre hilfreicher als diese Aussage.
Das ist mir klar. die Hilfe habe ich durch.
Trotzdem geht es nicht
Aktivier doch die Netcup Firewall, mach erst einmal alles incoming und outgoing dicht und setze eine Freigabe fuer deine WAN IP-Adresse auf den RPD-Port (3389 TCP/UDP).
INCOMING Rule, Source IP: deine IP, Target IP: IPv4/6 deines Servers, Port: 3389, Protokoll: TCP
Und vier Regeln fuer UDP 3389 jeweils INCOMING, OUTGOING fuer Source und Destination Port.
Und dann halt die Regeln setzen fuer DNS (53 UDP), NTP (123 UDP) ausgehend usw.
Ansonsten waere es empfehlenswert, wenn du eine Firewall vor den Windows Server haengst und dich per VPN dann mit der Firewall verbindest / ein Site-to-Site VPN einrichtest.
Aktivier doch die Netcup Firewall, mach erst einmal alles incoming und outgoing dicht und setze eine Freigabe fuer deine WAN IP-Adresse auf den RPD-Port (3389 TCP/UDP).
Ansonsten waere es empfehlenswert, wenn du eine Firewall vor den Windows Server haengst und dich per VPN dann mit der Firewall verbindest / ein Site-to-Site VPN einrichtest.
Siehe oben. Den Port 3389 aufzumachen ist exakt nicht empfehlenswert. Die Firewall gibt es mit der Netcup FW. Controllerbasierte VPNs wie Tailscale, Zerotier, Netbird und andere können auch ohne separaten Firewall RS verwendet werden.
Der Grund des Problems sind mangelnde Grundkenntnisse hinsichtlich Firewalls und Networking (IP Adressen / Ports). Hier sollte sich Franci schlau machen und dann die Firewall korrekt konfigurieren.
Hatte ich auch öfters.
Ich hab mir nen Pico geholt und Wireguard draufgepackt und nur die IP Freigegeben, so wird alles außer dem Wireguard Server direkt blockiert
Also das Konzept verstehe ich nicht. Wenn man so einen Jump Host (beispielsweise "Pico") nicht ohnehin schon hat, dann verlagert man das Problem doch nur von einem Server zum anderen. Der Jump Host muss ja ebenso abgesichert werden (zzgl. Updates, Firewall, Kosten etc.) - was gewinnt man damit?
Wenn es nur um einen einzelnen Server geht, dann bleibt doch als Lösung nur, die Firewall dicht zu machen und über VPN zuzugreifen, wie bereits vorgeschlagen.
Der Pico mit Wireguard ist ja der VPN und meiner Meinung nach ordentlich sicher
Ist schon richtig, man sollte auch den kleinen Linux VPS korrekt konfigurieren.
Der große Vorteil ist halt, dass man diese absolute unsichere und nicht zu verstehende Windows Firewall umgeht. Unter Linux hat man halt eben wesentlich bessere Möglichkeiten
Na ja, auch die Windows Firewall ist im Prinzip sicher, nur halt nicht unbedingt mit den Default Werten und dann kommt noch dazu, dass der Server mit dem nackten Arsch im Internet haengt. Die Bedienungsfreundlichkeit der Windows-Firewall ist ein Thema fuer sich, i. d. R. hilft es, alle aus- und eingehenden Regeln zu loeschen, damit die Default-Werte weg sind und danach ein neues Gruppenrichtlinienobjekt zu erstellen, und dann, wie wir das unter Linux auch kennen, die erforderlichen Ports einzeln aufmachen (das macht man am Besten mit der Konsole, bevor man mit dem Server ueberhaupt online geht). Das geht jedoch erst, wenn man alles anderes bereits konfiguriert hat, weil:
Der Weg dort hin ist etwas steinig, denn man muesste neben DNS auch noch schnell Active-Directory hochziehen, damit die Gruppenrichtlinieverwaltung sich installieren laesst und erst dann, kann man erst (richtig) die Default-Policy und Profilzuordnung setzen. Dann gibt es noch den gemeinen .NET 3.5 Fallstrick (bei pre 2022), die korrekten DNS-Einstellungen der Netzwerkkarte (da sonst kein dcpromo laeuft) und die Installation von hilfreichen, optionalen Komponenten wie Desktop Experience, Telnet und natuerlich die Deinstallation dieses verfluchten Windows Defenders (geht ab 2022 nicht mehr), der jeden Windows Server mit unter 8 GB RAM so unertraeglich langsam macht, dass man... ach egal... FML! Und auf gar keinen Fall einen PPTP-Server (VPN) unter Windows installieren!
Jedenfalls spielt es keine Rolle, ob der RDP-Port nur fuer die eigene IP freigegeben wird oder man ein VPN dazwischen schaltet... es ist weder mehr noch weniger sicher, sondern beides falsch, weil es gegen geltende Normen der IT-Sicherheit verstoesst (BSI, CISA etc.). Die richtigen Vokabeln sind oben schon gefallen: Firewall davor, Jumphost dazwischen, (der JH hat uebrigens kein Internet und ist nur vom Adminnetz aus erreichbar), dann Netztrennung vornehmen, Inter-Zone Verkehr in der Firewall regulieren und dann kommen wir der Sache schon etwas naeher. Ueberfordert aber jeden, der keine sachkundige Person im Bereich IT-Sicherheit ist.
Fuer den Hobby/Privatgebrauch ist das alles irrelevant, aber VPN ist kein Allheilmittel und kann man deswegen getrost weglassen. Meiner Erfahrung nach, sind die meisten VPN-Server nicht unbedingt sicher vom Verantwortlichen konfiguriert (nur PSK, ohne MFA, ohne Zertifikate, ohne IP-Beschraenkungen, ohne Firewall) und jeder, der das beherrscht, braucht glaube ich keine Hilfe mehr, bei der Absicherung eines MS Windows Servers.
Wer es ganz einfach haben moechte, kann Zero-Trust von Cloudflare (oder sonstiger Anbieter) nutzen, aber ich will nicht schon wieder meine Kollegen, von der Datenschutzfraktion auf die Palme bringen. Dennoch, es ist keine Schande, wenn man das als Privatperson nutzt, um sich das Leben einfacher zu machen. Immer noch besser, als einen eigenen VPN-Server -- als Laie -- betreiben zu muessen.
Fazit: Im Privatbereich -- und das duerfte auf die Meisten hier zutreffen. Ihr macht es euch erheblich einfacher, wenn ihr mit IP-Restriktionen fuer SSH und RDP (auf die eigene WAN IP) in der Netcup Firewall arbeitet.
PS: don't kill the messenger
