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

Schlagwort: Email (Seite 3 von 11)

E-Mail Adressen

Das ist eine Kontaktliste mit E-Mail Adressen, an welche man unbedingt Angebote schicken muss. Wer fragen zur Kontaktliste hat, bitte einfach melden!

wurstmann@kernel-error.org

kleinmann@kernel-error.org

hundebauch.balem@kernel-error.org

info@kernel-error.org

buchhaltung@kernel-error.org

management@kernel-error.org

ceo@kernel-error.org

wurstmann@tagesmutter-rheinbach.de

kleinmann@tagesmutter-rheinbach.de

hundebauch.balem@tagesmutter-rheinbach.de

info@tagesmutter-rheinbach.de

buchhaltung@tagesmutter-rheinbach.de

management@tagesmutter-rheinbach.de

ceo@tagesmutter-rheinbach.de

wurstmann@van-alst.de

kleinmann@van-alst.de

hundebauch.balem@van-alst.de

info@van-alst.de

buchhaltung@van-alst.de

management@van-alst.de

ceo@van-alst.de

wurstmann@linux-rheinbach.de

kleinmann@linux-rheinbach.de

hundebauch.balem@linux-rheinbach.de

info@linux-rheinbach.de

buchhaltung@linux-rheinbach.de

management@linux-rheinbach.de

ceo@linux-rheinbach.de

wurstmann@kindertagespflege-sprockhoevel.de

kleinmann@kindertagespflege-sprockhoevel.de

hundebauch.balem@kindertagespflege-sprockhoevel.de

info@kindertagespflege-sprockhoevel.de

buchhaltung@kindertagespflege-sprockhoevel.de

management@kindertagespflege-sprockhoevel.de

ceo@kindertagespflege-sprockhoevel.de

wurstmann@geekbundle.de

kleinmann@geekbundle.de

hundebauch.balem@geekbundle.de

info@geekbundle.de

buchhaltung@geekbundle.de

management@geekbundle.de

ceo@geekbundle.de

Fragen? Einfach melden.

TLS 1.3 für Postfix & Dovecot: Einrichtung und Konfiguration

TLS 1.3 ist im Mailbetrieb kein Sonderfall mehr, sondern der Normalzustand. Voraussetzung ist lediglich, dass Postfix und Dovecot gegen eine aktuelle OpenSSL-Version gelinkt sind. Sobald OpenSSL TLS 1.3 unterstützt, wird es automatisch verwendet. Eine explizite Aktivierung in der Applikation ist nicht erforderlich.

Die eigentliche Aufgabe der Konfiguration besteht daher nicht darin, TLS 1.3 „einzuschalten“, sondern darin, alte Protokollversionen sauber zu deaktivieren und für den verbleibenden TLS-1.2-Fallback eine kontrollierte Cipher-Policy zu definieren.

Illustration zu TLS 1.3 im Mailbetrieb: Symbolische Darstellung von Postfix und Dovecot mit Schloss und Schlüssel vor Server-Hintergrund, steht für verschlüsselte SMTP- und IMAP-Verbindungen mit modernen TLS-Standards.

Voraussetzungen

Postfix und Dovecot müssen gegen OpenSSL ≥ 1.1.1 gebaut sein. OpenSSL 3.x funktioniert ebenfalls ohne Einschränkungen. Welche Version tatsächlich genutzt wird, lässt sich eindeutig prüfen:

postconf -a | grep -i tls
dovecot --version
ldd $(which dovecot) | grep ssl
openssl version

Wenn hier OpenSSL 1.1.1 oder neuer auftaucht, ist TLS 1.3 verfügbar.

Postfix

Postfix verwendet TLS 1.3 automatisch, sofern der Client es anbietet. Entscheidend ist, welche Protokollversionen minimal erlaubt werden. TLS 1.0 und TLS 1.1 gelten als kryptographisch überholt und sollten nicht mehr akzeptiert werden.

Die folgende Konfiguration beschränkt Postfix auf TLS 1.2 und neuer. TLS 1.3 wird dabei bevorzugt ausgehandelt, TLS 1.2 dient nur noch als Fallback.

smtpd_tls_protocols = >=TLSv1.2
smtp_tls_protocols  = >=TLSv1.2

smtpd_tls_security_level = may
smtp_tls_security_level  = may

smtpd_tls_cert_file = /etc/letsencrypt/live/DOMAIN/fullchain.pem
smtpd_tls_key_file  = /etc/letsencrypt/live/DOMAIN/privkey.pem

Cipher-Optionen in Postfix gelten ausschließlich für TLS 1.2 und ältere Protokolle. TLS 1.3 verwendet fest definierte Cipher-Suites und ignoriert diese Einstellungen vollständig. Dennoch ist es sinnvoll, für den TLS-1.2-Fallback eine saubere Policy zu setzen.

tls_preempt_cipherlist = yes

smtpd_tls_ciphers = high
smtp_tls_ciphers  = high

Damit werden nur moderne Cipher mit Forward Secrecy genutzt, abhängig von den OpenSSL-Defaults der jeweiligen Distribution. Wer zusätzlich sicherstellen will, dass ausgehende Verbindungen verschlüsselt bleiben, sollte sich MTA-STS ansehen.

Session-Caching reduziert Handshake-Overhead und sollte aktiv sein:

smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database  = btree:${data_directory}/smtp_scache

Dovecot

Auch Dovecot nutzt TLS 1.3 automatisch, sofern OpenSSL es bereitstellt. Die relevante Einstellung ist die minimale Protokollversion. Alles darunter wird explizit ausgeschlossen.

ssl = required
ssl_min_protocol = TLSv1.2

Die Cipher-Liste in Dovecot betrifft ebenfalls nur TLS 1.2 und älter. TLS 1.3 wird davon nicht beeinflusst. Eine explizite, restriktive Cipher-Liste verhindert jedoch unsaubere Fallbacks bei älteren Clients.

ssl_cipher_list = \
ECDHE-ECDSA-CHACHA20-POLY1305:\
ECDHE-RSA-CHACHA20-POLY1305:\
ECDHE-ECDSA-AES256-GCM-SHA384:\
ECDHE-RSA-AES256-GCM-SHA384

ssl_prefer_server_ciphers = yes

Die Zertifikate werden wie gewohnt eingebunden:

ssl_cert = </etc/letsencrypt/live/DOMAIN/fullchain.pem
ssl_key  = </etc/letsencrypt/live/DOMAIN/privkey.pem

TLS 1.3 und Cipher-Suites

TLS 1.3 unterscheidet sich grundlegend von älteren Versionen. Die Cipher-Suites sind fest definiert und bestehen ausschließlich aus modernen AEAD-Verfahren mit integrierter Authentifizierung und Forward Secrecy. Typische Cipher sind AES-GCM und CHACHA20-POLY1305.

Postfix und Dovecot bieten keine Möglichkeit, diese Cipher direkt zu konfigurieren. Die Auswahl erfolgt intern durch OpenSSL während des Handshakes. Das ist beabsichtigt und reduziert Fehlkonfigurationen erheblich.

Wer versucht, TLS-1.3-Cipher über Applikationsoptionen zu beeinflussen, konfiguriert faktisch nur TLS 1.2.

Verifikation

Ob TLS 1.3 tatsächlich genutzt wird, lässt sich eindeutig prüfen.

SMTP mit STARTTLS:

openssl s_client -starttls smtp -connect mail.example.com:25 -tls1_3

IMAPS:

openssl s_client -connect mail.example.com:993 -tls1_3

Wird der Handshake erfolgreich aufgebaut und ein moderner AEAD-Cipher angezeigt, ist TLS 1.3 aktiv. Fällt die Verbindung auf TLS 1.2 zurück, greift die konfigurierte Cipher-Liste.

Fazit

TLS 1.3 erfordert in Postfix und Dovecot keine Sonderbehandlung. Entscheidend ist eine aktuelle OpenSSL-Version, eine klare Mindest-TLS-Policy und eine saubere Cipher-Konfiguration für den unvermeidbaren TLS-1.2-Fallback.

Alles andere erledigt der TLS-Stack selbst. Wer noch einen Schritt weiter gehen will, findet im Beitrag zu Post-Quantum TLS für E-Mail die nächste Stufe.

Kein Feature-Flag.
Keine Magie.
Nur korrekte Defaults, bewusst begrenzt.

Fragen? Einfach melden.

TLS 1.0 und 1.1 abschalten: Postfix, Dovecot und Nginx auf TLS 1.2+ umstellen

TLS 1.0 stammt von 1999, TLS 1.1 von 2006. Beide Versionen haben bekannte Schwächen (BEAST, POODLE, fehlende AEAD-Cipher) und werden seit 2020 von keinem Browser mehr unterstützt. Qualys SSL Labs vergibt seit 2020 maximal ein B-Rating wenn TLS 1.0 oder 1.1 aktiv ist. Es gibt keinen Grund mehr, diese Protokolle anzubieten.

Postfix

In der main.cf die Mindestversion auf TLS 1.2 setzen. Die Einstellungen gelten getrennt für eingehende (smtpd) und ausgehende (smtp) Verbindungen:

# Eingehend (smtpd)
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_protocols = >=TLSv1.2

# Ausgehend (smtp)
smtp_tls_mandatory_protocols = >=TLSv1.2
smtp_tls_protocols = >=TLSv1.2

Die Syntax >=TLSv1.2 gibt es seit Postfix 3.6. Bei älteren Versionen muss man die alten Protokolle einzeln ausschließen: !SSLv2, !SSLv3, !TLSv1, !TLSv1.1. Wenn OpenSSL 1.1.1+ oder neuer installiert ist, wird TLS 1.3 automatisch unterstützt und bevorzugt.

Dovecot

In conf.d/10-ssl.conf:

ssl_min_protocol = TLSv1.2
ssl_cipher_list = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
ssl_prefer_server_ciphers = yes

ssl_min_protocol gibt es seit Dovecot 2.3.15. In älteren Versionen heißt es ssl_protocols = !SSLv3 !TLSv1 !TLSv1.1. Die Cipher-Liste enthält nur AEAD-Cipher mit Forward Secrecy.

Nginx

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;

Die TLS-1.3-Cipher (TLS_AES_*) werden von OpenSSL automatisch bevorzugt und lassen sich nicht über ssl_ciphers deaktivieren. Die Reihenfolge in der Cipher-Liste gilt nur für TLS 1.2.

stunnel

Wer stunnel als TLS-Wrapper nutzt (z.B. für DNS over TLS):

options = NO_SSLv3
options = NO_TLSv1
options = NO_TLSv1.1

Prüfen

Nach der Umstellung prüfen ob die alten Protokolle wirklich deaktiviert sind:

# TLS 1.0 testen (sollte fehlschlagen)
openssl s_client -connect smtp.example.de:25 -starttls smtp -tls1 2>&1 | grep "Protocol"

# TLS 1.2 testen (sollte funktionieren)
openssl s_client -connect smtp.example.de:25 -starttls smtp -tls1_2 2>&1 | grep "Protocol"

Für Webserver hilft Qualys SSL Labs. Wer noch einen Schritt weitergehen will: Mit ECDSA-Zertifikaten wird der Handshake schneller und mit Post-Quantum Key Exchange ist der Schlüsselaustausch auch gegen Quantencomputer abgesichert. Fragen? Einfach melden.

IPv6 Traffic hat sich verdoppelt

Wenn ich meine Graphen so verfolge sehe ich eine Verdopplung des IPv6 Traffics seit dem Anfang diesen Jahres beim HTTPS Traffic. SMTP ist es nur knapp 50% mehr. Ich würde nun jetzt einfach mal behaupten dass inzwischen viel mehr Enduser mit einer IPv6 Adresse unterwegs sind und Mailserverbetreiber so schnell nicht „nachziehen“.

Mich überrascht dieser starke Anstieg in 2017 etwas daher habe ich nun mal alles gegen meinen IPv4 Traffic gehalten.

Insg. habe ich von meinen Systemen ausgehend 12,5% mehr IPv6 Traffic als IPv4 Traffic. Eingehend habe ich tatsächlich 6% mehr IPv6 Traffic als IPv4 Traffic. OK OK jetzt bin ich dabei sicher nicht repräsentativ… Nur ist in 2017 das Verhältnis zumindest bei mir von IPv4 zu IPv6 gekippt. Jetzt sind alle Systeme bei mir durchgängig IPv6 fähig und alles bewegt sich sicher sehr in seiner eigenen Blase, nicht zu viel herein steigern…

Gab es da nicht vor Kurzem eine Heise Meldung?

https://www.heise.de/newsticker/meldung/IPv4-Adressen-immer-knapper-Adressklau-sogar-mit-gefaelschter-Sterbeurkunde-3872129.html

Schaue ich mir die großen an sieht man das es mehr wird und vor allem auch bei uns in Deutschland:

https://www.google.de/ipv6/statistics.html

https://stats.labs.apnic.net/ipv6

Mit einigen Bekannten habe ich ebenfalls gesprochen, hier zeigt sich ein sehr ähnliches Bild. Wir bleiben nur immer in der gleichen „Blase“. Mein Brötchengeber wäre noch ein ganz guter und sicher schon ein repräsentativ Statistikgeber, nur leider ist es hier produktiv noch extrem dunkel wenn es um IPv6 geht. 🙁 Hier gibt es gerade andere Baustellen.

Wie ist es denn bei euch? Jemand ein paar Zahlen oder Links für mich?

Update

Na schau an, eine erste Anregung habe ich schon mal. Mobile Endgeräte... Wenn man nicht gerade bei der Telekom ist sind viele noch mit ihren Smartphones auf IPv4 festgebunden. Statistiken von google/facebook/twitter usw. wird dieses sicher stark verfälschen. Wobei *grübel* verfälschen? Ist „das Internet“ (ich denke gerade an The IT Crowd) nicht inzwischen eher Smartphone? Benutzer mit einem Smartphone werden meine Webseite kaum anschauen, denn sie sieht mit so einem Gerät noch viel schlimmer aus als sie es bereits mit einem normalen Browser tut.

Siehe auch: IPv6 Grundlagen

Fragen? Einfach melden.

IPv6 – Bewerbung – Unitymedia

Das IPv6 eines meiner Lieblingsthemen ist muss ich ja keinem von euch erzählen. Auf das Thema bringt mich gerade sixxs. Die Jungs stellen nämlich ihren Service ein…. War ja fast zu erwarten! Sixxs kann sicher für sich behaupten eines der Projekte zu sein/gewesen zu sein welches extrem stark an der Verbreitung von IPv6 mitgewirkt hat!

Passend dazu saß ich vor kurzem in einem Bewerbungsgespräch irgendwann sind wir ebenfalls kurz auf das Thema IPv6 gekommen und da hat der Bewerber etwas gesagt was mir bis jetzt nicht mehr aus dem Kopf gegangen ist. Er sagt: „IPv6, ja… das war vor 5/6 Jahren mal so ein Hype, weil ja alle Adressen aufgebraucht sind, das ist aber inzwischen vorbei.“ Der Mann hat recht! OK, Adressen sind wirklich leer aber merkt man es denn wirklich? Also normaler User nicht. Von jedem gängigen ISP bekommt man IPv6 einfach in den Router geworfen und ob man jetzt noch eine „echte“ IPv4 Adresse hat oder man wie im Mobilfunk hinter einem carrier grade nat versteckt wird merken die normalen Nutzer eh nicht. Wenn man nicht gerade ein /24 haben will ist ebenfalls jeder DataCenterbetreiber oder Business ISP ohne großes hin und her gewillt einem das Netz zu geben. Selbst Unitymedia bekommt das hin!

Dabei kommt mit Unitymedia immer als der unprofessionellste Verein aller Zeiten vor. *kopfschüttel* Gut gut… Sie haben noch nicht SO viel Zeit als ISP verbracht wie der rosa Haufen. Habt ihr da mal versucht einen PTR Record zu setzen? Ach was schreib ich… Nicht setzten, setzten zu lassen?!?! Das geht per Fax. Echt jetzt PER FAX!!! Man bekommt so ein tolles PDF Formular OHNE Felder! Also so als PDF Bild zum Ausdrucken und dann muss man mit der Hand in so Kästchen seinen Wunsch PTR, die IP seine Kundennummer usw. eintragen und es dann zu ihnen zurück FAXEN. Nicht mal einscannen und E-Mail… Echt FAXEN! Jetzt ratet doch mal was passiert ist nachdem ich mein Fax mit 4 PTR Wünschen geschrieben habe? Richtig… Ich habe eine E-Mail vom Support bekommen, das sie leider nicht alles lesen konnten und ich das Fax doch bitte noch mal schicken solle *aaaarrrrggggghhhhh*

Siehe auch: IPv6 Grundlagen

Fragen? Einfach melden.

Die Jungs vom BSI und Nextcloud: Zusammenarbeit für mehr Sicherheit

Nextcloud hat sie die Mühe gemacht und mal nach owncloud und nextcloud Installationen gesucht. Dabei haben sie direkt mal geprüft wie sicher oder unsicher die wohl sind. Das hat seinen Weg zum BSI gefunden und die haben dann die abuse Adressen aller Netzbetreiber „gefüttert“.

Erstmal keine schlechte Idee. Natürlich will nextcloud was damit erreichen, das BSI macht auch brav mit super… Solange wir alle IPv4 machen läuft diese Version auch!

Oh ja, die abuse Mail:

Sehr geehrte Damen und Herren,
 
 ownCloud und Nextcloud sind Software-Lsungen zum Betrieb selbst
 gehosteter Cloud-Instanzen zur Synchronisation und zum Austausch
 von Daten.
 
 Das Unternehmen Nextcloud GmbH hat offen aus dem Internet
 erreichbare Installationen von ownCloud und Nextcloud geprft.
 Dabei wurden zahlreiche Cloud-Instanzen identifiziert, die mit
 veralteten Software-Versionen laufen, welche verschiedene
 Sicherheitslcken aufweisen.
 
 Angreifer knnen diese Schwachstellen ausnutzen, um unter anderem
 unberechtigt auf die in der Cloud gespeicherten Daten zuzugreifen.
 Dabei knnen die Angreifer ggf. sensible Informationen wie z.B.
 persnliche Dokumente, Fotos oder Kundendaten von Unternehmen
 aussphen und diese anschlieend im Internet verffentlichen oder
 fr kriminelle Zwecke wie Erpressungen nutzen.
 Andere Schwachstellen ermglichen Angreifern die Ausfhrung
 beliebigen Programmcodes auf dem Cloud-Server. Dies kann ggf.
 zu einer vollstndigen Kompromittierung des Systems und dessen
 Missbrauch fr weitere kriminelle Aktivitten fhren.
 
 Die Nextcloud GmbH hat CERT-Bund ihre Ergebnisse der Prfungen
 zur Untersttzung bei der Benachrichtigung betroffener Server-
 Betreiber bereitgestellt.
 
 Nachfolgend senden wir Ihnen eine Liste betroffener Systeme in
 Ihrem Netzbereich. Der Zeitstempel (Zeitzone UTC) gibt an, wann
 die verwundbare Cloud-Installation identifiziert wurde.
 Weiterhin sind fr jedes System eine Risikoeinstufung sowie eine
 eindeutige ID (UUID) angegeben.
 
 Die Nextcloud GmbH stellt unter folgender URL detaillierte
 Informationen zu den bei der jeweiligen Cloud-Instanz erkannten
 Schwachstellen und deren Behebung zur Verfgung:
 https://scan.nextcloud.com/results/[UUID]
 
 Der Parameter [UUID] muss dabei durch die zu der jeweiligen Instanz
 angegebene UUID ersetzt werden. Beispiel:
 https://scan.nextcloud.com/results/12345678-1234-1234-1234-12345678
 
 Wir mchten Sie bitten, den Sachverhalt zu prfen und Manahmen zur
 Aktualisierung der Cloud-Installationen auf den betroffenen Systemen
 zu ergreifen bzw. Ihre Kunden entsprechend zu informieren. Fr alle
 auf den betroffenen Systemen identifizierten Schwachstellen stehen
 entsprechende Sicherheitsupdates der Hersteller zur Verfgung.
 
 Bei Rckfragen zu den durchgefhrten Prfungen der Cloud-Instanzen
 wenden Sie sich bitte direkt an die Nextcloud GmbH unter
 <cloud-security-scan@nextcloud.com>.
 
 
 Diese E-Mail ist mittels PGP digital signiert.
 Informationen zu dem verwendeten Schlssel finden Sie unter
 <https://reports.cert-bund.de>.
 
 Bitte beachten Sie:
 Dies ist eine automatisch generierte Nachricht.
 An die Absenderadresse kann nicht geantwortet werden.
 Bei Rckfragen zu dieser Benachrichtigung wenden Sie sich bitte
 unter Beibehaltung der Ticketnummer in der Betreffzeile an
 <certbund@bsi.bund.de>.
 
 ======================================================================
 
 Betroffene Systeme in Ihrem Netzbereich:
 
 Format: ASN | IP | Timestamp (UTC) | UUID | Severity | Port | Hostname
  12345 | 1.2.3.4    | 2017-02-06 19:53:17 | 1ae3f7da-3367-4012-9382-7912dd4bd163 | high       | 80     | cloud.domain.de
  12345 | 1.2.3.5    | 2017-02-06 19:53:17 | 2e0a45fa-1568-458f-898e-2a888b44c9c6 | medium     | 80     | cloud.wurst.com
  12345 | 1.2.3.6    | 2017-02-06 19:53:17 | 32288a95-d396-4c9b-8998-d1968dc30ad7 | low        | 80     | cloud.alalaa.de 
  12345 | 1.2.3.7    | 2017-02-06 19:53:17 | ecfd4e62-b1b5-4c7d-b888-3f19ca3ca7ff | high       | 443    | cloud.butani.cn
  12345 | 1.2.3.8    | 2017-02-06 19:53:17 | 52ff7f71-c004-4a36-9975-2b5a99f280d6 | high       | 80     | cloud.bima.org
  12345 | 1.2.3.9    | 2017-02-06 19:53:17 | e388d8c5-4124-4af3-b052-57f77469783a | high       | 80     | cloud.2083a.net
  12345 | 1.2.3.10   | 2017-02-06 19:53:17 | 5cad0785-a6eb-47ca-aeec-6c4252928d13 | low        | 443    | cloud.lutzola.nl
  12345 | 1.2.3.11   | 2017-02-06 19:53:17 | 7da5d2dc-8556-4699-9ea4-7814c6afb8c0 | high       | 80     | cloud.weglaa.wu
  12345 | 1.2.3.12   | 2017-02-06 19:53:17 | adac575f-6a42-487d-a8c3-1b789ebafe39 | medium     | 80     | cloud.breck.aa
  [.....]

 
 Mit freundlichen Gren / Kind regards
 Team CERT-Bund
 
 Bundesamt fr Sicherheit in der Informationstechnik (BSI)
 Federal Office for Information Security
 Referat CK22 - CERT-Bund
 Godesberger Allee 185-189, D-53175 Bonn, Germany

Fragen? Einfach melden.

Anruf bei der G Data Hotline: Ein Erfahrungsbericht

Ich: tuuuuut…… tuuuuuut
Hotline: Bla gdata Hotline bla
Ich: Pffffhhhh
Hotline: *laala* (mucke)
Ich: Pffffhhhh
Hotline: Willkommen an der Hotline, mein Name ist Mann, was kann ich für sie tun?
Ich: Sie brauchen sicher meinen Benutzernamen, oder?

Das scheint da so etwas wie die Kundennummer in anderen Unternehmen zu sein….

Hotline: Oh ja, den nehme ich gerne.
Ich: Konrad-5-Julius-Heinrich-97- [Hotlinemann unterbricht mich]
Hotline: Konrad ausgeschrieben?
Ich: Öhm ähh ne also öh der Buchstabe?!?
Hotline: OK
Ich: Kundenummer…
Hotline: und was kann ich nun für sie tun?
Ich: Wir testen gerade die Amavis Integration eurer G DATA Business Lösung und das läuft nicht ganz rund.
Hotline: uhhaaa ohh
Ich: Warum uhaaa ohh?
Hotline: Öhm (hehe) also ähh, da bekommen wir eher weniger Anfragen. Wird nicht so oft benutzt.
Ich: Na aber ihr verkauft das ja.
Hotline: Ja aber ähh gut.


Dann wurden Version und OS abgefragt und ein Ticket angelegt. Ich sollte mal Auszüge aus dem Maillog senden. irgendwie habe ich das Gefühl als wenn das gerade nix wird.

Für Spaß auch mal die Logfiles:

Feb  7 08:27:54 mx amavis[27217]: (21323-04-4) (!)run_command: child process [27217]: Insecure dependency in exec while running with -T switch at /usr/sbin/amavisd-new line 4743.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-4) (!!)collect_results from [27217] (/usr/bin/gdmailscannerc): exit 3 Feb  7 08:27:54 mx amavis[21323]: (21323-04-4) (!)checking with spam scanner GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-4) (!!)TROUBLE in check_mail: spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-4) (!)PRESERVING EVIDENCE in /var/lib/amavis/tmp/amavis-20170207T082744-21323-gFK_Ofar
Feb  7 08:27:54 mx postfix/smtp[27003]: EFA15C0A13: to=<type@domain.de>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=4, delay=85234, delays=85181/42/0/10, dsn=4.5.0, status=deferred (host 127.0.0.1[127.0.0.1] said: 451 4.5.0 Error in processing, id=21323-04-4, spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159. (in reply to end of DATA command)) Feb  7 08:27:54 mx amavis[27219]: (21323-04-5) (!)run_command: child process [27219]: Insecure dependency in exec while running with -T switch at /usr/sbin/amavisd-new line 4743.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-5) (!)run_av (GDAVCLIENTC SCANNER.) FAILED - unexpected , output=""
Feb  7 08:27:54 mx amavis[21323]: (21323-04-5) (!)GDAVCLIENTC SCANNER. av-scanner FAILED: CODE(0x2cc4260) unexpected , output="" at (eval 97) line 905.
Feb  7 08:27:54 mx amavis[21323]: (21323-04-5) (!)WARN: all primary virus scanners failed, considering backups Feb  7 08:27:54 mx amavis[27221]: (20783-09-4) (!)run_command: child process [27221]: Insecure dependency in exec while running with -T switch at /usr/sbin/amavisd-new line 4743.
Feb  7 08:27:54 mx amavis[20783]: (20783-09-4) (!!)collect_results from [27221] (/usr/bin/gdmailscannerc): exit 3 Feb  7 08:27:54 mx amavis[20783]: (20783-09-4) (!)checking with spam scanner GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158.
Feb  7 08:27:54 mx amavis[20783]: (20783-09-4) (!!)TROUBLE in check_mail: spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159.
Feb  7 08:27:54 mx amavis[20783]: (20783-09-4) (!)PRESERVING EVIDENCE in /var/lib/amavis/tmp/amavis-20170207T082744-20783-75UHo67I
Feb  7 08:27:54 mx postfix/smtp[27159]: D74F7C00F4: to=<type@domain.de>, relay=127.0.0.1[127.0.0.1]:10024, conn_use=4, delay=342238, delays=342185/42/0/10, dsn=4.5.0, status=deferred (host 127.0.0.1[127.0.0.1] said: 451 4.5.0 Error in processing, id=20783-09-4, spam_scan FAILED: GDATA_SPAM_SCANNER failed: GdataSpamScanner: Failed processing request; illegal response(%d) at /usr/local/lib/site_perl/Amavis/SpamControl/GdataSpamScanner.pm line 158. at (eval 98) line 159. (in reply to end of DATA command)) Feb  7 08:27:55 mx amavis[20783]: (20783-09-5) Passed CLEAN {RelayedInbound}, SPAM_DISC [1.2.3.4]:44419 [1.2.3.4] <type@domain.de> -> <type@domain.de>, Queue-ID: 6D65CC0A33, Message-ID: <62734015.3835.1486452455492.JavaMail@domain.de>, mail_id: lsOZOYNAIa3o, Hits: 0, size: 44774, queued_as: 57B04C0A40, 471 ms

Feb  7 09:55:25 mx amavis[22893]: (22893-07) Passed CLEAN {RelayedInbound}, SPAM_DISC [1.2.32.4]:36945 [1.5.7.98] <type@domain.de> -> <type@domain.de>, Queue-ID: E7592C0071, Message-ID: <20170207085513.B8A52340881@domain.de>, mail_id: 3lhpfBFnyuAI, Hits: 0, size: 4172, queued_as: 1F499C00F7, 10166 ms Feb  7 09:55:25 mx amavis[20843]: (20843-14) (!)run_av (GDAVCLIENTC SCANNER.) FAILED - unexpected , output="SKIP"
Feb  7 09:55:25 mx amavis[20843]: (20843-14) (!)GDAVCLIENTC SCANNER. av-scanner FAILED: CODE(0x2cc4260) unexpected , output="SKIP" at (eval 97) line 905.
Feb  7 09:55:25 mx amavis[20843]: (20843-14) (!)WARN: all primary virus scanners failed, considering backups

Fragen? Einfach melden.

Eigene DNS-Blocklisten in Postfix: DNSRBL und RHSBL einrichten

Postfix kann eingehende Mails anhand von DNS-basierten Blocklisten ablehnen. Zwei Typen sind relevant: DNSRBL (IP-basiert) prüft ob die sendende IP-Adresse auf einer Blockliste steht. RHSBL (Domain-basiert) prüft ob die Absenderdomain gelistet ist. Beides passiert in Echtzeit während der SMTP-Sitzung, noch bevor die Mail angenommen wird.

Öffentliche Listen

Es gibt dutzende öffentliche Blocklisten. Nicht alle sind gleich zuverlässig. Diese hier laufen bei mir seit Jahren ohne nennenswerte False Positives:

# /etc/postfix/main.cf (Auszug)
smtpd_recipient_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_unauth_destination,
   reject_rbl_client zen.spamhaus.org,
   reject_rbl_client bl.spamcop.net,
   reject_rbl_client b.barracudacentral.org,
   reject_rbl_client ix.dnsbl.manitu.net,
   permit

zen.spamhaus.org ist die Kombiliste von Spamhaus (SBL + XBL + PBL). ix.dnsbl.manitu.net wird in Deutschland gepflegt und erwischt deutschsprachigen Spam den internationale Listen übersehen.

Eigene Listen

Zusätzlich betreibe ich eigene Blocklisten unter kernel-error.de. Die werden teils von Hand gepflegt, teils automatisch aus einem Honeypot-Postfach befüllt. Einträge bleiben mindestens sechs Monate drin:

# Eigene Listen (RHSBL + RBL)
reject_rhsbl_sender abuse.rhsbl.kernel-error.de,
reject_rhsbl_sender postmaster.rhsbl.kernel-error.de,
reject_rhsbl_sender spam.rhsbl.kernel-error.de,
reject_rbl_client spam.rbl.kernel-error.de,

Die RHSBL-Listen prüfen die Absenderdomain: abuse listet Domains ohne funktionierende abuse-Adresse, postmaster solche ohne postmaster-Adresse, spam bekannte Spam-Domains. Die RBL-Liste prüft die IP-Adresse des sendenden Servers.

Warnung

Das sind meine privaten Listen. Ich pflege sie nach meiner persönlichen Einschätzung. Wer sie produktiv einsetzt, macht das auf eigene Verantwortung. Es wird zu False Positives kommen, weil meine Kriterien nicht mit den eigenen übereinstimmen müssen. Für den eigenen Mailserver sind sie ein nützlicher Baustein neben den öffentlichen Listen. Für fremde Mailserver würde ich sie nicht empfehlen.

Wer seinen Postfix weiter absichern will: Die HELO-Prüfung fängt einen erstaunlichen Anteil an Spam ab, bevor die RBL-Abfrage überhaupt nötig wird. Fragen? Einfach melden.

TLSA verkackt: Wenn man nach dem Zertifikatstausch den DNS-Record vergisst

Da kommt folgende Mail rein:

Hi,
mein Firefox Plugin und hash-slinger sagen beide, dass dein TLSA Record für
munin.kernel-error.com
kaputt ist.

Gruß
Andreas

Recht hat der Mann. Ich hatte das Zertifikat getauscht (auf Elliptic Curve umgestellt) und vergessen, den TLSA-Record im DNS zu aktualisieren. Klassiker. Der TLSA-Record enthält einen Hash des Zertifikats. Tauscht man das Zertifikat, stimmt der Hash nicht mehr, und jeder Client der DANE prüft sieht einen Fehler.

Passiert schneller als man denkt, besonders wenn man mehrere Dienste auf verschiedenen Subdomains hat. Jeder braucht seinen eigenen TLSA-Record. Zertifikat erneuern, TLSA vergessen, niemand merkt es (weil kaum jemand DANE validiert). Bis jemand wie Andreas mit dem Firefox-Plugin vorbeikommt.

Die Lektion: Nach jedem Zertifikatstausch die TLSA-Records prüfen. Am besten automatisiert, zum Beispiel per Skript das nach dem ACME-Renewal den Hash berechnet und den DNS aktualisiert. Wer TLSA-Records von Hand prüfen will, findet die Anleitung unter TLSA/DANE manuell prüfen. Die Grundlagen zu DANE stehen im Beitrag DNSSEC und DANE. Fragen? Einfach melden.

Firefox OCSP-Stapling Fehler bei StartSSL beheben

Veraltet: StartSSL wurde 2017 von allen Browsern als nicht mehr vertrauenswürdig eingestuft und hat den Betrieb eingestellt. OCSP Stapling ist weiterhin relevant, aber die hier beschriebene Fehlerursache (StartSSL OCSP-Responder) existiert nicht mehr.

Natürlich ist bei mir OCSP Stapling am Apache 2.4 aktiviert…. Doch plötzlich zeigt mir meine Webseite beim Besuch mit dem Mozilla Firefox folgende Fehlermeldung:

Secure Connection Failed

An error occurred during a connection to www.kernel-error.de. The OCSP server suggests trying again later. (Error code: sec_error_ocsp_try_server_later)

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.

Im Error Log des Webservers finden sich zur gleichen Zeit Logmeldungen wie:

[Mon Aug 10 07:06:28.572899 2015] [ssl:error] [pid 23648] (70007)The timeout specified has expired: [client 1.2.3.4:23726] AH01977: failed reading line from OCSP server
[Mon Aug 10 07:06:28.572924 2015] [ssl:error] [pid 23648] [client 1.2.3.4:23726] AH01980: bad response from OCSP server: (none)
[Mon Aug 10 07:06:28.572950 2015] [ssl:error] [pid 23648] AH01941: stapling_renew_response: responder error

Ahja… bad response from OCSP Server…. Habe ich nun irgendwo Mist konfiguriert oder hat wirklich der OCSP Server meiner CA StartSSL / StartCOM ein Problem? Mein Verdacht ist natürlich, dass es an der CA liegen muss. ;-P

Am schnellsten Teste ich es einmal von Hand auf meinem Client. Ist hier das gleiche Problem, liegt es sicher an der CA. Wie also manuell per openssl testen ob der OCSP Server tut was er will? Ganz einfach, so:

Als erstes einmal den öffentlichen Teil meines Zertifikates herunterladen und in einer Datei speichern:

# openssl s_client -connect www.kernel-error.de:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > www.kernel-error.de.pem

Jetzt das Intermediate besorgen. Dieses sollte ja ebenfalls mein Server senden, also hole ich es von dort. Dabei ist hier nun etwas copy & paste Arbeit nötig. Folgendes wirft mir einiges um die Ohren:

# openssl s_client -connect www.kernel-error.de:443 -showcerts 2>&1 < /dev/null

Hier ist kopiere ich mir nun das Intermediate Zertifikat heraus in das File interm.pem. Spannend ist dabei das Zertifikat zu:

 1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 2 Primary Intermediate Server CA
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
-----BEGIN CERTIFICATE-----
MIIGNDCCBBygAwIBAgIBGzANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEW

Dabei alles ab —–BEGIN CERTIFICATE—– bis einschließlich —–END CERTIFICATE—–

In meinem Zertifikat sollte der OCSP Server meiner CA hinterlegt sein. Diesen lasse ich mir nun mit folgendem Befehl ausgeben:

# openssl x509 -noout -ocsp_uri -in www.kernel-error.de.pem
http://ocsp.startssl.com/sub/class2/server/ca

Perfekt… Nun habe ich alle Informationen zusammen um einen manuellen Test gegen den OCSP Server meiner CA zu fahren:

# openssl ocsp -issuer interm.pem -cert www.kernel-error.de.pem -text -url http://ocsp.startssl.com/sub/class2/server/ca
OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: B9B2D56DB021B36E42F627245806C4A9A6979AEB
          Issuer Key Hash: 11DB2345FD54CC6A716F848A03D7BEF7012F2686
          Serial Number: 06D8F968657B18
    Request Extensions:
        OCSP Nonce: 
            04109228F685EAF4211B1A6D6CCF67AD9CC9
Error querying OCSP responder
34379249832:error:27076072:OCSP routines:PARSE_HTTP_LINE1:server response error:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/ocsp/ocsp_ht.c:255:Code=400,Reason=Bad Request

Hm… Sehr eindeutig, oder? Es scheint also wirklich ein Problem am Server der CA zu geben. Eine kurze E-Mail an die CA später habe ich, auf die Frage ob es ein Problem mit dem OCSP Server gibt, die folgende Antwort in meinem Postfach:

Yes. It would be fixed asap.

-- 
Regards
 
Signer:  	Kirill Ivanov, VO
  	StartCom Ltd.

Na wunderbar… Damit schalte ich also OCSP Stapling mal wieder aus, bis meine CA wieder korrekt arbeitet!

SSLUseStapling Off

Bis spööööter 😀

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑