DNSSEC und DANE per default!

  • Hallo an alle, bin ein neuer Kunde von Netcup!


    Zuerst ein großes Lob an Netcup.de:


    Eure Root-Server sind vom Preis und der angebotenen Leistung,

    vor allem die KVM Remote Konsole zum Installieren aller OS ist normal nur bei hochpreisigen Servern per default im Angebot enthalten.

    Die Möglichkeit eigene .iso Images auf Euren FTP Server zu laden finde sehr gut.

    Nur so ist es möglich wirklich jedes OS zu installieren. Vor allem die Partitionierung so zu machen wie man es benötigt je nach der Server Installation.

    Ein Web Server hat eine andere Partitionierung als ein Mail Server oder ein FTP Server je nach Server ist dies unterschiedlich.

    Nicht alles auf / zu installieren so wie es der Standard der meisten Hoster ist leider.

    Sicherheitstechnisch ein großes Problem alles auf / zu installieren.


    Das obige ist ein großes Plus an Netcup.


    Danach die Kritik an Netcup.de:


    Zuwenig Netzwerksicherheit momentan leider:


    DNSSEC ist derzeit nur im SCP aktiv!


    Im CCP und der Domain netcup.de aber nicht!


    DANE ist sowohl im CCP als auch im SCP und der Domain netcup.de nicht aktiv!


    #####

    DNSSEC:


    https://de.wikipedia.org/wiki/…ystem_Security_Extensions


    #####

    DANE:


    https://de.wikipedia.org/wiki/…ication_of_Named_Entities


    #####

    SSHFP

    https://de.wikipedia.org/wiki/SSHFP_Resource_Record


    #####

    SSL Server Test


    https://www.ssllabs.com/ssltest/


    #####

    Scan your site now


    https://securityheaders.com/


    #####

    DANE SMTP Validator


    https://dane.sys4.de/


    #####

    https://www.christianlepuschitz.at/htl/netzwerksicherheit/


    #####

    Partitionieren für eine Debian-Installation


    https://www.debian.org/releases/stable/arm64/apcs03.de.html



    LG Riko :)

  • Vielen Dank für Ihr positives Feedback und Ihre geäußerte Kritik.


    DANE unterstützen wir bei eigenen Mailservern noch nicht.


    DNSSEC birgt uns ein zu hohes Risiko das Key-Rollovers fehlschlagen, weshalb wir DNSSEC bei kritischen Domains selber nicht verwenden. Hier gab es ja bis vor kurzem einen ausstehenden Keychange seitens der IANA, bei dem niemand zu 100% zusichern konnte, dass er komplett fehlerfrei vonstatten geht.


    Mit freundlichen Grüßen


    Felix Preuß

  • Hallo Felix,


    vielen Dank für Ihre schnelle Antwort.


    Bezüglich des Risiko des Key-Rollovers,

    laut ICANN war --> Das Ergebnis war außergewöhnlich gut.


    Ich persönlich habe lieber 2 Tage kein Internet im Jahr und dafür 363 Tage ein mit DNSSEC und DANE gesichertes sicheres Internet,

    als 365 Tage ein unsicheres Internet.


    Aber ja ... so sind wir Menschen halt unterschiedlich in der Meinung.


    LG Riko


    #####

    ICANN


    https://www.icann.org/news/blo…er-summary-and-next-steps


    #######

    DNSSEC



    ##############

    DANE + DNSSEC


  • […] aber wie gesagt auch wenn clients es nicht prüfen könnte man die keys ja im [CCP/SCP/whatever] panel listen sodass man diese selbst prüfen kann.

    Sofern man selbst SSHFP-Einträge im CCP für die dort verwalteten Domänen anlegt, sieht man die key fingerprints dort ja auch; verwendet man nicht-öffentliche Einträge/eigene Nameserver, lassen sich diese zumindest explizit manuell abfragen:

    Code
    1. [2019-09-08T09:32:01+0200] root@vserver06<kvm>:/etc/ssh# dig +dnssec vpn-vserver06.example.org sshfp | egrep ';; [Sf]|SSHFP\s'
    2. ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
    3. vpn-vserver06.example.org. 3600 IN SSHFP 2 2 21D0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 7E94xxxx
    4. vpn-vserver06.example.org. 3600 IN SSHFP 3 2 F190xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx EFADxxxx
    5. vpn-vserver06.example.org. 3600 IN SSHFP 4 2 4829xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 9097xxxx
    6. vpn-vserver06.example.org. 3600 IN SSHFP 1 2 FFA5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 2F6Axxxx
    7. ;; SERVER: 127.0.0.1#53(127.0.0.1)

    (Im gezeigten anonymisierten Beispiel sind die Schlüsselinformationen und der Hostname-Alias nicht öffentlich abrufbar.)


    Wenn die aktuellen key fingerprints im SCP angezeigt werden sollen, muss der jeweilige (interne) Name/Alias des Hosts bekannt und eine Zugriffsmöglichkeit auf die jeweiligen DNS-Einträge "von außen" möglich sein (für eine "Live-Abfrage"[*]), was im allgemeinen Fall sowohl eine Konfigurationsänderung auf den Servern sowie eine explizite Hinterlegung/Synchronisation von Zusatzinformationen erfordern würde.


    [*] Wenn hingegen keine SSHFP-Einträge existieren, kann das SCP keine Informationen liefern, welche über die eigene ssh-Kontaktaufnahme zwecks Anzeige des key fingerprints (des jeweiligen privaten Schlüssels) hinausgeht, und auch in diesem Fall müssten je nach Konfiguration beispielsweise der Nutzername, IP-Adresse, Port und der öffentliche Schlüssel auch im SCP hinterlegt sein. (Im Falle einer VPN-Nutzung erforderte dies insbesondere einen Zugriff auf selbiges durch ein Netcup-verwaltetes System! Das will weder der Kunde noch der Dienstleister…)

  • Welchen Nutzen soll denn SSHFP haben?

    All diese extra DNS-RR sind doch nur Hacks für ein kaputtes Protokoll.

    Das würde ich nicht so extrem sehen. Jede Art von Trust (wie z. B. Zertifikate o. Ä.) brauchen eine Art von Trust Anchor. SSH kann dies eben über DNS realisieren. Offen bleibt dann eben, wie der DNS Trust Anchor aussieht (DNSSEC z. B.). Es hat schon einen Sinn. Keine Lösung kann komplett für sich alleine existieren.

  • Wenn du schon mit domain name anstatt IP verbindest und wenn dir ein Angreifer eine andere IP Adresse unterjubeln kann, weil DNS schlecht konfiguriert ist, dann wird er dir wahrscheinlich auch einen gefälschten DNS-RR unterjubeln können.


    Und selbst dann lehnt ein normaler SSH Client die Verbindung ab .. außer der SSH Client würde den gefälschten DNS-RR lesen und ihm vertrauen, dann würdest du in eine Falle tappen, die dieser Mechanismus erst möglich macht.

    Wenn der Angreifer hingegen Zugriff auf deine Keys hat, dann hast du sowieso schon verloren. Da ist DNS dann auch schon irrelevant.


    Wie gesagt, ich verstehe den Sinn nicht, aber vielleicht habe ich etwas übersehen?

    Trust wird bei SSH über Server/Client Keys hergestellt.


    Manche DNS-RR für Mail Server existieren ja auch nur, weil das Protokoll kaputt ist und z.B. vom Client ein Downgrade von TLS auf keine Verschlüsselung machen kann.

  • Ok, kurz im RFC gestöbert: dieser RR ist so gedacht, dass er über DNSSEC verifiziert wird. Ansonsten hätte man genau die Lücke geöffnet, die ich angeführt habe.

    Es wird übrigens beschrieben, dass der Client bei Übereinstimmung dann *automatisch* neue Server Keys annehmen kann.


    Schräg.

    Wenn ich schon regelmäßig neue User habe, die sich alle immer wieder zum ersten Mal auf den Server verbinden, dann kann ich ihnen den Server-Key-Fingerprint über den gleichen sicheren Kanal zukommen lassen wie die Serverdaten selbst...

  • So schräg ist das nicht.


    1. lässt man nicht den Benutzern "Zugangsdaten zukommen", sondern man berechtigt die PubKeys der User sich dort anmelden zu dürfen. Somit ist da kein "sicherer Kanal" im Sinne von Vertraulichkeit nötig.


    2. hat das Hinterlegen von Server-Keys im DNS vor allem dann große Vorteile, wenn man sehr viele Server betreibt und / oder diese häufig (z.B. automatisiert) neu initialisiert - z.B. weil es sich um VMs, Container etc handelt.

  • Wenn du schon mit domain name anstatt IP verbindest und wenn dir ein Angreifer eine andere IP Adresse unterjubeln kann, weil DNS schlecht konfiguriert ist, dann wird er dir wahrscheinlich auch einen gefälschten DNS-RR unterjubeln können.

    Nicht zwangsläufig. Ein Angreifer könnte sich auch als MITM einklinken und sich als der Zielserver ausgeben, indem er alle Pakete zur Ziel-IP abfängt und beantwortet. Wenn er die Kontrolle über den Netzwerkverkehr hat, braucht er dir gar keinen falschen RR unterzujubeln. Letzteres alleine würde eventuell gar nichts bringen, weil das Opfer vielleicht einen eigenen Resolver am Client betreibt und diesen speziell geschützt hat. (DNSSEC, DNSCrypt, DoT, …)

  • So schräg ist das nicht.


    1. lässt man nicht den Benutzern "Zugangsdaten zukommen", sondern man berechtigt die PubKeys der User sich dort anmelden zu dürfen. Somit ist da kein "sicherer Kanal" im Sinne von Vertraulichkeit nötig.


    Und die PubKeys der User bekommst du über unsichere Kanäle zugesandt, die du dann blind akzeptierst? Ich denke nicht.

    Bei SSH MUSS ein sicherer Kanal initial für den Austausch der Schlüssel verwendet werden. Sowohl von Client- als auch Server-Keys.

    Da führt kein Weg daran vorbei.


    Quote

    2. hat das Hinterlegen von Server-Keys im DNS vor allem dann große Vorteile, wenn man sehr viele Server betreibt und / oder diese häufig (z.B. automatisiert) neu initialisiert - z.B. weil es sich um VMs, Container etc handelt.

    Wenn man viele VMs, Container, etc. wartet, dann wird man das vernünftigerweise automatisiert und über sichere Kanäle machen.

    Entsprechend kann man mit selbigen Automatisierungstools über selbige sichere Kanäle auch Keys austauschen. Musst du sowieso, wenn du dich mit PubKey einloggen willst. Entsprechend kannst du so auch die Server-Key-Fingerprints rausschreiben.


    Aber ja, wenn man stattdessen immer die DNS-RR Einträge alle aktualisiert, das richtig konfiguriert ist (DNSSEC ist hierfür eine Voraussetzung und eine hohe TTL wäre wahrscheinlich schlecht) und der Client/Resolver das auch unterstützt, dann muss man bei den Clients theoretisch nichts mehr machen.

  • Nicht zwangsläufig. Ein Angreifer könnte sich auch als MITM einklinken und sich als der Zielserver ausgeben, indem er alle Pakete zur Ziel-IP abfängt und beantwortet. Wenn er die Kontrolle über den Netzwerkverkehr hat, braucht er dir gar keinen falschen RR unterzujubeln. Letzteres alleine würde eventuell gar nichts bringen, weil das Opfer vielleicht einen eigenen Resolver am Client betreibt und diesen speziell geschützt hat. (DNSSEC, DNSCrypt, DoT, …)

    Das Unterjubeln eines falschen RR würde ja eine neue Lücke öffnen, die es vorher gar nicht gab, weil der Client dann theoretisch den SSH-Server des Angreifers (mit anderem Server-Key) blind akzeptieren könnte/würde. Aber wie danach erwähnt ergibt der RR eh nur dann Sinn, wenn der Kanal auch sicher ist - also DNSSEC.


    MITM auf IP Ebene hilft dem Angreifer bei SSH relativ wenig, eben weil die Keys zuvor durch einen sicheren Kanal ausgetauscht wurden.

  • MITM auf IP Ebene hilft dem Angreifer bei SSH relativ wenig, eben weil die Keys zuvor durch einen sicheren Kanal ausgetauscht wurden.

    Ja, genau. :D Zumindest theoretisch.


    Mal ernsthaft: Wieviele Leute "Unknown host key? Joa, akzeptier ich mal." Schön finde ich, dass SSH nicht anbietet, einen geänderten Key nicht einfach zu überschreiben sondern echt lautstark meckert. Nur das Thema "unknown key" finde ich noch... zu bequem zu lösen ohne sicheren Austausch.

  • Ja ich meine, wenn man Keys initial nicht über einen sicheren Kanal austauscht, dann hat man auch keine Authentifizierung.

    In den meisten Fällen wird es gut gehen, aber wenn dann mal was schiefläuft heißt es nur SSKM: selber schuld, kein Mitleid.


    Ist ein bisschen so, wie wenn man auf einen Link in einer Mail klickt und dann vermeintlich auf einer Webseite seiner Bank landet und sich dort dann direkt einloggt...

  • Das System des "Trust on First Use" (neuen Pubkey beim Ersten Kontakt zum Server akzeptieren und eine Änderung mit einer Warnung zu versehen) ist besser als gar kein Schutz, aber bei Anwendern die wie Schimpansen darauf dressiert sind alle Warnungen stets "wegzuklicken" ohne der Ursache nachzugehen geht dieser Schutz freilich ins Leere.


    customer - Du hast mich zwar vollständig zitiert, Dein Einwand es braucht einen "sicheren Kanal" um PubKeys auszutauschen ignoriert jedoch den zweiten Halbsatz im Zitat. Ich schrieb Zitat: "Somit ist da kein "sicherer Kanal" im Sinne von Vertraulichkeit nötig."


    Dass es dennoch einen Integritätsschutz braucht steht außer Frage, aber - wie ich ganz deutlich schrieb - es braucht keinen sicheren Kanal im Sinne von Vertraulichkeit.

    Um die Integrität zu prüfen kann man z.B. ganz simpel auch wie folgt vorgehen: Ich kann meinen SSH-Key dem Server-Admin per ungeschützter Klartextmail an dessen gehackten GMAIL-Account übermitteln. Der Server-Admin empfängt das Mail und ruft mich anschließend am abgehörten GSM-Telefon zurück und fragt mich "Hast Du mir gerade deinen SSH-Key gesendet? OK. Hat der an der 10ten Stelle ein C? OK und an der 20ten Stelle ein O? OK und die letzte Stelle ein kleines w? OK, danke, ich berechtige Dich.
    Trotz unsicherer Kanäle kann mit diesem simplen Verfahren ein ausreichender Integritätsschutz gewährleistet werden. Dazu muss man nicht erst SMIME/GPG ausrollen oder persönliche Übergabe auf USB-Stick durchführen.

  • Sorry, das habe ich tatsächlich überlesen. Natürlich sind public keys nicht vertraulich.

    Was man jedoch braucht ist Integrität und Authentizität.


    Ach ja, Anwender, die sich wie Schimpansen verhalten würde ich erst gar nicht auf meine Server lassen. ;)

    Fehlt nur noch ein Admin, der sich genauso verhält und jeden unsicher übertragenen PubKey blind akzeptiert.