Wie man die neue Kernellücke DirtyFrag abwehrt

Moin,

ja, schon wieder eine Lücke im kernel die Rootrechte gibt.. wird grade ein Volkssport so etwas zu finden 🙂

Wie man die neue Kernellücke DirtyFrag abwehrt

Ihr wehrt das ab, indem Ihr diese 4 Kernel-Module blacklistet:

Legt als Root eine Datei an : „/etc/modprobe.d/lockdown-esp.conf

Schreibt das hier rein:

install esp4 /bin/true
install esp6 /bin/true
install rxrpc /bin/true
install afs /bin/true

Eigentlich braucht man nur die ersten drei, aber afs konnte ich noch nie leiden 😉 Scherz beiseite, afs ist ein Modul für das Andrew File System und das pullt rxrpc rein, deswegen einfach mit listen.

dann führt Ihr „rmmod esp4;rmmod esp6;rmmod rxrpc;rmmod afs“ aus und wartet auf Kernel 7.04, der fixt das Problem.

In der zwischenzeit gehen alle VPNs nicht, die IPSEC brauchen, aber Wireguard und diverse andere VPNs (via ssh z.b.) brauchen IPSec nicht und laufen weiter. Seid flexibel 😉

 

Fahrplan für den Terror, Danke Denic.

Ich weiß nicht ob es allen klar ist, aber die DENIC hat mit dem gestrigen faktischen Ausfall aller DE Domains gezeigt, wie man ein Land heute destabilisieren kann.

DENIC legt alle Deutschen Domains mit einem Schlag lahm!

Fahrplan für den Terror, Danke Denic.

Das der Fehler von DENIC gestern Abend nicht zu einem totalen Chaos geführt hat, lag u.a. daran, daß DNS Daten gecacht werden. Obwohl alle DE-Domains nicht mehr aufgelöst werden konnten, waren einige Domains für bestimmte Menschen noch erreichbar, die dann meinten, daß es ja keinen Totalausfall gab. Ein technisches Missverständnis, daß auch zeigt, daß diese Menschen gar nicht wissen, wie das Internet und DNS funktionieren.

Konnten wirklich alle DE-Domains nicht mehr aufgelöst werden?

Diese spannende Frage erinnert irgendwie an die Einleitung eines jeden Asterix Bandes, und die Parallele stimmt auch. Heute beachten so ziemlich alle DNS-Resolver DNSSEC. Das ist gut, wenn eine Domain DNSSEC benutzt, ist aber natürlich überflüssig für Domains, die kein DNSSEC einsetzen. Weil die Resolver, das sind die Computerprogramme, die für den eigenen PC losgehen und die Frage nach der IP eines Domainnamens stellen, modern sind, beachten Sie DNSSEC. Da, wie oben im Bild, bereits der erste Eintrag, die TOP-Level-Domain ( TLD ), falsch signiert war, brechen Resolver an der Stelle direkt ab und fragen sich nicht weiter die Kette bis zum Schluß durch:

  • dig @8.8.8.8 „de.“

  • […]RRSIG with malformed signature found for de/soa (keytag=33834)

8.8.8.8 sind die öffentlichen Nameserver von Google, die dann für den fragenden das „Resolving“ (Auflösen) übernehmen. Und wie man sieht, hat der gestern Abend direkt für „de.“ gestreikt. Den Root-Punkt am Ende eines Domainnamens kennen normale Menschen im Internet gar nicht, weil der geflissentlich von echt allen Programmen weggelassen wird, und das zu Recht. Nicht desto trotz ist „test.de.“ eigentlich die korrekte Schreibweise. (Würdet Ihr den alle schreiben wollen? Genau).

Gallische Resolver, die kein DNSSEC validieren, waren nicht betroffen

Genauso habe ich unsere Zentralen DNS-Caches im Rechenzentrum wieder zum Funktionieren gebracht: DNSSEC abgeschaltet. Mein privater DNS Resolver auf dem PC hatte das auch nicht aktiviert, so daß ich zu den wenigen gehörte die alles machen konnten, aber den Luxus haben die Normalbürger nicht, da bei denen der (DSL-)Router die DNS Auflösung macht und den hat man nicht unter dieser strengen Kontrolle.

Ihr habt bestimmt schon einmal von der NIS-2 Richtlinie der EU gehört, die kritische Infrastrukturbetreiber zu Widerstandsmaßnahmen verdonnert, daß deren kritische Dienste in Betrieb bleiben. NIS-2 ist der Grund, wieso Ihr seit Dezember Eure Domaininhaberemailadressen validieren müsst. Ein Vorgang, der das Netz TOTAL SICHER macht 😉 Das ist natürlich blanker Aktionismus und so nutzlos, wie man sich das nur vorstellen kann.

Beispiel:

Ich gebe als Inhaberemail eine Adresse genau der Domain an, die ich gerade registriert habe. Was habe ich dadurch mehr an Infos über den gefakten Inhabernamen erfahren? Nichts.

Eine Validierung von Firmennamen und Adressen ist dagegen schon eine andere Hausnummer, außer der Eintrag im Handelsregister oder Datenbank des Adresshändlers ist genauso Fake, dann gewinne ich auch nichts.

Ihr seht, so ganz durchdacht ist die NIS-2 Umsetzung der DENIC nicht. Zurück zum DNS.

Wie wird da jetzt aber ein Fall für ISIS draus?

Der Ausfall gestern hat sehr eindringlich gezeigt, wieso ein Cyberangriff auf Deutschland, oder jedes andere Land, dort ansetzen wird: Beim ROOT Nameserver der TLD.

Der Angriff wird grob so ablaufen:

  1. Infiltration der DENIC
  2. Zerstörung der DE Zone und des Backups
  3. Eliminierung der Personen die wissen wie man das zurücksetzt.

Folgen:

  1. alle nicht in DNS Cachen gespeicherten Zonendaten sind unerreichbar
  2. nach maximal 24 Stunden sind diese Caches eruiert(leer)
  3. Ausfall von deutschen EMAIL, MATRIX, WHATSAPP, SMS, WEBSEITEN
  4. Ausfall von Zahlungsdienstleistern mit der TLD des angegriffenen Landes

Alles in <24h ohne Möglichkeit das zu vermeiden. 

Wieso 24h? Weil das die normale TTL von DNS Einträgen ist, damit die nicht ständig bei den ADNS ( Authoritative Domain Name Server ) nachgefragt werden müssen. Das wäre zu viel Stress fürs Netz, Ihr habt keine Vorstellung davon wie viele DNS Anfragen so ein PC am Tag macht.

Gegenmaßnahme

Ein dezentraler DENIC Ersatz bei dem der Angriff auf eine Instanz keine Folgen hat.

Das stellen wir uns am besten so vor, daß diese Schatten-Server die ganze Zeit die Infos von Denic kopieren, solange die Zone intakt ist und sobald die Zone defekt ist, den Stand einfrieren und aus Ihren Caches den JOB von den zerstörten DE-ROOTServern der Denic übernehmen.

Die Liste mit den Schattenservern liegt allen Resolvern bei oder wird wie die DNSSEC Keys von der Denic verteilt so lange sie kann und die Resolver ziehen sich einmal im Monat ein Update, so wie das bei den .-ROOTservern auch ist.

Der Unterschied eines Schattenserver zum offiziellen DE-Rootnamervern ist: Die Denic hat keine administrative Möglichkeit die Zonendaten zu zerstören, weil die nur gepullt werden und wenn die Daten die gepullt werden sollen, invalide sind, hört das Pullen auf und der „Notfall“ wird ausgerufen.

Funktion systemisch eingebaut.

Das System hat den Vorteil, daß es automatisch funktioniert, es kann also eine Blackbox einfach ins Netz eines Rechenzentrums gesteckt werden, die dann die DE-Rootzone spiegelt und das ausgibt. Die .-Rootserver könnten diese Schattenserver auch als normale DE-Rootserver ausgeben, weil es funktional nach außen keinen Unterschied gibt, solange die Updates der Zonendaten kommen (was ne Menge am Tag sein dürfte).

So ein System anzugreifen wäre fast unmöglich, weil man dazu DOS Angriffe benutzen müßte, und die können erkannt und abgewehrt werden. Dazu kommt, daß das System kostendeckend fast unbegrenzt skaliert werden kann, wenn die Schattenserver z.b. zusätzlich ein P2P Netzwerk zum Abgleich aufbauen. Setzt der Ernstfall ein, würde sich das System so, sogar selbst auf den letzten Stand syncen.

Der Realitätsabgleich

In der Realität des eingesetzten Notfalls, gibt es vermutlich ein paar tausend eher unwichtige Abweichungen wegen der Sync-Verzögerung, aber das ist dann zu verschmerzen und deutlich besser als der Totalausfall gestern Abend. Ihr macht Euch keine Vorstellung davon was an der „Meine Webseite ist offline“ Front los war. Mails im Sekundentakt von Überwachungsservern, ich musste gestern Abend z.B. das Konto beim SMS-Provider aufladen, weil mein Handy tatsächlich vom Tisch vibriert ist .. echt wahr.

Im Positiven würde man im Idealfall die zerstörte DE-Zone gar nicht bemerken. Denkt mal darüber nach.

Proxmox cooles Transferfeature

Vor einiger Zeit gab es Probleme mit der Storage eines unserer Hostingsysteme. Die auf dem PCIE Port verbaute M.2 sprang offenbar unter Last vom PCIE-Bus, was zum Totalausfall der VMs führte, die darauf Ihre Daten gelagert hatten.

Proxmox cooles Transferfeature

Nachdem klar war, daß das ein Problem des Mainboards ist und damit nicht ohne weiteres lösbar war, wurde eine alternative Storage in den Server eingebaut, die als neues Heim für Daten der VMs dienen sollte. Jetzt mußten die Daten da aber auch hin und da kommt die Livemigration von Proxmox ins Spiel.

Damit ist es möglich die Festplatten der VM’s auf eine andere Storage zu verschieben, ohne das die VM gestoppt werden muß. Ich habe Euch da ein Logfile mitgebracht, damit Ihr Euch das mal „ansehen“ könnt:

create full clone of drive sata1[1] (local-lvm:vm-101-disk-2)
Formatting[2] ‚/disks//images/101/vm-101-disk-0.qcow2‘, fmt=qcow2 cluster_size=65536 extended_l2=off preallocation=metadata compression_type=zlib size=85899345920 lazy_refcounts=off refcount_bits=16
drive mirror is starting for drive-sata1
drive-sata1: transferred 0.0 B of 80.0 GiB (0.00%) in 0s
drive-sata1: transferred 457.0 MiB of 80.0 GiB (0.56%) in 1s
drive-sata1: transferred 932.0 MiB of 80.0 GiB (1.14%) in 2s
drive-sata1: transferred 1.4 GiB of 80.0 GiB (1.70%) in 3s
drive-sata1: transferred 1.8 GiB of 80.0 GiB (2.27%) in 4s
drive-sata1: transferred 2.3 GiB of 80.0 GiB (2.84%) in 5s
drive-sata1: transferred 2.7 GiB of 80.0 GiB (3.42%) in 6s
drive-sata1: transferred 3.2 GiB of 80.0 GiB (3.99%) in 7s
drive-sata1: transferred 3.7 GiB of 80.0 GiB (4.56%) in 8s
drive-sata1: transferred 4.1 GiB of 80.0 GiB (5.13%) in 9s
drive-sata1: transferred 4.6 GiB of 80.0 GiB (5.70%) in 10s
drive-sata1: transferred 5.0 GiB of 80.0 GiB (6.27%) in 11s
drive-sata1: transferred 5.5 GiB of 80.0 GiB (6.84%) in 12s
drive-sata1: transferred 5.9 GiB of 80.0 GiB (7.41%) in 13s
drive-sata1: transferred 6.4 GiB of 80.0 GiB (7.98%) in 14s
drive-sata1: transferred 6.8 GiB of 80.0 GiB (8.54%) in 15s
drive-sata1: transferred 7.3 GiB of 80.0 GiB (9.12%) in 16s
drive-sata1: transferred 7.8 GiB of 80.0 GiB (9.70%) in 17s
drive-sata1: transferred 8.2 GiB of 80.0 GiB (10.27%) in 18s
drive-sata1: transferred 8.7 GiB of 80.0 GiB (10.84%) in 19s
drive-sata1: transferred 9.1 GiB of 80.0 GiB (11.39%) in 20s
drive-sata1: transferred 9.6 GiB of 80.0 GiB (11.98%) in 21s
drive-sata1: transferred 10.0 GiB of 80.0 GiB (12.55%) in 22s

drive-sata1: transferred 78.6 GiB of 80.0 GiB (98.22%) in 2m 55s
drive-sata1: transferred 79.0 GiB of 80.0 GiB (98.77%) in 2m 56s
drive-sata1: transferred 79.5 GiB of 80.0 GiB (99.29%) in 2m 57s
drive-sata1: transferred 79.9 GiB of 80.0 GiB (99.82%) in 2m 58s
drive-sata1: transferred 80.0 GiB of 80.0 GiB (100.00%) in 2m 59s, ready
all ‚mirror‘ jobs are ready
drive-sata1: Completing block job_id…
drive-sata1: Completed successfully.
drive-sata1: mirror-job finished
TASK OK

[1]  SATA1 ist schlicht und ergreifen die Nummerierung von Proxmox für die erste (und einzige) „SATA“-Platte an der VM. SATA meint hier nur den simulierten Anschluss, nicht das echte Speichermedium. Die Tragödie mit Fedora und SCSI hatte ich schon einmal thematisiert.
[2] Der Vorgang erzeugt auf der (nicht als LVM realisierten) neuen Storage erstmal eine Imagedatei passender Größe.

Wie man sehen kann, wurden da 80GB in 3 Minuten verschoben, was einer Datenrate von 455 MB/s entspricht. Das war schon mal viel schneller als wir das bei der Storage erwartet hatten. Diese soll eigentlich nur als Überbrückung dienen, um die defekte NVME aus dem RAID zu bekommen, ohne das es zum Datenverlust kommt.

Durch die Livemigration bleiben die VMs am laufen und die Benutzer merken idealerweise nichts von dem Transfer. Natürlich haben wir den nicht zur Primetime gemacht, daher war in der VM tatsächlich nichts von dem Transfer zu merken. An der Stelle, ein großes Lob für das Proxmox Team.Man muß die VM dafür nicht mal rebooten.

Das Feature soll auch bei externen Storages funktionieren, so daß eine nachträgliche Anschaffung einer „echten ;)“ Storage-Unit den Transfer von VMs  dort hin ermöglicht und die ehemals lokalen Server zu reinen Webslaves werden.

Also traut Euch ruhig das mal auszuprobieren, wenn Ihr neue Storages in Euren Proxmox einbaut.