Autorenarchiv: Jörg Kastning

Network Bound Disk Encryption im Überblick

8 Antworten

In diesem Artikel gebe ich euch einen Überblick, was Network Bound Disk Encryption (NBDE) ist und beschreibe einen konkreten Anwendungsfall. Am Ende des Artikels führe ich einige Verweise auf, mit deren Hilfe ihr NBDE bei Interesse selbst implementieren könnt.

Linux Unified Key Setup (LUKS)

Bevor ich auf NBDE eingehe, möchte ich kurz ein paar Worte zu LUKS verlieren.

Bei LUKS handelt es sich um das Standardverfahren zur Festplattenverschlüsselung unter Linux (siehe 1). Dieses erweitert dm-crypt um einen Header, welcher Slots zum Speichern von bis zu acht Schlüsseln bietet (siehe 2).

Ich benutze dieses Verfahren auf nahezu all meinen Rechnern. Ich möchte damit erreichen, dass meine Daten bei Diebstahl des Rechners bzw. der Festplatte möglichst lange vor unberechtigtem Zugriff geschützt sind.

Typischerweise wird zur Entschlüsselung einer Festplatte bzw. Partition während des Boot-Vorgangs die Eingabe eines Kennworts benötigt. Die Sicherheit des Verfahrens hängt dabei direkt von der Stärke des verwendeten Passworts ab (siehe 1).

Steht der Rechner im Büro und man ist täglich vor Ort, ist es kein Problem, bei Neustart des Rechners das LUKS-Kennwort einzugeben. Wenn man allerdings im Homeoffice arbeitet und Zugriff auf seinen Büro-Rechner braucht, sieht die Sache anders aus.

Möchte man den entfernten Rechner neustarten, z.B. nach der Installation von Updates, muss man dafür extra ins Büro fahren. Alternativ kann man ein zweites Kennwort einrichten, dieses einem Kollegen mitteilen und diesen bitten, es vor Ort einzugeben. Beides ist nicht komfortabel. Und hier kommt NBDE ins Spiel.

LUKS an Netzwerkressource binden

Network Bound Disk Encryption heißt auf Deutsch in etwa netzwerkgebundene Festplattenverschlüsselung und bedeutet, dass die Verschlüsselung an eine oder mehrere Ressourcen im Netzwerk gebunden ist.

Das Prinzip ist ganz einfach. Wenn ein Rechner mit einer verschlüsselten Festplatte oder Partition startet, sucht er nach einer bestimmten Ressource im Netzwerk. Kann der Rechner diese Netzwerkressource erreichen, wird die Festplatte bzw. Partition entschlüsselt und der Startvorgang fortgesetzt. Folgende Abbildung soll dies veranschaulichen.

nbde-network
Clevis-Client und Tang-Server zur Nutzung von NBDE im LAN

Im eigenen LAN werden zwei sogenannte Tang-Server positioniert (siehe 4 und 6). Diese stellen die Netzwerk-Ressource dar, welche erreichbar sein muss, damit ein an Tang gebundenes Gerät entschlüsselt werden kann. In diesem Beispiel werden zwei Tang-Server betrieben, um die Verfügbarkeit des Dienstes zu gewährleisten, wenn ein Server gewartet wird.

Auf dem Client kommt die Anwendung Clevis zum Einsatz (siehe 5, 6 und 7), bei welcher es sich um die Client-Komponente zum Tang-Server handelt. Diese empfängt einen Schlüssel vom Tang-Server und verwendet diesen, um einen Token in einem LUKS-Slot zu speichern (Details siehe 3, 6 und 7). Beim Start eines Rechners wird nun versucht, einen der Tang-Server zu erreichen, an die man sich gebunden hat.

Wird der Rechner bzw. seine Festplatte gestohlen, sind die Tang-Server nicht erreichbar und die Daten werden nicht automatisch entschlüsselt. Der Dieb muss nun die Verschlüsselung bzw. das verwendete Kennwort brechen.

Steht der Rechner jedoch an seinem Platz, kann er aus der Ferne neugestartet werden und den Startvorgang beenden, ohne dass jemand vor Ort ein LUKS-Kennwort eingeben muss.

Damit diese Konfiguration Sinn macht, dürfen die Tang-Server nicht weltweit erreichbar sein. Ihr Standort und die Netze, aus denen sie erreichbar sind, sind daher sorgfältig zu planen.

Zusammenfassung

Ohne NBDE muss an einem Rechner mit LUKS-Verschlüsselung bei jedem Startvorgang das LUKS-Kennwort eingegeben werden, was einen Neustart aus der Ferne enorm erschwert.

NBDE ist leicht zu implementieren und löst dieses Problem. Gleichzeitig bleiben die Daten im gleichen Maße bei einem Diebstahl des Rechners geschützt.

  1. LUKS im Wiki von Ubuntuusers.de. URL: https://wiki.ubuntuusers.de/LUKS/
  2. https://de.wikipedia.org/wiki/Dm-crypt#LUKS
  3. Automatic data encryption and decryption with Clevis and Tang. ADMIN 43/2018. URL: https://www.admin-magazine.com/Archive/2018/43/Automatic-data-encryption-and-decryption-with-Clevis-and-Tang
  4. https://github.com/latchset/tang
  5. https://github.com/latchset/clevis
  6. RHEL 8 Security Hardening Chapter 12. Configuring automated unlocking of encrypted volumes using policy-based decryption. URL: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_security-hardening
  7. RHEL 7 Security Guide 4.10.1. Network-Bound Disk Encryption. URL: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-policy-based_decryption#sec-Using_Network-Bound_Disk_Encryption
  8. How to set up Network-Bound Disk Encryption with multiple LUKS devices (Clevis+Tang unlocking). URL: https://access.redhat.com/articles/4500491. (Login erforderlich)

Der Umwelt und mir gefällt es am besten, wenn „ihr“ mich „remote“ arbeiten lasst.

2 Antworten

Themen wie der Klimawandel, Maßnahmen zum Schutz des Klimas, nachhaltige Lebensweise und der sparsame Umgang mit den Ressourcen unseres Planeten sind die letzten Monate in unseren Medien omnipräsent.

In den letzten Tagen machen Nachrichten über steigende Benzinpreise und Preissteigerungen bei der Bahn Schlagzeilen. In den Kommentarspalten treffen nun wieder die Freunde des Individualverkehrs und die Liebhaber des ÖPNV aufeinander und streiten über Vor- und Nachteile und die sinnvollste Verknüpfung der letzteren.

An dieser Stelle folgt nun keine Rechnung für oder wider das Auto. Sondern ein Appell, das beizubehalten, was in der Pandemie gut funktioniert hat. Das Homeoffice nämlich.

Meine Dienststelle liegt ca. 33 km von meinem Wohnort entfernt. Vor der Pandemie bin ich fünf Tage in der Woche gependelt. Dabei benötige ich mit dem Auto für eine Strecke je nach Verkehrslage 40-50 Minuten.

Möchte ich auf das Auto verzichten, verlängert sich die einfache Fahrzeit auf 96-150 Minuten, je nach Verbindung. Das ist für mich inakzeptabel, denn ich möchte ja auch noch etwas vom Tag und meiner Familie haben. Die Fahrzeit lässt sich auf 69 Minuten reduzieren, wenn ich die ersten 12 km mit dem Auto bis zu einer günstigen Haltestelle fahre. Da fahre ich die restlichen 21 km lieber auch noch selbst und spare mir die Zeit.

Seit die Pandemie über uns kam, arbeite ich von daheim. Die Dienststelle suche ich jetzt eher an 5 Tagen im Quartal auf. Nämlich immer dann, wenn Arbeiten nicht von daheim ausgeführt werden können, keine Remote-Hands verfügbar sind, ich meine Post abholen muss oder ich einfach mal mit einem Kollegen essen gehen möchte.

Damit spare ich mir täglich 1,5 Std. auf der Straße und meinem Auto und der Umwelt ca. 14.000 km im Jahr.

Für mich und viele meines Berufsstandes funktioniert dieses Modell sehr gut. Mir ist bewusst, dass dieses Modell nicht für alle Erwerbstätigen möglich oder wünschenswert ist, doch ist es, denke ich, für ebenso viele ein Segen.

Daher wünsche ich mir, dass die Pandemie schnell enden möge und all jene, denen es so geht wie mir, im Homeoffice bleiben dürfen.

Update 2022-08-26: Mit der Dienstvereinbarung FlexWork hat meine Dienststelle die Möglichkeit geschaffen, bis zu 60 % der geschuldeten Arbeitszeit aus dem Heimbüro zu erbringen. Nach diesem Modell arbeite ich nun schon einige Monate und bin sehr zufrieden damit. Etwas Raum für Verbesserung gibt es noch. Ich würde mir 80 % FlexWork wünschen oder eine Regelung nur noch in die Dienststelle kommen zu müssen, wenn es mir beliebt bzw. Arbeiten nicht remote ausgeführt werden können.

GNU/LinuxDay in Vorarlberg – am 16. Okt. 2021 (nur online)

Schreibe eine Antwort

Am 16. Oktober 2021 findet zum zweiten Mal ein reiner Online-LinuxDay AT statt.

LinuxDay 2021 am 16. Oktober

Noch immer hat uns die Covid-Pandemie im Griff und so findet auch dieser LinuxDay wieder online statt.

Dennoch hat sich die Linux User Group Vorarlberg wieder tüchtig ins Zeug gelegt und ein abwechslungsreiches Programm mit 12 Vorträgen zusammengestellt. Informationen für Besucherinnen und Besucher stellt die LUG unter „Was wie wo – 2021“ bereit.

Ich freue mich, wenn wir uns im virtuellen Raum treffen und einen schönen LinuxDay verbringen. Hoffentlich können wir uns im nächsten Jahr wieder vor Ort treffen und ein schönes Wochenende in Dornbirn verbringen.

Zwei Bash-Skripte zur Analyse der NGINX Access Logs

6 Antworten

Beim Durchwühlen des Internets bin ich auf eine Perle gestoßen, die ich hier festhalten möchte. In „Bash Script to Parse and Analyze Nginx Access Logs“ stellt Ruan Bekker ein kurzes Bash-Skript vor, welches die NGINX Access Logs analysiert, um einen Bericht mit folgenden Sektionen auszugeben:

  • Top 10 Request IPs (aus dem aktuellen Access Log)
  • Top Request Methods (aus dem aktuellen Access Log)
  • Top 10 Request Pages (aus dem aktuellen Access Log)
  • Top 10 Request Pages (aus dem aktuellen und Gzipten Logs)
  • Top 10 HTTP 404 Page Responses (aus dem aktuellen und Gzipten Logs)

Ich selbst nutze aktuell den Fork von Marc Brunet, welchen ich meinen My-IT-Scripts hinzugefügt habe:

#!/bin/bash

# URL: https://github.com/Tronde/My-IT-Scripts/blob/master/bash/analyze_nginx_access_logs.sh

# variables
LOGFILE="/var/www/jkastning/sites/logs/www.my-it-brain.de_access.log"
LOGFILE_GZ="/var/www/jkastning/sites/logs/www.my-it-brain.de_access.log.*"
RESPONSE_CODE="200"

# functions
filters(){
grep -w $RESPONSE_CODE \
| grep -v "\/rss\/" \
| grep -v robots.txt \
| grep -v "\.css" \
| grep -v "\.jss*" \
| grep -v "\.png" \
| grep -v "\.ico"
}

filters_404(){
grep -w "404"
}

request_ips(){
awk '{print $1}'
}

request_method(){
awk '{print $6}' \
| cut -d'"' -f2
}

request_pages(){
awk '{print $7}'
}

wordcount(){
sort \
| uniq -c
}

sort_desc(){
sort -rn
}

return_kv(){
awk '{print $1, $2}'
}

request_pages(){
awk '{print $7}'
}

return_top_ten(){
head -10
}

## actions
get_request_ips(){
echo ""
echo "Top 10 Request IP's:"
echo "===================="

cat $LOGFILE \
| filters \
| request_ips \
| wordcount \
| sort_desc \
| return_kv \
| return_top_ten
echo ""
}

get_request_methods(){
echo "Top Request Methods:"
echo "===================="
cat $LOGFILE \
| filters \
| request_method \
| wordcount \
| return_kv
echo ""
}

get_request_pages_404(){
echo "Top 10: 404 Page Responses:"
echo "==========================="
zgrep '-' $LOGFILE $LOGFILE_GZ\
| filters_404 \
| request_pages \
| wordcount \
| sort_desc \
| return_kv \
| return_top_ten
echo ""
}


get_request_pages(){
echo "Top 10 Request Pages:"
echo "====================="
cat $LOGFILE \
| filters \
| request_pages \
| wordcount \
| sort_desc \
| return_kv \
| return_top_ten
echo ""
}

get_request_pages_all(){
echo "Top 10 Request Pages from All Logs:"
echo "==================================="
zgrep '-' --no-filename $LOGFILE $LOGFILE_GZ \
| filters \
| request_pages \
| wordcount \
| sort_desc \
| return_kv \
| return_top_ten
echo ""
}

# executing
get_request_ips
get_request_methods
get_request_pages
get_request_pages_all
get_request_pages_404

Selbstverständlich erhalte ich damit keine genauen Statistiken, da meine Logs nach einem Monat automatisch gelöscht werden. Für einen kurzen Rückblick und der Erstellung eines monatlichen Berichts scheint das kleine Skript jedoch gut geeignet zu sein. Ich probiere es gerade aus, um zu sehen, wie gut es mir auf Dauer gefällt.

Auf Basis des ersten Skripts habe ich ein zweites geschrieben, mit dessen Hilfe ich die Requests für einen spezifischen Beitrag abfragen kann (Quelle):

#!/bin/bash

# variables
LOGFILE="/var/www/jkastning/sites/logs/www.my-it-brain.de_access.log"
LOGFILE_GZ="/var/www/jkastning/sites/logs/www.my-it-brain.de_access.log.*"
RESPONSE_CODE="200"
ARG1=$1

# functions
filters(){
grep -w $RESPONSE_CODE \
| grep -v "\/rss\/" \
| grep -v robots.txt \
| grep -v "\.css" \
| grep -v "\.jss*" \
| grep -v "\.png" \
| grep -v "\.ico"
}

request_ips(){
awk '{print $1}'
}

request_page(){
awk '{print $7}' \
| grep -w $ARG1
}

wordcount(){
sort \
| uniq -c
}

return_kv(){
awk '{print $1, $2}'
}

get_request_page(){
echo "Page requests in current log:"
echo "====================="
cat $LOGFILE \
| filters \
| request_page \
| wordcount \
| return_kv
echo ""
}

get_request_page_all(){
echo "Page requests in all logs (last month):"
echo "==================================="
zgrep '-' --no-filename $LOGFILE $LOGFILE_GZ \
| filters \
| request_page \
| wordcount \
| return_kv
echo ""
}

# execute
get_request_page
get_request_page_all

Der folgende Code-Block zeigt ein Beispiel, wie das Skript angewendet wird. Dabei wird der Permalink als Argument übergeben:

:~/bin$ sh get_page_requests_from_nginx_access_logs.sh kommentar-linux-container-spreu-und-weizen
Page requests in current log:
=====================
262 /wordpress/kommentar-linux-container-spreu-und-weizen/
6 /wordpress/kommentar-linux-container-spreu-und-weizen/feed/

Page requests in all logs (last month):
===================================
5124 /wordpress/kommentar-linux-container-spreu-und-weizen/
49 /wordpress/kommentar-linux-container-spreu-und-weizen/feed/
2 /wordpress/wp-json/oembed/1.0/embed?url=https://www.my-it-brain.de/wordpress/kommentar-linux-container-spreu-und-weizen/

Noch nicht schön, aber zweckmäßig.

Was haltet ihr davon? Falls ihr beim Drübergucken zufällig noch einen Fehler in den Skripten entdeckt, freue ich mich, wenn ihr mir einen Kommentar hinterlasst.

In-Place-Upgrade für Red Hat Enterprise Linux (RHEL)

Schreibe eine Antwort

In diesem Beitrag beschreibe ich exemplarisch, wie ein In-Place-Upgrade von RHEL 7 auf RHEL 8 durchgeführt werden kann. Dabei beschreibe ich zuerst, was ein In-Place-Upgrade ist und in welchen Fällen es sinnvoll sein kann, bevor ich im Hauptteil anhand einer Test-VM die Durchführung demonstriere.

Was ist ein In-Place-Upgrade?

Als In-Place-Upgrade wird der Vorgang bezeichnet, bei dem ein Betriebssystem auf ein neues Major-Release aktualisiert wird, ohne das System dabei neuinstallieren zu müssen. Statt dessen werden alle zum Betriebssystem gehörenden Dateien gegen die entsprechende Version des neuen Release ausgetauscht.

Nutzer von Debian und Ubuntu kennen dieses Verfahren unter dem Begriff Distributions-Upgrade.

In-Place-Upgrade vs. Neuinstallation

Grundsätzlich bevorzuge ich die Neuinstallation eines Systems. Da man sich üblicherweise mit Backups und Deployment-Skripten darauf vorbereitet hat, einen Dienst bzw. eine Anwendung nach einem Verlust des laufenden Systems wiederherstellen zu können, kann man sich dies auch zu Nutze machen und den Dienst bzw. die Anwendung auf einem frisch installierten System wiederherzustellen. Auf diese Weise werden keine Altlasten über mehrere Betriebssystemversionen mitgeschleppt.

Gleichzeitig kann man die Downtime verkürzen, indem das neue System parallel zum alten aufgebaut wird und man nach dem Abschluss aller Arbeiten und Tests umschaltet. Das Altsystem kann im Nachgang in Ruhe abgebaut werden.

Es gibt jedoch auch Gründe, die für ein In-Place-Upgrade sprechen. Verfügt man nur über einen einzigen Host und kann kein Parallelsystem aufbauen, kann ein In-Place-Upgrade die Lösung sein.

Evtl. verfügt man selbst zwar über ausreichend Berechtigungen, um das vorhandene System zu aktualisieren, für die Provisionierung neuer Systeme ist man jedoch auf die Unterstützung weiterer Stellen angewiesen. Die Abhängigkeitskette lässt sich hier zum Teil deutlich reduzieren.

Dabei muss stets bedacht werden, dass bei einem In-Place-Upgrade auch ein katastrophaler Fehler eintreten kann, welcher zum Verlust des Systems führt. Es ist daher dringend angeraten, eine Datensicherung zu haben, aus welcher das System wiederhergestellt werden kann. Besitzt man ein Backup, auf das man sich verlassen kann, kann es auch schon losgehen.

Das Upgrade von RHEL 7 auf RHEL 8

Laut Kapitel 1 der unter [0] verlinkten Dokumentation stellt das In-Place-Upgrade den von Red Hat unterstützten und empfohlenen Weg dar, um auf das nächste Major-Release zu aktualisieren. Dabei kann man stets nur von der letzten Verfügbaren RHEL 7 Version auf das jeweils letzte gerade RHEL 8 Release (z.B. 8.4) aktualisieren. Details hierzu können im Artikel unter [1] nachgelesen werden.

Die folgenden Abschnitte können die Dokumentation unter [0] nicht ersetzen. Sie sollen lediglich einen kompakten Überblick über den Prozess geben.

Limitierungen

Zum Zeitpunkt der Artikelerstellung , kann das In-Place-Upgrade nicht auf Systemen mit verschlüsselten Dateisystemen durchgeführt werden.

Netzwerkspeicher, wie z.B. iSCSI oder NAS, werden nicht unterstützt und müssen während des Upgrades ausgehängt werden. Die dazugehörigen Dienste, wie z.B. autofs müssen vorübergehend deaktiviert werden.

Weitere bekannte Probleme sind Kapitel 8 in [0] zu entnehmen.

Vorbereitung

Bevor man mit dem Upgrade beginnen kann, sind folgende Voraussetzungen zu schaffen:

  • Das System erfüllt die minimalen Systemvoraussetzungen für RHEL 8 (siehe [2]).
  • Zugriff auf Repos mit aktuellen Paketen für RHEL 7.9 und RHEL 8.4.
  • Korrekte Registrierung des Systems am Red Hat Content Delivery Network (CDN) oder den Red Hat Satellite Server mittels Red Hat Subscription Manager (RHSM).

Wichtig: Ich empfehle ausdrücklich, vor Beginn der Arbeiten ein aktuelles Backup bzw. einen Snapshot zu erstellen, um auf den Ausgangszustand vor der Upgrade-Prozedur zurückkehren zu können.

Kapitel 2 in [0] bietet eine ausführliche Schritt-für-Schritt-Anleitung zur Vorbereitung des Upgrades. Der folgende Codeblock bietet eine kompakte Übersicht der einzelnen Schritte. Als Zielsystem dient eine aktuelle RHEL 7.9 Minimal-Installation.

[tronde@rhel7-t1 ~]$ # Überprüfung, ob eine RHEL-Subskription abonniert wurde
[tronde@rhel7-t1 ~]$ sudo subscription-manager list --installed
[sudo] password for tronde: 
+-------------------------------------------+
    Installed Product Status
+-------------------------------------------+
Product Name:   Red Hat Enterprise Linux Server
Product ID:     69
Version:        7.9
Arch:           x86_64
Status:         Subscribed
Status Details: 
Starts:         06.10.2020
Ends:           06.10.2021

[tronde@rhel7-t1 ~]$ # Aktivierung des RHEL 7 Basis- und Extras-Repo
[tronde@rhel7-t1 ~]$ sudo subscription-manager repos --enable rhel-7-server-rpms
Repository 'rhel-7-server-rpms' is enabled for this system.
[tronde@rhel7-t1 ~]$ sudo subscription-manager repos --enable rhel-7-server-extras-rpms
Repository 'rhel-7-server-extras-rpms' is enabled for this system.

[tronde@rhel7-t1 ~]$ # Ist locale auf en_US.UTF-8 gesetzt?
[tronde@rhel7-t1 ~]$ cat /etc/locale.conf
LANG="en_US.UTF-8"

[tronde@rhel7-t1 ~]$ sudo yum install leapp leapp-repository
# Ausgabe gekürtzt
Transaction Summary
================================================================================
Install  2 Packages (+24 Dependent packages)

Total download size: 5.3 M
Installed size: 19 M
Is this ok [y/d/N]: y
# Ausgabe gekürtzt

Pre-Upgrade-Bericht erstellen

Bevor das eigentliche Upgrade durchgeführt wird, führe ich auf meinem Testsystem das Kommando leapp preupgrade aus. Dieses sammelt Informationen über das System, um die Upgradefähigkeit zu bewerten und erstellt einen detaillierten Bericht, welcher im Pfad /var/log/leapp/leapp-report.txt abgelegt wird.

[tronde@rhel7-t1 ~]$ sudo leapp preupgrade
# Ausgabe gekürzt
============================================================
                           ERRORS                           
============================================================

2021-08-31 06:33:26.035495 [ERROR] Actor: repository_mapping
Message: Data file /etc/leapp/files/repomap.csv is invalid or could not be retrieved.
Summary:
    Details: Could not fetch repomap.csv from https://cert.cloud.redhat.com/api/pes/repomap.csv (unreachable address).
    Hint: Read documentation at: https://access.redhat.com/articles/3664871 for more information about how to retrieve the file.
2021-08-31 06:35:22.415297 [ERROR] Actor: restricted_pcis_scanner
Message: Data file /etc/leapp/files/unsupported_driver_names.json is invalid or could not be retrieved.
Summary:
    Details: Could not fetch unsupported_driver_names.json from https://cert.cloud.redhat.com/api/pes/unsupported_driver_names.json (unreachable address).
    Hint: Read documentation at: https://access.redhat.com/articles/3664871 for more information about how to retrieve the file.
2021-08-31 06:35:47.800140 [ERROR] Actor: pes_events_scanner
Message: Data file /etc/leapp/files/pes-events.json is invalid or could not be retrieved.
Summary:
    Details: Could not fetch pes-events.json from https://cert.cloud.redhat.com/api/pes/pes-events.json (unreachable address).
    Hint: Read documentation at: https://access.redhat.com/articles/3664871 for more information about how to retrieve the file.

============================================================
                       END OF ERRORS                        
============================================================


Debug output written to /var/log/leapp/leapp-preupgrade.log

============================================================
                           REPORT                           
============================================================

A report has been generated at /var/log/leapp/leapp-report.json
A report has been generated at /var/log/leapp/leapp-report.txt

============================================================
                       END OF REPORT                        
============================================================

Answerfile has been generated at /var/log/leapp/answerfile
[tronde@rhel7-t1 ~]$

Dem obigen Codeblock ist zu entnehmen, dass der Pre-Upgrade-Check Fehler festgestellt hat, die behoben werden müssen, bevor ein In-Place-Upgrade durchgeführt werden kann. Dankenswerter Weise ist sowohl in der Ausgabe auf STDOUT als auch in /var/log/leapp/leapp-report.txt der Knowledge-Base-Artikel [3] verlinkt, welcher die Lösung parat hält.

Ist dieser Fehler behoben, lässt man leapp preupgrade ein weiteres Mal laufen und prüft die Ausgabe erneut. Auf meinem Testsystem erhalte ich nun folgende Ausgabe:

[root@rhel7-t1 ~]# leapp preupgrade
# Ausgabe gekürzt
============================================================
                     UPGRADE INHIBITED                      
============================================================

Upgrade has been inhibited due to the following problems:
    1. Inhibitor: Missing required answers in the answer file
Consult the pre-upgrade report for details and possible remediation.

============================================================
                     UPGRADE INHIBITED                      
============================================================


Debug output written to /var/log/leapp/leapp-preupgrade.log

============================================================
                           REPORT                           
============================================================

A report has been generated at /var/log/leapp/leapp-report.json
A report has been generated at /var/log/leapp/leapp-report.txt

============================================================
                       END OF REPORT                        
============================================================

Answerfile has been generated at /var/log/leapp/answerfile

Diesmal weist die Ausgabe darauf hin, dass ein Upgrade durch fehlende Antworten in /var/log/leapp/answerfile verhindert wird. Die genannte Datei kann mit einem Editor geöffnet und entsprechend bearbeitet werden:

[remove_pam_pkcs11_module_check]
# Title:              None
# Reason:             Confirmation
# =================== remove_pam_pkcs11_module_check.confirm ==================
# Label:              Disable pam_pkcs11 module in PAM configuration? If no, the upgrade process will be interrupted.
# Description:        PAM module pam_pkcs11 is no longer available in RHEL-8 since it was replaced by SSSD.
# Type:               bool
# Default:            None
# Available choices: True/False
# Unanswered question. Uncomment the following line with your answer
confirm = True

Die Datei enthält direkt eine Erklärung, warum das erwähnte Modul zu entfernen ist und wie dies zu geschehen hat.

Anschließend empfiehlt sich ein Blick in den Bericht unter /var/log/leapp/leapp-report.txt, um zu prüfen, ob einem Upgrade evtl. weitere Gründe entgegen stehen. Auf die Ausgabe des Berichts in diesem Artikel wird aus Platzgründen verzichtet. Da der Inhalt auf jedem System unterschiedlich ausfallen kann, ist sein Nutzen an dieser Stelle ohnehin stark begrenzt.

Durchführung des In-Place-Upgrade

An dieser Stelle wird es ernst. Man sollte sich noch einmal vergewissern, dass man einen Snapshot bzw. ein geeignetes Backup des Systems hat. Dann wird das Upgrade mit folgendem Befehl gestartet:

# leapp upgrade
# Ausgabe gekürzt
============================================================
                           REPORT                           
============================================================

A report has been generated at /var/log/leapp/leapp-report.json
A report has been generated at /var/log/leapp/leapp-report.txt

============================================================
                       END OF REPORT                        
============================================================

Answerfile has been generated at /var/log/leapp/answerfile

Dieser Vorgang kann mehrere Minuten dauern. Leapp lädt notwendige Daten herunter und bereitet die RPM-Transaktionen für das Upgrade vor. Dabei wird erneut geprüft, ob Gründe vorliegen, die ein Upgrade verhindern können. Sollte dies der Fall sein, bricht leapp den Vorgang ab und erzeugt einen neuen Bericht.

Ist das Upgrade erfolgreich durchgelaufen, muss das System manuell neugestartet werden. Das System startet anschließend in eine RAM-Disk und aktualisiert alle Pakete des Systems. Anschließend wird automatisch ein Neustart ausgeführt. Dieser Vorgang lässt sich am besten an einer (virtuellen) Konsole beobachten.

Nachdem das Upgrade abgeschlossen ist, kann man sich wieder am System anmelden und mit folgenden Kommandos prüfen, ob das System den gewünschten Status hat (vgl. Kapitel 5 in [0]):

[root@rhel7-t1 ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux release 8.4 (Ootpa)

[root@rhel7-t1 ~]# uname -r
4.18.0-305.12.1.el8_4.x86_64

[root@rhel7-t1 ~]# subscription-manager list --installed
+-------------------------------------------+
    Installed Product Status
+-------------------------------------------+
Product Name:   Red Hat Enterprise Linux for x86_64
Product ID:     479
Version:        8.4
Arch:           x86_64
Status:         Subscribed
Status Details: 
Starts:         06.10.2020
Ends:           06.10.2021

[root@rhel7-t1 ~]# subscription-manager release
Release: 8.4

Hier sieht alles gut aus.

Post-Upgrade-Tasks

Kapitel 6 in [0] beschreibt detailliert, welche Aufgaben nach einem erfolgreichen In-Place-Upgrade noch auszuführen sind, um ein möglichst sauberes System zu erhalten.

Auf meinem Testsystem sind einige RHEL 7 Pakete zurückgeblieben, welche ich mit folgendem Kommando entferne:

# dnf remove `rpm -qa | grep -e '\.el[67]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sort`
Updating Subscription Management repositories.
Dependencies resolved.
===============================================================================
 Package              Arch       Version                     Repository   Size
===============================================================================
Removing:
 doxygen              x86_64     1:1.8.5-4.el7               @System      15 M
 kernel               x86_64     3.10.0-1160.31.1.el7        @System      64 M
 kernel               x86_64     3.10.0-1160.36.2.el7        @System      64 M
 leapp                noarch     0.12.1-1.el7_9              @System      93 k
 leapp-repository     noarch     0.14.0-4.el7_9              @System     1.7 M
 python2-leapp        noarch     0.12.1-1.el7_9              @System     618 k
 ustr                 x86_64     1.0.4-16.el7                @System     279 k

Transaction Summary
===============================================================================
Remove  7 Packages

Freed space: 146 M
Is this ok [y/N]:

# cd /lib/modules && ls -d *.el7*
3.10.0-1160.25.1.el7.x86_64  3.10.0-1160.36.2.el7.x86_64
3.10.0-1160.31.1.el7.x86_64

# /bin/kernel-install remove 3.10.0-1160.36.2.el7.x86_64 /lib/modules/3.10.0-1160.36.2.el7.x86_64/vmlinuz
# /bin/kernel-install remove 3.10.0-1160.25.1.el7.x86_64 /lib/modules/3.10.0-1160.25.1.el7.x86_64/vmlinuz
# /bin/kernel-install remove 3.10.0-1160.31.1.el7.x86_64 /lib/modules/3.10.0-1160.31.1.el7.x86_64/vmlinuz

Damit ist es geschafft. Das System wurde erfolgreich auf RHEL 8 aktualisiert.

Fazit

Dieser Artikel stellt das RHEL-In-Place-Upgrade vor und nennt kurz einige Gründe, wann dies gegenüber einer Neuinstallation Vorteile bietet. Anschließend wurde das Upgrade an einem Testsystem demonstriert mit dem Ziel, einen Überblick über den Upgrade-Prozess zu geben.

Für In-Place-Upgrades von Produktionssystemen ist ein Blick in die Hersteller-Dokumentation, Backups und sorgfältige Planung unerlässlich.

Das für diesen Artikel verwendete Testsystem besteht lediglich aus einer Minimal-Installation ohne Anwendungen von Dritten. Ob ein In-Place-Upgrade auch mit installierten Anwendungen Dritter funktioniert, hängt vom Einzelfall ab und ist sorgfältig zu prüfen und zu testen.

Erste Versuche mit Web- und Anwendungsservern aus unserer Umgebung konnten mit positivem Ergebnis abgeschlossen worden.

Es gibt Anwendungsfälle, wo ein In-Place-Upgrade vorteilhaft ist. Ich persönlich bevorzuge, wenn möglich und vom Aufwand vertretbar, jedoch die Neuinstallation inkl. Migration der Daten auf einem neuen System. So kann sichergestellt werden, dass keine unentdeckten Altlasten mitgeschleppt werden.

[0] Upgrading from RHEL 7 to RHEL 8. Instructions for an in-place upgrade from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8. Red Hat Enterprise Linux 8. Red Hat Customer Content Services.

[1] Supported in-place upgrade paths for Red Hat Enterprise Linux (Login required)

[2] Red Hat Enterprise Linux technology capabilities and limits

[3] Data required by the Leapp utility for an in-place upgrade from RHEL 7 to RHEL 8 (Login required)

Grundlagenwissen: Verschlüsselungsverfahren

Schreibe eine Antwort

Verschlüsselung, zur Wahrung der Vertraulichkeit einer Nachricht, spielt in der IT-Welt eine große Bedeutung. Ein Grundverständnis weit verbreiteter Verschlüsselungsverfahren ist Pflicht für jene, die in der IT arbeiten. Aber auch für Nutzer ist ein Grundverständnis hilfreich, um Anwendungen, Apps und Dienste hinsichtlich ihrer Sicherheit einschätzen und bewerten zu können.

In diesem Artikel erkläre ich die grundlegenden Konzepte asymmetrischer und symmetrischer Verschlüsselungsverfahren. Mein Ziel ist es, damit ein solides Grundwissen zu vermitteln, ohne in die Tiefen der Mathematik abzuschweifen. So werdet ihr diesem Artikel auch folgen können, wenn Mathematik nicht zu euren stärksten Fächern gehörte.

Akteure

Alice und Bob werden als Synonyme für Sender und Empfänger einer Nachricht
verwendet: Alice sendet eine Nachricht an Bob. Neben Alice und Bob werden
noch folgende Akteure in diesem Text eine Rolle spielen:

Eve, von engl. eavesdropper (zu deutsch Lauscher/Lauscherin), ist passiver Angreifer. Sie versucht, ausgetauschte Nachrichten mitzuhören (und auch zu verstehen). Sie kann die übertragenen Nachrichten jedoch nicht verändern oder in die
Systeme von Sender und Empfänger eindringen.

Marvin bezeichnet einen aktiven Angreifer. Dieser kann aktiv in das Geschehen
eingreifen, indem er z. B. Nachrichten fälscht oder zu übertragende Nachrichten
verändert.

Trudy, von engl. intruder (Eindringling), wird in ähnlicher Rolle wie Marvin gebraucht. Im Unterschied zu diesem jedoch mit dem Fokus auf das Eindringen in ein bestehendes System.

Verschlüsselung

Durch die in diesem Text beschriebenen Verschlüsselungsverfahren sollen in Bezug auf eine Kommunikationsverbindung im Wesentlichen die drei folgenden Ziele erreicht werden:

Vertraulichkeit Nur direkt an der Kommunikation beteiligte Sender und Empfänger haben Zugriff auf den Inhalt einer Nachricht. Unbeteiligte Dritte können den Inhalt der Nachricht hingegen nicht lesen.

Integrität Durch entsprechende Verfahren kann ̈uberprüft werden, ob eine Nachricht auf dem Übertragungsweg verändert wurde. Dadurch wird die Nachricht vor Fälschung durch Dritte auf dem Übertragungsweg geschützt.

Authentizität Der Absender einer Nachricht kann überprüft werden. Es soll damit verhindert werden, dass Marvin Nachrichten im Namen von Alice versendet.

Dabei werden im Allgemeinen symmetrische und asymmetrische Verschlüsselungsverfahren unterschieden.

Symmetrische Verschlüsselung

Symmetrische Verschlüsselung beschreibt ein Verfahren, bei dem zur Ver- und
Entschlüsselung von Daten der gleiche Schlüssel verwendet wird. Mit einem solchen Schlüssel kann Alice bspw. ihre Daten verschlüsseln, um sie vor den neugierigen Augen Eves zu schützen. Damit nun niemand außer Alice die Daten entschlüsseln und lesen kann, muss Alice den Schlüssel geheim halten. Daher wird dieses Verfahren auch als secret key Verschlüsselung bezeichnet.

Möchte Alice nach diesem Verfahren Nachrichten mit Bob austauschen, müssen beide über den gleichen Schlüssel verfügen, um Nachrichten ver- und entschlüsseln zu können. Die Kenntnis des geheimen Schlüssels stellt ein gemeinsames Geheimnis von Alice und Bob dar. Dieses Geheimnis wird auch als shared secret bezeichnet.

symmetriy-key-encryption
Nachrichtenübertragung unter Einsatz symmetrischer Verschlüsselung

In obiger Abbildung verwendet Alice einen geheimen Schlüssel, um eine Nachricht an Bob zu verschlüsseln. Bob verwendet den gleichen geheimen Schlüssel, um die Nachricht wieder zu entschlüsseln. Hören Eve und Trudy die Nachricht während der Übertragung ab, sehen sie nur den verschlüsselten Text und nicht die ursprüngliche Nachricht. Die Kommunikation von Alice und Bob bleibt so lange vertraulich, wie der verwendete Schlüssel geheim bleibt.

Die Schwierigkeit bei der symmetrischen Verschlüsselung besteht darin, dass Alice vor Beginn des Nachrichtenaustauschs Bob den geheimen Schlüssel mitteilen muss. Hierbei besteht das Risiko, dass der geheime Schlüssel bei der Übertragung von Eve abgehört werden kann. Eve könnte damit fortan die Kommunikation zwischen Alice und Bob mithören, mit Hilfe des geheimen Schlüssels entschlüsseln und damit auf den ursprünglichen Nachrichtentext zugreifen.

Asymmetrische Verschlüsselung

Symmetrische Verschlüsselung leistet gute Arbeit bei der Verarbeitung großer Datenmengen mit hoher Geschwindigkeit. Doch bleibt das Problem des sicheren
Schlüsselaustauschs. Dieses Problem wächst mit der Menge der Kommunikationsteilnehmer. Denn alle Teilnehmer müssen über den gleichen geheimen Schlüssel verfügen. Je mehr Teilnehmer Kenntnis über den geheimen Schlüssel haben, desto größer ist das Risiko der Kompromittierung.

Dieses Problem versucht die asymmetrische Verschlüsselung (welche auch als
public key Verschlüsselung bezeichnet wird) zu lösen, indem für die Ver- und
Entschlüsselung unterschiedliche Schlüssel verwendet werden.

Nutzer erstellen mit Hilfe einer Anwendung zuerst ein Schlüsselpaar, bestehend aus einem privaten und einem öffentlichen Schlüssel.

public-private-keygeneration.svg
Erzeugung eines Schlüsselpaars: Blaue Bildelemente sind geheim, orange sind öffentlich. Bildquelle: https://de.wikipedia.org/wiki/Datei:Orange_blue_public_private_keygeneration_de.svg

Der öffentliche Schlüssel wird zur Verschlüsselung einer Nachricht genutzt und kann frei verteilt werden. Die mit diesem öffentlichen Schlüssel verschlüsselten Daten können, wie in folgender Abbildung dargestellt, ausschließlich mit dem dazugehörigen privaten Schlüssel wieder entschlüsselt werden.

public-key-cryptography.svg
Verschlüsselung mit öffentlichem Schlüssel und Entschlüsselung mit privatem Schlüssel. Bildquelle: https://de.wikipedia.org/wiki/Datei:Orange_blue_public_key_cryptography_de.svg

Darüber hinaus kann mit dem privaten Schlüssel eine Signatur erstellt werden. Mit Hilfe des dazugehörigen öffentlichen Schlüssels kann anschließend die Authentizität und Integrität einer Nachricht überprüft werden:

digital_signature_de.svg
Signieren mit privatem Schlüssel und Verifikation mit öffentlichem Schlüssel. Bildquelle: https://de.wikipedia.org/wiki/Datei:Orange_blue_digital_signature_de.svg

Die asymmetrische Verschlüsselung findet z. B. Anwendung in OpenPGP, S/MIME und SSL/TLS-Verbindungen.

Da der zur Verschlüsselung benötigte Schlüssel nicht geheim gehalten werden muss, kann dieser auf vielfältige Weise z. B. auf Webseiten, im E-Mail-Anhang
oder über Schlüsselserver veröffentlicht werden.

Die folgende Abbildung zeigt, wie Bob eine Nachricht mit dem öffentlichen Schlüssel von Alice verschlüsselt. Alice kann diese Nachricht ausschließlich mit ihrem dazugehörigen privaten Schlüssel wieder entschlüsseln. Hört Eve die Kommunikation
ab, kann sie die Nachricht nicht entschlüsseln, da sie den zugehörigen privaten
Schlüssel nicht besitzt.

public-key-encryption.png
Bob verschlüsselt eine Nachricht und sendet sie an Alice. Bildquelle: https://en.wikipedia.org/wiki/File:Public_key_encryption.svg

Wenn Bob die Nachricht an Alice zusätzlich noch mit seinem eigenen privaten Schlüssel signiert hat, kann Alice mit Bobs öffentlichen Schlüssel überprüfen, ob die Nachricht tatsächlich von Bob stammt oder auf dem Übertragungsweg evtl. von Marvin verändert wurde.

Asymmetrische Verschlüsselung kann für die gleichen Zwecke wie symmetrische Verschlüsselung verwendet werden. Das Verfahren ist jedoch wesentlich langsamer als symmetrische Verschlüsselungsverfahren. Daher kommen in der Praxis häufig hybride Verfahren zum Einsatz.

Dabei verwendet Alice z. B. den öffentlichen Schlüssel von Bob, um einen symmetrischen Schlüssel sicher an Bob zu übertragen. Damit Bob verifizieren kann,
dass ihm der symmetrische Schlüssel auch wirklich von Alice gesendet wurde, kann Alice diesen zusätzlich mit ihrem privaten Schlüssel signieren. Bob kann den symmetrischen Schlüssel mit seinem privaten Schlüssel entschlüsseln. Anschließend nutzen Alice und Bob für die weitere Kommunikation den symmetrischen Sitzungsschlüssel.

Zusammenfassung

Dieser Artikel ist Kapitel 2 aus meinem TLS/SSL Kochbuch entnommen. Er vermittelt Grundlagenwissen zu symmetrischen und asymmetrischen Verschlüsselungsverfahren.

Während sich symmetrische Verfahren besonders durch ihre hohe Geschwindigkeit auszeichnen, stellt der sichere Austausch des shared secrets eine große Herausforderung dar. Das Problem des Schlüsselaustauschs wurde mit den asymmetrischen Verfahren gelöst. Allerdings arbeiten diese deutlich langsamer als symmetrische Verfahren. Daher werden diese Verfahren in der Praxis häufig kombiniert. So kommt ein asymmetrisches Verfahren zum Einsatz, um einen Sitzungsschlüssel auszutauschen (shared secret), welcher für die weitere Kommunikation verwendet wird.

Die in diesem Artikel beschriebenen Verfahren finden z.B. in OpenPGP, S/MIME und X.509-Zertifikaten Anwendung. Sie alle haben gemeinsam, dass Nutzer über eine private Komponente verfügen, welche stets geheim zu halten ist und eine öffentliche Komponente, die unbeschränkt geteilt werden kann.

Eine solide Kenntnis der beteiligten kryptographischen Verfahren erleichtert das Verständnis und den Umgang mit den genannten Protokollen und Werkzeugen im Alltag. Ich freue mich, wenn es mir mit diesem Artikel gelungen ist, dieses Grundlagenwissen zu vermitteln.

Quellen und weiterführende Links

  • J. Callas u. a. OpenPGP Message Format. IETF RFC 4880. The Internet Engineering Task Force (IETF R©), 2007. url: https://tools.ietf.org/html/rfc4880.
  • Charlie Kaufman, Radia Perlman und Mike Speciner. Network security : private communication in a public world ; [now includes IPsec, SSL, PKI, AES, and web security]. eng. 2. ed. Prentice Hall series in computer networking and distributed systems. Upper Saddle River, N.J. ; London: Prentice Hall PTR, 2002, XXVI, 713 S. : graph. Darst. isbn: 0-13-046019-2.
  • B. Ramsdell u. a. Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification. IETF RFC 5751. The Internet Engineering Task Force (IETF R©), Jan. 2010. url: https://tools.ietf.org/html/rfc5751.
  • Ivan Risti ́c. Bulletproof SSL and TLS : [understanding and deploying SSL/TLS and PKI to secure servers and web applications]. eng. London: Feisty Duck, 2014, XXII, 506 S. : graph. Darst., Kt. isbn: 978-1-907117-04-6.

Wie (rechts-)sichere elektronische Kommunikation aussehen könnte

3 Antworten

Am 31. August 2021berichtete die Tagesschau, dass die Telekom ihren De-Mail-Service zum 31. August 2022 einstellen wird. Diesen Schritt kann ich persönlich gut nachvollziehen, empfand ich die DE-Mail und den ePostbrief doch schon 2012 als Rohrkrepierer.

In diesem Beitrag möchte ich euch meine persönliche Vorstellung schildern, wie (rechts-)sichere elektronische Kommunikation aussehen könnte. Auf Fachchinesisch verzichte ich dabei bewusst und gehe bei der Technik nur soweit ins Detail wie absolut notwendig. So können möglichst viele Personen dem Text folgen.

Im ersten Abschnitt beschäftige ich mich damit, welche Merkmale eine (rechts-)sichere elektronische Kommunikationslösung aufweisen muss. Allerdings bin ich kein Jurist, so dass mir eine Beurteilung, ob etwas nach geltendem Recht tatsächlich rechtssicher ist, nicht möglich ist.

Anschließend beschreibe ich, warum es aus meiner Sicht bisher nicht geklappt hat, eine Lösung zu etablieren und was den existierenden Lösungen zum Erfolg fehlt.

Zum Schluss beschreibe ich meine Wunschlösung.

Welche Merkmale muss eine Lösung besitzen?

Eine Lösung für die Kommunikation mit und zwischen Behörden, Bürgern und Unternehmen muss gewisse Anforderungen an Authentizität, Integrität, Vertraulichkeit, Verbindlichkeit und Zurechenbarkeit erfüllen.

So muss hinreichend sichergestellt bzw. nachvollzogen werden können, von wem eine Nachricht stammt (Authentizität) und ob sie auf dem Weg vom Sender zum Empfänger verändert worden ist (Integrität). Ebenso muss sichergestellt werden, dass ein Sender einer Nachricht seine Willensbekundung nicht unzulässig abstreiten kann (Verbindlichkeit und Zurechenbarkeit). Üblicherweise sollen nur der Sender und die adressierten Empfänger Kenntnis über den Inhalt einer Nachricht erlangen (Vertraulichkeit).

In der analogen Welt dient zum Nachweis der Authentizität häufig die Vorlage eines Ausweisdokuments und/oder die eigenhändige Unterschrift. Bei einem Brief mit eigenhändiger Unterschrift wird in der Regel die Integrität unterstellt. Auch die Anforderungen an die Verbindlichkeit und Zurechenbarkeit gelten dabei in den meisten Fällen als erfüllt. Vertraulichkeit erreicht man häufig schon dadurch, dass man eine Nachricht in einem verschlossenen Briefumschlag verschickt, statt sie auf eine Postkarte zu schreiben. All diese Maßnahmen bieten keinen hinreichenden Schutz vor der Ausspähung und Manipulation durch Geheimdienste. Doch dies ist meines Wissens auch nicht die Anforderung, welche an die analogen Kommunikationsmittel gestellt wird.

Eine elektronische Lösung muss mindestens die gleichen Anforderungen erfüllen wie ihr analoges Gegenstück. Sonst bietet sie kaum einen Mehrwert und stellt den Nutzer sogar schlechter.

Das vermutlich wichtigste Merkmal kommt zum Schluss. Eine Lösung muss gleichermaßen auf dem Desktop-PC, Notebook, Tablet und selbstverständlich Smartphone nutzbar sein.

Digitale Signaturen für Authentizität, Integrität, Verbindlichkeit und Zurechenbarkeit

Ich belasse es hier bewusst bei einer ganz allgemeinen und un-technischen Beschreibung des Verfahrens.

Eine digitale Signatur besteht grundsätzlich aus zwei Komponenten. Einer Komponente zum Signieren einer Nachricht bzw. eines Antrags oder sonstigen Dokuments und einer Komponente, mit welcher eine solche Signatur überprüft und ihrem Besitzer zugeordnet werden kann.

Und technische Internetstandards dazu existieren bereits. Das Rad muss nicht neu erfunden werden:

Unbestritten ist, dass es im Bereich der nutzbaren Implementierung dieser Standards noch erhebliches Verbesserungspotenzial gibt.

Vertraulichkeit durch Verschlüsselung

Hierfür existieren in der IT bereits etablierte Ansätze. Diese sind oben in vier Punkten bereits aufgeführt.

Den größten Fehler, den man begehen kann, ist eine eigene Verschlüsselung für seine Anwendung zu entwickeln. Die Erfahrung zeigt, dass es nicht lange dauert, bis diese gebrochen ist. Auch hier gilt, erfindet das Rad nicht neu.

Ob es sich dabei stets um Ende-zu-Ende-Verschlüsselung handeln muss, stelle ich in Frage. Ein Brief wird häufig bereits im Posteingang geöffnet und dann intern an die bearbeitende Stelle weitergeleitet. Äquivalent und in vielen Fällen ausreichend wäre demnach eine Transport-Verschlüsselung, welche eine Nachricht verschlüsselt vom Sender an den Verantwortungsbereich einer Organisation bzw. des Empfängers transportiert, wo diese intern jedoch entschlüsselt weitergeleitet und bearbeitet werden kann. Dem spricht nicht entgegen, dass es Nachrichten einer erhöhten Vertraulichkeitsstufe geben kann, welche nur durch bestimmte Empfänger entschlüsselt werden können dürfen.

In diesem Bereich existieren bereits funktionierende Lösungen, welche die klassische E-Mail ergänzen. Zugegeben sind diese aktuell jedoch technisch versierten Personen vorbehalten, da es seit Jahren an einfach zu nutzenden Client-Implementierungen mangelt.

Einwurf-Einschreiben und das Fax mit Sendebericht

Sind Fristen zu wahren, ist es nach meiner Erinnerung ausreichend, wenn eine Nachricht innerhalb der Frist im Verantwortungsbereich des Empfängers eingeht. Damit kann der Briefkasten oder das empfangende Fax gemeint sein. Zum Nachweis dient dem Sender in diesen Fällen ein Einschreiben oder der Sendebericht des Fax.

Entsprechende rechtliche Rahmenbedingungen vorausgesetzt, wäre es ausreichend, wenn eine E-Mail den empfangenden Mailserver fristgerecht erreicht. Mit der „Delivery Status Notification (DSN)“ existiert auch hier bereits eine technische Lösung, bei welcher der Mailserver eine Status-E-Mail an den Absender der E-Mail versendet. Einziger Haken an dieser Sache ist, dass es aktuell allein in der Verantwortung des Mailserver-Betreibers liegt, ob diese Funktion aktiviert ist oder nicht. Man kann sich also nicht darauf verlassen, dass man eine entsprechende Benachrichtigung erhält.

Warum es bisher nicht geklappt hat

Hier lassen sich in meinen Augen zwei Problembereiche differenzieren.

Sicherheit und Nutzbarkeit

Die gute alte E-Mail an sich ist wie eine Postkarte. Jeder, der sie auf dem Transportweg in die Hände bekommt, kann sie lesen. Um die E-Mail für Authentizität und Integrität zu ertüchtigen, gibt es seit Jahren OpenPGP und S/MIME, welche für normale Nutzer völlig unbenutzbar sind. Selbst unter meinen IT-Kollegen sind diese Verfahren nicht weit verbreitet.

Selbst wenn das Projekt „pretty Easy privacy“ hier eine Vereinfachung der Handhabung anstrebt, bleibt hier das Problem, dass OpenPGP-Signaturen keine qualifizierten Signaturen nach Signaturgesetz darstellen.

Bei den Alternativen sieht es jedoch nicht besser aus. An dieser Stelle mache ich es mir einfach und verlinke die entsprechenden Abschnitte in der Wikipedia zu DE-Mail, ePostbrief und BeA.

Henne-Ei-Problem

Lange Zeit besaß ich sowohl eine DE-Mail- als auch ePostbrief-Adresse und wartete auf entsprechende Angebote, wo ich einen Mehrwert aus der Nutzung ziehen kann.

Ich bin jetzt jedenfalls für die De-Mail
gerüstet und hoffe, dass im Laufe des Jahres möglichst viele
öffentliche Einrichtungen und Unternehmen der Privatwirtschaft ebenfalls
die Möglichkeit schaffen, die Kommunikation via De-Mail abzuwickeln.
Denn nur wenn diese Institutionen mitziehen wird sich die De-Mail
durchsetzen können und einen echten Mehrwert bieten. Und so werde ich
skeptisch und gespannt die weitere Entwicklung der De-Mail beobachten.

Auf dem Weg zur DE-Mail Adresse

Das Zitat stammt aus einem Beitrag von 2013. Für diesen Beitrag habe ich noch einmal geprüft, welche der Organisationen eine DE-Mail-Adresse besitzen, mit denen ich gerne auf sicherem Wege kommunizieren möchte. Das Ergebnis lässt sich aus folgender Tabelle ablesen.

Name der Organisation/des Unternehmens/der BehördeDE-Mail ja/nein?
Meine Direkt-Banknein
Meine Hausbanknein
Mein Arbeitgebernein
LBV NRWja
Meine Krankenkassenein
Alle meine verschiedenen Versicherungsanbieternein
Meine Gemeindeverwaltungnein
Die Kreisverwaltungja
Von mir regelmäßig genutzter Online-Handelnein
Tabelle: Wer unterstützt DE-Mail?

Zumindest für mich persönlich ist das Angebot sehr überschaubar. Dabei sind die DE-Mail-Adressen dann auch noch häufig gut auf den Webseiten der Anbieter versteckt. Andere, komfortabel nutzbare Kontaktmöglichkeiten stehen bereit und im Vordergrund.

Obige Anbieter haben alle gemeinsam, dass es akzeptable Kontaktmöglichkeiten gibt. So ist auf Seite der Empfänger und auf meiner Seite als Absender die Motivation gering, DE-Mail zu nutzen.

Dieses Henne-Ei-Problem wurde bis heute nicht gebrochen. Und ich glaube nicht daran, dass sich dies noch ändern wird.

Ein ähnliches Henne-Ei-Problem sehe ich aktuell auch noch bei der eID-Funktion des elektronischen Personalausweises. Außer meiner Kfz-Zulassungsstelle habe ich noch keine weiteren Anbieter gefunden, wo mir diese Funktion einen Vorteil bringt.

Wie könnte eine Lösung aussehen?

Im ersten Abschnitt dieses Beitrags habe ich bereits etwas zu Authentizität, Integrität, Verbindlichkeit und Zurechenbarkeit geschrieben. Alle diese Punkte würde ich mit einem Produkt im Scheckkartenformat adressieren, das viele Deutsche Staatsbürger bereits ihr Eigen nennen. Mit dem Personalausweis:

Dieser Personalausweis bietet neben einer Online-Ausweis-Funktion auch die Möglichkeit, Signaturzertifikate für eine qualifizierte elektronische Unterschrift zu speichern.

Mit der Online-Ausweis-Funktion gibt es die Henne. Jetzt brauchen wir noch Eier. Und mit Eiern meine ich Angebote der Behörden, Ämter und Verwaltungen zur Nutzung dieser Funktion. Diese sind nicht durch Gewinnerzielungsabsicht gehemmt und können maßgeblich dazu beitragen, den Teufelskreis zu durchbrechen. Bei den notwendigen Prozessen muss ein Fokus darauf gelegt werden, die Hürde zur Adaption durch private Unternehmen nicht zu hoch zu legen, da diese sonst keine Motivation haben, ein weiteres Authentifizierungsverfahren anzubieten.

Es gibt Kartenlesegeräte und Apps. Hier fehlt es in meinen Augen eigentlich nur noch an Angeboten.

Etwas düsterer sieht es aktuell mit der Unterschrift aus:

Derzeit gibt es keinen Anbieter für Signaturzertifikate, die mit dem Personalausweis verwendet werden können.

URL: https://www.personalausweisportal.de/Webs/PA/DE/buergerinnen-und-buerger/der-personalausweis/funktionen/funktionen-node.html#doc14626304bodyText3

Das traurige Ende dieser Funktion ist in einem heise-Artikel aus Oktober 2018 nachzulesen. Die darin genannte Petition erreichte ihr Quorum leider nicht. Die Frage lautet nun, wo bekommen wir eine Henne für diese Funktion her? Hier wünsche ich mir, dass unsere Bundesregierung uns diese beschafft.

Denn ein Teil der Infrastruktur, welche zur Verwaltung von Signaturzertifikaten benötigt wird, existiert bereits. Um einen neuen Personalausweis zu beantragen, muss die Identität des Antragstellers festgestellt werden. Hier kann ein und derselbe Verwaltungsprozess sowohl zur Beantragung des Personalausweises, als auch zur Beantragung eines Signaturzertifikats benutzt werden.

Der Vorteil für die Bürgerinnen und Bürger ist offensichtlich. Mit einem Gang zum Amt erhalten sie ihren Personalausweis mit Signaturzertifikat. Sie müssen sich daheim nicht mehr damit beschäftigen, wie sie nun ein Zertifikat auf ihren nPA bekommen.

Alternativ dazu bietet die Möglichkeit der Fernsignatur evtl. die Chance, an unsere Henne zu kommen. Das BSI hat hierzu von 2019 bis 2020 ein Pilotprojekt durchgeführt und erfolgreich beendet.

Anschließend sind es auch hier die Behörden, Ämter und Verwaltungen, welche die ersten Eier legen müssen, um die kritische Masse zu erreichen. Andere Organisationen werden dann nachziehen. Denn ich bin mir sicher, das Interesse an einer sicheren digitalen Unterschrift ist groß.

Damit hätten wir eine Lösung, um sich online auszuweisen und um Dokumente digital zu unterschreiben (signieren). Was noch fehlt, ist eine Möglichkeit diese Dokumente, unter Einhaltung eines Mindestmaß an Vertraulichkeit, an den gewünschten Empfänger zu versenden.

Tja, hier fällt mir leider auch nichts besseres ein, als die gute alte E-Mail zu ertüchtigen. Alternativ kann ich mir jedoch auch einen SSL/TLS-geschützten Uploadbereich beim Empfänger vorstellen, in den ich meine Anträge/Dokumente hochladen kann und nach dem erfolgreichen Upload eine Quittung bekomme. Allerdings fehlt bei letztem Verfahren die Antwortmöglichkeit.

Mit dem nPA als Signaturkarte und der dazugehörigen Infrastruktur fehlt es hier allerdings nur noch an passenden Clientanwendungen, um diese Zertifikate praktisch nutzbar zu machen.

Stammen die für die Verschlüsselung benötigten öffentlichen Schlüssel eines Empfängers aus einem amtlichen Verzeichnis, wurde im Vorfeld geprüft, ob der öffentliche Schlüssel von Bob auch wirklich zu Bob gehört. Und nicht Trudy einfach einen Schlüssel auf einen Schlüsselserver hochlädt und behauptet, Bob zu sein.

Sicher ist es nicht ganz so einfach, wie hier geschrieben. Sonst hätte es ganz sicher schon jemand umgesetzt. Doch denke ich, dass man ausgehend vom Personalausweis und dem elektronischen Aufenthaltstitel hier eine Lösung schaffen kann. Unsere Regierung muss es sich dazu im „Neuland“ nur gemütlich einrichten und vorangehen.

PS: Und vielleicht klappt es ja irgendwann doch noch mit verschlüsselter E-Mail-Kommunikation. ;)

Kommentare auf My-IT-Brain

Liebe Leserinnen und Leser,

es freut mich, wenn euch meine Artikel gefallen und ihr euch die Zeit nehmt, sie zu kommentieren.

Leider wird auch dieses Blog, wie viele andere, von Kommentar-Spam geplagt. Es kann daher vorkommen, dass mancher legitime Kommentar fälschlicher Weise als Spam markiert und aussortiert wird. Wenn ich einmal pro Woche die Spamliste überfliege, kann es passieren, dass ich euren Kommentar darin schlicht übersehe. Dies tut mir leid. Doch kann ich es einfach nicht leisten, alle, als Spam markierten, Kommentare einzeln zu prüfen. Daher habe ich eine Bitte.

Falls ihr einen Kommentar zu einem meiner Beiträge geschrieben oder auf einen Kommentar geantwortet habt und euer Kommentar nicht innerhalb von 1-2 Tagen freigeschaltet wird, schreibt bitte eine kurze E-Mail an webmaster(aet)my-it-brain(Punkt)de. Dann schaue ich gezielt nach.

Sollte diesers Blog eure Kommentare in der Vergangenheit verschluckt haben, möchte ich mich an dieser Stelle dafür entschuldigen.

Kommentar: Linux-Container — Spreu und Weizen

2 Antworten

In diesem Beitrag möchte ich meine persönliche Meinung zu und über Linux-Container mit euch teilen. Ich freue mich, wenn sich daraus eine Diskussion entwickelt, in der ihr eure Erfahrungen und Gedanken zum Thema einbringt.

Mir geht es dabei ausschließlich um Linux-Container, welche ich von ähnlichen Konzepten wie z.B. den LDOMs und Kernel-Zones unter Solaris, etc. bewusst abgrenzen möchte.

Was habe ich mit Containern zu tun?

Nun, Container haben in vielen Branchen Fuß gefasst, in denen IT/EDV eine Rolle spielt und werden voraussichtlich nicht mehr verschwinden. Ich selbst bin als Sysadmin und Nerd sowohl aus privatem Interesse, als auch beruflich mit dem Thema in Berührung gekommen.

Mit den Konzepten und der Architektur bin ich vertraut. Mit dem Wochenendprojekt „Kanboard im Container…“ verfüge ich über wenig praktische Erfahrung.

Wie lautet das Versprechen der Container-Technologie?

Alles wird agiler, schneller, effizienter, sicherer UND einfacher. Das Übliche halt.

Im Wesentlichen bieten Container die Chance, dass Anwendungen mit all ihren Abhängigkeiten ausgeliefert werden können.

Damit könnte das Ende der Zeit eingeläutet werden, wo einer Anwendung eine Installationsanleitung mit dem Kapitel „Systemvoraussetzungen“ beiliegt, mit welcher der Administrator sich auf die Suche nach den benötigten Bibliotheken und Paketen macht, welche in seiner konkreten Umgebung zu installieren und zu konfigurieren sind, bevor die eigentliche Anwendung installiert werden kann.

In der schönen neuen Welt verpacken Entwickler alles, was ihre Anwendung braucht, in einen Container, welchen sie anschließend in den Versand geben (deployen) können. Auf dem Zielsystem wird nur noch eine kompatible Container-Engine benötigt und die Anwendung läuft.

Dabei sind Szenarien realistisch, in denen Anwendungen z.B. in einem Ubuntu-Userland auf einem RHEL-Kern laufen und umgekehrt.

Auch Update-Szenarien können deutlich vereinfacht werden. Ein neues Release kommt in Form eines neuen Container-Images, welches instanziiert wird. Gibt es Probleme, bringt man die laufende Instanz um und startet eine Instanz vom vorherigen Container-Image. Vorausgesetzt die Container beinhalten keine persistent zu speichernden Daten (was sie laut Konzept nicht sollen), kann das wirklich gut funktionieren.

Und wie fühlt sich das bis jetzt in der Praxis an?

Die kurze Antwort auf diese Frage lautet: „Sehr unterschiedlich. Das Spektrum reicht von gut bis durchwachsen.“

Ich möchte noch einmal erwähnen, dass ich Systemadministrator und kein Anwendungsentwickler bin. Ich entwickle also keine Software, welche dann mit CI/CD-Pipelines verarbeitet und ausgerollt wird. Meine Aufgabe ist eher die Bereitstellung und der Betrieb von Umgebungen, in denen Container ausgeführt werden können. Zu möglichen Kunden/Nutzern zählen dabei Teams, die eigene Anwendungen entwickeln, aber auch Teams, welche Anwendungen in Form von Container-Repositorien bzw. -Images geliefert bekommen und diese dann betreiben müssen.

Insbesondere in dem Bereich, wo uns die Aufgabe des Betriebs von extern erstellten Anwendungen obliegt, machen wir gerade ein paar Erfahrungen, die ich hier gerne aus meiner persönlichen Sicht teilen möchte.

Beginnen möchte ich mit der insgesamt positiven Erfahrung, die ich mit meinem Wochenendprojekt „Kanboard im Container…“ gemacht habe. Hier laufen eine Anwendung und eine Datenbank jeweils als Container in einem Pod auf einem RHEL 8 Host mit einer Rootless-Podman-Installation und einem Reverse-Proxy. Die Dokumentation von Red Hat und dem Kanboard-Projekt sind hinreichend genau und verständlich, um diese Anwendung ohne große Mühe zu betreiben. Ohne große Verrenkungen kann ich unterschiedliche Versionen aus dem Postgres-Container-Repo ausprobieren und verschiedene Releases der Anwendungen testen.

Leider hat man nicht immer soviel Glück. Ein anderes Software-Projekt, dessen Namen ich hier bewusst nicht nenne, liefert eine kleine Sammlung von Bash-Skripten aus, welche in einer bestimmten Reihenfolge auszuführen sind, um zur Laufzeit eine Docker-Compose-Datei zu generieren, auf deren Basis dann entsprechende Container gestartet werden. Wenn nun ein Update ansteht, ist der ganze Prozess mit der Ausführung der Bash-Skripte in wohldefinierter Reihenfolge erneut durchzuturnen. Das ganze lässt sich ausschließlich auf einem Host mit einer Docker-Installation ausführen und ist zu Podman inkompatibel. Ob es auch mit einer Rootless-Docker-Installtion läuft, ist noch zu testen. Ein Deployment auf einem Kubernetes-Cluster ist undenkbar. Das Projekt stellt keinerlei Informationen dazu bereit.

Übrigens handelt es sich bei diesem Projekt nicht um ein 1-2 Personen FOSS-Projekt, sondern um eines, hinter dem ein Unternehmen steht, welches kostenpflichtige Support-Verträge für seine Anwendung vertreibt.

Es bleibt also wieder mal nur, die eigene Umgebung der Anwendung anzupassen, die sich andernfalls nur mit extrem hohen Aufwand integrieren lässt. Das kennen wir schon aus dem Zeitalter vor der Container-Erscheinung. Es ist in diesem Fall halt etwas anders, aber nicht besser.

In einem anderen Fall blieb das Erfolgserlebnis aus ähnlichen Gründen aus. Der Container mit der gewünschten Anwendung lies sich nicht in die Zielumgebung integrieren, da ein für die Kommunikation benötigtes Software-Modul fehlt. Erste Aussage des Herstellers: „Da müssen sie noch Paket XY im Container nachinstallieren.“

Halt Stopp! Sollten mit dem Container nicht alle notwendigen Abhängigkeiten mit ausgeliefert werden? Jetzt sollen wir Software im Container nachinstallieren, was zur Folge hat, dass wir damit ein neues Image erzeugen, welches wir zukünftig wieder selbst weiterpflegen dürfen? So habe ich mir die schöne neue Welt aber nicht vorgestellt. Den Aufwand mit den eigenen Anpassungen haben wir ohne Container auch. Auch hier wird es erstmal nur anders, aber nicht besser.

Allerdings möchte ich zur Ehrenrettung des Anbieters hinzufügen, dass er das fehlende Modul in sein Image einbauen und zukünftig selbst pflegen und ausliefern möchte und uns hier lediglich um Unterstützung beim Test bittet. Dies ist für mich im Sinne von FOSS und vollkommen akzeptabel. Wir wissen allerdings noch nicht, ob der Anbieter sein Versprechen hält.

Wo ist nun das Dilemma?

Ich persönlich habe eine Präferenz, wie Betriebsplattformen für Container aussehen sollten. So sehe ich die Nutzung von Rootless-Podman für einfache Anwendungen und Kubernetes bzw. Kubernetes-kompatible Lösungen für die Orchestrierung als sinnvoll an.

Leider kann ich mir nicht immer aussuchen, welche Software es zu betreiben gilt. Allzu oft muss mit dem gearbeitet werden, was bestellt bzw. geliefert wurde. Und hier sind die Probleme fast so zahlreich wie außerhalb der Container-Welt. Die einen laufen nur mit Docker, aber nicht im Rootless-Modus. Die anderen verlangen eine Docker-Swarm-Umgebung und Kubernetes mögen sie beide nicht. Das ist halt Pech.

Manchmal lassen sich die gelieferten Container auch ganz einfach starten, dafür aber überhaupt nicht in bestehende Umgebungen integrieren. So kann es schon in Arbeit ausarten, wenn man den voreingestellten Datenbank-Container herausoperieren muss, um den vorhandenen Datenbank-Cluster nutzen zu können.

Ein wenig neidisch blicke ich dabei zu Berufskollegen, die eigene Softwareentwicklung betreiben und von den Vorzügen ihrer Kubernetes-Cluster schwärmen.

Allerdings stehe ich mit meinen Erfahrungen noch ganz am Anfang und lasse mich gerne überraschen, was die Zukunft noch bringt.

Was habt ihr für Erfahrungen im Umgang und mit dem Betrieb von Containern gemacht? Könnt ihr hier Geschriebenes in Teilen nachvollziehen oder sind eure Erfahrungen völlig anderer Natur? Ich freue mich auf eure Beiträge in den Kommentaren und per E-Mail.

Bis bald im schönen neuen Container-Land.