Als Entwickler von Kommunikationslösungen und Dienstleister im Umfeld von Internet-Service-Providern bin ich mit den Realitäten der Internetversorgung für die typischen privaten Haushalte vertraut. Mir ist der Referentenentwurf erst vor wenigen Tagen zugegangen und ich möchte auf ein paar grundsätzliche Punkte in diesem Entwurf hinweisen. Dazu beschränke ich mich auf den Teil, der den Massenmarkt der Internetversorgung für Privatleute betrifft.

In der Begründung des Referentenentwurfes heißt es:

• Nach dem Entwurf werden Internetzugangsdiensteanbieter erstens verpflichtet, für drei Monate die von ihnen an Endkunden vergebenen IP-Adressen und weitere Daten wie die Portnummer zu speichern, sofern dies für eine eindeutige Zuordnung der IP-Adresse zu einem Anschlussinhaber erforderlich ist. Dadurch können Strafverfolgungs- und Gefahrenabwehrbehörden anhand eines Zeitstempels, einer IP-Adresse und gegebenenfalls einer Portnummer die Bestandsdaten beim Internetzugangsdiensteanbieter abfragen, […]

Der Referentenentwurf sieht dazu insbesondere folgende Änderungen vor:

• TKG §176 Speicherpflicht und Verwendungsbefugnis von Verkehrsdaten zur Identifizierung von Anschlussinhabern
  (1) Anbieter von Internetzugangsdiensten sind verpflichtet, mit der Zuweisung einer öffentlichen Internetprotokoll-Adresse an einen Anschlussinhaber folgende Daten für drei Monate zu speichern:
  1. die dem Anschlussinhaber für eine Internetverbindung zugewiesene, öffentliche Internetprotokoll-Adresse,
  2. eine eindeutige Kennung des Anschlusses, über den die Internetverbindung erfolgt, sowie eine zugewiesene Benutzerkennung,
  3. das Datum und die sekundengenaue Uhrzeit von Beginn und Ende der Zuweisung der öffentlichen Internetprotokoll-Adressen an einen Anschlussinhaber unter Angabe der jeweils zugrunde liegenden Zeitzone sowie
  4. die der Internetprotokoll-Adresse zugehörigen Portnummern und weitere Verkehrsdaten, soweit diese für eine Identifizierung des Anschlussinhabers anhand einer zu einem bestimmten Zeitpunkt zugewiesenen Internetprotokoll-Adresse erforderlich sind.
• BKAG § 10b Sicherung von Verkehrsdaten
  (1) Zur Erfüllung der Aufgabe als Zentralstelle nach § 2 Absatz 1 kann das Bundeskriminalamt zum Zwecke einer etwaigen Erhebung gegenüber demjenigen, der öffentlich zugängliche Telekommunikationsdienste anbietet oder daran mitwirkt, anordnen, Verkehrsdaten gemäß § 3 Nummer 70 des Telekommunikationsgesetzes von betroffenen Personen unverzüglich zu sichern (Sicherungsanordnung), wenn die zuständige Strafverfolgungsbehörde oder die zuständige Polizeibehörde noch nicht erkennbar ist […]

Lassen Sie mich dazu einige Begrifflichkeiten aus den referenzierten Gesetzen zitieren:

• TKG §3(6): Bestandsdaten Daten eines Endnutzers, die erforderlich sind für die Begründung, inhaltliche Ausgestaltung, Änderung oder Beendigung eines Vertragsverhältnisses über Telekommunikationsdienste
• TKG §3(70): Verkehrsdaten Daten, deren Erhebung, Verarbeitung oder Nutzung bei der Erbringung eines Telekommunikationsdienstes erforderlich sind
• BSIG §2(31): Protokolldaten Steuerdaten eines informationstechnischen Protokolls zur Datenübertragung, die a) zur Gewährleistung der Kommunikation zwischen Empfänger und Sender notwendig sind und b)  unabhängig vom Inhalt des Kommunikationsvorgangs übertragen oder auf den am Kommunikationsvorgang beteiligten Servern gespeichert werden
• TDDDG §2(3) Nutzungsdaten die personenbezogenen Daten eines Nutzers von digitalen Diensten, deren Verarbeitung erforderlich ist, um die Inanspruchnahme von digitalen Diensten zu ermöglichen und abzurechnen; dazu gehören insbesondere a) Merkmale zur Identifikation des Nutzers, b)  Angaben über Beginn und Ende sowie über den Umfang der jeweiligen Nutzung und c) Angaben über die vom Nutzer in Anspruch genommenen digitalen Dienste

Die offenkundige Intention des Referentenentwurfs ist, aus Protokolldaten, die an einer bestimmten Stelle (z.B. einem bestimmte Daten bereitstellenden Server) erfasst wurden, einen Rückschluss auf den Kommunikationspartner (z.B. den PC eines Benutzers, der die Daten abruft) ziehen zu können. Wie die gesamte Gesetzeslage so atmet auch der Referentenentwurf die Idee der klassischen Telefonie: Es besteht die (irrige) Annahme, es gäbe eine direkte Kommunikationsverbindung zwischen zwei Teilnehmern, die man – dem Kabel folgend – finden kann. Da Internet-Protokolle i.d.R. tatsächlich eine Kommunikation zwischen zwei Endstellen abbilden, besteht die (irrige) Annahme, jede Gegenstelle sei bereits der Endpunkt der Kommunikation und damit einem Benutzer zuordenbar.

Der fundamentale Irrtum besteht im Glauben an das Prinzip der Ende-zu-Ende-Kommunikation. Dieses Prinzip wurde Mitte der 2000er Jahre durch fortschreitenden Mangel an IPv4 Adressen aufgegeben. Stattdessen entwickelte  sich das Privatkunden-Internet in drei Richtungen, die oft gleichzeitig angeboten werden:

1. Kunden bekommen öffentliche IPv4-Adressen als Premiumprodukt
2. Kunden bekommen öffentliche IPv6-Adressen
3. Kunden bekommen nicht-öffentliche IPv4-Adressen zugewiesen und erreichen das Internet über Mittelboxen, die die Adressen umschreiben (Carrier Grade Network Address Translation – CGNAT)

Um aus den (entfernt erfassten) Protokolldaten auf die Bestandsdaten der (unbekannten) Gegenstelle schließen zu können, müssen die Verkehrsdaten beim ISP rechtzeitig abgefragt werden. Bisher gibt es keine Notwendigkeit für eine längere Speicherung der Verkehrsdaten beim ISP. Aktuell wird seitens der Datenschützer aber eine Frist von einigen Tagen zwecks Beseitigung von Betriebsstörungen toleriert. Dieses Zeitfenster soll der Referentenentwurf auf drei Monate ausdehnen.

Gestatten Sie mir zunächst eine Abschätzung der dabei anfallenden Datenmengen: Im Fall der Zuteilung von öffentlichen IP-Adressen an den Kunden bleibt diese Zuteilung meist mehrere Stunden stabil. Es genügt also zu erfassen, welcher Kunde wann welche Zuteilung für wie lange bekam. Die Datenmengen liegen dabei pro Kunde bei ca. 50 Byte pro Zuweisung (128bit Adresse, 64bit Zeitstempel, 64bit Kundenkennung plus weitere Metadaten). Bei durchschnittlich vier Änderungen pro Tag sind das 20kByte pro Kunde für drei Monate. Ein mittlerer ISP mit ca. 100000 Endkundenanschlüssen benötigt dafür also minimal 2 GByte Speicherplatz. In der Praxis wird die Art der Datenspeicherung das Zehnfache (plus Backup) benötigen.

Im Fall von (CG)NAT ist die Situation deutlich schwieriger. Viele Kunden mit nicht-öffentlichen IPv4-Adressen werden durch Mittelboxen auf wenige öffentliche IPv4-Adressen umgesetzt. Dabei werden die Portnummern der (TCP oder UDP)-Verbindungen umgeschrieben. Ein Verhältnis von 250 Kunden pro öffentliche IPv4-Adresse ist für einen mittleren ISP durchaus typisch. Als Faustformel gilt: Je mehr Kunden ein ISP hat, desto mehr Kunden teilen sich eine öffentliche NAT-IP.

Da nur ca. 64000 Port-Nummern (es gibt reservierte Bereiche) pro IPv4-Adresse zur Verfügung stehen, kann ein Kunde bei einer direkten Zuordnung der Portnummer zum Kunden (Cone-NAT) nur ca. 250 Ports benutzen. Offenbar hat der Referentenentwurf dieses Modell im Blick, wenn von der Erfassung der Portnummern zusammen mit der öffentlichen IPv4-Adresse gesprochen wird.

Leider ist Cone-NAT in der Praxis völlig unzureichend: Die meisten modernen Webseiten benötigen in schneller Folge mehrere hundert Verbindungen. Dazu kommen hunderte von DNS Anfragen. Eine Webseite wie z.B. Google Maps wird mit 250 freien Ports schlicht nicht vollständig aufgebaut. Bei vielen Social-Media Seiten fehlen dann Bilder oder andere Teile des Inhaltes. Eine Wiederverwendung der Port-Nummern ist insbesondere bei UDP Kommunikation schwierig, da es kein definiertes Ende der Kommunikation gibt. Der Port muss also über längere Zeit auf Verdacht mit diesem Kunden belegt bleiben.

Bei der Verwendung von Symmetric-NAT geht auch die Gegenstelle der Kommunikation mit ein. So stehen alle 64000 Ports einer öffentlichen IPv4-NAT-Adresse für jede Server-IP und jeden Server-Port (i.d.R. immer 443) zu Verfügung. Eine Anfrage welcher Nutzer hatte zum Zeitpunkt x die IP y mit Port z ist deswegen nicht beantwortbar. Es wird zusätzlich die Information die eine s-Verbindung mit Server a auf Port b hatte benötigt.

Man benötigt ca. 100 Byte pro Verbindung (3∙32bit IPv4, 3∙16bit Port, 16bit Protokoll, 64bit Zeitstempel, 64bit Kundenkennung plus Metadaten). Mit durchschnittlich einem Verbindungsaufbau pro Minute (über den Tag gerechnet, d.h. einige zig-tausend in kurzer Zeit und dann lange Pausen) bei Wenignutzern entstehen so 13 MByte pro Kunde für drei Monate. Ein mittlerer ISP wird also 2 TByte Verkehrsdaten verwalten müssen, die real sich auf 20 TByte Plattenplatz plus Backup ausdehnen.

Hat der ISP auch einige Poweruser (Familien mit Kindern reichen da schon), so kann man mit dem Mehrfachen an Platzbedarf rechnen. 10% der Nutzer machen jeder für sich so viele Verbindungen auf, wie der Rest aller Kunden zusammen, so dass der Platzbedarf um den Faktor 10 auf 200 TByte (plus Backup) anwächst.

Die Rechnung ist allerdings für normale Nutzung ohne besondere Vorkommnisse. Sollte ein(!) Nutzer Teil einer(!) dDOS-Attacke sein (z.B. durch ein(!) gekapertes IoT-Device), so generiert allein ein(!) solcher Vorgang ca. 1000 Verbindungsaufbauten pro Sekunde: Es entstehen hierbei 360 MByte pro Stunde an Verkehrsdaten für den einzelnen(!) Angriff.

Solche Angriffe passieren leider täglich und sind für die Strafverfolgung von hohem Interesse. Derartige explosionsartig anfallende Datenmengen sind also genau die Verkehrsdaten, auf die der Referentenentwurf abzielt. Deswegen ist es nicht möglich, in Anbetracht der Datenmenge eine Ausnahme für Angriffe von der Speicherpflicht zu machen, wenn der Referentenentwurf überhaupt nützlich sein soll.

Zusammenfassend kann man bei einem mittleren ISP also von ca. 500 TByte an Plattenplatz für die Speicherung von Verkehrsdaten beim Einsatz von CGNAT ausgehen. Backup kommt extra dazu, um im Falle einer Störung nicht die Daten der letzten Monate zu verlieren. Die zusätzlichen Anforderungen an einen mittleren ISP landen also im PByte Bereich, wenn dieser Referentenentwurf so realisiert würde.

Weiter heißt es in der Begründung des Referentenentwurfs:

• Die Speicherpflicht betrifft zwar alle Nutzer von Internetzugangsdiensten in Deutschland. Allerdings lassen die Daten nichts anderes zu als die Identifizierung des Anschlussinhabers anhand einer IP-Adresse. Es handelt sich gerade nicht um eine Vorratsdatenspeicherung von allen Verkehrs- und Standortdaten. Aus den gespeicherten IP-Adressdaten lassen sich insbesondere keine Surf- oder Bewegungsprofile erstellen. Die Beeinträchtigung insbesondere der unbescholtenen Nutzer ist damit überschaubar.

Diese Aussagen sind bei NAT nicht haltbar. Da für die korrekte Zuordnung beide Seiten der Kommunikation bekannt sein müssen, handelt es sich bei der geplanten Speicherung von Verkehrsdaten um eine unzulässige Vorratsdatenspeicherung, die genaue Rückschlüsse über das Kommunikationsverhalten des Nutzers zulässt. Das betrifft nicht nur die genauen Zeiten der Kommunikation, sondern auch die Kenntnis der Kommunikationspartner, so dass ein genaues Surf- und Bewegungsprofil erstellt werden kann.

Abschließend gibt es also drei Möglichkeiten:

1. Alle Referenzen auf Portnummern werden aus dem Referentenentwurf entfernt. Dies führt dazu, dass nur die Speicherfrist für die Zuordnung öffentlicher IP-Adressen erweitert wird. CGNAT-Nutzer werden dann nicht erfasst. Dies entspricht einer graduellen Ausweitung der aktuellen Rechtslage.
2. Der Einsatz von CGNAT wird verboten. Da es nicht genügend IPv4 Adressen für alle Kunden gibt, wird die Anzahl der Internetanschlüsse für Haushalte beschränkt.
3. Die verpflichtende Umsetzung des RFC 6540 für die deutschen ISPs wird eingefordert: Mit dem Wechsel auf IPv6 only besteht kein Bedarf mehr an NAT. Die Umsetzung des RFC muss deswegen gesetzlich verpflichtend sein, damit die ISPs sich nicht in einem ruinösen Wettbewerb für legacy IPv4-Nutzer gegenseitig kaputt machen. Während der Übergangszeit bleibt es bei Möglichkeit 1 für Bestandsverträge. Neuverträge sind ab einem Stichtag generell nur noch IPv6 only.

Danke für Ihr Interesse.

Microsoft veröffentlich am zweiten Dienstag im Monat neue Patches. In größeren Unternehmen wird bei normalen Updates eine Woche auf Unverträglichkeiten getesten und dann die Patches unternehmensweit ausgerollt. In dieser "Patchwoche" sollen auch automatisch Updates ausgerollt werden, in anderen Wochen aber nicht.

Das Problem besteht offensichtlich darin, dass Patches, die auf einem Gerät am Mittwoch in der Patchwoche ausgerollt werden sollen, jeden Monat von Hand mit dem Datum verknüpft werden müssen. So kann der 1. des Monats ein Montag oder Dienstag sein, dann ist der relevante Tag der 16. oder 18. des Monats. Ist der 1. des Monats aber ein Mittwoch, so wäre der relevante Tag am 21. des Monats.

Wie automatisiert man sowas?

Offensichtlich ändert sich an der Situation nichts, wenn der Wochentag und gleichzeitig das Datum erhöht werden: Die gesuchte Woche ist charaterisiert durch die Differenz von Datum und Wochentag.

Diese Differenz bezieht sich auf den Montag (1) als Monatsanfang (1), denn da ist die Differenz 0. Nun soll der Wochenanfang so liegen, als sei der Dienstag der Wochenbeginn. Die Differenz ist für einen Dienstag (2) als Monatsanfang (1) aber -1. Um das wieder auf 0 zu bekommen, muss man diese 1 hinzu addieren.

Um die Woche zu ermitteln teilt man einfach durch 7 und verwirft den Rest. 0 ist dann die erste Woche, 1 die Woche, in der der Microsoft veröffentlicht und 2 die Woche, in der regulär gepatcht werden soll.

Die Formel lautet also: (Monatstag - Wochentag + 1)/7 == 2

Als Shellscript sieht das so aus:

$ cat patchwoche-mache
#! /usr/bin/bash

[ 2 -eq $[$(/usr/bin/date +'(%-d-%u+1)/7')] ] || exit
exec mache "$@"

Nun steht einem generischen Crontab nichts mehr im Wege:

# Daueraufgaben
0 2 * * 1      mache am montag
0 2 * * 2      mache am dienstag
0 2 * * 3      mache am mittwoch
0 2 * * 4      mache am donnerstag
0 2 * * 5      mache am freitag
...
0 2 * * 3      patchwoche-mache am mittwoch
...

Und tut.

Mein eigner CLI-Prometheus-Exporter lieferte heute spontan Label-Werte, die der Prometheus als ungültig im Sinne von UTF8 ansah.

Am Exporter-Programm und an der Konfig einer ASA hatte sich nichts geändert. Der Exporter ist durchgelaufen, es gab also auch kein unbewusste Codeänderung. Der Abruf der Metrik im Browser funktionierte tadellos, die Ausgabe war unauffällig. Keine Sonderzeichen oder irgendetwas ungewöhnliches zu erkenne, Trotzdem verstand der Prometheus mit einem Male die Metriken nicht mehr.

Es gibt wenige Stellen an denen "Freitext" aus der CLI in die Label-Werte übernommen wurde. Eine davon ist der Nutzername von eingewählten Remote-Access-VPNs. Dort steht öfter mal die Domain mit dabei, also DOMAIN\user. Kann es sein, dass der Prometheus irgendwo eine Backslash-Sequenz missversteht anstatt es literal zu übernehmen?

Ich filtere also nun die Domain incl. des Backslash weg und die Ausgabe wird immer noch nicht akzeptiert. Irgendwo soll noch eine ungültige UTF8 Sequenz stehen.

Beim Durchmustern der Ausgabe fällt mir einpeer_user="`user" auf. Was soll das sein? Ein Accent Acute vor dem Nutzernamen? Mal in die ASA schauen:

Username     : ´user
Assigned IP  : a.b.c.d
Protocol     : IKEv1 IPsecOverNatT L2TPOverIPsecOverNatT
License      : Other VPN

Was sucht da ein Accent-Zeichen? Der Nutzer hat dieses Zeichen nicht im Login-Namen! Trotzdem hat die Anmeldung geklappt!

Ohne eine sinnvolle Quelle gefunden zu haben, scheint Windows dieses Zeichen als Domain-Separator zu interpretieren oder in dem Fall als "domainloses Login".

Jetzt filtere ich es raus, so wie die domain\ Vorsätze.

Obwohl IPv6 entwickelt wurde, um IPv4 zu ersetzen, ist der Übergangsprozess nicht wie erwartet in Gang gekommen und wird es auch weiterhin nicht sein.  Der Hauptgrund für die ins Stocken geratene Einführung ist nicht technischer Natur, sondern liegt im historischen Wissen und in den etablierten Verfahren.  Der fehlende Teil zwischen IPv4 und IPv6 soll die Migrationsbemühungen unterstützen, indem die nichttechnischen Anforderungen für einen reibungslosen Übergang berücksichtigt werden.

IPv4 kommt mit dem visuellen Erscheinungsbild von gepunkteten Quad-Zahlen daher, während IPv6 wie ein Speicherauszug während einer Kernel-Panik aussieht. Älzere Administratoren sowie Lehrer, Dokumentationsautoren oder Filmemacher sind mit dem IPv4-Adressstil vertraut und können und werden ihre Gewohnheiten, Folien oder Bücher nicht ändern.  IPv6 wird sich erst durchsetzen, wenn diese Generation von Menschen die Unternehmen und Schulen verlassen haben.
Um ein neues Protokoll einzuführen, darf sich das Erscheinungsbild und die Bedienung nicht ändern.  Wenn man von IPv4 kommt, sollte es bei der Verwendung von IPv5 keinen Unterschied geben.  Bei der Umstellung auf IPv6 sollte es nur einen minimalen Unterschied zu IPv5 geben.  IPv5 ist so konzipiert, dass die ältere Generation an Bord bleibt und gleichzeitig ein Protokoll eingeführt wird, das wie das neuere IPv6 verwendet werden könnte.
Außerdem sollten die organisatorischen Auswirkungen so gering wie möglich gehalten werden.  Personen, die bereits IPv4 oder IPv6 verwenden, sollten ohne zusätzliche bürokratische Hindernisse zu IPv5 wechseln können.

Weitere Details finden sich in https://datatracker.ietf.org/doc/draft-april-ipv5/

Ein FreeBSD vom Source aktuell zu halten geht mit etcupdate ziemlich gut. Diese Programm macht einen 3-Wege-Merge, berücksichtigt also die Änderungen durch den Update und die vom Nutzer. Manchmal aber übersieht es etwas.

Nach einem Update blieben einige Warnungen bestehen und liesen sich nicht beheben:

# etcupdate status
Warnings:
  Removed file changed: /etc/kyua/kyua.conf
  Removed file changed: /etc/rc.d/tlsclntd
  Removed file changed: /etc/rc.d/tlsservd
  Removed file changed: /etc/rc.d/zpool
  Removed file changed: /root/.shrc

Wie das passieren konnte, ist ein anderes Thema. Wichtig ist hier, wie man da wieder raus kommt. Normalerweise per etcupdate resolve.

# etcupdate resolve

Exakt: Da geht gar nichts. Lösen (resolve) kann man nur Konflikte, keine Warnungen.

Die Warnungen der Statusmeldngen sind gecached und stehen in /var/db/etcupdate/warnings. Man muss diese Datei nur leeren:

# : > /var/db/etcupdate/warnings
# etcupdate status

Fertig!

Und damit das irgendwo dokumentiert von Google und Co gefunden werden kann, steht's im Blog.

So langsam muss ich wieder anfangen, über die kleinen Erfolge zu bloggen, die sich in den letzten Jahren ergeben haben. Hier geht es nun um unwillkommene Spikes im Trafficgraphen, wenn dieser sich aus einer generalisierten Metrik erzeugt.

Trafficcounter in heterogenden Netzen kommen aus vielen unterschiedlichen Quellen, die alle ihre eigene Syntax und Labelstruktur aufweisen. Mit sowas will man möglichst schnell nichts mehr zu tun haben. Stattdessen soll eine generalisierte Metrik common:interface:counter die ganzen hässlichen Details wegabstrahieren.

groups:
- name: Leitungen
  rules:
  - record: common:interface:counter
    expr: >-
      sum by (device,port,type,direction,description) (
        label_replace(label_replace(
          sum by (direction,instance,intf,type,description) (
            intfCounter + on(instance,intf) group_left(description)
              (0*label_replace(interfaceDescription,"intf","$1","interface","(.*)"))
          ) or sum by (direction,instance,intf,type) (
            label_replace(intfLagCounter,"type","$1","unnamedLabel4","(.*)")
          ),
          "device","$1","instance","(.*):.*"),
          "port","$1","intf","(.*)")
      or label_replace(label_replace(
          label_replace(label_replace(cisco_interface_receive_bytes,"direction","in","job",".*"),"type","Octets","job",".*") or
          label_replace(label_replace(cisco_interface_transmit_bytes,"direction","out","job",".*"),"type","Octets","job",".*") or
          label_replace(label_replace(cisco_interface_receive_errors,"direction","out","job",".*"),"type","Errors","job",".*") or
          label_replace(label_replace(cisco_interface_transmit_errors,"direction","out","job",".*"),"type","Errors","job",".*") or
          label_replace(label_replace(cisco_interface_receive_drops,"direction","out","job",".*"),"type","Discards","job",".*") or
          label_replace(label_replace(cisco_interface_transmit_drops,"direction","out","job",".*"),"type","Discards","job",".*"),
          "device","$1","target","(.*)"),
          "port","$1","name","(.*)")
      or label_replace(label_replace(
          label_replace(label_replace(junos_interface_receive_bytes,"direction","in","job",".*"),"type","Octets","job",".*") or
          label_replace(label_replace(junos_interface_transmit_bytes,"direction","out","job",".*"),"type","Octets","job",".*") or
          label_replace(label_replace(junos_interface_receive_errors,"direction","out","job",".*"),"type","Errors","job",".*") or
          label_replace(label_replace(junos_interface_transmit_errors,"direction","out","job",".*"),"type","Errors","job",".*") or
          label_replace(label_replace(junos_interface_receive_drops,"direction","out","job",".*"),"type","Discards","job",".*") or
          label_replace(label_replace(junos_interface_transmit_drops,"direction","out","job",".*"),"type","Discards","job",".*") ,
          "device","$1","target","(.*)"),
          "port","$1","name","(.*)")
      ) 

Das sieht zunächst komplett wahnsinnig aus, ist aber relativ schnell erklärt:

Mit or werden Metriken, die eigentlich nichts miteinander zu tun haben, zu einer Metrik vereinigt. Dabei bleiben die Detail-Labels erhalten, der Name der Metrik fällt nur weg. Da ich hinterher eine Metrik mit neuen Label-Bezeichnern haben will, muss die die neuen Label-Namen erzeugen und mit den Werten der alten Labels befüllen. Die Funktion label_replace tut dies: Sie befüllt ein neues Label mit den Treffern des regulären Ausdrucks eines existierenden Labels. Dies kann man besonders schön an den letzten Zeilen sehen, wo das neue Label port mit dem vollen Text des alten Labels name gefüllt wird. So werden also nacheinander die Labels direction, type, device und port befüllt.

Um hinterher nicht mit einem Zoo weiterer Alt-Labels rumlaufen zu müssen, wir per sum by (labels) einfach die "Summe" ohne die unnötigen Labels ausgeführt: Da sie verbleibenden Labels eindeutig sind, ist es eine Summe über jeweils genau einen Eintrag, der einfach die nicht benötigten Labels weg wirft. Das ist ein typisches Idiom in PromQL.

Schwieriger ist der erst Teil, bei dem die Zählerstände zwar schon schön vorliegen, aber die Informationen wie description fehlen. Man muss also hier die Labels aus einer ganz anderen Metrik passend dazu pappen. Das zugehörige Idiom addiert nun also zwei Metriken (unter Berücksichtigung ausgewählter Labels als passend angesehen) und übernimmt das Label description. Damit die Summe aber nichts kaputt macht, multipliziert man die zweite Metrik mit 0.

Auf diese Weise entsteht eine neue Metrik common:interface:counter mit den Labels device, port, type, direction und description, die nun universell einsetzbar ist.

Schaut man sich die Traffiggraphen solcher Metriken an, so haben die häuftige und störende Ausreißer:

Beiden Bildern ist anzusehen, wie zittrig oder sprunghaft der Graph ist. Dieser Effekt stört mich seit mindestens einem Jahr und ich hatte ich bisher nicht in den Griff bekommen.

Mwhr durch Zufall kam ich heute dazu, den generierte Metrik und die Originalmetrik mal übereinander zu legen. Das Ergebis war, dass die Metriken fast identisch sind. Jedoch läuft die originale Metrik der generierten Metrik etwas voraus, bis die generierte Metrik den Fehler nach Minuten oder Stunden wieder einholt, dann aber sprunghaft.

Wie kann das sein? Wann wird denn die generierte Metrik erzeugt? Sicher nicht immer dann, wenn irgendeine der Metriken irgendeinen Update bekommt. Nein, das geschieht in regelmäßigen Intervallen durch den Prometheus selbst.

global:
  scrape_interval:     59s
  evaluation_interval: 1m 

Den Werte habe ich so gesetzt, damit er kurz nach neu eintreffenden Werten diese verarbeiten kann und diese nicht verpasst. Im Laufe der Zeit hatten sich dann andere Geräte mit scrape_interval von 29s bis 3m eingefunden. Die Daten kommen also zu sehr unterschiedlichen Zeiten rein.

Aber selbst diese Sekunde Unterschied bedeutet, dass die generierende Metrik jede Stunde (60x aufgerufen) doppelte Daten sieht. Diesen Takt kann man in der gelben Kurve ziemlich gut erkennen. Es kommen dann ja auch noch so Dinge rein, wie Verzögerungen beim Auslesen der Metriken, etc. pp.

Worin besteht also die Lösung? Viel häufiger die Metrik generieren! Das neue evaluation_interval beträgt nun die Hälfte des kleines Scrape-Intervals also 10 Sekunden.

Glücklicherweise ist Prometheus sehr effizient mit dem Abspeichern von "unveränderlichen" Passagen von Metriken. So ist das zumindest kein Plattenfresser.

Achja, ganz rechts im Bild ist die Änderung wirksam. Die Kurven haben aufgehört zu zittern.

This week, on Thursday, a list of URLs to be blocked was distributed by Breko to the German ISPs. After consultation with Breko and the BNetzA, as well as after contacting some of the operators to be blocked (including a streaming service in the USA), answers from the BNetzA on how to deal with the liability issue are still pending. Last week, I had already discussed the problem in general with the responsible person at the EU Commission.
Current status:

• There is a draft of the changes to the sanctions lists on the part of the Council of Europe, which goes via the member states to the BNetzA, among others.
• The political responsibility in Germany lies with the State Secretary for Education and Cultural Affairs, Claudia Roth.
• Some employees of the BNetzA create templates for the blacklists in addition to their actual work.
• The employees do not contact the operators concerned in advance to obtain a deletion
• The BNetzA's net neutrality department checks whether the selected targets might lead to overblocking.
• The list thus cleansed is distributed to the associations (including Breko), which then distribute it to their members.
• With the decision of the EU, the Council proposal is either accepted, amended or rejected.
• From the time of the decision, the ISPs are obliged to implement the proposal.

According to the BNetzA, the ISP must take note of the following:

• Blocking too early (before the decision) is illegal. Customers can insist on compensation (or sue for damages).
• Incorrect blocking (if the decision changes compared to the original) may be illegal in parts and allows claims for damages.
• A blocking that is not carried out is illegal and may be prosecuted by the public prosecutor's office.
• Overblocking (i.e. blocking more than the organisation subject to the sanction) is illegal and will be prosecuted by the BNetzA. Affected customers are entitled to damages.
• The lists of the BNetzA sometimes contain URLs, in which case only the specific web service is to be blocked; a DNS block can be overblocking.
• For the lists issued by the BNetzA, the BNetzA assures that it will not initiate administrative offence proceedings against the ISP if overblocking occurs

In the specific case this week, several disputed pages are listed with deep links (i.e. parts of the offer), which themselves cannot be attributed to Russian authorities or organisations. A query to at least one of the operators showed that he had not been informed in advance and had deleted the channel in question (a website with a link to a Russian offering, i.e. not even hosted by himself). This information was passed on to the BNetzA and Breko with the request to suspend or correct the list. So far there has been no feedback. Likewise, the decision is not yet available: https://eur-lex.europa.eu/oj/direct-access.html?locale=en.

In a nutshell: So far, implementation is only possible if the domains to be blocked have been instructed individually by the managing director of the ISP concerned. The latter then bears the responsibility for claims for damages by customers, non-implementation of sanctions, and overblocking.

Reaction to deletion notice

After the BNetzA was informed on Friday about the successful deletion at coolstreaming, among others, combined with the request for suspension or correction of the list, a response came on Tuesday:

• Clarification that the domain blocking will not be assessed as a violation of net neutrality even for full URLs.
• With reference to the decision of Friday, the lists of URLs are repeated again, but now without deep links, so that a review of the sanctionability can no longer take place.
• Clarification that overblocking is accepted by the sanctions: As long as there is content behind the affected domains that is covered by the EU Sanctions Regulation, the entire domain must be blocked.
• Clarification that deletion is not listed in the Sanctions Regulation, but only the prevention of the transport of the content
• Clarification that deleted content must not be blocked
• Clarification that the BNetzA only communicates with the industry associations, but not with the companies affected by the blocks
• Clarification that the BNetzA is not responsible for the implementation of the sanctions, but that this is exclusively in the hands of the obligated companies (ISPs)
• Clarification that the lists of the BNetzA only state that blockings that include these domains are not considered a violation of net neutrality.
• Of course, this does not apply to domains that do not host sanctioned content. The ISP has to check this independently.

Despite the notice to delete the content, the domains concerned are still on the list. This time, however, without any possibility of control for the Internet provider concerned. Combined with the indication that the blocking of domains that no longer contain sanctioned content is again a violation of net neutrality, even if this was included in the BNetzA's list, this is a strong piece of work: a liability privilege is deliberately suggested, of which the suggesting body already knows that this privilege does not apply.

Weg war das Blog für zwei Monate. Warum?

Zunächst gab es einen Stromausfall im Rechenzentrum. Einen ziemlich Interessanten sogar, denn obwohl der Anschluss an verschiedene Trafos direkt im Kraftwerk des Energieversorgers besteht und eine USV dahinter hängt, war der Strom weg.

Die Ursachen dafür sind vielschichtig, dass ein Kraftwerk so komplett abschaltet ist äußerst selten und hat viel mit dem Abführen von überschüssiger Wärme zu tun.

Entscheidend war aber, dass die USV zwar weiter Strom lieferte, nicht aber das Klima im Haus versorgt wurde.

Auch das wäre kein Problem gewesen, hätte die Rackklimatisierung funktioniert. Die war aber gerade in der Konfiguration und kam mit der Situation nicht klar.

Auch das wäre kein Problem gewesen, hätte die Alarmierung funktioniert. Aber da das alles erst relativ kurz eingebaut war, fehlt noch das Einstecken des letzten Netzwerkkabels.

Mit dem Alarm wäre der diensthabende Techniker einfach hin gegangen und hätte die Racktüren geöffnet, ggfl. auch Durchzug organisiert. Aber es war kurz nach Mitternacht und niemand vor Ort.

So überhitzte das Rack und die Technik schaltete sich selbst ab, bevor was kaputt gehen konnte. Einige Technik ist aber nicht ganz so robust und wieder verstarb ein Netzteil.

Einige wichtige Systeme sollte man halt nicht virtualisieren, weil man die beim Hochfahren der Virtualisierungsumgebung selbst braucht. Die stehen also als extra Maschinen daneben. Auf einer der gerade nicht benötigten Kisten läuft das Blog.

Als ich dann gegen drei Uhr ankam, fehlte noch eines dieser Systeme und ehe man da lange rum sucht, woran es liegen kann, hab' ich einfach meine Maschine zerlegt und als Ersatzteilspender genutzt. Katastrophe vor privat.

Nur war dann halt der Druck raus und bis ich es hinbekommen habe, meine Kiste wieder zu komplettieren, ist leider viel Wasser die Saale runter geflossen. Prioritäten halt.

Aber heute hat's geklappt, die Kiste rennt wieder. I'm back.

Was taugen also diese Antigen-Tests die für Schnell- und Selbsttests eingesetzt werden? Prof. Drosten hat ja in seinem gestrigen Podcast auch auf die hohe Fehlerquote des Tests verwiesen. Hier lohnt es sich genau hin zu schauen …

Antigen- oder Lateral-Flow-Tests bekommen eine Probe eines Nasen/Rachenabstriches vorgelegt, die dann in einer Lösung langsam den Teststreifen entlang kriecht (das ist der lateral flow). In zwei Querstreifen befinden sich Farbstoffe, die an Sensormoleküle gebunden sind. Der weiter entfernte Querstreifen reagiert auf das Lösungsmittel und zeigt somit an, dass der Test korrekt benutzt wurde. Am eigentlichen Test-Querstreifen ist der Farbstoff an Antikörper gebunden, die spezifisch auf bestimmte Viruseiweiße reagieren. Derartige Antikörper sind auch Bestandteil des Immunsystems, sie dienen der Erkennung schädlicher Eindringlinge.

Problemfelder

Was kann dabei schief gehen?

Zunächst mal könnte es ein anderes Material geben, dass den Farbstoff zum Leuchten bringt. Säuren sind da beispielsweise geeignet. Deswegen sollte man einige Zeit vor einem Test nichts trinken (außer Wasser). Andere Krankheitserreger lösen den Antikörper nicht aus. Es ist jedoch denkbar, dass nahe Verwandte des SARS-CoV2 ebenfalls eine Reaktion hervor rufen. Praktisch bekannt sind solche Fälle bisher nicht.

Ist wenig Virusmaterial vorhanden, so gibt es nur eine sehr schwache oder gar keine Verfärbung des Teststreifens. Man könnte also eine schwache Linie für fälschlich negativ halten. Dass kein oder zu wenig Material vor liegt kann nicht nur daran liegen, dass die Person virenfrei ist, sondern auch an einem fehlerhaften Abstrich. Wer also nur kurz durch die Nase huscht, riskiert eine zu geringe Probenentnahme. Auch kann die Nase gerade frisch gereinigt worden (Nasenspray etc.) und so evtl. vorhandenes Virenmaterial beseitigt sein.

Darüber hinaus variiert die Virenmenge in den oberen Atemwegen während des Krankheitsverlaufs. So steigt die Virenlast erst einige Tage an (und der Test erkennt nichts), dann ist man infektiös (und der Test schlägt an). bekommt evtl. Symptome, weil sich das Virus in die Lunge verlagern (der Test schlägt nicht mehr an). Insbesondere die ersten Tage stellen ein Problem dar, denn obwohl der Test (gerade noch) negativ ist, ist man einige Zeit später schon infektiös.

Aber auch Umgebungseinflüsse können den Test beeinträchtigen. Ist es zu warm oder zu kalt, erfolgt die notwendige Nachweisreaktion nicht in der benötigten Stärke, der Test wird so unbrauchbar. Natürlich können auch Proben vertauscht werden. Und man sollte die Teststäbchen auch nicht mehrfach benutzen.

Fazit

Summiert man all diese Fehlermöglichkeiten auf, so stellt sich heraus, dass in der Praxis ein positiver Schnelltest fast immer auch eine positive PCR Bestätigung bekommt. Die Fälle in denen der Test falsch positiv ist, sind meist durch Fremdeinwirkung (z.B. Trinken von Cola oder Fruchtsaft) zurück zu führen. Andererseits sagt ein negativer Test wenig aus, denn an drei von acht Tagen des typischen Infektionsverlaufs bleibt er aufgrund der niedrigeren Virenlast negativ. Schlechte Abstriche und falsche Handhabung dazu, kann eine infizierte Person in 40% der Fälle fälschlich als negativ bewertet werden.

Kürzlich hat das RKI davon geschrieben, dass Geimpfte genauso angesehen werden sollen, wie negativ Getestete. Das ist in Anbetracht der gerade vorgenommen Ausführungen völlig verständlich: Geimpfte können sich zwar wieder infizieren und diese Infektion auch weiter geben, aber die Wahrscheinlichkeit dafür ist mit höchstens 10% deutlich kleiner als die 40% false-negative Wahrscheinlichkeit eines Schnelltests.

Das ist deutlich weniger als die Politik aus der Aussage heraus zu lesen versucht: Geimpfte sind also ebenso wenig wie negativ Getestete garantiert ungefährlich, sondern übertragen in einer vergleichbaren Größenordnung das Virus trotzdem weiter.

Der Krux mit den Prozenten

Nehmen wir ein Beispiel: In einer größeren Stadt wurden 10000 Schnelltests an einem Tag durchgeführt. Dabei wurden 20 positive Tests ermittelt. Die Inzidenz in der Gegend liegt bei 150.

Mit einer unbekannten Dunkelziffer (die die Anzahl der Infizierten nach oben treiben würde) und einer Vorselektion auf komplett symptomfreie Nutzer der Schnelltests (was die Anzahl nach unten treibt) ist es eine mögliche Annahme, dass sich diese beiden Effekte neutralisieren. Man kann also die Inzidenz direkt auf die Testmenge anwenden und würde somit 15 Infizierte unter den 10000 Test-Kandidaten erwarten.

Von den 15 Infizierten haben 40% ein falsch-negatives Ergebnis: 6 Personen bekommen also einen negativen Befund, obwohl sie aktive Virenträger sind. Die restlichen 9 Infizierten werden korrekt erkannt. Da aber 20 positive Tests vorliegen, sind elf Personen mit falsch-positiven Resultaten dazu gekommen.

Wenn man selbst zum Testen geht, interessiert man sich natürlich nur für die Wahrscheinlichkeit die der Test bei einem persönlich hat. Ob man infiziert ist oder nicht, weiß man ja nicht. Also gehört man zur Gesamtheit der getesteten Personen. Und da hat der Test also:

• 11 von 10000 = 0,11% falsch-positive Wahrscheinlichkeit
• 6 von 10000 = 0,06% falsch-negative Wahrscheinlichkeit

Hat man dann wirklich einen positiven Test (was erst mal unwahrscheinlich ist), dann kann der zu über 50% falsch-positiv sein. Diese massive Vergrößerung ist als bedingte Wahrscheinlichkeit bekannt und der menschlichen Intuition fremd.

Dieses Verschätzen der Intuition ist in die andere Richtung noch viel extremer. Aus der Angabe 40% nimmt man einfach an, dann 4000 Virenträger unerkannt durch die Tests kommen! Real sind es aber nur sechs Personen, also 1,5 Promille der intuitiven Vorstellung.

Schnelltests filtern also Infizierte aus der Masse heraus, verringern aber die Anzahl der Infizierten nicht ausreichend.

Die Verwendung von Schnelltests als Freigabe für Öffnungen und Treffen ist bei hohen Infektionszahlen schlicht fahrlässig. Nur bei niedrigen Inzidenzwerten eignen sich Schnelltests für diesen Zweck. Sie dienen dann dem Auffinden von noch unbekannten Infektionsclustern in einer fast komplett virenfreien Umgebung.

Aus aktuellem Anlass hier nochmal ein Hinweis auf die Auswirkung der Testanzahlen. Wesentlich ist dabei zunächst der Fakt, dass die Infektionen völlig unabhängig von der Teststrategie sind. Die Leute bekommen und haben das Virus auch dann, wenn man nicht testet. Mit Tests kann man sich der Infektionslage annähern, indem man möglichst viele Personen ermittelt, die infiziert sind. Man leuchtet also das Dunkelfeld aus.

Dabei gibt es vier Gruppen von Personen:

1. Menschen, deren Infektion schon bekannt ist (aus einem früheren Test). Diese werden regelmäßig wieder getestet, um zu erkennen, wann die Gefahr vorbei ist. Die Positivquote dieser Tests ist sehr hoch: Viele von denen, die bekanntermaßen infiziert sind, bleiben es auch noch für eine ganze Weile. Die Infektion verschwindet nur langsam aus dem Körper, auch wenn die ansteckende Phase schon lange vorbei ist.
2. Menschen, die typische Covid19-Symptome haben. Diese werden hoffentlich schnell getestet, um Klarheit über ihren Zustand zu erhalten. Meist sind diese Personen noch ansteckend oder haben vor kurzem andere Menschen anstecken können. Auch hier ist die Positivquote der Tests hoch.
3. Menschen, die durch Kontakte zu als infiziert bekannten Personen (aus Gruppe 2) sich angesteckt haben können. Diese Personen möglichst vollständig zu ermitteln ist Aufgabe des Gesundheitsamtes. Hier ist Geschwindigkeit so ziemlich das Wichtigste. Binnen 24h sollten alle potentiellen Kontaktpersonen benachrichtigt sein, egal ob es gerade Wochentag oder Wochenende ist. Digitalisierung hilft hier massiv. Diese Menschen sind zu testen, um weitere Ansteckungswege zu erkennen. (Zum Verhindern reicht Quarantäne.) Die Positivquote dieser Tests ist ziemlich niedrig, weil (Achtung Überschlag) eine Person zwar 40 Kontakte in zwei Wochen gehabt, aber nur einen oder zwei angesteckt hat (Positivquote bei 3%). Besonders heimtückisch sind Superspreader-Events, bei denen eine Person sehr viele andere angesteckt hat, beispielsweise bei einem längeren, lautstarken Aufenthalt mit vielen Personen in Innenräumen.
4. Menschen, die sich auf noch unbekannten Wege angesteckt haben. Diese zu finden, ist sehr schwer. Hier kommen Schnelltests zur Vorselektion zum Einsatz, um schnell größere Menschengruppen auf verdächtige Virenausscheidungen zu überprüfen. Die Verdachtsfälle werden dann durch PCR-Tests validiert. Es kommt also bei Schnelltests auf den preiswerten Durchsatz an, nicht auf absolute Genauigkeit. Natürlich sollte der Schnelltest nicht zu viele falsch-negative Ergebnisse bringen, weil das die Ausbreitung der Infektion begünstigt. Eine zu hohe falsch-positiv Quote ist dagegen mehr ein Problem der Akzeptanz des Tests. Da der Schnelltest in einem Umfeld mit wenigen Fällen (niedrige Prävalenz) angewendet wird, ist seine erwartete Positivquote sehr niedrig (0,2% in Jena). Es ist also sinnvoll, Verdachtsgruppen mit höherer Prävalenz (z.B. Reiserückkehrer) komplett mit Schnelltests zu überprüfen.

Das kann man auch mal numerisch durch spielen.

Wenn also eine Positivquote an Tests von ca. 5% gemeldet wird, sind ausschließlich die Gruppen 1 bis 3 dafür verantwortlich. Positive Tests aus Gruppe 4 spielen fast keine Rolle. Vergrößert man jetzt die Anzahl der Tests in die Gruppe 4 hinein, so erhöht sich die Anzahl der gefundenen Infektionen nur sehr wenig.

Liegt die Positivquote bei höheren Werten, vielleicht sogar über 7% oder gar 10%, dann hat man die Gruppe 3 (Kontakte) nicht ausreichend untersucht. Mehr Tests führen also in dem Fall zu echt mehr gefundenen Infektionen, was aber auch dringend notwendig ist.

Liegt die Positivquote bei niedrigen Werten, vielleicht sogar unter 1%, dann hat man ein sehr umfassendes Bild der Infektionslage (unter der aktuellen Prävalenz). Dazu muss man vermutlich mehr als die Hälfte der Bevölkerung testen, denn die Positivquote kann nicht niedriger sein als die Prävalenz in der Bevölkerung. Alle gefundenen Fälle stecken keine neuen Menschen mehr unkontrolliert an, so dass das Virus sich nicht mehr ausbreiten kann. Dies ist die #NoCovid-Strategie. Erfolgreich durchgeführt kann man dann auch Millionen Menschen testen, ohne einen positiven Fall zu haben. Das Virus ist dann faktisch verschwunden.