Liebe Hersteller sogenannter "Security Appliances"…

Habt Ihr eigentlich den Arsch offen?
Ich hoffe, Ihr macht Witze. Denn, ernstgemeint können Eure Produkte kaum sein.

Fangen wir mal auf der Habenseite an:
Ihr habt HA- und Failover-Cluster. Bei Euch ist es möglich, sehr, fast beliebig, fein granulare Filterregeln zu definieren. Und meistens gibt es irgendeine mehr oder minder proprietäre SSL-VPN-Lösung, die Ihr in das Gesamtkunstwerk integriert habt.
Leider hört es da dann auch schon wieder auf.

Konfiguriert wird der ganze Kram sehr Windows-freundlich mit einer oft nur minimal übersichtlichen Klicki-Bunti-Oberfläche. Selbstverständlich ist diese Oberfläche nicht fähig, Massenvorgänge, wie etwa das gesammelte Anlegen von 20 oder 30 VLAN-Interfaces durchzuführen. Das muss mit diversen Klicks – eine sinnvolle Tastatursteuerung gibt's natürlich auch nicht – mühsam einzeln erledigt werden.
Vielleicht ein CSV-Import? So, als hilfreiches Feature für Netzwerker, die es gewohnt sind, ihre Geräte mit einer Scripting-fähigen CLI auf der selben Komplexitätsebene binnen Minuten konfigurieren zu können.

Ganz generell wäre es natürlich auch hilfreich, bei Clustern, egal welcher Couleur, eine ohnehin spiegelgleiche Einrichtung auch nur einmal vornehmen zu müssen. Oder sind Eure Entwicklungsabteilungen der Überzeugung, wer sich schon einmal die Mühe macht, 30 VLAN-Interfaces auf der einen Appliance anzulegen, der macht sich die gleiche Arbeit gerne auch ein zweites Mal?

Interessanterweise scheint mit steigendem Preis die Liste an wünschenswerten, und bei Nachdenken für ganze 5 Cent auch durchaus nachvollziehbaren Extras, drastisch zu länger zu werden. Bei Produkten mit geringeren Anschaffungskosten geht's schließlich auch.

Das Thema "SBOM" (Software Bill of Materials, die Liste an Drittprodukten in Verwendung auf den jeweiligen Appliances) und deren zum Teil katastrophal schlechten Versionierung lasse ich hier mal aus, da können sich andere besser aufregen. Nur soviel: Wozu genau werden eigentlich diese hunderte oder gar tausende Megabyte an Updatepaketen gebraucht, wenn nicht für die Aktualisierung der verwendeten Software?

 

Sprechen wir über die GUI, die zu benutzen ja leider unvermeidlich ist.
Gut, dass aussagekräftige Fehlermeldungen auch in einer GUI hilfreich wären, ist eine seit etlichen Generationen von Microsoft Windows in Vergessenheit geratene Weisheit – wahrscheinlich ist die Annahme, dass eine tatsächlich hilfreiche Aussage die armen Nutzer vor allem verwirren würde. "Gibt's sonst ja auch nicht."

Das Thema "Anordnung und Bedienung" der GUI gab's oben schon – warum brauche ich zwei GUIs, um ein Cluster-Interface anzulegen? Eine einzelne wäre zu einfach gewesen? Wahrscheinlich. Irgendwie muss ja der kostenpflichtige Einsatz von bezahlten Spezialexperten zur Einrichtung der Appliance begründet werden.

Allerdings stellt sich mir eine andere Frage, zu der ich ein bisschen ausholen muss.
Es gibt – durchaus verständlicherweise – Einstellungen, die nur sichtbar sind, wenn bestimmte Features überhaupt aktiv sind. Natürlich werden die erst eingeblendet, wenn der Haken am Feature gesetzt ist.
Soweit zur Theorie und daran ist auch nichts auszusetzen.
Nun stellt sich aber heraus, dass, auch wenn das Feature nie wirklich gestartet wurde, warum auch immer dessen Untereigenschaften trotzdem schonmal konfiguriert werden. Und plötzlich kollidiert das mit Einstellungen, die zuvor völlig reibungslos vorgenommen werden konnten?

Kurze Zwischenfrage: Wer programmiert eigentlich den Müll, den Ihr uns für mehrere Zehntausend harter Währung so andreht? Dressierte Affen an Schreibmaschinen? Denkende Menschen können das ja nicht sein, die würden so einen Scheiß nicht freigeben. Schon gar nicht in der x-ten Iteration.

Ich schweife ab.
Gut, der Haken für das Feature wurde gesetzt, wieder entfernt – und zwar bevor die Einstellung an den Cluster gesendet wurde! –, trotzdem ist die Einstellung auf dem Cluster aktiviert und nun muss das auf die gleiche krude Art und Weise rückgängig gemacht werden, um weiterarbeiten zu können. Vielen Dank auch.

Ich fasse zusammen:
Eine moderne "Security Appliance" lässt auf 08/15-Hardware hack-, weil updatebare, aber uralte Software laufen, versteckt durch eine hübsche, aber quasi unbenutzbare grafische Oberfläche, die Funktionen konfiguriert, die auch mit OpenSource-Software zu realisieren wären, sogar mehr noch, wenn das Geld für die Anschaffung der Appliance in entsprechende Lehrgänge investiert würde.
Und bei den Preisen für die "Support"-Verträge, wären auch ein bis zwei angestellte Mitarbeiter drin, die eine solche "Frickellösung" warten könnten.
Nur mit weniger Sicherheitslücken.

Um nicht nur schlechte Laune zu verbreiten, hier noch ein positiver Ausblick:
Es wird nicht besser werden.
Solange Software-Hersteller wie Microsoft nicht finanziell dafür bluten müssen, dass sie Katastrophen wie Windows, Outlook und ActiveDirectory programmieren und verkaufen; solange Hardware-Hersteller wie Intel nicht an Bugs wie Spectre pleitegehen; solange Versicherer zahlen, weil durch Ransomware geschädigte Kunden wertlose Zertifikate von inkompetenten Behörden über Schrottprodukte wie Eure "Securityappliances" vorzeigen können, solange werden Eure Produkte – und seien sie noch so wertlos, anstrengend und angreifbar – gekauft, eingesetzt, gehackt und trotzdem nicht ersetzt werden.
Insofern könnt Ihr Euch weiter auf Eurem indirekt vom Steuerzahler gepamperten Hintern ausruhen und auf die nächste Runde Supportverlängerungen warten.
Denn auch der nächste Zero-Day war wieder ein Softwareproblem. Kann man nichts machen.

Es hätte ein ganz normaler, gemütlicher, geselliger, angenehmer Abend im Kreise der Kameraden werden… äh… sollen.

Da war diese ganz normale Einsatzübung – nur verbunden mit den üblichen Kleinigkeiten: Der Hydrant ist verdreckt und geht nicht auf, der Schlüsselkasten zickt, sowas halt – sein sollen.
Und das war es auch. Übung beendet, Equipment verräumt, Fahrzeuge aufgefüllt und die Beteiligten entspannen bei Würstchen und Getränken.

Und dann klingelt auf der Wache das Telefon. "Nur das Telefon", denke ich noch. "Kann so schlimm nicht sein."

Doch, kann es.

Der Chef kommt zurück in die Versammlung und spricht nur zwei Worte: "Umziehen. Einsatz."

Dann bricht Hektik aus. Alle lassen alles stehen und liegen und joggen zurück in die Umkleidekabine. In einer freien Sekunde kann ich den Chef noch fragen, ob die Azubis mitkommen oder zurückbleiben sollen: "Azubis im Einsatzleitwagen", lautet die knappe Antwort und dann durchzucken die ersten blauen Blitze die Nacht.

Ich habe gerade noch Zeit, eine kurze Nachricht nach Hause zu schicken, dann muss ich zur Garage und die Tore aufmachen, während der Wagen vorfährt.
Dann heißt es Aufsitzen und auch unser Auto durchbricht Dunkelheit und Stille der dörflichen Nacht mit Blaulicht und Sirene.

Der Feuerschein zwischen den Feldern ist weit zu sehen – da fackelt es richtig. Innerlich verabschiede ich mich bereits von sämtlichen Feierabendplänen.
Es wird nicht das letzte Mal gewesen sein, dass meine Familie darunter leidet, das ich jetzt bei der Feuerwehr bin.

Und dann kommt die Meldung über Funk: "Brennt Unterstand in voller Ausdehnung." Das wird eine lange Nacht werden.
Vor allem, weil es da draußen kein Wasser gibt. Das ganze Wasser zum Löschen muss aus den Tanks der Fahrzeuge kommen. Und die sind letztlich endlich. So einem handelsüblichen Löschgruppenfahrzeug geht bereits nach ein paar Minuten unter voller Leistung die Luft, äh, das Wasser aus.
Kompliziert wird die Angelegenheit durch die Lage zwischen den Äckern: Es hat in den vergangenen Tagen ergiebig geregnet und entsprechend weich ist der Untergrund. So dauert es keine halbe Stunde, bis das erste Fahrzeug meldet, dass es sich festgefahren hat und nunmehr nicht mehr einsatzfähig ist. Glücklicherweise ist der Trecker bereits angefordert und das Fahrzeug nach kurzer Zeit wieder frei.

Und endlich trifft der Tanker aus der Nachbarstadt ein. Mit vorerst genügend Wasser – und einer langen Kette von Feuerwehrfahrzeugen, die ebendieses zur Einsatzstelle pumpen – wird jetzt gründlich gelöscht.

Trotzdem werden die Trupps unter Atemschutz fast schneller gewechselt als die Tanks nachgefüllt werden. Alle paar Minuten kommen zwei Leute mit Pressluftflasche auf dem Rücken aus den Rauchwolken und werden durch neue ersetzt. Dazu die Dunkelheit: Die Azubis sorgen für Licht und auch für Sitzplätze für die erschöpften Kameraden. Und nebenbei auch für allerlei Laufjobs.

Irgendwann um Mitternacht ist das Feuer im Großen und Ganzen aus.
Das Heu wird verteilt, das ausgebrannte Blech auf einem Haufen gesammelt und alles großzügig mit Löschschaum zugedeckt.

Endlich, es wird langsam kalt und müde sind wir auch, wird der Befehl zum Abbauen gegeben und ich habe mich nicht verschätzt: Um 1 Uhr morgens sitzen wir wieder in den Fahrzeugen.

Geputzt und Wasser nachgefüllt wird nicht auf der Wache, mehr in der Nähe meines Zuhause, trotzdem kann ich noch immer nicht absehen, wann das zuende sein wird. So lasse ich Jacke und Handschuhe zurück, stapfe nur im Hemd durch die eiskalte Frühlingsnacht nach Hause, wohl wissend, dass ich noch am nächsten Tag neue Einsatzkleidung brauche.
Und endlich kann meine Angetraute den ursprünglich schon vor Stunden geplanten Weg ins eigene Bett antreten.

Killing my network with VLANs

Yes, the semblance of "Killing Me Softly" is kind of intentional here.

Abstract: External replies were completely ignored by pppd causing my internet connection to fail completely. Diagnostic tools were of limited assistance because of information hidden in their output even though running in multiple levels of verbosity.
It was discovered a feature was not working as expected any longer, requiring a manual workaround outside of the faulty device.

This is a post-mortem to document what happened and what I've learned while diagnosing the problem.

This is not about a problem the regular home-user is likely to ever encounter.

Part 1: The Setup

To give a bit of an overview of the situation, it is necessary to note that my network is not the usual home-user WiFi with a dial-up internet connection. While my network does use a PPPoE dial-up DSL to connect to the internet, my local network setup requires the routing between LAN and WAN to be performed by a highly customizable system. The reasoning here is that I do have multiple internal networks separated from each other with different degrees of "separation" from "completely stand-alone" to "highly privileged access to protected interfaces and devices".
At this point it is just a side-note that part of my outgoing traffic utilizes a fixed IP address while most of all other traffic is NAT‑ed to my dynamic IP address changing every 24 hours.
Also, I have IPv6 rolled out over many of those separated networks, eliminating the need for NAT but still requiring a lot of sophisticated filter rules, most of which cannot be implemented with the regular consumer DSL WiFi router.

Unfortunately, despite my clear – and somewhat over-the-top – requirements, there's one thing I still need: A modem for my DSL landline. After using a bit overpriced OEM modem with a very limited feature set for the better half of the last two decades, with an upgrade to a faster contract that old device reached a hard limit. It was simply no longer capable of handling the new speed.

My decision fell on a device recommended by my ISP for its capable vendor, the feature set and its reported stability: The DrayTek Vigor130 ADSL/VDSL router. Among the features are its versatility, configurability, the closer-to-enterprise-grade built-in diagnostics and – and this is the important part – its ability to work as a PPP pass-through device, allowing me to terminate the dial-up connection on my own router as required by my aforementioned rather complex local setup.

Needless to say, it worked flawlessly for about five years.
Until…

Part 2: The Mishap

Software has bugs, software receives fixes and updates, which have to be applied. The sooner, the better. The same holds true for any embedded device firmware, even that of a pretty stupid DSL modem (whereas mine is not that stupid).
That much is a no-brainer, more so for devices connected to the inherently hostile environment we call "the internet".

One particular friday morning a couple of days of ago, I went on to install the latest firmware release on my DSL modem. That in and of itself was uneventful.
The image was copied to and installed on the device, it rebooted, loaded its config and was back available in practically no time.

That could have been the end of the (very boring) story.
Unfortunately, it was not.

The usual procedure for such a firmware upgrade is as described: Load the image to the device, await its request to be rebooted, acknowledge and reboot, wait for it to come back up, re-negotiate DSL parameters on the outside landline and at worst the local router's PPP connection has to be manually restarted. At best, it just comes back up and that's it.

Not this time.
This time, the connection went down and never came back. Instead, the router reported missing replies to its PADI connection queries.

Never too shy to blame coincidence I went on the phone quickly to request a port‐reset on the provider end to rule out the DSL access concentrator went haywire with my firmware upgrade.
My provider stated that the port had reported down with an error and it would require an on-site technician to fix it, yet he complied with my request and initiated the port‐reset.

It didn't work, my software still reported a timeout while waiting for replies to its queries.

With that, my internet was gone for the day.

Part 3: Troubleshooting.

I hate troubleshooting. (Imagine Agent Smith from the 1999 film "Matrix" here, saying "I hate this place …")

However, like it or not, the outside connection has to be fixed at some point. So I had to busy myself with troubleshooting it. Regardless of how much I hate it.

At least the setup allows for an easy tapping into the communication between the router, where the problem manifested itself by those dreaded "timeout" error messages and the modem. That should make it easier to pinpoint where the communication actually fails.

Naughty detail: My router is actually a virtual machine, which makes it even easier, because on the machine's host I can see frames the router's packet filter would drop, which would cause the frames to not show up in a dump running on the router itself.

So I fired two sessions of tcpdump on the wire: One on the router, one of the router's host to see what was actually exchanged through the modem.
And then the real dread set in: The router was sending out its queries and from the modem the replies were sent back. Worse still, those replies did not only appear on the host, they also appeared in the dump on the router meaning there was no packet filter rule dropping them. They got lost between the kernel and the pppd.

Fixing a misbehaving packet filter would have been easy. Frames being lost between kernel and userspace is a different story, it usually means a buggy software needs a fix and with the last release of pppd being from autumn 2021 it was unlikely I had missed an important update.

On the other hand: It all started with the firmware upgrade on the modem, so it is more likely the modem is the culprit and that's where I should look. But that also hasn't seen a recent update in the past three months.

So I began working through it: Downgrade, reconfigure, reboot, change network interfaces (yes, I've seen a kernel upgrade causing a network card to fail to work until an older kernel is booted), the whole she-bang.
To no avail. Packets were flowing out, answered from outside and then dutifully ignored.

One more test revealed the fact that the connection itself was not the problem: If I terminated the PPPoE session on the modem it worked as designed. The modem reported a successful login and a public IP assigned in no time.
That indicated the problem was on my end of the outlet.

First things first: Cancel the on-site technician who wouldn't be of much help if my modem was able to successfully connect but my router was not. That's obviously a problem with my setup and nobody but myself would be able to fix it, if it is fixable after all.

Second: If my modem can log in, I can haz internet. At least part of it.
It doesn't fix the issue with the rest of the installation but I can be back to download packages and search the web for possible solutions.
Of which there are few. It seems it either works completely or not at all. Most sites with the keywords I had available were just describing the intricacies of the point-to-point protocol and its fallacies when run over regular ethernet (what a regular DSL essentially is in the end), but not how to fix it, if, for some unknown reason, the flow of information ends at a usually unsuspected point along the line, as it did in my case.

Mentally, I had already settled with either buying a new device. Which would take its time, one because of the current global shortage of microchips, and second, because it wouldn't be easy to free the necessary funds to pay for those unavailable chips…
Or to figure out how to adapt my setup to the new situation, not something I was particularly keen of.

Part 4: One ray of light on the horizon

I have no clue why I did it, but on monday morning I restarted the router virtual machine and for a couple of seconds the regular and intended PPPoE session came back to life on the router. There was still hope around the corner. I just had to chase it down and grab it before it could evade.

So I deconfigured the PPPoE session on the modem to get its IP addresses back to my own router and rebooted the modem.

And the light went out again. The connection was gone and it did not come back.

This time I was desperate. Obviously my setup still worked. With all the latest software installed, with my old config active, it must be something I could handle, I just hadn't been able to put my finger on it. But the truth must be out there.

This time I took my even brighter flashlight.
tcpdump did not help, but Wireshark should be able to assist in finding where exactly communication got stuck. So, instead of letting pages and pages of tcpdump console output run past me, I decided to dump my connection attempts into a file for an in‐depth analysis with wireshark.

I should have done that three days ago.

Part 5: Nailing down the problem

I intended to have a deeper look into the conversation between my router and my ISP.
tcpdump showed my router sending the necessary frames for initiating the PPPoE session with ISP and the ISP's replies. Somewhere in those replies must be the answer toe the issue bothering me for the weekend. It should be easy to find when looking at one stream of frames.

Wireshark is a very powerful tool and following a communication stream in a dump of thousands of frames is one of its most basic features.
In the dump there were my requests and my ISP's replies. It should be quite easy to filter it all down to one stream and then read the details of the exchange to understand what goes wrong here. So I selected one of my requests and opted to filter for all PPPoE LCP frames.

And then it hit me, hard: With the filter in place, all my ISP's replies were suddenly gone from the display. All that was left were my requests. The problem was not inside the payloads, the problem was with the frames themselves! Something somewhere in the reply frames caused the kernel to misinterpret them and not relate them to the requests it had already sent out. Ouch.

From here on out it was quite simple: All PPPoE frames coming in from the ISP were carrying a VLAN tag. My frames did not. And that explained why sometimes I got a timeout waiting for PADO packets, most of the time I got timeouts waiting for LCP configuration replies and one particular time I got a running connection: The VLAN tagging had gone mad.

Excursion: The triple-play (now better named "double-play") feature of my ISP with Internet and streaming IPTV over the same wire requires the customer's regular internet traffic to be tagged with a VLAN id when leaving the modem over the DSL. Likewise the ISP sends its traffic back with the same VLAN tag. Some device on the customer end has to add the tag for outgoing frames and remove it from incoming traffic. In a regular consumer setup it is all done by the single WiFi router device: Decapsulating the ISP's VLAN‐tagged traffic, terminating the PPPoE session and pushing the remaining payload into the user's (W)LAN. And vice versa for outgoing traffic.

In my setup, my modem was tasked with doing the VLAN en-/decapsulation for the past couple of years, while my router did the rest. That had worked well all the time. And now it had stopped.

Part 6: Fixing the problem

Easier said than done.
The problem exists somewhere whithin the modem's firmware and I can't fix a binary blob from a taiwan-based vendor. Not in a couple of hours. Yet, if it is just the VLAN tag, that is one of my easier tricks.

First I did a cross-check, of course: I've fully deactivated the modem's VLAN‐tagging feature and looked at what effects that would have.
Easy enough it did what I expected it to do: Now the replies were gone entirely. They were no longer seen on the wire. So, the VLAN encapsulation is actually required (yes, it says so on the ISP's website, but I felt better making sure).

The next step was to add a sub-interface to my router's connection the DSL modem, one with the VLAN id my ISP wants to see on the wire and then tell pppd to use the new sub-interface as the base for its PPPoE session.

And that's it.
Within seconds the whole thing was fixed. The PPPoE session was back online and as fast and stable as it was before. End of story.

Part 7: Aftermath

One moment, please. There are some things to take away from this episode.

1. Know your toolkit!
   tcpdump is all good and well, but it has its limitations. One of which is the fact it doesn't show VLAN information unless specifically asked for it. Pumping up verbosity doesn't help here. Had I looked at the VLAN tags with the first run of tcpdump I wouldn't have spent a weekend contemplating alternatives.
   If tcpdump doesn't tell, let it dump into a file and use wireshark.
    
2. Coincidence is an asshole.
   It would have been easy if it were just a coincidence with a failed ISP port precisely at the time I was performing a modem firmware upgrade – and I've seen such a coincidence in my professional career, which had me pulling my hair out until it was figured it were unrelated events, the real issue actually happening a couple of seconds before the suspected culprit action. Yet, in most cases, it isn't coincidence. In most cases there is a string of causality which needs to be followed. A problem occurring right after such a firmware upgrade most likely has its root cause in that very upgrade.
    
3. Perform all possible cross-checks.
   Blaming an apparent problem on the professionals on the other end of the line is easy but it is as likely wrong as it is easy. If it has worked for years, why should they change anything? It is way more probable the problem is on the local end.
   Nevertheless…
    
4. Reach out for help.
   Supporters aren't happy to be called when there's actually nothing wrong. But they are eager to help. Otherwise they wouldn't be in that very position. Sometimes they might not be able to help but offer ideas.
   Also, once called, provide them with updates. Or even a resolution to the problem. If available they are now able to help the next customer with a similar problem.
   Notify vendors. In my case it probably is a bug introduced with some earlier firmware version, despite it is unclear which exactly, since a downgrade did not help. While a support ticket with the details might not cause immediate action vendors worth their money will use such findings to improve their products.

And that's the real end of this post-mortem.

Zabbix ist ein Hardware- und Dienstemonitoringsystem mit einer Fülle an Möglichkeiten zur Überwachung und Mitteilung, darunter unter anderem eMail, SMS und alles, was per Skript durchgeführt werden kann.

Eine weitere Option ist der Aufruf von Webhooks, über die REST APIs anderer Dienste angesteuert werden können.
Ein offensichtlicher Nutzen ist die Erstellung von Tickets in einem entsprechenden Ticketsystem, welches den Verlauf eines Dienstausfalls, die Arbeiten daran und die Wiederherstellung besser oder zumindest anders nachverfolgbar macht, als eine Reihe von eMails in irgendeinem Postfach.

Für Redmine bietet der Hersteller von Zabbix eine fertige Konfiguration an, ich persönlich halte die jedoch für unvollständig, da mindestens das automatische Schließen eines erzeugten Tickets fehlt.

Und damit beginnt Teil 1 dieser Geschichte.
Ich mag es nicht, wenn Automaten automatisierbare Aufgaben nicht automatisch erledigen.

Folgende Punkte sollte meine Erweiterung mehr (oder besser) können:

• Zuweisung des Tickets an die zuständige Person
• Statusänderung des Tickets bei Statusänderung des Problems in Zabbix
• Änderung der Priorisierung bei entsprechender Änderung in Zabbix

Das Erste erwies sich bereits als Aufgabe, nämlich zu ermitteln, wer das genau ist. Glücklicherweise ist die Redmine-API dafür vollständig und entsprechend gut dokumentiert, sodaß es am Ende eher eine Aufgabe war, die Feinheiten von JavaScript zu erlernen, um es nicht nur funktional, sondern auch schnell und zuverlässig, sprich: fehlertolerant, zu realisieren.
Ich mußte zusätzliche Funktionen schreiben, um IDs zu ermitteln, die dann wiederum in die API gefüttert werden mußten.

Außerdem gibt es bei Zabbix' Mittelungseinstellung ein grundsätzlich zu befüllendes Feld für das Ziel der Benachrichtigung, welches von der Beispielkonfiguration geflissentlich ignoriert wird - Zwangsfelder mit Nonsense zu füllen widerstrebt mir aber auch.

Damit wurde dann auch der Teil der Projektzuweisung entsprechend abgewandelt.
Schlußendlich ist der Webhook nun in der Lage, mit dem selben API-Key (das heißt, in der selben Redmine-Instanz) Zabbix-Probleme an verschiedene Personen in unterschiedlichen Projekten zuzuweisen.

Nächster Schritt: Tickets schließen, wenn das Problem gelöst ist.
Je nach Gusto des Nutzers wird hierfür ein weiterer API-Aufruf gebraucht, um die zugehörige ID des Zielstatus' des Tickets zu ermitteln, wenn diese nicht direkt in der Zabbixkonfiguration hinterlegt ist. Nach der vorangegangenen Arbeit an der Adressierung des Tickets war dies nunmehr allerdings nur noch eine Fingerübung.

Noch einfacher war es dann, die Änderung der Priorität in Redmine abzubilden.
Da für das ursprüngliche Setzen der Priorität beim Erstellen des Tickets bereits eine Zuweisung zwischen Dringlichkeitsstufe bei Zabbix und Prioritäten-ID in Redmine geben muß, bot es sich an, diese erneut zu benutzen und bei einem Update erneut in das Ticket zu füttern, was eine Änderung der Priorität in Redmine bewirkte.

Soweit, so gut. Es hat ein paar hundert generierter und dann gelöschter Tickets gebraucht aber es funktioniert jetzt und es gibt eine offene Anfrage bei Zabbix, das Beispiel zu aktualisieren, bislang ist da jedoch noch nicht viel passiert.

Teil 2: Gitlab

Redmine ist nicht das einzige Ticketverwaltungssystem, Gitlab ist ein weiteres.
Und Freunde von mir baten mich darum, meine Arbeit für Redmine doch auch mit Gitlab zu realisieren.

Leichter gesagt als getan.

Gitlab macht einige Dinge in Bezug auf Standardtickets ganz anders als Redmine.
Zunächst einmal gibt es keine Prioritäten. Gitlab realisiert sämtliche derartigen Zusatzinformationen über frei definierbare Labels, was zwar sehr flexibel, gleichzeitig für die Nutzung über eine API auch sehr anstrengend ist, da es überhaupt keinen Weg gibt, über die API irgendwelche Vorabinformationen zu erfragen - alles muß beim Aufrufer hart codiert werden.
Kommentare werden nicht als Notiz im Ticket selbst gespeichert, vielmehr handelt es sich um ein global verfügbares Objekt, das lediglich an ein Ticket gebunden werden kann.
Und diese Tickets sind Projekt-lokal, was zu zusätzlichem Aufwand beim Wiederaufruf des Tickets für Ergänzungen und andere Vorgänge bedeutet.

Und dann gibt es da noch weitere Fallstricke in der API.
Statt auf Anfrage einfach alle Ergebnisse zum Selbstdurchsuchen zurückzuliefern, werden maximal 100 Einträge geliefert - "zur Ressourcenschonung" heißt es. Obwohl es jahrealte Anfragen nach einer Möglichkeit zur Abschaltung dieser Zwangsbeschränkung gibt, hat sich da nichts bewegt.

Das heißt im Umkehrschluß, daß die Projektsuche zur Ermittlung der benötigten ID nun zwangsläufig von Gitlab ausgeführt wird, mit der entsprechenden Einschränkung der Suche in der API. Zabbix könnnte theoretisch nach beliebigen Eigenschaften eines Projektes und deren Kombination suchen, die Suche über die Gitlab-API beschränkt sich auf den Projektnamen.
Die Alternative besteht darin, eine im Vorfeld unbekannte Anzahl an Anfragen an die API zu stellen, um die gesamte Projektliste zu erhalten.

Da, wie oben erwähnt, Kommentare in Tickets nicht per se eine Ticketaktualisierung darstellen, braucht Gitlab, anders als eben Redmine, beim Ticketabschluß mit Kommentar - und das ist, was bei Zabbix grundsätzlich geschieht - mindestens zwei API-Aufrufe: Einen für den Kommentar und einen für das Update des Tickets.

Und zum Schluß noch die Krönung des Ganzen: Labels.
Labels sind eine sehr flexible Methode, Tickets zu markieren und zu filtern, auch mehrfach. Labels erfodern aber, anders als eine Liste von Prioritäten, eine große Menge Eigendisziplin der Anwender, seien es nun menschliche oder programmierte. Minimal anders geschriebene Labels begründen ein neues Label und passen auch nicht auf eventuell bereits vorhandene Filter.

Das allein macht diese Labels zu einem sehr zweischneidigen Schwert - sie sind ein sehr mächtiges Werkzeug, aber wie alle mächtigen Werkzeuge machen sie es auch einfach, sich einen blauen Daumen zu holen.

Das macht sie hier aber keiner Erwähnung wert - bei programmierten API-Aufrufen werden die zu verwendenden Labels fest eingestellt und damit sind sie verlässlicher als durch Menschen vergebene Markierungen.
Wäre da nicht… die Dringlichkeit von Zabbix-Problemen.

Da Gitlab, anders als Redmine, für seine Tickets keine Dringlichkeitsstufen vorsieht - überhaupt sieht Gitlab für seine Tickets so gut wie gar keine Zusatzinformationen vor -, muß die Abbildung der Dringlichkeit von Zabbix-Problemen in Gitlab-Prioritäten über Labels erfolgen.
Bei der Erstellung ist das trivial: Anhand der Dringlichkeitsstufe wird ein Label ausgewählt, in das neue Ticket eingetragen und damit könnte der Fall bereits erledigt sein.

Allerdings kann die Dringlichkeit eines Zabbix-Problems in Zabbix sowohl nach oben, als auch nach unten geändert werden, von Zabbix erstellte Tickets sollen vielleicht eine eindeutige Markierung erhalten, um danach zu filtern und vielleicht soll, wenn Zabbix das Problem als behoben meldet, eine weitere Markierung hinzugefügt werden, um solche Tickets aus dem Filter auszuschließen.

Damit geht es neben dem Festlegen von Labels nicht mehr nur um das Setzen eines Wertes, sondern auch um Hinzufügen und Ersetzen.

Die Dokumentation der Gitlab-API spricht davon, daß Labels als Folge kommagetrennter Wörter in einem einzigen Wert zu übergeben sind, um sie im Ticket festzu legen.
Um sie nun aber zu ändern, müssen zunächst die gerade gesetzten Labels abgerufen werden. Die Erwartungshaltung wäre natürlich (zumindest ist das bei mir so), daß die aktiven Labels eines Tickets in exakt der selben Form ausgegeben werden, wie sie zum Setzen eingetragen werden müssen, als einfache Reihe kommagetrennter Wörter.

Nicht so bei Gitlab.
Gitlab gibt die aktiven Labels eines Tickets als Sammlung einzelner Wörter aus, nicht als Reihe kommagetrennter Wörter, woraus sich die Notwendigkeit einer weiteren Wandlung ergibt.

Mir stellt sich die Frage, wer solche Inkonsistenzen in einer API absegnet.

Oh, ach so: Gitlab kennt eine Unterart von Tickets, die "Incidents", die eigentlich genau das können, was die Tickets in diesem Fall nicht beherrschen.
Allein, sie sind nicht über die API erstell- oder änderbar. Schade.

Es hätte so einfach sein können:
# apk update
# apk upgrade
# reboot

Es hat nicht sollen sein.
"Kommt davon", könnte es heißen. "Kommt davon, daß die Dokumentation nicht gelesen wurde."

Stimmt schon, dafür werden Handbücher geschrieben.

 

Problem No. 1: Alter Kern in neuen Schläuchen

Ich hatte nicht berücksichtigt, daß diese Distribution bei Kernel-Updates das /boot nicht von sich aus einbindet. In der Folge ist der neue Kernel, nebst Bootloader, einfach nie gestartet worden. Woraus sich dann schließlich auch ergab, warum weder Netzwerk noch über Remotekonsole emulierte Tastendrücke bis zum Betriebssystem durchschlugen.

Drei vergebliche Startversuche und zwei Neustarts mit der Live-CD später war dann irgendwie klar, daß es da ein Mismatch zwischen gestartetem und laut Paketmanager installiertem Kernel gibt - als das dann korrigiert war, funktionierte der Rechner erstmal wieder so, wie er sollte.

Die dafür erforderliche Prozedur war erschreckend trivial:

1. Bootpartition außerhalb von /boot ins Dateisystem einhängen
2. Dateien aus dem falschen /boot in das richtige kopieren
3. chroot in das Betriebssystem und grub-install (wahlweise vergleichbares für den eigenen Bootloader) aufrufen
4. Dateisysteme aushängen und System neu starten

Dann lief's erstmal wieder.

Bis…

 

Problem No. 2: Neue Dienste starten nicht

Bis sich herausstellte, daß der zentrale Dienst der Virtualisierungsumgebung ums Verrecken nicht anspringen wollte.
Er wurde zwar in der Prozeßliste geführt, hat sich aber offenbar an irgendeiner obskuren Stelle verklemmt und war auch mit gutem Zureden nicht mehr zur Zusammenarbeit zu bewegen.

Die Suche dauerte drei Stunden und am Ende habe ich den Versuch aufgegeben.

Ich verwende die libvirt, um eine Reihe von voneinander unabhängigen virtuellen Maschinen auf dem Host zu verwalten (die Langstreckengurke ist eine davon). Hierfür werden von libvirt eine Reihe Dienste angeboten, ein monolithischer, der die nötigen Komponenten bei Bedarf nachläd und aktiviert, sowie eine Reihe "modularer" Dienste, die vom Systemadministrator einzeln gestartet werden müssen und dann jeweils eigenständig eben jene Komponenten anbieten.

Offenbar funktioniert der monolithische Dienst seit dem jüngsten Distributionsupgrade nicht mehr zuverlässig und so fiel die Entscheidung, die modulare Variante zu verwenden.

Um 2:00 morgens. Nach einem Arbeitstag.
Nicht soooo schlau.

Denn natürlich bedurfte es auch hier einiger Anläufe, bis alle Dienste zuverlässig liefen und die für den Fuhrpark an virtuellen Maschinen nötigen Komponenten bereitstellten.

 

Fazit

Es funktioniert jetzt wieder. Ich werde irgendwann nochmal einen Neustarttest machen müssen, ob die virtuellen Maschinen auch ohne manuellen Eingriff nach einem Systemneustart sauber wieder anfahren. Aber nicht heute und auch nicht morgen.

Einige der Dienste müssen noch sauber(er) konfiguriert werden, da fehlen im Augenblick noch Zugangsbeschränkungen.

Nach müde kommt doof!

Mein persönlicher Tipp: Arbeitet niemals übermüdet, es wird nicht besser, es passieren eher nur noch mehr Fehler.

Die Downtime war für 90 Minuten angesetzt und hat am Ende knapp sechs Stunden gedauert. Natürlich waren die Uhren der nur angehaltenen, aber nicht neu gestarteten virtuellen Maschinen komplett daneben und liefen allesamt rund sechs Stunden nach. Eine Zeitspanne, die der übliche NTPd nicht in wenigen Minuten aufholt, dafür lässt er sich eher einen Tag lang Zeit. Oder mehr. Entsprechend war noch ein manuelles Nachstellen der VM-Uhren fällig.

Und so waren die Arbeiten erst um 3:00 Uhr morgens fertig.

Mal sehen, ob ich was gelernt habe.

Die zweite Woche der Corona-Krise ist um.

In der Geschichte - sofern es denn noch eine geben wird, angesichts der Klimakatastrophe - wird es wohl heißen, der Beginn der zwanziger Jahre des 21. Jahrhunderts sei markiert vom weltweiten Ausbruch einer hochansteckenden Viruserkrankung, SARS-CoV-2.

Begleitet von einem messbaren Anstieg der Luftqualität in den Städten, sowie dem Zusammenbruch des neoliberalen Kapitalismus'.

Ich darf noch träumen.

Jetzt, am Beginn des Ausbruches, stehen weder Impfstoff noch Medikamente zur Verfügung und das Beste, was bei schweren Verläufen getan werden kann, ist, den Betroffenen mit Symptomen so gut als möglich zu helfen. Das ist möglich, weil unsere Medizintechnik entsprechend weit fortgeschritten ist, aber Todesopfer kostet es trotzdem. Und letztlich stehen von den nötigen Geräten und dem ausgebildeten Personal auch nicht genug zur Verfügung, um wirklich allen helfen zu können.

Daher haben die Regierungen vor zwei Wochen eine weitgehende Unterbrechung des öffentlichen Lebens verfügt. Schulen und Kindergärten wurden unbefristet geschlossen, Versammlungen und Veranstaltungen - öffentlich und privat - mit mehr als drei oder vier Teilnehmern untersagt, Sportereignisse verschoben oder gleich ganz abgesagt und Urlaubsreisende nach Hause geschickt.
Gearbeitet wird, wenn überhaupt noch, im Wesentlichen von zuhause aus, zumindest dort, wo das möglich ist.

Die Archive der Fernsehsender werden es zeigen: Ab der zweiten Woche Corona finden sämtliche Unterhaltungssendungen, live oder aufgezeichnet, komplett ohne Publikum statt, eventueller Applaus kommt aus der Konserve, ja sogar die Gäste bleiben zuhause und werden per Videokonferenz zugeschaltet.
Eine ziemliche skurrile Situation, angesichts der 30 Jahre Geschichte der TV-Unterhaltung.

Allerdings gibt es, neben dem kulturellen und politischen Einschlag der Krise, deren Folgen für die gesamtgesellschaftliche Entwicklung noch gar nicht absehbar sind, noch ganz praktische Auswirkungen: Durch verfrühte und überflüssige Hamsterkäufe sind einige Lebensmittel im Moment streckenweise schwer zu bekommen und das erzwungene dauerhafte Zusammenleben von Familien in den eigenen vier Wänden stellen Beziehungen auf eine harte Probe, von Patchworkfamilien, bei denen Eltern und Kinder zum Teil getrennt voneinander leben, ganz zu schweigen.

Und die Berichte aus den Krankenhäusern sind nicht gerade ermutigend.

Mythen über IPv6 und deren Wahrheitsgehalt.

 

IPv6 ist komplizierter zu nutzen

Wahr ist: Wer keine Software schreibt, wird kaum einen Unterschied bemerken. Dann besteht höchstens ein Unterschied bei der Konfiguration von Diensten im Netzwerk.
IPv6 Adressen sind deutlich länger (128 bit im Vergleich zu 32 bit bei IPv4), deren einzelne Segmente mit Doppelpunkten (':') statt Punkten getrennt werden. Das kollidiert mit dem üblicherweise verwendeten Trennzeichen zwischen Adresse und Portnummer, ebenfalls einem Doppelpunkt. Da Portnummern kleiner als 10000 nicht von einem IPv6-Adressoktet zu unterscheiden, dort aber die meisten statischen Dienste untergebracht sind, muß in diesem Fall die Adresse anders abgesetzt werden. In aller Regel wird eine IPv6-Adresse in der Konfiguration in so einem Fall durch eckige Klammern eingefaßt, die Portnummer folgt wie gehabt getrennt mit Doppelpunkt auf die schließende Klammer.

Im DNS gibt es einen neuen Recordtyp, AAAA, der für IPv6-Adressen zu verwenden ist.
 

IPv6 macht meine Geräte problemlos erreichbar

Wahr ist: Bei IPv6 entfällt die Netzwerkadressübersetzung ("NAT").
Tatsächlich kann jedes IPv6-Gerät, auch im LAN hinter dem DSL-Router, aus dem Internet direkt erreichbar sein, das beträfe dann auch eventuell offene Dienste, die nicht zum Internet hin offen sein sollten.
Dies hängt allerdings zu einem wesentlichen Teil an der Gerätekonfiguration. Ein Endgerät, das gar keine Dienste anbietet, würde höchstens auf Pings antworten. Lokal angebotene Dienste können über deren Konfiguration üblicherweise auf die lokalen Adressbereiche beschränkt werden oder ein lokaler Paketfilter kann verwendet werden, um diese Beschränkung durchzusetzen, wenn der Dienst selbst dafür nicht konfiguriert werden kann.

Dazu kommt der DSL-Router, der in aller Regel so konfiguriert werden kann und sollte, daß eingehende Verbindungen, außer zu entsprechend freigeschalteten Endgeräten und Diensten, gar nicht zugelassen werden.
Diese Verbindungsüberwachung ("SPI") findet notwendigerweise auch bei der von IPv4 bekannten NAT statt, bei IPv6 nur mit dem Unterschied, daß der Router eben diese Adressübersetzung (und für die andere Richtung die Rückübersetzung) nicht durchführen muß.
Ebenso können auf dem Router natürlich auch ganze Adressbereiche blockiert werden, sodaß sie gar nicht mehr aus dem Internet erreichbar sind.
 

IPv6 macht mich nachverfolgbar und identifizierbar

Wahr ist: Mit IPv6 entfällt der oft noch stattfindende tägliche Wechsel der öffentlichen IP-Adresse.
Viele große Provider führen alle 24h eine Zwangstrennung ihrer Kunden durch, bei der Wiederverbindung wird eine neue öffentliche IPv4-Adresse vergeben, die alte wird an einen anderen Kunden neu vergeben. Dieses Vorgehen soll wohl auch dazu dienen, Kunden davon abzuhalten, kostengünstige Privatanschlüsse für gewinnbringende Dienstleistungen im Internet zu verwenden - hierfür sollen bitte deutlich teurere Geschäftskundenverträge abgeschlossen werden, bei denen in der Regel sowohl die Zwangstrennung entfällt, als auch die zugewiesene öffentliche IPv4-Adresse statisch ist und bei Wiedereinwahl erhalten bleibt.

Das ist aber mitnichten ein Sicherheits- oder gar Anonymisierungsfeature, es ist schlicht Produktpolitik des Providers. Die geltende Rechtslage (in Deutschland) sieht vor, daß die Provider ohnehin für mindestens sieben Tage speichern müssen, wem welche öffentliche IP-Adresse zugeordnet ist und die Sicherheitsbehörden von Bund und Ländern können diese Information jederzeit abfragen.

Internetdienstanbieter, die ihre Nutzer verfolgen wollen, verwenden dafür im Zweifelsfall andere Technologien, die unabhängig von der benutzten IP-Adresse das Endgerät und im Zweifelsfall auch dessen Nutzer mehr oder minder eindeutig identifizieren - ein Wechsel der für den Anbieter sichtbaren IP-Adresse macht für diesen keinen Unterschied.

Wer sich anonym oder wenigstens pseudonym im Internet bewegen will, sollte dafür entsprechende Tools, wie z.B. den ToR-Browser verwenden. Script- und Adblocker tun ein Übriges.
 

IPv6 ist komplexer einzurichten

Wahr ist: IPv6 kennt mehrere Methoden, Endgeräte zu konfigurieren, mit unterschiedlichen Geschmacksrichtungen, Features und damit einhergehenden Notwendigkeiten.
Wer eine aufwendige Einrichtung mit mehreren Netzen, handvergebenen Adressen und -bereichen anstrebt, der hat mit IPv6 tatsächlich zusätzliche Hausaufgaben, während das Standardsetup mit einem einfachen LAN hinter einem Providerrouter dürfte in aller Regel ohne zusätzlichen Konfigurationsaufwand auskommen.
 

IPv6 bringt keine Vorteile

Wahr ist: Dienste, die über IPv6 nicht erreichbar sind, brauchen entweder IPv4 oder eine Umsetzung beim Provider.
Andersherum gilt allerdings: Dienste, die über IPv4 nicht erreichbar sind, können auch mit provider-seitiger Umsetzung nicht erreicht werden. In diesem Sinne ist das tatsächlich ein Henne-Ei-Problem: Solange nicht alle Endgeräte IPv6 unterstützen, gibt es keinen zwingenden Grund für Diensteanbieter, den Zusatzaufwand für IPv6 zu betreiben, was wiederum einen zwingenden Grund darstellt, jedem Internetnutzer immernoch eine IPv4-Adresse bereitzustellen. Diese sind jedoch inzwischen seit mehreren Jahren vollständig vergeben, sodaß neue Internetnutzer nur noch mit großem Aufwand an eine dieser Adressen gelangen können. Schon jetzt haben mobile Geräte in den Handy-Netzen keine eigene öffentliche IPv4-Adresse mehr, hier kommt im großen Stil NAT zum Einsatz, da für die Masse an Geräten nicht mehr genug Adressen zur Verfügung stehen.

Irgendwo muß angefangen werden, insofern sollten angebotene Dienste, sofern die Software es unterstützt und der Provider es anbietet, auch über IPv6 erreichbar sein und Nutzer, die die Möglichkeit haben, sollten ihre Geräte über IPv6 anbinden.

Eine Hassliebe, denke ich.

 

UEFI und die Linux-Gemeinde

UEFI wird, zumindest in vielen Tutorials für verschiedene Linux-Distributionen, ziemlich zurückhaltend behandelt. Der Grund dafür dürfte darin liegen, daß UEFI bei OpenSource-Verfechtern unbeliebt ist. Und das ist auch nachvollziehbar: Inzwischen laufen unterhalb des Linux-Kernels neben der üblichen Gerätefirmware je nach System zusätzliche Betriebssysteme, die auch nicht all zu leicht loszuwerden sind.

Für aktuelle Intel-CPUs ist das zumindest die Management Engine, ohne die die CPU nichtmal anspringt und eben UEFI, der Nachfolger des BIOS, welches sich ja noch nach dem Laden des OS aus dem Speicher zurückzog.

Das macht es für Verfechter der "Meine Hardware, (ausschließlich) meine Software"-Sicht schwer, mit UEFI überhaupt warm zu werden, geschweige denn, darüber mal Tutorials zu schreiben.

Grundlagen

Soweit ich sie verstanden habe…

UEFI ist das "Unified Extensible Firmware Interface" und hat das alte BIOS inzwischen weitgehend ersetzt. Ein eventuell noch aufrufbarer "Legacy" Mode emuliert nur noch ein BIOS, dennoch wird auch im Legacy mode weiterhin das UEFI ausgeführt.
Im BIOS waren viele Dinge hart codiert - daher die Bedingung, daß es nur eine "aktive" Bootpartition pro Festplattenpartitionstabelle geben durfte; entsprechend, wo der Bootloader zu suchen und wie er aufzurufen war. Daher war BIOS auch Dateisystemagnostisch, solange ein passendes Binary mit einem ausführbaren Einsprungspunkt im richtigen Sektor der zu startenden Festplatte abgelegt war, konnte BIOS dies ausführen und dann die Gesamtkontrolle abgeben.

UEFI macht das anders.
Je nach Hardwarehersteller bietet UEFI Unterstützung für verschiedene Dateisysteme, mindestens aber wird FAT32 ("vfat") angeboten.
UEFI sucht auf den verfügbaren Datenträgern entweder nach aktiven Boot-Partitionen, für Datenträger mit BIOS ("msdos") Partitionstabelle oder nach speziellen EFI-Systempartitionen ("esp") bei den modernen GUID-Partitionstabellen ("gpt"), die bei Datenträgern oberhalb von 2TB Größe zwangsläufig genutzt werden müssen.

Im ersten Fall wird das alte BIOS-Bootloader-Verhalten verwendet, sprich: Das Binary im Bootsektor der aktiven Partition einer BIOS-partitionierten Festplatte gestartet.
Im zweiten Fall wird UEFI versuchen, das Dateisystem der ESP zu lesen und dort nach den konfigurierten Loadern suchen.

Wird der im UEFI hinterlegte Loader auf der ESP gefunden, wird er geladen und ausgeführt - was dann in aller Regel den regulären Start des Betriebssystems nach sich zieht.
Es kann aber auch sein, daß der Loader "einfach nur" ein Update der Firmware des unterliegenden Systems ausführt.

SecureBoot

Natürlich macht sich keine Firma überflüssig viel Arbeit und naben dem unangenehmen Umstand, daß schlicht absehbar war, daß die msdos-Partitionstabelle irgendwann die Festplattengrößen - es gibt heute SSDs im 2,5-Zoll-Format mit >15TB Speicherkapazität - nicht mehr würde handhaben können, gab es auch den Anspruch der Unterhaltungsindustrie, daß Computer doch bitte nur verifizierte Software ausführen mögen, um das Kopieren der hochauflösenden Hollywood-Blockbuster zu verhindern.

Die Geburtsstunde von SecureBoot.
Während BIOS einfach nur ein Stück Code von einem wohldefinierten Bereich der Festplatte lud und diesen dann zur Ausführung brachte, war UEFI plötzlich in der Lage, zu prüfen, was genau da eigentlich gerade geladen und ausgeführt werden sollte - und die Ausführung auch zu verweigern, wenn es zwar ausführbar ist, aber bestimmte Bedingungen nicht erfüllt.
Der Vorteil sollte - neben der Befriedigung der Paranoia der MPAA - auch sein, daß Nutzer, bzw. IT-Abteilungen, sicherstellen können, daß nicht unterhalb der wirklichen Betriebssystems irgendwelche Schadsoftware Passwörter und Festplattenverschlüsselungen abschnüffelt. - Nicht, daß UEFI und die noch darunter laufende Intel-ME nicht ihrerseits angreifbar und zu genau diesem Zweck nutzbar sind. Von den CPU-Bugs Spectre und Meltdown ganz zu schweigen.

An dem Punkt setzte dann der wirkliche Hass der Linux-Gemeinde gegen UEFI ein - weil nämlich ein PC mit aktiviertem SecureBoot die Zusammenarbeit mit den bisherigen Bootloadern stumpf verweigern würde. Die einzige Option, den Linux-Kernel in so einem System zu laden, wäre, eine gültige Signatur für den Bootloader zu bekommen, an die aber natürlich nicht so einfach dranzukommen ist - ganz zu schweigen von dem Fall, daß das Binary gar nicht direkt vom Hersteller bzw. Softwareautor kommt, sondern, wie z.B. bei Linux-from-Scratch oder Gentoo, schlicht selbst erstellt wird.

Tatsächlich ist es wohl gelungen, einen Stub signieren zu lassen, ein Stück Software, welches unveränderlich bleiben mußte, aber immerhin von UEFI mit aktiviertem SecureBoot ausgeführt werden würde und seinerseits dann den regulären Bootloader starten könnte.
Manche PC-Hersteller waren auch einsichtig und haben ihrem UEFI eine Option hinzugefügt, die ab Werk eingebauten SecureBoot-Zertifikate durch eigene zu ersetzen - womit der Nutzer/Eigentümer dann die Möglichkeit bekam, seine eigenen Schlüssel und Zertifikate zu erzeugen, im UEFI zu hinterlegen und seinen Linux-Bootloader bzw. Kernel selbst zu signieren.

Ende der Vorrede.

Linux-Kernel

Der Linux-Kernel bietet eine Option, das erzeugte Image mit einem EFI-Stub zu versehen. Im Prinzip bedeutet das nichts anderes, als daß das (komprimierte) Image für den Bootloader den erforderlichen Code enthält, um es für UEFI ausführbar zu machen.
Es reicht, einen solchen Kernel auf der ESP abzulegen und im UEFI als Bootoption einzutragen.

Damit könnte die Geschichte für den Linux-Kernel an sich schon zuende sein, wäre da nicht ein großes Aber.

Heutzutage übergeben Bootloader eine ganze Reihe an Parametern an den Kernel, manches davon weniger nötig als anderes, gebraucht wird aber immer das root-Device, die Festplattenpartition, in der der Kernel nach dem - ebenfalls zu spezifizierenden - Init-Binary sucht.
Interessant wird es, wenn der Bootloader eine Initramdisk mit übergibt, ein komprimiertes Dateisystem im RAM mit Binaries, die der Kernel braucht, um zum Beispiel eine verschlüsselte Festplatte zu öffnen - jedes Setup mit verschlüsseltem root-Dateisystem braucht eine solche Initramdisk.
Und natürlich die Kernelparameter, um die eigentliche Verschlüsselung nutzen zu können.

Alles kein all zu großes Problem - moderne Linux-Kernel können ihre eigene Ramdisk mit einkompilieren, ebenso statische Kernel-Parameter. Für Menschen mit entsprechender Detailkenntnis kein sonderlich großes Problem - Distributionen, die für möglichst große Flexibilität Initramdisks mit einer großen Zahl von Treibermodulen verwenden oder der Nutzerin die Möglichkeit geben möchte, den Kernel ausnahmsweise mit anderen Parametern zu starten, können darauf nicht zurückgreifen.

Bootloader

GRuB

Leider muß ich mich an dieser Stelle auf GRuB beschränken. Ich weiß, daß es andere Bootloader gibt und zum Teil sogar, wie sie heißen - ich habe mich nur nie mit ihnen auseinandergesetzt, geschweige denn, herausgefunden, wie ich die für ein UEFI-System benutze.

Eine UEFI-Installation von GRuB erschöpft sich darin, die ESP als /boot/efi zu mounten und grub-install --target=x86_64-efi /dev/to/esp aufzurufen.

Das wird sich bei anderen Bootloadern - sofern sie UEFI auch unterstützen - sicherlich ähnlich verhalten.

Vielleicht füge ich hier zu den anderen mal ein paar Absätze ein, wenn ich darüber stolpere.

SecureBoot - die Zweite

Mußte ja kommen.

Die einfachste Variante ist, SecureBoot abzuschalten.
Das bringt, dank des Dateisystems der ESP, einen großen Nachteil mit sich: Es gibt praktisch keine Möglichkeit, zu verifizieren, daß zwischenzeitlich, z.B. während der Laufzeit des Systems durch Schadsoftware, der Bootloader - oder das Kernel-Image - verändert wurde. FAT32 hat überhaupt keine Methoden, die darauf gespeicherten Daten mit auch nur rudimentären Zugriffsrechten zu versehen, verschlüsselt ist es auch nicht - ein Scheunentor für unbemerkte Zugriffe.

Außerdem könnte eine parallele Windows-Installation die Zusammenarbeit ohne SecureBoot verweigern - und jedes Mal im UEFI die Einstellung zu ändern ist auch nicht unbedingt praktikabel.

Eine Methode wäre es, einfach gar keine ESP im System selbst zu haben, sondern diese auf einem externen USB-Stick ständig bei sich zu haben.
Das ist einerseits im Schwimmbad etwas unpraktisch, weil die wenigsten Sticks wasserfest sind, andererseits auch einfach nicht praktikabel, wenn nicht für jeden Systemstart erst hingerannt werden soll.

Um eine gewisse Integrität des Bootloaders sichern zu können, kann wieder auf SecureBoot zurückgegriffen werden. Zumindest, wenn der Hersteller das Austauschen der SecureBoot-Zertifikate im UEFI vorgesehen hat.
Manche bieten den trivialen Weg, dies im Systemsetup während des Systemstarts zu tun: Die Zertifikatdateien liegen auf der ESP - oder einer anderen FAT32-Partition - und das Systemsetup kann sie von dort in den Flashspeicher der Firmware laden. Bei anderen Systemen muß dafür leider auf die etwas obskuren und nicht notwendigerweise sicheren Methoden der jeweiligen Linux-Distribution zurückgegriffen werden - mit dem Risiko, sich dabei das System zu bricken.

Dabei finden drei verschiedene Keys Verwendung: PK, der Platform-Key, eine Art Master-Schlüssel, vergleichbar einer Trusted Root-CA. KEK, der Key-Exchange-Key, ein Intermediate-Zertifikat, signiert durch den PK. Und db, eine ganze Sammlung an Keys, die die eigentlichen Bootloader signieren.
Im Normalfall liefert der Hersteller seine eigenen PK und KEK, mit denen er die Keys in der db signiert hat - darunter sind auch Revocation Keys, Schlüssel und Bootloader die für SecureBoot explizit gesperrt wurden.

Der Sinn und Zweck dieser ganzen Reihe von Keys ist die Handhabbarkeit auf Herstellerseite: Es gibt einen Hersteller-Root-Key (PK), der für alle Geräte des Herstellers identisch ist und der entsprechend besonders gesichert abgelegt ist.
Statt nun aber jeden Bootloader - und alleine Microsoft veröffentlicht da öfter mal einen neuen, durch die PKs aller Hersteller signieren zu lassen, hat sich Microsoft einen Key generiert, die die Hersteller ihrerseits signieren und signiert damit seine Bootloader. Sollte der Key bei Microsoft kompromittiert werden, kann er in der db des UEFI gelöscht oder als gesperrt markiert werden.
Der KEK dazwischen dient als Sicherungsschicht gegenüber dem PK - statt also den PK für jeden neuen Key in der Bootloader-Datenbank herauszuholen, wird dafür der KEK verwendet, der leichter zu ersetzen ist.

Sollen die SecureBoot Keys ersetzt werden, müssen ein neuer PK, ein neuer KEK und ein neuer "Bootloader-Signingkey" her, mit PK als selbstsigniertem Zertifikat, dem durch PK signierten KEK und dem durch den KEK signierten Bootloader-Signingkey.
Dafür gibt es Tutorials - das unterscheidet sich nicht wesentlich vom Anlegen einer CA und einer daran hängenden Intermediate-CA-Kette nach bestem X.509-Schema. Es finden sogar tatsächlich dieselben Dateiformate Verwendung.

Wer sich die gesamte Kette nicht zutraut - es genügt auch ein PK ohne KEK und dedizierten Bootloader-Signingkey.

Sind die Zertifikate erzeugt und im UEFI hinterlegt, kann jedes UEFI-Binary damit signiert werden.
Ist der Bootloader - oder der Linux-Kernel erstmal signiert, kann SecureBoot wieder eingeschaltet werden und zumindest der EFI-Stub des Linux-Kernels teilt dann im Kernel-Log auch mit, daß SecureBoot aktiv und nicht kompromittiert ist.
Passt die Signatur nicht (mehr), sollte das UEFI den Start des Bootloaders/Kernels verweigern.

Und ja, das geht auch mit den Bootloadern von Windows 10, die tatsächlich mehr als eine Signatur tragen dürfen.

Zumindest technisch. Leider.
Unglücklicherweise hat Microsoft, zumindet bis zur Build 1703 von Windows 10 entweder mit jedem Update den Bootloader ausgetauscht, oder irgendeine dieser obskuren Systemschutztechniken in Windows tauscht den Bootloader immer wieder gegen das nur einfach (und damit ungültig) signierte Original aus.

Es ist ein bißchen nervig, den Windows-Bootloader regelmäßig neu signieren zu müssen, weil das UEFI mit SecureBoot aber ausgetauschten Keys den Start von Windows mit dem Hinweis auf die ungültige Signatur des Loaders ablehnt…

efivars

Da UEFI auch nach dem Start des eigentlichen Betriebssystems noch läuft und auch für Resourcenzuteilung zumindest in Grenzen immernoch zuständig ist, kann und muss mit UEFI kommuniziert werden.
Unter Linux sind dafür die efivars - sowohl der Eintrag im sysfs, als auch die zugehörigen Tools - zuständig.

Darüber lassen sich Systemeigenschaften, wie das nun schon zum Erbrechen oft genannte SecureBoot oder, interessanter, die Bootreihenfolge auslesen. Und in manchen Fällen auch ändern.
Ebenfalls enthalten kann auch das Debug-Log des UEFI-eigenen Firmware-Updaters sein, und damit dem Betriebssystem eine Anzeige des Logs nach einem fehlgeschlagenen Firmwareupdate ermöglichen.

Prinzipiell wird damit das Systemsetup, welches während der Einschalttests eines PC aufgerufen werden kann, nahezu überflüssig.

efibootmgr

Eine der interessantesten Komponenten, die über efivars modifizierbar ist, sind die Boot-Variablen.
Hier können zusätzliche Einträge in der UEFI-Bootauswahl angelegt, geändert, gelöscht und an eine andere Position in der Reihenfolge verschoben werden.

Unter anderem können hier sogenannte "Capsules" eingetragen werden, UEFI-Binaries, die zum Aktualisieren der Firmware des Geräts dienen.
Und genau dafür benötigt der efibootmgr Schreibzugriff auf die EFI-Variablen.

Es sind also zwei verschiedene Dinge mit dem EFI-Stub und den efivars im Linux-Kernel: Keines bedingt das andere, aber es hilft, beides zur Verfügung zu haben.

 

Sollte mir irgendwann noch etwas Wesentliches einfallen, mache ich vermutlich einen Nachtrag…

 

Ist ein bisschen kitzschig. Glaube ich. Aber auch das beste Bild, das mir zum Start des Langstreckengurkenblogs eingefallen ist.

Also, hier ist der Sonnenaufgang über einer Autobahn, wobei das meiste Licht wohl eher von den Scheinwerfern stammt, die auf besagter Autobahn gerade im Stau stehen.

Damit ist dann auch der Bezug zur Langstreckengurke hergestellt, das bin ich. Ich fahre - gurke - von Berufs wegen lange Strecken und um das, was mir dabei so in den Sinn kommt und passiert, Nachdenkliches wie Lustiges, soll es hier gehen.

Herzlich Willkommen.

Im Niemandsland zwischen Brandenburg und Mecklenburg-Vorpommern
hat die herbstfahle Sonne am ansonsten wolkenlos-blauen Himmel nachmittags nicht mehr die Kraft,
die Nebelschwaden über den Feldern und noch grünen Wiesen zu vertreiben.
Ihre langsam vergehenden Farben
verschwinden unter einer Decke aus weißer Watte,
nur durchbrochen durch ein paar letzte Nachzügler an Vieh, das noch draußen weidet,
statt sich im warmen Stall das Futter bringen zu lassen.
Der Sommer ist Geschichte.