EMail Datenschutz – Mail Header filtern

Vor einigen Tagen fiel mir bei der Untersuchung  des, auch an dieser Stelle behandelten, TLS-Fehlers auf, das die E-Mail Header aller über meinen Server vesandten EMails die folgenden beiden Header-Zeilen enthalten.:

Ich bin mir, mit Blick auf den 25. Mai 2018 nicht sicher ob eine EMail diese zusätzlichen, nicht für die Erfüllung des Dienstes erforderlichen, Metadaten weiterhin beinhalten darf.
(Lieber Leser, liebe Leserin, wenn Du eine Online-Rechtsberatung erteilen darfst und dich mit der EU-Datenschutz-Grundverordnung auskennst, würde ich mich über einen Kommentar ↓ von Dir sehr freuen!)

Da ich es persönlich nicht mag wenn Daten versteckt vorliegen (in diesem Fall im EMail-Header) die nicht benötigt werden aber dritten unter bestimmten Umstenden helfen können mir zu schaden habe ich mich für die Entfernung der Header-Zeilen entschieden. Auch ein Blick in die RFC5321, und einige eigene Tests, zeigen das diese beiden Header-Zeilen nicht für die Zustellung verwendet werden und somit die Entfernung nicht schadet.

Vorgehen:

1.) Den EMail-Server Prüfen

Mit dem Postfix-Konfigurationsparameter header_checks kann ich die EMails am einen PCRE Filter weitergeben und verändern lassen.
Mit dem Postfix-Konfigurationsparameter smtpd_sasl_authenticated_header Erweitere ich den EMail-Header um einen Eintrag über den zur Authentifizierung am EMail-Server genutzten Benutzernamen.

Ich bekomme für beide Konfigurationen eine leere Antwort, daher schaue ich nach den Defaultwerten.:

2.) EMail-Server Konfiguration anpassen

Da ich vor habe den Filter über PCRE umzusetzen benötige ich das Debian Paket postfix-pcre, welches die Unterstützung dür die gewünschten Perl Regular Expressions für Postfix mitbringt.:

Nach dem das Paket installiert ist lege ich auf dem Server eine Datei mit dem Namen „header_checks“, im Postfix Verzeichnis, an. In dieser Datei werden die Filterregeln hinterlegt.:
sudo vi /etc/postfix/header_checks

Im Anchluss verlange ich vom Postfix dem Benutzernamen, der zur Anmeldung am EMail-Server verwendet wurde in die Header einzufügen und die Mail Header über meinen Filter zu leiten.:

Nach dem folgenden neustart von Postfix kann ich mir eine Testnachricht senden und die Header prüfen.

Bei meinem Vergleich des neuen EMail-Headers mit dem EMail-Header einer älteren EMail, die ich mir vor der Einrichtung des Filters gesandt habe, fehlen die von mir zu begin beanstandeten Header Zeilen.

Korrektur für Postfix TLS-Fehler „untrusted issuer“

Postix Logo mit Schriftzug Postfix

Ich konnte beim EMail-Versand von meinem Postfix EMail-Server zu GMX einmal wieder keine EMails zustellen. Laut Fehlermeldung in der Mail Delivery Notification gab es einen Zertifikatsfehler.

In den Postfix Logfiles erscheint die TLS-Fehlermeldung „untrusted issuer“.:

Der Aussteller des Zertzifikats des GMX-EMail Servers war meinem Postfix nicht bekannt.
Das SSL-Zertifikat des GMX EMail Server ist mit dem von der „Deutsche Telekom Root CA 2“ signiert. War über eine Suche im Internet schnell gefunden. Die erste Zeile des Zertifikats ist in der Datei /etc/ssl/certs/ca-certificates.crt enthalten.

Die erste Zeile des Zertifikats der Telekom lautet.: MIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQGEwJERTEc

In meiner Suche konnte ich einfach feststellen das das CA-Zertifikat der Telekom ab der Zeile 1110 in der Datei ca-certificates.crt enthalten ist.:

Ich prüfe daher gegen welche CA Zertifikate mein Postix prüft ob das Zertifikat gültig ist:

Ich hatte versäumt meinem Postfix bekannt zu geben wo es die CA Zertifikate auf meinem Server findet.
Ich habe mit postconf den CAfile bekannt gegeben…

…und Postfix neu gestartet…

…und endlich werden meine EMails wieder ohne Fehlermeldung an den gmx Mailserever zugestellt.

 

howto – Shellshock auf der NAS

Leider ist auch die Bash-Shell der NAS CL-35B2 vom shellshock betroffen.

Hier meine Anleitung, wie die Bash auf der NAS durch eine neue, selbst compilierte ersetzt werden kann

1.) Bash auf Shelshock Verwundbarkeit testen

Sollte bei einem der Tests die Meldung „VULNERABLE“ erscheinen, sollte die „Bash“ mit dieser Anleitung aktualisiert werden.
Sollten alle Tests „not vulnerable“ ausgeben ist diese Anleitung nicht interessant für Sie.
Ein Mirror des Scriptes ist unter der URL http://dl.loteks.de/shellshock_test.sh zu finden.

1.) Build Umgebung erstellen

Leider enthält die NAS CL-35B2 keine installierte Build-Umgebung. Von den 195MB Speicherplatz sind nur noch ca 40 frei, der Speicherplatz auf der NAS ist einfach zu klein um GCC und make zu installieren.

Ich habe einen USB stick angeschlossen, der sich als /dev/sdc meldet. (herauszufinden via dmesg)
via cfdisk habe ich auf diesem USB Stick zwei Partitionen angelegt, zuerst eine ein Gigabyte Swap Partition und im Anschluss den Rest als Linux Partition.

Im Anschluss den swap Speicher Partitionieren und aktivieren:

Das Dateisystem auf /dev/sdc2 erstellen und Das Laufwerk Mounten:

Anschließend die RPM Pakete der Verwendeten Linux Distribution herunterladen. Bei der Fantec CL-35B2 ist es leider noch Fedora ARM 12, welches ein wenig betagt ist. Ich habe unter http://dl.loteks.de/fedora12arm_rpms.tar.gz (größe 119 MB) ein Paket mit den, für das Compilieren der Bash notwendigen rpm-Paketen abgelegt.

Nach dieser, sehr sehr lange dauernden Installation (dies dauert auf der NAS mehrere Stunden!) befindet sich die chroot umgebung im Order /mnt/chroot

2.) Bash Quellen bereitstellen

Jetzt brauchen wir die Bash Quellen und Patches in der chroot-Ubgebung:

Ab diesem Punkt liegen die Quellen der Bash gepatched im Verzeichnis /mnt/chroot/usr/src/bash-4.3. Das herunter geladene sstrip.c brauchen wir am ende um die Datei „bash“ auf ein der NAS angepasste Größe zu kürzen.
Jetzt können je nach Wunsch beliebige Compiler Flags gesetzt werden und die Configurationsoptionen gesetzt werden.

mit dem „strip bash“ werden alle, für die Ausführung der bash, nicht benötigten teile der elf-Datei entfernt. Die Datei wird von fast 1,5 MB auf unter 840KB reduziert.

3. bash Installieren

CVE-2014-6271 (original shellshock): not vulnerable
CVE-2014-6278 (Florian’s patch): not vulnerable
CVE-2014-7169 (taviso bug): not vulnerable
CVE-2014-//// (exploit 3 on https://shellshocker.net/ ): not vulnerable
CVE-2014-7186 (redir_stack bug): not vulnerable
CVE-2014-7187 (nested loops off by one): not vulnerable

Die Anleitung wurde vom mir zuletzt am 05.10.2014 getestet.
Sollten Irrtümer, Fehler oder Verbesserungen zum Artikel auffallen bitte ich dies mir mit einem Kommentar zu melden.

Besser wäre ein rpm-Paket, ich hoffe die Anleitung demnächst bezüglich rpm-Paket bau erweitern zu können.


Das aus diesem Tutorial entstehende Bash-Binary und RPM-Datei aus dem RPM-Tutorial zur Installation

MAC-Adresse ändern (Linux, Apple, Windows)

Die MAC-Adresse ist für jede Netzwerkschnitstelle einzigartig. Die MAC-Adresse zu ändern geht in den verschiedenen Systemen wie folgt:

Linux

Unter Linux kann die MAC-Adresse unkompliziert über das Terminal geändert werden.:

Mac OS

Wie unter Linux kann auch unter dem Apple MAC OS die Adresse über das Terminal geändert werden.
Der Aufruf sieht dort wie folgt aus:

oder alternativ

Windows 7

Unter Windows 7 muss die Mac Adresse über einen Registry Eintrag geändert werden.
Hier gilt es „regedit.exe“ zu starten und im Anschluß der Eintrag

Unter diese „key“ erscheint eine Nummern-Sequenz (000, 001, 002…), von welchem festgestellt werden muss welcher die Netzwerkkarte repräsentiert, in dem Feld  „DriverDesc“ steht der Name der Netzwerkkarte. (bei mit 007)

In diesem Key (bei mir 007) suche nach dem Schlüssel “NetworkAddress” und ändere diesen. Änderungen sind über doppelklick oder alternativ Rechtsklick + Ändern.
Gib die gewünschte MAC-Adresse als zusmmenhängende Zeichenfolge, ohne Leerzeichen, Punkte oder Minuszeichen ein.

Wenn der Schlüssel bei der Netzwerkkarte nicht vorhanden ist, Rechtsklick auf einen Freien Bereich und “Neu” – “Zeichenfolge” wählen. Gib als Name “NetworkAddress” und als Wert und als Daten die gewünschte MAC Adresse ein.

Anschleßend muss noch das Netzwerkinterface deaktiviert und in folge wieder aktiviert werden.

RETTET TrueCrypt…

Da TrueCrypt auf der offiziellen Internet Seite eine Anleitung zur Umstellung auf unsicherere Software, wie zum Beispiel „BitLocker“, gestellt hat und aus Archiven verschwindet hier ein Spiegel der letzten Aktuellen Version! Bewahrt es gut auf!

Ich hoffe es finden sich Entwickler die TrueCrypt weiterführen!!!

Die Checksummen der Dateien (Bitte mit den Dateien und Checksummen aus Drittquellen vergleichen!)
md5sum:

  • bb355096348383987447151eecd6dc0e truecrypt-7.1a-linux-x64.tar.gz
  • 09355fb2e43cf51697a15421816899be truecrypt-7.1a-linux-x86.tar.gz
  • 89affdc42966ae5739f673ba5fb4b7c5 truecrypt_7.1a_mac_os_x.dmg
  • 102d9652681db11c813610882332ae48 truecrypt-7.1a-source.tar.gz
  • 7a23ac83a0856c352025a6f7c9cc1526 truecrypt_setup_7.1a.exe

sha1sum:

  • 086cf24fad36c2c99a6ac32774833c74091acc4d truecrypt-7.1a-linux-x64.tar.gz
  • 0e77b220dbbc6f14101f3f913966f2c818b0f588 truecrypt-7.1a-linux-x86.tar.gz
  • 16e6d7675d63fba9bb75a9983397e3fb610459a1 truecrypt_7.1a_mac_os_x.dmg
  • d43e0dbe05c04e316447d87413c4f74c68f5de24 truecrypt-7.1a-source.tar.gz
  • 7689d038c76bd1df695d295c026961e50e4a62ea truecrypt_setup_7.1a.exe

STELLT AUCH IHR SPIEGEL DES QUELLCODES!

Multidomain Zertifikat erstellen

Mit openssl ist es wirklich einfach ein eigenes SSL Zertifikat und CSRs zu erstellen. Für Multi Domain Zertifikate muss jedoch auf konfigurations-Dateien zurückgegriffen werden.
Auch diese konfiguratios-Dateien sind nicht besonders kompliziert.

Eine Beispiel Konfigurationsdatei:

In diesem Beispiel werden als Domain „example.com“, „www.example.com“ und „www2.example.com“ validiert. Selbstverständlich könnten auch andere Domains angegeben sein.

Bei diesem Aufruf wird der Private Schlüssel key.pem und der CRS (Zertifikatsanfrage)csr.pem erstellt.

Diese Anleitung ist durch Lets Encrypt eigentlich überflüssig geworden. Um lokal genutzte Zertifikate und Testumgebungen zu unterstützen bleibt diese Anleitung erhalten.

Paranoid?

wget http://ftp.gnu.org/gnu/bash/bash-3.1.tar.gz
tar zxfv bash-3.1.tar.gz
cd bash-3.1
wget http://dl.loteks.de/bash-paranoia.patch
patch -p0 < bash-paranoia.patch
autoconf
./configure –enable-paranoia –prefix=/usr
make
make install

Security Report by ‚tiger‘

Um einen einfachen Security Report über den eigenen Server zu erhalten nutzt Ihr am besten den Tiger.
Tiger liefert einen Bericht über die aktuell vorhandenen Diskrepanzen in den Einstellungen des Systems.

Installation

Anwendung

sudo /usr/sbin/tiger
im Verzeichniss /var/log/tiger/ finden sich nach dem Durchlauf von ‚tiger‘ einen Logfile welcher nützliche Tipps zur Konfiguration gibt.