Beiträge von MrKrabat

    einige von euch kennen vielleicht Kodi (ein Mediencenter),

    deren gesponserter Server auf dem deren Forum läuft wird in ein neues Rechenzentrum umgezogen

    und dabei geht so alles schief was schief gehen kann.


    https://forum.kodi.tv/


    Derzeit findet man dort die Leidensgeschichte der letzten 6 Tage ^^

    Hallo,


    ich versuche derzeit OpenDKIM dazu zu bringen auch Subdomains zu signieren, jedoch ignoriert er diese einfach.

    Wichtig in meinem Setup ist: mein Hauptserver arbeitet als Relay für zwei weitere Server und diese senden als Subdomains die signiert werden sollen.

    Mein komplettes E-Mail Setup funktioniert tadellos auch DKIM für die Stammdomain. Nur die Subdomain E-Mails werden abgelehnt, da nicht signiert (soll durch DMARC auch so sein).

    Code
    Sep 19 14:03:19 mcplayman opendkim[2001]: A8F1B200BD: cdn.mcplayman.de [185.194.141.112] not internal
    Sep 19 14:03:19 mcplayman opendkim[2001]: A8F1B200BD: not authenticated
    Sep 19 14:03:19 mcplayman opendkim[2001]: A8F1B200BD: no signature data

    Konfiguration:

    DNS Einträge sollten korrekt gesetzt sein, aber keinen Einfluss haben ob signiert wird oder nicht.


    Die Frage ist nun, warum fühlt sich OpenDKIM nicht für die Subdomains zuständig? Warum signiert er nicht?



    Mit freundlichen Grüßen,

    MrKrabat

    Ich kann dir auch nicht weiterhelfen, aber dir die Empfehlung geben einmal RainLoop anzuschauen

    Bin schon vor einiger Zeit von Roundcube auf RainLoop umgestiegen und bin sehr zu frieden


    Die Besonderheit ist, dass RainLoop dazu konzipiert ist mit mehreren Mailservern zu funktionieren,

    so kann man verschiedene Mailserver einfach hinzufügen oder gar GMail etc. über RainLoop nutzen.

    Für jede hinzugefügte Domain kann eine Sieverule angelegt werden (auch wenn ich nicht weiß was das ist ;) )

    Das ist richtig, dass du zwei Dateien hast.


    Du solltest jeweils eine .conf haben für die book und cloud Seite (HTTP).

    Dann auch jeweils eine .conf für beide mit ssl.


    Es sollten auch alle 4 Konfigurationen aktiviert sein und entsprechend konfiguriert.

    Wer faul ist kann auch HTTP/HTTPS in eine .conf packen, dann wird der Certbot jedoch nichts mehr automatisch generieren.


    Du solltest entsprechend auch zwei SSL Zertifikate nun besitzen, eines für cloud und eins für book.


    Sollte es weiterhin nicht gehen kann das mehrere Gründe haben:

    Dein Server oder die Klienten unterstützen kein SNI.


    Hinweis: Bei mir geht es übrigens wenn ich deine Seiten aufrufe, hast es also scheinbar schon behoben? ;)

    An deinen root Server gehen alle Anfragen von cloud und book.


    Das bedeutet wenn du per HTTPS auf book zugreifst entscheidet dein root Server welches SSL Cert er ausliefert.

    Dies ist komplett unabhängig von dem Webhostingpaket bei Netcup den du hast.


    Prüfst du eine nicht explizit auf deinen root Server geleitete Subdomain landest du entsprechend bei deinem Webhostingpaket, da der "Catch All Subdomains" Eintrag da hinleitet.


    Lösung:

    a) Ruf book nicht per HTTPS auf da dies einen Fehler erzeugen wird in JEDEM Fall, eine Umleitung geht nicht ohne gültiges Zertifikat.

    b) Ein Zertifikat für book anfordern, wie du schon geschrieben hast :)


    Der Befehl sollte dir jedenfalls ein Zertifikat ausspucken, der Certbot sollte theoretisch auch den SSL-vHost automatisch anlegen.

    Das hört sich gut an, wenn eine API auf dem Weg ist :thumbup:

    Dann kann ich im selben Zug auch endlich die TLSA/DANE Records automatisieren.


    Die API hat zum Glück noch einiges an Zeit, bis die Wildcards kommen :)


    Grüße,

    MrKrabat

    Hallo,


    ich wollte mal fragen ob es eine API oder ähnliches gibt um auf Domains zuzugreifen und insbesondere DNS Einträge zu manipulieren?


    Der Grund dafür ist, dass Let's Encrypt angekündigt hat ab Januar 2018 Wildcardzertifikate anzubieten, jedoch vorerst nur über die DNS Challenge.

    Zur Automatisierung des Prozesses kann man im Certbot Hooks implementieren.


    Ziel wäre es ein Hook zu erstellen der automatisch den DNS Validierungstoken als TXT-Record setzt und anschließend wieder löscht.


    Grüße,

    MrKrabat :)

    Du musst wie margau sagte IPv4 ebenfalls statisch einstellen.


    Ich lehne mich mal aus dem Fenster und behaupte, sobald die IPv4 DHCP Lease erneuert wird, droppt er die statische IPv6 Konfiguration.



    PS: Denk an die Firewall, iptables deckt IPv6 nicht ab => ip6tables gibt es separat.
    fail2ban ist derzeit IPv4-only, daher SSH Port auf IPv6 nicht freigeben, unter IPv6 ist fail2ban eh fragwürdig, da "eigentlich jeder" ein /64 Bit Subnetz hat ;)

    Hallo Leute,


    ich wollte heute mal eine kleine Anleitung dazu geben, wie Ihr DANE in Verbindung mit Letsencrypt verwenden könnt.
    Das ganze kann relativ kompliziert werden und die Anleitungen im Internet sind meist nicht vollständig zu gebrauchen oder auf Netcup anwendbar.


    Voraussetzungen für diese Anleitung:

    • Im CCP ist für die Domains DNSSEC aktiviert
    • Letsencrypt / Certbot eingerichtet
    • Zertifikate für eure Domains beantragt
    • E-Mail/SMTP Server mit STARTTLS und Zertifikat konfiguriert
    • Es wird die fullchain.pem verwendet


    Ihr braucht also ein vollständig laufendes System, indem nur noch DANE fehlt ;)
    Hinweis: Für SMTP ist es notwendig a) einen einzelnen MX Hostname für alle Domains zu verwenden oder b) ein sammel Zertifikat in dem alle Domains enthalten sind


    1. Schritt: Zertifikat Fingerprint
    Dazu empfehle ich das TLSAGEN Skript von sys4.de

    Code
    printf '_25._tcp.%s. IN TLSA 3 1 1 %s\n' \
        $(uname -n) \
        $(openssl x509 -in cert.pem -noout -pubkey |
            openssl pkey -pubin -outform DER |
            openssl dgst -sha256 -binary |
            hexdump -ve '/1 "%02x"')


    Dieses Skript speichern unter:
    /etc/letsencrypt/live/deinedomain.tld/
    Ausführbar machen und starten, der Output enthält nun den notwendigen Hash des aktuellen Letsencrypt Zertifikates.


    2. Schritt: Letsencrypt CA Fingerprint
    Wir benötigen nun noch den Hash von der Letsencrypt CA selbst, ich verwende "Let’s Encrypt Authority X3",
    in der Zukunft könnte sich dieses Zertifikat ändern.
    X1 und X2 sind mittlerweile veraltet, X4 dient derzeit dem worst-case Szenario als Backup.


    Chain of Trust - Let's Encrypt - Free SSL/TLS Certificates


    Wir downloaden also das X3 Zertifikat von Letsencrypt und generieren hiermit den Hash:

    Code
    openssl x509 -in lets-encrypt-x3-cross-signed.pem -noout -pubkey | openssl rsa -pubin -outform DER | openssl dgst -sha256 -hex | awk '{print "le-ca TLSA 2 1 1", $NF}'


    Damit haben wir den Hash des aktuellen Letsencrypt CA Zertifikates.


    3. Schritt: TLSA RR erstellen
    Im CCP könnt Ihr nun die RR für TLSA erstellen für jede Domain, die sollten wie folgt aussehen:

    Code
    Host	Type	Destination
    *._tcp	TLSA	3 1 1 HASH_AUS_SCHRITT_1
    *._tcp	TLSA	2 1 1 HASH_AUS_SCHRITT_2


    *._tcp sorgt dafür, dass dieser TLSA Eintrag für jeden Port gilt, Ihr könnt es bei bedarf auch nur auf SMTP beschränken durch _25._tcp


    4. Schritt: Validierung
    Sobald die Änderung übernommen wurden könnt Ihr hier prüfen ob alles funktioniert hat:
    DANE SMTP Validator


    5. Schritt: Zertifikat Erneuerung
    Wenn Ihr euer Zertifikat erneuert muss auch der TLSA RR aktualisiert werden.
    Dazu führt die Schritte 1-4 erneut aus.
    Schritt 2 kann übersprungen werden, wenn sich das Letsencrypt CA Zertifikat nicht geändert hat (sollte die nächsten Jahre so sein).


    Da der Certbot automatisch die Zertifikate erneuert und keine Info E-Mail versendet, kann es leider sein, dass man den Tag verpasst.
    Das ist jedoch nicht weiter schlimm aus folgendem Grund:


    Wir verwenden oben "3 1 1" und "2 1 1" Einträge, den Grund findet man hier:
    Please avoid "3 0 1" and "3 0 2" DANE TLSA records with LE certificates - Server - Let's Encrypt Community Support
    Durch das Pinnen der Letsencrypt CA haben wir eine Art "fallback", wenn unser Zertifikat erneuert wurde ist weiterhin der TLSA RR von der Letsencrypt CA gültig.
    Sollte Letsencrypt jedoch das "Let’s Encrypt Authority X3" Zertifikat ändern gilt dies nicht mehr!
    Daher sollte man es dennoch nicht vernachlässigen die TLSA RR zu aktualisieren ;)



    Damit endet nun meine Anleitung, ich hoffe sie ist soweit verständlich.


    Mit freundlichen Grüßen,
    MrKrabat

    Es ist ja auch eine Frage, was für eine Kartoffel er da angegriffen hat,
    über die IP findet man raus die gehört zu einem ISP, also ist der Server zuhause gehostet, bestenfalls noch von nem Raspberry Pi.


    Am besten sind übrigens noch die Kommentare von den Kindern die das nachgemacht haben ;)
    "Ein anderer Hoster bitte. *Provider* hat mich sofort gesperrt. Hab gerade 4 Server gekauft, die haben noch schneller als *Provider* gebannt, 18€ weg."
    "Hahahha ich wurde sofort gesperrt nach einem mal !"
    "kann mir jemand einen ´vserver empfehlen wo ich nicht gespeert werde"


    Der Hoster sperrt immerhin sofort die VPS :)

    Auch wenn das Problem bereits gelöst ist möchte ich nochmal eine Bemerkung dazu einschieben:


    Der Trend geht dazu über, dass über SMTP / Port 25 ausschließlich E-Mail Server untereinander verkehren sollen.
    E-Mail Klienten sollten über Port 587, den Submission Port, die E-Mails einliefern, das ist mittlerweile auch Standard (RFC 2476) soweit ich weiß.


    Wie auch schon korrekt erwähnt wurde wird Port 25 gerne blockiert um dadurch E-Mail Spam zu verhindern, die Telekom scheint ja noch ganz nett zu sein.
    1&1 als Beispiel blockiert Port 25 komplett in ihrem Netzwerk, das Problem hatte ein Freund von mir gehabt mit denen.
    Die simple Lösung ist bei SMTP als Port 587 auswählen und alles funktioniert :)
    Ich (Kabel Deutschland Kunde) kann auch problemlos Port 25 verwenden.


    Ich kann natürlich jetzt nicht sagen ob dein E-Mail Server den Port 587 anbietet oder ob die (tolle) Firewall den evlt. sogar auch blockiert, das sollte aber funktionieren! :)



    Grüße,
    MrKrabat


    Ohne die Details zu TLSA zu kennen: Das würde allerdings im Widerspruch zu diversen RFC's stehen, die DNS behandeln. Dort ist ein Wildcardeintrag explizit nur ganz links von einem Punkt erlaubt. (*.sub.example.com)


    MfG Christian


    Ja du hast recht, der _ am anfang gehört weg :)
    Ich habe Wildcards erfolgreich getestet mit "*._tcp"




    Danke! Das Funktioniert so jetzt, Wildcards gehen auch mit "*._tcp", deckt dann alle Ports ab


    Ich verlinke auch mal das Tool meines Vertrauens
    https://ssl-tools.net/
    die Seite kann ebenfalls auf DANE Prüfen und viele andere Sachen auch :)

    Danke guest123,


    die Frage wegen dem Wildcard für den Port kommt daher, dass bei dem Facebookpost von Netcup ein Screenshot gegeben war:
    https://www.facebook.com/netcup/photos/a.392423024148693.89056.165424236848574/1081006705290318/?type=3&theater


    dort sieht man, dass kein Port bei dem TLSA-Record angegeben wird daraus würde sich ja schließen, dass der Port hardcoded sein muss
    Laut Standard für TLSA wäre es erlaubt "_*._tcp.example.com." zu machen und jeden Port abzudecken, daher die Frage :)

    ich habe da höchstens ein paar Fragen,


    wenn ich im CP nun ein TLSA Eintrag der Art

    Code
    _tcp.test TLSA 03 01 01 SHA256Hash


    habe, steht "test" ja für die Subdomain nehme ich an, auf Facebook der Screenshot von euch hatte das ja äquivalent nur mit mail.


    Laut Standard sieht der Eintrag ja so aus:

    Code
    _443._tcp.example.com.  IN TLSA 3 0 1 SHA256Hash


    a) den Port können wir ja nicht angeben, ist er mit Wildcard vorgeben? Laut RFC6698 ist das ja möglich
    b) Wie setzt man den TLSA für die Stammdomain bei Netcup? "_tcp", "_tcp.", "_tcp.@" mir würde vieles einfallen :S
    c) Kennt jemand ein TLSA/DANE Testtool? Für Webseiten und SMTP :thumbup: am besten ohne das ich etwas Installieren muss


    Derzeit behaupten meine Testseiten ich habe keine TLSA Records ^^

    Ich habe auch nochmal Google bemüht,


    "_autodiscover._tcp.der-webcode.de. 3600 IN SRV 0 0 587 mail.der-webcode.de"
    Wenn sich dein DNS-Server an die Standards hält müsste es so aussehen


    Jedoch hast du 2x den autodiscover mit unterschiedlichen Port, das geht nicht.
    Hier würde der DNS Server als Loadbalancer arbeiten und die 50% 50% Verteilen

    soweit mir bekannt benutzt man SRV Einträge nur für Subdomains,


    in meinem Beispiel oben definiere ich für die Subdomain "dev" einen SRV.
    Wenn ein Minecraftclient sich nun mit dev.domain.tld verbinden will sucht er nach einem SRV Eintrag der mit "_minecraft" Beginnt findet er so einen Eintrag verbindet er sich mit der dort hinterlegten Adresse + Port,
    ansonsten versucht er die A/AAA/CNAME Adresse der Subdomain "dev" zu nehmen, sofern vorhanden.


    Wenn du einen eigenen DNS Server nutzt kannst du dich an Internet Vorgaben wie Wikipedia halten
    SRV Resource Record – Wikipedia
    "_identifier._protokoll.example.com." für die Stammdomain.


    Aber ich bin mir dennoch nicht sicher ob man bei E-Mail mit SRV arbeitet ;)

    die SRV Einträge sehen falsch aus,


    das Format bei Netcup ist folgendes (siehe Dateianhang):
    _identifier._protokoll.subdomain SRV priorität gewicht port Adresse


    der identifier ist dabei von deiner Anwendung vorgegeben, wenn SRV Unterstützt wird nach diesem Eintrag gesucht.
    Wird von E-Mail Programmen überhaupt SRV unterstützt?



    mit freundlichen Grüßen,
    MrKrabat

    Ich würde als SPF "v=spf1 mx a -all" empfehlen.


    Ich erkläre mal was dein derzeit gewählter Eintrag macht:
    a = autorisiere die IP im A-Record
    mx = autorisiere alle Mailserver in den MX Einträgen
    ~all = "Soft Fail": Akzeptiere ALLE Mails, markiere sie aber als Spam/ oder wie auch immer der Server damit umgeht.


    das a und mx sind ziemlich redundant, man kann das a also besser weg lassen, zumal in den MX Einträgen eh alle expliziten Mailserver drin stehen sollten.
    -all sorgt dafür, dass jede Mail abgelehnt werden soll, die nicht vom SPF autorisiert ist, in diesem fall sind nur die im MX Record enthalten Mail-Server autorisiert.


    Der SPF muss prinzipiell überall gesetzt werden also @ für die Stammdomain und dann noch als Wildcard für jede Subdomain.
    Ist eine Subdomain explizit Definiert A/CNAME z.B. so müsste dort der SPF auch nochmal explizit gesetzt werden.


    Korrigiert mich wenn ich falsch liege :)



    Edit: Wer von euch G-Mail zum versenden von E-Mails nutzt muss dies auch explizit whitelisten im SPF
    das könnte so aussehen "v=spf1 mx a include:_spf.google.com -all" (ungetestet, keine Gewähr)

    Kleine Rückmeldung,


    ich habe einfach ALLE DNS Records von Domain A gelöscht und neu erstellt.
    Jetzt gehen wildcard Subdomains, also das neu signieren der Zone hat bei mir allein nicht gereicht aus unerklärlichen Gründen :)


    Vieleicht wurde das Problem auch indirekt durch Einführung von Dane gefixt :)

    DNSSEC deaktivieren und aktivieren hat keine Änderung gebracht.


    Ich habe heute nochmal Resolver Tests gemacht,
    mein Handy ist nicht DNSSEC fähig, mein PC schon.


    Das ändert aber nichts daran, dass ich Wildcard Subdomains NUR bei Domain A nicht auflösen kann.
    Bei Domain B und C gehen Wildcard Subdomains.


    Bei mir (Kabel Deutschland) und einem Freund (Telekom) besteht das Problem mit Domain A. Ebenfalls mit Google DNS Server oder VPN geht es nicht.
    Im mobilen Netzwerk (T-Mobile) und im Uni-Netzwerk gehen wildcard Subdomains hingegen.


    Warum aber lassen sich wildcard Subdomains von Domain B und C auflösen aber von Domain A nicht?
    Es sind keine Sonderzeichen enthalten in Domain/Subdomain.


    Ich hoffe ich konnte damit die Problematik nochmal verdeutlichen :)