Archiv des Autors: Jörg Kastning

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.

Quick Ansible: Enforce SSHD configuration options

Schreibe eine Antwort

You need to enforce certain configuration options in sshd_config, while leaving the rest of the config to your colleagues? Your colleagues need to be able to change these parameters too, temporarily, but they should be reset after a certain time? And you wanna do it with Ansible? Read on.

---
- hosts: all
  tasks:
  - name: sshd configuration file update
    blockinfile:
      path: /etc/ssh/sshd_config
      insertbefore: BOF # Beginning of the file
      marker: "# {mark} ANSIBLE MANAGED BLOCK BY LINUX-ADMIN"
      block: |
        PermitRootLogin no
        PubkeyAuthentication yes
        AuthorizedKeysFile .ssh/authorized_keys
        PasswordAuthentication no
      backup: yes
      validate: /usr/sbin/sshd -T -f %s

  - name: Restart SSHD
    service:
      name: sshd
      state: restarted

I’ll show you a playbook that sets the options PermitRootLogin, PubkeyAuthentication, AuthorizedKeysFile and PasswordAuthentication using the Ansible module blockinfile.

What happens here is that at the beginning of the file sshd_config a block is getting inserted containing the shown key-argument pairs. Inserting this block at the beginning of the file ensures that these lines are used, because first occurrence wins (see sshd_config(5)).

This playbook ensures the desired configuration that the user root is not permitted to login via ssh, public key authentication is enabled, the .ssh/authorized_keys file from user’s HOME directory should be used, and password authentication is disabled. Before /etc/ssh/sshd_config gets changed a backup is created and the new file is going to be validated prior to saving it.

The second task restarts the sshd service to make sure the desired config is going to be used.

Of course, any user with sudo or root access could edit the sshd_config file and restart the service to change the desired settings; and it might be OK to do so temporarily. To make sure any changes to the file will be reset to the desired config you could just run the playbook every 30 minutes per cron.

This was a really quick example of how to use ansible to set or change configuration settings. I hope you enjoyed it.

Neue Schwachstelle in Linux(-Paket) gefunden! Bin ich betroffen?

Schreibe eine Antwort

Es ist nur eine Frage der Zeit, bis die Fachpresse oder ein CERT über eine neue Schwachstelle im Linux-Kern oder einem der anderen für Linux verfügbaren Pakete berichtet. Diese Schwachstellen werden meist unter einer sogenannten CVE-Nummer geführt, welche die jeweilige Schwachstelle eindeutig referenziert.

In diesem Artikel beschreibe ich, wie ihr mit Hilfe der CVE-Nummer herausfinden könnt, ob euer System betroffen ist und wie ihr die aktualisierte Paketversion identifiziert, welche gegen die beschriebene Schwachstelle abgesichert ist. Der Text ist in Abschnitte gegliedert, welche die entsprechende Vorgehensweise für die Distributionen Debian (Link zum Abschnitt), RHEL (Link zum Abschnitt) und Ubuntu (Link zum Abschnitt) beschreiben.

Debian Security Bug Tracker

Unter der URL https://security-tracker.debian.org/tracker/ befindet sich der Security Bug Tracker des Debian-Projekts. Am Ende der Bug-Tracking-Seite gibt es ein Suchfeld, über welches man nach einer CVE-Nummer suchen kann.

screenshot-debian-security-bug-tracker
Screenshot: Security Bug Tracker

Der folgende Screenshot zeigt das Suchergebnis für CVE-2021-33909.

screenshot-search-result-cve-2021-33909
Screenshot: Ergebnis der Suche nach CVE-2021-33909

In der unter der Überschrift „Vulnerable and fixed Packages“ dargestellten Tabelle werden die verwundbaren und abgesicherten Paketversionen für die aktuell unterstützten Debian-Releases aufgeführt. So ist in diesem Fall das Paket für den Linux-Kern in Version 4.19.194-1 verwundbar, während mit der aktualisierten Version 4.19.194-3 eine abgesicherte Version bereitsteht.

Um nun zu sehen, welche Version auf dem eigenen System läuft, kann man z.B. das folgende Kommando verwenden, welches die Version des laufenden Kernels ausgibt:

tronde@host:~$ uname -v
#1 SMP Debian 4.19.194-2 (2021-06-21)

Da es sich bei der laufenden Version nicht um die abgesicherte Version handelt, ist davon auszugehen, dass das System verwundbar ist. Ein Update ist hier also angeraten.

Der folgende Code-Block zeigt, dass ein entsprechendes Update auch bereits angeboten wird (Ausgabe gekürzt):

tronde@host:~$ apt list --upgradable
Auflistung... Fertig
[...]
linux-image-4.19.0-17-amd64/stable 4.19.194-3 amd64 [aktualisierbar von: 4.19.194-2]
[...]

Für ein Nicht-Kernel-Paket sieht der Ablauf ein wenig anders aus. Nehmen wir dazu beispielhaft eine Schwachstelle im Paket systemd. Dazu suchen wir im Security Bug Tracker nach CVE-2021-33910.

screenshot-search-result-cve-2021-33910
Screenshot: Suchergebnis zu CVE-2021-33910

Die systemd-Paketversion 241-7~deb10u7 ist also gegen diese Schwachstelle verwundbar, während Version 241-7~deb10u8 abgesichert ist. Eine Möglichkeit, sich die installierte Version anzeigen zu lassen, besteht mit dem Befehl dpkg -l <PAKETNAME>, wobei die Spalte „Version“ die relevante Versionsnummer enthält:

tronde@host:~$ dpkg -l systemd
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name           Version       Architektur  Beschreibung
+++-==============-=============-============-=================================
ii  systemd        241-7~deb10u7 amd64        system and service manager

Der Ausgabe ist zu entnehmen, dass auch in diesem Fall die verwundbare Version installiert ist. Auch hier stehen Updates für mehrere Pakete zur Verfügung:

tronde@host:~$ apt list --upgradable | grep systemd

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libpam-systemd/stable 241-7~deb10u8 amd64 [aktualisierbar von: 241-7~deb10u7]
libsystemd0/stable 241-7~deb10u8 amd64 [aktualisierbar von: 241-7~deb10u7]
systemd-sysv/stable 241-7~deb10u8 amd64 [aktualisierbar von: 241-7~deb10u7]
systemd/stable 241-7~deb10u8 amd64 [aktualisierbar von: 241-7~deb10u7]

Ich empfehle an dieser Stelle, alle angebotenen Updates zu installieren, da diese in aller Regel mehr Vorteile als Nachteile für das aktuelle System bedeuten.

Red Hat CVE Database

Red Hat bietet unter der URL https://access.redhat.com/security/security-updates/#/cve eine Datenbank zur Suche nach CVEs an. Ruft man die URL auf, so werden existierende CVEs in umgekehrt chronologischer Reihenfolge angezeigt. Über das Suchfeld kann gezielt nach CVE-Nummern gesucht werden. Die Ergebnisse werden anschließend in tabellarischer Form präsentiert.

rh-cve-database
Screenshot: Red Hat CVE Database

Mit einem Klick auf die CVE-Nummer gelangt man auf eine Seite, welche die Schwachstelle im Detail beschreibt und darüber hinaus Informationen zur Mitigation und abgesicherten Paketen bietet. Der folgende Screenshot zeigt einen Auszug dieser Seite für CVE-2021-33909. Darin ist eine Tabelle dargestellt, welcher die betroffenen Plattformen und die jeweiligen Paketnamen zu entnehmen sind. Die Tabelle lässt sich über das Suchfeld weiter filtern und nach Spalten sortieren. So kann man leichter einen Überblick über alle von der Schwachstelle betroffenen Pakete der eigenen Plattform bekommen.

screenshot-affected-pkgs-and-issued-errata
Screenshot: Affected Packages and Issued Red Hat Security Errata for CVE-2021-33909

Red Hat behebt sicherheitsrelevante Probleme mit Hilfe sogenannter Red Hat Security Advisories (RHSA). Der Spalte Errata der obigen Tabelle ist das jeweilige RHSA zu entnehmen. Ein Klick darauf führt zur jeweiligen Beschreibung des RHSA. Es ist nicht unüblich, dass ein RHSA mehrere Schwachstellen adressiert, wie das Beispiel RHSA-2021:2725 zeigt. Darüber hinaus bieten die RHSA Informationen, welche Pakete aktualisiert wurden und ob ein Neustart des Systems erforderlich ist, um eine Schwachstelle zu schließen.

In dem hier gewählten Beispiel ist das RHEL7-Kernel-Paket kernel-3.10.0-1160.36.2.el7.x86_64.rpm gegen CVE-2021-33909 abgesichert. Folgender Befehl zeigt mir, dass dieses Paket auf meinem RHEL7-System noch nicht verwendet wird:

[tronde@rhel7 ~]$ uname -r
3.10.0-1160.31.1.el7.x86_64

Alternativ kann man die Paketversion auch mit dem Kommando rpm -qa | grep <PAKETNAME> ermitteln. Dieses Kommando funktioniert auch für Nicht-Kernel-Pakete.

[tronde@rhel7 ~]$ rpm -qa | grep kernel
kernel-3.10.0-1160.31.1.el7.x86_64
kernel-devel-3.10.0-1160.24.1.el7.x86_64
kernel-devel-3.10.0-1160.31.1.el7.x86_64
kernel-3.10.0-1160.24.1.el7.x86_64
texlive-l3kernel-svn29409.SVN_4469-45.el7.noarch
kernel-headers-3.10.0-1160.31.1.el7.x86_64
kernel-3.10.0-1160.21.1.el7.x86_64
abrt-addon-kerneloops-2.1.11-60.el7.x86_64
kernel-devel-3.10.0-1160.21.1.el7.x86_64
kernel-tools-libs-3.10.0-1160.31.1.el7.x86_64
kernel-tools-3.10.0-1160.31.1.el7.x86_64

Dank des RHEL-Paket-Managers YUM bzw. DNF und der in den Repositories bereitgestellten Metainformationen, müssen jedoch nicht mühsam Versionsnummern manuell abgeglichen werden. Die Kenntnis der CVE-Nummer oder des RHSA genügen. Der erste Code-Block zeigt, wie ein RHEL7-System gegen CVE-2021-33909 abgesichert werden kann (Ausgabe gekürzt):

[tronde@rhel7 ~]$ sudo yum --cves=CVE-2021-33909 update
[sudo] Passwort für tronde: 
Geladene Plugins: langpacks, nvidia, product-id, search-disabled-repos,
                : subscription-manager
[...]
7 package(s) needed (+0 related) for security, out of 27 available
Abhängigkeiten werden aufgelöst
--> Transaktionsprüfung wird ausgeführt
---> Paket bpftool.x86_64 0:3.10.0-1160.31.1.el7 markiert, um aktualisiert zu werden
---> Paket bpftool.x86_64 0:3.10.0-1160.36.2.el7 markiert, um eine Aktualisierung zu werden
---> Paket kernel.x86_64 0:3.10.0-1160.36.2.el7 markiert, um installiert zu werden
---> Paket kernel-devel.x86_64 0:3.10.0-1160.36.2.el7 markiert, um installiert zu werden
---> Paket kernel-headers.x86_64 0:3.10.0-1160.31.1.el7 markiert, um aktualisiert zu werden
---> Paket kernel-headers.x86_64 0:3.10.0-1160.36.2.el7 markiert, um eine Aktualisierung zu werden
---> Paket kernel-tools.x86_64 0:3.10.0-1160.31.1.el7 markiert, um aktualisiert zu werden
---> Paket kernel-tools.x86_64 0:3.10.0-1160.36.2.el7 markiert, um eine Aktualisierung zu werden
---> Paket kernel-tools-libs.x86_64 0:3.10.0-1160.31.1.el7 markiert, um aktualisiert zu werden
---> Paket kernel-tools-libs.x86_64 0:3.10.0-1160.36.2.el7 markiert, um eine Aktualisierung zu werden
---> Paket python-perf.x86_64 0:3.10.0-1160.31.1.el7 markiert, um aktualisiert zu werden
---> Paket python-perf.x86_64 0:3.10.0-1160.36.2.el7 markiert, um eine Aktualisierung zu werden
--> Abhängigkeitsauflösung beendet
--> Transaktionsprüfung wird ausgeführt
---> Paket kernel.x86_64 0:3.10.0-1160.21.1.el7 markiert, um gelöscht zu werden
---> Paket kernel-devel.x86_64 0:3.10.0-1160.21.1.el7 markiert, um gelöscht zu werden
--> Abhängigkeitsauflösung beendet

Abhängigkeiten aufgelöst

================================================================================
 Package            Arch    Version                  Paketquelle          Größe
================================================================================
Installieren:
 kernel             x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms    50 M
 kernel-devel       x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms    18 M
Aktualisieren:
 bpftool            x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms   8.5 M
 kernel-headers     x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms   9.0 M
 kernel-tools       x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms   8.1 M
 kernel-tools-libs  x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms   8.0 M
 python-perf        x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms   8.1 M
Entfernen:
 kernel             x86_64  3.10.0-1160.21.1.el7     @rhel-7-server-rpms   64 M
 kernel-devel       x86_64  3.10.0-1160.21.1.el7     @rhel-7-server-rpms   38 M

Transaktionsübersicht
================================================================================
Installieren   2 Pakete
Aktualisieren  5 Pakete
Entfernen      2 Pakete

Gesamtgröße: 110 M
Is this ok [y/d/N]:

Mit diesem einen Befehl ist es möglich, gezielt alle betroffenen Pakete zu aktualisieren, um die Schwachstelle zu schließen. Sollen in einem Durchgang mehrere CVEs geschlossen werden, so können mehrere CVE-Nummern durch Kommata getrennt angegeben werden.

Ebenso ist es möglich, mit den RHSA-Nummern zu arbeiten, wie der folgende Code-Block zeigt (Ausgabe gekürzt):

[tronde@rhel7 ~]$ sudo yum --advisory=RHSA-2021:2725 update
Geladene Plugins: langpacks, nvidia, product-id, search-disabled-repos,
                : subscription-manager
[...]
7 package(s) needed (+0 related) for security, out of 27 available
Abhängigkeiten werden aufgelöst
--> Transaktionsprüfung wird ausgeführt
---> Paket bpftool.x86_64 0:3.10.0-1160.31.1.el7 markiert, um aktualisiert zu werden
---> Paket bpftool.x86_64 0:3.10.0-1160.36.2.el7 markiert, um eine Aktualisierung zu werden
---> Paket kernel.x86_64 0:3.10.0-1160.36.2.el7 markiert, um installiert zu werden
---> Paket kernel-devel.x86_64 0:3.10.0-1160.36.2.el7 markiert, um installiert zu werden
---> Paket kernel-headers.x86_64 0:3.10.0-1160.31.1.el7 markiert, um aktualisiert zu werden
---> Paket kernel-headers.x86_64 0:3.10.0-1160.36.2.el7 markiert, um eine Aktualisierung zu werden
---> Paket kernel-tools.x86_64 0:3.10.0-1160.31.1.el7 markiert, um aktualisiert zu werden
---> Paket kernel-tools.x86_64 0:3.10.0-1160.36.2.el7 markiert, um eine Aktualisierung zu werden
---> Paket kernel-tools-libs.x86_64 0:3.10.0-1160.31.1.el7 markiert, um aktualisiert zu werden
---> Paket kernel-tools-libs.x86_64 0:3.10.0-1160.36.2.el7 markiert, um eine Aktualisierung zu werden
---> Paket python-perf.x86_64 0:3.10.0-1160.31.1.el7 markiert, um aktualisiert zu werden
---> Paket python-perf.x86_64 0:3.10.0-1160.36.2.el7 markiert, um eine Aktualisierung zu werden
--> Abhängigkeitsauflösung beendet
--> Transaktionsprüfung wird ausgeführt
---> Paket kernel.x86_64 0:3.10.0-1160.21.1.el7 markiert, um gelöscht zu werden
---> Paket kernel-devel.x86_64 0:3.10.0-1160.21.1.el7 markiert, um gelöscht zu werden
--> Abhängigkeitsauflösung beendet

Abhängigkeiten aufgelöst

================================================================================
 Package            Arch    Version                  Paketquelle          Größe
================================================================================
Installieren:
 kernel             x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms    50 M
 kernel-devel       x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms    18 M
Aktualisieren:
 bpftool            x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms   8.5 M
 kernel-headers     x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms   9.0 M
 kernel-tools       x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms   8.1 M
 kernel-tools-libs  x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms   8.0 M
 python-perf        x86_64  3.10.0-1160.36.2.el7     rhel-7-server-rpms   8.1 M
Entfernen:
 kernel             x86_64  3.10.0-1160.21.1.el7     @rhel-7-server-rpms   64 M
 kernel-devel       x86_64  3.10.0-1160.21.1.el7     @rhel-7-server-rpms   38 M

Transaktionsübersicht
================================================================================
Installieren   2 Pakete
Aktualisieren  5 Pakete
Entfernen      2 Pakete

Gesamtgröße: 110 M
Is this ok [y/d/N]:

Auch hier können mehrere RHSA (oder auch RHBA und RHEA) durch Kommata getrennt angegeben werden. Die dargestellten Kommandos funktionieren selbstverständlich auch unter RHEL 8.

Damit ist es möglich, Schwachstellen gezielt und mit minimalen Auswirkungen auf das System zu schließen. Ich persönlich empfehle jedoch, das Patch-Fenster zu nutzen und sofern möglich alle verfügbaren Updates zu installieren. Denn in der Regel ist der Nutzen durch aktualisierte Pakete größer, als das Risiko eines potenziellen Schadens.

Die Paketmanager YUM und DNF bieten, Dank der von Red Hat bereitgestellten Metainformationen in den Repos, vielfältige Möglichkeiten, um die Installation oder Aktualisierung von Paketen granular zu steuern. Weiterführende Informationen finden sich den Manpages yum(8) und dnf(8).

In wie weit sich die hier beschriebene Vorgehensweise auch für CentOS Stream bzw. Fedora eignet, kann ich nicht sagen, da ich diese noch nicht untersucht habe.

Ubuntu CVE reports

Canonical stellt für Ubuntu unter der URL https://ubuntu.com/security/cve eine CVE-Datenbank bereit, in der sich der Status von Schwachstellen über deren CVE-Nummer recherchieren lässt.

screenshot-ubuntu-cve-reports-search
Screenshot: Ubuntu CVE reports search

Eine Suche nach einer CVE-Nummer führt zu einer Seiten mit einen Statusreport, welcher betroffene Pakete in den jeweiligen Releases und deren Status aufführt. Der folgende Screenshot zeigt dies beispielhaft für den CVE-2021-33909 und das Paket linux:

status-cve-2021-33909
Screenshot: Status des Paket ‚linux‘ zum CVE-2021-33909

Der Spalte „Status“ ist die Versionsnummer der abgesicherten Paketversion zu entnehmen. Die Vorgehensweise, um herauszufinden, welche Paketversion aktuell auf dem eigenen System installiert ist, entspricht der für Debian und kann im dortigen Abschnitt nachgelesen werden.

Zusammenfassung

Zumindest die im Rahmen dieses Artikels getesteten Distributionen bieten Webseiten, auf denen man sich zum Stand von Schwachstellen informieren kann. Dabei kann die in der Fachpresse oder vom CERT kommunizierte CVE-Nummer für eine gezielte Suche nach Informationen zur jeweiligen Schwachstelle verwendet werden.

Mir persönlich haben die Möglichkeiten von YUM und DNF zur granularen Steuerung und gezielten Mitigation von Schwachstellen am besten gefallen. Dabei sei jedoch erwähnt, dass ich längst nicht alle Distributionen und deren Paketwerkzeuge betrachtet habe.

Vorstellung: Red Hat Accelerators Program

Schreibe eine Antwort

In diesem Beitrag möchte ich euch das Red Hat Accelerators Programm vorstellen und einige Beispiele geben, was wir dort so tun. Ich selbst bin seit 2019 Mitglied dieser Gemeinschaft und freue mich, mit IT-Experten aus verschiedensten Branchen und Red Hat selbst austauschen zu können. Dieser Artikel gibt meine persönliche Meinung und Sicht auf die Red Hat Accelerators wieder. Diese kann mit der von Red Hat übereinstimmen, muss es aber nicht.

Das Programm selbst beschreibt sich als globale Gemeinschaft, bestehend aus IT-Experten unter den Red Hat Kunden/Partnern, welche ihr Wissen und ihre Leidenschaft für Red Hat Produkte und Open Source Projekte mit Fachkollegen und Red Hat teilen und sich darüber austauschen mögen. Dem Einzelnen verspricht das Programm dabei folgenden Nutzen.

Netzwerken

Kurz gesprochen sind die Red Hat Accelerators ein Slack Channel voller interessanter Menschen. Diese stammen aus den verschiedensten Branchen, wie z.B. dem Gesundheitswesen, der Automobilindustrie, Versicherungen und Banken, um nur einige zu nennen. Dazu gesellen sich auch einige „Rote Hüte“, darunter Technical Account Manager, Mitarbeiter:innen aus verschiedenen Produkt-Teams und selbstverständlich die Community-Managerinnen Andi und Lili.

Wenn man seit vielen Jahren im gleichen Unternehmen arbeitet und stets nur zu den eigenen Kollegen Kontakt hat, stellt sich häufig eine gewisse Betriebsblindheit ein. Bei den Red Hat Accelerators bietet sich die Gelegenheit, mit Fachkollegen aus der gleichen, aber vor allem auch aus anderen Branchen in Kontakt zu treten und sich auszutauschen, um über den Tellerrand schauen zu können und der Betriebsblindheit entgegen zu wirken.

Ganz nebenbei lernt man neue Anwendungsfälle für bekannte oder weniger bekannte Produkte kennen. Gleiches gilt für Fehler in bzw. Probleme mit eben diesen Produkten. So bilden sich im Chat häufig so etwas wie spontane Arbeitskreise, die Probleme in der allerneusten Version eines Produktes adressieren. Hier wird sich gegenseitig geholfen. Und sollte einmal noch keine Lösung existieren, nimmt meist einer der anwesenden TAMs (steht wahlweise für Technical Account Manager oder The Almighty Moderator) das Problem/die Frage mit, um eine Lösung zu finden.

Mir hat sich durch diesen Austausch schon einige Male ein neuer Blickwinkel eröffnet, wodurch sich neue Lösungswege auftaten. Und das selbst über Red Hat Produkte hinaus.

Zugang zu Produkt-Teams und zukünftigen Releases

Für mich persönlich ist dies der größte Nutzen, den ich aus dem Red Hat Accelerators Programm ziehe. Ich habe hier die Möglichkeit, frühzeitig Kenntnis über (geplante) Neuerungen in Red Hat Produkten zu erlangen und durch qualifizierte Beiträge die Produktentwicklung mit zu beeinflussen.

Die Produkt-Teams stellen ihre Ideen und Pläne in gemeinsamen Videokonferenzen mit den Accelerators vor und diskutieren mit uns über Anwendungsfälle sowie Vor- und Nachteile der Änderungen.

Diese Form der Kommunikation hat Vorteile sowohl für Red Hat selbst, als auch für uns Kunden. Red Hat erfährt von seinen Kunden, wo der Schuh drückt, was sich diese wünschen, um ihren Arbeitsalltag effizienter zu gestalten. Als Kund erfährt man frühzeitig von geplanten Entwicklungen und Ideen und kann diese in gewissem Rahmen mit beeinflussen. Dazu möchte ich drei Beispiele geben.

Umfragen

Regelmäßig werden Umfragen zu Produkten aus dem Red Hat Portfolio und IT-Themen durchgeführt, die viele von uns im Arbeitsalltag betreffen. Red Hat nutzt diese Fragen dazu, um seine Kunden besser kennen zu lernen. Basierend auf diesen Umfragen werden weitere Sitzungen geplant, um einzelne Punkte in kleineren Arbeitsgruppen besprechen zu können.

Umfragen werden z.B. als webbasierte Formulare durchgeführt oder als Live-Interviews mit den Produkt-Teams.

Produktvorstellungen

Hier stellt ein Produkt-Team geplante Neuerungen, Änderungen oder neue Funktionen vor und stellt sich direkt der Kritik der Accelerators. Es wird dabei darauf geachtet, dass Kritik konstruktiv geäußert wird. Ein einfaches „Das ist Mist.“ oder „Das finde ich doof.“ ist dabei nicht gern gesehen. Ein konstruktives „Ich würde mir dieses oder jenes aus folgenden Gründen wünschen.“ wird gern entgegengenommen.

Als Accelerator hat man hier die Möglichkeit, seine Wünsche mitzuteilen. Es besteht keine Garantie und kein Anspruch, dass diese Berücksichtigung finden. Auch kann man die Entwicklung nicht direkt bestimmen. Doch hat Red Hat selbstverständlich ein Interesse daran, möglichst viele seiner Kunden bei der Stange und bei Laune zu halten. Denn ein glücklicher Kunde kauft gern nochmal, während ein unglücklicher Kunde vermutlich etwas neues ausprobiert.

Schön finde ich bei diesen Veranstaltungen auch, dass man erfahren kann, warum einige Wünsche nicht berücksichtigt werden oder auf der Roadmap sehr weit hinten anstehen müssen. Dies schafft Transparenz und ist in meinen Augen sehr zu begrüßen.

Doch auch für Red Hat kann es hier manchmal eine Enttäuschung geben, wenn z.B. ein Design-Entwurf von einer großen Mehrheit abgelehnt (im Sinne von: „Wir mögen das wirklich nicht und wünschen es uns wie folgt.“) wird.

Fokus-Gruppen

In den sogenannten Fokus-Gruppen bietet sich für ausgewählte Accelerators die Chance, eng mit einem Red Hat Produkt-Team zusammen zu arbeiten.

So hatte ich im Sommer 2020 das Vergnügen, in der Fokus-Gruppe Red Hat Insights unter Leitung von Mohit Goyal (Senior Principal Product Manager, Red Hat) mitzuarbeiten. Hier bot sich mir die Möglichkeit, die besonderen Anforderungen an den Einsatz einer solchen Lösung in Deutschland und in meiner Organisation zu vertreten und dafür zu sensibilisieren. Durch den Einfluss mehrerer Red Hat Accelerators wurde die geplante automatische Registrierung von RHEL-Systemen in Red Hat Insights auf unbestimmte Zeit verschoben.

So viel Einfluss auf eine laufende Produktentwicklung hatte ich bisher bei keinem anderen Hersteller. Und ich wünsche mir deutlich mehr davon.

Welche Vorteile hat Red Hat davon?

Selbstverständlich profitiert auch Red Hat von dem Accelerators-Programm. Wie bereits erwähnt, bekommt der Hersteller hier wertvolle Rückmeldungen von vertrauten Kunden, direkt aus der Praxis. Darüber hinaus stehen die Accelerators bereit, Produktneuheiten zu testen, zu validieren und den Einsatz in der eigenen Umgebung zu prüfen, bevor diese veröffentlicht werden. Dadurch kann bei Problemen noch rechtzeitig gegengesteuert werden.

Das Programm hilft Red Hat, seine Kunden und deren Bedürfnisse besser zu verstehen und die eigenen Produkte noch besser am Bedarf der Kunden auszurichten.

Und natürlich verfügt Red Hat mit den Accelerators über ein Heer aus Enthusiasten, Evangelisten und Missionaren, welche die Open Source Botschaft in die Welt hinaus tragen. Und wir alle wissen doch, dass Mund-zu-Mund-Propaganda die wirksamste Form der Werbung ist.

Wie kann man Mitglied werden?

Ihr seid bereits Red Hat Kunde und mein Beitrag hat euch neugierig gemacht, so dass ihr ebenfalls zu den Red Hat Accelerators dazustoßen möchtet? Das ist gut, denn die EMEA-Region und besonders der deutschsprachige Raum ist aktuell noch etwas unterrepräsentiert.

Bitte lest euch die Programm-Bedingungen (in englischer Sprache) durch und bewerbt euch.

Ich selbst darf übrigens keinerlei Geschenke von Red Hat oder dem Accelerators-Programm annehmen. Wenn ihr im letzten Feld des Bewerbungsformulars also meinen Namen angebt, ist mir nicht mehr und nicht weniger gewiss, als der ewige Dank von Andi und Lili.

Es ist in 2021 ein Lenovo ThinkPad T14s (AMD) geworden

9 Antworten

Anfang April habe ich mir Gedanken zu Neuer Hardware in 2021 gemacht. Zu der Zeit hatte ich ein TUXEDO Pulse 14 Gen 1 und ein ThinkPad P14s Gen 1 ins Auge gefasst.

Eure Rückmeldungen in den Kommentaren und das Studium etlicher Testberichte auf notebookcheck.net mündeten nun in einer Entscheidung. Besonders das umfangreiche Feedback von ‚Art‘ hat meine Kaufentscheidung beeinflusst. Danke dafür.

Ich habe mir nun ein Lenovo Campus ThinkPad T14s 20UJS00K00 für 1.399 Euro bei cyberport gekauft. Das Gerät beinhaltet (Quelle: Datenblatt):

  • CPU: AMD Ryzen™ 7 Pro 4750U Prozessor (bis zu 4,1 GHz), Octa-Core
  • Display: 35,6 cm (14 Zoll) IPS Full-HD Display mit LED-Hintergrundbeleuchtung, 400 nits, 800:1 Kontrast
  • RAM: 32 GB DDR4-3200 SO-DIMM fest verlötet
  • Festplatte: 1 TB SSD M.2 2280 PCIe NVMe Opal2
  • Webcam: IR Kamera und HD720p Kamera mit ThinkShutter
  • WLAN und Bluetooth: Wireless LAN 802.11 ax und Bluetooth 5.1
  • Weitere Anschlüsse:
    • 2x USB 3.2 Gen 1 (1x Always On)
    • 2x USB 3.2 Type-C Gen 2 (mit Power Delivery und DisplayPort 1.4)
    • 1x HDMI 2.0
    • Ethernet extension connector (proprietärer Anschluss)
    • Mikrofoneingang / Kopfhörerausgang (komb.)
    • Dockinganschluss
    • MicroSD-Kartenleser; Lesegerät für Smartcards

Das Feedback von ‚Art‘ bezieht sich zwar auf das P14s, doch teilt sich dieses Modell etliche Komponenten mit dem T14s, so dass ich in der Hoffnung gekauft habe, einige Eigenschaften übertragen zu können. Dieses Feedback, der Trackpoint, dieser Testbericht und der Preis waren die Haupteinflussfaktoren bei diesem Kauf.

Es folgt ein erster persönlicher Erfahrungsbericht zum neuen Gerät.

Ach du Schreck, ist das dünn.

Mein erstes ThinkPad war ein R61. Ich habe dessen Größe, Gewicht und Robustheit geschätzt. Auch das T410 und das X201 machen einen stabilen und robusten Eindruck. Und nun ist da dieses T14s.

  • hoehenvergleich-t14s-t410
    Vergleich zwischen T41s (links) und T410 (rechts)
  • hoehenvergleich-x201-t14s
    Höhenvergleich von X201 (links) zu T14s (rechts)

Mein erster Gedanke war: „Damit erschlägst du niemanden mehr.“ (Nicht, dass ich das jemals getan hätte.)

Für ein Gerät dieser Größe ist die Stabilität in Ordnung. Erwartungsgemäß ist es nicht so verwindungssteif, wie die älteren Modelle. Dafür ist es bedeutend leichter. Ich glaube, auf dieses Gerät muss ich deutlich besser acht geben, damit es lange hält.

Die äußeren Maße finde ich hingegen optimal. Es passt genau zwischen das T410 und das X201, was mir gut gefällt.

vergleich-t410-x201-t14s
T410 (links unten), X201 (oben) und T14s (rechts unten) auf einen Blick

Um es kurz zu machen, ich habe mich mit dem T14s angefreundet.

Die einzige Sache, die sich mir bisher noch nicht erschlossen hat, ist der Sinn hinter dem proprietären LAN-Anschluss.

proprietaerer-lan-anschluss
Der proprietäre LAN-Anschluss befindet sich zwischen dem USB-C-Ladeanschluss (links) und dem USB-A-Anschluss.

Um einen LAN-Anschluss mit bis zu 1 Gbps nach außen zu führen, hätte in einen Augen ein normaler USB-C-Port gereicht. Diesen hätte man auch noch anderweitig verwenden können. Aber vielleicht steckt ja noch mehr hinter diesem Port, das mir noch nicht bewusst ist.

Und wie läuft es mit Linux?

Debian Buster wollte nicht starten. Ich habe mehrere Debian Testing Images ausprobiert, doch hat mich die Partitionierung im Installer so genervt, dass ich schlussendlich (erstmal) zu Fedora 34 Workstation gegriffen habe. Hiermit funktionierte fast alles Out-of-the-Box.

Lediglich für den Standby-Modus war noch ein Firmware-Update auf Version 1.30 notwendig. Dank LVFS war dies im Handumdrehen aus Linux heraus erledigt.

Nur ein Bug nervt mich sehr. In meinem Gerät ist ein Touchpad und Trackpoint der Firma Elantech verbaut. Bei Nutzung des Trackpoints springt dieser sporadisch an die Seiten bzw. in die Ecken des Displays. Da dieser Bug bei Lenovo bekannt ist und reproduziert werden konnte, habe ich die Hoffnung, dass hier noch Abhilfe geschaffen wird.

Mit dem letzten Debian Testing weekly-build funktionieren Stand-By (ursächlich ist hier wohl eher die aktualisierte Firmware). Nur der Trackpoint-Bug existiert wenig überraschend auch hier.

Fazit

Alles in allem ist es ein schönes Gerät. Die Linux-Unterstützung ist gut und ich habe es behalten.

Das Problem mit dem Trackpoint ist wirklich nervig, doch verschmerzbar. Zudem hoffe ich hier auf Abhilfe.

An dieser Stelle noch einmal Danke für eure Kommentare, die mir bei der Entscheidung geholfen haben.

Weiterführende Links

Ansible: Wiederherstellung meines Blogs auf Buster und Bullseye in 2021

Schreibe eine Antwort

Dies ist ein Update zu den Beiträgen:

  1. Konzept zum Deployment meines Blogs mit Ansible und
  2. Erfahrungsbericht zum Deployment meines Blogs mit Ansible.

Umgebung

Aktuell nutze ich als Ansible Control Node (ACN) ein Debian Buster mit Ansible 2.7.7. Die Backups liegen wie gehabt auf einem Speicher im lokalen Heimnetzwerk.

Als Zielsysteme für die Wiederherstellung dienen ein Debian 10 (Buster) und Debian Testing (das kommende Bullseye). Bei beiden Zielsystemen handelt es sich um minimale Installation in zwei VMs auf einem KVM-Hypervisor.

Ablauf

Zuerst habe ich meinen Blog aus dem Backup auf der Debian 10 VM wiederhergestellt. Dabei gab es tatsächlich ein Problem. Das VHOST-Template für den Webserver entsprach nicht mehr der Version, die auf dem Produktivsystem zum Einsatz kommt. Ich hatte schlicht vergessen, die Änderung nachzupflegen. Der Fehler wurde schnell identifiziert und behoben. Anschließend verlief der Wiederherstellungsprozess reibungslos.

Beim zweiten Versuch erfolgte die Wiederherstellung auf einer VM mit Debian Testing (Bullseye). Dieser Test ist für mich wichtig, um zu sehen, ob ich meinen Blog auch auf der kommenden stabilen Debian-Version ausrollen kann. Hier waren etwas mehr Anpassungen an der Rolle „deploy-my-blog“ notwendig, um dieses Blog erfolgreich wiederherstellen zu können. So haben sich einige Paketnamen geändert:

Alter NameNeuer Name
python-aptpython3-apt
python-mysqldbpython3-mysqldb
Gegenüberstellung der alten und neuen Paketnamen

Doch auch an der VM selbst war ein manueller Eingriff notwendig, bevor sich mein ACN überhaupt mit dem Node verbinden konnte. Ansible konnte auf dem Node keinen Python-Interpreter finden. Ich schiebe die Schuld der Version 2.7.7 in die Schuhe. Nachdem ich einen Symlink von /usr/bin/python auf /usr/bin/python3 erstellt hatte, klappte der Zugriff.

Der letzte Stolperstein war php-fpm. Kommt unter Buster Version 7.3 zum Einsatz so ist dies unter Bullseye 7.4. Da die Versionsnummer in meiner Ansible-Rolle hart verdrahtet ist, war auch hier eine Anpassung notwendig. Anschließend gelang auch hier die Wiederherstellung.

Fazit

Grundsätzlich klappte die Wiederherstellung wie gewohnt. Den Fehler mit der VHOST-Datei könnte ich zukünftig vermeiden, indem ich diese einfach mit aus dem Backup wiederherstelle, statt ein Template zu nutzen.

Das bei der Wiederherstellung auf einer neueren Betriebssystemversion Anpassungen erforderlich sind, hatte ich erwartet. Diese halten sich meiner Meinung nach in Grenzen und sind akzeptabel.

Die längste Zeit beanspruchte das Kopieren der Backups auf die Zielsysteme. Die eigentliche Wiederherstellung war mit den Stolpersteinen in 10-15 Minuten. Mit fehlerbereinigter Rolle sogar nur noch ca. 5 Minuten. Eine manuelle Wiedereinrichtung hat mich früher eher zwischen 30-60 Minuten gekostet. Von daher bin ich sehr zufrieden.

Postfix: From-Adresse beim Relay über Smarthost erzwingen

2 Antworten

In diesem Beitrag dokumentiere ich eine Lösung für die Meldung: „554 5.7.1 REJECT policy violation – too many different Display Names – code #242 (in reply to end of DATA command)“

Umgebung

Ich betreibe einen Virtual Private Server (VPS) im Internet, sowie einige Raspberry Pis und weitere Geräte, die man heute wohl am ehesten dem Internet der Dinge zuordnen würde.

Diese Systeme sollen mir Systemmeldungen per E-Mail senden. Dafür habe ich mir ein günstiges E-Mail-Postfach bei Mailbox.org gebucht und auf den betroffenen Systemen Postfix installiert und zum Versand über einen Smarthost konfiguriert. Die Konfiguration erfolgte über die Ansible-Rolle relaymail von Yannik. Diese dient jedoch nur als Werkzeug. Die Konfiguration kann selbstverständlich auch manuell durchgeführt werden.

Problembeschreibung

Bei einer Systemüberprüfung fielen mir einige Fehlermeldungen der folgenden Art ins Auge (einige Werte durch <Platzhalter> ersetzt):

„<Hostname und IP-Adresse> said: 554 5.7.1 id=<ID> – Rejected by next-hop MTA on relaying, from MTA(smtp:[<IP-Adresse>]:10025): 554 5.7.1 REJECT policy violation – too many different Display Names – code #242 (in reply to end of DATA command)“

Während meine Raspberry Pis mit Raspbian GNU/Linux 10 (buster) und Postfix 3.4.14-0+deb10u1 sich wie erwartet verhalten und lediglich meine E-Mail-Adresse in das Header-Feld „From“ eintragen, fügt mein VPS mit Debian GNU/Linux 10 (buster) und Postfix 3.4.14-0+deb10u1 den Namen des jeweiligen Benutzers bzw. Dienstes mit ein, welcher die E-Mail versenden möchte. Diese Informationen nimmt der VPS aus dem Kommentarfeld der /etc/passwd. Während die Kommentarfelder auf meinen Raspberry Pis leer sind, sind diese auf dem VPS entsprechend gefüllt.

Im E-Mail-Header stellt sich das dann wie folgt dar.

Header-Auszug bei E-Mail von Raspberry Pi

Date: Mon, 10 May 2021 04:56:32 +0200 (CEST)
From: no-reply@example.com

Header-Auszüge bei E-Mails vom VPS

From: no-reply@example.com (Cron Daemon)
To: root
Date: Mon, 10 May 2021 04:44:12 +0200 (CEST)
From: Jörg Kastning <no-reply@example.com>
Date: Mon, 10 May 2021 04:44:36 +0200 (CEST)
From: root <no-reply@example.com>

Lösung

Um das Problem aufzulösen, lasse ich nun Postfix das Header-Feld „From“ umschreiben und explizit auf den Wert no-reply@example.com setzen. In der /etc/postfix/main.cf müssen dazu folgende Zeilen vorhanden sein:

sender_canonical_classes = envelope_sender, header_sender
sender_canonical_maps =  regexp:/etc/postfix/sender_canonical_maps
smtp_header_checks = regexp:/etc/postfix/header_check

Inhalt der /etc/postfix/sender_canonical_maps:

/.+/    no-reply@example.com

Dies sorgt dafür, dass Postfix das Feld „Envelope-From“ explizit auf no-reply@example.com setzt.

Inhalt der /etc/postfix/header_check:

/From:.*/ REPLACE From: no-reply@example.com

Hiermit wird der Wert des Header-Felds „From“ explizit auf no-reply@example.com gesetzt. Die Lösung habe ich hier gefunden. Damit läuft der Versand meiner Systembenachrichtigungen wieder.

Weitere Artikel zu Postfix und Smarthosts in diesem Blog