Container statt Updates: Docker, Kubernetes & VM

Volker: Moin Moin, hallo und herzlich willkommen zur Sicherheitslücke und unser Podcast

Volker: heute handelt vom Thema oder über das Thema Virtualisierung.

Volker: Wir kommen ja in den letzten Sendungen aus dem Umfeld der, was machen wir,

Volker: wenn Windows 10 jetzt ausläuft, wie können wir eigentlich überhaupt relativ

Volker: sichere Betriebssysteme herstellen und haben uns dann nochmal überlegt,

Volker: naja, wie wäre es eigentlich, wenn wir die Sicherheit vom Betriebssystem komplett

Volker: abstrahieren und in irgendein Virtualisierungsumfeld oder Software stecken.

Volker: Und damit begrüßen wir euch. Ich bin Volker Skwarek von der HW Hamburg.

Monina: Monina Schwarz vom LSI.

Ingo: Und Ingo Tim vom DFKI und der Uni Trier.

Volker: Und als besonderen Gast haben wir mit dabei Mark Hebbel von der Firma Chainstep. Hallo Mark.

Mark: Hi Volker, hallo alle.

Volker: Ja, vielen Dank, dass du bereit bist, so ein bisschen über euch und eure Projekte

Volker: zu erzählen, wobei natürlich kein Projekt interner, sondern mehr so die Frage,

Volker: wie ihr mit Virtualisierung im Rahmen von Projekten umgegangen seid.

Volker: Einsteigen wollen wir auch schon gleich mit dem allseits bekannten Thema Docker oder Nicht-Docker,

Volker: sprich so eine mittlere Virtualisierungsebene, wo man schon irgendwie auf den

Volker: ganzen Rechnern, die man betreibt, eine eigene Virtualisierungssoftware installieren muss.

Volker: Das ist allerdings dann eine recht leichtgewichtige, weil Docker nun kein eigenes

Volker: Betriebssystem mitbringt, sondern quasi auf dem Betriebssystem aufsetzt in der

Volker: eigenen Docker-Software.

Volker: Und da gleich mal so an Marc die Frage, inwieweit oder wie lange habt ihr mit

Volker: Docker gearbeitet, beziehungsweise welche Art von Projekten geht ihr mit Docker an?

Mark: Ja, so, ich habe persönlich mit dochiger Arbeit, seit es rausgekommen ist fast,

Mark: so, ich glaube, ich habe nachgeguckt gestern, es ist rausgekommen 2014,

Mark: ziemlich lange her jetzt,

Mark: und fand es sehr nützlich, aber kommen wir dazu gleich.

Mark: Wie oft benutzen wir das? Wir benutzen das für jede einzelne Projekte im Prinzip,

Mark: eben groß oder klein, so auch privat für die Entwicklung, so jeder Entwickler

Mark: benutzt das für sich selbst, auch seinen eigenen Rechner, aber wir benutzen

Mark: das auch in Produktion für gehosteted Software, das die Kunden denn benutzen.

Volker: Hat das bei euch Sicherheitsgründe oder ist das eher so ein bisschen Bequemlichkeit,

Volker: so nach dem Motto, naja, jeder Rechner hat irgendwie eine eigene Konfiguration,

Volker: und wenn ich die ausblenden will, nehme ich einfach eine standardisierte Umgebung

Volker: und baue da drin. Also Sicherheit oder Bequemlichkeit?

Mark: Beides. Ich meine, klar, für die Bequemlichkeit ist auf jeden Fall das Hauptthema

Mark: für die private Entwicklung auf seinen privaten Rechner.

Mark: Die Sicherheit ist ein großes Thema, wenn man das fängt an zu hosten auf Kubernetes

Mark: und für Produktion und so weiter.

Volker: Wie geht ihr damit um? Also habt ihr irgendwelche Checklisten,

Volker: wonach ihr sichere oder, ich sag mal, irgendwelche Entwicklungsguidelines,

Volker: Policies, wonach ihr entwickelt und was ihr dann nachher in Docker auch mit

Volker: implementiert, um das dann Kunden weiterzugeben?

Volker: Oder wie funktioniert das bei euch mit der Sicherheit?

Mark: Ach, mit der Sicherheit? Das ist wirklich für die Produktion.

Mark: Es gibt verschiedene Arten und Weise, wie man sicher sein kann in Docker.

Mark: Ich weiß nicht, aber ich springe einfach direkt rein. Erstens,

Mark: die Software in die Docker-Container oder vielleicht so anfangen.

Mark: Die Docker-Container, wie man heißt, ist ein eigenes Betriebssystem.

Mark: Der läuft so in einer Linux-Umgebung und läuft dann auf einem Hauptrechner.

Mark: Die Software selbst in die Docker-Container muss erstens minimal sein und auch

Mark: quasi sauber sein von irgendwelchen Viren oder sowas.

Mark: So Sicherheitsweise, wenn man Standardsoftware benutzt, zum Beispiel einen SQL

Mark: Server oder irgendwas, dann nimmt man immer die neueste Docker Container für die SQL Server.

Mark: Dann kann man immer, ist man immer sicher, dass man hat die neueste Bugfix ist

Mark: drin, die neueste Sicherheitslöcke sind gestopft.

Mark: Wenn man seine eigene Software in Docker Container baut, dann baut man das Docker

Mark: Container im Prinzip so, dass es minimal ist.

Mark: Man hat die schöne Sache mit Docker, dass man kann im minimalen Basissystem

Mark: da reinparken und nur die Sachen installieren, das wirklich notwendig sind.

Mark: Der dritte Punkt ist natürlich die Sicherheit von der Quelle selbst.

Mark: Man kann natürlich alle Docker-Containers auf das sogenannte Docker-Hub hosten. Das kommt von Docker.

Mark: Aber das ist ein offener Repository und ob das sicher ist in sich selbst oder

Mark: andere Leute machen Side-Attacks da, das ist eine Sache.

Mark: Das heißt, wir benutzen unsere eigenen Docker-Repository für unsere eigenen

Mark: Containers, das dann direkt in Amender unser Kubernetes dann liefert,

Mark: aber kann auch lokal benutzt auf seinen eigenen Rechner.

Mark: So, das war sofort tief drin in die Haupt-3-Punkte, das du gefragt hast für die Sicherheit.

Volker: Ja, mich würde tatsächlich auch interessieren, es gibt ja auch jetzt zwei Arten

Volker: von Updates der Applikationen.

Volker: Also wir möchten ja im Prinzip etwas unabhängiger werden von der Sicherheit

Volker: des Betriebssystems für die Sicherheit der Anwendung.

Volker: Und da eben als Zwischenschicht Docker, dass man sagt, na gut,

Volker: wenn, keine Ahnung, dein Windows-Rechner, du jetzt auf Windows 10 bleibst,

Volker: wovon wir dringend abraten und dieses Windows 10 noch Sicherheitslücken jetzt

Volker: entwickelt, die ausgenutzt werden,

Volker: dann ist die Anwendung innerhalb von Docker erstmal davon abgekoppelt und relativ, relativ sicher.

Volker: Jetzt ist aber die Frage, was passiert, wenn du ein Update der Applikation bekommst?

Volker: Du hast jetzt von SQL Server geredet.

Volker: Wie wird innerhalb von Docker jetzt damit umgegangen?

Volker: Aktualisiert ihr das? Aktualisiert das die Applikation innerhalb von Docker

Volker: selbst? Wie funktioniert da so ein Update?

Mark: So ein Update funktioniert ist, dass die Leute, die Community,

Mark: die SQL-Service machen, so wir benutzen Postgres zum Beispiel,

Mark: machen eine neue Software-Update und dann wird es normalerweise heutzutage automatisch

Mark: führen zu einem neuen Container-Update.

Mark: Bei uns, wenn wir das hosten auf ein Server oder irgendwas, dann machen wir

Mark: meistens ein manuell Update, weil wir müssen das erstens testen mit unserer Software.

Mark: Meistens haben wir ein Dev Cluster, wo wir das testen, bevor wir das auf Production bringen.

Mark: Aber wir im Prinzip machen nichts anderes als die alte Container runterfahren

Mark: und die neue Container hochfahren.

Mark: Die ganzen Daten selbst sind auf ein sogenannter gelinkter volume das heißt

Mark: die daten behalten sich und die

Mark: Man kann einfach die neue Version von der Software hochfahren und hat sofort

Mark: alle Bugfixes und Sicherheitslöcke geblockt, die in die Updates sind.

Mark: Das ist aus diesem Grund auch für ein ganz normaler SQL Server,

Mark: wo wir kein Kubernetes benutzen aus verschiedenen Gründen.

Mark: Wir haben einfach einen Server, einen reinen Debian Server, wo wir einfach die

Mark: SQL Server drauf spielen.

Mark: Und dann, wenn wir sehen, dass eine neue Version kommt, können wir einfach schnell

Mark: updaten ohne großen Aufwand. Und das ist der große Vorteil davon.

Mark: Wenn man das installiert direkt auf dem Server, dann musste man dann erstens

Mark: dieses Server sauber machen, vielleicht Debian neu installieren und dann die neue Software drauf.

Mark: Hier können wir einfach die Container runterfahren, in die neue Software,

Mark: in die neue Container hochfahren.

Volker: Okay, also ihr würdet jetzt den SQL-Server einfach austauschen und insofern

Volker: finde ich auch ein ganz guter Vorgang für eine saubere Deployment-Policy,

Volker: weil, nehmen wir mal an,

Volker: ein SQL-Server hätte ein Update in einer normalen Entwicklungsumgebung,

Volker: dann würde man einfach das Update einspielen und die gesamte SQL-Umgebung,

Volker: die man ja programmiert hat, die Datenbank,

Volker: bleibt ja erst mal bestehen.

Volker: Das heißt, es würde quasi ein heimliches, mehr oder weniger Update eingespielt

Volker: werden, Sicherheitsupdate,

Volker: und es wäre gar nicht sauber getestet, ob das Sicherheitsupdate noch mit der

Volker: ursprünglichen SQL-Konfiguration, die ihr ja gemacht habt, mit der Datenbank, zusammenspielt.

Volker: Und das macht ihr dann erst manuell.

Volker: Das heißt, ihr trennt die Datenbankanwendung und die Datenbank an sich,

Volker: aktualisiert den Docker, prüft das Ganze und gebt es dann für den Kunden frei,

Volker: sodass er sich einen kompletten Docker-Container mit Datenbank und Anwendung herunterladen kann.

Mark: Genau, was heißt runterladen? Die sind alle gehöstet im Cloud,

Mark: aber im Prinzip, ja, die können das dann benutzen dann auch, ja.

Volker: Und dann hattest du noch so ein nettes Stichwort gesagt, mir fällt immer dieser

Volker: Journalisten-Modus schwierig, Entschuldigung.

Volker: Du hattest gesagt Kubernetes.

Volker: Kubernetes, ja. Was meinst du damit? Ich stelle mich jetzt mal dumm,

Volker: sorry, geht nicht so gut, aber sowas macht Kubernetes bei euch.

Mark: So, der Container selbst ist ein abstrakter Konstrukt von dem Linux-Betriebssystem.

Mark: Das heißt, man kann irgendwas da reinstopfen und das laufen lassen,

Mark: irgendwelche Software da reinstopfen und das laufen lassen auf einen Computer.

Mark: Entweder ein Linux-Computer, aber auch ein Windows-Computer oder ein Mac-Computer.

Mark: Es ist völlig egal, es läuft dann überall.

Volker: Und das macht Docker ja auch. Das macht Docker ja auch.

Mark: Der Docker ist im Prinzip die Satze von Tools, die lassen diese Container laufen.

Mark: Das Container ist abstrahiert von Docker selbst.

Mark: Docker ist eine Firma, der diese Tools entwickelt hat, sodass man es einfach

Mark: laufen lassen kann auf verschiedenen Betriebssystemen.

Mark: Sie mich selber.

Mark: Das ist aber begrenzt auf die eine PC oder die eine Server, wo man gerade drauf ist.

Mark: Das heißt, man kann das starten lokal, man kann die Sachen ausprobieren,

Mark: testen, gucken, ob es tut, was man will und dann das muss dann irgendwie in Produktion.

Mark: Und natürlich, wenn ich mal private Rechner irgendwie zur Produktion stellen,

Mark: so wie sie kundenloggen in Minecraft konkrete Rechner ein, die wollen,

Mark: das wird in einem Server, irgendwo in Cloud gestartet.

Mark: Dieser Container. Das Problem ist, wenn ich ein richtig cooler Software habe

Mark: und ich starte das Container irgendwo in Cloud und am Anfang nur ein paar hundert

Mark: Leute benutzen, das ist okay.

Mark: Aber wenn hunderttausend Leute fangen an zu benutzen, knallt der Server zusammen

Mark: wahrscheinlich unter der Last.

Mark: Und in erster Reihe Kubernetes ist ein Lastverteilungsmechanismus.

Mark: Das heißt, ich kann so viele.

Mark: Servers einbinden in ein Kubernetes-Cluster, wie ich will. also so viele Computers

Mark: einbinden in den Kubernetes-Cluster.

Mark: Und Kubernetes passt auf, dass genug Kopien von meiner Software laufen in Kopien

Mark: von einem Container, sodass alle die Leute gleichzeitig die Software benutzen

Mark: können. So, das skaliert für mich.

Mark: Und wenn ich von 100.000 Kunden auf Millionen Kunden gehe, dann packe ich einfach

Mark: mehr Service rein und Kubernetes skaliert das Große für mich.

Mark: Das ist quasi der praktische Grund für Kubernetes. ist.

Mark: Der zweite Grund, wahrscheinlich relevanter ist hier für die Diskussion,

Mark: ist, es baut sich sein eigenes Netzwerk zwischen diesen Computern.

Mark: So dieses Skalieren passiert auch sehr, sehr sicher.

Mark: Das heißt, man kommt nicht einfach so rein in irgendwelche Computer und irgendwelche

Mark: Container, aber man muss sich einloggen über das sogenannte Ingress.

Mark: Und damit hat man sehr, sehr feinheitliche Kontrolle über wer darf was auf dem System.

Mark: Es ist ein bisschen wie ein Firewall, aber auf einem Service-Level.

Mark: Also man kann sagen, für bestimmte Services können bestimmte Leute das angreifen.

Mark: Es gibt auch das Gleiche wie Egress.

Mark: So bestimmte Containers können nur so bestimmte IP-Adressen schreiben oder lesen.

Mark: Und das heißt, die gesamte Sicherheit ist viel, viel strenger.

Mark: Bestimmte Add-ons, und das geht wahrscheinlich sehr tief her,

Mark: aber bestimmte Add-ons kann man ein Zero-Trust-Architect machen,

Mark: sodass zwischen den Containers, die laufen, auch TLS passiert,

Mark: sodass niemand kann da zwischen die Containers reinkommen.

Mark: Wie gesagt, das gesamte Thema Kubernetes ist läuft seit zehn Jahren und weil

Mark: es immer in Cloud ist, ist es extrem sicher aus diesen verschiedenen Gründen.

Volker: Ich habe mal die Docker-Seite Security Announcements aufgemacht.

Volker: Also wer sich interessiert, docs.docker.com Security Security Announcements,

Volker: packen wir auch in die Shownotes.

Volker: Dort gibt es, das ist spannend, so eine exponentiell steigende Liste an Security Announcements.

Volker: Eins, ich sag mal so, das erste ist so Log4J von 2021, dann kommt Text4Shell

Volker: von 2022 und ich fasse mal zusammen, dann gibt es 2024,

Volker: 434, 2025, 441, 443, 444, 443, 447 und 449.

Volker: Das waren die Docker-Updates, die Security-Updates nur aus 2025.

Volker: Wollen wir das mal extra polieren nach 2026?

Mark: Ich glaube, in erster Runde, was das sagt, ist, wie viele Leute benutzen Docker

Mark: mittlerweile. Weil je mehr Leute das benutzen, desto mehr Leute versuchen das reinzuhacken.

Mark: Das muss man auch hier einfaktoren.

Mark: Aber die Frage ist dann, ist das für die Docker das Toolset von den Firmen-Docker

Mark: oder ist das für die Containers jetzt?

Volker: Also das waren jetzt verschiedene Fixes, wo sie CVEs dann gefixt haben.

Volker: Das habe ich jetzt nicht einzeln nachgeguckt, aber zum Beispiel hier ein NVIDIA-Docker-Container-Toolkit

Volker: wurde dann gefixt und so weiter.

Volker: Also ich glaube, der Super-GAU, der entstehen kann und da gab es Security-Probleme,

Volker: ist, wenn du aus dem Container auf den Host kommst.

Volker: Das sollte ja nie gegeben sein, aber es gab schon welche, da war es möglich.

Mark: Genau. Ja, ein Container ist am Ende, so gesehen, es gibt die Containermechanismus

Mark: selbst, dass sie mir sicher ist, weil es existiert seit über zehn Jahren von Linux.

Mark: Aber es gibt natürlich die Software, die in die Container installiert ist.

Mark: Und wenn die Probleme hat und man findet die entsprechenden Backdoor,

Mark: kann man sich dann raufhacken auf das Host-System, das stimmt.

Mark: Das ist natürlich immer die glaschen sachen immer benutzen containers sondern sichern,

Mark: queller und von und können dass du vertraust weil es ist wie alle unseren software

Mark: wenn es schlecht installiert ist oder es gehackt wird dann kann ein backdoor

Mark: reingebracht würden deswegen kommen wir so was wir machen für unsere software

Mark: wir hoßen das nicht in die offentlichkeit auf Docker Hub, aber wir haben unseren

Mark: eigenen Container-Repo,

Mark: es ist niemand, außer wir kommen dran.

Mark: Aber natürlich die SQL-Server-Repos machen wir nicht selbst,

Mark: das holen wir die neueste Repo vom SQL-Server und die sind unter anderem auf Docker Hub gehostet.

Mark: Wir vertrauen sie ein bisschen, dass sie richtig sind. Aber es sind schon ziemlich

Mark: große Distributionen, so ist es wahrscheinlich sicherer, als irgendwas das kleiner ist.

Volker: Ja, wobei im Docker ist an sich dann eben auch kein Heiligtum oder frei von Fehlern.

Volker: Also beispielsweise das Update 4.43 aus Juli, habe ich jetzt mal hier nebenbei nachgeguckt,

Volker: da fixed sensitive environment variables were included in Docker Desktop,

Volker: allowing potential secret exposure.

Volker: Das heißt, man konnte möglicherweise das jetzt Spekulationen von außerhalb Docker

Volker: über die Systemvariablen, sowas wie Nutzernamen und sonst was auslesen, vielleicht.

Mark: Genau, das war nochmal einer von den Tools. Das ist Docker Desktop,

Mark: der ist für Macs und Windows PCs.

Mark: Benutzen wir nicht wirklich für Produktion, das ist nur für Entwicklung.

Mark: Ja, passiert, da gibt es, das ist wie alle Software, muss man das updaten die ganze Zeit.

Mark: Das ist, die Leute finden was, besonders in dieser hilfreiche Tools.

Mark: Es gibt andere Variationen von Containers, Docker ist die beliebteste und die

Mark: sind sicher in verschiedenen Arten und Weise.

Mark: Ich meine, wenn wir in die Architekturdiskution gehen wollen,

Mark: Das größte Problem mit Docker von der Firma Docker ist, dass das hat einen Daemon,

Mark: der läuft auf deinem Computer und das läuft mit Root Privileges.

Mark: Wenn man einmal sich raushackt, ist man sofort Root auf die Host-Server.

Mark: Andere Versionen von Containerization, die nicht so bekannt sind,

Mark: zum Beispiel Podman, das läuft nicht als Root, das läuft als dein User.

Mark: Das heißt, auch wenn jemand aus dem Container raushakt, landet man in der User-Umgebung

Mark: und nicht in der automatischen Root.

Mark: Das ist immer diese Frage von Bequemlichkeit und Sicherheit am Ende.

Mark: Wie tief in das Rabbit Hole will man verschwinden in der Containerization,

Mark: um noch sicherer zu sein?

Volker: Ich glaube, genau da hast du ein gutes Stichwort gebracht, wodurch ich gleich

Volker: mal vielleicht nicht auf ein anderes Thema, aber ich sage mal eine andere Art

Volker: der Kontinuitisierung umschwenken würde.

Volker: Und zwar wäre das dann die virtuelle Maschine. Also wenn mir Docker innerhalb

Volker: eines Betriebssystems zu unsicher ist, weil ich sage, ich selbst...

Volker: Ich möchte nicht gerne, dass man auf meinem Host direkt arbeiten kann.

Volker: Naja, der oder diejenige muss halt das extrem wählen, dass er halt sein eigenes

Volker: Betriebssystem mitbringt.

Volker: Und das Ganze, das nennt man dann Hypervisor Typ 2.

Volker: Nachher kommen wir noch zu einer sogenannten Hypervisor Typ 1 Lösung.

Volker: Das bedeutet, ich installiere halt erstmal mein Host-Betriebssystem und kapsele

Volker: alles, was ich an Anwendung haben möchte, in einem weiteren Betriebssystem da drin.

Volker: Eigentlich das Betriebssystem meiner Wahl.

Volker: Jetzt wissen wir natürlich, dass unterschiedliche Betriebssysteme verschiedenen

Volker: Ressourcen hungrig sind. Es ist also relativ wahrscheinlich,

Volker: dass man zum Beispiel auf einem Windows-Rechner wohl auch eine virtuelle Maschine

Volker: mit Linux laufen lassen kann.

Volker: Ob man jetzt auf einem grenzwertigen Linux-Rechner eine virtuelle Maschine mit

Volker: Windows laufen lassen kann, ich habe es nie ausprobiert, aber ist vielleicht nicht ganz so klar.

Volker: Aber da hätte man jetzt natürlich den Vorteil, wenn wir das aus der Perspektive

Volker: mal sehen, wir können wirklich irgendeinen Rechner nehmen, der ausreichend viele

Volker: CPU-Ressourcen noch frei hat, um noch ein weiteres Betriebssystem daran laufen zu lassen.

Volker: Und in diesem weiteren Betriebssystem, da hosten wir dann alle Anwendungen.

Volker: Ganz praktisch für, ich sag mal, kleine und mittlere Unternehmen,

Volker: weil dort die, meistens, ich sag mal, so Größenordnung 50 Leute oder sowas,

Volker: die sich kein großes Lager an Computern anschaffen können, die aber auch keinen

Volker: großen Lieferanten haben, der ihnen immer die gleichen Computer liefert.

Volker: Das heißt, sie sind irgendwie so darauf angewiesen, im Gegensatz zu einer 10.000-Personen-Firma,

Volker: die, weiß ich nicht, mit Dell oder wem auch immer einen Servicevertrag machen

Volker: und jetzt fünf Jahre lang immer dieselben Computer für dieselbe Software geliefert bekommen.

Volker: Das heißt, sie können nehmen, was sie kriegen im Mediamarkt,

Volker: Discounter, Aldi oder sonst was, was sie gerade an billigen Computern kriegen

Volker: und installieren dort erst ihre virtuelle Maschine und da drin dann die gesicherte,

Volker: freigegebene Anwendungsumgebung mit Office-Anwendung und Unternehmensanwendung und sonst was.

Volker: Und haben quasi für jede Anwenderin, für jeden Anwender immer das gleiche Erscheinungsbild,

Volker: die gleiche Software, den gleichen Sicherheitsstand, unabhängig von der virtuellen Maschine.

Volker: Problem an der Stelle bei Hypervisor 2-Lösungen ist dieses mit dem doppelten Betriebssystem.

Volker: Wir brauchen natürlich jetzt erstmal grob gesprochen doppelte CPU-Power,

Volker: weil das Betriebssystem im Betriebssystem beides laufen muss.

Volker: Doppelten Speicher, doppelte CPU-Power für ein Betriebssystem,

Volker: das wir so gerade nicht machen.

Monina: Das Problem, das du hier ansprichst mit der doppelten CPU-Power,

Monina: hast du, weil du eine komplette Umgebung als Host-OS hast und das Gast-OS zusätzlich

Monina: laufen lässt, quasi als Hypervisor 2.

Monina: Das spart man sich natürlich, wenn man Hypervisor 1 benutzt.

Monina: Wo ich vorhin eigentlich noch eine Anmerkung einwerfen wollte,

Monina: war zur automatisierten Bereitstellung.

Monina: Das Problem, mehrere gleiche Systeme den Benutzern zur Verfügung stellen zu

Monina: können, kann man zum Beispiel durch automatisierte Bereitstellungen lösen.

Monina: Und dafür würde sich dann eine Lösung mit Ansible und Proxmox beispielsweise eignen.

Monina: Ansible ist ein Open-Source-Konfigurationstool, mit dem könnte man oder kann

Monina: man automatisiert beispielsweise Container oder VMs ausrollen.

Monina: Ansible hat wiederum ein Modul für Proxmox. damit man hier beispielsweise Playbooks

Monina: in BoxMox mehrere VMs automatisiert aufsetzen und starten kann oder auch updaten, verwalten.

Monina: Genau, BoxMox ist ebenfalls Open Source, es ist ein Hypervisor wie beispielsweise VMware.

Monina: Mit dem kann man sowohl KVM-basierte VMs als auch LXC, das sind Linux-Containers,

Monina: als Container laufen, zum Beispiel.

Monina: Also sowohl volle VMs als auch Container. Und das Ganze mit einer hübschen oder

Monina: mehr oder weniger hübschen Web-GUI, da kann man das aufsetzen und verwalten.

Monina: Also das Ganze lässt sich jetzt eben die Hypervisor Proxmox über Ansible automatisieren.

Monina: Damit hat man eine praktische Lösung, die Open-Source ist.

Ingo: Vielleicht können wir noch versuchen, das ein bisschen zu strukturieren gerade,

Ingo: weil ich glaube, wir sind jetzt so ein bisschen von einem Server-basierten Ansatz,

Ingo: also der Frage, wie wir Dienstleistungen im Unternehmen bereitstellen können,

Ingo: zu einem gemischt Server- oder Nutzer-basierten Ansatz, also wie können wir

Ingo: Desktops bereitstellen, gerutscht.

Ingo: Und da würde ich vielleicht noch mal ganz kurz eingrätschen.

Ingo: Wir hatten jetzt ja schon die Diskussion nebenüber Hypervisor 1 und 2.

Ingo: Vielleicht könnt ihr noch mal ganz kurz etwas dazu sagen, was der Unterschied ist.

Volker: Ja, Hypervisor 1 hat man noch nicht.

Volker: Also Hypervisor 1 ist halt die voll Hardware-basierte Virtualisierung.

Volker: Und 2 ist, ich brauche Hardware plus Betriebssystem plus meine Virtual Software.

Volker: Und das ist dann die softwarebasierte.

Volker: Das ist der Kern. Das heißt auf eine Hypervisor 1 Maschine kann ich direkt theoretisch

Volker: ohne Betriebssystem gleich eine Virtualisierung installieren.

Monina: Was ganz spannend ist, Microsoft liefert ja mittlerweile Hyper-V mit den meisten Systemen mit aus.

Monina: Ich glaube auch Windows 10 und 11 haben das normalerweise mit dabei,

Monina: auch in der Ausstattung, mit der man damit arbeiten kann.

Monina: Das ist auch ein Typ 1, halberweise. Und wenn man das benutzt, hat man quasi aber auch,

Monina: trefft man ja direkt auf die Hardware damit zu und hat dann sozusagen das Windows

Monina: selber auch gar nicht mehr so richtig als Host-System, sondern auch eigentlich

Monina: als Gast-System, das auf derselben Ebene läuft, wie das in Anfangszeichen Gast-System,

Monina: was man dann laufen lassen möchte.

Monina: Also sprich, wenn ich jetzt zum Beispiel dann mit Hyper-V irgendwie mehr Ubuntu

Monina: oder Ähnliches laufen lassen wollen würde, würde ich das auf derselben Ebene

Monina: laufen lassen wie in Windows. Aber gerne.

Ingo: Ja, der Vorteil ist ja, dass dann entsprechend die Geschwindigkeit auch höher ist.

Ingo: Durch den Direktzugriff, die Hardware hat man ja oft eine bessere Beschleunigung,

Ingo: als wenn die Befehle eben noch umgelenkt werden über ein anderes Betriebssystem.

Volker: Er hat Vor- und Nachteile. Also wenn wir über Hyper-V direkt arbeiten,

Volker: dann greifen wir halt auf den Prozessor rein.

Volker: Das heißt, dass wiederum die Betriebssystem-Variante unseres Gastbetriebssystems,

Volker: also wenn wir irgendeine Linux-Variante, Ubuntu irgendwas haben,

Volker: mit dem Prozessor auch kompiliert oder arbeiten können muss mit dem Kern.

Volker: Während wenn wir eine Softwarelösung haben, können wir fehlende Prozessorbefehle,

Volker: ich sage jetzt mal irgendwie Hashbildung, lasse ich jetzt auf den Prozessor

Volker: machen, mein alter Prozessor kann es aber nicht, dann kann ich das durch die

Volker: virtuelle Maschine, durch die Software abfangen, was ich bei Typ 1 Zeit nicht kann.

Volker: Wenn er es nicht kann, dann kann er es nicht und dann läuft die Software darauf nicht.

Mark: Ja, ich würde hier kurz einspringen. Die lustige Überlappung oder die Ironie

Mark: ist, dass Docker Desktop, was du vorher erwähnt hast, auf Windows startet tatsächlich

Mark: ein gesamter Virtual Machine,

Mark: um Docker da drin laufen zu lassen, weil Docker ist im Prinzip ein Linux-System-basiertes Sachen.

Mark: Das heißt, wenn man Docker Desktop startet auf Windows und denkt,

Mark: oh, man benutzt Lightweight Containers auf Windows System, tatsächlich startet

Mark: es ein gesamter VM mit Debian drauf, um Docker zu starten.

Mark: Das ist eine interessante Mischung zwischen die beiden da.

Volker: Das ist krass, das wusste ich noch gar nicht. Ich dachte echt,

Volker: Lightweight, also ich kann mir den ganzen Kram ja sparen mit Docker.

Volker: Kann ich ja gleich VirtualBox installieren.

Ingo: Nee, du kannst dir die Sachen mit dem Windows sparen und lieber auf Linux setzen.

Ingo: Das ist eigentlich die richtige Konsequenz davon. Aber wie sieht denn das bei Mac aus?

Mark: Mac bin ich nicht so sicher. Theoretisch, weil Mac ist Unix.

Mark: Aber Windows auf jeden Fall habe ich vorher benutzt.

Mark: Und um doch gekonplettnissen zu

Mark: starten, hat es eine ganze Virtual Machine gestartet. Das war ganz lustig.

Volker: Ich frage mich immer, wenn ich so einen angebissenen, ablängenden Gegend liegen

Volker: lasse, schimmelt der dann nicht schneller? Okay, sorry.

Ingo: Nicht so schnell wie bei gutem Wind das Fenster klappert. Also von daher,

Ingo: das hat alles seine Vor- und Nachteile, würde ich mal sagen.

Ingo: Was ich nur spannend finde, so von der Gedankenwelt her, wir hatten ja vorhin

Ingo: schon ein bisschen über Security auch gesprochen und Marc hat ja gesagt,

Ingo: dass es diese Probleme auch gibt, mit welchen Docker-Container man quasi sich

Ingo: installiert und man da auch ein bisschen dem Entwickler oder dem,

Ingo: der den Container konfiguriert hat,

Ingo: vertrauen muss. Ich denke, das ist noch ein Punkt, den man nicht vernachlässigen sollte.

Ingo: Im privaten Umfeld, in dem sehr viele dynamische oder schnell verfügbare Container

Ingo: genommen werden, irgendwas ausprobieren zu Hause, holt man sich da schnell auch

Ingo: einfach Software rein, wo man gar nicht weiß, was da passiert.

Ingo: Und wenn wir jetzt an KMUs denken, eine typische Form zum Beispiel jetzt Nextcloud

Ingo: zu installieren, ist ja auch einfach auf dem Docker-Container zu installieren,

Ingo: auf irgendeinem Host-System wie ein Android-System, also wenn man auf dem NAS oder sowas arbeitet,

Ingo: das ist aber immer etwas intransparent, also diese Frage, wie eben der Docker-File

Ingo: sich dann zusammensetzt, natürlich kann Experte reinschauen,

Ingo: aber es braucht irgendwo Expertenwissen, um es dann zu kontrollieren.

Mark: Klar, aber auf der anderen Seite hast du auch eine begrenzte Menge von Sachen, das du vertraust.

Mark: Der eine große Unterschied zwischen Containers und Virtual Machines.

Mark: Virtual Machines hast du meistens eine große Maschine, wo viele verschiedene Software draufläuft.

Mark: Du kannst es anders machen, aber so ist es.

Mark: Bei Containers, und deswegen sind sie auch die Basis von Microservices zum Beispiel,

Mark: kann man sehr kleine Stücke Software individuell laufen lassen.

Mark: Und weil sie isoliert sind, auch wenn ich zehn Containers habe und alle mit

Mark: einem kleinen Stück Software drauf, wenn eins kaputt ist oder gehackt ist,

Mark: nur diese ist kaputt und nicht die anderen neun, gehen wir davon aus,

Mark: dass die Hackers nicht auf mein Host-System kommen können.

Mark: Man begrenzt die Auswahl quasi zu nur einem Stück Software, nicht das gesamte

Mark: Machine oder das gesamte Virtual Machine.

Ingo: Wenn ich jetzt aber beim Docker reinschaue, ich habe mehrere Docker in einem

Ingo: also in einem Environment, da habe ich mehrere Docker-Container laufen.

Ingo: Wie gefährlich, wie gefährdet sind die Container untereinander?

Ingo: Also wie stark kann man von einem Container auf den anderen Container zugreifen?

Mark: Eigentlich alles ist kontrollierbar, wie weit man gehen will, sozusagen. Das ist,

Mark: grundsätzlich und das ist ein, grundsätzlich ist das System in sich selbst sicher.

Mark: Wenn ein Container, wenn ein Software innerhalb eines Containers greift auf

Mark: Loco-Host, dann sieht er nur seine Container.

Mark: Und das ist sehr, sehr wichtig. Das ist die Hauptfehle, das die meisten Anfänger

Mark: machen. Die glauben, ich habe ein Stück Software, das läuft auf Loco-Host.

Mark: Diese Containers laufen alle auf Loco-Host.

Mark: Deswegen kann ich einfach auf Loco-Host greifen. Können sie nicht.

Mark: Von der Sicht von innerhalb des Containers ist das Containers gesamte Computer,

Mark: inklusive Netzwerk und alles.

Mark: Alles andere sind anderen Computers irgendwo anders in der Welt.

Mark: Das heißt, das ist auch normal, man muss explizit auf die anderen Containers

Mark: darauf zugreifen, dann muss man dann wissen, wo sie sind, quasi wie sie heißen

Mark: und so weiter und so fort.

Mark: Und das ist auf die Abstraktionslevel von das Host-System. Das kann der Container

Mark: selbst nicht herausfinden.

Mark: Das heißt, wenn ich ein Virus bin oder ein Hacker innerhalb eines Containers,

Mark: ich weiß ehrlich gesagt nicht, ob ich in einem Container bin oder ob ich auf

Mark: einer Virtual Machine bin oder ob ich auch eine echte Machine bin.

Mark: Die sehen alle gleich aus, von wo ich sitze.

Mark: Das heißt natürlich, das begrenzt die Angriffsfläche, die ich habe.

Mark: Alles steht ohne Prinzip, das Docker ist richtig installiert und die kann ich

Mark: rausbrechen durch verschiedene Tricks.

Ingo: Ja, nicht nur Tricks, auch Dummheit der Anwender, dass man nicht die falschen Dinge freigibt.

Ingo: Also man braucht für einige wenige Container ja auch mal privilegierte Rechte,

Ingo: wenn man so ein Support-Hainer oder so etwas hat, also wenn man eine gewisse

Ingo: Art von grafischer Oberfläche für die Administration der Container hat.

Volker: Da sehe ich im Übrigen auch noch ein weiteres Problem.

Volker: Also mal ab, ich würde ungern hier von Dummheit der Anwenderinnen sprechen.

Volker: Manchmal ist es auch Dummheit, gebe ich zu. Also man macht Dinge,

Volker: von denen man weiß, dass man sie nicht tun sollte.

Volker: Aber zum Beispiel, ganz kritisch sind ja immer die Netzwerkeinstellungen.

Volker: Also ich gehe jetzt mal wieder zurück in so eine Typ 2 virtuelle Maschine,

Volker: die ja auch ganz gern genommen wird, um Malware zum Beispiel auszuprobieren

Volker: oder forensisch zu sichern oder sonst irgendwas.

Volker: Und wenn ich in diesem Malware-Container jetzt falsche Netzwerkeinstellungen

Volker: gewählt habe, zum Beispiel nutze das Host-Netzwerk, ja wunderbar,

Volker: besser kann ich doch meinen Rechner gar nicht für die Malware freigeben,

Volker: um den gleich mit zu verschlüsseln.

Volker: Und da bin ich mir überhaupt nicht sicher, wie funktioniert denn das unter Docker?

Volker: Also hat ein Docker eine eigene Pipeline, womit es quasi Befehle wie ein Betriebssystem

Volker: auch austauschen kann oder nutzt es die offizielle Netzwerkfade oder, Marc, erzähl mal.

Mark: Das ist komplett konfigurierbar. Du weißt ja dein eigener Schicksal.

Mark: Die Standard-Default-Einstellung ist, dass alle die Containers laufen auf ein erseuten Netzwerk.

Mark: Das hat nichts zu tun mit dem Netzwerk von dem Host-System. Das heißt,

Mark: es ist alles komplett getrennt.

Mark: Man kann, es hat natürlich, das macht die Sachen schwer darauf hinzugreifen,

Mark: ganz viele Leute sagen, okay, dann linke ich das zu den Localhost,

Mark: und dann fangen natürlich diese Probleme dann an, weil wenn das Localhost auch,

Mark: und das ist so das Hostrechner jetzt,

Mark: dann hat man das Problem, aber theoretischerweise kann man komplett getrennte

Mark: Netzwerke bauen und das ist in

Mark: sogenannten Namespaces so in Linux kann man verschiedene Namespaces haben,

Mark: dann sind nicht nur die Netzwerke getrennt, aber auch die Ressource-Gruppen und so weiter.

Mark: Das heißt, auch wenn jemand versucht, einen Denial-of-Service-Attack,

Mark: das ist bestimmt deine nächste Frage, Volker, auf meine Container zu machen,

Mark: Der Container kann hochlaufen und ordentliche Sachen tun, aber er hat nur diese

Mark: begrenzten Ressourcen innerhalb des gesamten Host-Systems.

Mark: Das heißt, man hat ein feinfühliges Gefühl, kann man alles einstellen oder das

Mark: Default lassen, aber das ist natürlich, wo es gefährlicher wird,

Mark: für einen Otto-Verbraucher benutzen, das wirklich schnell einzustellen und hoffen,

Mark: dass es alles richtig ist. Das ist schon ein komplexes System.

Volker: Ja, danke. Da nochmal für das

Volker: Stichwort, Denial-of-Service, wäre ich tatsächlich noch drauf gekommen.

Volker: Weil ja theoretisch ein Denial-of-Service auf eine virtuelle Maschine,

Volker: theoretisch auch ein Denial-of-Service auf den gesamten Rechner ist.

Volker: Und wenn wir jetzt so einen Virtualisierungsserver haben, so theoretisch,

Volker: naja, ich sage mal erstmal nicht so schön aufgesetzt als Typ 2,

Volker: also als Software-Virtualisierung,

Volker: dann könnte ich ja theoretisch mir so viele Ressourcen mit dieser einen Software

Volker: nehmen, dass die anderen schon gar nicht mehr zum Zug kommen.

Volker: Also klar, ich weiß, es gibt Umgehungsmöglichkeiten, Aber Marc,

Volker: was würdest du da jetzt so sagen?

Mark: Nochmal genau das Szenario.

Volker: Also Denial of Service. Ich habe jetzt meinetwegen einen Web-Server auf einer

Volker: eigenen virtuellen Maschine, weil ich den auch security-seitig mit so einer

Volker: fiktiven, demilitarisierten Zone gegenüber anderen Diensten trennen möchte.

Volker: Ich mache also einen Web-Server, der direkt ein offenes Web-Interface über eine

Volker: Firewall hat, auf eine virtuelle Maschine.

Volker: Dieser Web-Server kriegt jetzt einen Denial of Service. und damit zieht er sich

Volker: ja theoretisch erstmal alle Ressourcen, die der Rechner zur Verfügung hat.

Volker: Und die stellt dieser Rechner den anderen virtuellen Maschinen,

Volker: zum Beispiel meiner SQL-Umgebung oder sowas, nicht mehr zur Verfügung.

Mark: Nein, nein, nein, nein. Beides in normaler Docker, aber auch besonders in Kubernetes,

Mark: das begrenzt man die Anzahl von CPUs und Rahmen und alles, das jedes Service

Mark: oder jeder Container hat zur Verfügung.

Mark: Das heißt, man kann,

Mark: Sollte die Web-Server begrenzen auf, was weiß ich, 1 GB, wenn der Host-Server

Mark: hat 6 sind, dann sollte der Rest laufen wie immer.

Volker: Okay, jetzt bin ich aber mal der junge Junior-Systemadministrator und sage,

Volker: komm, wenn mein Rechner vier CPUs hat und 16 Gigabyte an Speicher,

Volker: dann lasse ich vielleicht nochmal eine Reserve-CPU,

Volker: in Klammern funktioniert eigentlich gar nicht von diesem CPU-Ansatz,

Volker: weil nicht jede CPU durch jeder Kern das gleiche kann, aber egal,

Volker: ich lasse schon von vier Kern, lasse ich mal einen für das Host-Betriebssystem

Volker: und ich sage mal von 16 Gigabyte, die mein Rechner an RAM hat,

Volker: die gebe ich einfach mal zwölf jetzt frei für alle Container.

Volker: Also jeder Container kriegt drei CPUs und zwölf Gigabyte, damit er sich wohlfühlt

Volker: und der soll sich einfach nehmen, was er kann.

Volker: Was würdest du zu so einem Junior-Administrator sagen?

Mark: Ja, nicht eine gute Idee. Genau passiert in den All-of-Service-Zeiten,

Mark: was du vorher erwähnt hast.

Mark: Man soll immer jeder Service oder jeder Container begrenzen,

Mark: auf was diese Container maximal braucht in sinnvoller Art und Weise.

Mark: Und wenn man wirklich nicht weiß, wie viele Leute auf diese Web-Server aufkommen,

Mark: weil man weiß nicht vom Gefühl, es kann sein, dass Services plötzlich,

Mark: ich habe von Online-Firmen gehört, wo sie gebaut haben für 1.000 Leute und haben

Mark: trotzdem 10.000 Leute bekommen in den folgenden Wochen, weil die haben erfolgreiche

Mark: Marketing gemacht oder irgendwas.

Mark: Dann soll man auf skalierende Lösungen kommen wie Kubernetes,

Mark: wo die Sachen einfach skaliert werden mit genug Kapazität.

Mark: Aber auf einen Einzelrechner, Computer oder Host-Server, das ist schwer,

Mark: sowieso diese Kalkül zu machen.

Volker: Und wie stehst du zur Nutzung von GPUs?

Volker: Weil in der Regel habe ich ja keine, also wieder, ich denke an das mittelständische Unternehmen.

Volker: Ich habe mal einen tollen Server, ich habe dafür 10.000 Euro ausgegeben und

Volker: da ist auch eine Nvidia Grafikkarte drin.

Volker: Und ich mache einfach mal das Häkchen bei GPU freigeben.

Volker: Bei allen virtuellen Maschinen. Was sagst du dazu?

Mark: Wahrscheinlich nicht so gut. Ich habe, ehrlich gesagt, keine GPUs freigegeben

Mark: in die Vergangenheit. Deswegen kennen wir nicht so aus da.

Mark: Das ist auch ein Vorteil für Kubernetes, dass der Volk schon eine Lösung ist.

Mark: Man kann eine sogenannte Node oder eine Server haben in der GPU drin und das

Mark: kann dann freigeben werden für GPU Services, die brauchen ein GPU,

Mark: weil nicht alle Services brauchen ein GPU.

Mark: Das ist wahrscheinlich, was weiß ich, Machine Learning Sachen,

Mark: vielleicht, wenn man irgendwelche Grafikgenerationen hat.

Mark: Und dann Kubernetes packt nur auf diese Node die Services, die das wirklich

Mark: brauchen. Und die bleiben auf die anderen Nodes.

Mark: Wenn man versucht, das alles auf dem gleichen Hostrechner zu machen,

Mark: mit einer großen Anzahl von Leuten, die es gleichzeitig benutzen,

Mark: dann sollte man überlegen, seine grundsätzliche Systemarchitektur, was man da macht.

Monina: Ich hätte noch eine Frage zu dem Punkt vorher mit einzuhaken,

Monina: wie wir waren, zu Malware, die in Containern teilweise läuft oder laufen möchte.

Monina: War das nicht oder hat da jemand Erfahrung, dass Malware früher zumindest oft

Monina: auch oder Software generell geprüft hat, ob sie in der VM läuft?

Monina: Anhand von verschiedenen Merkmalen, auf was sie zugreifen kann,

Monina: also gerade auch Grafik zum Beispiel oder andere Parameter vom System,

Monina: um gegebenenfalls, wenn sie in der VM läuft, gar nicht erst zu starten,

Monina: weil oft ja gerade Malware-Analysten Schadsoftware in der VM oder in irgendwelchen

Monina: Containern testen, also schauen, was die tut.

Mark: Ich hatte ein paar Sachen gelesen, aber es ist total schwer zu sehen,

Mark: ob du in einem Container bist als Vios-Software.

Mark: Meistens kann man das raten, weil es nicht so viel installiert ist.

Mark: Wenn der Container richtig gebaut ist, dann hat es kein volles System oder irgendwas.

Mark: Hat man nicht ein Debian zum Beispiel, man hat ein Alpine Linux als Basis.

Mark: Das ist viel, viel kleiner, wenn die Angriffsfläche.

Mark: Aber es ist alle diese Nebenbei-Sachen, dass man sieht.

Mark: Das ist nicht so, man kann nicht fragen, bin ich in einem Container?

Mark: Und dann gibt es irgendwelche Antwort dazu. Das könnte auch ein Wasp Repay sein.

Volker: Ja, es gibt einen Trick, tatsächlich, es gibt wahrscheinlich mehrere Tricks.

Volker: Ich bin jetzt nicht der super erfahrene Malware-Entwickler, leider.

Volker: Sonst würde ich wahrscheinlich mein Geld mit anderen Dingen verdienen.

Volker: Es ist immer die Frage des Stundensatzes. Es ist nur zehn Jahre Gefängnis,

Volker: was kosten die an Stundensatz? Und wenn nachher 100 Millionen dabei überbleiben,

Volker: Okay, lass mal diese Kalkulation.

Volker: Vielleicht kann Christian die auch rausschneiden, wenn nicht, dann nicht.

Volker: Okay,

Volker: allen wird gleich klar sein, wenn sie das hören, warum wir alle lachen und Christian

Volker: Graf im Kopf geschüttelt hat, dass das nicht rausschneidet.

Volker: Na gut, nee, ein Trick ist tatsächlich, dass die Malware die Pause-Taste in

Volker: der virtuellen Maschine bedient, die sie beim richtigen Rechner nicht bedienen kann.

Volker: Und wenn sie vorher einen Ping auf den C2-Server sendet, die Pause-Taste bedient

Volker: und quasi schon bestimmte Zeiten Timeout macht und dann misst,

Volker: wie lange die Timeout auf dem C2-Server war, dann weiß sie,

Volker: dass sie auf einer virtuellen Maschine ist, weil sie diese Pause-Taste bei einem

Volker: richtigen Rechner nicht bedienen könnte.

Monina: Ich bin mir ein, es gab auch noch ein paar mehr Parameter. Allerdings ist das,

Monina: dass ich mich mit dem Thema beschäftigt habe, ein bisschen länger her.

Monina: Das heißt, die Informationen sind nicht mehr aktuell.

Monina: Aber es hätte mich interessiert, ob es jetzt noch mehr aktuelle Maßnahmen gibt.

Volker: Und du verdienst dann Geld jetzt auch anders, ne?

Ingo: Wir wollen ja nicht über die Details sprechen, was Regierungsständen alles tun.

Ingo: Regierungsinstitute, öffentliche Institute tun.

Monina: Um aus der Sicht der Angriffserkennung zu verstehen, was Angräufer tun,

Monina: muss man ja auch wissen, was Angräufer tun. Das heißt, man braucht ein Verständnis dafür, was passiert.

Monina: Logischerweise.

Volker: Ingo, du hattest vorhin noch ein Thema, das du angeschnitten hast.

Volker: Wollen wir das in die Shownotes bringen oder passt das noch?

Volker: Sorry für die Unbrechung.

Ingo: Ich würde vielleicht das mit einem zweiten Thema noch zusammenbinden.

Ingo: Es ging mir vorhin darum, dass bei Docker es zwar eine sehr niedrige Einrichtigstufe

Ingo: gibt, man kann sehr schnell einen Docker-Container starten, man hat sehr schnell

Ingo: auch komplexe Anwendungssysteme mit Abhängigkeiten dargestellt,

Ingo: aber man muss sich schon ein bisschen auch damit beschäftigen,

Ingo: was eigentlich Docker wirklich tut und wie man mit Docker dann noch umgeht.

Ingo: Also es gibt zum einen Möglichkeiten, privilegierten Zugang für Docker-Container

Ingo: zu ermöglichen mit Optionen, die man beim Starten einrichten kann.

Ingo: Und man kann auch Zugriffe geben auf den sogenannten Docker.soc,

Ingo: mit dem man eben auch die Steuerung von dem Docker-Container zum Teil mit übernehmen kann.

Ingo: Und das sind Dinge, die man nicht tun sollte, wenn man nicht weiß,

Ingo: dass man genau eine Software hat, die genau das braucht, weil sie eine Oberfläche

Ingo: für den Docker-Container, also für dieses Docker-System dann auch ist.

Ingo: Also da sollte man sehr, sehr vorsichtig sein mit solchen Dingen,

Ingo: mit Anleitungen, die im Netz rumfliegen, dass man eben mal schnell damit etwas sehen kann.

Ingo: Und das andere ist, was ich eigentlich beim Docker noch spannend finde,

Ingo: aber was eben auch eine gewisse Grundkomplexität erzeugt, man sollte sich sehr

Ingo: intensiv mit den Netzwerkmöglichkeiten von Docker beschäftigen,

Ingo: weil man die Möglichkeiten hat,

Ingo: über die Netzwerkkonfiguration eines Containers sehr stark zu beeinflussen,

Ingo: inwieweit Malware überhaupt sich auswirken kann oder nicht.

Ingo: Also man kann den Netzwerkerzugang vollständig sperren, man kann einem Container

Ingo: eine eigene MAC-Adresse zuweisen, Man kann mit einem Host-System interagieren,

Ingo: also dass man den direkten Netzwerk-Stack vom Host benutzt.

Ingo: Man kann eine Bridge installieren. Also es gibt alle möglichen Formen,

Ingo: wie eben genau dieser Container interagieren kann mit der Netzwerkschnittstelle.

Ingo: Und das beeinflusst sehr, sehr stark, glaube ich, die Frage,

Ingo: ob ich einen exponierten und angreifbaren Container habe oder ob er eher etwas

Ingo: zurückhaltend dann auch ist.

Ingo: Ich würde ganz gerne noch kurz so einen Seitendreh zu dem treiben,

Ingo: was Monina vorhin gesagt hat.

Ingo: Wir hatten ja vorhin kurz über Boxmox gesprochen, beziehungsweise das angesprochen.

Ingo: Interessanterweise ist im Privatbereich ist Proxmox und Docker sehr stark in

Ingo: Konkurrenz zueinander bei Proxmox baut man ja eigene Server auf also man hat

Ingo: einen Hypervisor für das Gesamtsystem installiert in diesem dann weitere,

Ingo: Container oder eben auch.

Ingo: Virtual Machine oder Container und kann an dieser Stelle dann,

Ingo: verschiedene Rechner auf einen Rechner zusammenführen, die jeweils wie ein eigener

Ingo: Server zu konfigurieren sind.

Ingo: Also es macht es einfach, wenn man eine bestimmte Anleitung hat für irgendeine

Ingo: Software, die man serverbasiert zur Verfügung stellen möchte und sich nicht

Ingo: damit beschäftigen möchte, wie ein Docker-File aussieht oder wie man sowas in

Ingo: einem Docker-File dann entsprechend aufbereiten müssen, nur dass es eben keinen

Ingo: Docker-Container dazu gibt.

Ingo: Man hat das Gefühl, dass man damit mehr Freiheiten hat, obwohl es grundsätzlich

Ingo: für die Ausführungen von den meisten Dingen, die man damit wirklich realisiert,

Ingo: eigentlich sehr vergleichbar auch wiederum ist.

Ingo: Aber das ist auch so eine Methode, die man da gut nutzen kann.

Ingo: Und ich denke, das sollte man auch im Kopf haben, dass man diese unterschiedlichen

Ingo: Virtualisierungsmöglichkeiten und Kontinuierungsmöglichkeiten miteinander vergleicht

Ingo: und versucht herauszufinden, was dann gute oder schlechte sind.

Ingo: Weil doch der Aufwand des Supports, die Möglichkeiten, kostenpflichtigen Support

Ingo: auch einzukaufen, auch sehr unterschiedlich sind von diesen verschiedenen Systemen.

Monina: Da möchte ich nochmal einen ganz kurzen Abstecher noch machen,

Monina: um noch eine weitere Option einen Ring zu werfen, so jetzt sich zu hier quasi

Monina: einer Orchestrierung von mehreren VMs oder Docker oder Ähnlichem.

Monina: Wenn man tatsächlich nur eine VM oder ein Gastsystem braucht,

Monina: um unter Windows ein Linux zu testen, gibt es mittlerweile ja auch noch eine

Monina: recht spannende verbreitete Option,

Monina: die vorhin mal kurz schon viel, nämlich WSL, das Windows-Subsystem für Linux.

Monina: Mittlerweile gibt es das in Version 2 und ist, wie gesagt, on board bei den

Monina: meisten Windows-Systemen.

Monina: Da hat es sich irgendwann mal Microsoft mit Canonical, also mit Ubuntu,

Monina: drauf geeinigt oder verständigt.

Monina: Und das ist ganz spannend. Das ist mit Hyper-V ein vollständiger Linux-Kernel,

Monina: zumindest wenn man WSL 2 und nicht WSL 1 nimmt, der leichtgewichtig,

Monina: ich glaube, sogenannten Lightweight Utility VM in einem Windows läuft.

Monina: Das heißt, man kann relativ easy unter Windows Linux-Funktionen testen.

Monina: Hat den Vor- und Nachteil, also es ist kein ganz abstrakter Container,

Monina: sondern man hat den Vorteil, dass man mit dem Linux auch im Windows-Dateisystem mit rumvorwerken kann,

Monina: halt mit Linux-Befehlen, was nett ist, um das zu testen, um ein paar Linux-Funktionen

Monina: auszuprobieren und da das eine oder andere zu benutzen,

Monina: aber hat natürlich auch jeglichen Nachteil oder entbehrt jeglichen Vorteilen,

Monina: dass man ein getrenntes Dateisystem und ein getrenntes System hat.

Monina: Aber das ist für den einen oder anderen Benutzer vielleicht nochmal eine noch

Monina: leichtgewichtigere Methode, Nino's zu benutzen.

Monina: Und wie gesagt, es ist ein Typ 1, Hyper-V, also Typ 1-Virtualisierung.

Monina: Sprich, das greift auch dann direkt da an Windows vorbei auch auf die Hardware zu.

Monina: Genau, das wollte ich der Vollständigkeit halt halber hier nochmal mit einwerfen,

Monina: weil das ja vielleicht für den einen oder anderen auch eine spannende Alternative

Monina: ist. Es funktioniert mittlerweile auch tatsächlich sehr gut.

Volker: Ich habe es tatsächlich auch mal genutzt, bin dann aber wieder von abgegangen,

Volker: weil mir, also was ich nicht machen konnte, waren so ein bisschen Speichermanipulationen.

Volker: Es ist natürlich jetzt, ja, es ist genau das, was eigentlich nicht sein soll.

Volker: Aber wenn man halt Malware-Mechanismen nachstellen will, dann muss man ja bestimmte

Volker: Begrantbedingungen erstmal schaffen, um zu gucken, ob das geht.

Volker: Und ich dachte halt, genauso wie du gesagt hast, das wäre ein Typ 1.

Volker: Das heißt, ich hätte ein vollwertiges Ubuntu da drunter und könnte halt bestimmte

Volker: Dinge ausschalten, einschalten, wie, keine Ahnung, Address-Based Randomization

Volker: und solche Sachen alles.

Volker: Und das ging aber nicht. Also da hat mich dann quasi wieder irgendwie die Windows-Sicherheit

Volker: daran gehindert, dass ich diese Rechte, diese Privilegien nicht auf dem Liedungssystem

Volker: hätte, was ja diesem Typ 1 eigentlich widerspricht.

Volker: Also ich bin mir da nicht ganz sicher, wie sauber das implementiert ist.

Monina: Es gibt ja wunderbare Grafiken, weil der WSL-Teil ja zumindest Open-Source und

Monina: relativ gut dokumentiert ist. Also das kann man sich auch sehr schön anschauen.

Monina: Da gibt es andersrum natürlich auch wieder andere Szenarien,

Monina: dass man unter dem WSL-Linux dann vielleicht wiederum was ausführen kann,

Monina: was das Dateisystem manipuliert, was unter Windows eingeschränkt ist.

Monina: Aber das ist jetzt, glaube ich, ein Bogen, der relativ weit führt.

Ingo: Wir reden hier über einen Systemkontext, wenn wir über Virtualisierung und Kontinuisierung sprechen,

Ingo: der sehr essentiell ist für die Infrastruktur von einem Unternehmen und der

Ingo: sehr tiefe Möglichkeiten auch in das Unternehmensnetzwerk erlaubt und natürlich

Ingo: auch die Gefahr immer enthält,

Ingo: dass man sich die Produktivität oder auch die Arbeitsfähigkeit des Unternehmens einschränken kann.

Ingo: Das heißt also, so viele Anleitungen ihr auch im Internet seht zu den Containern,

Ingo: die man auch schnell installieren kann, Nextcloud, die man vielleicht innerhalb

Ingo: von 15 Minuten mit einem kleinen Video aufbauen kann in einem Docker-Container,

Ingo: sobald es um Produktivsysteme geht, die ihr damit Geld verdient,

Ingo: in Unternehmen das Ganze nutzen wollt.

Ingo: Bitte entweder habt selber Kompetenz, eignet euch die Kompetenz an oder kauft sie euch ein.

Ingo: Also beschäftigte Unternehmen wie das Unternehmen von Marc, das eben wirklich

Ingo: dann auch spezialisiert darauf ist, zu unterstützen und zu entscheiden,

Ingo: welche Art von Virtualisierungskontext oder welche Art von Virtualisierungssystem

Ingo: ist für euren Zweck eigentlich das Richtige.

Ingo: Also nicht mal ganz kurz, das Docker ist besonders günstig, hat relativ einfache

Ingo: Skalierbarkeit mit den Containern.

Ingo: Man hat ein bisschen Könnenrisiken, aber nicht wirklich schlimm.

Ingo: Man kann es gut einsetzen.

Ingo: Bei Kubernetes hat man die Software gratis, muss aber mit der Orchestrierung

Ingo: schon auch ein bisschen gucken, wie es genau funktioniert.

Ingo: Hat eine ganz gute Sicherheitsarchitektur dabei. Man kann über VirtualBox sprechen

Ingo: oder über VMware sprechen.

Ingo: Bei VMware hat man teure Container, schon teure Lizenzen, die man kaufen muss,

Ingo: muss Support haben, hat aber dafür natürlich eine wahnsinnig gute Sicherheit

Ingo: und teilweise auch gute Nutzbarkeit im sehr großen professionellen Umfang.

Ingo: Und auch Poxmox als Open Source ist zwar erstmal kostenlos, aber wenn man es

Ingo: im Unternehmenskontext nimmt, gibt es kostenpflichtige Update-Strategien dafür.

Ingo: Mit denen man eben bestimmte Update-Server benutzen kann, die sonst nicht zur Verfügung stehen.

Ingo: Also man sollte sich sehr genauer damit auseinandersetzen und eben wirklich

Ingo: schauen, dass man für das Unternehmen das Richtige findet.

Ingo: Wenn man an dieser Stelle Fehler macht, kann es passieren, dass es dann später

Ingo: sehr, sehr teuer zu stehen kommt.

Mark: Ich würde auch, das ist alles richtig, ich würde auch eine Sache dazu sagen,

Mark: weil wir haben nicht drüber gesprochen, weil es nicht wirklich Thema ist,

Mark: wahrscheinlich von Sicherheitslücke,

Mark: aber die Backups und Speicherung von Daten, die meisten Containers starten mit

Mark: den eigenen Daten in den Container selbst und man muss das explizit auf der Festplatte,

Mark: das echte Festplatte jetzt, speichern lassen.

Mark: Wenn man das nicht macht, wenn man ein Update von einem Container macht,

Mark: löscht man dann seine gesamte Daten.

Mark: Und das ist auch nicht, was man haben will. Deswegen muss man echt aufpassen

Mark: hier bei Persistenz und Daten, Backups und alles mit Containers.

Mark: Das ist ein sehr komplexes Thema, das sehr schnell schief geht,

Mark: wenn man einfach ein Tutorial aus dem Web nimmt und versucht, das schnell zu starten.

Mark: Man startet das, scheint alles zu laufen, bootet sein Computer neu und plötzlich

Mark: ist die ganze Daten weg, im schlimmsten Fall. Und deswegen entweder Fida lernen,

Mark: seine Chat-GPT-Fragen oder noch besser Hilfe reinholen.

Volker: Ja, hier noch. Ich habe die Welche.

Monina: Aber vorsichtig. Wenn das mit falschen Informationen lernt, deinem Stack-Overflow

Monina: zusammenfasst, dann hat man natürlich auch falsche Informationen, die man bekommt.

Mark: Das war nicht ernst gemeint, ja.

Volker: Ja, aber tatsächlich, Marc, da hast du noch eine große Sicherheitslücke angesprochen,

Volker: die wir zumindest einmal wenigstens andeuten sollten bei Containerisierungslösungen.

Volker: Wenn ich explizite, einfache Software habe oder separate Software-Module und

Volker: ich bekomme einen großflächigen entweder Wiping-Angriff oder Ransomware oder

Volker: sonst was, die müssen ja alles einzeln verschlüsseln.

Volker: Das heißt sozusagen, meine Betriebsfähigkeit ist langsam stückweise weg,

Volker: je nachdem, wie viel Daten sie verschlüsseln.

Volker: Wenn die bei einer Virtualisierungslösung auf die Stufe da drüber kommen, nämlich meinen Host,

Volker: und die fangen an, meinen Host zu verschlüsseln, ist mit der ersten Scheibe,

Volker: dem ersten Byte, dass die anfangen zu verschlüsseln von meiner virtuellen Maschine,

Volker: ist meine gesamte Umgebung tot.

Volker: Und das ist natürlich nochmal nicht ein erhebliches, aber ein bedenkenswertes

Volker: Risiko, dass ich mir einkaufe, wenn ich mit Containern anfange.

Volker: Der Container ist faktisch erstmal eine Software an sich.

Volker: Und sobald auch nur ein Byte von dieser Software, Na gut, da sind auch noch

Volker: Sicherungslösungen drin, aber ich sage jetzt mal, wenn ein Byte von der Software

Volker: defekt ist, dann ist die Software defekt.

Volker: Das wollte ich nochmal mit reinwerfen, auch nochmal als Überlegung Pro und Contra,

Volker: wobei mich das jetzt nicht abhalten würde, an eine Kontinuitisierungslösung zu gehen.

Volker: Ja, und damit würde ich schon zusammenfassen...

Volker: Wir haben heute das Thema Kontinuitisierungslösungen betrachtet aus der Sicht

Volker: von kleinen und mittleren Unternehmen.

Volker: Das ist durchaus eine sinnvolle Variante oder Alternative zu einer,

Volker: ich sage mal On-Premise, On-Premise wäre jetzt falsch, einer lokalen Rechnerlösung ist.

Volker: Weil die lokalen Rechner muss

Volker: ich alle einzeln warten und in ihren Softwarebestandteilen aktuell halten.

Volker: Während ich bei einer Kontinuitisierungslösung quasi die automatischen Updates

Volker: eines sonst blank installierten Rechnerbetriebssystems nutzen kann.

Volker: Also im Prinzip lauter Automatismen, um die ich mich als Administrator oder

Volker: Administratorin nicht kümmern muss.

Volker: Und obendrauf habe ich dann halt irgendwie meinen Container und in dem Container

Volker: ist die Software, die ich dann nur einmalig sicher halten muss und dann auf

Volker: die ganzen Hosts verteile.

Volker: Und mit Kontinuitisierungslösungen hatten wir im Prinzip drei Ebenen.

Volker: Die eine Ebene ist Docker als Docker.

Volker: Ein eigenes System im Betriebssystem, das sich aber eigentlich dem Betriebssystem

Volker: oder des Betriebssystems bedient.

Volker: Das heißt, eigentlich leichtgewichtige Lösungen sind.

Volker: Jetzt haben wir von Marc gelernt, dass Docker schon gleich seine ganze virtuelle

Volker: Maschine unter Windows mitbringt, damit es unter Windows Linux starten kann

Volker: und in diesem Linux dann wieder ein Docker gestartet wird und so weiter.

Volker: Also vielleicht hätte man dann auch einfach mal WSL nutzen können oder Hyper-V,

Volker: aber sei es, darum ist egal.

Volker: Also es ist auch nicht alles so, wie es nur scheint, offensichtlich.

Volker: Vorteil von Docker ist dann dass man über Kubernetes oder Proxmox oder sonst

Volker: was noch das ganze skalieren kann also mehrere Container ausrollen,

Volker: ich kann Loadmanagement machen automatisiertes und so weiter das heißt Docker

Volker: ist schon eine schöne Alternative um solche Systeme auf mehreren Rechnern auszurollen

Volker: die nächst stärkere ist dann die virtuelle Maschine wie VMware und VirtualBox.

Volker: Risiko von dem System ist Laufzeitbedarf und wie bei Docker auch die Konfiguration.

Volker: Ich muss halt immer aufpassen, dass meine Anwendung nicht aufs Betriebssystem,

Volker: aufs Host-Betriebssystem ausbrechen kann.

Volker: Aber an sich habe ich dann halt ein Betriebssystem im Betriebssystem,

Volker: brauche mehr Ressourcen, habe aber auch erstmal noch mehr Kapselung.

Volker: Und die letzte Lösung, die wir dann auch noch angesprochen haben mit Monina

Volker: zusammen, war eben die Typ 1 Virtualisierung.

Volker: Das heißt, das System, das ich installiere, greift direkt auf die Prozessorfunktion

Volker: zu am Host-Betriebssystem vorbei.

Volker: Und wenn ich das richtig auf Server-Ebene mache, auf so einem Virtualisierung-Server,

Volker: brauche ich theoretisch gar kein Host-Betriebssystem mehr,

Volker: sondern bringe nur noch die Container drauf, mache eine Container-Management-Software

Volker: auf diesen Bit-Computer und bin dann quasi völlig virtuell unterwegs.

Volker: So, das sind die drei Skalierungen.

Volker: Habe ich irgendwas Fichtiges vergessen, Monina, Ingo, Marc?

Volker: Dann danke ich euch, liebe Zuhörerinnen und Zuhörer, für eure Geduld und übergebt

Volker: die Bühne wieder an Monina für unseren netten, freundlichen Abspann.

Monina: Genau, das war die Sicherheitslücke zum Thema Kontainerisierung mit unserem Gast Marc.

Monina: Ihr könnt unseren Podcast wie immer dort finden, wo ihr Podcast hört und auf unserer Webseite.

Monina: Den Link zur Webseite und weiterführenden Inhalten der Folge und auch die Shownotes

Monina: findet ihr unter anderem auf unserer Sicherheitslücke-Webseite und in den sozialen Medien.

Monina: Empfehlt den Podcast gerne weiter und bewertet uns dort, wo ihr uns hört,

Monina: damit uns auch andere leichter finden können. Die Sicherheitswirke selber ist

Monina: ein Podcast der Hamburg Open Online University.

Monina: Und die Kapitelbilder, die immer noch fantastisch sind, kommen von Anne Vogt

Monina: und die Produktion übernimmt, wie man gelegentlich auch bei unseren Kommentaren

Monina: hört, Christian Friedrich.

Monina: Vielen Dank dafür und auch vielen, vielen Dank, Marc, dass du als Gast dabei

Monina: warst. Das war sehr spannend.

Monina: Wir verabschieden uns und bis zur nächsten Folge. Monina Schwarz.

Ingo: Ingo Timm.

Volker: Volker Skwarek und unser Gast.

Mark: Marc Hebbel, vielen Dank.