Seite wählen

NETWAYS Blog

Do Servers Dream of Electric Sadness?

Als Systemadministrator ist man oft mit einer Vielzahl von Fehlermeldungen konfrontiert, die manchmal klar verständlich, manchmal mehrdeutig und manchmal völlig nichtssagend sein können. Wichtig ist hierbei, sich nicht von der Meldung in der Herangehensweise an den Fehler beeinflussen zu lassen und somit von vornherein auf dem Holzweg unterwegs zu sein.

icingadbweb

Zwei Hosts down, oder nur redis und mysql?

In diesem Blogbeitrag werden wir die Bedeutung eines methodischen Denkens und eines gut ausgestatteten Werkzeugkastens für Systemadministratoren erkunden.

 

Kenne Deine Umgebung:

Für die korrekte Interpretation ist es nicht nur wichtig, seine Umgebung zu kennen, sondern auch zu wissen, welche Werkzeuge in dem persönlichen Werkzeugkasten vorhanden sind. Sieht der Fehler nach Schraube aus, ich halte allerdings einen Hammer in der Hand, wird der Fehler gerne als Nagel interpretiert.Beides hält ja irgendwie Dinge zusammen und mit ausreichend Ausdauer, bekommt auch ein Hammer mit einer Schraube eine Verbindung zustande. Die Schraubverbindung mit einem Hammer zu lösen ist hier allerdings schon wieder eine andere Geschichte.

Aufbau Deines Werkzeugkastens:

Der Werkzeugkasten eines Systemadministrators baut sich über viele Jahre Erfahrung zusammen, kann aber auch durch realitätsnahe Übungen erweitert werden, was dann auch eine gewaltige Zeitersparnis beim Lösungsweg mit sich bringt. Ein sehr sympathischer Ansatz ist der Advent of Code mit dem Fokus auf programmatischen Lösungen, um so auch eventuell eine neue Sprache näher zu beleuchten.

Realitätsnahe Herausforderungen:

Mit realitätsnahen Herausforderungen auf AWS-Root Servern locken dagegen die traurigen Server auf https://sadservers.com. In derzeit 20 unterschiedlichen Szenarien darf man, falls nötig auch mit Tipps, eine definierte Aufgabe via bash lösen. Während der Beginn und die Zeitvorgaben entspannt anfangen, wird es je nach Kenntnisstand ziemlich schnell ziemlich fordernd. Einen ersten Einblick bietet auch das zugehörige GitHub Repository

Austausch und Schulungen:

Wer danach oder währenddessen Interesse daran hat, den Werkzeugkasten über einen Monat hin weiter zu befüllen, sollte einen Blick auf https://linuxupskillchallenge.com/ riskieren. Auch Personen, die schon Jahrzehnte im Geschäft sind, erfahren bei solchen Challenges nicht nur neues, sondern auch der Austausch mit Gleichgesinnten hilft hierbei enorm. Wem das alles zu digital ist, findet vielleicht in unseren Schulungen und Events nicht nur sich selbst eher wieder, sondern auch mehr Gleichgesinnte.

 

Ein gut ausgestatteter Werkzeugkasten und ein methodischer Ansatz sind entscheidend für den Erfolg eines Systemadministrators. Indem Du Deine Umgebung kennst, Deine Werkzeuge verstehst und durch praktische Übungen und Herausforderungen Dein Wissen erweiterst, wirst Du in der Lage sein, Fehler effektiv zu lösen und die Herausforderungen Deines Berufs zu meistern!

Tim Albert
Tim Albert
Senior 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. Seit Anfang 2016 ist er bei uns tätig. Zuerst im Managed Services Team, dort kümmerte Tim sich um Infrastrukturthemen und den internen Support, um dann 2019 - zusammen mit Marius - Gründungsmitglied der ITSM Abteilung zu werden. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr – als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit...

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
Senior 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. Seit Anfang 2016 ist er bei uns tätig. Zuerst im Managed Services Team, dort kümmerte Tim sich um Infrastrukturthemen und den internen Support, um dann 2019 - zusammen mit Marius - Gründungsmitglied der ITSM Abteilung zu werden. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr – als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit...

Lessons learned – how not to make beginner’s mistakes: Fibre

Another entry of this somewhat cathartic short series. In the previous post, I already have included a lengthy introduction, so there is no need for this anymore.

Let’s dive directly into todays topic: Fibre

Fibre is easy: light goes in on one end and in a matter of nanoseconds reaches the other end of your cable. Voila, data transferred.

Always keep in mind that you can’t conduct electricity via your fibre installation. So you have to use some kind of media converter to let your data travel. A switch might serve the same purpose.

Everybody knows about the difference between multi mode and single mode fibre, right? Actually, you don’t necessarily need to know the exact difference. Just be aware to not mix them.

Not mixing means from start to finish. Just because there is a patch panel in between, you can’t magically switch from single mode to multi mode. And vice versa, obviously.

This concerns not only the fibre itself but also the transceiver which you have to plug into your active network component.

Be sure to always have the correct transceiver for your switch/firewall model. Avoid mixing SFP, SFP+, SFP WDM and SFP with RJ45 jack. Of course the difference multi mode ./. single mode still applies.

You might have heard of GBIC. You will know when you have to use it.

Also, have a look at DAC cabling for your system. Of course you use uniform hardware, don’t you?

Speaking of uniformity: you know exactly which kind of connector types you will need for your installation. If not, look closely and keep asking yourself why you can’t plug in your connectors.

Copyright: Twentieth Century Fox

Copyright: Twentieth Century Fox

 

 

 

 

 

 

On the other hand you might have to use adapting cables, as the preexisting installation tells you so. No, a knife won’t do the trick.

Also be prepared to disjoint your patch cables to switch a and b channels. Have fun rejoining them.

For having a colourful setup, make sure all your fibres come in different colours. There is a colour code in place, but how can you express your individuality best if not using colour?

As there is no interference between the optical medium and your ethernet cabling, there is no need to route your cables separately. Todays fibre isn’t as brittle as it has been in the previous millenium. You are free to pull or twist them – you might simply intertwine your fibre in your rats nest of Cat.7 cables.

This will save mm³ of space in your rack, and rack space is expensive! (cherry on top: try to match the colour of fibre and copper jackets)

To give your datacenter the last polish, you should have plasterboard (AE: drywall) all over the place. For the perfect finish, make sure, sanding takes place while you’re doing your fibre cabling.

Only this will guarantee best results of your cleaning kit.

(/sarcasm)

Tim Albert
Tim Albert
Senior 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. Seit Anfang 2016 ist er bei uns tätig. Zuerst im Managed Services Team, dort kümmerte Tim sich um Infrastrukturthemen und den internen Support, um dann 2019 - zusammen mit Marius - Gründungsmitglied der ITSM Abteilung zu werden. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr – als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit...

Lessons learned – how not to make beginner’s mistakes: Migrating server

At Netways we try to learn all the time. Often you can simply read man pages, change logs, or even tabtab through your shell command at hand.

Trainings and conferences are a bit more time consuming, but can offer you one priceless advantage: the direct communication with someone, who has seen several sides of the topic at hand. I think, you learn best from other peoples experiences – even more from the situations where failure ensued. Here it is critical to not only look at the failure itself, but why it occured and how it was finally resolved.

Using other persons failure as a mean to learn  might seem a bit cynically at first. In an ideal world, however, the same failure would only ocurr once.

So let’s begin with my contribution to a better world, maybe even as a start of a series. This entry is not meant as full post-morten per se, it only describes mistakes you can make and should avoid.

As many might know, our office moved. Having been 10ish years in our „old“ office, you might figure that quite a lot „historical infrastructure“ can grow in this time. Especially in an IT environment where everybody wants to try something new, better, and undocumented.

Being in the distinguished situation of having direct access to our DC via 1GBit-Fiber, it was possible to use some of our external IPs in our office. VLAN-Tagging, firewall policies, iptables rules – all well known and understood best practices. The services got installed, used and worked flawlessly for all the time and have lived happily ever after.

With the announcement of moving to the new premises, the blue sky became a bit hazy. We had to move all needed hardware devices (NASA could tell you how small and well hidden some of them can be) and also separate them from the unneeded devices. Todays story is about two specific systems, each consisting of two 1U server. Those were some of the systems which used external IPs to provide services to the public. They have been running flawlessly for quite some time and given their age, had started to develop some adorable quirks.

It was my task to move these „dear old ladies“ out of the cozy office into the cold, professional DC downstairs.

What harm can 4 old and lovable server possibly do, you might ask? The answer is: None, if you treat them the way they were used to.

First things first: How can you gain access to the DC? Is there a registration process, which has to be followed? How long does this take? Can you access the DC after business hours easily? (Hints: yes, long, no)

Also don’t try to rush things when it comes to shutdown the machines for moving  them. The machines owners like to what is going to happen.

Grab all the tools you will need to remove the server from your previous rack and install them in their new home (cordless screwdriver, all bits you can find)

Are all installation material available? This is not only referring to rack rails, but also cage nuts, screws (size matters) and front covers for feng-shui and air flow. (depends, mostly: no)

Cables! Just collect all the cables you need and then some. Usually, they will be too short. Too long is not an issue you can’t fix with zip ties (you will forget these)

Do you have network access in the DC for debugging, communication etc.? (Hint: depends)

Do you want to move more than one server? Be cautios and do them step by step. You’re absolutely allowed to install them all at the same time. Be aware you might experience crooked rails, incorrect cabling and other time consuming things.

When you have installed the machines, definitely take your time to check these with a KVM device. Whichever is in reach. (you guessed it: there won’t be any when you need them the most). Don’t rely on the machine and its fancy blinkenlights: Some may flash when everything is ok, some flash to indicate errors, some don’t flash at all.

Check all your cabling at least twice, give them a gentle pull – if they come lose, you have to start over again.

Take breaks between different machines. Either try to find a cool spot in the DC (haha) or get outside, have something to drink and return refreshed. The noise (ear plugs, ANC Headphones), temperature, confinement while working in the rack will wear you out eventually.

If you route the machines traffic through several VLANs, make sure all needed switch ports are tagged (or untagged? You decide!) and firewall policies applied for the new location.

Always have a piece of paper and a (working!) pen with you – it’s faster to scribble something on paper than to crawl through yor rats nest of cabling, climb over all the machines you’re up to install and then find your trusty notebook with dead battery.

Before you finally leave, make sure to give everything one last check and, if possible, communicate with the owners of the respective machines. Collect all the tools you brought with you. If you didn’t bring them but „found“ them somewhere and used them: make sure to return them.

If you run into any issues, make sure all colleagues you could ask for assistance are currently at the party you’re rushing to attend.

Also make sure to communicate only via phone, so you don’t leave any paper trail when it comes to DC access, network config or time accounting.

When you don’t experience some of these mistakes because of this post, this post was a success. Of course some points are missing (feel free to comment), but I hope the overall pattern is visible:

be prepared, double check and take your time

 

Oh, and don’t forget the key to your racks. There is just one key, right?

Tim Albert
Tim Albert
Senior 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. Seit Anfang 2016 ist er bei uns tätig. Zuerst im Managed Services Team, dort kümmerte Tim sich um Infrastrukturthemen und den internen Support, um dann 2019 - zusammen mit Marius - Gründungsmitglied der ITSM Abteilung zu werden. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr – als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit...

OSDC 2019 Part 2 – Automating patching, VMs in containers & much more

After having a really successful and sublime evening event on Tuesday, today was the last day of the Open Source Data Center Conference.

Reading all the #osdc tweets tells me that I missed a great conference. ?

— Marcel Weinberg (@winem_) May 15, 2019

Andreas Lehr and Rico Spiesberger showed off with their automated patch management using Ansible and Rundeck at Lidl and Kaufland.
Things to keep in mind:

  • rebooting bare metal takes time
  • firmware updates might change things
  • have enough space in /var/yum and /tmp -> might result in kernel panics (:

And why not doing a Live Demo at a production system and simply patch the spanish webshop?

Live demo at a new level: @crsp and @shakalandy patching the spanish shop live with the audience #osdc pic.twitter.com/EHa7nZJoPS

— Nicolai Buchwitz (@NicolaiBuchwitz) May 15, 2019

On the next slot, it was our pleasure to welcome Kosisochukwu Anyanwu with kinvolk.io. She showed us how to use KVM as a Hypervisor, running a VM in a Docker Container! Get in touch with her at @kosyfrances and feel free to ask her for their use case.

Nikhil Kathole presented how to simplify your IT Workflow with Katello and Foreman. You can use Foreman for provisioning, configuration and monitoring (to some extend) of your hosts. It also provides you with many plugins for flexibility for provisioning tools and infrastructure. If you want to manage your .rpms/.debs, katello should be your choice

A talk at #osdc about @ForemanProject by @NikhilKathole1 and missing #DirkGötz here

— Toshaan Bharvani (@toshywoshy) May 15, 2019

 

Troy Harvey started with tossing shirts and gave a quite interesting introduction into the concept of privacy. Privacy demands ethical behaviour of professionals and they should always try to automate things

3 Big Ideas: 1. Privacy has a strange history. 2. Privacy-first systems are designed by people with a professional ethic. 3. Privacy can be automated away. – @troyharvey from Carta #osdc pic.twitter.com/DiocjWGGhW

— NETWAYS Events (@NetwaysEvents) May 15, 2019

 

Furthermore, if you want to have to use slack, try to get a job at Carta.

Colin Charles closed the conference with mysql & mariadb security. Obviously breaches are bad and there are the issues you can easily avoid. Use TLS for replication – also update your instances!

I don’t know how you feel after these two days. But I feel like I want more of that! Save the date for next OSDC!

Goodbye! ??

See you next #osdc 17-18 June in Berlin

Save the date https://t.co/hYX8SlM2CA pic.twitter.com/ZawVzImVTg

— NETWAYS Events (@NetwaysEvents) May 15, 2019

 

 

Tim Albert
Tim Albert
Senior 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. Seit Anfang 2016 ist er bei uns tätig. Zuerst im Managed Services Team, dort kümmerte Tim sich um Infrastrukturthemen und den internen Support, um dann 2019 - zusammen mit Marius - Gründungsmitglied der ITSM Abteilung zu werden. In seiner Freizeit engagiert sich Tim in der Freiwilligen Feuerwehr – als Maschinist und Atemschutzgeräteträger -, spielt im Laientheater Bauernschwänke und ist auch handwerklich ein absolutes Allroundtalent. Angefangen von Mauern hochziehen bis hin zur KNX-Verkabelung ist er jederzeit...