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.

Diese Woche wurde am Donnerstag eine Liste von zu sperrenden URLs durch die Breko an die deutschen ISPs verteilt. Nach Rücksprache mit der Breko und der BNetzA, sowie nach Kontaktaufnahme mit einigen der zu sperrenden Betreibern (u.a. ein Streamingdienst in den USA), stehen Antworten der BNetzA aus, wie mit der Haftungsfrage umgegangen werden soll. Letzte Woche hatte ich generell das Problem schon mit dem Zuständigen der EU-Kommission besprochen.

Aktueller Stand:

• Es gibt einen Entwurf der Änderungen der Sanktionslisten seitens des Rates der Europäischen Union, dieser geht über die Mitgliedsstaaten u.a. an die BNetzA
• Die politische Verantwortlichkeit in Deutschland liegt bei der Kultusstaatssekretärin Claudia Roth
• Einige Mitarbeiter der BNetzA erstellen neben ihrer eigentlichen Arbeit Vorlagen für die Sperrlisten
• Die Mitarbeiter kontaktieren die betreffenden Betreiber nicht vorab, um eine Löschung zu erreichen
• Die Abteilung Netzneutralität der BNetzA prüft, ob die ausgewählten Ziele evtl. zu Overblocking führen
• Die so bereinigte Liste wird an die Verbände (u.a. Breko) verteilt, die diese dann an die Mitglieder verteilen
• Mit Beschluss der EU wir der Ratsvorschlag entweder angenommen, geändert oder abgelehnt
• Ab dem Zeitpunkt des Beschlusses gilt die Umsetzungsverpflichtung bei den ISPs

Lt. BNetzA gibt es für den ISP dabei zu beachten:

• Eine zu frühe Sperrung (vor dem Beschluss) ist illegal. Kunden können auf Schadenersatz bestehen (oder einklagen)
• Eine falsche Sperrung (wenn sich die Beschlusslage gegenüber der Vorlage ändert) ist ggfls. In Teilen illegal und erlaubt Schadenersatzansprüche
• Eine nicht durchgeführte Sperrung ist illegal und wird ggfls. von der Staatsanwaltschaft verfolgt
• Ein Overblocking (also eine Sperrung, die mehr blockt als die von der Sanktion belegte Organisation) ist illegal und wird von der BNetzA ordnungsrechtlich verfolgt. Betroffenen Kunden steht Schadenersatz zu.
• Die Listen der BNetzA enthalten teilweise URLs, dann ist nur der spezifische Webdienst zu sperren, eine DNS Sperre kann Overblocking sein
• Für die von der BNetzA herausgegebenen Listet sichert die BNetzA zu, kein Ordnungswidrigkeitsverfahren gegen den ISP einzuleiten, wenn es zu Overblocking kommt.

In dem konkreten Fall diese Woche sind mehrere strittige Seiten mit Deeplinks (also Teile des Angebots) aufgeführt, die selbst nicht russischen Behörden oder Organisationen zuzuordnen sind. Eine Rückfrage bei mindestens einem der Betreiber zeigte, dass dieser vorab nicht informiert wurde und den betreffenden Kanal (eine Webseite mit einem Link zu einem russischen Angebot, also nicht mal selbst gehostet) gelöscht hat. Diese Information wurde an die BNetzA und die Breko weitergegeben mit der Bitte um eine Aussetzung oder Korrektur der Liste. Bisher gibt es keine Rückmeldungen. Ebenso liegt der Beschluss noch nicht vor: https://eur-lex.europa.eu/oj/direct-access.html?locale=de.

Kurz und gut: Bisher ist eine Umsetzung nur möglich, wenn die zu sperrenden Domains einzeln durch den Geschäftsführer des betreffenden ISP angewiesen wurde. Dieser trägt dann die Verantwortung für Schadenersatzforderungen der Kunden, Nichtdurchführung der Sanktionen und Overblocking.

Reaktion auf Löschmitteilung

Nachdem die BNetzA am Freitag auf die erfolgreiche Löschung u.a. bei coolstreaming hingewiesen wurde, verbunden mit der Bitte um Aussetzung oder Korrektur der Liste, kam am Dienstag eine Antwort:

• Klarstellung, dass die Domainsperre auch bei vollen URLs nicht als Verstoß gegen die Netzneutralität bewertet wird
• Mit Verweis auf den Beschluss vom Freitag werden die Listen der URLs nochmal wiederholt, jetzt aber ohne Deeplink, so dass eine Überprüfung der Sanktionsfähigkeit nicht mehr erfolgen kann
• Klarstellung, dass Overblocking durch die Sanktionen in Kauf genommen wird: So lange sich hinter den betroffenen Domains Inhalte befinden, die von der EU-Sanktionsverordnung gedeckt sind, muss die gesamte Domain gesperrt werden.
• Klarstellung, dass Löschen nicht in der Sanktionsverordnung aufgeführt ist, sondern ausschließlich das Unterbinden des Transports der Inhalte
• Klarstellung, dass gelöschte Inhalte nicht geblockt werden dürfen
• Hinweis darauf, dass die BNetzA nur mit den Branchenverbänden kommuniziert, nicht aber mit den von den Sperren betroffenen Unternehmen
• Klarstellung, dass die BNetzA nicht für die Durchführung der Sanktionen zuständig ist, sondern dies ausschließlich in der Hand der verpflichteten Unternehmen (ISPs) liegt
• Klarstellung, dass die Listen der BNetzA lediglich besagen, dass Sperrungen, die diese Domains umfassen, nicht als Verstoß gegen die Netzneutralität gewertet werden
• Dies gilt natürlich nicht für Domains, die keine sanktionierten Inhalte hosten. Der ISP hat das selbstständig zu prüfen.

Trotz Hinweis auf Löschung der Inhalte sind die betroffenen Domains weiterhin in der Liste aufgeführt. Diesmal aber ohne Kontrollmöglichkeit für den betroffenen Internetprovider. Verbunden mit dem Hinweis, dass die Sperrung von Domains, die keine sanktionierten Inhalte mehr enthalten, wieder ein Verstoß gegen die Netzneutralität darstellt, selbst wenn diese in der Liste der BNetzA enthalten war, ist das ein starkes Stück: Es wird bewusst ein Haftungsprivileg suggeriert, von dem die suggerierende Stelle bereits weiß, dass dieses Privileg nicht zutrifft.

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.