22
Sicherheitstechnisch sinnvoll: Deaktivierung von RDP und Verwaltung von Backups über die Veeam Console
Hallo zusammen,
ich beschäftige mich derzeit mit der Sicherheit meines Systems und bin auf eine Frage gestoßen, über die ich gerne eure Meinungen und Erfahrungen hören würde.
Ist es aus Sicherheitsgründen sinnvoll, das Remote Desktop Protocol (RDP) zu deaktivieren und stattdessen Backups über die Veeam Backup & Replication Console zu verwalten? Ich frage mich, ob diese Maßnahmen tatsächlich die Sicherheit meines Systems verbessern könnten. Gibt es potenzielle Risiken oder Vorteile, die ich möglicherweise übersehe?
Ich bin mir bewusst, dass Sicherheit ein komplexes Thema ist und nicht nur von diesen Maßnahmen abhängt. Dennoch interessiert mich eure Einschätzung zu diesem spezifischen Aspekt der Systemabsicherung.
Vielen Dank im Voraus für eure Beiträge und Ratschläge!
ich beschäftige mich derzeit mit der Sicherheit meines Systems und bin auf eine Frage gestoßen, über die ich gerne eure Meinungen und Erfahrungen hören würde.
Ist es aus Sicherheitsgründen sinnvoll, das Remote Desktop Protocol (RDP) zu deaktivieren und stattdessen Backups über die Veeam Backup & Replication Console zu verwalten? Ich frage mich, ob diese Maßnahmen tatsächlich die Sicherheit meines Systems verbessern könnten. Gibt es potenzielle Risiken oder Vorteile, die ich möglicherweise übersehe?
Ich bin mir bewusst, dass Sicherheit ein komplexes Thema ist und nicht nur von diesen Maßnahmen abhängt. Dennoch interessiert mich eure Einschätzung zu diesem spezifischen Aspekt der Systemabsicherung.
Vielen Dank im Voraus für eure Beiträge und Ratschläge!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5136743220
Url: https://administrator.de/forum/sicherheitstechnisch-sinnvoll-deaktivierung-von-rdp-und-verwaltung-von-backups-ueber-die-veeam-console-5136743220.html
Ausgedruckt am: 22.12.2024 um 17:12 Uhr
22 Kommentare
Neuester Kommentar
Es schadet sicherlich nicht.
Ob Du Fisch gegen Fleisch tauschst ist die Frage.
Ob Du Fisch gegen Fleisch tauschst ist die Frage.
1
Hallo, wegen Verschlüsselung ggf. über einen Medienbruch nachdenken. Oder Server der zumindest nicht via SMB erreichbar ist. So die Richtung.
Je nachdem gibt es da ja so einiges. Die Verschlüsselungstrojaner machen es sich ja relativ einfach. Da reicht mitunter schon ein geeignert sek. Backup-Ort.
Je nachdem gibt es da ja so einiges. Die Verschlüsselungstrojaner machen es sich ja relativ einfach. Da reicht mitunter schon ein geeignert sek. Backup-Ort.
Theoretisch könnte Veeam natürlich auch Sicherheitslücken haben. Allerdings zielen Angreifer natürlich immer (automatisiert oder nicht) auf sehr verbreitete und möglicherweise schlecht gepatchte Protokolle. "Exotische" Sicherheitslücken haben die dann eher nicht grade zur Hand oder in ihrem Exploit eingebaut. Daher würde ich sagen Fisch != Fleisch, daher schon sicherer.
Dein Host ist ja vermutlich auch erstmal nicht direkt aus dem Internet ansprechbar, korrekt?
Dein Host ist ja vermutlich auch erstmal nicht direkt aus dem Internet ansprechbar, korrekt?
Zitat von @ukulele-7:
Theoretisch könnte Veeam natürlich auch Sicherheitslücken haben. Allerdings zielen Angreifer natürlich immer (automatisiert oder nicht) auf sehr verbreitete und möglicherweise schlecht gepatchte Protokolle. "Exotische" Sicherheitslücken .....
Theoretisch könnte Veeam natürlich auch Sicherheitslücken haben. Allerdings zielen Angreifer natürlich immer (automatisiert oder nicht) auf sehr verbreitete und möglicherweise schlecht gepatchte Protokolle. "Exotische" Sicherheitslücken .....
Es sei denn es ist eh schon viel passiert. Softwarelieferant mit alter VPN Hardware. Dann uralter, aktiver Admin Account mit geklauten Passwort. Dann geht es auch auf RDP zu.....
Räusper: sage es nur ungern. Vor ein paar Wochen erlebt. RDP zum rumschnüffeln und via Remoteservice versucht Trojaner zu verteilen. Gut RDP ist da wo eh egal. Remote Code mit Admin Kennwort ausführen ist schon worst-case. Da ist RDP nur ein Schmankerl: GUI für die Angreifer. Man tut sich ggf. leicht beim Umsehen.
Ja das kann auf alle Fälle sinnvoll sein. Die Verwaltung per Konsole sollte von einem anderem System erfolgen, mit aktivierten MFA, Vier Augen Prinzip und separater Authentifizierung; d.h. der Server ist nicht Mitglied der produktiven Domain. Auf dem Server selbst sollte kein Administrator aktiv arbeiten und genauso keine Anmeldung per RDP möglich sein.
Mehr Details und weitere Möglichkeiten finden sich unter anderem im Best Practice Guide: https://bp.veeam.com/security#forenote
Mehr Details und weitere Möglichkeiten finden sich unter anderem im Best Practice Guide: https://bp.veeam.com/security#forenote
Nur Veeam Konsole wäre auch bei uns der Plan... irgendwann mal.
Windows Updates sind dann noch ein Punkt der noch nicht ganz ausdiskutiert wurde.
Windows Updates sind dann noch ein Punkt der noch nicht ganz ausdiskutiert wurde.
Moin,
In der jüngsten Veeam B&R-Version ist ein Best Practice Analyzer enthalten. Den kann man abarbeiten
Zu Rest (RDP deaktiviert, keine AdminUser, separates VLAN, …) wurde ja oben schon gesagt.
In der jüngsten Veeam B&R-Version ist ein Best Practice Analyzer enthalten. Den kann man abarbeiten
Windows Updates sind dann noch ein Punkt der noch nicht ganz ausdiskutiert wurde.
1x Im Monat WSUSOffline. Die ISO wird dann via xClarity/ iDRAC/ IPMi/ … gemounted und die Updates installiert.Zu Rest (RDP deaktiviert, keine AdminUser, separates VLAN, …) wurde ja oben schon gesagt.
Zitat von @em-pie:
Moin,
In der jüngsten Veeam B&R-Version ist ein Best Practice Analyzer enthalten. Den kann man abarbeiten
Den gibt es bereits seit v12 und nicht erst seit v12.1. Jetzt gibt es aber noch mehr "Punkte" und es ist sinnvoll sich diesen anzuschauen.Moin,
In der jüngsten Veeam B&R-Version ist ein Best Practice Analyzer enthalten. Den kann man abarbeiten
Einfach Veeam Best Practise befolgen hilft schon viel.
3-2-1 Backup Regel.
Dann Immutable Backup Repositorys mit Linux. Bestenfalls auf "richtigen" Hardware Servern....und nicht auf einem NAS, denn da würde das ganze nur virtuell Immutable sein und so bald man Zugriff auf das NAS hat ist e auch vorberei.
Offload Backup auf Tape oder S3 Storage ....z.B. Wasabi oder in eine CoLocation
Gruß
Ich verwalte Veeam nur noch direkt vor Ort über eine lokale Konsole. Unser Veeam-Server ist in einem abgeschotteten VLAN und darf nur noch über die benötigten Ports mit dem vCenter kommunizieren. Die VMs werden über FC abgezogen.
Bisher wurde dieses Konzept von allen Auditoren gelobt.
Bisher wurde dieses Konzept von allen Auditoren gelobt.
1
Bei uns ist / soll es final auch so sein, dass RDP auf den Veeam Server abgestellt ist.
Bzw. generell RDP auf Server eher nur von einer dedizierten Admin Station aus.
ILO auf Server auch aus oder lokal abgesteckt (wenn es eh nebenan ist)
Ich denke, RDP ist ein größeres Angriffsziel als die Veeam Konsole / der benötigte Port.
wie oben schon geschrieben wurde, ist es best-practice von Veeam selbst
Dazu eben VLAN-Abschottung.
Firewall grundsätzlich DENY.
natürlich Veeam Server nicht in der Domäne
Sichere, dedizierte Passwörter
Die Basics im Zwiebelschalen-Prinzip
Bzw. generell RDP auf Server eher nur von einer dedizierten Admin Station aus.
ILO auf Server auch aus oder lokal abgesteckt (wenn es eh nebenan ist)
Ich denke, RDP ist ein größeres Angriffsziel als die Veeam Konsole / der benötigte Port.
wie oben schon geschrieben wurde, ist es best-practice von Veeam selbst
Dazu eben VLAN-Abschottung.
Firewall grundsätzlich DENY.
natürlich Veeam Server nicht in der Domäne
Sichere, dedizierte Passwörter
Die Basics im Zwiebelschalen-Prinzip
Zitat von @139689:
Ich denke, RDP ist ein größeres Angriffsziel als die Veeam Konsole / der benötigte Port.
Ich denke, RDP ist ein größeres Angriffsziel als die Veeam Konsole / der benötigte Port.
Kannst du das begründen?
Über welchen einen Port reden wir? (
Der Grund meiner Aussage ist, dass RDP (Port 3389) einfach weit verbreitet genutzt wird. Natürlich wird Veeam auch oft eingesetzt, aber prozentuell sicher weniger und ich vermute, dass Angriffe auf Konsole und Backup Server Service (via Ports 9392, 9420) weniger lukrativ und ggf. auch weniger anfällig sind. Lezteres ist aber Vermutung
Ich gehe einfach nach der Verbreitung - Windows ist zb. auch ein lohnenderes Ziel als GNU/Linux ob der NutzerMassen.
Ich gehe einfach nach der Verbreitung - Windows ist zb. auch ein lohnenderes Ziel als GNU/Linux ob der NutzerMassen.
Okay.
Dann vermute ich, dass ein Wechsel des Ports, auf den statistisch unwahrscheinlichsten Port, die maximale Sicherheit bringen wird.
So die Vermutung.
Dann vermute ich, dass ein Wechsel des Ports, auf den statistisch unwahrscheinlichsten Port, die maximale Sicherheit bringen wird.
So die Vermutung.
Richtig.
Was aber nicht meine Aussage entkräftet, dass RDP per se (Port lässt sich auch raus finden) aktiv eher angegriffen / gesucht wird als Veeam Backup / Konsole
Als Angreifer schaue ich nach lohnenden Zielen. Erst mal die Standardports, dann schau ich, ob der Port geändert wurde. Und da nehme ich was lohnendes und nicht was, was vielleicht eher weniger genutzt wird
Was aber nicht meine Aussage entkräftet, dass RDP per se (Port lässt sich auch raus finden) aktiv eher angegriffen / gesucht wird als Veeam Backup / Konsole
Als Angreifer schaue ich nach lohnenden Zielen. Erst mal die Standardports, dann schau ich, ob der Port geändert wurde. Und da nehme ich was lohnendes und nicht was, was vielleicht eher weniger genutzt wird
Es ist dem Angreifer egal welchen Port die Software nutzt. Es ist auch technisch egal.
Wenn keine verwundbare Software einen Port abhört, kann sie alle Ports anhören und sich von überall und jedem ansprechen lassen.
Wenn keine verwundbare Software einen Port abhört, kann sie alle Ports anhören und sich von überall und jedem ansprechen lassen.
In meiner Aussage ging es mir mehr um die Absichten und Ziele, weniger um die Technik. Aber egal. Vermutlich schreibe ich missverständlich.
Den meisten geht es ums Geld.
Die Frage ist, wie oft ist ein Eingriff nötig? Normal kommen nicht tgl. neue Maschinen hinzu. Für das daily Datei Backup und Wiederherstellung gibt es ja noch die Schattenkopien. Das reicht meist, wenn XYZ versehentlich ein File gelöscht hat. Veeam oder Acronis sind da außen vor. Selbst duplicati ist da etwas langsamer.
Wen wir also nur über VMs und normale Backups von Freigaben reden, muss man nicht tgl. an Veeam heran. Berichte gibs per Mail oder selber was bauen:
So z.B. startet Zip nach Failure erneut den Task. Für die normale Version gibst die entsprechenden Parameter.
RDP gibt es unter Windows überall. Auch von einen anderen Server kommt man teils einfach an Backup Repositories u.ä. heran. Um RDP sicherer zu machen gibt es noch andere Methoden. Ist der Server in anderne VLAN kann man auch in der Firewall Regeln setzen. Zugriff auf Uhrzeiten und Workstations beschränken. Einige nutzen für die Verwaltung von Servern eine eigene VM.
Gibt hier zig Ansätze. Wenn jemand via RDP auf Veeam geht - wovor graut es dir hieram meisten? Dass Backup gelöscht oder verschlüsselt werden?
Allein wegen Brandschutz sollte ggf. ein Repo an anderer Stelle liegen. Air-gap um es Trojanern zu erschweren:
https://github.com/GustavBrock/Veeam.Linux
Sich über RDP Gedanken zu machen ist ok. Und teils ein Muss. Durch Strategien wie immutable backup schützt man nochmal das oder die Repositories. Der Aufwand erhöt sich etwas - auch bei der kompletten Wiederherstellung. Dafür hast du noch was wiederherzustellen.
RDP nur auf einen Backup Server einzuschränken ist nicht alles. Wenn dann ein komplettes RDP Konzept für alle Windows basierten Maschinen. Bei VLANs am einfachsten schon über Einschränkung des Zuganges via Firewall mit zu erreichen. Zumindest bis zu einen gewissen Punkt.
Isoliert RDP zu betrachten verschließt ggf. die Augen und die Sichtweise auf andere Schwachstellen.
Verschlüsselungstronjaner arbeiten recht simpel. Genau so simpel sind "erste Ansätze" dagegen vorzugehen. Ansätze wohl gemerkt. Den Rest darf man nicht außer acht lassen.
mfg Crusher
Wen wir also nur über VMs und normale Backups von Freigaben reden, muss man nicht tgl. an Veeam heran. Berichte gibs per Mail oder selber was bauen:
$result = Get-VBRBackupSession
$result | ? { $_.Result -eq 'Failed' -and $_.EndTime -gt $fromdate -and $_.JobSpec.Length -gt 0 } | Select JobName, JobSpec, Stage, StartTime, EndTime, Result | `
% { $xml = $_.JobSpec
Select-Xml -Content $Xml -XPath "//VmName" | foreach {
$VM = $_.Node.InnerXml
StartVBRZip $VM
}
}So z.B. startet Zip nach Failure erneut den Task. Für die normale Version gibst die entsprechenden Parameter.
RDP gibt es unter Windows überall. Auch von einen anderen Server kommt man teils einfach an Backup Repositories u.ä. heran. Um RDP sicherer zu machen gibt es noch andere Methoden. Ist der Server in anderne VLAN kann man auch in der Firewall Regeln setzen. Zugriff auf Uhrzeiten und Workstations beschränken. Einige nutzen für die Verwaltung von Servern eine eigene VM.
Gibt hier zig Ansätze. Wenn jemand via RDP auf Veeam geht - wovor graut es dir hieram meisten? Dass Backup gelöscht oder verschlüsselt werden?
Allein wegen Brandschutz sollte ggf. ein Repo an anderer Stelle liegen. Air-gap um es Trojanern zu erschweren:
https://github.com/GustavBrock/Veeam.Linux
Sich über RDP Gedanken zu machen ist ok. Und teils ein Muss. Durch Strategien wie immutable backup schützt man nochmal das oder die Repositories. Der Aufwand erhöt sich etwas - auch bei der kompletten Wiederherstellung. Dafür hast du noch was wiederherzustellen.
RDP nur auf einen Backup Server einzuschränken ist nicht alles. Wenn dann ein komplettes RDP Konzept für alle Windows basierten Maschinen. Bei VLANs am einfachsten schon über Einschränkung des Zuganges via Firewall mit zu erreichen. Zumindest bis zu einen gewissen Punkt.
Isoliert RDP zu betrachten verschließt ggf. die Augen und die Sichtweise auf andere Schwachstellen.
Verschlüsselungstronjaner arbeiten recht simpel. Genau so simpel sind "erste Ansätze" dagegen vorzugehen. Ansätze wohl gemerkt. Den Rest darf man nicht außer acht lassen.
mfg Crusher
Ich hatte aus alten Zeiten für Privat-User im Kopf: RDP per nativer win-firewall nur lokal, aber nicht von außen zulassen, wenn das möglich ist.
Gilt das noch?
Gilt das noch?
Kommt drauf an.
Grundsätzlich jede Software die nicht über einen Port erreichbar ist, eine gute Software.
Es gibt aber immer Gründe etwas zu machen.
Modernes RDP ist seit langen nicht negativ aufgefallen. Natürlich muss ALLEs entsprechend konfiguriert sein.
3389 in der Firewall offen ist gar nicht so selten.
Grundsätzlich jede Software die nicht über einen Port erreichbar ist, eine gute Software.
Es gibt aber immer Gründe etwas zu machen.
Modernes RDP ist seit langen nicht negativ aufgefallen. Natürlich muss ALLEs entsprechend konfiguriert sein.
3389 in der Firewall offen ist gar nicht so selten.
Zitat von @-webu-:
Ich hatte aus alten Zeiten für Privat-User im Kopf: RDP per nativer win-firewall nur lokal, aber nicht von außen zulassen, wenn das möglich ist.
Gilt das noch?
Persönlich würde ich sagen ja, das gilt noch. Allerdings weiß ich zumindest von einer größeren lokalen IT-Bude bei uns die das auch im Internet betreiben. Ich hatte mich mal mit denen ausgetauscht (zu anderen Dingen) und die hatten (glaube ich) nur RD-Web Access dazwischen. Habe mich dann aber nicht weiter damit befasst.Ich hatte aus alten Zeiten für Privat-User im Kopf: RDP per nativer win-firewall nur lokal, aber nicht von außen zulassen, wenn das möglich ist.
Gilt das noch?
Es gibt halt kein Tool wie RDP, dass so richtig gut ist wie RDP. Isso.
Im Idealfall läuft es direkt zwischen Host und Client, ohne Umweg Fremdserver (Anydesk, Team-Viewer etc.)
Wir haben noch Mesh im Einsatz, auf eigenem Server installiert, aber da geht auch nicht alles richtig gut.
Im Idealfall läuft es direkt zwischen Host und Client, ohne Umweg Fremdserver (Anydesk, Team-Viewer etc.)
Wir haben noch Mesh im Einsatz, auf eigenem Server installiert, aber da geht auch nicht alles richtig gut.
