Wie angekündigt habe ich nun meinen Apachen in den Ruhestand geschickt… Damit ist nun also ebenfalls mein Webserver auf FreeBSD und ebenfalls auf NGINX.
Siehe auch: HTTP/3 und QUIC
Fragen? Einfach melden.
Schlagwort: SelfHosted (Seite 3 von 6)
Ihr erinnert euch doch sicher noch an meinen Bla zum BSI und nextcloud, oder? ==> Die Jungs vom BSI und nextcloud
Inzwischen ist der Scanner wohl für jeden einfach nutzbar… So wie man es von Qualys oder ähnlichem kennt. Einfach mal hier klicken: https://scan.nextcloud.com/ und fröhlich scannen.
Solche Scanner haben ja auch schon irgendwie etwas für sich, oder? Ein A+ sollte wohl für den Moment jeder ohne weitere Probleme erreichen können!
So long…
Siehe auch: MTA-STS einrichten
Fragen? Einfach melden.
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.
Inzwischen bin ich etwas weiter. Ich nutze nun einen sauberen Filter um SPAM von meinem Jabberserver fern zu halten. \o/ Somit habe ich die Block der besonders auffälligen xmpp-server zurückgezogen. So gefällt mir die Lösung schon viel besser.
Siehe auch: Eigenen Jabber-Server betreiben
Fragen? Einfach melden.
Aktuell beobachte ich sehr für SPAM mit teils russsichem Inhalt zu Exploits und ähnlichem, der von vielen verschiedenen Domains bei meinem Server ankommt.
Die Admins dieser Server kommen zum Teil aktuell nicht mit dem Aussortieren der Spamaccounts nach. Ich selbst habe ebenfalls schon viele Anmeldeversuche dieser Spamaccounts bewundert. Diese werden automatisch erstellt, dann etwas später wird darüber ein einem riesigen Schwung versucht Spam zu verteilen und nach knapp 1Stunde verstaubt der Account wieder. Dagegen hilft fast nur die einfache Benutzeranmeldung über xmpp zu deaktivieren.
Derzeit bei mir also nur möglich über (Gott ist das hässlich): https://jabber.kernel-error.de:9091/plugins/registration/sign-up.jsp
Oh ja, die Spamserver habe ich aktuell geblockt. Im Moment sind es die folgenden:
ajabber.me
anonymitaet-im-inter.net
codingteam.net
exploit.im
igniterealtime.org
jabber.co.za
jabber.no
jabber.zerties.org
jabbim.cz
jclub.pw
jumbo.li
justnet.pl
km-net.pl
lih.im
pandion.im
qip.ru
svnet.fr
sync-hv.de
talkers.im
tigase.im
xmpp.svnet.fr
Siehe auch: Eigenen Jabber-Server betreiben
Fragen? Einfach melden.
Kaum geht mein Artikel zur erweiterten Sicherheit meiner Webseite online >>TLS Sicherheit weiter verschärft….<< schon kommen Fragen. Eine habe ich nun schon vier mal bekomme, daher hier direkt die Antwort. Ach ja, die Frage:
Wie habe ich meinen Apache dazu überredet DHE-Keys mit 4096bit zu benutzen?
Also… Der Apache beherrscht seit Version 2.4 Diffie Hellman mit mehr als 1024bit. Um dieses nutzen zu können, muss der Apache die passenden dh-params haben. Der Apache nutzt dabei automatisch die ihm gegebene Key stärke.
Ich generiere den DH Teil gerne direkt mit dem jeweiligen Zertifikat und verbinde dieses. Beschrieben habe ich es hier: >>Sicheres SSL / TLS Zertifikat<<
Wer gerne nachträglich generieren möchte macht es mir:
$ openssl gendh 4096 > dh_4096.pem
Dieses lässt sich nun einfach wie ein normales Zertifikat mit in die Konfiguration des Apachen einbinden. Im Grunde nichts besonders und nachdem man es gelesen und absolut einleuchtend, man sucht aber dann doch zuerst etwas.
Viele andere Dienste (Postfix usw…) bringen ja meist einen eigenen Konfigurationspunkt dafür mit. Im Apache liegt es ohne große Konfiguration in Zertifikatsnähe.
So long….
Fragen? Einfach melden.
Seit ein paar Tagen scheint das Thema DNSSEC, DANE und TLSA im Zusammenhang mit Postfix im Internet besonders aktiv zu sein. Ich bekomme täglich Anfragen dazu und einige scheinen zu testen — E-Mails mit Random-Empfängern an meine Domains. Gegen Tests habe ich nichts, aber grob abgesprochen wäre schön, mein Monitoring wird sonst immer so wuschig.
Kurz zusammengefasst:
- Basis von allem ist DNSSEC.
- TLSA-Records sind DANE.
- Postfix kann TLSA-Records auswerten, ohne selbst welche für sein System zu haben.
Weiterführend:
Fragen? Einfach melden.
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)
Siehe auch: Client-Initiated Renegotiation deaktivieren
Fragen? Einfach melden.
Kex exchange basierend auf EECDH (diese elliptischen Kurven nach DH Diffie-Hellmann), sollte ja inzwischen ein alter Hut sein. Ich gehe also mal von einer aktivieten und funktionsfähigen Konfiguration aus (irgendwo habe ich das wohl auch schon mal beschrieben).
Im Standard läuft dieses nun bei 1024bit also EECDH mit ca. 128bit (smtpd_tls_eecdh_grade=strong). Möchte man alles auf 2048bit EECDH mit ca. 192bit aufbohren… Was ca. die doppelte „Sicherheit“ zu EECDH mit 128bit bedeutet, dann ist folgendes zu erledigen.
Zuerst benötigen für eine große prime group:
$ cd /etc/postfix $ openssl dhparam -out dh_2048.tmp 2048 && mv dh_2048.tmp dh_2048.pem $ chmod 644 dh_2048.pem
Dann Postifix mitteilen, dass er sie bitte nutzten soll (ist kein Typo, gehört zur Option „smtpd_tls_dh1024_param_file„).
/etc/postfix/main.cf:
smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem
smtpd_tls_dh512_param_file = /etc/postfix/dh512.pem
Nun wechselt smtpd_tls_eecdh_grade von strong zu ultra und ich setzte noch die zu verwendende „Kurve“ fest.
/etc/postfix/main.cf:
smtpd_tls_eecdh_grade = ultra
tls_eecdh_strong_curve = prime256v1
tls_eecdh_ultra_curve = secp384r1
Diese Aktion könne nicht ganz Schmerzfrei sein. Für privat und mein Testsystem sicher zu verantworten. Manche MSA (Mail SUbmission Agent) könnten damit Probleme bekommen. Hat also jemand ein Problem mit E-Mail zu senden, bitte melden.
So long….
Siehe auch: Perfect Forward Secrecy
Fragen? Einfach melden.
Veraltet: Debian 7 (Wheezy) hat seit 2018 keinerlei Support mehr. TLS_FALLBACK_SCSV ist seit Jahren in allen aktuellen OpenSSL-Versionen enthalten und muss nicht mehr manuell kompiliert werden.
Wer bei seinem Debian TLS_FALLBACK_SCSV im Apache nutzen möchte, muss im Grunde nur auf eine OpenSSL Version >=1.0.1j wechseln.
Einen direkten Backport gibt es dafür leider nicht, also selbst übersetzten. Dazu nutzt man einfachsten direkt den „Debian-Weg“.
Vorbereiten fürs Kompilieren:
$ cd /usr/src $ apt-get install build-essential fakeroot $ apt-get build-dep openssl
Herunterladen der aktuellen Version:
$ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j-1.dsc $ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j.orig.tar.gz $ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j-1.debian.tar.xz
Auspacken des Archives und mit den Patchen „verknüpfen“:
$ dpkg-source -x openssl_1.0.1j-1.dsc
Ins neue Verzeichnis wechseln:
$ cd openssl-1.0.1j
Kompilieren und deb Pakete erstellen:
$ dpkg-buildpackage -us -uc -rfakeroot
Die neuen Pakete installieren:
$ cd .. $ dpkg -i libssl1.0.0_1.0.1j-1_amd64.deb libssl1.0.0-dbg_1.0.1j-1_amd64.deb libssl-dev_1.0.1j-1_amd64.deb libssl-doc_1.0.1j-1_all.deb openssl_1.0.1j-1_amd64.deb
Kontrolle der Version:
$ openssl version OpenSSL 1.0.1j 15 Oct 2014
ACHTUNG… Ab diesem Moment ist man natürlich selbst dafür verantwortlich Pachte zu installieren.
So long…..
Selbstverständlich profitieren damit alle Anwendungen, die auf OpenSSL aufbauen, so auch Postfix, Dovecot usw:
$ openssl s_client -connect smtp.kernel-error.de:465 -fallback_scsv -no_tls1_2 CONNECTED(00000003) 140410198378152:error:1407743E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert inappropriate fallback:s23_clnt.c:770: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 215 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE ---
U-P-D-A-T-E
Denkt an die Updates.
$ openssl version OpenSSL 1.0.1k 8 Jan 2015