postfix „cannot find your hostname“ und „transport smtp failure“

Ich habe meinen Root-Server umgezogen von Debian 8 auf Arch Linux. Bei postfix (aktuell in der Version 3.1.3 hatte ich zwei Phänomene.

Reverse Lookup schlägt fehl mit „cannot find your hostname“

Unschöne Logmeldungen tauchten auf:

Dez 20 22:35:04 mineralwasser postfix/smtpd[31080]: Anonymous TLS connection established from unknown[2607:f8b0:4001:c06::245]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Dez 20 22:35:04 mineralwasser postfix/smtpd[31080]: NOQUEUE: reject: RCPT from unknown[2607:f8b0:4001:c06::245]: 450 4.7.25 Client host rejected: cannot find your hostname, [2607:f8b0:4001:c06::245]; from=<3HENWWAcLBcMwx0nyu77x323kn.lxvqnuux4nuxlA27.mn@youtube-subscriptio
Dez 20 22:35:05 mineralwasser postfix/smtpd[31080]: disconnect from unknown[2607:f8b0:4001:c06::245] ehlo=2 starttls=1 mail=1 rcpt=0/1 data=0/1 quit=1 commands=5/7

Mein Postfix ist so konfiguriert, dass der Reverse DNS Eintrag zum angegebenen HELO Hostname passen muss. Ist das nicht der Fall, dann wir die E-Mail nicht angenommen. Diese Maßnahme filtert viele spamversendende E-Mail Server weg. Diese Regel wollte ich also nur ungern deaktivieren.
Eine manuelle Rückwärtsauflösung funktioniert jedoch einwandfrei. Es handelt sich also nicht um ein DNS Problem. Als nächstes hatte ich systemd-resolved in Verdacht. Da dieser Service aber nicht aktiviert ist musste es doch an postfix liegen.
Den entscheidenden Hinweis gab folgende Logmeldung:

/etc/postfix/master.cf: line 47: using backwards-compatible default setting chroot=y

Read More „postfix „cannot find your hostname“ und „transport smtp failure““

Tor: Shutdown meines Exit Relays

Vor zwei bis drei Wochen habe ich mein Tor Exit Relay heruntergefahren. Der Grund hierfür ist der Umgang der Tor „Community“ über die Vorwürfe gegen ioerror. Viele Threads gingen auf den Mailing Lists auf und alle spekulierten wild rum. Niemand lieferte Beweise und viele Opfer versteckten sich in der Anonymität.
Das Verhalten der sogenannten Community hat mich zutiefst bestürzt. Danach habe ich beschlossen mein Relay abzuschalten und das Projekt nicht weiter zu unterstützen.

Der Daemon ist deinstalliert und die Keys wurde sicher gelöscht. Ich habe mich von allen Mailinglisten abgemeldet. Die negativen Seiten von Tor überwiegen damit für mich.

Icinga 2: Hoher inode Verbrauch unter /var/spool/icinga2/perfdata

Nur ein kurzer Blogeintrag, weil man da Thema nicht wirklich unnötig lange ausformulieren muss. Mein Icinga 2 hat mich darauf hingewiesen, dass mein Master Server einen hohen inode Verbrauch hat. Dank Stackexchange habe ich einen Einzeiler erhalten, der mir den inode Verbrauch in Ordnern aufsummiert und sortiert:

:~$ find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n

Die Ausgabe in meinem Fall war:

   1122 /usr/share/man/man1
   2360 /usr/share/man/man3
   3150 /var/lib/dpkg/info
  30497 /var/lib/grafana/png
 896245 /var/spool/icinga2/perfdata

Im Ordner unter /var/spool/icinga2/perfdata waren knapp 900.000 Dateien. In diesen stehen die Performance Werte von ausgeführten Checks drinnen. Verursacht werden diese Anhäufung durch das Icinga 2 Feature perfdata.
Ich hatte das damals aktiviert, weil ich dachte, dass ich nur so Performance Daten weitergeben kann. Dies ist aber nicht der Fall. Deaktivieren kann man es einfach via:

:~$ icinga2 feature disable perfdata
:~$ systemctl reload icinga2.service

Die bereits gespeicherten Daten kann man gefahrlos entfernen. Entweder man löscht alle Dateien einzeln mit

:~$ find /var/spool/icinga2/perfdata -type f -delete

oder gleich den gesamten Ordner:

:~$ rm -rf /var/spool/icinga2/perfdata

 

Icinga2 Notifications via Pushover.net

Vor einiger Zeit habe ich in einem Artikel geschrieben, wie man den Notify My Android Dienst für Icinga 2 Notifications einbindet. Leider ist dieser hin und wieder für mehrere Tage offline. Deshalb bin ich zu einem größeren Anbieter gewechselt. Pushover.net bietet die selbe Funktionalität und war bei mir bis jetzt ohne Ausfall erreichbar.

Script anpassen

Pushover hat viele Integrationsbeispiele des API Aufrufes auf deren Homepage. Ich benutze das Perl Beispiel und habe es ein bisschen modifiziert. Das Script liegt auf meinem Monitoring Host unter /etc/icinga2/scripts/pushover.pl und hat diesen Inhalt:

#!/usr/bin/perl

use LWP::UserAgent;
use Mozilla::CA;

LWP::UserAgent->new()->post(
 "https://api.pushover.net/1/messages.json", [
 "token" => "meinapitoken",
 "user" => "meinusertoken",
 "message" => $ENV{'message'},
 "title" => $ENV{'title'},
]);

Read More „Icinga2 Notifications via Pushover.net“

Ubuntu 15.10/16.04 – Center und Bass/LFE bei 5.1 Audio vertauschen

Ich benutze eine USB Soundkarte am Laptop, da ich mein Roccat Kave XTD nicht mit den Klinksteckern am Laptop direkt anstecken kann. Der Grund dafür sind fehlende Steckmöglichkeiten :-)
In Ubunteu 15.10 und 16.10 meldet sich diese Soundkarte als „CM106 Like Sound Device“. Das Problem ist, dass Center- und Bass- bzw. LFE-Lautsprecher vertauscht sind. In Ubuntu 15.04 war das noch nicht so.

Um dies zu ändern öffnet man im Termin (als root) die Datei unter /usr/share/pulseaudio/alsa-mixer/profile-sets/default.conf. In dieser Datei befindet sich folgender Block:

[Mapping analog-surround-51]
device-strings = surround51:%f
channel-map = front-left,front-right,rear-left,rear-right,front-center,lfe
paths-output = analog-output analog-output-lineout analog-output-speaker
priority = 8
direction = output

Das ist das Standardprofil, was in der GUI als „Analog Surround 5.1 Ausgang“ bezeichnet wird. Um nun Center- und Bass- bzw. LFE-Lautsprecher zu vertauschen, passt man die Option „channel-map“ an, sodass die Reihenfolge in der Zeile so aussieht: Read More „Ubuntu 15.10/16.04 – Center und Bass/LFE bei 5.1 Audio vertauschen“

check_rdns: Reverse DNS/PTR Records monitoren

Frei nach dem Motto „Monitoren was geht“, habe ich wieder mal versucht, mit den Boardmitteln check_dig und check_dns meine Reverse DNS/PTR Records zu monitoren.
Leider geht das nicht so, wie ich mir das vorgestellt habe. Deshalb habe ich einen kurzen Check für diese Usecase geschrieben. Zu finden ist das gute Stück auf GitHub.

Das Script nimmer zwei Parameter:

  • –address und
  • –expected

Der Parameter „–address“ nimmt eine IPv4 oder IPv6 Adresse. Mit Hilfe von dem Kommando „dig“ wird der Reverse DNS Lookup durchgeführt und das Ergebnis mit dem Wert von „–expected“ verglichen. Das Ergebnis ist entweder ein Match oder eben kein Match. Read More „check_rdns: Reverse DNS/PTR Records monitoren“

Icinga 2: DNSBL Check mit Icinga 2 und check_rbl

Viele Mailserver überprüfen vor dem anliefern eine E-Mail, ob der versendende Server auf einer Blacklist steht. Dazu fragen sie via DNS bei einem Blacklist Provider an. Gibt dieser eine IP Adresse aus dem Bereich 127.0.0.1/24 zurück, dann steht der Server auf der Blacklist. Das Resultat: Die E-Mails werden nicht mehr angenommen. Wird der Fehler NXDOMAIN (also „nicht gefunden“) zurück geliefert ist kein Eintrag auf der Blacklist vorhanden.
Für Firmen ist ein Eintrag auf einer Blacklist nichts schönes, doch auch für private Mailserver ist so ein Check sinnvoll. Normalerweise landet man schneller auf einer Blacklist als eine Abusemeldung beim Provider eintrifft und bearbeitet wird. Sobald diese eintrifft, kann man den Provider wenigstes beschwichtigen und sagen, dass das Problem schon bekannt und hoffentlich auch schon behoben ist.

Mit den Boardmitteln check_dns oder check_dig kann man leider nicht arbeiten, da man nicht auf NXDOMAIN prüfen kann.

check_rbl

Es gib auf GitHub das Plugin check_rbl von Matteo Corti, mit dem die Prüfung möglich ist. Das Script nimmt eine Domain oder IP-Adresse und prüft sie gegen eine Liste von Blacklists. Leider wird kein CheckCommand mitgeliefert. Das CheckCommand von Markus Benning hat mir nicht gefallen, da ich dort nicht in der Lage bin verschiedene IPs gegen verschiedenen Blacklists zu checken. Deshalb habe ich es etwas angepasst: Read More „Icinga 2: DNSBL Check mit Icinga 2 und check_rbl“

HTTP Public Key Pinning mit Let’s Encrypt Zertifikaten

Es war mal wieder soweit. Drei Monate sind rum und mein Monitoring vermeldete: „You Certificate expires in 15 days“. Die Erneuerung war dank Let’s Encrypt kein Problem und innerhalb einer Minute durch. Den HTTP Header für HTTP Public Key Pinning anpassen war ein Kampf, da ich keine Dokumentation drüber hatte. Das hole ich jetzt nach.

Hashes erstellen

Für den Header braucht man die Base64 encoded SHA-256 Hashes der Zertifikate. Im HTTP Header müssen mindestens zwei Pins angeben und mindestens ein Pin darf nicht einem Zertifikat in der Chain matchen.
Andere Tutorials erstellen einen „Backup“ Certificate Signing Request. Da das ganze CSR erstellen und signieren lassen der Job vom Let’s Encrypt Client ist, gehe ich einen anderen Weg: Ich denke mir den dritten Pin einfach aus. Ganz sauber ist das nicht, jedoch geht es ohne zwei Pins nicht und es ist besser als gar kein Pinning.
Pin 1 wird vom Zertifikat an sich generiert, der benötigte zweite valide Pin wird vom Let’s Encrypt CA Zertifikat erstellt.

Der Let’s Encrypt Client speichert die Zertifikate und alle anderen benötigten Datein unter /etc/letsencrypt/live/>domain</. Bei mir also unter /etc/letsencrypt/live/blog.veloc1ty.de/.
In diesem Verzeichnis habe ich folgende Dateien: Read More „HTTP Public Key Pinning mit Let’s Encrypt Zertifikaten“

KVM: Wenig Entropie in Guests | Virtualisierter Hardware RNG

Ich habe bei der Diagnose bezüglich langsamen TLS/SSL Verbindungen festgestellt, dass die verfügbare Entropie meiner KVM Guests sehr gering war. Der Wert Betrug ungefähr 150 – 190.
Nach dem Start eines Guests konnte ich sehen, wie der Pool nur sehr langsam gefüllt wurde. Dabei ist es eigentlich kein Wunder, dass die Werte bei KVM Guests ziemlich gering ist: Die Maschinen haben im Vergleich zu physischen Servern fast keine Last oder Hardware, die gute Zufallszahlen zulassen würden.

Exkurs: Entropie und Linux

Linux hat einen Entropie-Pool, der stets mit „qualitativ hochwertige“ Zufallszahlen gefüllt sein sollte. Diesen Pool kann man via den beiden Device Files

  • /dev/random (blocking) und
  • /dev/urandom (non-blocking)

anzapfen.

Jedes Programm, das Zufallszahlen braucht, benutzt sich im Normalfall aus einem der beiden Files. Stark beansprucht wird der Entropie Pool, wenn zum Beispiel mit Kryptographie gearbeitet wird (TLS-Verbindungen, Schlüsselpaare erzeugen, usw). Read More „KVM: Wenig Entropie in Guests | Virtualisierter Hardware RNG“

HP Office Jet 6700 – Scans direkt auf USB Stick speichern

Vor einiger Zeit habe ich auf Twitter den HP Support bezüglich des Speicherns von Bildern auf USB Sticks befragt. Ich hatte die Hoffnung, dass das Multifunktionsgerät ext4 erkennt. Meiner Meinung nach sollte das 2015 schon möglich sein. Ich wurde enttäuscht. Mehr oder weniger wurde ich jedoch auf die richtige Vorgehensweise hingewiesen. Der Link zum Tweet: https://twitter.com/DerVeloc1ty/status/580432675913232384

Ohne weiteres mit FAT32 zu formatieren und einstecken ist es aber nicht: Auf dem USB Stickt darf es keine Partitionstabelle geben. Ich musste also einen USB Stick sehr speziell herstellen.

Nullen des USB Sticks

Zu Beginn muss man das bestehende Dateisystem (falls vorhanden) kaputt machen. Das macht man am besten durch überschreiben der ersten Bits. Vorher sollte man aber prüfen, ob der Stick nicht irgendwo gemounted ist. Falls ja, dann zuerst unmounten. Read More „HP Office Jet 6700 – Scans direkt auf USB Stick speichern“