Skip to content

Corona-Infektion im Haushalt eindämmen

Stellt euch vor, ihr lebt mit mehreren Personen in einer Wohnung und jemand von denen hat sich mit SARS-CoV-2 infiziert. Wie schafft ihr es, dass alle anderen uninfiziert bleiben? Vor knapp zwei Jahren habe ich mir die Frage gestellt und mir ein “Konzept” überlegt. Über diesen Zeitraum habe ich immer mal wieder darüber nachgedacht und Änderungen vorgenommen. Nun kam der Zeitpunkt, wo ich mein Konzept mal live testen kann und weitere Änderungen machte. Ich will euch meine Ideen mal unten vorstellen. Solltet ihr Verbesserungen oder Fragen haben, freue ich mich natürlich über Kommentare.

Tweet von @fischblog zur Übertragung im Haushalt

Das Corona-Virus ist hochansteckend. Derzeit geht die Variante Omikron in Form von BA.5 herum. Wie schon bei den Vorvarianten hört man immer wieder, dass ganze Familien erwischt werden. In einem Thread auf Twitter schätzt @fischblog die Wahrscheinlichkeit auf unter 50%, wenn man mit Infizierten in einem Haushalt lebt. Quelle scheint die Studie “Secondary Attack Rates for Omicron and Delta Variants of SARS-CoV-2 in Norwegian Households” zu sein. Diese etwa 50% würde ich nun gern auf 0% oder nahe 0% bringen.

Ziel

Wie ich schon schrieb, geht es mir darum, weitere Ansteckungen innerhalb des Haushalts auszuschließen bzw. das Risiko weitgehend zu minimieren.

Maßnahmen

Neben den untenstehenden Maßnahmen gibt es natürlich einiges in der Vorbereitung. Zuallererst steht für mich die Impfung. Alle sollten geimpft sein. Nach meiner Meinung heißt dass derzeit, dass die letzte Impfung gegen SARS-CoV-2 maximal ein halbes Jahr her ist.

Kurzversion

  • Person isolieren
  • Maske in der Wohnung tragen
  • Wohnung gut lüften
  • Viruzides Gurgeln
  • Kontaminierte Gegenstände waschen, desifizieren oder wegräumen

Isolationszone

Innerhalb der Wohnung sollte es eine Isolationszone geben. Idealerweise ist das ein Zimmer, in dem sich die infizierte Person aufhält. Dort bleibt diese solange, bis sie wieder negativ getestet ist.

Generell erscheint mir wichtig, dass möglichst wenig Luft aus der Isolationszone in den Rest der Wohnung strömt. Das heißt, der Raum selbst sollte gut durchlüftet werden.

In der Isolationszone verbleiben auch alle Gegenstände, die die infizierte Person berührt (Teller, Besteck, Taschentücher, Nahrung etc.). So soll eine “Kontamination” möglichst vermieden werden. Problematisch sind Sachen, die gekühlt werden müssen sowie das Bad bzw. die Dusche. Hier sollte darauf geachtet werden, dass die Räume regelmäßig mit Seife gereinigt oder desinfiziert werden.

Isolation bedeutet aber auch, dass die Person wenig oder gar keinen Kontakt zu anderen hat. Dies ist auf Dauer belastend. Regelmäßige Videokonferenzen, Telefonate oder andere Fernkontakte sind daher wichtig. Beispielsweise kann die Person über einen Videoanruf am gemeinsamen Essen teilnehmen oder anderweitig mit eingebunden werden. Dies erleichtert die Zeit in Isolation enorm.

Belüftung

Das Virus sollte die Wohnung möglichst schnell wieder verlassen. In den warmen Tagen sollten einfach alle Fenster geöffnet sein. Aus meiner Sicht solltet ihr darauf achten, dass der Luftzug nicht Luft aus der Isolationszone anzieht. Unsere Wohnung ist glücklicherweise so beschaffen, dass ich über einen Luftstrom die Luft direkt aus der Wohnung leiten kann.

Für die kälteren Tage habe ich Luftreiniger beschafft. Eines steht in der Isolationszone und tut dort seine Arbeit. In den Aufenthaltsräumen steht auch mindestens einer. Dieser wälzt die Luft mindestens einmal um, bevor der Raum benutzt wird.

Masken

Ein einfaches und wirksames Mittel sind Masken. Wir tragen innerhalb der Wohnung eine FFP2-Maske. Dies ist für mich der Basisschutz, der immer funktionieren muss. Innerhalb unserer Wohnung gibt es einige Bereiche, die so gut belüftet sind und wo kein “infizierter” Luftstrom hinkommt, dort verzichten wir dann auf die Maske.

Hände waschen / desinfizieren

Es kann immer mal sein, dass man in Kontakt mit Gegenständen kommt, die auch die infizierte Person berührt hat. Insbesondere bei gemeinsam genutzten Räumen, wie Bad, besteht die Gefahr mit Virenrückständen in Kontakt zu kommen. Daher muss insbesondere in solchen Situationen ausführlich Hände gewaschen oder desinfiziert werden. Dabei ist Seife und warmes Wasser sehr wichtig.

Prophylaxe bei Exposition

Nun kann es immer sein, dass man mit Viren in Kontakt kommt. Hierzu gibt es eine Empfehlung der Gesellschaft für Krankenhaushygiene zum viruziden Gurgeln. Das heißt, Gurgeln mit

  • Kochsalzlösung (1 Teelöffel auf 100 ml, 3 min)
  • grünem Tee
  • Listerine Cool Mint

und Anwendung von Algovir Nasenspray.

Dies reduziert die Virenlast und vermindert damit auch den Schweregrad der Erkrankung.

Entsorgung der kontaminierten Gegenstände

Wie oben beschrieben, verbleiben die Gegenstände zunächst in der Isolationszone. Diese werden von Zeit zu Zeit ausgeräumt. Geschirr wird sofort mit Seife abgewaschen. Müll wird ordentlich verpackt und in die Mülltonne gegeben.

Erfolgskontrolle

Ob die Maßnahmen funktionieren oder nicht, lässt sich letztlich schwer sagen. Einerseits weiß ich nicht, was ohne jegliche Vorkehrungen passiert wäre. Sofern man sich noch außerhalb der Wohnung bewegt und sich infiziert, ist andererseits auch oftmals unklar, wo die Infektion passierte.

Insgesamt gehe ich davon aus, dass die Maßnahmen sehr helfen, das Infektionsrisiko in der Wohnung abzusenken.

Update: Nach einem Hinweis auf Twitter habe ich den Link zum PDF für das viruzide Gurgeln aktualisiert. Die DGKH hat die Empfehlungen in diesem Jahr aktualisiert.

Automatisch ein screen nach einem SSH-Login starten

Wenn ich mich auf einem Server per SSH einlogge, starte ich in der Regel direkt die Software screen oder tmux. Dies sind so genannte Multiplexer. Sie erlauben es mir mehrere “Fenster” zu öffnen und auch wenn die Verbindung weg ist, werden die Befehle weiter abgearbeitet.

Im Normalfall gebe ich also zuerst ssh server ein und wenn ich dann auf dem Server eingeloggt bin, gebe ich screen -R oder tmux a ein. Viel schöner wäre es nun, wenn der letzte Schritt automatisiert geschehen würde. Man mag es kaum glauben, aber OpenSSH ist dazu in der Lage. :-)

Hier hilft eine kleine Einstellung in der Konfigurationsdatei. Diese liegt normalerweise im Verzeichnis ~/.ssh und heißt config. Ein Eintrag könnte so aussehen:

Host server
  HostName server.example.com
  IdentityFile ~/.ssh/mein-geheimer-schluessel
  User jens

Mit der Eingabe ssh server verbindet sich SSH zu dem Rechner unter der Adresse server.example.com, nutzt den angegebenen Schlüssel und loggt sich als Nutzer jens ein. Mit den Optionen RemoteCommand und RequestTTY kann ich nun den gewünschten Effekt erzielen:

Host server
  HostName server.example.com
  IdentityFile ~/.ssh/mein-geheimer-schluessel
  User jens
  RemoteCommand screen -RD #oder tmux a
  RequestTTY yes

Nun führt OpenSSH den gewünschten Befehl aus und ich lande sofort in meiner gewünschten Sitzung.

Dies ist natürlich nur eine Kleinigkeit. Aber es nimmt mir einen kleinen Schritt ab und fühlt sich so bequemer an. Vielleicht probiert ihr es auch mal aus und erzählt von euren Erfahrungen.

Ein Brief als trojanisches Pferd

https://nitter.dark.fail/qbi/status/1519444736431603716
Screenshot von https://nitter.dark.fail/qbi/status/1519444736431603716

Vor einiger Zeit fragte ich, was passieren würde, wenn jemand von geheimen Plänen berichten würde, dass Schulen “islamisiert” werden sollen. Die Reaktionen hielten sich in Grenzen. Jemand meinte, es würde mit den 3 L des Beamtenlebens bearbeitet:

  • Lesen
  • Lachen
  • Lochen

In der Realität gab es leider nicht so banale Folgen auf diesen Brief. Vielmehr hatte dieser Brief massive Folgen, kostete einigen Menschen den Job und sorgte für einige Verunsicherung. Was ist passiert?

Anfang des Jahres 2014 tauchte in Birgmingham ein Brief auf, der mittlerweile als Trojan Horse Letter im Vereinigten Königreich weithin bekannt ist. Darin beschrieben die Autor:innen, dass sie unter dem Radar agieren und versuchen, Schulen zu “islamisieren”. Es wurde in dem Brief ein Vorgehen beschrieben, wie man das erfolgreich umsetzen kann und einige Schulen wurden genannt, wo dies angeblich erfolgreich durchgeführt wurde.

Erste Seite des Trojan Horse Letter

Erste Seite des Trojan Horse Letter (Kopie aus dem Bericht von Peter Clarke)

Im Brief wurde unter anderem Tahir Alam “beschuldigt”. Er hatte vorher sehr erfolgreich eine Schule gemanagt. Diese stand wegen schlechter Leistunge kurz vor der Schließung. Alam übernahm das Management und verbesserte die Schule. Vor Erscheinen des Trojan Horse Letters erhielten die Schule und er viele Preise und wurden hochgelobt. Durch die Auswirkungen des Briefes verlor er seine Stelle und darf sich auch nicht mehr in Schulen engagieren.

Weitere Personen wurden ebenfalls aus dem Schulbetrieb verbannt, es gab Antiterrorermittlungen und selbst Regierungsstellen schalteten sich ein.

Nun kann man sich fragen, wer eigentlich diesen Brief in die Welt gesetzt hat. Auf den verfügbaren Kopien des Briefes fehlen erste und letzte Seite. Daher wird das direkt aus dem Brief nicht klar. Es gab wohl einige Ermittlungen. Allerdings konnten Urheber nie festgestellt werden.

An dieser Stelle setzt nun ein Podcast “The Trojan Horse Affair” der New York Times an. Der Journalist Hamza Syed versucht als Abschlussarbeit seines Journalismusstudiums den oder die Urheber zu finden und nimmt uns in den Sendungen mit auf die Reise. Und diese Reise ist wahrhaft spannend. Sie versuchen, aufgrund der Umstände zu schließen, woher der Brief kommen könnte, finden logische Anhaltspunkte und können diese begründen. Im Verlauf ihrer “Ermittlungen” kommen sie jedoch sehr oft in mekrwürdige Situationen, einmal wird gegen sie ermittelt und sie müssen das Land verlassen.

Der Podcast ist sehr gut gemacht und man erfährt sehr viel über das britische Schulsystem, über die Auswirkungen der Terrorhysterie und auch wie Ermittlungen blockiert werden. Hört euch das unbedingt mal an.

Start der Woche bei Logseq

Date Picker bei Logseq
Date Picker bei Logseq

Ich habe angefangen, Logseq und Obisidan für das Wissensmanagement auszuprobieren. Meine ersten Erfahrungen hatte ich verbloggt. Mittlerweile nutze ich Logseq recht regelmäßig und bin bisher recht zufrieden.

Eine Sache, die mich bislang störte, war der so genannte Date Picker. Damit lässt sich ein Datum aussuchen. Logseq stellt den Wochenbeginn auf Sonntag. “Meine” Woche beginnt jedoch montags. Bisher gab es keine Möglichkeit, dies umzuschalten. Seit kurzem hat sich dies geändert. Der Pullrequest 4949 brachte die Erleichterung. Nun gibt es eine Konfigurationsoption namens :start-of-week. Wenn der Wert auf 0 steht, beginnt die Woche auch am Montag.

Dazu müsst ihr die Einstellungen öffnen und “config.edn bearbeiten” wählen. In der Datei, die sich öffnet, sucht ihr nach der Konfigurationsoption und ändert diese. Ein explizites Speichern ist nicht nötig.

Später ist vorgesehen, dass sich das auch über einen Menüeintrag anpassen lässt.

Im obigen Screenshot seht ihr die Abkürzung des Wochentages. Sat steht für Saturday. Das ist die nächste Kleinigkeit, die mich noch stört. Dies lässt sich nämlich nicht ins Deutsche übertragen. Hierzu gibt es den Issue 5421. Mal sehen, wann und ob dieser behoben wird …

Webfinger bei Mastodon

In meinem vorigen Beitrag hatte ich über den vergleichsweise neuen RFC 9116 geschrieben. Der RFC 742 ist hingegen schon 45 Jahre alt. Der definierte damals das Finger-Protokoll, mit dem sich Informationen über Benutzer:innen gewinnen ließen:

jens@host:~$ finger
Login     Name               Tty      Idle  Login Time   Office     Office Phone
peter     Peter Ones        *:3             Apr 19 13:09 (:3)
paul      Paul Twos         *:2             Apr 17 21:01 (:2)
mary      Mary Threes       *:1             Apr  2 22:38 (:1)

Oder für einen bestimmten Username:

jens@host:~$ finger peter
Login: peter                       Name: Peter Ones
Directory: /home/peter             Shell: /bin/bash
On since Sun Apr 17 21:01 (CEST) on :2 from :2 (messages off)
No mail.
No Plan.

Kürzlich fand ich heraus, dass ich auch Personen bei Mastodon, einem Twitter-ähnlichen sozialen Netzwerk, fingern kann. Hierzu benötigt man im wesentlichen die Domain der Mastodoninstanz und den Usernamen. Daraus wird eine Anfrage gebaut, die wieder das .well-known-Verzeichnis nutzt, welches ich schon im letzten Beitrag erwähnt hatte.

Eine Anfrage auf die Adresse https://mastodon.social/.well-known/webfinger?resource=acct:qbi@mastodon.social liefert dann folgendes Ergebnis:

{
  “subject”: “acct:qbi@mastodon.social”,
  “aliases”: [
    “https://mastodon.social/@qbi”,
    “https://mastodon.social/users/qbi”
  ],
  “links”: [
    {
      “rel”: “http://webfinger.net/rel/profile-page”,
      “type”: “text/html”,
      “href”: “https://mastodon.social/@qbi”
    },
    {
      “rel”: “self”,
      “type”: “application/activity+json”,
      “href”: “https://mastodon.social/users/qbi”
    },
    {
      “rel”: “http://ostatus.org/schema/1.0/subscribe”,
      “template”: “https://mastodon.social/authorize_interaction?uri={uri}”
    }
  ]
}

Das bedeutet, den angefragten Username gibt es und dessen Profil ist unter der Adresse https://mastodon.social/users/qbi verfügbar.

Im Allgemeinen heißt dieses Protokoll Webfinger und ist für die Mastodon-Instanzen verfügbar. Probiert es doch mal aus!

security.txt

Kennt ihr noch die Datei robots.txt, die auf verschiedenen Webseiten hinterlegt sind? Dahinter stand der Robots Exclusion Standard und die verschiedenen Bots sollen zuerst die Seite ausweren, bevor sie eine Webpräsenz indexieren. Daneben entstand auch die Idee für eine humans.txt und mit dem “Erschaffen” des .well-known-Verzeichnisses auf dem Webserver gibt es eine ganze Reihe Dateiformate zur Information oder für andere Zwecke.

Seit April 2022 gibt es nun den RFC 9116 für die Datei security.txt. Diese soll anderen helfen, Sicherheitslücken an die richtige Stelle zu melden. Denn oftmals steht das Problem, dass eine Schwachstelle gefunden wurde und es vielleicht unklar ist, wohin diese zu melden ist.

Mail wäre natürlich eine mögliche Wahl. Im besten Fall existiert sogar eine E-Mail-Adresse namens security@. Aber sehr häufig ist dies nicht der Fall. Mails an info@ oder ähnliche Adressen landen eher im Nirwana oder werden mit Standardtextbausteinen beantwortet. Daher ist ein gezielter, standardisierter Weg gut.

Der RFC 9116 definiert hierfür eben die Datei security.txt, die im Unterordner .well-known einer Webpräsenz liegen muss. Die Datei selbst muss über HTTPS erreichbar sein. Ein korrekter Pfad wäre also https://example.com/.well-known/security.txt.

Doch was darf da drin stehen? Naheliegend sind Kontaktinformationen. :-) Spezieller Informationen, an die man Informationen zu Schwachstellen melden kann. Hierfür ist der Eintrag Contact: gedacht. Dieser muss in der Datei enthalten sein und sollte die Kontaktmöglichkeiten in absteigender Reihenfolge enthalten. Daneben benötigt die Datei zwingend ein Ablaufdatum. Eine Minimalversion der Datei kann also so aussehen:

Contact: mailto:security@example.com
Expires: 2023-05-01T12:13:24+02:00

Weiterhin könnt ihr in der Datei Informationen zu einer Policy hinterlegen, welche Sprachen ihr sprecht, ob ihr Leute einstellt, wer in der Vergangenheit Lücken meldete und einen Verweis zu einem Schlüssel machen. Eine erweiterte Version der Datei sähe also so aus:

Contact: mailto:security@example.com
Contact: +49-123-456-7890
Contact: https://example.com/meldeformular.html
Policy: https://example.com/security-policy.html
Preferred-Languages: de, en
Acknowledgments: https://example.com/hall-of-fame.html
Encryption: https://example.com/pgp-key.txt
Expires: 2023-05-01T12:13:24+02:00

Hier sind mehrere Kontaktmöglichkeiten genannt. Es gibt eine Policy. Die Leute sprechen Deutsch und Englisch und ihr bekommt Infos über andere, die etwas gemeldet haben. Am Schluss findet sich auch ein PGP-Schlüssel. Optimalweise würde der über Web Key Discovery bereit gestellt. Aber das ist ein Thema für einen anderen Beitrag. ;-)

Schließlich könnt ihr den Eintrag auch noch mittels OpenPGP signieren. Dann sähe meine obige Datei so aus:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Contact: mailto:security@example.com
Contact: +49-123-456-7890
Contact: https://example.com/meldeformular.html
Policy: https://example.com/security-policy.html
Preferred-Languages: de, en
Acknowledgments: https://example.com/hall-of-fame.html
Encryption: https://example.com/pgp-key.txt
Expires: 2023-05-01T12:13:24+02:00

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.2.19

[Viele Zeichen, die gpg auswerten kann]
-----END PGP SIGNATURE-----

Wenn ihr also eine Schwachstelle gefunden habt, dann lohnt es sich nach der Datei zu schauen und die dort genannten Kontakte anzusprechen. Ich habe mal ein wenig gegraben. Bei den großen, bekannten Seiten, wie Google, Facebook, Twitter, GitHub usw., fand ich jeweils eine solche Datei. Seiten aus dem Microsoft-Universum wie auch viele chinesische Seiten haben keinerlei solche Informationen.

Ansonsten ist das Bild recht gemischt. Während beispielsweise Facebook und WhatsApp eine security.txt anbieten, hat Instagram keine, obwohl alle zum selben Konzern gehören.

Unter andere namhaften Seiten fand ich nichts bei

  • Reddit
  • Wikipedia
  • Zoom
  • Netflix
  • Stackoverflow
  • Apple
  • und weiteren

Hier ist also noch ein wenig Arbeit zu tun. Wenn die Datei auch bei euch oder eurem Arbeigeber fehlt, sprecht die doch an und bittet die, diese Informationen bereitzustellen (und natürlich bei Bedarf zu aktualisieren).

Siehe auch:

Update: Ich hatte übersehen, dass das Expires:-Feld auch ein Pflichtfeld ist und habe die obige Beschreibung ergänzt. Vielen Dank an Jürgen für den Hinweis!

Warum eine Onion-Adresse betreiben anstatt Menschen animieren, Tor zu nutzen

Dieser Text ist eine Übersetzung des Blogpostings Why offer an Onion Address rather than just encourage browsing-over-Tor? von Alec Muffett. Alex pflegt auch eine Liste nützlicher Onion-Adressen.


Es gibt eine Reihe von Gründen, eine Onion-Site einzurichten. Ein Reihe von Vorteilen waren für Plattformen wie Facebook, BBC oder NYTimes von Nutzen.

Die ersten Vorteile sind Authentizität und Verfügbarkeit: Wenn du den Tor-Browser benutzt und genau die richtige Onion-Adresse eingibst, bist du garantiert mit der erwarteten Seite verbunden, was du erwartest - oder eben gar nicht.

Das ist für die Menschen sehr einfach zu begreifen und auch einfach zu erklären.

Diese Funktion entschärft Angriffe, die von möglicherweise bösartigen “Tor-Exit-Knoten” ausgehen können. Die Angriffe sind zwar selten, existieren aber dennoch. Die Tatsache, dass du eine “.onion”-Adresse verwendest, setzt voraus, dass du Tor und den Tor-Browser verwendest. Dies entschärft die folgenden möglichen Angriffe:

  • landesweite Websperren
  • Man-in-the-Middle-Angriffe auf das TLS-Protokoll
  • SNI-Filter
  • Tracking und Zensur von DNS-Anfragen (betrifft sowohl Clients wie auch Exitknoten)
  • Probleme beim Tracking durch Cookies und Fingerprinting-Angriffen
  • … sowie eine Reihe weiterer Probleme

Um es anders zu formulieren: Die Werbung für eine Onion-Adresse ist ein implizites Verkaufsargument für die Nutzung von Tor.

Update: Eine Sache, die ich in der ursprünglichen Version dieses Beitrags vergaß zu erwähnen, ist, dass die Nutzung von Onion-Netzwerken für Seiten mit hohem Traffic den Druck auf die Exit-Node-Infrastruktur von Tor reduziert. Denn der Traffic fließt stattdessen durch die größere und reichhaltigere Menge an Middle-Relays, ohne Exit-Nodes und/oder das Klartext-Internet zu nutzen.

Letzteres ist wichtig und bringt uns zum zweiten (dritten?) Satz von Vorteilen:

Der Betrieb einer Onion-Site ist eine Verpflichtung [der Plattform], mit Tor-Benutzer:innen gerecht umzugehen; bei der normalen Benutzung von Tor werden die Benutzer mit allen anderen vermischt, die aus dem Internet kommen, und (seien wir ehrlich) einige Leute benutzen Tor manchmal zum Herunterladen einer kompletten Webpräsenz (Scraping) oder anderem unangenehmen Verhalten.

Das führt zu der Herausforderung, die “Spreu vom Weizen zu trennen”.

Das Einrichten einer Onion-Adresse ist jedoch ein praktischer Schritt, der zeigt, dass die Plattform explizit auf die Bedürfnisse von Tor-Nutzern eingeht, und nun kehrt sich das Problem um: Ein gewisses Maß an schlechtem Verhalten über die Onion-Adresse kann überwacht und als “schlechtes Verhalten” eingestuft werden, was den Tor-Nutzern maximale Freiheit gewährt.

Dies ist eine Angelegenheit, die ich bei Facebook hautnah miterlebt habe und auf einer Tor-Mailingliste beschrieben habe.

Wenn ich die Vorteile in einem Satz zusammenfassen sollte, wäre es folgender: Eine Onion-Adresse ist ein Versprechen und ein Mechanismus, der sicherstellt, dass du die Bedürfnisse der Leute, die Tor benutzen, ernst nimmst.

Anstatt ihnen zum Beispiel eine endlose Reihe von CAPTCHAs auf Basis der IP-Reputation aufzudrängen.

 

 

cronjob