Beiträge von gunnarh

    Fehlercode SC-001 scheint mir nicht zu bedeuten, dass Du auf der Microsoft-Blacklist stehst, eher das du auf irgend einer Blacklist stehst, prüfe das mal z.B. mit http://rbl-check.org/


    Man kann dir übrigens schlecht helfen, denn mir scheint Du hast im Ursprungsposting Angaben verschleiert die zur Beurteilung nötig wären - denn die teils unkenntlich gemachte IP-Adresse Deines MTA passt mit mail.xy.eu nicht zusammen, ich bezweifle, dass es um die Domain xy.eu geht.

    Mein Feedback: Schließe mit thys und Hecke29 an. Euer Engagement ist gut gemeint - und vermutlich macht es euch Spaß und ihr lernt was dabei. Aber auch mir ist die Zielgruppe dieser Lösung unklar.


    Was ihr hier tun möchtet ist klassische "Desired State Configuration".

    Server nehmen, sagen welche Dienste drauf sollen, und ein Mechanismus soll sich vollautomatisch um die Provisionierung kümmern.

    Das löst man heute nicht mehr mit Scripts, sondern mit Puppet oder dem schon genannten Ansible. Module auf denen man aufsetzen kann finden sich zur Genüge, man kümmert sich nicht mehr um das "wie konfiguriert man das" sondern legt schlicht nur mehr fest wie die Konfiguration aussehen soll.


    Ist der Server mal "verkonfiguriert" wird der Agent einfach erneut aufgerufen und stellt die gewünschte Konfiguration wieder her. Ist nichts zu tun, weil die Config bereits wie gewünscht vorliegt tut der Agent auch nichts (desired state config / idempotent aufrufbar).

    Jemand der ein gehobenes Schutzniveau benötigt wird wohl kaum ein Shared-Webhosting dafür nutzen.

    Immerhin teilt man sich dabei nicht nur die TLS-Settings mit allen anderen Kunden. Man teilt sich das OS, die Webserver- und die Datenbank-Instanz. Wer ein überdurchschnittliches Schutzniveau sucht oder benötigt, wird daher Wert auf Abschottung des Systems legen und sich nicht die angesprochenen Software-Instanzen mit anderen Unbekannten teilen, sondern im Minimum eine eigene (virtuelle) Maschine für seine Bedürfnisse nutzen.

    Auch für Android 4 und Java 7 gibts es keine Patches mehr.

    Der Verbreitungsgrad ist dennoch nicht auf 0% abgesunken.


    Als Anbieter von Content habe ich die freie Wahl des Anbieters, der Lösung und des Schutzniveaus.

    Was ich mir jedoch nicht direkt aussuchen kann ist, mit welchen Clients meine Nutzer zugreifen.


    Auf meinem eigenen Server kann ich freilich eine Entscheidung treffen, und den Trade-Off Kompatibilität versus Security in Richtung Security verschieben. Damit nehme ich dann eben in Kauf, dass nicht mehr alle Anwender meine Inhalte nutzen können.


    Auf einer Shared-Hosting-Plattform (die man sich ja mit anderen teilt) muss dieser Trade-Off jedoch ausgewogen und dem typischen Content und Schutzbedarf angepasst gewählt werden. Hier zu fordern, dass TLS 1.0 und 1.1 ausgeschaltet werden müssen erscheint mir persönlich überzogen. Immerhin hosten darauf die Mehrzahl der Kunden vermutlich nur einfache Informationsangebote, deren Interessenten dann eventuell ausgesperrt sind. Oder wie erklärst Du dem Betreiber einer Frühstückspension, warum die Windows XP nutzenden Kunden aus Asien plötzlich ausbleiben und nicht mehr Preise und Zimmerausstattung nachschauen können?

    Die Diskussion hier vergisst aus meiner Sicht auf einen sehr wesentlichen Aspekt: Welchen Wert haben denn die Daten, die auf shared Webhosting-Accounts bei NetCup liegen? Ich mutmaße mal, dass die Vertraulichkeits- und Integritäts-Anforderungen für 99% der Kunden die hier Webhosting-Accounts nutzen völlig egal sind. Da liegen vermutlich ohnehin nur die im Public-Web frei verfügbar gemachten Inhalte drauf.


    Ich bin auch kein Fan davon, alte CipherSuites bis zum Sankt-Nimmerleinstag weiter zu unterstützen. Aber auf Shared-Webhosting legt doch hoffentlich niemand sensible Daten ab, die dann ausschließlich mittels starker Chiffren ausgeliefert werden dürfen? Wenn jemand solche Anforderungen hat, dann wird er mit diesem Requirement wohl eher einen Managed-Server wählen oder sich der Sache selbst annehmen - immerhin werden diesbezüglich ja im Produkt-Angebot auch keinerlei Zusagen gemacht.


    Wer sich einen Überblick verschaffen möchte, welche Clients welche Crypto-Merkmale unterstützen, dem sei diese Übersicht hier ans Herz gelegt:

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

    Man muss übrigens gar kein Windows XP einsetzen, um von der Thematik betroffen zu sein. Ein 3 Jahre altes Android-Phone mit Android 4 oder eine Java7-Applikation reichen auch aus, um mit einem "streng" konfigurierten Server nicht mehr kommunizieren zu können.

    Um welche Domain / Subdomain gehts?


    plausible Gründe könnten ins Blaue geraten sein:

    1. ein oder mehrere autoritative Nameserver ausgefallen bzw. gestört
    2. Nameserver nicht synchron
    3. DNSSec aktiviert? Wenn ja eventuell Signaturen abgelaufen / ungültig (geworden).
    4. IPv6 enabled? Eventuell Records inkl. Glue-Records zu groß um in einem UDP Paket beauskunftet werden zu können.

    Das müsste eigentlich die Funktion "Herunterfahren (ACPI)" aus dem Server Control Panel sein.
    Wenn das jemand über das SCP ausgelöst hat, dann wird das im SCP Protokoll mit "Server ACPI Stop Signal gesendet" vermerkt.
    Würde mal das SCP Protokoll prüfen, eventuell konnte sich jemand auf das SCP Zugriff verschaffen.


    Wenn dort nichts verzeichnet ist, würde ich den Support fragen - vermutlich musste der Host neu gestartet werden.

    Ich kenne Plesk nicht, aber eine kurze Google-Recherche zeigt mir, dass man mit Plesk sehr wohl die Firewall als auch die Settings der nginx vHosts konfigurieren kann.


    Wenn Du meinst das fällt in den Aufgabenbereich von Netcup, dann wende Dich an den Support. Ich persönlich würde angesichts der Produktbeschreibung aber davon ausgehen, dass alles was über Plesk konfiguriert werden kann eher in deine Sphäre fällt. Vielleicht kann Dir hier im Plesk-Subforum jemand weiterhelfen, andernfalls halt ein spezialisiertes Plesk-Forum, die Doku oder doch den Support bemühen.

    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.


    Zitat


    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.