Ich habe das per externer Firewall gelöst. RDP darf nur von bestimmer IP zu bestimmter IP erfolgen,
Für alle anderen IPs sind die RDP Ports per drop Firewallregel gesperrt und unsichtbar. Mit 2 festen IPs geht das hervorragend und statisch einzurichten.
Hat man keine feste IP auf Clientseite, und steht der Server im Rechenzentrum, so kann man sich dennoch helfen:
Zum Beispiel bei der extern vorgelagerten, aber per Web konfigurierbaren, Hetzner Firewall kann man ja vor dem geplanten RDP Zugriff den RDP Port explizit temporär für die aktuelle Client IP freigeben, und nach dem Wartungsende wieder für alle IPs sperren. Es erfordert nur etwas mehr Disziplin. Aber so kommen Angriffe nichtmal bis zum Server durch.
Ne deutliche Nummer schwächer ginge das auch mit der Server Betriebssystem Firewall zu lösen sofern der Client eine feste IP hat. Man muss sich aber klar sein das da der eigene Server bereits unter Beschuss steht.
Das bedeutet aber nicht das ein Überwachungstool überflüssig wäre, ich würde nur damit primär andere Dienste auf Angriffe überwachen.
Die absolute Nummer 1 wäre ein SIP fähiger Voiceserver wie Freeswitch. Der zieht Hacker an wir Honig die Schmeissfliegen.
Die Überwachung der SIP Ports 5066/5060 wäre daher mein Primäres Ziel.
Interessant wäre auch den Port des externen Gridservices (typisch 8002 oder 9000) sowie der Siminstanzen im Auge zu behalten, da Angriffe darauf oft unerkannt bleiben.
Und natürlich gehört absolut alles hinter die Firewall was nicht extern erreichbar sein muss. Insbesondere die SQL Ports und internen Gridports, wenn man nur einen Server betreibt.
Da rege ich die Erstellung einer "Soll" Verbindungsmatrix als Planungsgrundlage an.
- wer (Jeder / Berechtigte / Admin / interne Dienste) darf auf welche IP/Dienst/Port zugreifen (Externe IP, InterneIP, Loopback IP 127.0.01, Port, Netzwerkdienst).
Danach kann man sich Konfigregeln der Firewall systemaltisch erstellen die genau diese Regeleinhaltung erzwingen.
Doch nutzt eine Überwachung nur wenn es eine zeitnahe Benachrichtigung gibt. Diese gilt es zu testen!
Was sich bei mir auch als gute Hilfe erwiesen hat, ist eine Traffik Benachrichtigung einzurichten, wenn plötzlich ungewöhnliche Datenmengen über Netzwerk flutschen.
Wir lernen nie aus..... das Wichtigste ist das aus Blinden Sehende werden, denn nur die können reagieren.
Und Abwehr ist immer ein Verbund mehrere Mittel.
Gruß Tron
Für alle anderen IPs sind die RDP Ports per drop Firewallregel gesperrt und unsichtbar. Mit 2 festen IPs geht das hervorragend und statisch einzurichten.
Hat man keine feste IP auf Clientseite, und steht der Server im Rechenzentrum, so kann man sich dennoch helfen:
Zum Beispiel bei der extern vorgelagerten, aber per Web konfigurierbaren, Hetzner Firewall kann man ja vor dem geplanten RDP Zugriff den RDP Port explizit temporär für die aktuelle Client IP freigeben, und nach dem Wartungsende wieder für alle IPs sperren. Es erfordert nur etwas mehr Disziplin. Aber so kommen Angriffe nichtmal bis zum Server durch.
Ne deutliche Nummer schwächer ginge das auch mit der Server Betriebssystem Firewall zu lösen sofern der Client eine feste IP hat. Man muss sich aber klar sein das da der eigene Server bereits unter Beschuss steht.
Das bedeutet aber nicht das ein Überwachungstool überflüssig wäre, ich würde nur damit primär andere Dienste auf Angriffe überwachen.
Die absolute Nummer 1 wäre ein SIP fähiger Voiceserver wie Freeswitch. Der zieht Hacker an wir Honig die Schmeissfliegen.
Die Überwachung der SIP Ports 5066/5060 wäre daher mein Primäres Ziel.
Interessant wäre auch den Port des externen Gridservices (typisch 8002 oder 9000) sowie der Siminstanzen im Auge zu behalten, da Angriffe darauf oft unerkannt bleiben.
Und natürlich gehört absolut alles hinter die Firewall was nicht extern erreichbar sein muss. Insbesondere die SQL Ports und internen Gridports, wenn man nur einen Server betreibt.
Da rege ich die Erstellung einer "Soll" Verbindungsmatrix als Planungsgrundlage an.
- wer (Jeder / Berechtigte / Admin / interne Dienste) darf auf welche IP/Dienst/Port zugreifen (Externe IP, InterneIP, Loopback IP 127.0.01, Port, Netzwerkdienst).
Danach kann man sich Konfigregeln der Firewall systemaltisch erstellen die genau diese Regeleinhaltung erzwingen.
Doch nutzt eine Überwachung nur wenn es eine zeitnahe Benachrichtigung gibt. Diese gilt es zu testen!
Was sich bei mir auch als gute Hilfe erwiesen hat, ist eine Traffik Benachrichtigung einzurichten, wenn plötzlich ungewöhnliche Datenmengen über Netzwerk flutschen.
Wir lernen nie aus..... das Wichtigste ist das aus Blinden Sehende werden, denn nur die können reagieren.
Und Abwehr ist immer ein Verbund mehrere Mittel.
Gruß Tron