Beiträge von KB19

  • Das längste Thema

    mainziman Bei Spamhaus und SORBS wäre ich halt vorsichtig. Deren Geschäftspraktiken sind alles andere als gut. Wenn man sich auf die als einziges Kriterium verlässt, sind Fehlalarme vorprogrammiert. Das wird legitime Absender, die absolut nichts falsch gemacht haben, sicher freuen…

  • Das längste Thema

    Zitat von killerbees19

    Ich teste so ein Setup derzeit, mal schauen, ob es sich lohnt.

  • Das längste Thema

    Alle paar Jahre muss man das eigene Setup mal infrage stellen und experimentieren. ;) Selbstverständlich auf einem neuen System. :)


    Wobei ich TLS 1.3 ja wieder entfernt habe, solange OpenSSL 1.1.1 nicht aus der Beta raus ist. Aber die Config ist vorbereitet und nur einen Daemon-Restart entfernt. ^^

  • Das längste Thema

    Zitat von H6G

    Dovecot hat nichts mit E-Mail senden zu tun. Dovecot ist für IMAP zuständig, damit du die Mails in deinem Client sehen kannst.

    btw: Dovecot hat mittlerweile einen Submission-Daemon. Der ist zwar nur ein halbwegs intelligenter Proxy (mit Zusatzfeatures wie BURL) für einen richtigen SMTP-Server, aber das könnte in Zukunft noch sehr interessant werden. Vor allem, weil man die Authentifizierung und den TLS-Kram für den MUA-Bereich nur mehr an einer einzigen Stelle konfigurieren muss. Postfix braucht die Userauthentifizierung somit gar nicht mehr und kann bei TLS etwas weniger streng konfiguriert werden, damit die ungepflegten Mailserver da draußen kein Problem haben.


    Ich teste so ein Setup derzeit, mal schauen, ob es sich lohnt. Praktisch wäre es auf jeden Fall, da es für eine deutlich klarere Struktur sorgt! :)

  • MySQL/MariaDB - Shared Hosting - Datenbankgröße begrenzen (Quota)

    Alternative Idee: Eigene MariaDB-Instanz je Kunde? (mit eigenem Useraccount unter Linux und z.B. Journal-Quota)


    Dank Systemd ist das mittlerweile deutlich einfacher realisierbar. Die meisten Control Panel für Kunden kommen damit aber nur schwer bis gar nicht klar. Aber prinzipiell wäre das eventuell mein Weg, wie ich es machen würde, wenn ich es hart begrenzen wollen würde. Die von Hecke29 erwähnten Probleme mit Hardlimits existieren bei so einem Setup natürlich trotzdem. Aber das könnte man durch rechtzeitige Warnungen mittels Softlimit halbwegs kompensieren. Wobei sich dann die Frage stellt, warum man das Hardlimit so kompliziert macht und nicht gleich "nur" den Zugang sperrt… ?


    Eine eigene Instanz pro Kunde hätte auch den Vorteil, dass man auf beliebige Kundenwünsche bei der Datenbankserverkonfiguration eingehen könnte. Es erhöht halt den Verwaltungs und Administrationsaufwand.

  • Das längste Thema

    Zitat von mainziman

    die Mail soll ja wenn einer dieser Listen anschlägt rejecten

    Und genau das ist das Problem. Ein einziges False-Positive und sie wird rejected. Deshalb verwendet man normalerweise mehrere RBLs mit unterschiedlicher Gewichtung. Eine RBL alleine (die man nicht ausschließlich selbst füttert) darf niemals als einziger Ablehnungsgrund herhalten!


    Postscreen wäre übrigens auch eine Möglichkeit, wenn man es ohne externe Dienste stemmen will. Dort kann man RBLs direkt konfigurieren.

  • Das längste Thema

    Das 100% A+ Rating schafft man derzeit übrigens so… (Debian Buster; TLSv1.3 ist nur als Vorbereitung drinnen)

    Code
    ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384";
ssl_dhparam /etc/nginx/dhparam-4096.pem;
ssl_ecdh_curve secp384r1;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
ssl_session_timeout 1d;

    Die Cipherliste ist von Mozilla, wobei alle 128 Bit Cipher entfernt wurden.

    Nicht vergessen, die DH-Datei mit 4096 Bit zu generieren!


    Jetzt fehlt nur noch eine Bestnote bei securityheaders.com :D

  • Eigene Nameserver + email

    Zitat von AD1

    Auf dem Vserver liegen aber mehrere Webspaces für mehrere Domains, alles unter einer IP, findet er denn die richtige Domain?

    Das hat mit DNS wenig zu tun und würde sich bei einem eigenen Nameserver nicht anders verhalten.


    Dafür gibt es bei HTTP den Host-Header und bei HTTPS auch noch SNI. Der Webserver gibt dann anhand der vHost-Konfiguration die richtige Seite aus.


    Darf man fragen, ob das ein unmanaged (v)Server ist? Administrierst Du den selbst?

  • Eigene Nameserver + email

    Solange der MX-Record auf den Webspace zeigt, sollte das klappen. Nicht vergessen, dass der TXT-Record (SPF) dazu passt, falls über den anderen Server ebenfalls Mails verschickt werden sollen!


    Aber wieso gleich eigene Nameserver? Reicht es nicht, wenn Du die A/AAAA-Records auf den (v)Server zeigen lässt?

  • Das längste Thema

    Zurück zu Testing – bye, bye Experimental 8)

    Code
    # apt-get install openssl=1.1.0h-4 libssl1.1=1.1.0h-4 
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Die folgenden Pakete werden durch eine ÄLTERE VERSION ERSETZT (Downgrade):
  libssl1.1 openssl
0 aktualisiert, 0 neu installiert, 2 durch eine ältere Version ersetzt, 0 zu entfernen und 0 nicht aktualisiert.

    Ich hoffe, dass OpenSSL 1.1.1 bald offiziell erscheint und dann schnell den Weg nach Buster findet. Wäre schade, wenn es erst in Bullseye enthalten wäre.

  • Das längste Thema

    florian2833z Bei einem stabilen Debian Release würde ich lieber nicht an grundlegenden Dingen wie OpenSSL herumpfuschen. Das kann, fast wie mit der libc, schnell ins Auge gehen.


    Die genauen Parameter habe ich gerade nicht. Schau mal in die Source-Pakete bei Debian und vergleiche den debian-Ordner zwischen den Versionen. Was OpenSSL angeht, stecke ich zu wenig drinnen, um das beurteilen zu können.

  • Das längste Thema

    Zitat von florian2833z

    Mal so ne dämliche Frage, muss ich nginx neu kompilieren, wenn ich openssl 1.1.1 installiert habe? Manche Seiten sagen ja, manche nein.

    Unter Buster nicht. Einfach OpenSSL (und libssl1.1) aus Experimental installieren, TLS1.3 in ssl_protocols aufnehmen und das Ding neustarten. Das ist alles, danach läuft es. Es ist halt experimentell, nichts für den Produktiveinsatz.


    Vorsicht: OpenSSL 1.1 unterstützt in Debian derzeit per Default nur noch TLS >= 1.2! Wenn Du ältere Versionen brauchst, musst Du Deine openssl.cnf anpassen: https://lists.debian.org/debia…nce/2018/05/msg00000.html


    Dual RSA/ECDSA funktioniert übrigens auch bei Nginx einwandfrei. Dort reicht es, wenn man die cert/key Konfiguration fürs zweite Schlüssel/Chain Paar dupliziert.

  • Das längste Thema

    Ich experimentiere gerade zum ersten Mal mit certbot. Es soll bei diesem Szenario absichtlich kein alternativer Client genutzt werden.


    Sehe ich das richtig, dass man bei gleichzeitiger Nutzung von RSA und ECDSA Zertifikaten noch immer möglichst viel selbst erledigen muss, wenn sich der Publickey nicht andauernd ändern soll? (Stichwort TLSA-Record)


    D.h. den Key und CSR für beide Varianten erstellen und nachher das Zertifikat mit certbot certonly anfordern. Um die Verlängerung bzw. den Speicherort kümmert man sich besser selbst mit einem kleinen Script.


    Oder habe ich irgendeinen supertollen modernen Weg übersehen? Genutzt wird übrigens Debian Buster, die eingesetzten Versionen sollten somit aktuell sein.



    Edit, wenn man schon mal am Testen ist: Mit OpenSSL 1.1.1 aus Experimental klappt dann auch schon TLSv1.3 über Nginx 8o


    tls13-summary.png tls13-configuration.png


    (Let's Encrypt Staging; deshalb nicht vertrauenswürdig)