-=Kernel-Error=-

Datenhaufen zu IT und Elektronik.

Autor: Sebastian van de Meer (Seite 22 von 49)

Openfire unsichere Cipher und Protokolle deaktivieren

6. Februar 2015 / / Keine Kommentare

Der Jabber/XMPP Server von Ignite Realtime, Openfire ist ein ganz nettes System. Leider ist das Thema Sicherheit noch nicht ganz in der aktuellen Version angekommen. Bei den Entwicklern schon. In den aktuellen Nightly Builds sind bereits die „unsichern“ Protokolle und cipher im Default aus. In der Beta geht es so… Die aktuelle stable Openfire Version 3.9.3 bietet leider weder etwas einstellbares, noch eine zufriedenstellende standard Konfiguration.

Sucht man nun im Internet nach: „how to disable weak ciphers“ in Verbindung mit Openfire findet man derzeit nur viele Menschen, welche auf der Suche nach einer gangbaren Lösung sind. Leider finden sich kaum welche 🙁

Eine Lösung möchte ich hier kurz vorstellen….

Openfire basiert auf Java. Ab Oracle Java 8 gibt es eines hier Möglichkeiten die Protokolle und Cipher zu deaktivieren, welche nicht genutzt werden sollen.

Wenn ich also von einem Debian oder Ubuntu System ausgehe und ich hinsichtlich Java nur über Openfire nachdenken muss, lässt sich mit folgender Konfiguration von Oracle Java 8 ein brauchbares Ergebnis erzielen.

In der Konfigurationsdatei: /usr/lib/jvm/java-8-oracle/jre/lib/security/java.security sollten folgende zwei Optionen gesetzte werden. Dabei ist natürlich darauf zu achten, dass sie nicht noch einmal in der Konfiguration vorkommen 😉

# Example:
#   jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 2048
#
#
jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024

# Example:
#   jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048
jdk.tls.disabledAlgorithms=SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA, SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_WITH_3DES_EDE_CBC_SHA, SSL_DH_anon_WITH_DES_CBC_SHA, SSL_DH_anon_WITH_RC4_128_MD5, SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DH_DSS_WITH_DES_CBC_SHA, SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DH_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA, SSL_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_RC4_128_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_FORTEZZA_DMS_WITH_FORTEZZA_CBC_SHA, SSL_FORTEZZA_DMS_WITH_NULL_SHA, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA, SSL_RSA_EXPORT1024_WITH_RC4_56_SHA, SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_FIPS_WITH_DES_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_RSA_WITH_IDEA_CBC_SHA, SSL_RSA_WITH_NULL_MD5, SSL_RSA_WITH_NULL_SHA, SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_WITH_RC4_128_MD5, SSL_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA, SSL_DHE_DSS_WITH_RC4_128_SHA, TLS_DHE_PSK_WITH_RC4_128_SHA, TLS_ECDH_anon_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_PSK_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_MD5, TLS_KRB5_EXPORT_WITH_RC4_40_SHA, TLS_KRB5_WITH_RC4_128_MD5, TLS_KRB5_WITH_RC4_128_SHA, TLS_PSK_WITH_RC4_128_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT1024_WITH_RC4_56_SHA, TLS_RSA_PSK_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSLv3

Damit wird SSLv3 deaktiviert, MD5 sowie RC4 werden ebenso wie einige recht schlechte Cipher nicht weiter verwendet. Mehr Informationen erhält man über die Schlagwörter: Java8 Algorithm restrictions for Secure Socket Layer/Transport Layer Security processing sowie Java8 Algorithm restrictions for certification path processing

Ein Starten und Stoppen des Openfire sollte diese Einstellungen nun aktivieren. In diesem Zusammenhang sollte natürlich noch auf die JCE Unlimited Strength Jurisdiction Policy Files geachtet werden. Diese ermöglichen höhere Bit-Stärken als 128!

>>Openfire AES 256 und JCE Unlimited Strength Jurisdiction Policy Files<<

Damit lassen sich nun mit dem IM Observatory für Client und Server folgende Ergebnise / Reports erzielen:

IM Observatory client report for jabber.kernel-error.de
https://xmpp.net/result.php?id=115781

IM Observatory server report for jabber.kernel-error.de
https://xmpp.net/result.php?id=115782

Noch Fragen?

Postfix: Serverzertifikat nicht verifiziert – Fehlerbehebung

2. Februar 2015 / / Keine Kommentare

Da bekomme ich doch gerade eine E-Mail zurück mit der Begründung:

Reporting-MTA: dns; smtp.kernel-error.de
X-Postfix-Queue-ID: 30E4E7461347
X-Postfix-Sender: rfc822; kernel-error@kernel-error.com
Arrival-Date: Wed, 28 Jan 2015 11:50:00 +0100 (CET)

Final-Recipient: rfc822; mailer@domain.tld
Original-Recipient: rfc822;mailer@domain.tld
Action: failed
Status: 4.7.5
Diagnostic-Code: X-Postfix; Server certificate not verified

Dazu passend findet sich im Postfix Logfile folgendes:

Feb  2 12:15:21 postfix/smtp[1520]: Trusted TLS connection established to domain.tld[2001:1111:1:1111::1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb  2 12:15:21 postfix/smtp[1520]: 30E4E7461347: Server certificate not verified
Feb  2 12:15:22 postfix/smtp[1520]: Trusted TLS connection established to domain.tld[1.2.3.4]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb  2 12:15:22 postfix/smtp[1520]: 30E4E7461347: to=<mailer@domain.tld>, relay=domain.tld[1.2.3.4]:25, delay=433522, delays=433521/0.09/0.63/0, dsn=4.7.5, status=deferred (Server certificate not verified)

Na? Schon eine Idee? Erst soll die TLS Verbindung trusted sein und dann doch wieder nicht? Ganz einfach 🙂 Es ist DANE…. Postfix würde ja selbst eine E-Mail zustellen, wenn er das Zertifikat nicht prüfen könnte. Hat der Empfänger aber einen TLSA-Record für sein Mailserver Zertifikat veröffentlicht und Postfix prüft dieses mit negativem Ergebnis, dann kann man wohl davon ausgehen, dass da etwas nicht stimmt. Entweder der Empfänger hat ein Problem mit seiner Konfiguration oder es versucht sich gerade jemand „dazwischen“ zu drängen.

Weiter prüfen konnte ich es mit posttls-finger:

$ posttls-finger -t30 -T180 -c -L verbose,summary domain.tld
posttls-finger: initializing the client-side TLS engine
posttls-finger: using DANE RR: _25._tcp.domain.tld IN TLSA 3 0 1 B3:E7:94:4A:CE:14:0D:CE:53:08:C6:D8:A5:D3:8C:EE:DD:94:FC:8A:B4:DD:8E:DD:DD:DD:DD:DD:DD:DD:DD:DD
posttls-finger: setting up TLS connection to domain.tld[2001:1111:1:1111::1]:25
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL"
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: depth=1 verify=0 subject=/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: depth=0 verify=1 subject=/C=DE/CN=www.domain.tld/emailAddress=hostmaster@domain.tld
posttls-finger: domain.tld[2001:1111:1:1111::1]:25: subject_CN=www.domain.tld, issuer_CN=StartCom Class 1 Primary Intermediate Server CA, fingerprint=65:76:45:E3:50:1A:54:5D:BE:30:8F:DD:DD:DD:DD:DD:DD:DD:DD:DD, pkey_fingerprint=63:53:F8:60:76:8D:01:E8:57:93:EA:3C:DD:DD:DD:DD:DD:DD:DD:DD
posttls-finger: Untrusted TLS connection established to domain.tld[2001:1111:1:1111::1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Passt also wirklich nicht… Gleicher Test auf verschiedenen Systemen, gleiches Ergebnis. Ebenfalls die einschlägigen Webseiten bringen diese Meldung (https://de.ssl-tools.net/mailservers/).

Ich muss zugeben, ist eine Premiere für mich. Also ein wirklich echt fehlgeschlagener DANE Test von Postfix, welcher die Mailzustellung verhindert hat. Natürlich hat postfix nicht nach dem ersten Versuch aufgegben, diese Prüfung führt zu einem temporären Fehler der 4xx Reihe. Postfix versucht es also ein paar Tage. In meinem Fall hat also alles genau so funktioniert, wie ich es mir gewünscht habe. Postfix testet die TLSA-Records, bemerkt einen Fehler, logt diese und probiert es noch einmal. Der Fehler bestand dauerhaft und Postfix gab mir die Mail zurück, mit der Info das etwas mit dem Zertifikat des Empfängers nicht stimmt. Das hat Postfix wirklich gut gemacht *tätschel*

So long…

Thunderbird Filelink und owncloud / nextcloud

2. Februar 2015 / / Keine Kommentare

Inzwischen hat ja fast jeder bei uns „schnelles“ Internet…. So lassen sich per E-Mail auch mal etwas größere Dateien verschicken. Dennoch sollte man so ab 5MB ein schlechtes Gefühl haben und sich ab 10MB Anhängen nicht mehr über abgewiesene E-Mails ärgern.

Das Problem mit großen Dateianhängen bei E-Mails ist ja nicht nur die Verstopfung der Leitungen… Mailserver arbeiten sich daran ab, der absendende und empfangende Client ebenfalls. Hängt dann noch ein Virenscanner dazwischen rechnet noch jemand. Dann liegt die Datei auf dem System des Absenders, in dessen Postfach, im Postfach dem Empfängers und natürlich noch auf dem System des Empfängers. Bei einem 500MB Anhang sind das schon mal 2GB für nix.

Inzwischen gibt es 1000 Möglichkeiten um große Dateien schnell und einfach auszutauschen. Selbst ohne seine Daten auf irgendeinen Server bei irgendeinem Anbieter zu legen. So zum Beispiel über owncloud….. Hochladen muss man die Datei ja in jedem Fall zu seinem Mailserver, warum also nicht lieber in die „Cloud“? Ok, es ist etwas aufwendig. Erst hochladen, dann teilen, dann den Link kopieren und in die E-Mail packen, usw. usw…

Für Anwender des Mailclients Thunderbird gibt es in diesem Zusammenhang eine noch schönere Lösung. Sie nennt sich filelink. Im Grunde nichts weiter als eine kleine Funktion, welche dem Anwender etwas Arbeit abnimmt!

Hängt der Anwender eine Datei an seine E-Mail an, welche einen einstellbaren Schwellwert überschreitet, schlägt Thunderbird diesem vor, den Anhang für den Anwender in einen dieser „Austauschservices“ zu laden. Stimmt der Anwender zu, schiebt Thunderbird die Datei hoch und verlinkt sie automatisch in den E-Mail Body. Dieses hält die E-Mai klein und der Empfänger kann selbst entscheiden, ob und wann er den „Anhang“ herunterladen möchte.

Aktuell bringt Thunderbird aus dem Karton leider nur die Verknüpfung zu den bekannten großen Anbietern wie z.B.: dopbox mit. Dort möchte man ja nicht unbedingt seine Daten ablegen. Für owncloud habe ich vor kurzem eine gut funktionierendes Thunderbird Plugin gefunden:

https://github.com/guillaumev/owncloud_for_filelink

Einfach herunterladen, installieren, zwei drei Kleinigkeiten in der eigenen Cloud einstellen und glücklich sein 🙂 Mit zwei/drei erklärenden Sätzen in der E-Mail versteht es zudem fast jeder Empfänger. Noch Fragen?

PC-BSD 10 / FreeBSD und der Brenner geht nicht…

21. Januar 2015 / / Keine Kommentare

Ich experimentiere in der letzten Zeit etwas mehr mit PC-BSD herum und so langsam verdrängt es sogar seinen Vater FreeBSD von meinem Desktop….

Der angenehme Vorteil von PC-BSD ist, dass es bereits viele Kleinigkeiten für den Desktopeinsatz „fertig“ vorhält. Man muss nicht erste jede Kleinigkeit selbst konfigurieren (ich werde SO faul). Der Nachteil ist, man lernt nix mehr 🙁 Wie auch immer…

Ich wollte gerade eine CD brennen, starte mein xfburn und dieses erzählt mir es könne keinen Brenner finden oder die Berechtigungen würden nicht stimmen.

** (xfburn:12447): WARNING **: No drives were found! If this is in error, check the permissions

Nanu?!?! Als erstes wollte ich die Berechtigungen ausschließen:

$ pc-su xfburn
Passwort:** Message: Using elementar transcoder.

Brennen klappt… Also wirklich ein Problem mit den Berechtigungen. Dann schauen wir sie uns mal durch..

Der Brenner ist im Notebook das Device /dev/cd0 mal sehen…

$ ls -lisa /dev/cd0
105 0 crw-rw-rw-  1 root  operator  0x69 21 Jan 07:40 /dev/cd0

Sieht doch gut aus… Viele Anwendungen nutzen aber einen Link um auf das jeweilige Laufwerk zuzugreifen, auch wenn es der Brenner nicht tun sollte, denn… (dazu später)… mal schauen und gelesen haben stört aber nicht 🙂

$ ls -lisa /dev/cdrom
131 0 lrw-rw-rw-  1 root  wheel  3 21 Jan 07:43 /dev/cdrom -> cd0
$ ls -lisa /dev/dvd
132 0 lrw-rw-rw-  1 root  wheel  3 21 Jan 07:43 /dev/dvd -> cd0

Pass bei mir aber auch, sollte es nicht passen hilft bei Symlinks ein chmod -h 0666…. Nur würde es beim Problem mit dem Brenner nicht helfen! Warum? Nun ja, wer sich an „früher“ unter Linux erinnert, da musste man auch ein Modul laden, welches aus dem ATA Brenner einen SCSI Brenner für den Kernel macht. Funktioniert noch immer ähnlich, ist aber inzwischen im Linux Kernel verklappt. Unter BSD muss man noch immer dafür sorgen. Dafür müssen in der Datei /boot/loader.conf folgende Einträge erstellt werden:

atapicam_load="YES" 
hw.ata.atapi_dma="1"

Der erste Eintrag sorgt dafür, dass der ATA Brenner als „SCSI“ Laufwerk ~erkannt~ wird, der zweite aktiviert den DMA Zugriff auf ATA Laufwerke. Ich meine dass im Kernel vom PC-BSD bereits per Default DMA für ATA Geräte aktiviert ist, schadet aber nicht! Ach ja, in meiner PC-BSD loader.conf gab es den nötigen Eintrag bereits. Es war also schon richtig, denn noch ging es nicht 🙁

Macht nix, weiter suchen! Ist das Modul geladen, sollte mir camcontrol nun meine ATA Geräte auflisten können, inkl. deren SCSI ID und dem zugehörigen passthrue Device:

$ camcontrol devlist
<ST500LM000-1EJ162 DEM8>           at scbus0 target 0 lun 0 (ada0,pass0)
<TSSTcorp DVD+-RW SU-208CB D200>   at scbus1 target 0 lun 0 (cd0,pass1)
<AHCI SGPIO Enclosure 1.00 0001>   at scbus4 target 0 lun 0 (ses0,pass2)

Perfekt…

cd0 stimmt, habe ich bereits kontrolliert. pass1? Mal sehen:

$ ls -lisa /dev/pass1
76 0 crw-------  1 root  operator  0x4c Jan 21 07:40 /dev/pass1

Na schau mal einer an 😀 Zum Test setzte ich mal passende Rechte auf das Device und starte dann als User mein Brennprogramm.

$ chmod 0666 /dev/pass1

Geht… Dann soll es so bleiben! Nach einem Reboot wären meine vergebenen Rechte wieder weg. Damit diese bleiben muss ich meinen Wunsch in der Datei /dev/devfs.conf hinterlegen. Ein Blick in diese verrät mit, dass sich schon jemand Gedanken gemacht hat (pc-bsd halt…). So sind bereits passende Rechte für das Gerät /dev/pass0 gesetzt. Nur eben nicht für /dev/pass1. Es lässt sich also einfach der Eintrag von pass0 für pass1 kopieren:

/etc/devfs.conf
....
# Commonly used by many ports 
link    cd0     cdrom 
link    cd0     dvd 
....
# Allow all users to access CD's  
perm    /dev/acd0       0666 
perm    /dev/cd0        0666 
....
# Misc other devices 
own     /dev/lpt0       root:cups
perm    /dev/lpt0       0666
own     /dev/lpt1       root:cups
perm    /dev/lpt1       0666
perm    /dev/pass0      0666
perm    /dev/pass1      0666 
....

Nur ein Detail welches noch beim PC-BSD fehlt um es für den Benutzer beim Brennen noch einfacher zu machen. Wenn auch ein Detail, was Benutzer ohne FreeBSD Vorkentnisse ins Straucheln bringen könnte.

In diesem Sinne….

DNSSEC, DANE und TLSA mit Postfix: Hintergründe und aktuelle Probleme

16. Januar 2015 / / Keine Kommentare

Man man man… Was ist denn da passiert? Seit 3 oder 4 Tagen scheint das Thema im Internet irgendwie besonders aktiv zu sein, oder? Nur warum?!?!

Plötzlich bekomme ich nicht nur jeden Tag einen Haufen Anfragen zu dem Thema, viel scheinen auch irgendwas testen zu wollen und pumpen E-Mails mit Random-Empfängern an meine Domains….

Im Grunde habe ich ja nichts gegen Tests. Nur grob abgesprochen wäre schon schön, mein Monitoring wird sonst immer so „wuschig“! 😀

Um noch mal ein paar Themen zusammen zu fassen:

1. Basis von allem ist DNSsec
2. TLSA Records „ist DANE“
3. Postfix kann TLSA Records auswerden, ohne selbst welche für sein System zu haben.

Mein kleines DNSSEC Howto

DNSSEC und DNS-based Authentication of Named Entities (DANE)

Postfix SSL/TLS gesichert mit TLSA / DANE und DNSSEC

DNSSEC fähiger Registrar

TLSA / DANE RECORD von Hand manuel prüfen.

So long…

Mal wieder auffällig viele Brute-Force SSH Angriffe….

11. Januar 2015 / / Keine Kommentare

Seit gestern fällt es irgendwie auf… Da rattert wieder etwas über die Systeme 😀

Probiert werden die User:

– root
– admin
– mail
– Alphanetworks
– MANAGER
– test
– Factory
– vodafone
– telecomadmin
– draytek
– super
– FIELD
– ADVMAIL
– WP
– HELLO
– citel
– SPOOLMAN
– comcast
– wlseuser
– OPERATOR
– PCUSER
– MGR
– patrol
– netadmin
– anonymous
– craft
– websecadm
– netman
– MD110
– supervisor
– tiger
– manuf
– PBX
– NETWORK
– MDaemon
– readonly
– davox
– scout
– blank
– coress
– usw. usw. usw…..

Spannenderweise mit immer neuen Adressen aus verschiedenen großen Netzen. Im groben lässt es sich „eindampfen“ auf:

– 117.253.0.0/16
– 109.161.236.0/22
– 189.51.16.0/20

Hier und da noch etwas verteiltes… Indien, Brasilien, Italien, wenn man dem WHOIS trauen kann 😛 Was da wieder los ist? Dann wird wohl bald wieder mehr Spam kommen, hm?

Ich wünsche in jedem Fall ein paar klebrige Finger!

Jan 11 11:42:53 ssh-honeypot sshd[21822]: Invalid user MANAGER from 182.74.23.34
Jan 11 11:42:53 ssh-honeypot sshd[21822]: input_userauth_request: invalid user MANAGER [preauth]
Jan 11 11:42:56 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:42:58 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:01 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:03 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:05 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:08 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2

IPv6 Buch von Jens Link

5. Januar 2015 / / Keine Kommentare

Ich räume gerade etwas auf und da finde ich einen Merker für das IPv6 Buch von Jens Link…. Eigentlich etwas dass ich mir in den „Schrank“ stellen wollte. Leider scheint es noch immer nicht kaufbar 🙁 So als einfaches „Einsteigerbüchlein“ schien es mir perfekt. Schade… Werde es dann wohl mal aus meiner Merkliste löschen.

http://www.amazon.de/IPv6-Planung-Umstieg-Jens-Link/dp/3937514899

Komisch, oder?

So long…

Abwasserrohr

5. Januar 2015 / / Keine Kommentare

Mal etwas ganz anderes…. Keine Ahnung was ihr so zwischen den Feiertagen macht, ich repariere kaputte Abwasserrohre. Mit Vorliebe hinter der Dusche!

Nein, Scherz! Zumindest zum Teil… Irgendwas machte seit kurzem hinter der Dusche meiner Kinder „Probleme“. Irgendwo in der Wand war etwas undicht. Zwischen den Feiertagen hatte ich Zeit, so zumindest die Einschätzung meiner Frau 😛

Also habe ich alles auf gestemmt und ganz zuletzt das Problem gefunden. Das Abwasserrohr vom Waschbecken war dort undicht. Getauscht und jetzt muss ich wohl eine neue Dusche bauen, TOP.

Es will nicht zufällig jemand helfen?

Postfix: TLS-Protokoll und Cipher-Infos im E-Mail-Header anzeigen​

17. Dezember 2014 / / Keine Kommentare

Als kleiner Postfix Tipp am Rande…. Wenn man gerade mit seinen TLS Einstellungen „herumspielt“, kann es helfen die groben Informationen für jede E-Mail nicht immer aus dem Logfile sammeln zu müssen.

Postfix bietet die schnelle Möglichkeit, genau diese Informationen einfach mit in den Mail Header zu packen.

Folgende Konfigurationserweiterung ist dafür nötig:

/etc/postfix/main.cf:
smtpd_tls_received_header = yes

Ab diesem Moment finden sich Informationen wie die unten stehende in eingehenden E-Mails.

So long….

Received: from mx01.domain.de (mx01.domain.de [1.2.3.4])
    (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits))
    (No client certificate requested)
    by smtp.kernel-error.de (Postfix) with ESMTPS id 245478112D9
    for <kernel-error@kernel-error.com>; Wed, 17 Dec 2014 05:15:10 +0100 (CET)

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑