Beiträge von hardfalcon

Gibt's eventuell ne Möglichkeit, in die Kohorte derjenigen zu gelangen, deren VMs-Hosts als erste geupdatet/rebootet werden (vulgo: Beta-Tester)?

Ein paar Reboots mehr oder weniger stören mich nicht sonderlich, aber mein Versionsnummerntourette wird ganz unruhig beim Gedanken, dass es noch fast nen Monat dauern wird bis der Node, auf dem meine VM liegt, endlich seine Microcode-Updates kriegt, und die entsprechenden Feature Flags auch an die VMs durchreicht… ?

Sorry, bearbeiten kann ich die eh nicht mehr. Ist das nur bei mir, oder ist dieser seltsame WYSINWYG-Editor bei andern Forennutzern ebenfalls so kaputt und unbrauchbar?

Der Vollständigkeit halber: sowohl der Bloom-Filter als auch PrefixSet sind nur ein Teil von Safe Browsing. Beide sind aus Performancegründen bewusst so ausgelegt, dass sie zwar niemals False Negatives (=ne "böse" Seite aus der Blacklist wird nicht erkannt) aber durchaus (selten, d.h. "alle paar tausend Seitenaufrufe") False Positives zurückliefern (=ne Seite, die gar nicht auf der Blacklist steht, wird vom Bloom-Filter/PrefixSet trotzdem als "könnte auf der Blacklist stehen" erkannt).

Aus diesem Grund dienen Bloom-Filter und PrefixSet nur als Entscheidungsgrundlage, ob der Browser überhaupt in der "richtigen" Blacklist nachschaut (dazu wird er dann in der Tat meist nach Hause telefonieren, weil die Blacklists natürlich immer größer werden, und man diesen Speicherplatzverbrauch eher nicht in jedem Download des Browser-Installers haben möchte). Wie dieser Teil der Blacklist dann konkret funktioniert, ist z.B. für Googles Safe Browsing (das AFAIK u.a. auch Firefox mitbenutzt) hier beschrieben:

https://developers.google.com/safe-browsing/v4/urls-hashing

Zitat von eripek

Ich weiss ja nicht, was der Browser noch so an Telemetrie in diesem Fall nach Hause sendet. Serverlogs wird es wohl geben. Verkehrsdaten sind es allemal. Die Judikatur zur Personenbezogenheit von IP-Adressen ist wechselhaft. Im Fall von IPv6 mit EUI64-Schema wäre eine Identifizierbarkeit anhand eines Endgeräts durchaus nicht von der Hand zu weisen. Im Falle eines NAT-CGN wäre dies allerdings zu verneinen... Das Bestehen der Aufklärungspflicht (etwa durch Datenschutzerklärung) ist daher durchaus nicht von der Hand zu weisen.

Die Blacklist ist lokal? Wie oft synchronisiert er die, um Schutz zu bieten? Keine Abfrage nach Hause?

Der Browser wird schon aus Performance-Gründen nicht vor jedem Seitenaufruf "nach Hause telefonieren" und auf eine Antwort warten können, bevor er ne Verbindung zum eigentlichen Zielserver aufbaut.

Browser, die sowas wie "Safe Browsing" implementieren, benutzen dafür oft nen sogenannten "Bloom-Filter" (ne normale Blacklist würde sowohl nen deutlich höheren RAM-Verbrauch als auch ne höhere CPU-Last verursachen):
https://de.wikipedia.org/wiki/Bloomfilter

Chrome/Chromium hat vor ner Weile vom Bloom-Filter auf ein noch effizienteres Konstrukt namens "PrefixSet" umgestellt:
https://bugs.chromium.org/p/chromium/issues/detail?id=71832

"Rausfinden wann in der TLD die Zone neu geladen wird" geht, ist aber auch eher fummelig, und ein ziemlicher Aufwand, den dann jeder Kunde für jede Domain auf sich nehmen muss, anstatt dass das eigentliche Problem an der richtigen Stelle (im CCP) ein für alle Mal sauber und nachhaltig gelöst wird.

DNSSEC abschalten geht, ist aber auch ne eher dreckige Lösung, und führt nebenbei auch dazu, dass diverse Record-Typen während der Migrationsphase de facto nicht funktionieren (z.B. SSHFP, TLSA, SMIMEA, OPENPGPKEY, oder auch die TXT-Records für MTA-STS).

Letztlich sind das alles dreckige und umständliche Hacks, die nicht nötig wären, wenn das CCP schlicht das anbieten würde, was (aus guten Gründen) technisch möglich ist, anstatt die Möglichkeiten, die man als Kunde hat, aus Nonsens-"Gründen" zu beschränken.

Zitat von killerbees19

Zu mindestens diese beiden Punkte könntest Du über die CCP/DNS API selbst lösen: https://www.netcup-wiki.de/wiki/DNS_API

Für Letzteres gibt es auf GitHub schon etwas: https://github.com/stecklars/dynamic-dns-netcup-api

Für den ersten Punkt gibt es derzeit maximal Scripte für ein allgemeines Backup. Ein direkter Import von Bind-Konfigurationsdateien ist damit afaik noch nicht möglich. Das müsste erst jemand programmieren.

Danke für den Hinweis, aber "BIND-File runterladen" sollte schlicht ein Button/Link im CCP sein, und nichts, wofür ich mit der API rumfrickeln und erst noch irgendwelchen Third-Party-Code von Github ausführen muss in der Hoffnung, dass der schon keinen Unsinn mit meinem API-Zugang anstellt.

Bitte nimm das nicht persönlich, aber "Die Netcup-API für DynDNS benutzen" ist (genau wie auch bei mehr oder weniger allen anderen Anbietern, die so nen Zugang anbieten) IMHO gemeingefährlicher Unfug - um einen einzelnen simplen A-/AAAA-/TXT-Record zu updaten, klatschst du da auf ein im Zweifelsfall nicht vertrauenswürdiges Gerät Logindaten, mit denen man deinen ganzen Kundenaccount übernehmen und in deinem Namen kostenpflichtig Dinge bestellen kann. Die API ist für Domainreseller gedacht, nicht für DynDNS.

[EDIT]
Die sicherere Notlösung für das DynDNS-Problem wäre übrigens, sich bei nem externen Anbieter (gibt auch in Deutschland welche, die das kostenlos und mit DNSSEC anbieten) ne DynDNS-Subdomain für das betreffende Gerät zu holen, und bei der "richtigen" Domain, die man bei Netcup liegen hat, nen CNAME auf die DynDNS-Subdomain des externen Anbieters zu setzen.
[/EDIT]

Ansonsten noch ein weiterer "Nice to have"-Vorschlag: Das Webinterface sollte beim Umzug von Domains, beim Umstellen einer Domain von den Netcup-Nameservern auf externe Nameserver und beim Bearbeiten der Einträge für externe Nameserver Dinge automatisch erkennen/vorschlagen, die es es erkennen kann. Z.B. sollte es reichen, wenn ich eine IP-Adresse oder den Hostname eines Nameservers eintippe, damit das Webinterface sich von diesem Server gleich die NS-Records für diese Zone und ggf. die dazugehörigen IP-Adressen für etwaige Glue Records abfragen und vorschlagen kann. Genauso könnten auch DNSKEY- bzw. DS-Records automatisch erkannt und vorgeschlagen werden.

Und um den Umzug von Mitbewerbern zu Netcup noch ein wenig einfacher zu gestalten, könnte man z.B. auch ne Möglichkeit anbieten, vor dem Domaintransfer einzelne DNS-Labels per ANY-Abfrage beim alten Nameserver abzufragen (würde viel Zeit sparen in Situationen, wo der Kunde kein Zonefile der Zone besitzt, und in der Zone vllt. nur wenige Label, aber viele Records pro Label hat).

Zitat von [netcup] Johannes

Vielen Dank für die netten Worte. Es ist schön so nette Kunden zu haben.

Aktuell werden nach meinen Informationen die Algorithmen nur von der Registry für .ch und .li Domains unterstützt. Wir können nur anbieten was die jeweilige Registry auch unterstützt.

CentralNIC (die einige der "größeren" gTLDs betreiben) unterstützen wohl auch alle Algorithmen, inkl. 15 und 16:
https://twitter.com/GavinBrown/status/1062448026717949953
Allerdings war der Support für Algorithmus 15 (ed25519) zumindest in BIND bis vor Kurzem (< 9.13.4) kaputt und in der Praxis nicht benutzbar. Und Algorithmus 16 (ed448) wird zumindest von BIND bis heute nicht unterstützt (zumindest nicht um damit Einträge zu signieren).

Moin,

mir fehlen bislang einige (meines Erachtens teils essenzielle) Features in der DNS-Verwaltung im CCP. Ich schreibe hier ausschließlich aus der Perspektive "nackte Domain über Netcup registriert bzw. zu Netcup transferiert", ohne irgendwelche zusätzlichen Netcup-Produkte, die möglicherweise noch am DNS dranhängen könnten.

Essenzielle Features, um Migrationen ohne Downtime zu ermöglichen:

• Möglichkeit, die Netcup-Nameserver schon vor dem eigentlichen Domaintransfer so weit zu konfigurieren, dass beim Domaintransfer wirklich nur noch die NS-Records in der TLD-Zone geändert werden müssen (inkl. DNSSEC-Signaturen, nur halt ohne die entsprechenden Einträge in der TLD-Zone). Um Missbrauch vorzubeugen, könnte man z.B. den eigentlichen Domaintransfer zeitlich hinter den Klick auf den "kostenpflichtig bestellen"-Button verlagern. Ohne dieses Feature kann man Domains nicht ohne Downtime zu Netcup umziehen.
• Möglichkeit, schon vor der Umstellung einer Domain von den Netcup-Nameservern auf eigene/externe Nameserver zusätzliche DS-Records und Glue Records in der jeweiligen TLD-Zone eintragen zu lassen.
• Ne dreckige und unvollständige Alternative zu den beiden o.g. Features wäre u.U. noch die Möglichkeit, den Netcup-Nameservern für eine Domain eigene Private Keys als DNSSEC-KSK zu geben, bzw. den Private Key des KSK im CCP-Webinterface herunterladen zu können, wenn man von den Netcup-Nameservern auf externe Nameserver umstellen will.

Mit "Downtime" ist hier gemeint "Hosts im Internet behandeln die Domain als nicht existent". Beispiel: Wenn im Rahmen einer eines Domainumzugs auf die Netcup-Nameserver die DNSSEC-Signaturkette der Zone kaputtgeht, weil man nicht vorhersehen konnte welchen DNSKEY die Netcup-Nameserver als KSK für die Zone erzeugen/verwenden werden, dann kriegt man für Einträge in der Zone von validierenden DNS-Resolvern nur noch ein "SERVFAIL" zurück. Wenn ein Mailserver versucht, an so eine Domain Emails auszuliefern, dann wird er die Emails nicht zwischenspeichern und warten bis die Domain wieder verfügbar ist, sondern die Emails schlicht verwerfen, und dem Absender ne Fehlermeldung à la "Die Domain gibt’s nicht" schicken. Sowas macht natürlich besonders viel Freude, wenn Nutzer von Emailadressen unter dieser Domain z.B. auf eine größere Anzahl Mailinglisten abonniert sind. Aber selbst wenn da nur ein einzelner Nutzer dranhängt, risikiert man immer noch ne Downtime von 24h, denn bei vielen DNS-Anbietern kann man die TTL des SOA-Records und der ganzen DNSSEC-Einträge nicht beeinflussen - da steht öfter mal ein Wert von irgendwo zwischen einer Stunde und einem Tag drin. Daher ist das IMHO auch klar ein essenzielles Feature, und nicht bloß ne "nice to have"-Geschichte.

Ansonsten hätte ich auch noch ein paar "Nice-to-have"-Feature-Vorschläge:

• Import und Export von BIND-Zonefiles (damit man sich nicht für jeden einzelnen DNS-Record im Webinterface dumm und dämlich klicken muss)
• Unterstützung für Dynamic Updates (abgesichert per TSIG- oder SIG0-Keys, optimalerweise granulierbar bis runter zum einzelnen Record/Record-Typen, so wie das bei Bind z.B. mit "update-policy" möglich ist)
• Möglichkeit, einzelne Records für DynDNS über HTTP(S) zu verwenden, wenn man die Netcup-Nameserver nutzt
• Möglichkeit, die Netcup-Nameserver als Slaves zu benutzen (damit man nicht extra nen zweiten Server nur als Fallback-Nameserver braucht, wenn man sein seine Zone komplett selber verwalten möchte)
• Möglichkeit, den/die DNSSEC-Signaturalgorithmen für die eigene Zone auszuwählen, wenn man die Netcup-Nameserver nutzt (optimalerweise inkl. der Möglichkeit, eigene Private Keys zu konfigurieren)
• Für die Hardcore-Nerds: Möglichkeit, die NSEC3-Parameter zu konfigurieren

Moin,

könnt ihr bitte die MSRs/Feature Flags für die ganzen Spectre-Mitigations an die VMs durchreichen? Konkret wären das z.Z. folgende Feature Flags:

• IBRS (gegen Spectre v2, MSR "spec_ctrl")
• IBPB (gegen Spectre v2, MSR "pred_cmd")
• STIBP (MSR "spec_ctrl", nur relevant wenn Hyperthreading verwendet wird)
• SSBD (gegen Spectre v4)

Die Microcode-Updates mit IBRS, IBPB und STIBP sind schon seit Ende Januar/Anfang Februar veröffentlicht, die Updates mit zusätzlicher Unterstützung für SSBD und nem Microcode-Fix gegen Spectre v3a hat Intel vor einigen Tagen endlich auch mal "offiziell" veröffentlicht (nachdem es die je nach Mainboard-Hersteller auch schon 1-2 Monate vorher als BIOS-Update gab). Da Intel die Microcode-Updates endlich auch selber veröffentlicht hat, kann man die auch dann auf den Hostsystemen ausrollen, wenn der Mainboard-Hersteller nicht aus dem Quark kommt, oder man aus sonstigen Gründen kein BIOS-Update installieren kann/will. Wenn man die Microcode-Updates ohne Downtime/Reboot laden will, kann man sie statt als initramfs-Image auch im laufenden Betrieb per microcode_ctl nachladen (die Variante über das BIOS-Update oder über das Initramfs-Image ist natürlich trotzdem vorzuziehen, damit der Kernel auf dem Hostsystem die Mitigations ab dem frühestmöglichen Zeitpunkt anwenden kann).

Ohne diese Feature können die VMs sich im Zweifelsfall nicht vollständig gegen einige Varianten der Spectre-Lücken schützen - retpoline alleine reicht leider nicht auf allen CPU-Generationen als vollständiger Schutz gegen Spectre v2 aus, und gegen Spectre v3a und Spectre v4 helfen wohl generell nur Microcode-Updates.

Grüße
Pascal

//EDIT: Nachtrag: Das Tool der Wahl, um in einer Linux-VM zu testen, welche Mitigations verfügbar sind, gibt es übrigens hier.