IT-Blog von Sebastian van de Meer

Kategorie: Kernel-Error-Blog (Seite 22 von 45)

Persönlicher Tech-Blog von Sebastian van de Meer — Beiträge zu IT-Security, Netzwerken, FreeBSD, Linux, Elektronik und Maker-Projekten.

Temperatur und Luftfeuchtigkeit mit DHT22 am Raspberry Pi messen

Meine Wetterstation hatte aufgegeben. Wirklich interessiert haben mich aber eh nur Temperatur und Luftfeuchtigkeit draußen. Das sollte ein Raspberry Pi mit einem DHT22 für zwei Euro hinbekommen — und die Daten landen direkt in meinem Cacti.

Update März 2026 — Dieser Beitrag ist von 2014 und einer meiner ältesten hier im Blog. Die Grundidee — DHT22 an den GPIO, Werte per Cron einsammeln, per SNMP an Cacti liefern — funktioniert unverändert. Ich habe den Beitrag komplett überarbeitet und den Software-Teil auf Python aktualisiert. Die ursprünglich verwendete C-Bibliothek wiringPi wurde 2019 vom Autor offline genommen und lol_dht22 wird nicht mehr gepflegt. Der Ansatz selbst ist zeitlos.

Was du brauchst

  • Einen Raspberry Pi — egal welches Modell, solange GPIO-Pins vorhanden sind
  • Einen DHT22 / AM2302 Sensor (2–5 €)
  • Einen 4,7 kΩ Widerstand als Pull-up
  • Drei Kabel

Die Verkabelung ist simpel: VCC an 3,3 V (Pin 1), Data an GPIO 4 (Pin 7), GND an GND (Pin 6). Der 4,7 kΩ Widerstand kommt zwischen VCC und Data. Den handgezeichneten Schaltplan habe ich unten in der Bildergalerie.

Sensor auslesen — Python

Auf einem aktuellen Raspberry Pi OS brauchen wir die Adafruit CircuitPython DHT Bibliothek und libgpiod:

sudo apt install python3-pip libgpiod2
pip3 install adafruit-circuitpython-dht

Dann ein kleines Script /usr/local/bin/read_dht22.py:

#!/usr/bin/env python3
import adafruit_dht
import board
import sys

sensor = adafruit_dht.DHT22(board.D4)
try:
    print(f"{sensor.humidity:.1f}")
    print(f"{sensor.temperature:.1f}")
except RuntimeError:
    sys.exit(1)
finally:
    sensor.exit()

Ausführbar machen und testen:

chmod +x /usr/local/bin/read_dht22.py
/usr/local/bin/read_dht22.py
73.9
9.3

Erste Zeile Luftfeuchtigkeit, zweite Zeile Temperatur. Der DHT22 liefert nicht bei jedem Aufruf saubere Daten — manchmal kommt ein RuntimeError. Das ist normal bei diesem Sensor, deswegen der try/except und der Exit-Code. board.D4 entspricht GPIO 4, also Pin 7 auf dem Board.

Werte per Cron einsammeln

Per Cron-Job jede Minute:

* * * * * /var/scripts/getsensor.sh

Das Script /var/scripts/getsensor.sh:

#!/bin/bash
/usr/local/bin/read_dht22.py > /home/pi/both.txt 2>/dev/null

while [ ! -s "/home/pi/both.txt" ]; do
    sleep 5
    /usr/local/bin/read_dht22.py > /home/pi/both.txt 2>/dev/null
done

sed '2d' /home/pi/both.txt > /home/pi/humid.txt
sed '1d' /home/pi/both.txt > /home/pi/temp.txt

Wenn der Sensor beim ersten Versuch keine Daten liefert, probiert das Script alle fünf Sekunden erneut. Am Ende liegen Luftfeuchtigkeit und Temperatur in separaten Textdateien unter /home/pi/.

Ab in den Cacti — SNMP

Damit Cacti die Werte abfragen kann, brauchen wir SNMP auf dem Pi:

sudo apt install snmpd snmp

In der /etc/snmp/snmpd.conf zwei Pass-through OIDs anlegen. Wird eine dieser OIDs per SNMP abgefragt, führt der snmpd das zugehörige Script aus und liefert dessen Ausgabe als Antwort:

pass .1.3.6.1.2.1.25.1.8.1  /bin/sh  /usr/local/bin/humid
pass .1.3.6.1.2.1.25.1.8.2  /bin/sh  /usr/local/bin/temp

Die beiden Scripts müssen drei Zeilen ausgeben — die OID, den Datentyp und den Wert:

/usr/local/bin/temp:

#!/bin/bash
echo .1.3.6.1.2.1.25.1.8.2
echo gauge
cat /home/pi/temp.txt

/usr/local/bin/humid:

#!/bin/bash
echo .1.3.6.1.2.1.25.1.8.1
echo gauge
cat /home/pi/humid.txt

Test:

snmpget -v2c -c public localhost .1.3.6.1.2.1.25.1.8.1
iso.3.6.1.2.1.25.1.8.1 = Gauge32: 76

snmpget -v2c -c public localhost .1.3.6.1.2.1.25.1.8.2
iso.3.6.1.2.1.25.1.8.2 = Gauge32: 9

Damit lässt sich im Cacti ein Graph anlegen. Etwas von hinten durch die Brust ins Auge — aber es funktioniert seit über elf Jahren zuverlässig. Die Template-Exports für Cacti gibt es hier: cacti-temp.tar.gz


Hinweise

SNMP-Sicherheit — Im Beispiel steht public als Community-String und SNMPv2c. Für ein Heimnetz reicht das. In einem produktiven Umfeld sollte man SNMPv3 mit Authentifizierung verwenden und den Zugriff per Firewall auf den Cacti-Server beschränken.

Alternative zu Cacti — Wer kein Cacti hat: Grafana mit InfluxDB oder Prometheus wäre die modernere Alternative. Der SNMP-Weg funktioniert dort genauso, alternativ kann man die Werte auch direkt per Telegraf oder einen kleinen Python-Exporter einliefern.

Warum kein wiringPi mehr? — Gordon Henderson hat das wiringPi-Repository 2019 offline genommen. Es gibt Forks auf GitHub, die auf neueren Pi-Modellen funktionieren, aber offiziell wird die Bibliothek nicht mehr gepflegt. Für neue Projekte ist Python mit der Adafruit-Bibliothek der bessere Weg — weniger Kompilieraufwand, bessere Fehlerbehandlung und aktive Wartung.


Der Sensor da draußen

Der Sensor muss nach draußen, vor Wasser geschützt sein, aber nicht hermetisch versiegelt — sonst kann er keine Luftfeuchtigkeit messen.

Meine Lösung: Ein PVC-Rohr, den Sensor dort mit etwas Silikon eingeklebt, eine Seite mit Deckel verschlossen. So kann kein Wasser an den Sensor laufen, Luft kommt aber noch ran. Angebracht am Pfosten der Satellitenschüssel — dort oben steht die Luft selten, es kommt niemand ran und es fällt nicht auf.

Das Ding hängt dort seit 2014. Funktioniert.


Siehe auch: Raspberry Pi als Konsolenserver

Fragen? Einfach melden.

Openfire: 404 Remote Server Not Found bei S2S-Verbindungen mit TLS

Seit ich für die Server-zu-Server-Verbindungen (S2S) auf meinem Openfire TLS erzwinge, melden sich andere Openfire-Admins: Ihre User bekommen ein „404 remote server not found“. Nachrichten gehen nur in eine Richtung durch. Wenn die Unterhaltung einmal läuft, klappt es für eine Weile. Ein seltsamer Effekt der nicht direkt auf die Ursache schließen lässt.

Das Problem

Das Problem liegt nicht am eigenen Server und nicht am DNS. Es liegt am Java-Keystore auf der Gegenseite. Java 6 und einige Versionen von Java 7 können die Zertifikatskette nicht korrekt aufbauen, wenn das Intermediate-Zertifikat der CA fehlt. Mein Server sendet es zwar mit, aber Java ignoriert es und versucht die Kette allein aus dem lokalen Truststore zu bauen.

Im warn.log des betroffenen Openfire findet man dann:

org.jivesoftware.openfire.server.ServerDialback - Error verifying key of remote server: jabber.kernel-error.de
org.jivesoftware.openfire.server.ServerDialback - ServerDialback: OS - Ignoring unexpected answer in validation

Die Lösung: Intermediate-Zertifikat importieren

Der Admin des betroffenen Openfire muss das Intermediate-Zertifikat der CA in den Java-Truststore importieren. Auf einem Debian-System:

cd /etc/openfire/security/
/etc/init.d/openfire stop

# Intermediate-Zertifikat der CA herunterladen
wget "https://example-ca.com/intermediate.crt"

# In den Truststore importieren
keytool -import -keystore truststore -alias ca-intermediate -file intermediate.crt
# Passwort: changeit (Java-Default)

/etc/init.d/openfire start

Das Prinzip gilt für jede CA. Das Intermediate-Zertifikat von der Webseite der CA herunterladen und mit keytool in den Truststore importieren. Falls das Zertifikat bereits vorhanden ist, meldet keytool das und man kann den Import überspringen.

Prüfen ob die Kette stimmt

Mit openssl lässt sich prüfen ob der Server das Intermediate-Zertifikat korrekt ausliefert:

openssl s_client -showcerts -connect jabber.example.com:5222 -starttls xmpp

Entscheidend ist die letzte Zeile der Ausgabe:

Verify return code: 0 (ok)

Steht dort etwas anderes, fehlt ein Zertifikat in der Kette oder das Intermediate-Zertifikat wird nicht mitgesendet. In dem Fall muss der Serverbetreiber seine Zertifikatskonfiguration in Openfire prüfen.

Wer schon dabei ist die TLS-Konfiguration anzufassen: Im Beitrag zu unsicheren Ciphern und Protokollen in Openfire steht wie man die veralteten Algorithmen loswird.

Fragen? Einfach melden.

DNSSEC: KSK auf 4096 Bit aktualisieren und SHA-512 vorbereiten

Ich habe nach längerem dann mal meinen KSK (Key Signing Key) für DNSSEC getauscht. Der alte war ein 1024-Bit NSEC3RSASHA1. Damit ist auch klar, warum er weg musste: 1024 Bit RSA gilt seit Jahren als zu schwach für langfristige Sicherheit, und SHA-1 steht ebenfalls auf der Abschussliste.

Die neuen Schlüssel

Zwei neue KSKs, beide mit 4096 Bit:

1. NSEC3RSASHA1, 4096 Bit  (primär, abwärtskompatibel)
2. RSASHA512, 4096 Bit     (Reserve, ohne SHA-1)

Die Idee: Der NSEC3RSASHA1 als primärer Schlüssel, weil ihn jede halbwegs aktuelle Software versteht. Der RSASHA512 liegt als Backup bereit, falls SHA-1 irgendwann komplett fällt. Inzwischen sollte jede aktuelle Software mit beiden Algorithmen umgehen können. Wenn nicht, wird es wirklich Zeit für ein Update.

KSK-Rollover

Ein KSK-Tausch ist kein Schalter den man umlegt. Man muss den neuen Schlüssel veröffentlichen, warten bis sich der DS-Record bei der übergeordneten Zone (also bei DENIC, Verisign etc.) verbreitet hat, und erst dann den alten entfernen. Dazwischen signiert man mit beiden gleichzeitig. Das dauert je nach TTL einige Tage.

Das Ergebnis auf DNSViz sieht sauber aus. Alle drei Zonen validieren korrekt:

Wer DNSSEC von Grund auf einrichten will, findet die Anleitung unter DNSSEC einrichten mit BIND. Fragen? Einfach melden.

Stromverbrauch messen mit Raspberry Pi, Eltako DSZ12E und Cacti

Im Keller hing ein alter Ferraris-Zähler mit Drehscheibe. Zählt brav für den Energieversorger, liefert aber keine Daten. Ich wollte den Stromverbrauch im Haus grafisch auswerten, am besten mit Cacti. Dafür braucht man einen Zähler mit S0-Schnittstelle.

Der Zähler

Mein Energieversorger wollte für einen digitalen Zähler Fantasiepreise. Also selbst kaufen. Die Wahl fiel auf den Eltako DSZ12E-3x80A, einen Drehstromzähler mit S0-Ausgang. 3 × 80 A reicht für den normalen Hausgebrauch locker. Kostenpunkt damals rund 75 Euro.

Wichtig: Dieser Zähler ersetzt nicht den offiziellen Zähler des Versorgers. Er wird dahinter eingebaut. Das darf nicht jeder machen. Wer nicht weiß ob er es darf, darf es nicht. Ein Elektriker braucht dafür eine halbe bis eine Stunde, mit Anfahrt kommt man auf 100 bis 150 Euro.

S0-Schnittstelle und Raspberry Pi

Die S0-Schnittstelle ist ein potentialfreier Impulskontakt. Pro verbrauchter Kilowattstunde gibt der Zähler eine bestimmte Anzahl Impulse aus, beim DSZ12E sind es 2000 Impulse pro kWh. Der Raspberry Pi zählt diese Impulse über einen GPIO-Pin.

Die Verkabelung ist simpel: S0-Ausgang des Zählers an einen GPIO-Pin und GND des Raspberry Pi. Ein Pullup-Widerstand sorgt dafür, dass der Pin sauber zwischen High und Low wechselt. Bei jedem Impuls wird ein Zähler hochgezählt und der aktuelle Verbrauch berechnet.

Die Auswertung habe ich nach dieser Anleitung aufgebaut: Stromzähler mit S0-Schnittstelle vom Raspberry Pi auswerten (Johannes Weber). Ein Python-Script zählt die Impulse und stellt die Werte per SNMP bereit.

Cacti-Graphen

Cacti fragt den Raspberry Pi per SNMP ab und zeichnet die Graphen. Neben dem aktuellen Verbrauch in Watt lassen sich mit zusätzlichen SNMP-Abfragen auch Tagesverbrauch, Wochenverbrauch und Monatsverbrauch darstellen. Die Berechnung macht das Script auf dem Pi, Cacti muss nur die fertigen Werte abgreifen und zeichnen.

Das Ergebnis: Auf einen Blick sieht man wann die Waschmaschine lief, wann der Herd an war und wie hoch die Grundlast nachts ist. Verbrauchsspitzen fallen sofort auf.

Fragen zum Aufbau? Einfach melden.

FreeBSD: ZFS-Datensicherung mit Snapshots und zfs send/recv

ZFS bringt alles mit, was man für eine solide Datensicherung braucht: Snapshots sind atomar und sofort erstellt, und mit zfs send lassen sie sich über SSH auf ein anderes System replizieren. Nach einem initialen Vollabgleich werden nur noch die Differenzen übertragen.

Der Ablauf:

  • Snapshot auf dem Quellsystem anlegen
  • Ziel-Dataset auf dem Backup-Server erstellen
  • Snapshot per SSH ins Ziel schieben (Vollabgleich)
  • Weitere Snapshots anlegen und nur die Differenz übertragen

Snapshot erstellen

Auf dem Quellsystem — hier ein FreeBSD-Notebook — einen rekursiven Snapshot anlegen:

zfs snapshot -r tank/usr/home/kernel@2014-10-12

Prüfen:

zfs list -t snapshot tank/usr/home/kernel
NAME                                    USED  AVAIL  REFER  MOUNTPOINT
tank/usr/home/kernel@2014-10-12        20,0M      -  96,9G  -

Initialer Vollabgleich

Auf dem Backup-Server ein Ziel-Dataset anlegen:

zfs create DatenPool01/Datensicherung/errorlap

Den Snapshot per SSH ins Ziel schieben — -R sendet rekursiv alle Datasets und Properties mit:

zfs send -R tank/usr/home/kernel@2014-10-12 \
  | ssh root@backup-server zfs recv -Fduv DatenPool01/Datensicherung/errorlap

receiving full stream of tank/usr/home/kernel@2014-10-12 into
DatenPool01/Datensicherung/errorlap/usr/home/kernel@2014-10-12
received 98.4GB stream in 5298 seconds (19.0MB/sec)

Inkrementelle Sicherung

Neuen Snapshot anlegen und nur die Differenz zum vorherigen übertragen:

zfs snapshot -r tank/usr/home/kernel@2014-10-12-02

zfs send -R -i tank/usr/home/kernel@2014-10-12 tank/usr/home/kernel@2014-10-12-02 \
  | ssh root@backup-server zfs recv -Fduv DatenPool01/Datensicherung/errorlap

receiving incremental stream of tank/usr/home/kernel@2014-10-12-02 into
DatenPool01/Datensicherung/errorlap/usr/home/kernel@2014-10-12-02
received 991MB stream in 59 seconds (16.8MB/sec)

991 MB statt 98 GB — das ist der Vorteil inkrementeller Snapshots.

Automatisierung

Dieser Ablauf lässt sich per Skript und Cronjob vollständig automatisieren. Mit automatischen ZFS-Snapshots und SSH-Key-Authentifizierung kann man alle 15 Minuten inkrementell sichern — bei passender Internetanbindung auch standortübergreifend. Falls beim inkrementellen Transfer ein cannot receive incremental stream auftaucht, hilft der Beitrag zur Fehlerbehebung mit zfs recv -F.

Wer das Backup auf eine verschlüsselte USB-Platte statt auf einen Server schieben will, findet dort die geli-Anleitung dazu.

Fragen? Einfach melden.

Alternative SPF-RECORDS im DNS

Veraltet: Der dedizierte SPF-DNS-Record-Typ (Typ 99) wurde mit RFC 7208 als deprecated eingestuft. SPF wird ausschließlich über TXT-Records veröffentlicht. Siehe den aktuellen SPF-Beitrag.

Da ich es gerade mal wieder auf dem Tisch habe…. Ja, „früher“ konnte man verschiedene RECORDS im DNS setzten um SPF-RECORDS zu veröffentlichen. So auch einen Record Type mit dem direkten Namen SPF. Seit 2014 ist dem aber nicht mehr so! Denn ab jetzt soll man seine SPF-Records nur noch als TXT-Record (RFC1035 Typ 16) veröffentlichen. Dieses steht im fertigen RFC7208 Abschnitt 3.1.

Damit also bitte die ganzen anderen RECORDS zu SPF aus dem DNS entfernen und nur noch TXT-RECORDS einsetzten. Ich freue mich darüber, denn bisher musste man sonst eine Vielzahl verschiedener Records pflegen, da man sich nicht sicher sein konnte, welchen jetzt bitte die Implementierung des Empfängers nutzt. Zugegeben, die Basis TXT war die am meisten verbreitete Version. Denn noch gab es da hin und wieder ein Problem. Nun steht das RFC bereits einige Zeit fest, und ich habe alle anderen „SPF-RECORDS“ aus dem DNS entfernt. Nun also nur noch TXT bei mir.

So long

Notebook Akku def.

Das ist doch nicht zu glauben 🙁 Mein Notebook Akku ist im Eimer!

Für einen passenden neuen muss ich knapp 100/120€ auf den Tisch legen. Klar, irgendwann gibt ein Akku halt mal auf… Nur dieser hat besonders schnell aufgegeben. Nach knapp 2,5 Jahren ist er nun tot. Die letzten haben im Schnitt 3 – 4 Jahre bei mir gehalten. Meine Art mit den Notebook zu arbeiten ist dabei fast unverändert. Na ja, der Stromverbrauch ist denn noch nicht ohne, daher mache ich dem Akku mal keinen Vorwurf. Große CPU, viel Speicher, zwei Festplatten, 17″ (ja, ich renne mit so einem riesigen Schläptop herum).

 

[kernel@errorlap:~]$ acpiconf -i 0
Design capacity:        5200 mWh
Last full capacity:     2093 mWh
Technology:             primary (non-rechargeable)
Design voltage:         14800 mV
Capacity (warn):        0 mWh
Capacity (low):         0 mWh
Low/warn granularity:   100 mWh
Warn/full granularity:  0 mWh
Model number:           BAT0
Serial number:          123456789
Type:                   LiON
OEM info:               PTL
State:                  high 
Remaining capacity:     97%
Remaining time:         unknown
Present rate:           0 mW
Present voltage:        16403 mV

 

In diesem Sinne… Werde ich wohl mal einen Ersatzakku bestellen, oder gleich ein neues Notebook? Ach ich bin da noch etwas unschlüssig. Das Gerät selbst ist noch ganz gut, hat aber schon einiges geleistet…

Fragen? Einfach melden.

Kein Jabber/XMPP mehr ohne Transportverschlüsselung

Hallo zusammen,

wie ja bereits vor einiger Zeit angekündigt, habe ich heute TLS als Transportverschlüsselung zwischen den Server to Server Verbindungen erzwungen. Für die Clients s2c besteht dieser Zwang bereits seit langem, nun also auch für die Verbindungen zwischen der Server.

Ich habe mir natürlich vorher die Mühe gemacht, andere Serverbetreiber anzuschreiben, wenn ich zu ihnen keine verschlüsselte s2s Verbindung aufbauen konnte. Ein paar sind aktiv geworden, ein paar nicht. Die Anzahl der nicht verschlüsselten s2s Verbindungen ist denn noch verschwindend gering! Ich habe diese Verbindungen also hiermit bewusst „abgehängt“.

Sollte ihr also aktuell Probleme mit der Verbindung zu oder von meinem System haben, bitte einfach melden!

So long…

Siehe auch: Openfire: Unsichere TLS-Cipher deaktivieren

Fragen? Einfach melden.

IP Reverse Map Delegation: Einrichtung und Fehlerbehebung

Reverse Map Delegation nach RFC 2317 klingt komplizierter als es ist. Es löst ein konkretes Problem: Wer ein kleines IP-Netz hat (kleiner als /24), kann normalerweise keine eigene PTR-Zone betreiben. Mit Reverse Map Delegation geht es doch.

Warum man es braucht

In der guten alten Zeit bekam man ein /24 (256 Adressen). Da legt man einfach eine Zone 3.2.1.in-addr.arpa. an und fertig. Heute bekommt man, wenn überhaupt, ein /29 (8 Adressen). Und da liegt das Problem: DNS-Zonen werden am Punkt getrennt. Bei einem /24 passt das, bei einem /29 gibt es keinen Punkt an dem man die Zone aufteilen kann.

Der Provider behält also die /24-Zone und richtet für das kleine Subnetz CNAMEs ein, die auf eine „Sub-Zone“ des Kunden zeigen. Der Kunde kann dann seine PTR-Records selbst verwalten.

Die Provider-Seite

In der /24-Zone des Providers wird für das Subnetz 1.2.3.0/29 eine Delegation eingerichtet. Jede IP-Adresse bekommt einen CNAME in die Sub-Zone des Kunden:

$ORIGIN 3.2.1.in-addr.arpa.
$TTL 1D
@   1D IN SOA ns1.kernel-error.de. hostmaster.kernel-error.de. (
              2014101701 ; serial
              6H         ; refresh
              30M        ; retry
              2W         ; expiry
              1D )       ; minimum

         IN NS  ns1.kernel-error.de.
         IN NS  ns2.kernel-error.org.

; Delegation für 1.2.3.0/29 an den Kunden
0/29     IN NS    ns1.vandemeer.de.
0/29     IN NS    ns2.vandemeer.de.
0        IN CNAME 0.0/29.3.2.1.in-addr.arpa.
1        IN CNAME 1.0/29.3.2.1.in-addr.arpa.
2        IN CNAME 2.0/29.3.2.1.in-addr.arpa.
3        IN CNAME 3.0/29.3.2.1.in-addr.arpa.
4        IN CNAME 4.0/29.3.2.1.in-addr.arpa.
5        IN CNAME 5.0/29.3.2.1.in-addr.arpa.
6        IN CNAME 6.0/29.3.2.1.in-addr.arpa.
7        IN CNAME 7.0/29.3.2.1.in-addr.arpa.

Die Kunden-Seite

Der Kunde richtet auf seinem DNS-Server die Sub-Zone ein und kann dort seine PTR-Records setzen wie gewohnt:

$ORIGIN 0/29.3.2.1.in-addr.arpa.
$TTL 1D
@   1D IN SOA ns1.vandemeer.de. hostmaster.vandemeer.de. (
              2014101701 ; serial
              6H         ; refresh
              30M        ; retry
              2W         ; expiry
              1D )       ; minimum

         IN NS  ns1.vandemeer.de.
         IN NS  ns2.vandemeer.de.

0        IN PTR netzadresse.vandemeer.de.
1        IN PTR router.vandemeer.de.
2        IN PTR mailin.vandemeer.de.
3        IN PTR imap.vandemeer.de.
4        IN PTR webserver.vandemeer.de.
5        IN PTR frei.vandemeer.de.
6        IN PTR frei.vandemeer.de.
7        IN PTR broadcastadresse.vandemeer.de.

Ergebnis

Eine Reverse-Lookup-Abfrage für 1.2.3.4 läuft jetzt über den CNAME zum DNS des Kunden und liefert den gewünschten PTR-Record:

dig -x 1.2.3.4 +short
4.0/29.3.2.1.in-addr.arpa.
webserver.vandemeer.de.

Probleme

Wäre ja zu schön, wenn es keine gäbe.

Laut RFC darf ein PTR-Record eigentlich kein CNAME sein, außer in genau diesem Fall. Das RFC ist von 1998, aber es hat sich nicht überall herumgesprochen. Man muss seinem Gegenüber gelegentlich RFC 2317 erklären, bevor die Diskussion weitergeht.

Außerdem macht Postfix Ärger, wenn man reject_unknown_client in den smtpd_restrictions hat. Diese Prüfung erwartet, dass PTR und A/AAAA-Record zueinander passen. Bei Reverse Map Delegation tun sie das nicht, weil der CNAME dazwischen steht:

450 4.7.1 Client host rejected: cannot find your hostname, [4.5.6.7]

Wer einen größeren Mailserver betreibt, sollte auf der Mail-IP kein Reverse Map Delegation einsetzen, sondern den PTR direkt beim Provider setzen lassen. Spart Arbeit und Ärger.

Fragen? Einfach melden.

SSLv3 ist tot…

Veraltet: Dieser Beitrag ist eine Momentaufnahme von 2014. SSLv3 ist seit dem POODLE-Angriff in allen Browsern und Servern deaktiviert. TLS 1.0 und 1.1 wurden ebenfalls inzwischen aus allen Browsern entfernt.

Nein, ich habe es nicht überlesen. SSLv3 ist damit wohl hoffentlich tot!

Es ist ja nicht so als wenn man nicht schon davor gewarnt hätte. Oh was hat diese Meldung bei mir für gute Laune geführt! Wieder mal ein richtiger „Told you so“ Moment für mich.

Oh ja, was zum Lesen gefällig?

http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html

Bäääähhhhmmmm! Das schreit nach einem GIF!

Told you so reaction GIF about SSLv3 deprecation

Auf die schnell böse Dinge deaktivieren…

Postfix:

smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers=high
tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA

Dovecot:

ssl_cipher_list = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4
ssl_protocols = !SSLv2 !SSLv3

Apache2:

SSLEngine on
SSLProtocol +ALL -SSLv3 -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4
SSLCompression off
Header always set Strict-Transport-Security "max-age=15552000"
« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑