Seite wählen

NETWAYS Blog

Webserver? Caddy bitte! Danke!

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.

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

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.

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

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.

Kibana Sicherheits-Updates: CVSS:Critical

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.

CVSS:Medium: Elastic Sicherheits-Updates gleich für drei Produkte

Gleich drei Sicherheits-Updates für drei verschiedene Produkte wurden von Elastic veröffentlicht. Alle drei haben den Schweregrad  Medium. Jedoch ist es Ratsam die Updates durchzuführen. Folgend eine kurze Zusammenfassung je Produkt.

Link: APM Server 8.12.1 Security Update (ESA-2024-03)

Solltet Ihr in Elasticsearch aktiv das Application performance Feature nutzen und einen eigenen lokalen APM Server betreiben, dann ist ein Update ratsam. Dies Betrift nur die selbst betriebene APM binary Server Varianten nicht die Elastic APM Integration des Agent.

Beschreibung

Der APM-Server schreibt bei Fehlermeldungen welche einen Indizierungsfehler (das schreiben von Dokumenten in den Index) betreffen, Teile des dazugehörigen Dokumentes mit in die lokale Log-Datei. Dies kann dazu führen das Schützens werte Informationen (z.B Entitäten z.B von Applikations-Nutzern) lokal lesbar in der Datei geschrieben sind.

Betroffene Versionen

  • APM Server <8.12.1

Abhilfe

  • Aktualisierung des lokal betriebenen APM-Server auf Version 8.12.1
  • Aufspüren von sensiblen Informationen in den Logs:
    • Beispiel unter Linux mit Standard Log-Einstellungen:
      grep -Hrn "Preview of field's value:" /var/log/apm
    • sollte es Treffer geben ist die Log-Datei am besten zu rotieren und danach zu löschen.

Link: Kibana 8.12.1 Security Update (ESA-2024-01)

Beschreibung

Solltet hier die Detection Search Engine nutzen und verfügt über eine Subskription die es euch ermöglicht die Document-level (DLS) oder Field-Level (FLS)= basierten Berechtigungen zu nutzen, dann solltet Ihr hier handeln. Denn Benutzer welche Berechtigt sind die Indices für Alarmierungen über die Kibana-Api zu nutzen (Webfrontentd) könnten bei der Abfrage der entsprechenden Indices „.alerts-security.alerts-{space_id} mehr angezeigt bekommen als diese sehen dürften. Grund ist das die Engine diese einfach ignoriert. Bedeutet wenn ein Benutzer mit Berechtigungen auf Basis von DLS und FLS diese API abfragt, bekommt er Zugriff auf Informationen die er nicht sehen sollte.

Betroffene Versionen

  • Kibana 8.x bis zu <8.12.1

Handlungsablauf zur Abhilfe

  • Aktualisierung auf Version 8.12.1
    • Vorsicht es empfiehlt sich immer Elasticsearch und Kibana auf gleicher Version zu halten. Somit kann hier auch ein Update von Elasticsearch anstehen, was mit einem Rolling Restart verbunden ist.

Link: Elastic Network Drive Connector 8.12.1 Security Update (ESA-2024-02)

Beschreibung

Der Elastic Network Drive Connector ist ein Werkzeug welches bei Verwendung der Enterprise Search zum Einsatz kommt (Subskription Funktion). Hier kann der Benutzer auf Dokumenten Ebene trotzdem Dokumente sehen, welche Ihm explizit zum lesen und schreiben nicht zugeordnet sind. Somit kann der Benutzer Dokumente, auf die er nicht zugreifen kann und sollte, trotzdem sehen.

Betroffene Versionen

  • Elastic Network Drive Connector  <8.12.1

Handlungsablauf zur Abhilfe

  • Aktualisierung auf Version 8.12.1

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.