21
Sicherheit virtueller Maschinen vs. dedizierter Hardware
Hallo Welt,
ich schicke voraus, dass ich nun seit 15 Jahren kein Sysadmin mehr bin und technische Entwicklungen lediglich durch lesen diversester Publikationen aufnehme. Also Halbwissen.
Für einen Kunden habe ich aus diversen Normen einige Vorgaben für ein größeres datenbankbasierendes System abgeleitet. Eine Vorgabe war, der Datenbankserver muss ein dedizierter physischer Server sein und darf nicht zusammen mit den Applikationsservern auf einem Virtualisierungssystem laufen. Als Gründe sind in den Normen angegeben, dass ein Ausbrechen aus einem Applikationsserver und ein Einbrechen in den Datenbankserver und damit direkten Zugriff auf die Datenbank nicht hinreichend ausgeschlossen werden kann.
Die Kunden-IT argumentiert nun, dass eine Person, der es gelingt auf einem Applikationsserver auf Betriebssystemebene zu agieren, jederzeit über das Netzwerk auf den Datenbankserver einwirken kann. Daher wäre ein physischer Server kein Sicherheitsgewinn.
Ich argumentierte wieder, auf dem DB-Server könnte mittels einer lokalen Firewall der direkte Zugriff verwehrt werden und nur der Datenverkehr zwischen APP-Server und DB-Server zugelassen werden.
Sagt die Kunden-IT, dann geht die Performance der DB-Maschine in den Keller.
Und jetzt hört es bei mir wieder auf. Port-Filter hatten wir schon zu meiner Zeit auf den Servern, war damals kein Problem. Oder haben die Jungs von der Kunden-IT recht?
Fakten und Meinungen sind mir willkommen.
Ciao
Pitti
ich schicke voraus, dass ich nun seit 15 Jahren kein Sysadmin mehr bin und technische Entwicklungen lediglich durch lesen diversester Publikationen aufnehme. Also Halbwissen.
Für einen Kunden habe ich aus diversen Normen einige Vorgaben für ein größeres datenbankbasierendes System abgeleitet. Eine Vorgabe war, der Datenbankserver muss ein dedizierter physischer Server sein und darf nicht zusammen mit den Applikationsservern auf einem Virtualisierungssystem laufen. Als Gründe sind in den Normen angegeben, dass ein Ausbrechen aus einem Applikationsserver und ein Einbrechen in den Datenbankserver und damit direkten Zugriff auf die Datenbank nicht hinreichend ausgeschlossen werden kann.
Die Kunden-IT argumentiert nun, dass eine Person, der es gelingt auf einem Applikationsserver auf Betriebssystemebene zu agieren, jederzeit über das Netzwerk auf den Datenbankserver einwirken kann. Daher wäre ein physischer Server kein Sicherheitsgewinn.
Ich argumentierte wieder, auf dem DB-Server könnte mittels einer lokalen Firewall der direkte Zugriff verwehrt werden und nur der Datenverkehr zwischen APP-Server und DB-Server zugelassen werden.
Sagt die Kunden-IT, dann geht die Performance der DB-Maschine in den Keller.
Und jetzt hört es bei mir wieder auf. Port-Filter hatten wir schon zu meiner Zeit auf den Servern, war damals kein Problem. Oder haben die Jungs von der Kunden-IT recht?
Fakten und Meinungen sind mir willkommen.
Ciao
Pitti
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: 544014
Url: https://administrator.de/contentid/544014
Ausgedruckt am: 24.11.2024 um 13:11 Uhr
21 Kommentare
Neuester Kommentar
Hi,
ich denke, rein aus Sicht der verwendeten OS und der LAN-Anbindung macht es keinen Unterschied. Bei einer VM kommt aber hinzu, dass man zumindest theoretisch durch den Hypervisor ein weiteres potentielles Einfallstor hat. Also eine weitere Stelle, welche man absichern muss.
E.
ich denke, rein aus Sicht der verwendeten OS und der LAN-Anbindung macht es keinen Unterschied. Bei einer VM kommt aber hinzu, dass man zumindest theoretisch durch den Hypervisor ein weiteres potentielles Einfallstor hat. Also eine weitere Stelle, welche man absichern muss.
E.
Hallo,
virtualisierung wurde eingeführt um die Effektivität von Servern zu erhöhen.
Durch die höhere Effektivität ist dieser Lösungsansatz günstiger.
Außerdem bringt er verschiedene Vorteile bei der Verfügbarkeit sowie Pflege und Wartung mit sich.
Die Virtualisierung stellt grundsätzlich eine komplexe Komponte dar die zu komplexen Fehlern neigen kann und auch die Sicherheit kompromitieren kann.
Eine physikalische Maschine ist teurer, aufwendiger, schneller und sicherer (wenn richtig gepflegt).
Was davon wie zutrifft hängt natürlich von den konkreten Umständen ab.
Ein nicht gepflegter und gewarteter Windows Server ohne Firewall und Updates ist wohl kaum sicherer als eine VM Umgebung die gut gepflegt ist.
Die Kunden-IT hat da einfach keinen Bock drauf.
Das könnte durchaus eine religioöse Diskussion werden.
Schon mal versucht einen Christen davon zu überzeugen, dass es Gott nicht gibt?
Die Vorgaben für die Sicherheit und Umsetzung machen aber andere.
Die sollen sie umsetzen.
virtualisierung wurde eingeführt um die Effektivität von Servern zu erhöhen.
Durch die höhere Effektivität ist dieser Lösungsansatz günstiger.
Außerdem bringt er verschiedene Vorteile bei der Verfügbarkeit sowie Pflege und Wartung mit sich.
Die Virtualisierung stellt grundsätzlich eine komplexe Komponte dar die zu komplexen Fehlern neigen kann und auch die Sicherheit kompromitieren kann.
Eine physikalische Maschine ist teurer, aufwendiger, schneller und sicherer (wenn richtig gepflegt).
Was davon wie zutrifft hängt natürlich von den konkreten Umständen ab.
Ein nicht gepflegter und gewarteter Windows Server ohne Firewall und Updates ist wohl kaum sicherer als eine VM Umgebung die gut gepflegt ist.
Die Kunden-IT hat da einfach keinen Bock drauf.
Das könnte durchaus eine religioöse Diskussion werden.
Schon mal versucht einen Christen davon zu überzeugen, dass es Gott nicht gibt?
Die Vorgaben für die Sicherheit und Umsetzung machen aber andere.
Die sollen sie umsetzen.
Hallo Pitti,
dieses Normativ halte ich für überholt. Sicherlich mag der Virtualisierungshost ein weiteres Einbruchstor sein, allerdings kann bei einem nicht-virtuellen Server das IPMI, Ilo etc ebenfalls eines sein. Generell muss jeder Server entsprechend gesichert sein, dies ist dabei irrelevant, ob es ein Träger oder ein Arbeitssystem ist, dazu kommt, dass die HAL (und damit der Schutz des Hypervisors gegen Eindringen vom Gast, als auchvice versa) ebenfalls wesentlich verbessert wurde.
Früher war auch das Paradigma, dass ein AD nur auf extra HW laufen sollte, dieses haben wir bereits seit 2014 verworfen. Es macht schlicht keinen Sinn, man kann einen HW-AD im wesentlichen genauso schnell richten, wie ein virtuellen, die Sicherheit wird (aus der Erfahrung der übernommenen Systeme bei Neukunden) dadurch ebenfalls nicht reduziert.
Wichtig ist ein profundes IT- und IT-Sicherheitskonzept und deren tatsächliche Umsetzung.
Wo man natürlich ansetzen kann ist eine Netzsegmentierung, dies sollte sowieso gegeben sein. Je nach Anforderung dimensioniert, um keine Verzögerung entstehen zu lassen.
Nebenbei, darf man Fragen, was dein "job" dort ist? Bzw was du da vor hast?
VG
dieses Normativ halte ich für überholt. Sicherlich mag der Virtualisierungshost ein weiteres Einbruchstor sein, allerdings kann bei einem nicht-virtuellen Server das IPMI, Ilo etc ebenfalls eines sein. Generell muss jeder Server entsprechend gesichert sein, dies ist dabei irrelevant, ob es ein Träger oder ein Arbeitssystem ist, dazu kommt, dass die HAL (und damit der Schutz des Hypervisors gegen Eindringen vom Gast, als auchvice versa) ebenfalls wesentlich verbessert wurde.
Früher war auch das Paradigma, dass ein AD nur auf extra HW laufen sollte, dieses haben wir bereits seit 2014 verworfen. Es macht schlicht keinen Sinn, man kann einen HW-AD im wesentlichen genauso schnell richten, wie ein virtuellen, die Sicherheit wird (aus der Erfahrung der übernommenen Systeme bei Neukunden) dadurch ebenfalls nicht reduziert.
Wichtig ist ein profundes IT- und IT-Sicherheitskonzept und deren tatsächliche Umsetzung.
Wo man natürlich ansetzen kann ist eine Netzsegmentierung, dies sollte sowieso gegeben sein. Je nach Anforderung dimensioniert, um keine Verzögerung entstehen zu lassen.
Nebenbei, darf man Fragen, was dein "job" dort ist? Bzw was du da vor hast?
VG
Na ja, ich bin für die Applikationssicherheit eingekauft. Die Technik mache ich, weil es sonst gar keiner machen würde.
Ich werfe mal das aktuellste Problem in den Raum: Die Bugs in den Intel-CPUs, die Zugriff auf den Cache ermöglichen und damit auf alle Daten aller Prozesse, die auf der CPU laufen — und das bei einigen dieser Lücken auch VM-Übergreifend.
Und Rowhammer gibt es ja auch noch...
Allerdings setzt das Code-Ausführung in einer VM voraus, was natürlich an sich eine massive Lücke voraussetzen würde und in der Regel mit sich bringt, dass sich Angreifer dann auch direkt per Netzwerk mit der Datenbank verbinden könnten um Daten herauszutragen oder zu manipulieren.
Von daher würde ich die Aussage so einschränken, dass man schlicht nur VMs gemeinsam auf dem gleichen Host laufen lässt, die ohnehin Zugriff auf die Datenbank hätten.
Was Portfilter auf dem DB-Server angeht, sehe ich da auch kein Performance-Problem.
Die meisten Leute denken bei "Firewall" direkt an aufwendige IDS, aber reine Portfilter sind ja letztlich nie verkehrt.
Und Rowhammer gibt es ja auch noch...
Allerdings setzt das Code-Ausführung in einer VM voraus, was natürlich an sich eine massive Lücke voraussetzen würde und in der Regel mit sich bringt, dass sich Angreifer dann auch direkt per Netzwerk mit der Datenbank verbinden könnten um Daten herauszutragen oder zu manipulieren.
Von daher würde ich die Aussage so einschränken, dass man schlicht nur VMs gemeinsam auf dem gleichen Host laufen lässt, die ohnehin Zugriff auf die Datenbank hätten.
Was Portfilter auf dem DB-Server angeht, sehe ich da auch kein Performance-Problem.
Die meisten Leute denken bei "Firewall" direkt an aufwendige IDS, aber reine Portfilter sind ja letztlich nie verkehrt.
Hallo,
ich sag mal das wenn dich das ganze in nem Rechenzentrum betreibe wo auf dem Server auch VM's von anderen Kunden liegen mag das noch seine berechtigung haben bezüglich Sicherheit.
Auch eine Firewall würde ich nur unter sehr bestimmten Bedigungen in einer VM laufen lassen.
Aber so sehe ich das auch etwas überhohlt.
Rein vom Leistungsaspekt kann es aber unter umständen schon sein das man sich mit VM's Ärger macht bei Datenbanken.
ich sag mal das wenn dich das ganze in nem Rechenzentrum betreibe wo auf dem Server auch VM's von anderen Kunden liegen mag das noch seine berechtigung haben bezüglich Sicherheit.
Auch eine Firewall würde ich nur unter sehr bestimmten Bedigungen in einer VM laufen lassen.
Aber so sehe ich das auch etwas überhohlt.
Rein vom Leistungsaspekt kann es aber unter umständen schon sein das man sich mit VM's Ärger macht bei Datenbanken.
Moin,
meiner Meinung nach ist die Diskussion bzgl. Sicherheit HV vs. Blech überflüssig. Beides gilt als sicher.
Andere Themen können hier interessant werden. Geschwindigkeit z.B. - da kann Blech z.T. punkten.
Was aber viel wichtiger ist, ist die Frage, wie man mit bestimmten Themen umgeht. Da wären zum Beispiel HA, Backup und DeasasterRecovery usw. usf.
Was bringt dir das sicherste System, wenn die Bude brennt und du dann 5 Tage mit dem Restore beschäftigt bist.
Gruß
meiner Meinung nach ist die Diskussion bzgl. Sicherheit HV vs. Blech überflüssig. Beides gilt als sicher.
Andere Themen können hier interessant werden. Geschwindigkeit z.B. - da kann Blech z.T. punkten.
Was aber viel wichtiger ist, ist die Frage, wie man mit bestimmten Themen umgeht. Da wären zum Beispiel HA, Backup und DeasasterRecovery usw. usf.
Was bringt dir das sicherste System, wenn die Bude brennt und du dann 5 Tage mit dem Restore beschäftigt bist.
Gruß
Noch eine Verständnisfrage, ans IPMI komme ich doch vom OS eines virtuellen Servers gar nicht ran, oder? Wir fahren hier ein Admin-Netz und ein App-Netz. Wenn ich auf einem APP-Server aus der Anwendung ausbreche und mit den Rechten der Applikation auf das OS zugreife, dann ist das Admin-Netz doch weiterhin unkompromitiert, oder?
Zitat von @Pitti259:
Noch eine Verständnisfrage, ans IPMI komme ich doch vom OS eines virtuellen Servers gar nicht ran, oder? Wir fahren hier ein Admin-Netz und ein App-Netz. Wenn ich auf einem APP-Server aus der Anwendung ausbreche und mit den Rechten der Applikation auf das OS zugreife, dann ist das Admin-Netz doch weiterhin unkompromitiert, oder?
Ob du aus einer VM dahin kommst hängt vom Netzdesign ab. Der Kollege spielte eigentlich darauf an, dass IPMI an sich schon ein Einfallstor für einen Server sein kann. Mal angenommen durch einen Softwarefehler wurde ein Adminrechner übernommen. Der kommt ans IPMI-Interface dann auf den Server usw uswNoch eine Verständnisfrage, ans IPMI komme ich doch vom OS eines virtuellen Servers gar nicht ran, oder? Wir fahren hier ein Admin-Netz und ein App-Netz. Wenn ich auf einem APP-Server aus der Anwendung ausbreche und mit den Rechten der Applikation auf das OS zugreife, dann ist das Admin-Netz doch weiterhin unkompromitiert, oder?
Danke schon mal, die Punkte machen mir aber weniger Sorgen. Auf den VMs werden mehrfach tätlighc Snapshots gezogen und für den DB-Server habe ich auch eine HV über zwei Standorte vorgeschlagen. Die Jungs von der Kunden-IT sind Profis, das bekommen die gut hin.
Und weil die Jungs Profis sind, möchte ich deren Argumente auch nicht ignorieren.
Meine Sorge ist hauptsächlich, dass Anwender aus der Applikation ausbrechen könnten. Die Anwender-PCs haben wir nicht im Zugriff, da drüber könnte sich Hinz und Kunz auf die Applikation schalten und mit eventuell auch geklauten Benutzeranmeldungen und "normalen" Benutzerrechten versuchen dort ihr Unwesen zu treiben.
Und weil die Jungs Profis sind, möchte ich deren Argumente auch nicht ignorieren.
Meine Sorge ist hauptsächlich, dass Anwender aus der Applikation ausbrechen könnten. Die Anwender-PCs haben wir nicht im Zugriff, da drüber könnte sich Hinz und Kunz auf die Applikation schalten und mit eventuell auch geklauten Benutzeranmeldungen und "normalen" Benutzerrechten versuchen dort ihr Unwesen zu treiben.
Zitat von @Pitti259:
Die Kunden-IT argumentiert nun, dass eine Person, der es gelingt auf einem Applikationsserver auf Betriebssystemebene zu agieren, jederzeit über das Netzwerk auf den Datenbankserver einwirken kann. Daher wäre ein physischer Server kein Sicherheitsgewinn.
Die Kunden-IT argumentiert nun, dass eine Person, der es gelingt auf einem Applikationsserver auf Betriebssystemebene zu agieren, jederzeit über das Netzwerk auf den Datenbankserver einwirken kann. Daher wäre ein physischer Server kein Sicherheitsgewinn.
Falsch.
Ich argumentierte wieder, auf dem DB-Server könnte mittels einer lokalen Firewall der direkte Zugriff verwehrt werden und nur der Datenverkehr zwischen APP-Server und DB-Server zugelassen werden.
ja.
Sagt die Kunden-IT, dann geht die Performance der DB-Maschine in den Keller.
Gößere Maschine kaufen.
Und jetzt hört es bei mir wieder auf. Port-Filter hatten wir schon zu meiner Zeit auf den Servern, war damals kein Problem. Oder haben die Jungs von der Kunden-IT recht?
Jein.
Fakten und Meinungen sind mir willkommen.
Wenn ein Angreifer aus einer VM heraus den hypervisor kontrolliert,kann der alle VMs kompromittieren, ohna daß diese dagegen etwas unternehmen können.
Wenn ein Angreifer eine Kiste im Netz kompromittiert, muß er immer noch über Netzwerk ander Kiste "aufschließen", was durch passenden Vorkehrungen wie Firewall und IDS im weitesten Sinne verhindert oder zumindest entdeckt werden kann.
Rein von der Sicherheit her gesehen sind dedizerte Kisten "sicherer". Allerdings auf Kosten andere Faktoren. wie z.B. Bandbreite der Komunnikation zu anderen Servern.
Was man letztendlich nimmt soltle druch eine Risikoabwägung geschehen, d.h. wie wahrscheinlich ist ein Angriff, welche Kosten verursacht dieser, welche mehrkosten entstehen durch die andere Lösung, etc.
Schlußendlich: Wirf 'ne Münze.
lks
also rein aus technischer Sicht ist ein Hypervisor natürlich ein potentielles zusätzliches Sicherheitsproblem weil es als zusätzliche Software immer irgendwelche zusätzliche Angriffsfläche darstellt. Eine Softwarefirewall macht das allerdings auch.
Da muss ich den Jungs aber dann schon zustimmen. Aus reinen Security-Gründen und so äusserst theoretischen Angriffsszenarien heraus würde ich mich jetzt auch nicht gegen Virtualisierung entscheiden. Wenn man das so genau nimmt, dann darf da auch kein L3 Switch dazwischen stecken, weil der hat ja auch viel mehr Angriffsfläche als ein L2 weil mehr Software. Dann darf da kein IPMI am Server sein, kein dies kein das.
Irgendwo ist halt auch mal der Punkt erreicht wo man wieder die realität betrachten muss, und da überwiegen die realen Vorteile einer VM einfach die potentiellen Nachteile:
Hochverfügbarkeit in einem kleinen VM Cluster bei geringeren Lizenzkosten (je nach OS\DB)
Sicherungsmöglichkeiten
Snapshots
Hardwareunabhängigkeit
Notfalloptionen wie spontanes "In die Cloud schieben"
usw usw.
Das übliche halt.
Da sollte man dann halt die Hypervisor aktuell halten.
Und beim Thema: Man kann natürlich auch einfach einen eigenen Server für die DB kaufen, darauf eienn Hypervisor standalone laufen lassen und darin dann eine einzige VM laufen lassen. Damit hätte man die meisten Vorteile einer Virtualisierung ohne die Möglichkeit das ein Angreifer aus einer anderen VM heraus ausbricht und über den Hypervisor auf die DB kommt. Bei genügend Budget geht das natürlich auch als Cluster.
Da muss ich den Jungs aber dann schon zustimmen. Aus reinen Security-Gründen und so äusserst theoretischen Angriffsszenarien heraus würde ich mich jetzt auch nicht gegen Virtualisierung entscheiden. Wenn man das so genau nimmt, dann darf da auch kein L3 Switch dazwischen stecken, weil der hat ja auch viel mehr Angriffsfläche als ein L2 weil mehr Software. Dann darf da kein IPMI am Server sein, kein dies kein das.
Irgendwo ist halt auch mal der Punkt erreicht wo man wieder die realität betrachten muss, und da überwiegen die realen Vorteile einer VM einfach die potentiellen Nachteile:
Hochverfügbarkeit in einem kleinen VM Cluster bei geringeren Lizenzkosten (je nach OS\DB)
Sicherungsmöglichkeiten
Snapshots
Hardwareunabhängigkeit
Notfalloptionen wie spontanes "In die Cloud schieben"
usw usw.
Das übliche halt.
Da sollte man dann halt die Hypervisor aktuell halten.
Und beim Thema: Man kann natürlich auch einfach einen eigenen Server für die DB kaufen, darauf eienn Hypervisor standalone laufen lassen und darin dann eine einzige VM laufen lassen. Damit hätte man die meisten Vorteile einer Virtualisierung ohne die Möglichkeit das ein Angreifer aus einer anderen VM heraus ausbricht und über den Hypervisor auf die DB kommt. Bei genügend Budget geht das natürlich auch als Cluster.
Wenn ein Angreifer aus einer VM heraus den hypervisor kontrolliert,kann der alle VMs kompromittieren, ohna daß diese dagegen etwas
unternehmen können.
unternehmen können.
Galt vielleicht in 2010. Nicht mehr in 2020. Abgesehen davon sehe ich die wahrscheinlichkeit des Ausbruchs aus einer VM für weniger wahrscheinlich, als den Ausbruch über
Wenn ein Angreifer eine Kiste im Netz kompromittiert, muß er immer noch über Netzwerk ander Kiste "aufschließen", was durch passenden
Vorkehrungen wie Firewall und IDS im weitesten Sinne verhindert oder zumindest entdeckt werden kann.
Vorkehrungen wie Firewall und IDS im weitesten Sinne verhindert oder zumindest entdeckt werden kann.
Das Netz. Die Behebung von Ausbrüche über das Netz auf andere Maschinen mussten wir leider schon öfter übernehmen, Ausbrüche über HV-Gast bisher noch nie. Du bereits?
(Ich widerspreche nicht, dass es in der Theorie möglich ist, aber das tatsächliche Vorkommnis...)
Zitat von @certifiedit.net:
Galt vielleicht in 2010. Nicht mehr in 2020. Abgesehen davon sehe ich die wahrscheinlichkeit des Ausbruchs aus einer VM für weniger wahrscheinlich, als den Ausbruch über
Wenn ein Angreifer aus einer VM heraus den hypervisor kontrolliert,kann der alle VMs kompromittieren, ohna daß diese dagegen etwas
unternehmen können.
unternehmen können.
Galt vielleicht in 2010. Nicht mehr in 2020. Abgesehen davon sehe ich die wahrscheinlichkeit des Ausbruchs aus einer VM für weniger wahrscheinlich, als den Ausbruch über
Deswegen sage ich ja immer: Risikoabwägung.
Wenn ein Angreifer eine Kiste im Netz kompromittiert, muß er immer noch über Netzwerk ander Kiste "aufschließen", was durch passenden
Vorkehrungen wie Firewall und IDS im weitesten Sinne verhindert oder zumindest entdeckt werden kann.
Vorkehrungen wie Firewall und IDS im weitesten Sinne verhindert oder zumindest entdeckt werden kann.
Das Netz. Die Behebung von Ausbrüche über das Netz auf andere Maschinen mussten wir leider schon öfter übernehmen, Ausbrüche über HV-Gast bisher noch nie. Du bereits?
Weder das eine noch das andere, wenn ich selbst die Systeme hingestellt habe. Als "Feuerwehr" kam schon beides vor.
(Ich widerspreche nicht, dass es in der Theorie möglich ist, aber das tatsächliche Vorkommnis...)
Es kommt vor, ist nicht so spektakulär wie über Netzwerk, weil es viel seltener auffällt. Man merkt es eigentlich nur an "Ungereimtheiten", wenn es zu spät ist.
lks
Würde mich interessieren in welchem Setup/mit welchem Ursprung/welche Auswirkungen.
auf dem DB-Server könnte mittels einer lokalen Firewall der direkte Zugriff verwehrt werden und nur der Datenverkehr zwischen APP-Server und DB-Server zugelassen werden.
Ist ja aus Netzwerksicht dann aber sinnfrei, denn das hypothetische Angriffsszenario des Kunden ging ja genau davon aus das jemand direkten OS Zugriff auf den APP Server hat. Wenn dann aber die DB Server Firewall Traffic zwischen APP Server und DB Server explizit zulässt, ist das Argument Firewall auf dem DB Server ja dann eigentlich ad absurdum geführt !
Äh, einen Traffic zwischen APP-Server und DB-Server muss ich ja wohl zulassen, sonst kriegt der APP-Server ja keine Daten. Aber ich kann doch den Datenstrom auf bestimmte Ports einschränken und damit z.B. einen SMB-Zugriff unterbinden.
Das kannst du aber in jedem Fall. Egal ob VM oder nicht.
@lks Hast du mir einen entsprechenden Case für den Ausbruch aus einer VM, den du behandelt hast?
@lks Hast du mir einen entsprechenden Case für den Ausbruch aus einer VM, den du behandelt hast?
Zitat von @certifiedit.net:
Das kannst du aber in jedem Fall. Egal ob VM oder nicht.
@lks Hast du mir einen entsprechenden Case für den Ausbruch aus einer VM, den du behandelt hast?
Das kannst du aber in jedem Fall. Egal ob VM oder nicht.
@lks Hast du mir einen entsprechenden Case für den Ausbruch aus einer VM, den du behandelt hast?
Ja, steht aber unter non-disclosure.
Auch das SystemSetup (eingesetzte Software/Version etc)? Naja, das ist dann natürlich sehr "aufschlussreich".
Moin,
Gruß,
Dani
Äh, einen Traffic zwischen APP-Server und DB-Server muss ich ja wohl zulassen, sonst kriegt der APP-Server ja keine Daten. Aber ich kann doch den Datenstrom auf bestimmte Ports einschränken und damit z.B. einen SMB-Zugriff unterbinden.
Das eine ist die Firewall, das andere die Verschlüsselung des Datenverkehrs. Beides kann mit Windows Defender realisiert werden. Macht eine spätere Fehlersuche nicht einfacher...Gruß,
Dani
