29
Veeam Backup-Server aus der Domäne nehmen
Guten Morgen,
da in unserer Backupumgebung ein Hardwaretausch ansteht, konzipiere ich gerade Möglichkeiten die Sicherheit zu erhöhen.
Konkret geht es um den Veeam-Server, der zurzeit auch u.a. Repository- und Tape-Server ist. In der aktuellen Konfiguration ist der Server Mitglied der Domäne, ich erwäge aus Sicherheitsgründen den neuen Server nicht in die Domäne aufzunehmen.
Wer hat Erfahrungen damit, gibt es in der Konfiguration oder Administration Stolperstein, die möglicherweise erst im Laufe der Zeit auffallen?
Nachteilig ist sicherlich der geringere Komfort durch lokale Konten, fehlende GPOs und aufwendigere Administration, dem gegenüber steht die Unabhängigkeit von der Domäne und die geringere Angriffsfläche.
Neben der Überlegung wird der Server zukünftig auch netzwerkseitig soweit wie möglich abgesichert.
Über eure Erfahrungen würde ich mich freuen!
da in unserer Backupumgebung ein Hardwaretausch ansteht, konzipiere ich gerade Möglichkeiten die Sicherheit zu erhöhen.
Konkret geht es um den Veeam-Server, der zurzeit auch u.a. Repository- und Tape-Server ist. In der aktuellen Konfiguration ist der Server Mitglied der Domäne, ich erwäge aus Sicherheitsgründen den neuen Server nicht in die Domäne aufzunehmen.
Wer hat Erfahrungen damit, gibt es in der Konfiguration oder Administration Stolperstein, die möglicherweise erst im Laufe der Zeit auffallen?
Nachteilig ist sicherlich der geringere Komfort durch lokale Konten, fehlende GPOs und aufwendigere Administration, dem gegenüber steht die Unabhängigkeit von der Domäne und die geringere Angriffsfläche.
Neben der Überlegung wird der Server zukünftig auch netzwerkseitig soweit wie möglich abgesichert.
Über eure Erfahrungen würde ich mich freuen!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 626698
Url: https://administrator.de/contentid/626698
Printed on: April 19, 2024 at 20:04 o'clock
29 Comments
Latest comment
Rechtemanagement vorausgesetzt ist ein Backupserver in der Domaine per se nicht unsicherer.
Fleißig muss man sein.
Fleißig muss man sein.
Zitat von @142583:
Rechtemanagement vorausgesetzt ist ein Backupserver in der Domaine per se nicht unsicherer.
Rechtemanagement vorausgesetzt ist ein Backupserver in der Domaine per se nicht unsicherer.
Rechtemanagement (least privilege) ist vorhanden und wird gelebt, das potenzielle Risiko ist letztendlich auf die Konten der Domänen-Administratoren herunterzubrechen. Komplexe Kennwörter, Überwachung von Fehlanmeldungen sind vorhanden, zudem werden diese Konten so gut wie nie benutzt.
Dennoch wäre es schön, wenn seitens Veeam eine 2FA möglich wäre, leider wurde das bis heute nicht realisiert, es müsste also wenn dann in der Domäne umgesetzt werden.
Zitat von @JoeDevlin:
Rechtemanagement (least privilege) ist vorhanden und wird gelebt, das potenzielle Risiko ist letztendlich auf die Konten der Domänen-Administratoren herunterzubrechen. Komplexe Kennwörter, Überwachung von Fehlanmeldungen sind vorhanden, zudem werden diese Konten so gut wie nie benutzt.
Dennoch wäre es schön, wenn seitens Veeam eine 2FA möglich wäre, leider wurde das bis heute nicht realisiert, es müsste also wenn dann in der Domäne umgesetzt werden.
Zitat von @142583:
Rechtemanagement vorausgesetzt ist ein Backupserver in der Domaine per se nicht unsicherer.
Rechtemanagement vorausgesetzt ist ein Backupserver in der Domaine per se nicht unsicherer.
Rechtemanagement (least privilege) ist vorhanden und wird gelebt, das potenzielle Risiko ist letztendlich auf die Konten der Domänen-Administratoren herunterzubrechen. Komplexe Kennwörter, Überwachung von Fehlanmeldungen sind vorhanden, zudem werden diese Konten so gut wie nie benutzt.
Dennoch wäre es schön, wenn seitens Veeam eine 2FA möglich wäre, leider wurde das bis heute nicht realisiert, es müsste also wenn dann in der Domäne umgesetzt werden.
Du kannst auch Domainadmins oder deren Gruppen einschränken.
Wir haben mindestens 99,9% unserer Daten im SAN und Backup auf Blockebene über einen "Bypass" direkt am SAN.
Auf Filesystem und Share-Ebene ist nichts mehr zu holen.
Zitat von @142583:
Schon klar, nur könnte dieser die Einschränkung selbst wieder aufheben.
Wir haben mindestens 99,9% unserer Daten im SAN und Backup auf Blockebene über einen "Bypass" direkt am SAN.
Auf Filesystem und Share-Ebene ist nichts mehr zu holen.
Auf Filesystem und Share-Ebene ist nichts mehr zu holen.
Das ist bei uns aktuell nicht umsetzbar.
Hallo,
ich verwende bei Kunden immer einen unabhängigen PC/Server für die Datensicherung.
Auch das NAS ist nicht in der Domäne.
Kommt natürlich auf die Größe des Kunden/Netzwerkes an.
Die Zugangsdaten für Backup-Server und NAS sind nirgendwo in der Domäne gespeichert.
Sicherheitsvorteile:
- Ein Hacker der das AD übernommen hat fängt damit wieder bei 0 an
- Das Kennwort für die Freigabe auf dem NAS ist nur in der Backup-Software gespeichert
- Bei QNAP ist der Zugriff auf den Netzwerkpapierkorb auf den Admin beschränkt
- Das NAS-Admin-Kennwort ist "nirgendwo" gespeichert
Stefan
ich verwende bei Kunden immer einen unabhängigen PC/Server für die Datensicherung.
Auch das NAS ist nicht in der Domäne.
Kommt natürlich auf die Größe des Kunden/Netzwerkes an.
Die Zugangsdaten für Backup-Server und NAS sind nirgendwo in der Domäne gespeichert.
Sicherheitsvorteile:
- Ein Hacker der das AD übernommen hat fängt damit wieder bei 0 an
- Das Kennwort für die Freigabe auf dem NAS ist nur in der Backup-Software gespeichert
- Bei QNAP ist der Zugriff auf den Netzwerkpapierkorb auf den Admin beschränkt
- Das NAS-Admin-Kennwort ist "nirgendwo" gespeichert
Stefan
Konkret geht es um den Veeam-Server, der zurzeit auch u.a. Repository- und Tape-Server ist. In der aktuellen Konfiguration ist der Server Mitglied der Domäne, ich erwäge aus Sicherheitsgründen den neuen Server nicht in die Domäne aufzunehmen.
wenn es nach dem Best Practice von Veeam geht, ist dies eine sehr gute Entscheidung! Alternativ bleibt das Hardenind der Domäne 
Wer hat Erfahrungen damit, gibt es in der Konfiguration oder Administration Stolperstein, die möglicherweise erst im Laufe der Zeit auffallen?
Durchweg positive. Bisher konnte ich keine Einschränkung feststellen.Nachteilig ist sicherlich der geringere Komfort durch lokale Konten, fehlende GPOs und aufwendigere Administration, dem gegenüber steht die Unabhängigkeit von der Domäne und die geringere Angriffsfläche.
Was willst du denn bei Veeam per GPO konfigurieren?Ich habe hier eine VMware Umgebung mit 7 Hosts.
Veeam ist komplett außerhalb der Domäne.
- Veeam Mgmt Server
- 2 x Physischer SAN für Direct SAN Access
- 1 x Tape Server mit Tape Library
Die Kommunikation per Veeam Console erfolgt von einer VM nur auf den Veeam MgmT Server. Die andere Veeam Server werden nur bei Bedarf angefasst. Somit spielt es keine Rolle bzgl. des "Mehraufwandes bzgl. Lokaler Konten"
Das komplette Backup Netz (Veeam+NAS) befinden sich in einem eigenen VLAN, in dem natürlich nur die benötigten Ports per ACL freigegeben sind. U.A. ist RDP auf die Veeam Server nur vom Admin Netz aus zulässig.
Guest Processing für Files, Exchange etc funktioniert ja weiterhin völlig problemlos, sofern man die korrekten Daten hinterlegt hat.
Veeam führt für das Hardening u. a. auf:
- Veeam außerhalb der Domäne
- Für Veeam eine Extra Management Forest Domain
- 2FA für die Domänen Admins z.B. über Azure.
Hier der Link zum Veeam Hardening
Sicherheitsvorteile:
- Ein Hacker der das AD übernommen hat fängt damit wieder bei 0 an
- Das Kennwort für die Freigabe auf dem NAS ist nur in der Backup-Software gespeichert
- Bei QNAP ist der Zugriff auf den Netzwerkpapierkorb auf den Admin beschränkt
Wozu nochmal ein Netzwerkpapierkorb? Nur aus Interesse - Ein Hacker der das AD übernommen hat fängt damit wieder bei 0 an
- Das Kennwort für die Freigabe auf dem NAS ist nur in der Backup-Software gespeichert
- Bei QNAP ist der Zugriff auf den Netzwerkpapierkorb auf den Admin beschränkt
Gruß
D
Zitat von @StefanKittel:
ich verwende bei Kunden immer einen unabhängigen PC/Server für die Datensicherung.
Auch das NAS ist nicht in der Domäne.
Kommt natürlich auf die Größe des Kunden/Netzwerkes an.
Die Zugangsdaten für Backup-Server und NAS sind nirgendwo in der Domäne gespeichert.
ich verwende bei Kunden immer einen unabhängigen PC/Server für die Datensicherung.
Auch das NAS ist nicht in der Domäne.
Kommt natürlich auf die Größe des Kunden/Netzwerkes an.
Die Zugangsdaten für Backup-Server und NAS sind nirgendwo in der Domäne gespeichert.
Unser Backup Copy-Job sichert auch auf ein NAS das nicht in der Domäne ist und dessen Benutzerkonto ausschließlich in Veeam eingetragen ist, dazu haben wir auch noch einen Tape-Job. Bei allen Backups besteht jedoch die gleiche Gefahr, dass ein Hacker in Veeam alle für Veeam erreichbaren Backups löschen kann (also die lokalen, die auf dem NAS sowie das aktuell eingelegte Tape).
Zitat von @tech-flare:
wenn es nach dem Best Practice von Veeam geht, ist dies eine sehr gute Entscheidung! Alternativ bleibt das Hardenind der Domäne
wenn es nach dem Best Practice von Veeam geht, ist dies eine sehr gute Entscheidung! Alternativ bleibt das Hardenind der Domäne
Ich habe da Best Practice gelesen, eine eigene Management Domain ist uns zu aufwendig, also bleibt uns entweder das Domain Hardening oder die Workgroup Variante.
Nachteilig ist sicherlich der geringere Komfort durch lokale Konten, fehlende GPOs und aufwendigere Administration, dem gegenüber steht die Unabhängigkeit von der Domäne und die geringere Angriffsfläche.
Was willst du denn bei Veeam per GPO konfigurieren?Nicht Veeam selbst sondern Sicherheitsrichtlinien, die per GPO auf die Domäne wirken, müssen dann lokal auf dem Server konfiguriert werden. Darüber hinaus auch weitere Einstellungen wie Updaterichtlinien, Überwachung der Ereignisanzeige, etc.
Die Kommunikation per Veeam Console erfolgt von einer VM nur auf den Veeam MgmT Server. Die andere Veeam Server werden nur bei Bedarf angefasst. Somit spielt es keine Rolle bzgl. des "Mehraufwandes bzgl. Lokaler Konten"
Das komplette Backup Netz (Veeam+NAS) befinden sich in einem eigenen VLAN, in dem natürlich nur die benötigten Ports per ACL freigegeben sind. U.A. ist RDP auf die Veeam Server nur vom Admin Netz aus zulässig.
Das komplette Backup Netz (Veeam+NAS) befinden sich in einem eigenen VLAN, in dem natürlich nur die benötigten Ports per ACL freigegeben sind. U.A. ist RDP auf die Veeam Server nur vom Admin Netz aus zulässig.
Das wollen wir auch genau so umsetzen, schön dass wir da mit unseren Gedanken richtig liegen
Nachteilig ist sicherlich der geringere Komfort durch lokale Konten, fehlende GPOs und aufwendigere Administration, dem gegenüber steht die Unabhängigkeit von der Domäne und die geringere Angriffsfläche.
Was willst du denn bei Veeam per GPO konfigurieren?Nicht Veeam selbst sondern Sicherheitsrichtlinien, die per GPO auf die Domäne wirken, müssen dann lokal auf dem Server konfiguriert
Darüber hinaus auch weitere Einstellungen wie Updaterichtlinien, Überwachung der Ereignisanzeige, etc.
Sowas kann man bequem in ein Powershell Skript schreiben, was überall 1 x ausgeführt wird....Aber selbst wenn man dies bei 3 Server händisch machen muss, ist dies doch schnell umgesetzt.
Hallo,
Du solltest auch darüber nachdenken, welche Authentifizierungsmethoden mit und ohne Domäne eingesetzt werden. Auf Domänenebene hast Du da erstmal über Kerberos recht sichere Techniken. Wenn dann beim Datentransfer in die Workgroup die Anmeldung über Passwort erfolgt, musst Du sicherstellen, dass dieses nicht so einfach abgefangen werden kann. Wenn Du von einer Kompromitierung der Domänadminkonten ausgehst, dann sind hier auch diverse Angriffsszenarien denkbar.
Grüße
lcer
Du solltest auch darüber nachdenken, welche Authentifizierungsmethoden mit und ohne Domäne eingesetzt werden. Auf Domänenebene hast Du da erstmal über Kerberos recht sichere Techniken. Wenn dann beim Datentransfer in die Workgroup die Anmeldung über Passwort erfolgt, musst Du sicherstellen, dass dieses nicht so einfach abgefangen werden kann. Wenn Du von einer Kompromitierung der Domänadminkonten ausgehst, dann sind hier auch diverse Angriffsszenarien denkbar.
Grüße
lcer
Moin,
Wir werden uns auch in den nächsten ein bis zwei Monaten VEEAM anlachen.
Und auch bei uns wird die Kiste mit Nichten in die Domain aufgenommen.
Ich hege da aber einen anderen Hintergrund:
Was nützt mir ein Backupserver in der Domain, wenn ich ein DR-Szenario habe, bei dem ich die DCs ebenfalls Recovern müsste...
Gruß
em-pie
Wir werden uns auch in den nächsten ein bis zwei Monaten VEEAM anlachen.
Und auch bei uns wird die Kiste mit Nichten in die Domain aufgenommen.
Ich hege da aber einen anderen Hintergrund:
Was nützt mir ein Backupserver in der Domain, wenn ich ein DR-Szenario habe, bei dem ich die DCs ebenfalls Recovern müsste...
Gruß
em-pie
Für den Fall das die Backup-Instanz kompromitiert oder sabortiert wurde und Jemand oder etwas den Inhalt vom NAS löscht.
Ich stelle das in der Regel auf 14 Tage ein. In der Zeit muss es Jemand wohl festgestellt haben.
Stefan
Ich stelle das in der Regel auf 14 Tage ein. In der Zeit muss es Jemand wohl festgestellt haben.
Stefan
Zitat von @tech-flare:
Welche denn zum Beispiel? Die Server sind doch dann komplett außerhalb.....was soll dann noch auf die Domäne wirken? Was für Sicherheitseinstellungen ? Die Backup Server sollen und dürfen bestenfalls nirgendwo hin, außer zu den von dir freigegeben Server (physische Server, NAS, VMware, Hyper, SAN, Monitoring) usw.
Welche denn zum Beispiel? Die Server sind doch dann komplett außerhalb.....was soll dann noch auf die Domäne wirken? Was für Sicherheitseinstellungen ? Die Backup Server sollen und dürfen bestenfalls nirgendwo hin, außer zu den von dir freigegeben Server (physische Server, NAS, VMware, Hyper, SAN, Monitoring) usw.
Ich meine z.B. die Überwachung von Fehlanmeldungen, Konfiguration von Konto- und Kennwortrichtlinien, Monitoring der Ereignisanzeigen, Firewalleinstellungen. Klar, diese Dinge lassen sich alle manuell konfigurieren, es ist nur mehr Aufwand allerdings zur Erhöhung der Sicherheit.
Zitat von @em-pie:
Was nützt mir ein Backupserver in der Domain, wenn ich ein DR-Szenario habe, bei dem ich die DCs ebenfalls Recovern müsste...
Was nützt mir ein Backupserver in der Domain, wenn ich ein DR-Szenario habe, bei dem ich die DCs ebenfalls Recovern müsste...
Dieses Argument liest man häufiger, jedoch sehe ich das nicht so problematisch. Es spricht doch nichts dagegen auf dem Veeam-Server einen lokalen Benutzer anzulegen und dessen Konto zu der Restore-Rolle innerhalb von Veeam hinzuzufügen. Damit wäre der Restore der DCs ebenfalls Domänenkonten möglich, oder habe ich da einen Denkfehler?
Hallo,
ne, anders.
Alle DCs sind tot.
Also kannst Du Dich an Deinem Recovery-System nicht anmelden.
Stefan
Zitat von @JoeDevlin:
Dieses Argument liest man häufiger, jedoch sehe ich das nicht so problematisch. Es spricht doch nichts dagegen auf dem Veeam-Server einen lokalen Benutzer anzulegen und dessen Konto zu der Restore-Rolle innerhalb von Veeam hinzuzufügen. Damit wäre der Restore der DCs ebenfalls Domänenkonten möglich, oder habe ich da einen Denkfehler?
Zitat von @em-pie:
Was nützt mir ein Backupserver in der Domain, wenn ich ein DR-Szenario habe, bei dem ich die DCs ebenfalls Recovern müsste...
Was nützt mir ein Backupserver in der Domain, wenn ich ein DR-Szenario habe, bei dem ich die DCs ebenfalls Recovern müsste...
Dieses Argument liest man häufiger, jedoch sehe ich das nicht so problematisch. Es spricht doch nichts dagegen auf dem Veeam-Server einen lokalen Benutzer anzulegen und dessen Konto zu der Restore-Rolle innerhalb von Veeam hinzuzufügen. Damit wäre der Restore der DCs ebenfalls Domänenkonten möglich, oder habe ich da einen Denkfehler?
ne, anders.
Alle DCs sind tot.
Also kannst Du Dich an Deinem Recovery-System nicht anmelden.
Stefan
Zitat von @StefanKittel:
Alle DCs sind tot.
Also kannst Du Dich an Deinem Recovery-System nicht anmelden.
Alle DCs sind tot.
Also kannst Du Dich an Deinem Recovery-System nicht anmelden.
Ich kann mich mit einem lokalen Benutzer am Backup-Server (z.B. Server\Administrator) und in Veeam anmelden und dort dann den DC wiederherstellen.
Zitat von @JoeDevlin:
Ich kann mich mit einem lokalen Benutzer am Backup-Server (z.B. Server\Administrator) und in Veeam anmelden und dort dann den DC wiederherstellen.
Zitat von @StefanKittel:
Alle DCs sind tot.
Also kannst Du Dich an Deinem Recovery-System nicht anmelden.
Alle DCs sind tot.
Also kannst Du Dich an Deinem Recovery-System nicht anmelden.
Ich kann mich mit einem lokalen Benutzer am Backup-Server (z.B. Server\Administrator) und in Veeam anmelden und dort dann den DC wiederherstellen.
Da musst du den Account ja auch pflegen. Da kannst du den Veeam Server auch gleich aus der Domäne rausnehmen
Zitat von @tech-flare:
Da musst du den Account ja auch pflegen. Da kannst du den Veeam Server auch gleich aus der Domäne rausnehmen
Da musst du den Account ja auch pflegen. Da kannst du den Veeam Server auch gleich aus der Domäne rausnehmen
Schon klar, ich wollte nur darauf hinaus, dass die Domänenzugehörigkeit im worst-case nicht dazu führt, dass ich nicht an die Backup der DCs rankomme.
Zitat von @JoeDevlin:
Schon klar, ich wollte nur darauf hinaus, dass die Domänenzugehörigkeit im worst-case nicht dazu führt, dass ich nicht an die Backup der DCs rankomme.
Zitat von @tech-flare:
Da musst du den Account ja auch pflegen. Da kannst du den Veeam Server auch gleich aus der Domäne rausnehmen
Da musst du den Account ja auch pflegen. Da kannst du den Veeam Server auch gleich aus der Domäne rausnehmen
Schon klar, ich wollte nur darauf hinaus, dass die Domänenzugehörigkeit im worst-case nicht dazu führt, dass ich nicht an die Backup der DCs rankomme.
Wenn du aber ohnehin einen zweiten Account hast, dann reduziere doch mögliche Angriffsvektoren, indem die ganze Kiste das AD quasi nicht kennt.
Man weiß ja nicht, was es für Angriffe gibt, aber sollte es mal eine Attacke geben, die Backupserver im Netzsucht und dort zunächst alle Konten deaktiviert, und dann weiteren Schafen anrichtet...
Lieber die Kiste soweit abschotten, wie nur möglich... und ist das System einmal mit installiert/ eingerichtet, hat man auch Ruhe. Ggf. Einmal pro Monat oder Quartal per WSUSoffline die Büchse auf Stand bringen (zzgl. der VEEAM-Updates) und das sollte erst einmal Bestand haben.
Rein aus Interesse...
Irgendwie, wird mein AD hochgenommen... Vielleicht bemerke ich das nicht. Alles möglich.
Jetzt ist mir mein AD verloren gegangen, durch einen High-End Schadcode oder durch einen Fehler in der Layer-8 Implementierung. Warum ist der Non-AD Veeam Server dann nicht vom Verlust bedroht nur weil er nicht in der AD ist?
Irgendwie, wird mein AD hochgenommen... Vielleicht bemerke ich das nicht. Alles möglich.
Jetzt ist mir mein AD verloren gegangen, durch einen High-End Schadcode oder durch einen Fehler in der Layer-8 Implementierung. Warum ist der Non-AD Veeam Server dann nicht vom Verlust bedroht nur weil er nicht in der AD ist?
Warum ist der Non-AD Veeam Server dann nicht vom Verlust bedroht nur weil er nicht in der AD ist?
Wenn dein AD hochgenommen wird, kann man sich problemlos bei einem Veeam Server mit AD Anbindung einloggen alle Backups löschen bzw. Verschlüsselt. Ein DomänenAdmin kommt nun mal
Auf jeden AD Client/Server .
Dies tut der Angreifer bestenfalls bereits Wochen vorher , ohne das es auffällt.
Bei einem Server ohne AD hast du beim Veeam Server hoffentlich andere Passwörter. Somit hat man dort erstmal eine weitere Stufe, welche überwunden werden muss. Nicht umsonst empfiehlt Veeam dies selbst als Alternative zum AD mit MFA
Backups extern mit Medienbruch zu lagern ersetzt dies natürlich nicht.
Ps.: dein AD kann auch mit lokalen Password Hashes hochgenommen werden... dafür brauch es keinen HighendSchadcode
Wenn dein AD hochgenommen wird, kann man sich problemlos bei einem Veeam Server mit AD Anbindung einloggen alle Backups löschen bzw. Verschlüsselt. Ein DomänenAdmin kommt nun mal
Auf jeden AD Client/Server .
Dies tut der Angreifer bestenfalls bereits Wochen vorher , ohne das es auffällt.
Bei einem Server ohne AD hast du beim Veeam Server hoffentlich andere Passwörter. Somit hat man dort erstmal eine weitere Stufe, welche überwunden werden muss. Nicht umsonst empfiehlt Veeam dies selbst als Alternative zum AD mit MFA
Backups extern mit Medienbruch zu lagern ersetzt dies natürlich nicht.
Ps.: dein AD kann auch mit lokalen Password Hashes hochgenommen werden... dafür brauch es keinen HighendSchadcode
Unsere Domainadmins können am Veeam nicht wirklich was machen. Dazu muss man in einer speziellen Gruppe sein. Änderungen an dieser Gruppe werden überwacht.
Und das Bruteforcen des Passworts ist also das große Risiko und passiert vermutlich auch tagtäglich?
Exploits, die Schwachstellen angreifen, nun denen es egal ist, in der Host in AD ist oder nicht, das ist nicht zufällig eine reele Gefahr?
Und das Bruteforcen des Passworts ist also das große Risiko und passiert vermutlich auch tagtäglich?
Exploits, die Schwachstellen angreifen, nun denen es egal ist, in der Host in AD ist oder nicht, das ist nicht zufällig eine reele Gefahr?
Zitat von @142583:
Unsere Domainadmins können am Veeam nicht wirklich was machen. Dazu muss man in einer speziellen Gruppe sein. Änderungen an dieser Gruppe werden überwacht.
Unsere Domainadmins können am Veeam nicht wirklich was machen. Dazu muss man in einer speziellen Gruppe sein. Änderungen an dieser Gruppe werden überwacht.
Nicht auf den Server zugreifen oder nichts machen? Ein Domain Admin ist ein Domain Admin ist ein Domain Admin
zb... Login Veeam Server, Login SQL Server von Veeam (in die Gruppe kommt man ganz einfach rein... siehe Migration Anleitung von Veeam)Bzgl Domain Clients:
Golden Ticket sagt dir etwas?
Ich gehe mal davon aus, dass sich Veeam selbst im Klaren ist, warum sie empfehlen den Veeam Server
- in eine Workgroups zu packen
Oder
- in eine Management Forest Domain mit 2FA zu packen
Und das Bruteforcen des Passworts ist also das große Risiko und passiert vermutlich auch tagtäglich?
Ich rede nicht vom Brute Force. Ich rede vom Password Hash. Stellenweise reicht der einfache Hash und der Login ist möglich... das ist nicht nur auf Veeam bezogen.Exploits, die Schwachstellen angreifen, nun denen es egal ist, in der Host in AD ist oder nicht, das ist nicht zufällig eine reele Gefahr?
Wo kommt denn der Angreifer zuerst hin? Nah ans AD oder nah an den Backup Server? Wenn letzteres, dann hat man etwas verkehrt gemacht.
Hat Veeam dahin gehend eine Schwachstelle und lässt sich sich mit einem Hash eines Passworts wie knacken?
Und warum sind diese Angriffe besonders gefährlich, wenn man in einer Domaine ist aber nicht als Workgroup-System?
Ich habs nicht verstanden.
Vielleicht sollte man eher seine Zeit für ein Sicherheitsaudit investieren, wenn man Angst vor Software hat, die sich so angreifen lässt und möglicherweise so schlecht auch wirklich designd und programmiert ist.
Und die Passwörter die der Workgroup Veeam brauch im über die Ressourcen sich zu bewegen hat er als Textdatei irgendwo abgelegt und bestimmt auch gehasht?
Wenn man da genauer drüber nachdenkt, dann würde es sogar Sinn machen die Domaincontroller aus der Domain zu nehmen.
Und warum sind diese Angriffe besonders gefährlich, wenn man in einer Domaine ist aber nicht als Workgroup-System?
Ich habs nicht verstanden.
Vielleicht sollte man eher seine Zeit für ein Sicherheitsaudit investieren, wenn man Angst vor Software hat, die sich so angreifen lässt und möglicherweise so schlecht auch wirklich designd und programmiert ist.
Und die Passwörter die der Workgroup Veeam brauch im über die Ressourcen sich zu bewegen hat er als Textdatei irgendwo abgelegt und bestimmt auch gehasht?
Wenn man da genauer drüber nachdenkt, dann würde es sogar Sinn machen die Domaincontroller aus der Domain zu nehmen.
Zitat von @142583:
Hat Veeam dahin gehend eine Schwachstelle und lässt sich sich mit einem Hash eines Passworts wie knacken?
Nein. Habe ich nicht gesagt.Hat Veeam dahin gehend eine Schwachstelle und lässt sich sich mit einem Hash eines Passworts wie knacken?
Ich habs nicht verstanden.
Merkt man...Vielleicht sollte man eher seine Zeit für ein Sicherheitsaudit investieren, wenn man Angst vor Software hat, die sich so angreifen lässt und möglicherweise so schlecht auch wirklich designd und programmiert ist.
Haben wir.Wenn man da genauer drüber nachdenkt, dann würde es sogar Sinn machen die Domaincontroller aus der Domain zu nehmen.
Scheinbar musst du immer das letzte Wort haben. Ich hoffe für euch, dass eure Backups immer sicher sind ;)
Ich habe eher den Eindruck, das hier eine Vorstellungswelt bezüglich Verwundbarkeit von Software und deren Hacking herrscht, wie sie in Hollywoodfilmen gezeigt wird.
Dass der Angreifer die (gesamte) Domaininfrastruktur kompromittiert hat und sich als Domainadmin bewegt...
Kleiner Tip aus der Praxis. Angriffe einer solchen Art und Güte werden manuell gesteuert. Da sitzt dann irgendwo auf der Welt ein kleines Team was es auf einen speziell abgesehen hat. Die Vorstellung dass ein Workgroup-Server dann sicherer ist, als ein Domainserver, ist wirklich eine naive Vorstellung.
Auch finde ich es interessant, dass man sich selbst als ein heikles Ziel einstuft und hier im Forum solch halbgare Sachen postet.
Wenn ich zu einer solchen Gefährdungsgruppe gehöre, dann wäre das Betreiben eines Backup Servers in einer Gesamtdomänenstruktur vielleicht nicht ganz optimal?
Als ich meinen Beruf angefangen habe, 1997, da habe ich morgens als erstes Datenträger von Backup Systemen eingesammelt und woanders hin getragen.
Dann gab es irgendwann bezahlbare Bandlaufwerke und schnelle große Wormbänder.
Heutzutage ist sicherlich nicht der große Sicherheitsgewinn zu erwarten, wenn ein Workgroup-Server an einen Netzwerk angeschlossen ist und neben einer Domäne langsam versauert.
Ich für meinen Teil weiß wie es bei Automotive OEMs, Banken und kommunalen Spitzenverbänden und Großkanzleien. Dort wäre alleine Verwaltungs-Overhead für einen Workgroup-Server mit solch wichtiger Aufgabe viel zu groß.
Dass der Angreifer die (gesamte) Domaininfrastruktur kompromittiert hat und sich als Domainadmin bewegt...
Kleiner Tip aus der Praxis. Angriffe einer solchen Art und Güte werden manuell gesteuert. Da sitzt dann irgendwo auf der Welt ein kleines Team was es auf einen speziell abgesehen hat. Die Vorstellung dass ein Workgroup-Server dann sicherer ist, als ein Domainserver, ist wirklich eine naive Vorstellung.
Auch finde ich es interessant, dass man sich selbst als ein heikles Ziel einstuft und hier im Forum solch halbgare Sachen postet.
Wenn ich zu einer solchen Gefährdungsgruppe gehöre, dann wäre das Betreiben eines Backup Servers in einer Gesamtdomänenstruktur vielleicht nicht ganz optimal?
Als ich meinen Beruf angefangen habe, 1997, da habe ich morgens als erstes Datenträger von Backup Systemen eingesammelt und woanders hin getragen.
Dann gab es irgendwann bezahlbare Bandlaufwerke und schnelle große Wormbänder.
Heutzutage ist sicherlich nicht der große Sicherheitsgewinn zu erwarten, wenn ein Workgroup-Server an einen Netzwerk angeschlossen ist und neben einer Domäne langsam versauert.
Ich für meinen Teil weiß wie es bei Automotive OEMs, Banken und kommunalen Spitzenverbänden und Großkanzleien. Dort wäre alleine Verwaltungs-Overhead für einen Workgroup-Server mit solch wichtiger Aufgabe viel zu groß.
Zitat von @142583:
Ich habe eher den Eindruck, das hier eine Vorstellungswelt bezüglich Verwundbarkeit von Software und deren Hacking herrscht, wie sie in Hollywoodfilmen gezeigt wird.
Ja und Nein,Ich habe eher den Eindruck, das hier eine Vorstellungswelt bezüglich Verwundbarkeit von Software und deren Hacking herrscht, wie sie in Hollywoodfilmen gezeigt wird.
Es gibt genug Bericht wo ein AD-Server nackt per RDP Online war und es parallel einen Admin-Benutzer "Scan" mit dem Kennwort "scan" gab.
und Zack und Ende...
Es ist eher eine Frage nach Aufwand und Nutzen und muss jeder selber entscheiden.
Ich mache es so weil es wenig Aufwand in kleinen Installationen ist und eine, vieleicht nur gefühlte, Form der Sicherheit bietet.
Stefan
Ja, das gibt es in der Tat.
Genau das ist es aber was ich zum Ausdruck bringen will.
Ich habe einen schlecht oder gar nicht geschützten Domain Controller oder Bestandteile der Domain.
In dieser Situation befindlich, mache ich mir dann große Gedanken über das hardening meines Veeam?
Genau das ist es aber was ich zum Ausdruck bringen will.
Ich habe einen schlecht oder gar nicht geschützten Domain Controller oder Bestandteile der Domain.
In dieser Situation befindlich, mache ich mir dann große Gedanken über das hardening meines Veeam?
