Select Page

NETWAYS Blog

Open Source VMware Alternativen für Deine IT-Infrastruktur

by | Jul 4, 2024 |

Der 22. November 2023 war ein Mittwoch wie jeder andere, doch dann ging es wie ein Paukenschlag durch die Presse:

Broadcom Inc. […] today announced that it has completed its acquisition of VMware, Inc.

Da war sie also, die Nachricht, die alle erwartet haben und noch mehr befürchtet haben: VMware wurde Teil von Broadcom. Damit auch ein Produkt, das wir selbst bei NETWAYS nicht nutzen, aber in vielen Umgebungen sehen: VMware vSphere. Niemand war überrascht, als kurz darauf Lizenzmodelle geändert und Verträge gekündigt wurden. Ich vermute, in IT Abteilungen auf der ganzen Welt hat man sich zuerst gegenseitig angeschaut, dann den Blick langsam auf das produktive VMware vSphere Cluster gerichtet und sich gefragt: “Was machen wir jetzt damit?”.

Ob es einen großen Exodus an Kunden gibt, ist derzeit noch unklar. Die Enterprise Mühlen mahlen langsam, und die Auswahl des unternehmensweiten Hypervisor ist keine Affekthandlung. Böse Zungen flüstern auch von Stockholm-Syndrom oder Sunk-Costs-Fallacy-Effekt. Fairerweise muss gesagt sein, vSphere ist kein schlechtes Produkt mit zahlreichen Features und Integrationen. Wie dem auch sei, es rumort auf dem Hypervisor Markt und viele Hersteller fragen sich, ob die Tage der VMware vSphere Dominanz gezählt sind. Was sind also VMware Alternativen?

Open Source Alternativen zu VMware vSphere

Glücklicherweise gibt es in der Open Source Hypervisor Welt Kandidaten, die es mühelos mit dem proprietären ESXi-Hypervisor aufnehmen können. Schwergewichte in der Kategorie sind: Kernel-based Virtual Machine (KVM) und Xen. Beide sind ausgereift und bieten zuverlässige Virtualisierung unter Linux. Schick ist auch, dank libvirt können wir diese und weitere Hypervisoren über eine einheitliche Schnittstelle ansprechen.

Aber Virtualisierung ist mehr als nur ein Hypervisor. Um eine angenehme Nutzererfahrung zu haben, möchte man Management Oberflächen, zusätzliche Administrationstools und Integration in Storage- und Backup-Systeme. Hier haben sich kleinere und größere Projekte und Produkte etabliert. Unter anderem:

  • oVirt, das Upstream Projekt von Red Hat Virtualization (mittlerweile durch OpenShift ersetzt)
  • XCP-ng, ursprünglich ein Citrix XenServer Fork
  • Proxmox VE

Daneben existiert natürlich noch OpenStack, was als “Cloud Operating System” wesentlich mehr bietet als eine Virtualisierungs-Plattform. Unter der Haube nutzt Nova, die VM Komponente von OpenStack, nutzt aber auch libvirt, um verschiedene Hypervisoren wie KVM oder Xen anzusprechen. Trotzdem muss man unterstreichen, dass die Installation und der Betrieb wesentlich involvierter ist als andere Virtualisierungs-Plattformen. Das überlässt man aber lieber den Profis bei NETWAYS Web Services, die haben sich sogar schon intensiv mit der Migration von VMware zu OpenStack beschäftigt.

Seit Kurzem gibt aber noch ein weiteres spannendes Projekt in der Runde: KubeVirt.

KubeVirt – the new kid on the block

KubeVirt bringt virtuelle Maschinen auf die Container-Orchestrierungsplattform Kubernetes. Kubernetes kommt mit vielen Komponenten zur Orchestrierung. Beispielweise eine gut dokumentierte Web API, einen flexiblen Scheduler und viele standardisierte Netzwerk/Storage Plugins. Alles Dinge, die man auch von einer soliden Virtualisierungs-Plattform erwartet. Die Grundidee von KubeVirt ist simpel: warum nicht einen Pod nutzen, um libvirtd zu starten, was dann eine VM startet? Um am besten noch mit bestehender Container Network Interface und Container Storage Interface Integration!

Heißt, ist KubeVirt einmal im bestehenden Cluster installiert, können VMs über die Kubernetes API verwaltet werden. Nicht nur das, da VMs hier über Pods gestartet werden und in bestehende Netzwerk/Storage Plugins integrieren, verhalten sich VMs auch einfach wie Pods. Im Gegensatz zu Containern behalten VMs aber ihre bekannten Eigenschaften, wie Langlebigkeit (über Virtual Disk Images) oder Live Migration. Umso mehr man drüber nachdenkt, umso schicker wirkt das Ganze. Der Meinung waren SUSE und Red Hat, die das Projekt als Kern in ihre Virtualisierungs-Plattformen aufgenommen haben:

Kubernetes ist kürzlich erst 10 Jahre alt geworden und das Projekt hat kaum was vom initialen Hype verloren. Doch zwischen Hype und Buzzword-Dschungel darf man nicht vergessen: Virtuelle Maschinen sind da, werden bleiben und haben ihre Daseinsberechtigung. Das Gleiche gilt für Container. Wäre es dann nicht schön, wenn man gemeinsam auf einer Plattform koexistieren könnte? Kann man, mit KubeVirt.

KubeVirt ist Apache-2.0-lizenziert und ein CNCF Projekt, dessen Version 1.0.0 im Juli 2023 erschienen ist.

Fazit

Die Entscheidung, ob man zu einer VMware Alternative wechseln möchte, hängt von vielen Variablen ab.

Zwar geniest freie und offene Software den Vorteil kostengünstig zu sein, dafür zahlt man hier meist mit Know-how das intern aufgebaut werden muss oder extern eingekauft werden muss. Dazu kommen dann auch Hardware und Software Anforderungen, über die man sich bei VMware vSphere vielleicht weniger Gedanken machen musste. Möchte man wirklich auf VMware vSAN verzichten?

Außerdem stellt sich die Frage, ob und welchen Support man bekommt, wenn man ein
Open Source Produkt nutzt, hinter dem ein Hersteller steht. Für Proxmox VE oder XCP-ng bieten die jeweiligen Hersteller Support an, aber deckt dieser die Anforderungen ab, die man im Unternehmen hat? Auf der anderen Seite sind oVirt und KubeVirt Projekte, die von einer Community gepflegt werden.

Wie bereits erwähnt, ist aktuell noch nicht sicher, wohin sicher der Hypervisor Markt bewegt. Es bleibt spannend! Persönlich kann ich mir eine Zukunft vorstellen, in der wir einen offenen Standard für virtuelle Infrastruktur haben, den unterschiedliche Herstellen dann implementieren können. Kubernetes und dessen Ökosystem bewegen sich schon in diese Richtung, vielleicht lässt sich dadurch langfristig Vendor Lock-in vermeiden oder zumindest reduzieren.

Hinweis in eigener Sache: Unser erfahrenes Team bei NETWAYS unterstützt gerne bei der Evaluierung und Implementierung der besten Lösung für Deine Bedürfnisse.

Wenn Du Fragen hast oder eine persönliche Beratung möchtest, nutze unser Kontaktformular. Wir freuen uns darauf, Dir zu helfen, die beste Virtualisierungslösung für Deine Anforderungen zu finden.

Markus Opolka
Markus Opolka
Senior Consultant
Markus war nach seiner Ausbildung als Fachinformatiker mehrere Jahre als Systemadministrator tätig und hat währenddessen ein Master-Studium Linguistik an der FAU absolviert. Seit 2022 ist er bei NETWAYS als Consultant tätig. Hier kümmert er sich um die Themen Container, Kubernetes, Puppet und Ansible. Privat findet man ihn auf dem Fahrrad, dem Sofa oder auf GitHub.
Read more from Markus and meet the Team

Webserver? Caddy bitte! Danke!

by | Jun 3, 2024 |

Hin und wieder gibt es einfach Software, die Probleme erschreckend gut löst: Der Webserver Caddy – eine in Go geschriebene Plattform, die mit ihrem HTTP-Server alle Standardfälle im täglichen Betrieb abdeckt – ist ein gutes Beispiel dafür.

 

Install Caddy auf Ubuntu (Noble)

Die Installation ist hier dokumentiert, und ich lege noch einen DNS-Record an. Die Konfiguration in /etc/caddy/Caddyfile passe ich entsprechend an:

caddy1.mhein.net-dump.de {
  root * /usr/share/caddy
  file_server
}

Caddy verwendet in diesem Beispiel ein ‘configuration format for humans’, das einer menschlicheren Sprachsemantik folgt. Intern verwendet Caddy JSON für seine Konfiguration und entsprechende Adapter für andere Formate.

Durch die Angabe des Hosts und nach einem Neustart erhalte ich ein Let’s Encrypt Production-Zertifikat und ein SSLLabs ‘A’ Rating. Das bedeutet: TLS 1.3, TLS_AES_256_GCM_SHA384 oder TLS_CHACHA20_POLY1305_SHA256, OCSP stapling und eine valide Zertifikatskette.

Also in etwa das, was uns ein Mozilla SSL Configuration Generator vorschlagen würde, inklusive aller Redirects, die ich in der Produktion benötige. In der Dreifaltigkeit von Apache2, HAProxy und Nginx würde ich das nicht unter 100 Zeilen fehlerfreier Konfiguration erreichen.

 

Reverse Proxy

Ich lege einen neuen DNS-Record an, packe ein paar Security Header mit rein und passe meine Konfiguration folgendermaßen an:

caddy2.mhein.net-dump.de {
  header {
    Permissions-Policy interest-cohort=()
    Strict-Transport-Security max-age=31536000;
    Content-Security-Policy "upgrade-insecure-requests"
    Content-Security-Policy: default-src 'self' caddy2.mhein.net-dump.de;
  }

 reverse_proxy 127.0.0.1:8080
}

Ich erhalte wieder Auto-TLS und einen perfekten Reverse Proxy. Durch korrekte Downstream-Header und WebSocket-Streaming als Standardeinstellung kann ich (nahezu) jede Applikation ohne Anpassung betreiben. Der HSTS-Header mit einer Dauer von einem Jahr verschafft mir jetzt ein ‘A+’ Rating und theoretisch die Erlaubnis, den Preload-Listen der Browserhersteller beizutreten.

 

PHP FastCGI Proxy

TL;DR – So schaut’s dann aus:

caddy3.mhein.net-dump.de {
  root * /var/www/html
  php_fastcgi localhost:9000
  # php_fastcgi unix//run/php/phpfpm.sock
}

Das reicht dann z.B. schon aus, um ein WordPress oder Icinga Web dahinter zu betreiben.

 

Fazit

Ich muss gestehen, dass ich von der grandiosen Leichtigkeit sehr angetan bin. Für mich bedeutet das in der Praxis, dass ich mich mehr um die ‘Sonderfälle’ kümmern kann, anstatt um die Standards. Dadurch funktionieren komplizierte Web-Deployments im Team deutlich besser und Fehlerquellen werden reduziert. Viele der Features habe ich noch gar nicht erwähnt, z.B. das Clustern von Caddys und das Speichern der Zertifikate in Redis oder Consul für Ingress-Cluster, Prometheus-Exporter, Live-Reload, On-The-Fly-API etc.

Wir haben hier eine Vielzahl von Apaches, Nginxen und HAProxies im Einsatz. Jeder davon hat seine Berechtigung und funktioniert sehr gut. Daher freue ich mich über etwas Frische und neue Motivation, um in passenden Fällen Gutes noch besser bereitstellen zu können. Für jeden, der auch nur im Entferntesten etwas mit Webservern zu tun hat: Unbedingt antesten!

 

Marius Hein
Marius Hein
Head of IT Service Management
Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert und viele Jahre in der Softwareentwicklung gearbeitet. Mittlerweile ist er Herr über die interne IT und als Leiter von ITSM zuständig für die technische Schnittmenge der Abteilungen der NETWAYS Gruppe. Wenn er nicht gerade IPv6 IPSec Tunnel bohrt, sitzt er daheim am Schlagzeug und treibt seine Nachbarn in den Wahnsinn.
Read more from Marius and meet the Team

Kritisch: Fehler in Elasticsearch mit JDK22 kann einen sofortigen Stop des Dienstes bewirken

by | Apr 8, 2024 | ,

Update

Seit gestern Abend steht das Release 8.13.2 mit dem BugFix zur Verfügung.

Kritischer Fehler

Der Elasticsearch Dienst kann ohne Vorankündigung stoppen. Diese liegt an einem Fehler mit JDK 22. In der Regel setzt man Elasticsearch mit der “Bundled” Version ein. Diese ist JDK 22 in den aktuellen Versionen. Dies geht aus einem Mailing des Elasticsearch Support-Teams hervor. Das Team entschuldigt sich für den Fehler und es wird mit hochdruck an einem Fix gearbeitet. Auch wird beschrieben, dass es nur sporadisch Auftritt und nicht in der Masse.

Betroffene Versionen:

  • Elasticsearch version 7.17.19 , versions 8.13.0/8.13.1 – with JDK 22

Empfehlung:

Da hier ein Datenverlust entstehen kann, sollte gehandelt werden. Wenn es das Einsatzszenario zulässt.

Workaround:

  • Self-Managed on Premise:
    • Installiert einfach ein JDK Bundle in der Version 21.0.2 und Elasticsearch. Beispiel: 
      • $ apt install openjdk-21-jdk-headless
      • Dann müsst ihr nach der Installation auf jeden Knoten einen Neustart des Dienstes durchführen. Denk dabei daran es als “Rolling Restart” durchzuführen.
  • Für die ES Cloud gibt es keinen Workaround. Hier gibt es Updates zum Services Status: Elasticsearch Instance Disruption on Elasticsearch 8.13
  • Für ECE/ECK (Elastic Clound on Premise / Elastic Cloud Kubernetes): gibt es keinen Workaround

 

Allgemeine Lösung

Das Team von Elastic arbeitet auf hochtouren an einem Fix für das Thema.

Die aktuellen Stände hierzu könnt ihr hier verfolgen:

Lösung

Natürlich ist es immer noch valide ein Donwgrade durch den Einsatz von OpenJDK durchzuführen wie im “Workaround” beschrieben. Empfehlenswerter ist es aber alle Elasticsearch-Nodes auf 8.13.2 zu aktualisieren. Da hier wie immer ein Neustart des Dienstes notwendig ist, vergesst nicht nach dem Schema des “Rolling Restart” zu handeln.

Anmerkung der Redaktion

Hier ist ein handeln Empfohlen. Der Hersteller hat die Schwachstelle erkannt und öffentlich bekannt gegeben, begleitet von Handlungsempfehlungen zur Behebung. Wir haben dies festgestellt und möchten euch mit diesem Beitrag bei der Erkennung und der damit verbundenen Möglichkeit zum Handeln unterstützen. Wenn Ihr unsicher seit, wie ihr reagieren sollt und Unterstützung benötigt, wendet euch einfach an unser Sales-Team. Das Team von Professional Services unterstützt euch gerne.

Daniel Neuberger
Daniel Neuberger
Senior Consultant
Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.
Read more from Daniel and meet the Team

End of Life von CentOS Linux 7 – Was bedeutet das für mich?

by | Mar 25, 2024 |

Der ein oder andere Admin wird sich vermutlich schon lange den 30. Juni 2024 im Kalender vorgemerkt haben, denn dann ist für CentOS Linux 7 das “End of Life” erreicht. Aber auch Benutzer von Red Hat Enterprise Linux 7 sollten sich Gedanken machen, denn auch dieses verlässt an dem Tag die “Maintenance Support 2 Phase” und geht in den “Extended life cycle” über.

Was bedeutet das nun?

“End of Life” ist relativ einfach erklärt, ab diesem Termin wird die Unterstützung für das Produkt eingestellt und somit gibt es hier keine Updates mehr. Insbesondere das Fehlen von Sicherheitsupdates spricht dann ganz klar gegen einen Weiterbetrieb.

“Extended life cycle” ist dagegen etwas komplizierter. Auf der einen Seite stellt auch Red Hat hiermit das Updaten ein, supported bestehende Systeme aber weiter und bietet auch Migrationsunterstützung. Auf der anderen Seite ermöglicht es bei Red Hat hier ein Support-Addon hinzu zu kaufen, welches dann Zugriff auf kritische und schwerwiegende Sicherheitsupdates und ausgewählte Bugfixes sowie andere Supportbedingungen gibt. Wer also aus irgendwelchen Gründen darauf angewiesen ist, kann für einen nicht gerade kleinen Betrag einen sicheren Weiterbetrieb sicherstellen und damit die Migration weiter hinauszögern. Für die meisten Nutzer dürfte es aber gleichbedeutend mit dem “End of Life” sein.

Was soll ich nun tun?

Der übliche Weg bei Software ist der Weg nach vorne, also ein Upgrade auf die nächste Version des Betriebssystems. Hier wird es allerdings in diesem Fall deutlich komplizierter denn mit der Einstellung von CentOS Linux gibt es den klaren Weg nach vorne nicht mehr, sondern einen echt verzwickte Weggabelung!

Wer weiterhin dem CentOS-Projekt sein Vertrauen schenkt, hat als direkten Nachfolger CentOS Stream 8. Dieses ist aber nicht länger ein Downstream von Red Hat Enterprise Linux und auch nicht mehr den kompletten Support-Lifecycle unterstützt, sondern EoL bereits am Ende des “Full support” was dem Release der Minorversion 10 und somit 5 Jahren statt 10 entspricht! Damit ist das EoL für CentOS Stream 8 allerdings bereits am 31. Mai 2024, also vor dem von CentOS Linux 7. Somit sollte der Weg schnell beschritten werden und dann direkt weiter zu CentOS Stream 9.

Der ein oder andere sollte auch überlegen ob die eigenen Anforderungen nicht den Wechsel zum Enterprise-Support rechtfertigen. Red Hat supportet den Wechsel hier nicht nur, sondern stellt auch entsprechende Werkzeuge zur Verfügung. Damit lässt sich auch das Upgrade bei Bedarf raus zögern, auch wenn ich nach dem Wechsel eigentlich direkt den Schritt zu RHEL 8 empfehlen würde bzw. man auch hier direkt mit Version 9 überlegen kann.

Eine andere Alternative mit direktem Enterprise-Support aber auch unbegrenzter freier Verfügbarkeit ist Oracle Linux. Hierbei lässt sich quasi das gleiche bezüglich Migration sagen. Aber bei diesem Wechsel empfehle ich sich mit den Besonderheiten von Oracle Linux ausführlich auseinander zu setzen. Ich habe da in der Vergangenheit durchwachsene Erfahrungen gesammelt. Zum einen haben wir Kunden, die mit teils recht großen Umgebungen komplett auf Oracle Linux sehr gut fahren. Zum anderen hatte ich mit zusätzlichen Repositories und dort enthaltener Software teils Probleme, da Oracle teilweise andere Kompiler-Flags setzt und auch EPEL (Extra Packages for Enterprise Linux) nachbaut, aber dies nicht im vollen Umfang.

Dann gibt noch die Forks, die aufgrund der Einstellung von CentOS Linux entstanden sind. Hier müssen für mich alle noch beweisen wie ihnen der veränderte Umgang von Red Hat mit den Quellen gelingt und wie das ganze nach dem EoL von CentOS Stream aussieht. Da sehe ich aktuell bei AlmaLinux, dass das Projekt sehr vieles richtig macht, sowohl technisch als auch in anderen Bereichen. Rocky Linux wirkt hier auch sehr solide. Alle anderen habe ich quasi aus den Augen verloren, da sie weder bei uns im Kundenstamm relevant geworden sind noch mein persönliches Interesse durch etwas geweckt wurde. Das Schöne hier ist, dass sowohl Werkzeuge zur Migration in Version 7, als auch direkt von 7 zu 8 existieren.

Den kompletten Distributionswechsel lasse ich in der Betrachtung mal außen vor, da hier dann deutlich mehr Planung notwendig ist. Auch dieser Aufwand ist zu stemmen, aber dann doch eher keine Lösung für einen Zeitraum von etwa 3 Monaten.

Wie gehe ich nun vor?

Nachdem die Entscheidung für das Ziel gefallen ist, stellt sich als nächste Frage üblicherweise ob man das System überhaupt upgraden oder lieber direkt neu erstellen will. Hier habe ich mich mittlerweile tatsächlich zu einem Befürworter von In-Place-Upgrades entwickelt, was auch an dem Tool Leapp bzw. ELevate liegt. Mit diesem und den Möglichkeiten wie ich es auch in größeren Umgebungen sinnvoll nutze, habe ich mich schon vor einer Weile in meinem Artikel “Leap(p) to Red Hat Enterprise Linux 9” beschäftigt.

Worauf ich damals nur am Beispiel von Foreman eingegangen bin, sind hier der Umgang mit zusätzlicher Software. Foreman war für den Artikel ein gutes Beispiel, da hier extra Migrationen für Leapp gebaut wurden. Bei anderer Software ist dies nicht der Fall. Also müssen wir hier von zwei Szenarios ausgehen. Zum einen von Software, die aus einem zusätzlichen Repository in Form von Paketen installiert wurde, und zum anderen solcher die manuell installiert wurde. Software in Containern oder ähnlichem können außen vor lassen, da diese unabhängig vom Betriebssystem sind.

Software aus zusätzlichen Repositories sollte mit Leapp/ELevate kein Problem darstellen, solang ein Repository für die neuere Version verfügbar ist. In diesen Fällen muss nur das zusätzliche Repository während des Upgrades verfügbar gemacht werden. Dass es auch hier Stolpersteine gibt ist klar, ein Beispiel wäre hier Icinga wo ab EL8 nur noch Subscription-pflichtige Repositories zur Verfügung stehen. Also auch hier sollte etwas Zeit in Planung und Tests investiert werden bevor es an produktive Systeme geht.

Bei manuell installierter Software ist nach dem Betriebssystem-Upgrade sehr wahrscheinlich einmal neu kompilieren angesagt, damit die Software mit neueren Version der Systembibliotheken läuft. In manchen Fällen wird auch ein Update der Software notwendig sein, wenn die Kompatibilität sonst nicht mehr gegeben ist. Das gilt auch in vielen Fällen für nicht zu kompilierende Software, da sich auch Perl-, Python-, Ruby- oder ähnliche Laufzeitumgebungen ändern. Da hier ein Vorteil des In-Place-Upgrades weg fällt und eh ein manueller Schritt übrig bleibt, ist hier ein paralleler Neuaufbau schon eher verlockend. Was am Ende sinnvoller ist, entscheidet sich meist je nach Menge der Laufzeitdaten.

Ist damit alles getan?

In vielen Umgebungen wird hier gerne noch vergessen wo das Betriebssystem noch so eine Rolle spielt und auch hier ist die Migration wichtig. Zum einen ist es sinnvoll sich bei Containern oder Images wie beispielsweise bei Vagrant die Basis anzuschauen und hier auf neuere Versionen zu wechseln. Und dann haben wir zum anderen CI/CD-Pipelines, hier kann im Vorfeld über eine Erweiterung der Matrix schon oft eine Kompatibilität sichergestellt werden und nach abgeschlossenem Upgrade können dann die alten Systeme entfernt und damit verbundene Restriktionen gelockert werden, was sicher einige Entwickler freut.

Fazit

Wie hoffentlich jeder sieht, hier steht uns allen Arbeit bevor und zwar nicht nur beim eigentlichen Doing. Aber es kann auch als Chance für Innovation gesehen werden. Beispielsweise hat beim Foreman-Projekt ein regelrechter Frühjahrsputz eingesetzt nachdem mit dem Wegfall des Supports für EL7 und damit dem Bedarf an Support für EL9 der ganze Technologie-Stack modernisiert werden kann. Wenn ich nun jemand aufgeschreckt habe oder allgemein jemand bei dem Thema Hilfe benötigt gerne unterstützen unsere Consultants bei der Planung egal ob es um das richtige Vorgehen oder den Einsatz der Tools geht. Über ein Outsourcing-Kontingent unterstützen die Kollegen auch gerne beim eigentlich Upgrade. Und auch wegen einer Icinga-Subcription darf sich bei Bedarf an unser Vertriebsteam gewendet werden.

Dirk Götz
Dirk Götz
Principal Consultant
Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.
Read more from Dirk and meet the Team

Kibana Sicherheits-Updates: CVSS:Critical

by | Feb 8, 2024 | , ,

Und täglich grüßt das Murmeltier. Nein nicht ganz. Heute ist es  aus der Elastic Stack Werkzeugkiste Kibana, für das es ein wichtiges Sicherheits-Update gibt. Es besteht auf jeden Fall Handlungsbedarf! IMHO auch wenn ihr die “Reporting” Funktion deaktiviert habt.

Der Link zur Veröffentlichung: Kibana 8.12.1, 7.17.18 Security Update (ESA-2024-04)

Schweregrad: Severity: CVSSv3: 9.9(Critical)

Beschreibung

Die Verwundbarkeit ist ist auf eine Schwachstelle von Google Chrome aus Dezember 2023 zurückzuführen. Da Kibana für die Reporting Funktion eine eingebettete “Chromium headless Verison” mit sich bringt, ist Kibana von dieser “Heap buffer overflow in WebRTC” ebenfalls betroffen. Diese Schwachstelle ermöglicht es einem entfernten Angreifer, über eine manipulierte HTML-Seite einen “Heap-Velrust” auszunutzen.

Dieser Effekt betrifft “on-premises” Kibana installation auf Betriebsystemen die “Chromium Sandbox” abgeschaltet haben. Diese sind CentOS, Debian, RHEL.

Es betrifft auch Instanzen welche mit dem Kibana Docker betrieben werden, wenn “Chromium Sandbox” wie explizit empfohlen abgeschaltet ist. Jedoch gilt hier, dass eine “Container Escape” nicht möglich ist, da es durch “seccomp-bpf” unterbunden wird. Das gilt auch für Kibana Instanzen auf “Elastic Cloud“, für “Elastic Cloud Enterprise (ECE)“, wobei hier das weitere Vordringen zusätzlich zum “seccomp-bf ” mit “AppArmor profiles” verhindert wird.

Für Kibana Instanzen welche auf “Elastic Cloud on Kubernetes” laufen, ist um das weitere Vordingen (Container Escape) durch “seccomp-bf” zu verhindern, dieses entsprechend in Kubernetes zu konfigurieren (wird seit V1.19 unterstützt).

Betroffene Versionen

  • Kibana bis 7.17.17
  • Kibana bis 8.12.0

Handlungsablauf zur Abhilfe

  • Dringend Update auf Version 8.12.1 oder Version 7.17.18
    • Dabei ist aber auch an die Elasticsearch Version zu denken
  • Sollte Kein UPDATE möglich sein, dann sollte die “Reporting” Funktion dringend abgeschalten werden 
    vi /etc/kibana/kibana.yml
...
xpack.reporting.enabled: false

     

Anmerkung der Redaktion

Hier ist ein handeln Empfohlen. Der Hersteller hat die Schwachstelle erkannt und öffentlich bekannt gegeben, begleitet von Handlungsempfehlungen zur Behebung. Wir haben dies festgestellt und möchten euch mit diesem Beitrag bei der Erkennung und der damit verbundenen Möglichkeit zum Handeln unterstützen. Wenn Ihr unsicher seit, wie ihr reagieren sollt und Unterstützung benötigt, wendet euch einfach an unser Sales-Team. Das Team von Professional Services unterstützt euch gerne.

Daniel Neuberger
Daniel Neuberger
Senior Consultant
Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.
Read more from Daniel and meet the Team

Trainings

Web Services

Events