Moderne Käsblättle

Manchmal kann ich meine schwäbische Herkunft nicht verleugnen. Ein Käsblättle ist eine Zeitung oder Zeitschrift, die man nicht ernst nehmen muss oder darf. Beispiele dafür z.B. in Käsplättle ond Käsblättle oder Die junge Speyerer Morgenpost hat eine lange Geschichte und einen gewitzten Verleger: Die Käsblättle der Familienmafia, und über diesen Artikel hat der Begriff sogar den Einzug in die deutsche Wikipedia geschafft. Im Saarland findet sich es Käsblättsche, die den Namen angenommen hat, nur halt mit dem saarländischen Äquivalent -sche statt -le.

Zwei Beispiele für Käsblättle bzw. Zeitschriften im IT-Bereich mit fragwürdigem Inhalt will ich aufgreifen, vielleicht wird die Liste in der Zukunft auch erweitert. Beiden Beispielen ist gemeinsam, dass die Zeitschriften zwar gegen teuer Geld abonniert werden können, aber auch ganz oder teilweise kostenlos im Internet einsehbar sind. Gemeinsam haben sie auch, dass kritische Leserbriefe offensichtlich nicht erwünscht sind.

Natürlich kann ich nicht den Inhalt jedes Artikels beurteilen. Ich beschränke mich daher auf die, bei denen ich denke, wirklich mitreden zu können. Aber vertrauenswürdig ist es nicht, da scheint jedenfalls kein ernsthafter Review stattzufinden. Mir liefern diese Zeitschriften allenfalls Hinweise, womit ich mich noch befassen könnte, dann aber an anderer Stelle recherchieren muss.

Linux-Magazin

Diese Zeitschrift adressiert vermutlich, was ich mit meiner Freundin scherzhaft die Keller-Kinder der IT nenne, den Administrator der die IT am laufen hält, und gelegentlich neue Produkte ausprobiert, wobei nicht immer klar ist, ob die für den heimischen oder den Organisationskeller sein sollen. Dort aufgefallen sind mir mehrere Artikel von Martin Loschwitz, die in meinen Augen unnötig gedrucktes Papier belegen. Über einen – NAS im Eigenbau statt vorkonfektionierter Fertigsysteme – habe ich mich schon in CIA, (to) DIE, or CAP? ausgelassen. Einen anderen darf ich hier nennen: Sicher mailen. Ich musste den Artikel mehrfach lesen um etwas mit Bezug zu Sicherheit zu entdecken. Tatsächlich gäbe es einiges was man ansehen könnte:

Sicherheit des Emailservers selbst

Den Emailserver verschlüsseln? Das hätte ich auch beim Artikel zu NAS erwartet, aber in beiden Fällen Fehlanzeige. Dass Docker den Emailserver sicherer macht? Hängt davon ab wie die Container konfiguriert werden, aber das wird nur angesprochen, nicht aber ausgeführt. Im Link zum Artikel findet sich etwas zu Beispiel-Container mit Postfix und Rspamd. Im dortigen Dockerfile ist jedenfalls kein USER-Statement enthalten.

Sicherheit der Authentifizierung der eigenen Benutzer

Im Artikel wird ein SASL LDAP Plugin erwähnt, das man für postfix und hoffentlich auch für dovecot einsetzen kann. Wie man das konfiguriert wird aber leider nicht erwähnt. Das wäre interessant, denn die extern verwendeten Emailadressen stimmen bei vielen Organisationen nicht mit dem Benutzernamen überein, so dass ein Mapping erforderlich ist.

Sichere Kommunikation

In Abschnitt Das Medium absichern steht Sinnvoller ist es dagegen, den Mailserver mit SSL zu betreiben oder ihm zumindest einen SSL-Terminator voranzustellen. Das oder ... SSL-Terminator ist in meinen Augen ein Fehler, nicht nur weil SSL veraltet und TLS aktuell ist, sondern ich rate davon ab, denn zwischen SSL-Terminator und Mailserver kann dann ein Angreifer alles mitlesen. In den Abschnitten Senden und Empfangen und DMARC, DANE und mehr tauchen dann die Begriffe SPF, DKIM, DMARC und DANE auf, aber wenig strukturiert. Dass SPF, DKIM, DMARC der Authentifizierung des sendenden Servers dient findet sich leider erst im unpassenden Abschnitt DMARC, DANE und mehr, dass DANE (oder auch das gar nicht erwähnte MTA-STS) nicht nur zur Erzwingung von STARTTLS sondern auch der Authentifizierung des empfangenden Servers dient fehlt ganz. Dass ein Emailserver eine Email zurückweist, wenn die DKIM-Signatur falsch ist – das ist eher selten, denn das erlaubt eigentlich nur die Kombination mit DMARC, und dass DMARC empfangsseitig verwendet wird ist eine seltene Ausnahme. Dass man all diese Standards in Sende- und Empfangsrichtung verwenden sollte wird leider nicht erwähnt, die Beispiele von DNS-Einträgen beziehen sich immer nur auf eine davon. Vielleicht erklärt das, warum so viele Organisationen SPF, DKIM und DMARC nur beim Senden und DANE oder MTA-STS nur beim Empfangen, selten aber in beiden Richtungen können? Die Ausführungen zu Mailinglisten sind meiner Auffassung nach überwiegend falsch, aber das ist weder mein Spezialgebiet noch würde eine ernsthafte Kritik allein vom Umfang in diesen Artikel passen.

Sicherheit vor Spam, Viren, Phishing

Hier werden Amavisd, SpamAssassin, ClamAV und Rspamd erwähnt, aber eigentlich keine konkreten Empfehlungen gegeben. Einiges finde ich verwirrend oder irreführend. Natürlich kann postfix mit rspamd und ClamAV zusammenarbeiten und Spam zurückweisen statt akzeptieren.

Ein Artikel zum Absichern und vielleicht dann auch Testen eines Mailservers wäre durchaus interessant. Aber warum sollte man überhaupt bei 0 anfangen? mailcow: dockerized liefert einen vollständigen und vorkonfigurierten Emailserver auf Basis von Docker, setzt die gleichen Komponenten zusammen wie im Artikel, und fügt weitere hinzu. Um die rspamd- und ClamAV-Konfiguration muss man sich nicht kümmern – funktioniert out-of-the-box. Ich betreibe meinen mailcow seit April 2018 und musste bei Inbetriebnahme noch nicht einmal die Dokumentation der integrierten Komponenten lesen. Das ist erst erforderlich, wenn man Details ändern will, z.B. DANE aka RFC 7672 (s.a. RFC 7672 mit Mailcow / Postfix). Aber auf eine weitgehend fertige Lösung wollte man wohl nicht hinweisen, denn dann wären mindestens 5 der 6 Seiten Artikel unnötig gewesen. Zugegeben: von einem SASL-LDAP-Plugin steht bei mailcow nichts, vermutlich weil das im kostenpflichtigen Supports angeboten wird, aber eine echte Anleitung findet sich im Artikel halt auch nicht. Da die Konfigurationsdateien von postfix und dovecot bei mailcow zugänglich sind, kann man die auch ändern, sollte aber natürlich den Testaufwand nicht unterschätzen.

Letztendlich liefert der Artikel kaum Hilfestellung, einen Emailserver wirklich sicher zu konfigurieren. Er reißt Themen an ohne weiterführende Information oder Anleitungen zur Konfiguration zu liefern.

Mein Verdikt: Vorsicht vor unreflektierter Übernahme irgendwelcher Informationen aus Artikeln. Ich habe die Redaktion angeschrieben. Eine Emailadresse von Herrn Loschwitz habe ich nicht.

IT-Sicherheit

Bei IT-Sicherheit ist die Grenze zwischen Anzeige und Artikel äußerst fließend. Es gibt auch Advertorials, ein Kunstwort aus Advertisement und Editorial, aber leider findet sich auch in vielen Artikeln wenig konzeptionelles sondern nur Marketing. Zwei Beispiele greife ich aus der IT-Sicherheit 04/2024 heraus und habe damit auch den Chefredakteur konfrontiert:

Interessant ist der Hinweis im Impressum:

Für mich bleibt da offen, ob die Redaktion überhaupt eine Meinung hat.

Weil mir das zumindest grenzwertig erschien habe ich die Landesanstalt für Medien Nordrhein-Westfalen dazu befragt. Die sieht aber keinen Verstoß darin:

Nicht gefragt habe ich den Presserat, denn der Pressekodex ist freiwillig und es gibt keinen Hinweis darauf, dass IT-Sicherheit sich dem unterwirft. Dort heißt es:

Statt dass man also das Durchrutschen von fragwürdiger Meinung ohne Tatsachen einräumt, droht man mir mit der Rechtsabteilung als ich nachhake.

Was lernen wir daraus? Wir müssen selbst prüfen und entscheiden, was wir für richtig halten. Presse darf zwar keine bekannt falschen Fakten verbreiten, aber das Weglassen von Fakten bis zur vollständigen Sinnentleerung ist alleine kein Verstoß gegen die Sorgfaltspflicht. Und Meinung darf sie im Rahmen der Meinungsfreiheit eben auch tendenziöse haben. Auch ich! Nur dass ich versuche, meinen Lesern auch die Fakten oder Quellen meiner Meinung offenzulegen.

Kommunikation