Posts by gunnarh

    Du hast uns keinerlei Infos zu Deinem System gegeben.
    Kaffeesud-lesen ist daher etwas schwer.


    Meine Glaskugel sagt mir, dass Du nginx und Plesk 12.5.30 auf einem Debian 8 System einsetzt?


    Offenbar gibts bei diesem vHost ein Problem mit der ServerNameIndication, sodass zumindest zeitweise das falsche Plesk-Default-Zertifikat ausgeliefert wird.
    Ich mutmaße mal, doppelt angelegter vHost/Alias-Name oder sowas in der Richtung. Ohne Deine Configs zu kennen ist das aber nur herumraterei.


    Übrigens: Dein System exponiert eine mySQL/MariaDB ohne Firewall nach außen - das ist aus Security-Sicht eher nicht best practice.

    Code
    file "/var/cache/bind/123.de.zone.signed";


    Das ist falsch, du musst in der Zone das unsignierte, menschenlesbare Textfile konfigurieren, nicht das signierte!
    Das .signed File sowie die Journale .jnl werden dann aufgrund der Konfiguration mit "auto-dnssec maintain; inline-signing yes;" völlig automatisch von Bind verwaltet.


    Wenn Bind die zone neu signiert, dann ändert sich auch automatisch die Serial um ein paar Ticks nach oben.


    Du kannst die signierte Zone (die ja nicht menschenlesbar ist, also ein Binärfile, kein Textfile) folgendermaßen prüfen:

    Code
    named-checkzone -D -i full -f raw $domain $ZONEDIR/$domain.signed >/tmp/$domain.txt
    ldns-verify-zone /tmp/$domain.txt -S -V 4 -k $KSK -k $ZSK

    Danke für den Pointer auf mein Blog ;)
    Ergänzend sei noch mein DANE-Tutorial hier genannt: https://hitco.at/blog/sicherer…ste-anbieter-dnssec-dane/


    Schlüsselpaar alle 60-90 Tage wechseln ist meines Erachtens etwas übervorsichtig und muss nicht sein (siehe meinen Blog-Beitrag der bereits zuvor zitiert wurde).


    Falls Du das Schlüsselpaar wechseln willst, dann musst Du - bevor Du es verwendest - jedenfalls rechtzeitig den TLSA-Record für DANE aktualisieren (also ergänzen, alten drinnen belassen und neuen zusätzlich hinzufügen). So rechtzeitig, dass alle Resolver sicher schon den neuen Record erhalten haben (abhängig von Deiner DNS Zonen-Konfiguration). Erst dann darfst Du das Zertifikat produktiv verwenden.


    Eine Automatisierung wäre denke ich nicht wirklich schwer, ich würde schematisch so vorgehen:


    Code
    export CERT=/etc/letsencrypt/live/it-security.eu.org/cert.pem
    export UpdateFile=/tmp/dns-update.txt
    echo zone it-security.eu.org>$UpdateFile
    openssl x509 -in $CERT -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -hex | cut -f2 -d" " | xargs echo "update add _443._tcp.test.it-security.eu.org. 1200 TLSA 3 1 1" >>$UpdateFile
    echo send>>$UpdateFile


    Das erzeugt ein File /tmp/dns-update.txt mit folgendem Inhalt:

    Code
    zone it-security.eu.org
    update add _443._tcp.test.it-security.eu.org. 1200 TLSA 3 1 1 a46dd6b2cb43b1f32445d1778410a55d1298c712942483aef03c1a6c6f0c16b5
    send


    Dieses kann mittels nsupdate dann an den Nameserver übergeben werden:

    Code
    nsupdate -v -d $UpdateFile


    Was hier noch fehlt ist, einen TSIG-Key festzulegen und diesen mittels "key" noch im Update-File zu hinterlegen, sonst wird der Nameserver (je nach Konfiguration) das Update nicht zulassen.


    Nachtrag: So würde ich bei meinen Nameservern vorgehen. Ob das mit den NetCup Nameservern auch so möglich ist, ist mir nicht bekannt. Kann man bei diesen einen TSIG-Key für automatisierte Updates hinterlegen? Wenn ja, dann würde das denke ich so funktionieren, wenn nein müsste NetCup einen Mechanismus bzw. eine API etc... bereitstellen.

    1. Soweit ich sehe, fehlt dir das v6 Default Gateway, bei mir sieht das folgendermaßen aus:

    Code
    root@nc:~# ip -6 r
    2a03:4000:6:71ec::/64 dev ens3  proto kernel  metric 256  pref medium
    fe80::/64 dev ens3  proto kernel  metric 256  pref medium
    default via fe80::1 dev ens3  metric 1024  pref medium


    Im NetCup Wiki ist die Config der /etc/network/interfaces korrekt beschrieben (inklusive Gateway):
    https://www.netcup-wiki.de/wik…sse_konfigurieren#IPv6%7C



    2. ein "ping6 fe80::1" kann nicht funktionieren, diese Adresse ist eine Link-lokale Adresse, somit mehrdeutig (könnte auf jedem Interface zu finden sein), man muss das Interface daher zwingend mit angeben, z.B.:

    Code
    root@nc:~# ping6 fe80::1 -I ens3
    PING fe80::1(fe80::1) from fe80::c4d2:beff:fea2:53f4 ens3: 56 data bytes
    64 bytes from fe80::1: icmp_seq=1 ttl=64 time=0.554 ms
    64 bytes from fe80::1: icmp_seq=2 ttl=64 time=0.568 ms

    Das die .net Registry andere Syntax nutzt als die .de Registry kann sein.
    Technisch gesehen läuft es aber immer auf das gleiche raus. Du gibst die Werte des KSK (257) an, in Deinem Fall die des Schlüssels 29115.


    Quote


    syncookie.de. IN DS 29115 7 1 BB3553956DC52388B7A36DC526DBC2DD5D36A82D
    syncookie.de. IN DS 29115 7 2 9008BC78042FA31CF513DA72670C15E63C29B98A2858683900CDE3C0 6E541D7C


    29115 ist die ID deines KSK
    7 der Algorithmus RSASHA1-NSEC3-SHA1
    1 steht für SHA1 und 2 steht hier für SHA256. Du musst in der Weboberfläche nur einen der beiden hinterlegen.


    Hier ist 1 und 2 nicht mit dem SHA1 im 7 des Alorithmus zu verwechseln. 1 und 2 sind hier lediglich zwei Varianten den Hash Deines DS-Pubkeys zu bilden, während der Algorithmus 7 fix SHA1 beinhaltet - an dieser Stelle hätte ich Dir wie gesagt empfohlen gleich von Beginn an Algorithmus 8 (RSA SHA256) zu nutzen und wie gesagt die Schlüssellänge des KSK auf 2048 zu reduzieren, für den ZSK ist sogar 1024 ausreichend, da dieser automatisiert periodisch geändert werden kann.


    Vielleicht hilft Dir auch mein hier veröffentlichtes PDF-Dokument:
    Sicherer E-Mail-Dienste-Anbieter (DNSSec & DANE) ← Gunnar Haslinger
    Im hier erhältlichen Dokument ist das Procedere der Hinterlegung beim Registrar auf Seite 30 erläutert.

    In der übergeordneten .de Zone wird nur ein DS-Record der auf den Key Signing Key (=Flags 257) zeigt erstellt, das ist bei dir in der syncookie.de Zone der mit ID 29115. Ich habe meine Domains nicht bei netcup registriert, kenne daher deren WebOberfläche (CCP) nicht. Aber der ZSK (=Flags 256) hat im CCP jedenfalls nichts zu suchen.


    Generell fällt mir auf:
    RSA 4096 zu verwenden halte ich für übertrieben, gerade weil aufgrund der Paket-Größen Problematik die DNS-Antworten kurz sein sollten, würde ich derzeit noch auf RSA 2048 setzen.
    Bei einer neuen Domain noch SHA1 zu verwenden würde ich nicht mehr tun, würde jetzt tunlichst schon mit SHA256 starten.

    Das österreichische StartUp https://nimbusec.com/ beschäftigt sich mit dieser Problemstellung.
    Wobei die nicht den fehleranfälligen PHP-Code detektieren, sondern deren Algorithmen durchforsten die PHP-Files am Server und sollen recht zuverlässig WebShells detektieren. Wenn man das also täglich oder mehrmals täglich laufen lässt, dann hat man zumindest eine Einbruchserkennung (die meisten Angriffe hinterlegen irgend einen Codeschnippsel der eine WebShell bereitstellt).

    n1, ns2, …? :)


    Dass man mehrere NS Records hinterlegt ist klar und war denke ich nicht gemeint.


    Angenommen jemand hat ein /47er Netz, dann ist für ein /47er Netz ja keine Delegation per NS-Record möglich. Man kann zwei /48 eintragen um ein /47er abzubilden - das war denke ich gemeint.
    Aber für alle durch 4 teilbare IPv6 Netze ist eine unmittelbare Delegierung ohne Tricks möglich.


    für IPv4-Adressen


    Die lassen sich nur an den durch 8 teilbaren Netzgrenzen delegieren, also im Minimum ein /24er IPv4 Netz.

    Quote

    Der eine Anbieter hat es dabei wie folgt umgesetzt, dass er einfach für mein spezifischeres /48 Netz ein/mehrere NS-Records zu meinen Nameservern erstellt hat.


    Verstehe ich nicht. Hilf mir mal bitte den Knopf in meinem Kopf zu lösen.
    Die ip6.arpa Einträge sind an jedem HEX-Zeichen der IPv6 Adresse möglich, somit sind an allen durch 4bit teilbaren Netzgrößen auch NS-Records setzbar.


    Beispiel: IP Adresse 2a03:4000:6:71ec::cafe

    Code
    dig -x 2a03:4000:6:71ec::cafe
    ...
    ;; ANSWER SECTION:
    e.f.a.c.0.0.0.0.0.0.0.0.0.0.0.0.c.e.1.7.6.0.0.0.0.0.0.4.3.0.a.2.ip6.arpa. 86052 IN PTR nc.hitco.at.
    ... 
    ;; AUTHORITY SECTION:
    0.0.0.4.3.0.a.2.ip6.arpa. 153456 IN NS root-dns.netcup.net.
    ...


    Die NetCup Nameserver sind hier für das Netz 2a03:4000::/32 zuständig (8 HEX-Zeichen x 4bit = 32bit)


    Will ich für mein Netz 2a03:4000:6:71ec::/64 einen eigenen Nameserver nutzen, so müsste NetCup in deren root-dns.netcup.net Nameserver einen NS Record auf meinen Nameserver setzen, und zwar an dieser Position hier:

    Code
    c.e.1.7.6.0.0.0.0.0.0.4.3.0.a.2.ip6.arpa. ... IN NS ns1.hitco.at.


    Hätte ich ein /48er Netz, so wäre es eben nicht nach 16 sondern schon nach 12 Zeichen:

    Code
    6.0.0.0.0.0.0.4.3.0.a.2.ip6.arpa. ... IN NS ns1.hitco.at.


    Warum meinst Du, man müsste für ein /48er Netz mehrere Einträge erstellen? Habe ich hier einen Denkfehler?

    felix: Die NS Records wären nicht für das /32er Netz sondern nur für das /64er Kunden-Netz in eurem Nameserver einzutragen - denke das hast Du inzwischen aber bereits erkannt.


    Ich hätte an diesem Feature übrigens auch Interesse. Nachdem mir der komerzielle Anwendungszweck fehlt würde ich dafür zur Zeit jedoch kein Geld ausgeben.

    Dein Einwand ist vollkommen berechtigt, genau daher möchte ich ja nicht die Google-Resolver verwenden, sondern lokale Netcup Resolver die nur 1-2 Hops entfernt von meinem Server stehen.
    Ich kann freilich einen Resolver lokal betreiben, hätte dann aber gerne noch einen zweiten. Und ehrlichgesagt ist es mir schleierhaft was Netcup da als Resolver einsetzt - die mir bekannten Resolver beherrschen seit Jahren in der Default-Konfiguration DNSSEC - das muss also extra abgeschaltet worden sein.

    Mein Server bei Netcup nutzt folgende zwei DNS-Resolver (von Netcup zur Verfügung gestellt):
    46.38.225.230 46.38.252.230


    Diese beiden haben aber kein aktiviertes DNSSEC. Fragt man eine DNSSEC aktivierte Domain z.B. mit "dig +dnssec ..." ab, so wird kein AD-Flag (Authenticated Data) zurückgeliefert.


    Ich könnte freilich einfach die Google-Resolver 8.8.8.8 und 8.8.4.4 verwenden, die liefern bei DNSSEC aktivierten Domains korrekt das AD-Flag, somit könnte ich damit einen Mailserver der ausgehend mit DANE arbeitet einfach in Betrieb nehmen. Mir widerstrebt aber eigentlich die Google-Resolver auf meinem Rootserver zu konfigurieren.


    Stellt Netcup vielleich noch andere Resolver als die von mir oben genannten bereit, die DNSSEC beherrschen?

    Beziehe mich auf dieses Sonderangebot hier: RS 500 SAS G7SEa1 12M
    https://www.netcup.de/bestellen/produkt.php?produkt=1607


    Festplatte: 4 x 120 GB SAS, "sieht" man in der VM wirklich 4 Stück Disken je 120GB, oder wird das bereits vom Hostsystem als eine virtual Disk durchgereicht? Effektiv nutzbar sind dann vermutlich 240GB?


    Konnte leider nichts zur Netzwerkanbindung finden. 100MBit oder Gigabit?


    Gibt es (abgesehen von CPU/RAM/HDD) noch andere Abweichungen zu den regulären RootServern?
    netcup GmbH - Root-Server


    Konkret: Rettungssystem, Snapshot-Export, DDoS-Schutz, IPv6-Adressen - identisch zu den größeren nutzbar?