IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Autor: Sebastian van de Meer (Seite 10 von 46)

Bosch Geschirrspülmaschine: Fehler E-21 beheben

Ursache

Meine Geschirrspülmaschine hat mir heute einige Nerven gekostet. Mit einem fröhlichen E-21 im Display war Schluss mit Spülen. Der Fehlercode deutet darauf hin, dass etwas mit der Umwälzpumpe nicht stimmt. Die Maschine ist knapp sechs Jahre alt und läuft hier täglich für einen Vier-Personen-Haushalt — sie hat selten Langeweile. Die Maschine ist baugleich zu Siemens, Neff und Constructa.

Mein erster Schritt war ein Anruf beim nächstgelegenen Serviceanbieter. Dieser sagte mir, dass er die Maschine in einer Woche abholen und bei sich überprüfen könnte. In der Regel wird dann die Umwälzpumpe ausgetauscht, und ich bekäme die Maschine nach zwei bis drei Tagen zurück. Für 200–300 € mehr könnte er mir aber direkt eine neue Maschine liefern und die alte entsorgen. Bei einer so alten Maschine… Warum werden heutzutage nur noch Teile ausgetauscht? Warum soll immer alles neu sein? Warum repariert niemand mehr?

Reparatur

Eine kurze Suche brachte mir eine Explosionszeichnung meiner Spülmaschine. Die Konstruktion sieht sehr überschaubar aus. Letztlich fand ich in der Umwälzpumpe ein Stück Plastikverpackung. Die Pumpe ließ sich fast vollständig zerlegen und reinigen. Jetzt läuft die Maschine wieder, ganz ohne Fehler — insgesamt 40 Minuten Arbeit.

Nachtrag: Pumpe doch kaputt

Einige Monate später hat die Pumpe dann doch aufgegeben. Anscheinend hat das Plastikteil eine Unwucht verursacht, die zum endgültigen Ausfall geführt hat. Falls die Pumpe tatsächlich defekt ist, lässt sich das Ersatzteil über Amazon bestellen. Der Austausch ist einfach, und alles Notwendige ist dabei.

Die gleiche Maschine hatte später auch den Fehler E-15 — eine verzogene Dichtung am Pumpentopf. Fragen? Einfach melden.

Dell Latitude E6540 mit Intel Wireless-AC 9260

Mein privates Notebook ist noch immer ein Dell Latitude E6540. Die ab Werk verbaute Intel Centrino Ultimate-N 6300 macht zwar noch immer ihren Job, inzwischen stört mich immer öfter ihr Durchsatz. Maximal soll sie 450 Mbps bringen, dieses schafft sie natürlich nur unter guten Bedingungen. Früher ist mir dieses nicht besonders aufgefallen, durch bessere WLAN APs und schnelleres Internet bremst mich inzwischen meine verbaute WLAN Karte beim Download :-/ das ist doof!

Also einfach neue Karte kaufen, ins Notebook stecken und los gehts.. Naja, fast! Im Latitude können drei PCIe Half MiniCard verbaut werden. Aktuelle WLAN Karten für Notebooks nutzen inzwischen aber M.2 als Schnittstelle zum Notebook. Ebenfalls sind die Anschlüsse der Antennen „kleiner“ geworden. Intel bietet für ihre Produkte auf ihrer Webseite die Option an ihre Produkte miteinander zu vergleichen. >klick<

Um M.2 komme ich nicht herum, wenn ich es mit einem möglichst einfachen Adapter anschließen möchte muss ich darauf achten, dass die neue Karte PCIe spricht. Die Intel Wireless-AC 9260 kann dieses und bietet dazu noch 1,73Gbps. Dazu noch ein Adapter und zwei Antennenadapter. Alles bekommt man schnell für einen kleinen Euro auf Amazon.

Intel Wireless-AC 9260
Adapter
Antennenadapter

Alles zusammen sitzt nun in meinem Notebook und das Internet „fliegt“ wieder.

Siehe auch: Lifebook E7110 unter Linux

Fragen? Einfach melden.

Draft zu Security Policies

Es gibt seit einiger Zeit einen Draft zu Security Policies. Schaut mal hier: https://tools.ietf.org/html/draft-foudil-securitytxt-07 über diesen Weg kann man für seine Domain eine Security Policie veröffentlichen. Dieses inkl. Kontaktdaten einer „Dankeschön“ Seite usw…

Die Idee ist es eine einheitliche Möglichkeit zu schaffen um freundlichen Findern von Sicherheitslücken/Problemen eine einfache und „sichere“ Anlaufstelle zu geben. Wer schon mal ein Löchlein gefunden hat, kennt das Problem. Man sucht eine Kontaktmöglichkeit, scheitert an der Human Firewall oder am technischen Verständnis von seinem Gegenüber. Gibt es es bug bounty oder wird der Informierte ~nervös~?!? Ist die Webseite vielleicht schon kompromitiert und der Hinweis wandert direkt an den Bösewicht? usw. usw. usw…

Diese Probleme soll dieser RFC möglichst einfach erschlagen. Es gibt ein textfile mit dem Namen security.txt unter der jeweiligen Domain im Pfad .well-known, diese ist nach Möglichkeit noch gpg cleartext signiert und beinhaltet alle nötigen Informationen.

Als kleine Beispiel: https://www.kernel-error.de/.well-known/security.txt

Es gibt sogar noch ein kleines Tool zum kreieren des Textfiles: https://securitytxt.org/

Da ich selbst sehr oft vor dem Problem stehe eine saubere Kontaktadresse zu finden, begrüße ich diesen RFC natürlich sehr!

Viel Spaß!

Fragen? Einfach melden.

Bluetooth-Audio unter FreeBSD und GhostBSD: Workaround mit Creative BT-W2

Bluetooth-Audio und FreeBSD vertragen sich nicht. Der Bluetooth-Stack wird nicht mehr gepflegt, in OpenBSD wurde er komplett entfernt. Einen Bluetooth-Dongle oder eine eingebaute Bluetooth-Karte dazu zu bringen, sich mit einem Audio-Gerät zu verbinden, funktioniert unter FreeBSD praktisch nicht.

Der Workaround: Creative BT-W2

Die Lösung ist ein USB-Dongle, der sich selbst um Bluetooth kümmert: Der Creative BT-W2. Das Gerät meldet sich am Betriebssystem als normale USB-Soundkarte. Das Pairing mit dem Bluetooth-Kopfhörer oder -Lautsprecher macht der Dongle selbständig per Knopfdruck. FreeBSD sieht nur eine Soundkarte, kein Bluetooth.

Das Kernelmodul snd_uaudio kümmert sich um die Erkennung. In der /etc/rc.conf:

kld_list="snd_uaudio"

Nach dem Laden des Moduls erscheint das Gerät im dmesg:

uaudio0:  on usbus0
uaudio0: Play: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 48000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
pcm5:  on uaudio0
uaudio0: HID volume keys found.

Pairing und Nutzung

Kurz den Knopf am Dongle drücken, er blinkt und verbindet sich mit dem nächsten Bluetooth-Audio-Gerät in Reichweite. Kopfhörer, Headsets, Lautsprecher und Mikrofone funktionieren. Die Qualität reicht auch für Telefonie, Latenz und Codec sind in Ordnung.

Das Audio-Device ist je nach Systemkonfiguration /dev/dsp5 oder ein anderer Index. Mit cat /dev/sndstat lässt sich prüfen welches Device der BT-W2 bekommen hat.

Nicht die eleganteste Lösung, aber sie funktioniert zuverlässig. Solange der Bluetooth-Stack auf FreeBSD nicht wiederbelebt wird, ist ein Dongle wie der BT-W2 der pragmatischste Weg.

Siehe auch: FreeBSD auf dem Desktop, GhostBSD und FreeBSD: GNOME-Keyring automatisch entsperren, GhostBSD 19.09 Ports benutzen

Fragen? Einfach melden.

Dominos´s Goldcard

Es gibt Momente im Leben eines Sysadmins, in denen man kurz innehalten und sich fragen sollte, ob alles noch so läuft wie geplant. Einer dieser Momente war, als mir der Typ an der Domino’s Theke eine Goldcard in die Hand drückte.

Nachtschichten und Pizza

Wer regelmäßig Nachtschichten im Serverraum schiebt, kennt das Dilemma. Es ist 23 Uhr, der Storage-Umbau läuft, die Migration zieht sich und der letzte vernünftige Bissen war irgendwann mittags. Döner hat zu, der Kühlschrank im Büro gibt maximal eine traurige Käsescheibe her. Aber Domino’s liefert. Immer. Egal ob Mitternacht oder drei Uhr morgens.

Irgendwann kennen die einen. Erst am Telefon („Ach, Sie schon wieder, das Übliche?“), dann an der Theke. Man wird Stammkunde, nicht weil man Domino’s so wahnsinnig toll findet, sondern weil die halt offen haben wenn sonst niemand mehr offen hat. Pragmatismus schlägt Kulinarik, vor allem um zwei Uhr nachts mit einer Hand am Terminal.

Die Goldcard

Jedenfalls drückte mir eines Abends der Filialleiter kommentarlos eine goldene Plastikkarte in die Hand. Domino’s Goldcard. Heißt im Klartext: Ab sofort gibt es auf jede Bestellung Rabatt. Weil man so oft da war. Weil man so viel bestellt hat. Weil man offenbar zu den besten Kunden der Filiale gehört.

Dominos Goldcard, Stammkunde durch Nachtschichten im Serverraum

Da steht man dann mit seiner Goldcard und fragt sich: Ist das jetzt eine Auszeichnung oder eher ein Hilferuf? Wahrscheinlich beides. Aber immerhin, die Server liefen am nächsten Morgen und die Pizza war warm. Prioritäten.

Falls du auch regelmäßig dein Rechenzentrum mit Pizza am Laufen hälst und Fragen hast, kannst du mich gerne fragen. Zur Pizza kann ich leider nicht mehr viel sagen, die Filiale hat inzwischen zugemacht. Wahrscheinlich nachdem ich weggezogen bin.

Outlook Autodiscover für IMAP und SMTP konfigurieren

Vor einigen Jahren habe ich bereits etwas zu Microsoft Office Outlook Autodiscover geschrieben. Ich setze es noch immer in ähnlicher Form ein. Hier der aktuelle Stand.

Nginx-Konfiguration

Hinter autodiscover.kernel-error.de steht ein Nginx, der unter /Autodiscover/Autodiscover.xml die Konfiguration für verschiedene Maildomains ausliefert. Die Location ist überschaubar:

location ~ /(?:a|A)utodiscover/(?:a|A)utodiscover.xml {
    root /usr/local/www/autodiscover.kernel-error.de;
    try_files /autodiscover/autodiscover.php =404;
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_pass unix:/var/run/php-fpm.sock;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $request_filename;
    include fastcgi_params;
    fastcgi_cache MYAPP;
    fastcgi_cache_valid 200 60m;
}

Das PHP-Script

Jede Anfrage nach /autodiscover/autodiscover.xml wird an autodiscover.php weitergeleitet. Das Script liest die im POST übermittelte E-Mail-Adresse, prüft sie und liefert die XML-Antwort mit IMAP- und SMTP-Einstellungen zurück:

<?php
// Autodiscover responder — responds to POST on /autodiscover/autodiscover.xml

$request = file_get_contents("php://input");
preg_match( "/\<EMailAddress\>(.*?)\<\/EMailAddress\>/", $request, $email );

if (filter_var($email[1], FILTER_VALIDATE_EMAIL) === false) {
	throw new Exception('Invalid E-Mail provided');
}

// IMAP settings
$imapServer = 'imap.kernel-error.de';
$imapPort   = 993;
$imapSSL    = true;

// SMTP settings
$smtpServer = 'smtp.kernel-error.de';
$smtpPort   = 465;
$smtpSSL    = true;

header( 'Content-Type: application/xml' );
?>
<?php echo '<?xml version="1.0" encoding="utf-8" ?>'; ?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
  <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
    <Account>
      <AccountType>email</AccountType>
      <Action>settings</Action>
      <Protocol>
        <Type>IMAP</Type>
        <Server><?php echo $imapServer; ?></Server>
        <Port><?php echo $imapPort; ?></Port>
        <LoginName><?php echo $email[1]; ?></LoginName>
        <SPA>off</SPA>
        <SSL><?php echo $imapSSL ? 'on' : 'off'; ?></SSL>
        <AuthRequired>on</AuthRequired>
      </Protocol>
      <Protocol>
        <Type>SMTP</Type>
        <Server><?php echo $smtpServer; ?></Server>
        <Port><?php echo $smtpPort; ?></Port>
        <LoginName><?php echo $email[1]; ?></LoginName>
        <SPA>off</SPA>
        <SSL><?php echo $smtpSSL ? 'on' : 'off'; ?></SSL>
        <AuthRequired>on</AuthRequired>
        <SMTPLast>off</SMTPLast>
        <UsePOPAuth>off</UsePOPAuth>
      </Protocol>
    </Account>
  </Response>
</Autodiscover>

Wichtig im SMTP-Block

Drei Zeilen machen den Unterschied:

<AuthRequired>on</AuthRequired>
<SMTPLast>off</SMTPLast>
<UsePOPAuth>off</UsePOPAuth>

Ohne diese Einträge muss man im Outlook manuell den Haken setzen bei „Gleiche Einstellungen wie für den Posteingangsserver verwenden“. Das überfordert erstaunlich viele Anwender.

Mehrere Domains per SRV-Record

Damit Autodiscover nicht nur für kernel-error.de funktioniert, gibt es in den anderen DNS-Zonen SRV-Records, die auf die zentrale Autodiscover-Domain verweisen:

$ dig _autodiscover._tcp.kernel-error.com IN SRV +short
0 0 443 autodiscover.kernel-error.de.

Outlook zeigt beim ersten Mal eine Warnmeldung, ob man dem Verweis folgen möchte:

Screenshot vom Outlook Client beim Konto hinzufügen. Frage ob die Konfiguration der Servereinstellungen von einer Webseite zugelassen werden soll.

Einmal bestätigt, ist die Konfiguration abgeschlossen. Man könnte die Meldung auch per Registry-Key unterdrücken, aber für die meisten Benutzer reicht ein Klick.

Screenshot vom Outlook Client beim Konto hinzufügen. Vorgang wurde erfolgreich abgeschlossen.

Update März 2026: Aufgeräumt und abgesichert

Das Grundprinzip funktioniert seit 2019 unverändert. Outlook bekommt per POST seine Konfiguration, der Benutzer muss nur E-Mail-Adresse und Passwort eingeben. Ein paar Dinge habe ich aber überarbeitet.

PHP-Script: GET-Requests und fehlende Eingaben abfangen

Das alte Script hat bei GET-Requests oder einem leeren POST-Body mit HTTP 500 geantwortet. Es versuchte auf eine Variable zuzugreifen, die bei fehlendem XML-Body nicht existiert. Monitoring-Tools und neugierige Browser liefen damit gegen die Wand.

Die korrigierte Version prüft jetzt sauber:

<?php
// Nur POST erlauben
if ($_SERVER["REQUEST_METHOD"] !== "POST") {
    header("HTTP/1.1 405 Method Not Allowed");
    header("Allow: POST");
    exit;
}

$request = file_get_contents("php://input");
preg_match("/\<EMailAddress\>(.*?)\<\/EMailAddress\>/", $request, $email);

if (empty($email[1]) || filter_var($email[1], FILTER_VALIDATE_EMAIL) === false) {
    header("HTTP/1.1 400 Bad Request");
    exit;
}

// XSS-Schutz: E-Mail fuer XML-Ausgabe escapen
$loginName = htmlspecialchars($email[1], ENT_XML1, "UTF-8");

GET liefert jetzt 405, ein POST ohne gültigen Body gibt 400. Die E-Mail-Adresse wird zusätzlich mit htmlspecialchars() escaped, bevor sie in die XML-Antwort geschrieben wird.

Nginx: Kein Cache für dynamische Antworten

In der ursprünglichen Konfiguration steckt fastcgi_cache MYAPP mit 60 Minuten Gültigkeit. Das ist für Autodiscover falsch. Die Antwort enthält die E-Mail-Adresse des anfragenden Benutzers als <LoginName>. Mit Cache bekommt der zweite Benutzer die Adresse des ersten. Ohne Cache:

location ~* ^/autodiscover/autodiscover\.xml$ {
    try_files /autodiscover/autodiscover.php =404;
    fastcgi_pass  unix:/var/run/php-fpm.sock;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root/autodiscover/autodiscover.php;
    include       fastcgi_params;
}

Das ~* macht den Match case-insensitive, kürzer als die alte Regex mit (?:a|A).

Thunderbird Autoconfig auf dem gleichen Host

Inzwischen bedient autodiscover.kernel-error.de nicht mehr nur Outlook, sondern auch Thunderbird per Autoconfig. Dazu reicht eine zusätzliche Location im gleichen Server-Block:

location /mail/ {
    alias /usr/local/www/autoconfig-mail/mail/;
}

Thunderbird fragt https://autoconfig.<domain>/mail/config-v1.1.xml. Für jede Maildomain gibt es einen autoconfig.* CNAME und einen eigenen HTTPS-Server-Block. Outlook nutzt weiterhin den POST-Endpoint, Thunderbird die statische XML.

Siehe auch: Thunderbird Autoconfig

Fragen? Einfach melden.

Postfix: Verschleierung nur für SASL-Benutzer einrichten

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:

/^(Received: from)[^\n]*(.*)/ REPLACE $1 ::88 (YOUR MOM [::88])$2
/^X-Originating-IP/ IGNORE
/^User-Agent*(.*)/ REPLACE User-Agent: YOUR MOMS MAILER
/^X-Mailer*(.*)/ REPLACE X-Mailer: YOUR MOMS MAILER

Nach einem Restart vom Postifx hat man nun den gewünschten Zustand. Natürlich dürfen nun die smtp_header_checks nicht mehr in der main.cf sein:

#smtp_header_checks = pcre:/usr/local/etc/postfix/header_cleanup

Viel Spaß

Fragen? Einfach melden.

FreeBSD OpenSSH: OS-Banner sicher entfernen

Im Standard ist der OpenSSH Server auf einem FreeBSD so konfiguriert, dass er jeweils die aktuelle Betriebssystemversion mit ausliefert.

Dieses sieht dann im Beispiel so aus:

telnet bsd01.testsystem 22
Trying 1.2.3.4...
Connected to bsd01.testsystem.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.8 FreeBSD-20180909

Um hier zumindest die genaue OS Version zu verstecken reicht folgendes in der /etc/sshd_config:

#VersionAddendum FreeBSD-20180909
VersionAddendum DemMeisterSeinRennAuto

Testet man nun noch mal sieht man nur noch die Version:

telnet bsd01.testsystem 22
Trying 1.2.3.4...
Connected to bsd01.testsystem.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.8 DemMeisterSeinRennAuto

Auf einem Debian basierten System wäre es hingegen:

DebianBanner no

Siehe auch: SSH-Server absichern

Fragen? Einfach melden.

GhostBSD 19.09 Ports benutzen

Veraltet: GhostBSD 19.09 ist stark veraltet. Aktuelle GhostBSD-Versionen nutzen pkg statt Ports. Siehe ghostbsd.org für die aktuelle Version.

GhostBSD basierte früher direkt auf FreeBSD. Inzwischen ist es aber auf TrueOS gewechselt. So sieht es ebenfalls mit den Ports aus. Man kann also nicht wie unter FreeBSD gewohnt mit portsnap arbeiten sondern muss einen gewissen „Umweg“ nehmen.

Die zu GhostBSD gehörenden Ports bekommt man nun so ins System:

sudo git clone https://github.com/ghostbsd/ghostbsd-ports.git /usr/ports

In GhostBSD Version 19.09 ist etwas Ordnung geschaffen worden und viele vermeintlich unnötige Pakete mussten weichen. Zum arbeiten mit den Ports benötigt man daher noch folgendes:

pkg install src os-generic-userland-devtools

Ab jetzt kann man wie gewohnt mit den Ports arbeiten!

Siehe auch: GhostBSD und FreeBSD: GNOME-Keyring automatisch entsperren, Bluetooth-Audio unter FreeBSD und GhostBSD: Workaround mit Creative BT-W2

Fragen? Einfach melden.

GhostBSD und FreeBSD: GNOME-Keyring automatisch entsperren

Ich nutze auf meinen Desktops GhostBSD und FreeBSD Systeme zusammen mit Mate und LightDM. Ebenfalls verwende ich für ein paar Kleinigkeiten den gnome-keyring. Dabei „stört“ es mich diesen nach der Anmeldung am Desktop gesondert entsperren zu müssen. Es gibt aber eine Möglichkeit dieses von pam nach der Anmeldung automatisch entsperren zu lassen. Dafür müssen nur folgende Zeilen in der /usr/local/etc/pam.d/lightdm ergänzt werden:
auth        optional    pam_gnome_keyring.so
session        optional        pam_gnome_keyring.so    auto_start

Meine sieht nun also wie folgt aus:

#
# PAM configuration for the "lightdm" service
#

# auth
auth		sufficient	pam_self.so		no_warn
auth		include		system
auth		optional	pam_gnome_keyring.so

# account
account		requisite	pam_securetty.so
account		required	pam_nologin.so
account		include		system

# session
session		include		system
session		optional	pam_gnome_keyring.so	auto_start

# password
password	include		system

Nach dem nächsten Login habe ich nun die Möglichkeit, beim Entsperren des Keyrings, einen Haken zu setzten und schon wird bei jedem Login mein Keyring automatisch geöffnet.

Siehe auch: FreeBSD Desktop mit MATE, GhostBSD 19.09 Ports benutzen, Bluetooth-Audio unter FreeBSD und GhostBSD: Workaround mit Creative BT-W2

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑