Datenhaufen zu IT und Elektronik.

Kategorie: IT-Security (Seite 6 von 15)

Notizen & Praxis zur IT-Sicherheit – von Responsible Disclosure bis Härtung.

Postfix MTA-STS Resolver für FreeBSD mit Logfile einrichten

Ich habe heute auch mal den postfix-mta-sts-resolver auf meinem privaten System zugeschaltet. Einfach um es mal zu „probieren“.

Tut einfach und wie beschrieben, ist so aber sicher nicht für größeren und produktiven Betrieb gedacht. So wie der resolver kommt schreibt er alle Meldungen leider nur in die Konsole, es gibt keinen File-Logger. Ich ähm will/brauch den aber!

Also habe ich einen Fork erstellt und ihn überredet in eine Datei zu loggen und direkt noch ein sehr rudimentäres rc.d init script beigelegt: https://github.com/Kernel-Error/postfix-mta-sts-resolver

Wer es also ebenfalls mal probieren möchte, viel Spaß.

Der mta-sts-daemon loggt nun per default in /var/log/mta-sts.log. Config über yml ist ebenfalls nun drin genau wie die Konfiguration per Startparameter. Das rc.d script für FreeBSD könnte sicher schöner sein und hätte gerne im default den Benutzer mta-sts im System. Wir wollen es ja nicht als Root laufen lassen, hm?

Das einzelne Programm mta-sts-query greift auf den gleichen Logger zu, gibt damit also nichts mehr in der Konsole aus sondern auch im Logfile. Vielleicht passe ich dieses noch an, wenn dann mache ich auch einen pull request. Sonst gehe ich mal davon aus, dass es eh bald im postifx ist *daumen-drück*


Update

Habe ich jetzt gemacht. Pullrequest wurde angenommen und das neue Release ist auch schon gemacht. Jetzt also mit Logfile und rc.d script für FreeBSD.

Fragen? Dann fragen 🙂

SMTP MTA-STS: Strict Transport Security für deinen Mailserver

Haben wir uns schon über MTA STS / RFC 8461 unterhalten? Nicht? Dann dann wird es aber Zeit 🙂

MTA STS ist ein RFC von Ende 2018. So kann man eine Policy veröffentlichen um anderen Mailservern mitzuteilen, dass man seine E-Mails bitte nur per TLS (also mit Transportverschlüsselung) erhalten möchte und an welchen MX…

Eine ganz nette Idee nur…. Wenn man keine E-Mail ohne Transportverschlüsselung erhalten möchte, dann könnte man ja einfach keine E-Mails ohne Transportverschlüsselung annehmen?!?!? Natürlich sagt man anderen Mailservern zusätzlich noch an welchen sie bitte die Mails zustellen sollen, das es eine Transportverschlüsselung geben muss und alles nur mit einem gültigen Zertifikat ablaufen kann.

Fehlt da nicht noch etwas? Klar reporting… Dazu gibt es im Moment ein RFC: SMTP TLS Reportingdraft-ietf-uta-smtp-tlsrpt-23

Ein einfaches Onlinetool zum Testen gibt es ebenfalls: MTA-STS validator

Was muss man dafür nun tun? Ohne Frage muss der eigene Mailserver sauber TLS sprechen… Dann wirfst man einen TXT RR in die jeweilige DNS Zone:

$ dig IN TXT _mta-sts.kernel-error.de +short
"v=STSv1;id=20190202111557Z;"

Die eigentliche Policy veröffentlich man nun per Webserver jeweils für die Zone unter: mta-sts.domain.tld https://mta-sts.kernel-error.de/.well-known/mta-sts.txt

Das Reporting lässt sich ebenfalls schnell per TXT RR in der DNS Zone einrichten:

$ dig IN TXT _smtp._tls.kernel-error.de +short
"v=TLSRPTv1;rua=mailto:postmaster@kernel-error.de"

Beides ist sehr schnell und einfach eingerichtet. Postfix selbst berücksichtigt dieses leider noch nicht. Es gibt natürlich schon eine Implementierung, welche ich persönlich noch nicht ganz glücklich finde. Wer schon mal schauen will: https://github.com/Snawoot/postfix-mta-sts-resolver

Fragen? Dann einfach mal fragen 🙂

Mailserver Test aus Holland

In den Niederlanden gibt es eine staatliche Initiative um das Internet Sicherer zu machen. Dazu gehören ebenfalls verschiedene Onlinetools zum Testen seiner Systeme.

Ganz gelungen finde ich dabei das Tool zum Testen seines Mailserver. Wenn ich da einfach mal eine Domain eintrage: https://en.internet.nl/mail/bechtle.de/201507/ Fällt mir auf, dass ich da mal fragen sollte warum SSLv3 mit RC4 hier anscheinend noch OK ist.

Viele Spaß beim Selbstscan! Bei Fragen natürlich wie immer einfach fragen 🙂


Als kleines Update… Die Jungs haben auf meine Frag/Hinweiß geantwortet:

Guten Tag,

vielen Dank für Ihre Anfrage und das damit verbundene Vertrauen in unser Unternehmen.

In der Bechtle Gruppe sind die Kundensegmente zwischen Bechtle direct GmbH und der ARP GmbH so aufgeteilt, das jeder Kunde gemäß seinen Bedürfnissen optimal betreut werden kann.

Während sich die BechtleAC direct GmbH ausschließlich auf Großkunden und Konzerne konzentriert, bietet die ARP GmbH allen Kundensegmenten ein großes Sortiment von IT-Hard- und Software sowie individuellen IT-Lösungen an. Neben der persönlichen Betreuung verfügt die ARP GmbH über einen preisgekrönten Online-Shop, der auf die individuellen Bedürfnisse jedes Kunden anpassbar ist.

Bitte wenden Sie sich mit Ihrem Anliegen direkt an die ARP GmbH. 

Hm… Ob sie das RFC beachten und ich den Postmaster erreiche?

*trommelwirbel*

Mar  6 08:14:49 smtp postfix/smtp[97730]: 5193FB4292: to=<postmaster@bechtle.com>, relay=mx.bechtle.com[178.249.84.24]:25, delay=17, delays=0.41/0.02/15/1.2, dsn=2.0.0, status=sent (250 2.0.0 2qygs8tdp2-1 Message accepted for delivery)

Zumindest nicht sofort abgewiesen 🙂

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

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

Sowohl mein Postfix als auch der Dovecot sprechen nun sauber TLS 1.3.

Wenn Postfix sowie Dovecot sauber gegen OpenSSL 1.1.1 gebaut sind fehlen nur zwei Configänderungen.

Dovecot spricht es meist sofort wenn man hier die minimale TLS Version ind der 10-ssl.conf:

ssl_min_protocol = TLSv1.1

Beim Postfix setzt man einfach die zu nutzenden TLS Versionen in der main.cf:

smtpd_tls_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_mandatory_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv2, !SSLv3

Schon spricht Postfix TLS 1.3 mit anderen Server und beide Dienste sind in der Lage dieses mit Clients zu sprechen!

Test für smtp:

$ openssl s_client -starttls smtp -crlf -connect smtp.kernel-error.de:25
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3944 bytes and written 404 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Test für imap:

$ openssl s_client -connect imap.kernel-error.de:993 -crlf
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3944 bytes and written 404 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

So sieht ein Logfile doch schon viel mehr nach 2019 aus, oder?

Feb 15 16:05:43 smtp postfix/smtp[7475]: Verified TLS connection established to mx1.freebsd.org[2610:1c1:1:606c::19:1]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256

Bei Fragen, einfach fragen 🙂

Hardenize ein Security-Scanner für die Domain

Mir ist ein weiteres Onlinetool zum scannen seiner Domain durch den Browser gerutscht. https://www.hardenize.com/

Wie immer darf man nicht bild jedem Tool trauen und sich ohne denken darauf verlassen! Die Ergebnisse müssen immer mit dem nötigen Hintergrundwissen und Feingefühl interpretiert werden…. Hardenize testet nach der Eingabe einer Domain etwas umfassender. Es schaut sich die TLS Konfiguration der Webseite, sowie des Mailservers an. Prüft auf wichtige Policys, schaut in den DNS und bewertet somit etwas das Gesamtbild.

Vielleicht interessant für einen von euch.

Geht deine Domain am 01.02.2019 noch oder ist dein DNS kaputt?

Hey,

viele übersehen wohl gerade das es in drei Tagen ein Problem mit ihrem DNS und vor allem der Erreichbarkeit ihrer Zone geben könnte.

Testet doch einfach mal ob eure Domain/Zone ein Problem bekommt oder nicht >>klick<<

Es dreht sich alles darum, dass man entlich mal die „alten“ DNS Server aus dem Internet schieben möchte. Heise hat das ganz fein zusammengeschrieben: >>heise-klick<<

Oder halt direkt bei: https://dnsflagday.net/

Spannend wird es ab dem 01.02.2019. Wer also ab dann keine Stress habe möchte sollte vielleicht noch mal nachsehen?

Viel Spaß 😀

TLS 1.3 ist da!

Im August wurde TLS 1.3 auf der IETFE-Tagung als fertig beschlossen 😀 Damit haben sich aber alle wirklich Zeit gelassen! OpenSSL hat am 11.09.2018 die Version 1.1.1 (LTS) freigegeben. Am 12.09.2018 ist diese in die FreeBSD Ports gekommen und:

root@www:/ # /usr/local/bin/openssl version
OpenSSL 1.1.1 11 Sep 2018

Fehlt also nur noch ein Eintrag in der make.conf und schon lässt sich nginx sauber dagegen bauen und alles automatisch mit portmaster auf dem neusten Stand halten 🙂

/etc/make.conf
DEFAULT_VERSIONS+= ssl=openssl111

Schaut mal nach, die meisten machen wohl jetzt schon TLS 1.3 beim lesen dieser Zeilen ^^

Qualys und SSL Labs hängen leider noch etwas nach, hier wird noch auf/gegen die Draft Version geprüft (For TLS 1.3 tests, we currently support draft version 28.). Aber ich wette das wird nicht mehr lange dauern!

Kleines Update, die HIGH-TECH Bridge Jungs testen sauber auf TLS 1.3.

Ich wurde gerade drauf hingewiesen, dass die Developer Version von ssllabs TLS 1.3 schon sauber testet. Danke Jost 😀

https://dev.ssllabs.com/ssltest/analyze.html?d=www.kernel%2derror.de&s=2a01%3a4f8%3a161%3a3ec%3a0%3a0%3a0%3a443&hideResults=on&latest

Kein TLS 1.0 mehr

Da TLS 1.0 zum 30.06.2018 aus dem PCI Support fliegt (was nach knapp 19 Jahren auch mal ok ist), habe ich bei mir gerade überall den TLSv1.0 Support deaktiviert. Nein ich möchte nicht PCI konform sein… Damit sorge ich nun wieder einmal dafür, dass man mich mit einiger alter Software/Hardware und Betriebssystemen nicht mehr erreicht. Für mich ganz persönlich kann ich damit sehr gut leben 🙂 Wer jetzt noch mit so einer „Kiste“ unterwegs ist…. Na, der ist Kummer gewohnt!

Wen es interessiert der kann mit Qualys SSL Labs alles Mögliche scannen und auch direkt sehen welche Systeme wohl bei einem selbst nicht mehr funktionieren werden.

Zusätzlich spiele ich schon länger mit dem Gedanken bei meinem Mailserver Übertragungen ohne Transportverschlüsselung komplett zu verbieten. Für mich selbst kann ich es ja frei entscheiden. Lieber keine E-Mail als eine ohne Krypto! Ich werde mal auswerten wie denn das Verhältnis ist und welche E-Mails mich nicht mehr erreichen würden. Dann sehen wir mal weiter! Ich bin nur deswegen etwas zögerlich, weil mir in der Vergangenheit immer mal wieder Gegenstellen unter die Nase gekommen sind, bei welchen ich fest davon ausgegangen wäre, dass sie TLS einsetzten. Städte, Krankenhäuser, Ärzte, Schulen, IT-Security Dienstleister usw. usw… Hier scheint noch immer Unverständnis darüber zu herrschen, für was man denn wohl bitte dieses TLS braucht. Der Dienstleister meiner Heimatstadt begrüßt mich zumindest inzwischen mit einem Cisco Demo Zertifikat. *kopfschüttel* da hat der Admin nach meinen letzten Fragen zu dem Thema wohl den „security ON Button“ in seiner GUI gefunden O_o

Wobei… Mein Brötchengeber setzt auf einen eigenen Exchange Server bei welchem zuletzt 3DES Cipher abgeschaltet werden mussten. Das macht keinen Spaß und keinen Sinn. Windows-Admins scheinen hier schmerzfrei zu sein, hm?

TLS 1.3, das wäre ja mal was 🙂 ich warte schon mit schwitzigen Fingern. Zumindest sind wir schon mal bei Beta 5 (29.05.2018). Die Beta 1 vom 20.03 habe ich mir zuletzt in einer Jail angesehen und damit sehr zufrieden etwas herumprobiert. Für so etwas bin ich einfach zu ungeduldig. Ist das bei euch anders? Wollt ihr lieber noch TLSv1.0 haben?

TLS 1 ist tot und damit ist es dann jetzt weg, egal ob im stunnel:

;/usr/local/etc/stunnel/conf.d/tls.conf
[...]
options = NO_SSLv3
options = NO_TLSv1
ciphers = ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DHE-RSA-AES256-SHA256
[...]

Oder unter Postfix:

#/usr/local/etc/postfix/main.cf
[...]
smtp_tls_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_ciphers = high
smtp_tls_mandatory_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL, aNULL
smtp_tls_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL, aNULL
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec
smtp_tls_loglevel = 1
smtp_tls_mandatory_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtp_tls_mandatory_ciphers = high
tls_preempt_cipherlist = yes
tls_random_source = dev:/dev/urandom
smtpd_tls_loglevel = 1 
smtpd_tls_received_header = yes
smtpd_use_tls = yes
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_key_file = /usr/local/etc/postfix/postfix.key
smtpd_tls_cert_file = /usr/local/etc/postfix/postfix.pem
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_mandatory_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL, aNULL
smtpd_tls_exclude_ciphers = MD5, DES, ADH, RC4, PSD, SRP, 3DES, eNULL, aNULL
smtpd_tls_mandatory_ciphers = high
smtpd_tls_ciphers = high
smtpd_tls_mandatory_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtpd_tls_protocols = TLSv1.2, TLSv1.1, !TLSv1, !SSLv2, !SSLv3
smtpd_tls_dh1024_param_file = /usr/local/etc/postfix/dh2048.pem
[...]

Oder auch im Dovecot:

#/usr/local/etc/dovecot/conf.d/10-ssl.conf
[...]
ssl = required
ssl_dh_parameters_length = 4096
ssl_protocols = !SSLv3 !SSLv2 !TLSv1
ssl_cipher_list = AES128+EECDH:AES128+EDH
ssl_prefer_server_ciphers = yes
[...]

Selbstverständlich auch im Nginx:

#/usr/local/etc/nginx/nginx.conf
[...]
ssl_stapling on;
ssl_stapling_verify on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp521r1:secp384r1:secp256k1;
ssl_dhparam /usr/local/etc/nginx/ssl/dhparam.pem;
ssl_protocols TLSv1.1 TLSv1.2;
[...]

Und so weiter und so weiter 🙂

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑