Wie man bei allen ausgehenden E-Mails dafür sorgt, dass die Client IP Adresse sowie der eingesetzte Mailclient vom Postfix verschleiert wird… Ja dieses habe ich bereits geschrieben. Postfix soll verschleiern…
Nun kann es dennoch Sinn ergeben dieses nicht für jede E-Mail zu tun, welche den Mailserver verlässt. Wenn man dieses nur auf E-Mails anwenden möchte, welche von angemeldeten Benutzern versendet werden, funktioniert es wie folgt.
Man erstellt in der master.cf vom Postfix einen neuen Service:
anonym unix n - - - 0 cleanup
-o header_checks=pcre:/usr/local/etc/postfix/header_cleanup
Nun sorgt man in der gleichen Konfigurationsdatei noch dafür, dass am Ende vom Submission und smtps Service in diesen neuen Service gesprungen wird:
submission inet n - n - - smtpd
[...]
-o cleanup_service_name=anonym
[...]
smtps inet n - n - - smtpd
[...]
-o cleanup_service_name=anonym
Der Inhalt unserer /usr/local/etc/postfix/header_cleanup ist dabei weiterhin gleich:
Die Zeit ging weiter, die Entwicklung bei BIND und DNS ebenfalls. Daher gibt es nun einen neuen Beitrag, der das aktuelle Setup mit BIND 9.20 auf FreeBSD 15 beschreibt – inklusive sauberer Trennung von authoritative DNS (Port 53) und öffentlichem Resolver (DoT/DoH) sowie reproduzierbaren CLI-Tests für IPv4 und IPv6. Bitte dort weiterlesen.
Die eigenen DNS Anfragen über eine Verschlüsselte Verbindung an einen DNS Server zu schicken welchem man vertraut, dieses liest sich schon gut oder? Keiner verfolgt mein Surfverhalten und zusammen mit DNSSEC schiebt mir so schnell keiner falsche Records unter.
Am ehesten vertraue ich meinem eigenen DNS Server (ns1.kernel-error.de). Auf diesem arbeitet ein Bind und vor diesen habe ich für DoT stunnel gestellt. Die Konfiguration vom stunnel sieht dabei grob wie folgt aus:
Auf einem Android 9 Gerät kann ich also nun unter den Einstellungen ==> Netzwerk & Internet ==> Erweitert ==> Privates DNS meinen Nameserver eintragen.
Jetzt sieht mir keiner mehr beim meinen DNS Abfragen zu.
SMTP überträgt E-Mails standardmäßig im Klartext. Mit STARTTLS lässt sich die Verbindung verschlüsseln, aber kein sendender Server ist gezwungen das auch zu tun. Schlimmer noch: Ein Angreifer im Netzwerk kann die STARTTLS-Antwort einfach unterdrücken und die Verbindung bleibt unverschlüsselt. MTA-STS (RFC 8461) löst dieses Problem: Der Empfänger veröffentlicht eine Policy, die sendenden Servern sagt „hier wird nur verschlüsselt zugestellt, mit gültigem Zertifikat, an genau diesen MX“.
MTA-STS vs. DANE
Es gibt zwei Wege, Transportverschlüsselung für E-Mail zu erzwingen: DANE und MTA-STS. DANE nutzt DNSSEC und TLSA-Records im DNS. Das ist technisch sauberer, setzt aber DNSSEC auf der Empfängerseite voraus. Viele große Provider (Google, Microsoft) haben kein DNSSEC. MTA-STS funktioniert ohne DNSSEC: Die Policy liegt als Textdatei auf einem Webserver, abgesichert durch ein normales TLS-Zertifikat. Wer beides kann, sollte beides einsetzen. DANE für die Server die DNSSEC können, MTA-STS für den Rest.
Die drei Komponenten
MTA-STS besteht aus drei Teilen: einem DNS-Record, einer Policy-Datei auf einem Webserver und optional TLS Reporting.
1. DNS TXT-Record
Ein TXT-Record unter _mta-sts.domain.de signalisiert, dass eine Policy existiert:
_mta-sts.kernel-error.de. IN TXT "v=STSv1;id=20260115130000Z;"
Die id ist ein beliebiger String. Sendende Server cachen die Policy und prüfen über die ID ob sich etwas geändert hat. Bei jeder Policy-Änderung muss die ID aktualisiert werden. Ich verwende dafür einen Zeitstempel, das macht es nachvollziehbar.
2. Policy-Datei
Die eigentliche Policy liegt unter https://mta-sts.domain.de/.well-known/mta-sts.txt. Wichtig: Der Webserver muss ein gültiges TLS-Zertifikat haben und unter genau diesem Hostnamen erreichbar sein.
enforce = nur verschlüsselt zustellen. testing = wie enforce, aber bei Fehlern trotzdem zustellen (gut zum Einstieg). none = Policy deaktiviert.
mx
An welche MX-Server zugestellt werden darf. Mehrere Einträge möglich (je eine Zeile). Wildcards gehen: *.kernel-error.de
max_age
Wie lange die Policy gecacht wird, in Sekunden. 2419200 = 28 Tage.
Der empfohlene Weg: Mit mode: testing anfangen und die TLS-Reports auswerten. Wenn alles sauber ist, auf enforce umstellen.
3. TLS Reporting
Wie bei DMARC gibt es auch für MTA-STS ein Reporting-System: SMTP TLS Reporting (RFC 8460). Ein weiterer DNS TXT-Record teilt Absendern mit, wohin sie Berichte über TLS-Verbindungsprobleme schicken sollen:
_smtp._tls.kernel-error.de. IN TXT "v=TLSRPTv1;rua=mailto:postmaster@kernel-error.de"
Die Reports kommen als JSON per Mail und enthalten Informationen über fehlgeschlagene TLS-Verbindungen, ungültige Zertifikate oder MX-Mismatches. Google und Microsoft schicken diese Reports zuverlässig.
Postfix und MTA-STS
Postfix prüft von Haus aus keine MTA-STS-Policies. Für die ausgehende Seite braucht es postfix-mta-sts-resolver, ein Policy-Daemon der sich als smtp_tls_policy_maps in Postfix einhängt. Der Daemon cached die Policies und liefert Postfix die passende TLS-Konfiguration pro Zieldomain.
Die eingehende Seite braucht keine Software. Die drei DNS-Records und die Policy-Datei auf dem Webserver reichen aus. Sendende Server wie Gmail, Outlook oder Yahoo werten die Policy selbständig aus.
Zusammen mit SPF, DKIM, DMARC und DANE ergibt MTA-STS eine lückenlose Absicherung: Authentifizierung (wer darf senden), Integrität (DKIM-Signatur) und Transportverschlüsselung (DANE/MTA-STS). Fragen? Einfach melden.
Etwas über ein Jahr betreibe ich nun bereits meinen eigenen Matrix Homeserver. Als Client dazu nutze ich Riot. Diesen Client gibt es für alle gängigen Geräte, egal ob Smartphone, Laptop oder Browser. Nun ist er in der Version 1.0 veröffentlicht worden.
Nachdem Frankreich nun die Idee verfolgt Matrix zu nutzen. Bin ich sehr gespannt welche Auswirkungen dieses auf Matrix und natürlich Riot haben wird. Wir setzten diese Konstellation schon länger als alternative zu anderen Messangern für Familie, Freunde und Bekannte ein. Der neue Client gefällt allen wirklich gut und er ist sogar noch etwas einfacher und angenehmer zu bedienen als sein Vorgänger. Schaut euch Matrix / Riot doch einfach mal an, ich bin erreichbar über: @kernel-error:kernel-error.com
Die netten Leute von Thomas Krenn haben uns ihr OpenPOWER-Testsystem zur Verfügung gestellt. Wir wollten dieses System schon länger in die Finger bekommen. Jetzt hat es endlich geklappt.
Die Hardware
Der Server zieht mit seinen zwei 1200-Watt-Netzteilen in der Spitze etwa 370 Watt (im Normalbetrieb um die 230 Watt) und soll laut Thomas Krenn 1.325 BTU/h produzieren. Verbaut sind 128 GB RAM und eine POWER8-CPU:
root@ubuntu:~# lscpu
Architecture: ppc64le
Byte Order: Little Endian
CPU(s): 64
Thread(s) per core: 8
Core(s) per socket: 8
Socket(s): 1
Model name: POWER8 (raw), altivec supported
CPU max MHz: 3857.0000
L1d cache: 64K
L1i cache: 32K
L2 cache: 512K
L3 cache: 8192K
64 Threads auf 8 Cores, SMT8. Das Betriebssystem war ein Ubuntu 16.04 LTS (ppc64le).
Storage-Anpassung
Die mitgelieferten Festplatten (3,5″ Nearline SAS mit 7,2k) waren für unseren Datenbanktest zu langsam. Also haben wir ein paar ältere 15k-SAS-Platten aus dem Lager verbaut und in ein RAID 10 geworfen. Damit war das lokale Storage laut pg_test_fsync vergleichbar mit unseren anderen Testsystemen. Wir wollten ja CPU-Leistung vergleichen, nicht Festplatten.
Alltagsvergleich
Als Erstes ein paar alltägliche Operationen im Vergleich mit Intel-Systemen:
CPU
SHA256 500 MB
bzip2 500 MB
AES 500 MB
2× Xeon E5-2665 @ 2.40 GHz
3,859 s
5,445 s
1,337 s
1× POWER8 @ 3.86 GHz
3,803 s
7,868 s
0,866 s
1× Core i7-6700 @ 3.40 GHz
2,370 s
4,207 s
0,831 s
2× Xeon E5-2650 v4 @ 2.20 GHz
2,652 s
5,413 s
1,585 s
2× Xeon E5-2650 v3 @ 2.30 GHz
2,484 s
5,217 s
1,500 s
AES-Verschlüsselung: POWER8 vorn. SHA256: gleichauf. bzip2: Intel deutlich schneller. Ein gemischtes Bild.
UnixBench
Das OpenPOWER-System gegen ein Dell-System mit zwei Intel Xeon E5-2665 (nur CPU/RAM relevant):
Benchmark
2× Xeon E5-2665
1× POWER8
Dhrystone 2
34.551.077 lps
27.167.564 lps
Double-Precision Whetstone
4.082 MWIPS
4.092 MWIPS
Execl Throughput
2.124 lps
2.776 lps
Pipe Throughput
2.067.851 lps
465.884 lps
Process Creation
4.278 lps
7.391 lps
Shell Scripts (1 concurrent)
5.543 lpm
7.085 lpm
Shell Scripts (8 concurrent)
6.090 lpm
4.357 lpm
System Call Overhead
4.186.840 lps
344.157 lps
Index Score
1.629,6
851,8
Process Creation und Shell Scripts (single): POWER8 vorn. System Calls und Pipe Throughput: Intel massiv besser. Der Index-Score geht klar an Intel, wobei der Vergleich nicht ganz fair ist (Dual-CPU gegen Single-CPU).
PostgreSQL-Restore
Die hohe Thread-Anzahl und die breite Speicheranbindung machen die POWER8 theoretisch zum guten Datenbankprozessor. Wir arbeiten viel mit PostgreSQL, also haben wir unsere Testdatenbank restored:
CPU
Restore-Zeit
2× Xeon E5-2650 v3 @ 2.30 GHz
129 min 34 s
1× POWER8 @ 3.86 GHz
120 min 43 s
Knapp 9 Minuten schneller als das Dual-Xeon-System. Bei Datenbank-Workloads macht sich die Speicheranbindung bemerkbar.
Fazit
Die POWER8 ist ohne Zweifel leistungsstark. Die Speicheranbindung und die 64 Threads merkt man bei Datenbank-Workloads. Im Single-CPU-Vergleich macht das System bei Datenbanken den Stich. Aber: Das OpenPOWER-System von Thomas Krenn gibt es nur mit einem CPU-Socket, preislich liegt es aber auf dem Niveau eines Dual-Xeon-Systems. In diesem Vergleich hat Intel die Nase vorn.
IBM hat die POWER8 2013 vorgestellt, unser Test war 2018. Die Vergleichssysteme waren ebenfalls nicht brandneu. Unterm Strich: Tolle CPU, aber im Preis-Leistungs-Verhältnis für einen Datenbankserver gegenüber Intel der Verlierer. Im HPC-Bereich oder bei der Anbindung von Nvidia-Beschleunigern sieht das sicher anders aus. Dual-CPU-Systeme oder direkt POWER9 (mit einem Hardware-GZIP-Accelerator und erweiterten Crypto-Instructions, AES gab es in POWER8 allerdings schon in Hardware) wären spannend gewesen. Da IBM von diesen CPUs im Vergleich zu Intel nur geringe Stückzahlen verkauft, bleibt der Preis hoch.
Update 2026: was sich seitdem getan hat
Der Test ist von 2018, die Server-Landschaft hat sich seitdem gedreht. IBM hat 2021 die POWER10 vorgestellt (Power E1080, S1014, S1022), inklusive Matrix Math Assist Instructions für AI-Inferenz. Die OpenPOWER-Foundation ist seit 2019 unter dem Dach der Linux Foundation, und für Workstations jenseits der reinen IBM-Welt ist RaptorCS mit den Talos-II-Boards (POWER9) die Community-Anlaufstelle geblieben. ppc64le-Linux lebt ebenfalls, Debian, Fedora, NixOS und diverse andere Distributionen pflegen die Architektur weiter.
Die größere Veränderung kommt allerdings aus der Konkurrenz. AMD EPYC (Genoa, Turin) dominiert heute im x86-Server-Bereich, Intel hat mit Sapphire Rapids und Granite Rapids nachgezogen, und vor allem ARM ist im Rechenzentrum angekommen: Ampere Altra und AmpereOne, AWS Graviton in der dritten und vierten Generation, NVIDIA Grace für HPC und AI. Die Nische für POWER liegt damit 2026 eher bei AIX-Legacy, HPC mit NVLink-Integration und bei Projekten, denen Architektur-Unabhängigkeit wichtig ist. Für den klassischen Datenbank- oder Webserver-Einsatz ist ppc64le ein Exot geworden.
Wer FreeBSD auf anderer Hardware ausprobieren will: FreeBSD auf dem Desktop beschreibt die Grundinstallation mit MATE. Und mit bhyve und vm-bhyve lassen sich Windows-VMs auf FreeBSD betreiben.
FreeBSD bringt seit Version 10.0 einen eigenen Typ-2-Hypervisor mit: bhyve. Für den täglichen Umgang empfiehlt sich vm-bhyve als Verwaltungstool, damit lässt sich eine Windows-VM in wenigen Minuten einrichten, ohne sich mit den bhyve-Basistools herumschlagen zu müssen.
vm-bhyve installieren und einrichten
# Installation
pkg install vm-bhyve grub2-bhyve uefi-edk2-bhyve
# ZFS-Dataset für VMs anlegen
zfs create pool/vm
# Autostart aktivieren
sysrc vm_enable="YES"
sysrc vm_dir="zfs:pool/vm"
# Initialisieren und Templates kopieren
vm init
cp /usr/local/share/examples/vm-bhyve/* /pool/vm/.templates/
# Netzwerk-Switch erstellen und physisches Interface anhängen
vm switch create public
vm switch add public em0
Windows-VM erstellen
ISO-Dateien importieren, die Windows-ISO und die virtio-Treiber für die Netzwerkkarte:
# Windows-ISO importieren
vm iso /home/kernel/Download/win10.iso
# virtio-net Treiber (für die Netzwerkkarte in der VM)
fetch https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso
vm iso /home/kernel/Download/virtio-win.iso
VM aus dem mitgelieferten Windows-Template erstellen:
vm create -t windows -s 200G win10
VM-Konfiguration anpassen
Das Windows-Template kommt mit 2 CPUs und 2 GB RAM. Für eine brauchbare Windows-VM besser anpassen:
Die wichtigsten Optionen: graphics="yes" aktiviert einen VNC-Server für die Grafikausgabe, xhci_mouse="yes" sorgt für eine brauchbare Maus in der VM, network0_type="virtio-net" nutzt den schnelleren paravirtualisierten Netzwerktreiber statt einer emulierten Karte.
Installation und Zugriff
# VM starten und ISO einlegen
vm install win10 win10.iso
Dann mit einem VNC-Viewer auf 127.0.0.1:5999 verbinden und Windows installieren. Nach der Installation die virtio-Treiber-ISO einlegen (vm install win10 virtio-win.iso) und Windows die Netzwerktreiber dort suchen lassen.
Für den täglichen Zugriff RDP in der VM aktivieren, dann braucht man den VNC-Viewer nur noch für die Ersteinrichtung.
VM verwalten
# Laufende VMs anzeigen
vm list
NAME DATASTORE LOADER CPU MEMORY VNC AUTOSTART STATE
win10 default uefi 4 8G , No Running (10638)
# VM stoppen / starten
vm stop win10
vm start win10
# Snapshot erstellen (ZFS-Snapshot der VM-Disk)
vm snapshot win10
Das Internet funktioniert nicht, wie euer normales Netzwerk zuhause. Es basiert in den weitesten Teilen auf BGP, dem Border Gateway Protocol. Natürlich kann es auch dabei zu Problemen kommen, mal macht ein Mensch einen Fehler, mal Hardware oder Software oder eine Regierung möchte etwas „blockieren“… Naja, oder die bösen Hacker halt.
Unter folgendem Link, werden BGP Probleme visualisiert und mit einer Historie versehen:
Klickt unbedingt auch mal auf „More detail“ bei einem Event und schaut euch das Replay an, das ist nicht nur interessant, sondern auch lehrreich. Viel besser zu verstehen, als wenn man nur die BGP Events im Log fliegen sieht!
Ich habe gerade eben meinen Openfire abgeschaltet und werde ihn nicht mehr einschalten. Jabber / XMPP war eine wirklich schöne Möglichkeit der Kommunikation. Der Aufwand SPAM zu filtern und das Teil selbst zu betreiben steht aber inzwischen einfach in keinem Verhältnis mehr. Zudem hat sich Jabber nur minimal weiterentwickelt. Inzwischen ist es von vielen schönen Lösungen überholt worden.
Meine Kommunikation läuft inzwischen mehr über Matrix/Riot oder Slack Chat als über Jabber.
Racktables ist zur Dokumentation seiner Assets im Rack nicht das schlechteste Tool. Es hat ganz klar seine Grenzen aber oft erfüllt es die Anforderungen.
Wie füge ich in Racktables einen Load Balancer hinzu? Vor dieser Frage stand ich vor einiger Zeit. Mein erster Anlaufpunkt war natürlich das Racktables Wiki. Leider wurde ich daraus nicht wirklich schlauer. Die google Suche: „How to add LoadBalancers to racktables“ hat mir ebenfalls nicht geholfen. Irgendwann bin ich auf den Hinweis zur User Interfaceconfiguration „IPV4LB_LISTSRC“ gestoßen. Ab da öffneten sich meine Augen.
Die Option ist im default mit einem false deaktiviert. Aktiviert man sie mit einem einfachen true, tauchen einfach alle Hardwareserver als Load Balancer unter IP SLB ==> Load balancers auf. Das ist fast gut. Fast… ja fast weil dort eigentlich nur die Load-Balancer auftauchen sollten. Da kam mir die Funktion der Tags in den Sinn. Nach diesen lässt sich bei Racktables nicht nur filtern, sondern man kann darauf aufbauend auch Dinge im Interface umorganisieren. Einfachstes Beispiel ist sicher der Tag „Poweroff“, welcher ausgeschaltete Systeme in der Rackübersicht andersfarbig darstellt, wenn man dem Tag eine andere Farbe zugewiesen hat.
Genau so bekommt man nun ebenfalls die Load balancers ins IP SLB von Racktables. Als erstes legt man also einen Tag an, der jedem Load balancer zugewiesen wird: Configuration ==> Tag tree ==> Edit tree
Nun weißt man dieses Tag dem jeweiligen Load Balancer Object zu.
Nun geht es weiter unter Configuration ==> User Interface ==> Change
Dort muss die Option IPV4LB_LISTSRC so geändert werden, dass unser neues Tag in geschweiften Klammern steht. In meinem Beispiel ist es das Tag LoadBalancer und dieses findet sich wie folgt in der Konfiguration:
Das war es auch schon. Ab jetzt wird jedes Object unter Racktables ==> IP SLB ==> Load balancers auftauchen, welches das Tag LoadBalancer bekommen hat.
Wenn man es einmal verstanden hat, ganz einfach oder? Viel Spaß.
