Seite wählen

NETWAYS Blog

OpenBugBounty.org – was ist das?

So wie es heise und anderen auch schon passiert ist, hatten wir kürzlich zwei Mails von openbugbounty.org im Postfach.

Im ersten Moment wunderten wir uns, was das denn für ein Laden sein könnte, aber am Ende gestaltete sich das ganze jedoch positiv.

 

Kommt erstmal überraschend

Über die nicht-kommerzielle Plattform haben uns unabhängig voneinander zwei IT-Security Spezis kontaktiert. Beide hatten unterschiedliche Lücken auf einer unserer WordPress-Installationen entdeckt und anstatt diese auszunutzen (sehr niedriger Impact) oder zu verkaufen (so sie denn Käufer:innen gefunden hätten), wählten sie den Weg des Responsible Disclosure mit einer Frist von 90 Tagen. Dieses Verhalten ist vergleichbar zum bekannteren Google Project Zero.

Responsible Disclosure wird oft kritisiert

Im Grunde gibt dieses Vorgehen den Betroffenen Zeit, den Fehler zu beheben, bevor dieser öffentlich gemacht wird und somit vielleicht auch einen größeren Schaden allein durch die Reichweite anrichten kann. Sobald der Fehler behoben ist, wird der Report veröffentlicht, damit auch andere Betroffene entsprechende Maßnahmen ergreifen können.

Einschub: oft wird Responsible Disclosure kritisiert, gerne auch Bug Bounty allgemein. Zum einen nimmt man den Betroffenen aus der Pflicht sofort zu handeln, wobei je nach Schwere der Lücke Zeit ein durchaus entscheidender Faktor sein kann. Und es ist ja auch nicht gesagt, dass nur exakt eine wohlmeinende Person diese Lücke findet und kein Schindluder damit treibt. Zudem könnte sich eine gewisse Laxigkeit im Bezug auf Datensicherheit einstellen, wenn ja eh ein zusätzlicher Feedbackkanal zur eigenen verhunzten Installation zur Verfügung steht. Und solange von der Seite kein Input kommt, kann das eigene System ja keine sooo schweren Lücken haben, oder?

Wie reagieren?

Wir standen am Anfang auch erst vor der Frage „wie reagieren?“, aber NETWAYS-typisch haben wir dann halt einfach mal gemacht. Also via Twitter bei openbugbounty.org eingeloggt (was machen eigentlich Leute ohne Twitter-Account? Solche soll es ja mittlerweile auch in NETWAYS-orange geben) und die Kontaktdaten der Spezln geholt.

Eine kurze Mail später hatten wir die Details, den möglichen Impact und eine Behebung für die Lücke im Postfach. Natürlich wurde das nochmal verifiziert, wobei seitens openbugbounty.org bereits eine Verifikation erfolgt. Die Fehlerbehebung war dann auch schnell erledigt und wir konnten die Lücken auch gleich noch auf unseren anderen WordPress-Installationen überprüfen.

Der längste Teil der Geschichte war am Ende die Entscheidung, was tun wir mit der Meldung, wie belohnen wir die beiden am besten und schreibe ich diesen Blogpost auf deutsch oder englisch.

Die Plattform selbst war bei diesem Prozedere nur als Kontaktvermittlerin involviert und hat von uns exakt nichts außer diesen Blogpost erhalten. Ihre Eigenpräsentation hat das Projekt auch hochgeladen. Unsererseits war die Erfahrung also gut, die Kommunikation war immer schnell und offen und es besteht hier wirklich kein Grund zur Furcht.

Details zu den Lücken

Wer bis hier hin durchgehalten hat, ist sicher auch neugierig, was das denn nun für Lücken waren. Die erste ermöglichte es, via WordPress API alle User unserer Installation abzufragen (nur GET, kein POST). Also im Grunde diese coolen Nasen – das NETWAYS-Team.

In der zweiten hätte die WordPress-RPC Funktion ausgenutzt werden können um bspw. DDoS-Attacken auszuführen. Details zu beiden Lücken finden sich bei openbugbounty.org unter den Meldungen 1777708 und 1814148.

Wenn Du Lust auf weitere solche und ähnliche Geschichten hast, schau bei unseren Trainings oder Events  vorbei. Mindestens in den Pausen werden immer Erlebnisse aus der IT Welt verglichen, manchmal auch die Länge der Pipelines oder Größe der Cluster.

Du willst davor eigene Erfahrungen sammeln? Klick Dir hier Deinen eigenen K8s-ClusterOpenStack oder GitLab-Server.

Wenn Du und Deine offene Fehlerkultur allerdings auch mal via WordPress-API angezogen werden sollen, ist jobs@netways.de der richtige Einstiegspunkt. Wir freuen uns darauf, den nächsten Bug Report mit Dir zusammen zu beheben!

Tim Albert
Tim Albert
Systems Engineer

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere...

Lust auf mehr Privacy? DIY Wireguard mit DNSCrypt & Quad9

Privacy & Warum Wireguard?

Mein Ziel in diesem Artikel ist es, dir zu zeigen, wie man einen eigenen Wireguard Server aufsetzt. Warum nicht einfach eine fertige VPN-Lösung einkaufen? Weil du ansonsten nie wirklich weißt, was mit deinen Logs & Daten passiert und diese zu gerne zu Analysezwecken weiterverwendet und verkauft werden.

Grade im Hinblick auf Werbe-/User-Tracking, ist es relativ schwer, browserseitig Internet-Privacy in 2021 zu erreichen (wie man auf Seiten wie AmIUnique sehen kann). Ein VPN wird einen individuellen Browser-Fingerprint nicht wirklich entfernen. Schaltet man aber noch ein Squid zum VPN der Wahl hinzu, mit http_anonymizer standard oder http_anonymizer paranoid, könnte man kleinere Erfolge erzielen! Zum Thema Browser-Fingerprinting erzähle ich vielleicht in Zukunft mal mehr.

Auf andere Protokolle bezogen, macht ein VPN aus Privacysicht aber dennoch Sinn, um z.B. Vorteile durch spezielle Services, die ländergebunden sind, zu erreichen und / oder um ein besseres Routing zu gewinnen. Da z.B. eine Suchanfrage via Google schön zeigt (ganz unten im Browser), wie nahe man via IP ohne extra Geo-tracking den Standort bestimmen kann, macht ein VPN mit integriertem DNS aber doch Sinn. Auch, um all seine Geräte gegen fremde Router & IP & DNS basierte Netzwerkangriffe zu schützen.

Warum Wireguard als VPN?

  • Leistung: OpenVPN ist recheninvensiver und benötigt praktisch AES Beschleunigung auf CPU-Form. Das bedeutet, dass ein Router, der zumeist ein ARM-Board hat (ohne AES Chip), niemals die selbe Leistung erreichen wird (MBit Download/Upload – technisch) wie es mit Wireguard der Fall wäre. Dies sollte man auch skaliert mit mehreren Servern / Clients betrachten.
    Wireguard selbst läuft mittlerweile auch als Linux-Kernel-Modul. Dies bringt natürlich Performanz-Vorteile mit sich. Zugleich gibt es mittlerweile direkten Support für OpenWRT Router (ohne dedizierte AES Chips) auf Kernel-Level (!), sowie neuerdings auch in OPNSense im Userland, und ab FreeBSD 13 auch im Kernelland.
  • Batterie: Selbiges gilt für Smartphones & Laptops, die natürlich mitrechnen müssen. Via OpenVPN werden deine Geräte mehr Rechenleistung aufwenden müssen, und praktisch schneller an Batterie verlieren.
  • Sicherheit: Wireguard hat mehrere Krypto-Runden. Dazu kommt, dass man manuell, individuellen Clients Zugriff genehmigen muss / darf, via assymetrischer Kryptographie & IP sowie symmetrischer Kryptographie falls gewünscht.
  • Codebase: Der Code ist sehr viel kompakter (< 4000 Zeilen Code), was ihn fehlerfreier sein lassen könnte. Als Faustregel kann man sagen: ~ 1 Fehler pro 1000 Zeilen Code. (Stichwort OpenBSD)

Guide

Meinen Wireguard-Guide findest du hier im Github. Er ist die Schnittmenge aus mehreren anderen Guides und eigenen Experimenten.

Im Prinzip ist alles, was du dann noch machen musst, dir ein Redhat 8 (gibt es umsonst bis zu 16 Lizenzen für den Privatgebrauch) oder CentOs 8 – VPS zu holen, welche es teilweise schon ab 5 -10 € pro Monat gibt. Warum nicht Debian oder Ubuntu? Weil ich SELinux persönlich mächtiger finde, und dieser Guide komplett unter Enforcing-Policies läuft.

Weitere Tweaks

  • SSH nur per Wireguard zulassen / Fail2 Ban installieren
  • Automatische Updates via DNF-Automatic anschalten
  • Überlegen, ob du vielleicht den Wireguard Server nur als diesen laufen lassen solltest. Einerseits um sauberes Enforcing / Targeted SE-Linux beizubehalten -> ohne viele extra Services <- andererseits um gefährlichere Services (Mail / Web) auf einen anderen Server auszulagern
  • Je nach Situation Client-Isolation anschalten
  • In Clients Kill-Switches setzen

Hinweise

  • Mir fiel auf, dass unter DNSCrypt-Proxy anfänglich Cloudflare DNS-Leaks provoziert hat (falsche Routes?), während Quad9 das per Default nicht getan hat. -> Ob das reproduzierbar ist oder an meinem Setup liegt, kannst du mir gerne in den Kommentaren sagen.
  • Mir ist außerdem aufgefallen, dass Hibernate unter manchen Linux-Distros, nach dem Hibernate, DNS-Leaks hervorruft. Hier sind die DNS-Adresse des Netzwerk-Interfaces, /etc/systemd/resolved.conf & /etc/dhcp/dhclient.conf (prepend domain-name-servers) drei Anlaufstellen, welche man dann am besten mit der neuen DNS des Wireguard-Servers versieht.
  • Mein VPS unterstützt leider kein IPv6, ich habe aber die Settings mal für dich im Github angelassen. Testen kann ich es nicht, aber die Konfiguration läuft genau so auch unter IPv4, falls dein VPS änlich ist.
  • Scheinbar leiden selbst DoH & DoT unter dem Problem, dass die initialen Client-Hello-Messages vor dem TLS Handshake sichtbar sind (Stichwort ESNI, dies muss also Serverseitig nachgerüstet werden). Das bedeutet konkret, dass ein VPN Server wirklich immer Sinn macht, da man dann im Notfall auf ihn zurückfällt, ohne die eigene IP zu leaken. Adguard liefert mit DNS-over-QUIC einen anderen interessanten Ansatz und begräbt TLS, was man im DNSCRYPT einstellen könnte.

 

Unser NETWAYS Github ist eine super Anlaufstelle, falls du Lust auf noch mehr Open Source hast.

Patrick Dolinic
Patrick Dolinic
Junior Consultant

Nachdem Patrick sein Psychologiestudium abgeschlossen hat, ist er 2020 zu NETWAYS, wo er nun sein Hobby zum Beruf macht: Endlich kann er sich voll und ganz der Linux-Welt widmen und sein Faible für Computersicherheit ausleben. Wenn er nicht gerade arbeitet, arbeitet oder zockt er. Nebenbei versucht er beim Joggen 8 km zu reißen, schafft aktuell aber nicht mal die ersten 7.

Endlich: Dein NWS JaaS – Jitsi as a Service !

Dein Jitsi as a Service (JaaS) kannst Du jetzt noch besser personalisieren.

Mit Beginn der ersten Coronawelle in Deutschland haben wir die Arbeit an einer Videokonferenz-Plattform begonnen, damals schon auf Basis von Jitsi. Schnell haben wir gemerkt, dass hier viel Bedarf besteht, gerade auch bei kleinen Firmen, Schulen oder Selbsthilfegruppen. Also haben wir die #StayAtHome Kampagne ins Leben gerufen, womit ihr unsere Dienste kostenlos nutzen konntet. Wir freuen uns seitdem über zahlreiche neue Kund*innen und euer wertvolles Feedback!

Vor einigen Wochen haben wir uns wieder zusammen gesetzt und versucht, dieses Kundenfeedback zu verarbeiten. Wir haben eure wichtigsten Punkte zusammengeführt und geschaut, wie wir das umsetzen können. Darunter waren Features wie Custom Logos, Logo Links, SIP, Custom Domains. Ein technischer Plan wurde erstellt, ein Zeitplan wurde aufgesetzt und dann ging’s los mit dem Erstellen des Prototypen.

Letzten Freitag war es dann soweit. “Geh ma live, oder was?” – Nun gut. Wir gingen live.
Doch was ist jetzt eigentlich anders? Kurz gesagt: ALLES.

Was ist neu? Ein kleiner Überblick

Die Passwort Authentifizierungsmethode haben wir ergänzt durch die JWT Authentifizierung. Du kannst hier Deine bevorzugte Methode zum Erzeugen der Tokens nehmen, oder eben unsere eigene Maske. Du kannst Dich also ab sofort entscheiden, was Du nutzen möchtest. Besonders wichtig ist dies für die Integration in RocketChat oder Mattermost.

 

 

Dazu kommt ein weiterer großer Schritt: Domains. Jede Instanz ist mit einem kostenlosen CNAME auf nws.netways.de ausstattbar. Damit aber nicht genug, auch eigene Domains können nun genutzt werden. TLS/SSL ist mit einem eigenen Zertifikat möglich, oder aber – wie immer – über unseren Let’s Encrypt Dienst.

 

 

 

 

Die auffälligste Neuerung wird aber die Design Sektion sein. Ich mach es kurz. Customizable ist:

  • Hintergrundfarbe
  • Logo
  • Hintergrundbild
  • LogoURL
  • App Name
  • Title
  • Subtitle
  • Impressum Link
  • Datenschutz Link
  • Cors Domains

 

Die Bilder, die für die Designänderungen ausgewählt wurden, landen in einem S3 Bucket. Jede Instanz hat einen eigenen Bucket und wir nutzen hier unser hauseigenes S3. Es gehen also wie üblich keine Deiner Daten ins Ausland.

Die Preise bleiben gleich. Du bekommst unser Jitsi für 25 User schon ab 24,99 €. Wichtig ist aber, dass es sich hier nicht um unique-User handelt oder Moderatoren, sondern um parallele User. Das unterscheidet uns von anderen großen Anbietern. Ebenso wie die Tatsache, dass wir alle Features für alle Pakete anbieten – egal, ob Du den kleinsten oder größten Plan gebucht hast.

Schaut’s euch an! Wir haben viel Zeit und Mühe investiert und bieten Dir unser JaaS 30 Tage kostenlos an. Es gibt also keinen Grund, es nicht sofort auszuprobieren. 😉

Jetzt Dein eigenes Jitsi starten!

Marius Gebert
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

NWS bekommt einen neuen Anstrich

Harte Arbeit, “Blut” und Schweiß und ein Ergebnis, das sich sehen lässt: Nach unserer Website erscheint nun auch das Kundeninterface in neuem Glanz!

Neben purer Ästhetik für Farben und Formen ging es uns natürlich auch darum, die Bedienung komfortabler und intuitiver zu gestalten. Zudem wurde es mit dem ein oder anderen neuen Feature beschenkt. Geburtstag wurde schließlich auch gefeiert. Aber der Reihe nach. Seit dem Start unserer NWS-Plattform im März 2017 sind ziemlich genau 4 Jahre vergangen.

 

Happy Birthday NWS!

 

 

Nun zum Kundeninterface:

 

Die Idee

Wie bei einem Kleinkind in diesem Alter sind viele – nicht alle – Kinderkrankheiten bereits überstanden und die ersten Gehversuche liegen hinter uns. Die Welt wird neugierig und furchtlos erkundet. Um in dieser Bildsprache zu bleiben: Wir haben unsere Kinderschuhe nun zur Seite gelegt und unser erstes Paar neue Sneakers geschnürt. Nachdem unsere Website bereits vor geraumer Zeit komplett überarbeitet wurde, war es letztendlich nur die logische Konsequenz, auch das Kundeninterface anzupassen. Neben unseren eigenen Ideen wurden unsere Erkenntnisse aus den letzten Jahren – und das wertvolle Feedback unserer immer größer werdenden Kundschaft – umgesetzt.

 

Bedienung

Die Navigation und das Bedienungskonzept standen zu Beginn im Vordergrund. Die größte Herausforderung war sicher, alle unterschiedlichen Produkte unter einen Hut zu bekommen. Eher einfache Produkte wie Jitsi – auf der einen Seite – und eher komplexe wie Managed Kubernetes oder unsere Cloud auf Basis von OpenStack, auf der anderen: Alle Produkte sollten einem Prinzip folgen und sich in der Bedienung und im Konzept ähnlich verhalten. Viele Stunden Brainstorming und einige Diskussionen später stand unsere Entscheidung fest: Sämtliche Produkte organisieren sich in unserer Hauptnavigation – egal, ob es bereits gebuchte oder neue Produkte sind. Gebuchte Produkte ordnen sich allerdings zuerst ein, da sie schließlich das Wichtigste für den Bedienenden sind. Wählt man eines aus, erhält man eine zweite Navigationsleiste, die nur Menüpunkte für das Produkt beinhaltet. Die dritte und letzte Ebene ist der jeweilige ausgewählte Inhalt. Durch die klare und nicht allzu tiefe Hierarchie ist es einfach und nachvollziehbar, wo man sich gerade in der Applikation befindet. Zusätzlich verliert man – durch die beiden stillstehenden Navigationen – seinen Fokus nicht und wird nicht unnötig abgelenkt.

 

 

Farben und Formen

Der neue Stil ist clean und simpel. Unsere Farbpalette der NETWAYS Web Services wurde übernommen und rundet das Erscheinungsbild ab. Die gewählte Schriftart “Montserrat” wirkt modern. Wiederkehrende Elemente wurden im Backend durch dynamische Templates gestaltet und helfen dem einheitlichen Erscheinungsbild. Die Icons unserer Produkte wurden per Hand neu gezeichnet.

 

 

 

Features

Neben der neuen Benutzerführung gibt es viele kleine Verbesserungen für bereits etablierte Elemente. Unser MyEngineer-Service hat einen omnipräsenten Navigationspunkt bekommen, um stets Zugriff auf seine Tickets, Zeiten und den Kontakt zu unseren Kollegen zu haben. In der Übersicht gibt es neben einem “Activitiy Log”, das die letzten Nutzeraktivitäten darstellt, außerdem Informationen über anstehende oder akute Wartungsarbeiten oder Ausfälle und weitere Informationen, wie beispielsweise hilfreiche Tutorials. Jedes Produkt hat jetzt eine Übersicht, in der die wichtigsten Schritte, weiterführende Links oder teilweise kurze und prägnante Tipps für die Verwendung des Produkts zu lesen sind.

 

 

 

Ausblick

Mit dem Ergebnis sind wir wirklich zufrieden und stolz. Ich denke, unsere Kunden werden es ebenso mögen. In den nächsten Wochen stehen bereits die nächsten geplanten Releases an, die unter anderem die Bedienung unserer Cloud betreffen. Mehr soll aber jetzt noch nicht verraten werden.

 

Sebastian Saemann
Sebastian Saemann
Head of Managed Services

Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.

The Need For Speed

Eine Sache, mit der man sich immer mal wieder konfrontiert sieht, sind „langsame Webinterfaces“: in erster Linie ist solch eine Aussage eine sehr subjektive Sache, und ohne Zahlen ist sie als Bugreport nicht übermäßig belastbar. Doch es gibt viele Tools die dabei helfen, aus dem Gefühl eine nachvollziehbare — und somit idealerweise leichter behebbare — Tatsache zu machen.

Ich für meinen Teil fange da ja gerne an, indem ich die Developer Tools des Browers (Chrome zumeist) und gerne auch im „Inkognito Mode“ nutze; der Reiter „Network“ zeigt sehr detailliert, was in welcher Reihenfolge geladen wird, inklusive Request- sowie Response Headers.

TTFB - Time To First Byte

Reiter „Network“ der Chrome Developer Tools

In obenstehendem Beispiel wird ersichtlich, dass moderate Zeiten verwendet werden auf die Namensauflösung, den initialen Verbidungsaufbau, das SSL/TLS-Handling und den eigentlichen Download der Seite. Was ins Auge springt – und mit mehr als zwei Sekunden auch wirklich schon signifikant ist – ist „TTFB (Waiting)“.

TTFB steht für „Time To First Byte“ und definiert sozusagen die Zeit die mein Browser darauf warten muss, das erste Byte vom Webserver zu erhalten. Die Praxisrelevanz, insbesondere für Suchmaschinen-Rankings, ist nicht unumstritten; man muss sich auch nicht verrückt machen um eine TTFB von 400ms auf 200ms zu drücken (es sei denn, man sieht es als sportliche Herausforderung).

Bei vollen zwei Sekunden verlässt man jedoch die Komfortzone von „nicht relevant“; Wartezeiten im Sekundenbereich machen die User überaus unglücklich, und sie können Akzeptanz, Klicks und schlimmstenfalls jede Menge zukünftiger Besuche kosten. Es kann sich also durchaus lohnen, an dieser Stelle Zeit zu investieren. Einen guten, wenn auch recht strengen Einstieg in die Thematik bietet die Analyse von Google PageSpeed Insights; andere Anbieter stellen eigene Analysetools zur Verfügung.

Nun stellt jedoch nicht jede Umgebung einen Browser nebst Developer Tools bereit; das Kommandozeilen-Tool cURL erweist sich in solchen Fällen eventuell als nützliches kleines Helferlein. Wie ich im Zuge meiner Analysen lernen durfte unterstützt cURL nämlich formatierte Ausgaben. Um dem Timing-Problem auf die Schliche zu kommen erstelle ich mir eine Datei namens curl-timing-template mit folgendem Inhalt:

time_namelookup: %{time_namelookup}\n
time_connect: %{time_connect}\n
time_appconnect: %{time_appconnect}\n
time_pretransfer: %{time_pretransfer}\n
time_redirect: %{time_redirect}\n
time_starttransfer: %{time_starttransfer}\n
———\n
time_total: %{time_total}\n

time_starttransfer entspricht hierbei „Time To First Byte“ und beinhaltet den Wert von time_pretransfer; die manpage von cURL gibt Aufschluss über alle verfügbaren Variablen sowie deren genaue Bedeutung (Stichwort „-write-out“). Im nächsten Schritt erfolgt der Aufruf der vermeintlich zu langsamen Adresse – natürlich unter Verwendung des eben erstellten Templates.

$ curl -w "@curl-timing-template" -o /dev/null -s https://example.com
time_namelookup: 0.002013
time_connect: 0.020424
time_appconnect: 0.076721
time_pretransfer: 0.076771
time_redirect: 0.000000
time_starttransfer: 13.158706
———
time_total: 13.158734

Autsch. Inzwischen liegt die Verzögerung bei ganzen 13 Sekunden – und es wird ersichtlich, dass das nicht durch die Namensauflösung (beispielsweise) verursacht wird. Die zielgerichtete Flaschenhalssuche kann nun also beginnen

Nicht selten sind Verzögerungen dieser Art abhängig von Uhrzeiten, Wochentagen oder ähnlichem; deshalb ist es praktisch, dass sich ein kontinuierlicher Test auf diese Art sehr einfach skripten, per Cron ausführen oder gar in andere Systeme integrieren lässt.

Marianne Spiller
Marianne Spiller
Senior Consultant

Nachdem sie über Jahre immer wieder für eine NETWAYS Mitarbeiterin gehalten wurde, hat sie im März 2020 ernst gemacht und wurde eine. Als Senior Consultant unterstützt sie fortan Professional Services. Ihre Freizeit widmet sie in weiten Teilen dem Schreiben, man findet sie aber auch häufig mit Kamera und Stativ auf unwegsamem Gelände.

Veranstaltungen

Di 18

Icinga 2 Fundamentals Training | Online

Mai 18 @ 09:00 - Mai 21 @ 17:00
Jun 15

stackconf online

Juni 15 - Juni 17
Jun 22

Ansible Fundamentals Training | Online

Juni 22 @ 09:00 - Juni 24 @ 17:00
Jun 22

Kubernetes Quick Start | Online

Juni 22 @ 09:00 - 17:00
Jun 25

Ansible AWX (Tower) Training | Online

Juni 25 @ 09:00 - 17:00