Die aktuell kochende Debatte zur Reform des Urheberrechts, insbesondere im Zusammenhang mit dem Internet ist ebenso spannend wie ermüdend. Es gilt dabei in der erster Linie zu verstehen, was den jeweiligen Gegenpart antreibt.

Die Erschaffer

Jedes Werk hat einen Erschaffer. Der Akt des Erschaffens ist eine Investition von Zeit, Können und Material. Auch der Akt der Aufführung ist eine solche Investition. Und wofür? Für den Konsumenten. Im Idealfall zahlt der dann dem Erschaffer für seine Leistungen einen Preis.

Es ist allerdings schwierig - sowohl für den Erschaffer als auch für den Konsumenten, für das Werk zusammen zu kommen. Hierbei braucht es Hilfe.

Die Rechteverwerter

Auslöser des Ganzen Spektakels ist die sterbende Branche der Rechteverwerter. Dies ist eine Gruppe von kommerziellen Vermittlern zwischen Erschaffenden und Konsumenten. Sie spekulieren auf zukünftige Talente, indem sie sie frühzeitig unter Vertrag nehmen, leidlich finanziell ausstatten und zu Erfolgserlebnissen führen. Hat man Glück mit der Spekulation werden große Geldsummen umgesetzt, an denen der Vermittler beteiligt wird. Davon kann er auch Fehlschläge abfedern. Sei es ein Buch, ein Musikstück, ein Film, eine Skulptur, ein Bild, ein Theaterstück, eine Fernsehserie, ein Computerspiel oder etwas anderes.

Die Rechteverwerter haben mit dem Urheberrecht ein Mittel in der Hand, mit der sie dem Schaffenden die Verwertung seiner Werke abkaufen. Er kann dann oft selbst nicht auftreten, ohne eine Vereinbarung mit seinem eigenen Verwerter getroffen zu haben, d.h. ein Teil seiner Einnahmen abführen zu müssen.

Voraussetzung dieses Modells ist, dass die Aufführungen unter Kontrolle des Vermittlers bleiben. In der einfachsten Form wird der Vermittler die Aufführung selbst organisieren. Um eine Amortisation der Anfangskosten und Fehlinvestitionen sicher zu stellen, werden die Verwertungsrechte sehr lang gewährt, auch über den Tod des Erschaffers hinaus. Die Idee dahinter ist, dass einige wenige zentral agierende Vermittler so viel Fehlinvestitionen vornehmen können, dass ein reiches kulturelles Leben für alle gedeihen kann.

Wie in allen Fällen verselbstständigen sich Teile des Konzepts und es gibt unerwünschte Missbildungen. So kann ein Vermittler wesentlich zu hart mit vermeintlichen Aufführungen umgehen, bspw. wenn Kinder beim Laternenumzug singen. Auch Gerechtigkeitsfragen sind ein immer wieder auftretender Knackpunkt, insbesondere, wenn es um die weitere Finanzierung der Fehlinvestitionen geht. Was kulturell wertvoll ist, muss nicht zwangsläufig eine sprudelnde Geldquelle sein.

Eine besondere Form der Vermittlungstätigkeit ist im Journalismus anzutreffen: Die erzeugten Produkte haben eine Halbwertszeit von wenigen Tagen, erfordern aber oft einen erheblichen Aufwand, um seriös zu sein. Entsprechend hoch ist der Druck, die wenigen Ergebnisse schnell, häufig und exklusiv zu vermarkten. Ein wesentliches Problem ist dabei die leichte Reproduktion des Produktes (einer Nachricht). An dieser Stelle wäre es dem Vermittler (der Zeitung) sehr recht, wenn sämtliche - auch ansatzweise reproduzierten - Kopien der Nachricht unter Kontrolle des Vermittlers blieben. Dies ist der Kern des Leistungsschutzrechtes. Es wird ebenfalls unter der Annahme formuliert, viele Fehlinvestitionen zu kompensieren und damit eine Vielfalt an Meinungen zu erhalten.

Das Internet

Der Kerngedanke des Internets ist dagegen die Idee, jede Form von Vermittlung zu vermeiden: "Jeder hat das Recht zu senden" und "Jeder hat das Recht sich aus öffentlich verfügbaren Quellen zu informieren" sind zwei Aussagen, die das Grundgesetz als Meinungs(äußerungs)freiheit und Rezipientenfreiheit bezeichnet. Diese Offenheit des Internet führt zu einen bis dahin unbekannten Meinungspluralismus und einem gigantischen kulturellem Reichtum, der jedem zur Verfügung steht.

Unglücklicherweise kann nicht jeder jedem jederzeit zuhören. Stattdessen muss man seine zeitlich beschränkte Aufmerksamkeit auf wenige von einem selbst ausgewählte Informationen konzentrieren. Welche das sind, entscheidet die Aufmerksamkeitsökonomie.

Was man aber tun kann, ist andere auf eine Quelle hinzuweisen. Dieses Konzept der Referenzierung einer Quelle nennt man Verlinkung. Mit einem kurzen kontextbezogenen Hinweis wird der Interessierte an die Originalstelle verwiesen. Der Hinweistext dient dabei als Motivation, zum fremden Angebot zu wechseln.

Referenzierung führt also vom eigenen Angebot weg zu einem Fremden. Es ist eine aktive Abgabe des Nutzers an andere. Dies ist das vollständige Gegenteil dessen, was bei einem Verwertungsmodell umgesetzt werden soll: Der Konsument soll maximal viel Ressourcen bei nur einem Produkt investieren.

So gesehen liegt dem Internet eine kommunistische Idee zugrunde: Jeder bietet an, was er kann und jeder nutzt, was er braucht. Auch das führt zu Vielfalt, nicht aber zu finanzieller Sicherheit für den Erzeuger. Internet kann man halt nicht essen.

Die angebotenen Monetarisierungsmöglichkeiten sind derzeit beschränkt: Man kann die gewonnene Aufmerksamkeit verkaufen indem man Werbung einblendet, oder man fordert vorab eine Bezahlung der Leistung ein (Paywall). Auf der Strecke bleiben dabei alle Dienstleister, die den Abruf der Information überhaupt erst ermöglichen: Niemand zahlt die Einnahmen anteilig an die Hersteller der Browser, der Betriebssysteme, der Webserver oder gar an die Transporteure der Daten. Die Infrastruktur wird als gegeben hingenommen.

Die Verweise selbst, die oft schon viel von der Information verraten, bleiben dabei komplett außen vor. Wer an dieser Stelle ein Geschäft aufzieht, indem er Verweislisten anbietet und die Aufmerksamkeit des Besuchers bei sich behält, kann die Geldflüsse zu sich umleiten. Das ist genauso wie eine Zeitung das Geld einsammelt, indem sie die Arbeit der Journalisten zusammenfasst und vervielfältigt. Interessanterweise unterscheidet sich hier das Vertragsverhältnis: Für einen Link im Internet braucht man keinen Vertrag, für einen Abdruck in der Zeitung schon.

Man könnte einfach hingehen und das Problem ignorieren. Wer interessante, wertvolle, oder aufmerksamkeitsheischende Inhalte anzubieten hat, wird durch viele Referenzen viele Konsumenten zugespielt bekommen und kann dann selbst monetarisieren.

Um aber gute Werbeverträge zu bekommen, braucht man einen Vermittler. Schon wieder Vermittler? Ja, allerdings liegt das Risiko komplett beim Erschaffer, denn eine Vorfinanzierung gibt es nicht.

Lösungsmöglichkeit

Wie kommt man aus diesem Dilemma heraus?

Es bedarf der Möglichkeit eines Vertragsschlusses zur Referenzierung, alternativ Micropayments. Könnte der Erschaffer (oder sein Rechteverwerter) eine korrekt, bezahlte Referenzierung ermitteln, so könnte er die Paywall nach außen verlagern und das Geld an den referenzierenden Plattformen auf Vertragsbasis abgreifen.

Was es dazu braucht ist eine andere Art der Referenzierung. Diese muss bis durch den Verbindungsaufbau hindurch den Nachweis der Abrechnung gestatten. Mit dem klassischen LINK-Element geht das nicht.

Gäbe es ein Element (ich nenne es mal das RECHTS), das den Verkauf von Referenzierungsrechten gestattet, so könnten die großen Plattformen entsprechenden Kontingente erwerben und damit auf die interessanten und spannenden Inhalte verweisen.

Es geht um die <right
  prepaid="U3BpZWdlbC5PbmxpbmU9UGF5Okdvb2dsZToxMjM0NTYK"
  href="https://spiegel.example/123456"
>Freiheit des Internets</right> und die Zukunft unserer Gesellschaft.

Wer kein Plattformbetreiber ist, kann trotzdem auf die Inhalte referenzieren, indem er auf die Micropayment-Schnittstelle des Verwerters verweist.

Es geht um die <right
  payment="gemacoin:springer"
  currency="EUR"
  view="0.0001" click="0.001"
  href="https://spiegel.example/123456"
>Freiheit des Internets</right> und die Zukunft unserer Gesellschaft. 

Da bei dieser PayPerUse Methode nicht sicher gestellt ist, dass entsprechende Zahlungen erfolgen, wurde der Preis zum Anzeigen des Referenzierungstextes auf ein Hundertstel-Cent festgelegt. Der Browser verhindert dann die Anzeige des Referenzierungentextes.

linktax

Das Anklicken kostet dann ein Zehntel-Cent. In beiden Fällen wird eine spezielle Form der TCP-Kommunikation zum Webserver aufgemacht, die sicher stellt, dass die Bezahlmethode auch ausgeführt wurde. Erfolgt der Zugriff ohne diese Methode (z.B. per LINK), dann lehnt der Webserver die Anfrage mit 402 - Payment required ab oder lenkt auf eine extra Paywall um.

Zusätzlich ermöglicht diese spezielle Art des Verbindungsaufbaus, dass die Access- und Transitprovider an den Einnahmen der Verwertungsgesellschaften teilhaben. Die Gelder, die durch das RIGHT-Element von den großen Plattformen zu den Erschaffern oder deren Verwertern strömen, sind ja nicht nur für die Leistungen der Erschaffer, sondern auch für die Dienstleistung, die die Provider erbringen, indem sie die Konsumenten zuführen.

Fazit

Der Wunsch aller an einem Werk beteiligter Personen und Unternehmen an entsprechender Entlohnung ist nachvollziehbar. Da das Internet in seiner jetzigen Form das nicht leisten kann, muss es um ein entsprechendes Element der entgeltpflichtigen Referenzierung ergänzt werden. Mittels dieser Erweiterung ist es allen, die auf einer Entlohnung bestehen, möglich, die notwendigen Einnahmen zu generieren.

Es steht jedem frei, seine Werke im Internet mit den kommunistischen Links oder den entgeltpflichtigen Rechts referenzieren zu lassen. Lassen wir also die Rosinenpickerei. Auf beiden Seiten. Verlinken wir nicht mehr auf kommerzielle Inhalte, lassen wir Rechts im Internet gedeihen.

Aktuell wird wieder die Sau der Zensur (Filterung vor Veröffentlichung) und Monetarisierung (Leistungsschutzrecht) durchs globale Dorf getrieben. Und ich muß feststellen, daß das Internet tatsächlich ein Rechtsfreier Raum ist. Aber dagegen kann man etwas tun.

Was ist das Problem mit Links?

Links sind im Internet weit verbreitet. Sie gestatten die Nutzung fremder Leistungen durch Verweis auf die oder Einbindung der fremde Leistung ohne ein Entgelt einzutreiben.

Auf diese Weise ist es selbstverständlich unmöglich, durch kreative Arbeit im Internet Geld zu verdienen.

Und was kann man dagegen tun?

  • Entweder man läßt zu, daß existierende Technik kaputt geklagt wird.
  • Oder man definiert eine neue Technik, die die Probleme punktgenau löst.

Das Internet darf kein rechtsfreier Raum sein

Also definiert man sich Rechts. Rechts sind wie Links, nur halt für die Content-Industrie.

Und sie haben alles, was die "geistiges Eigentum"-Vertreter wüschen:

  • Verweise können entgeltpflichtig werden.
  • Heruntergeladene Inhalte können vor unerwünschter Nachnutzung geschützt werden.
  • Schnellwege für die Datenauslieferung können vereinbart werden.

Und wie geht das? Per Definition bei der IETF.

Im der DSGVO steht drin, daß man seinen Datenschutzbeauftragten bei der Aufsichtsbehörde zu melden hat. Der zuständige Landesdatenschutzbeauftragte hier in Thüringen hat dafür ein sehr interessantes Formular erstellt.

Das Formular

Zum einen ist das Formular keine online-Einreichung, die dem TLfDI die Arbeit erleichtern würde. Stattdessen ist handelt es sich um ein Microsoft Word-Dokument, das man ausfüllen und ausdrucken soll. Anschließend ist das Dokument auf dem Postweg zu versenden, da in der Einreichungsaufforderung keine eMail-Adresse angeben wird.

Der Inhalt des Formulars ist ebenfalls überraschend:

2018-05-24-161013_626x678_scrot

Da stellt sich die Frage, ob denn die Angaben überhaupt alle benötigt werden. Wozu braucht die Aufsichtsbehörde beispielsweise die Webseite des bestellten Datenschutzbeauftragten?

Und dann stellt sich die Frage, was man da eigentlich melden muß.

  • Die verantwortliche Stelle ist ja noch klar.
  • Kommt bei Datenschutzbeauftragter aber nun der Datenschutzbeauftragte hin oder nur dann, wenn es ein interner ist?
  • Oder wird ein interner DSB als externer gemeldet, bei dem das Auswahlfeld externer auf Nein gestellt wurde?

Für die Kirchgemeinde kann ich das gut ausfüllen. Zuerst die Gemeinde, dann der örtlich zuständige DSB der Landeskirche, und dann der extern bestellte DSB des Verbands der evangelischen Kirchen in Berlin. Auf Beschluß der Landessynode wurde also der (externe) DSB an Stelle des (örtlichen) DSB für zuständig erklärt. Aber sonst?

Das Leak

Öffnet man aber die Eigenschaften des Dokumentes (was ich getan habe, weil das Dokument sich heute am Tag verändert zu haben schien), dann staunt man:

2018-05-24-154240_520x675_scrot

Autsch.

Wo meldet man diesen Datenschutzverstoß eigentlich?

Update

Seit heute früh (25.5.2018) gibt es ein neues Formular. Der Link zum alten Formular wird redirected.

Diesmal ist es besser ...

2018-05-25-131455_282x221_scrot

Danke.

Da nun keine Notwendigkeit für die Speicherung dieser personenbezogenen Daten besteht, habe ich auch die Klarnamen und E-Mail-Adressen unkenntlich gemacht.

Ich hatte kürzlich geschrieben, wie man die DSGVO als Blogger umsetzen kann. Der Text ist ziemlich abstrakt geworden, weil ich einen generellen Leitfaden beibehalten wollte. Nun also mal konkret für meine eigene Webseite.

Analyse

Ich schrieb: Man nehme sich seine Webseite her, und schau im Entwickler-Modus des Browsers erst einmal nach, welche Datenquellen die Webseite so alles einbindet.

Bei Firefox drücke ich F12 für den Entwickermodus und wähle den Reiter Netzwerk aus. Dann lade ich die Seite erneut mit F5.

2018-05-22-102920_715x381_scrot

Es fällt auf, das bei allen Zugriffen das Schlosssymbol aktiv ist. Das bedeutet die Zugriffe erfolgen über HTTPS. Wenn möglich sollte man HTTPS benutzen, besonders aber, wenn man Formulare benutzt. Den Punkt habe ich also schon mal erfüllt, es extra aufzuschreiben ist aber nicht nötig.

Als nächstes sticht ein Zugriff auf einen externen Server ins Auge: Ein Stylesheet wird fonts.googleapis.com nachgeladen. Das werde ich dokumentieren müssen.

Weiter mit der Faktensammlung: Wie schaut's mit Cookies aus? Unter Einstellungen - Privacy findet sich der Punkt Cookies.

2018-05-22-110102_973x407_scrot

Ohja. Das ist eine ganze Menge. Allerdings bin ich aktuell auch als Bearbeiter im Backend angemeldet und das ist keine öffentliche Funktion. Löscht man alle diese Cookies und versucht es nochmal (z.B: von einem anderen Rechner aus), so bleibt die Liste leer. Wie schön.

Die grundlegende Analyse ist damit schon abgeschlossen. Bleiben nun die gewollten Eigenschaften der Webseite, also die Dinge, die ich bewußt entwickelt, eingeschaltet und aktiviert habe. Die findet man natürlich nicht automatisch, sondern die weiß man als Autor. Im Zweifel hilft ein Blick über die verschiedenen Bereiche der eigenen Webseite, um das Gedächtnis aufzufrischen.

Was ist denn nun besonders an der Seite? Achja, Kommentare. Und da kann man sich tatsächlich einen Cookie setzen lassen, der die Angaben des Formulars automatisch vorab ausfüllt. Den wird man erwähnen müssen. Dabei fiel mir auf, daß das Formular den Cookiebutton automatisch aktiviert hat. Das habe ich gleich mal umgestellt.

Des weiteren habe ich interaktive Inhalte auf der Seite. Auf die will ich nicht verzichten, also muß ich sie beschreiben.

Und damit ist die Analyse schon beendet.

Eigner Server

Jetzt geht's ans Eingemachte: Was tut eigentlich mein Webserver so?

Ich weiß, daß er Logfiles führt. Die lese ich zwar nur bei Bedarf (und den hatte ich schon) und mache keine Statistik damit.

Und dann gibt's noch Logfiles für verschiedene Fehlerzustände. Die sind verdammt umfangreich, denn ich will wissen, was genau den Fehler ausgelöst hat.

Bleibt noch die Frage, wie lange die Logfiles liegen bleiben: Aha, eine Woche. Das scheint mir angemessen, denn ich brauche diese Zeit vor allem nach einem langen Wochenende.

Schreiben wir's auf:

Beim Zugriff auf diese Webseiten übermittelt der Browser des Besuchers
automatisch Daten über die gewünschte Ressouce, die IP-Adresse, an die
die Daten übermittelt werden sollen, gegebenenfalls auch spezifische Daten
aus vorherigen Anfragen (Cookies, Referer, Formulare, etc.).

Ein Teil dieser Daten wird automatisch geloggt, um den technischen Betrieb
sicherstellen zu können. Diese Daten werden grundsätzlich nur zur manuellen
Post-Mortem-Analyse herangezogen anderenfalls automatisch nach sieben
Tagen gelöscht.

Fertig.

Cookies

Meist ein heißer Punkt. Aber auch hier habe ich Glück, denn normalerweise setze ich keine Cookies, da ich auf Anmeldungen verzichte.

Nicht-angemeldete Nutzer erhalten grundsätzlich keine Cookies seitens des Webservers.

Und der Cookie bei Formularen?

Auf explizite Aufforderung des Nutzers werden die Angaben für Stammdaten
des Kommentarfeldes per Cookie im Browser gespeichert. Dieses dient dazu,
bei späterer Nutzung des Kommentarfelds diese Daten schon initial einzutragen.
Dieser Cookie wird vom Browser spätestens nach einem Jahr gelöscht,
eine manuelle Löschung ist jederzeit vom Nutzer selbst in seinem Browser möglich.
Eine Speicherung des Cookies auf Serverseite erfolgt nicht.

Der Teil mit der Anmeldung zwecks Bearbeitung betrifft nur mich allein. Aber der Vollständigkeit halber schreibe ich es auf. Es schadet ja nicht.

Mit dem Beginn einer Anmeldung oder Registrierung wird ein Session-Cookie
gesetzt, der dazu dient, den Nutzer bis zur Abmeldung wieder zu erkennen.
Dieser Cookie wird automatisch gelöscht, wenn der Browser geschlossen wird.
Eine Speicherung des Cookies auf Serverseite erfolgt nicht.

Für angemeldete Nutzer können weitere Cookies gesetzt werden,
um verschiedene Workflows technisch umzusetzen. Eine Speicherung dieser
Cookies auf Serverseite erfolgt nicht.

Nur für administrative Aufgaben ist eine Anmeldung notwendig,
die normale Nutzung erfolgt generell ohne Anmeldung. 

Und schon wieder fertig.

Externe Server

Warum mache ich das eigentlich? Weil ich es allein kann. Ich bin schlicht nicht in der Lage, abertausende von Besonderheiten von Browsern in verschiedenen Konfigurationen korrekt mit einem gewünschten Style zu beliefern. Ich kann das auch nicht mal eben kopieren, weil die Auslieferung ja browserabhängig ist. Und selbst wenn ich kopieren könnte, darf ich das überhaupt? Ganz zu schweigen davon, daß ich es nicht aktuell halten könnte. Deswegen binde ich diese Inhalte ja extern ein, von jemanden der es kann.

Grundsätzlich werden alle Inhalte direkt vom Server ausgeliefert.

Eine Einbettung externer Inhalte erfolgt automatisch dann, wenn die Inhalte
technisch nicht lokal bereit gestellt werden können. Dies betrifft generell die
browserabhängige Bereitstellung von Javascript/CSS/Font-Daten für eine
einheitliche Darstellung der Webinhalte. Typischerweise werden diese Daten
vom Browser gecached und nur einmal direkt geholt. Eine Korrelation zwischen
den einzelnen Webseiten-Besuchen und dem Nachladen dieser Ressourcen
ist also nicht zwingend gegeben.

Soweit so klar. Was ist mit Videos? Ich nehme gern mal ein Video auf und lasse es von YouTube streamen. Warum? Weil ich es lokal nicht kann. Der Aufwand wäre unverhältnismäßig.

Fallweise können auch Videos einbettet sein, um auf die nur extern
vorhandenen Streamingressoucen zugreifen zu können. 

Warum ist das alles überhaupt erwähnenswert? Weil es den Nutzer dazu bringt, evtl. Daten an Dritte weiter zu reichen.

In all diesen Fällen sendet der Browser des Besuchers selbst
entsprechende Daten an den jeweiligen externen Server.

Fertig.

Interaktive Inhalte

Jetzt ist meine Spielwiese dran. All die schönen Tools.

Es wäre sinnfrei, jedes Tool im Detail zu erklären. Dazu kommt, daß die meisten Tools komplett im Browser des Nutzers ablaufen. Schließlich will ich die Last ja nicht auf meinem Server haben.

Auf der Webseite können interaktive Inhalte angeboten werden.
Diese werden – soweit technisch möglich – als Javascript im Browser des Nutzers ausgeführt.

Unglücklicherweise kann Javascript nicht beliebige Dinge im Browser machen und braucht externe Informationen, die es nur vom ausliefernden Server bekommen kann (Same-Origin-Policy). Diese Zugriffe sind zu dokumentieren. Sie unterscheiden sich aber nicht wesentlich von normalen Zugriffen.

Werden bestimmte Inhalte dynamisch auf der Serverseite ermittelt,
so wird grundsätzlich kein weiteres Log über diese Aktionen geführt.
Beim Auftreten von Verarbeitungsfehlern können zur Fehlersuche
beliebig detaillierte Logs geführt werden. Diese werden automatisch
nach sieben Tagen gelöscht.

Und dann habe ich noch Scantools, die selbst aktiv nach außen greifen.

Einzelne aktive Inhalts können auch selbst Zugriffe auf andere
externe Ressourcen durchführen, z.B. einen Sicherheitsscan über
vom Nutzer definierte Netzbereiche.

Fertig.

Kommentare

Was gibt es persönlicheres an Daten als nutzergenerierte Inhalte? Die will ich haben, denn die machen die Würze eines Blogs aus.

Es ist grundsätzlich möglich, bereit gestellte Inhalte zu kommentieren.
Diese Kommentare sind öffentlich einsehbar und werden
von Suchmaschinen indiziert.

Wenn man einen Kommentar schreibt, will man diskutieren und agiert als handelnde Person. Welche Persönlichkeit man darstellen will, ist dabei egal. Darüber hinaus habe ich aber auch mit Mißbrauch und Rückfragen zu tun. Da möchte ich neben dem öffentlichen Kommentar auch direkt kommunizieren können. Und anhand der IP, der einzigen Information die man nicht beliebig wählen kann, möchte ich auf schweren Mißbrauch reagieren können.

Bei der Erstellung eines Kommentars wird der Nutzer gebeten,
seinen Namen und seine E-Mail-Adresse anzugeben.
Die Angabe eines Weblinks ist optional.

Der angegebene Name und die optionale URL werden zusammen
mit dem Kommentar angezeigt. Dies dient der Verbesserung
der Kommunikation, da dies die Zuordnung der Beiträge in einer
Diskussion ermöglicht. Der Name und die URL werden nicht validiert.

Die E-Mail-Adresse wird nicht angezeigt. Sie dient ausschließlich
der Kontaktaufnahme mit dem Kommentator zu administrativen
Zwecken. Sie wird bei der Eingabe nicht validiert.

Die IP Adresse des Kommentators wird automatisch erfaßt und wie
die anderen Angaben zusammen mit dem Kommentar gespeichert.
Dies dient dazu, einen Kommentar zweifelsfrei einer Quelle zuzuordnen.
Diese IP wird herausgegeben, wenn Strafverfolgungsbehörden anfragen.
Darüber hinaus wird die IP herangezogen, um automatisch
Kommentarspam zu blockieren.

Da hier nun erstmals und im engeren Sinne personenbezogene Daten verarbeitet werden, sollte man auch über Korrektur- und Löschmöglichkeiten informieren.

Es besteht kein Anspruch auf Veröffentlichung von Kommentaren.
Kommentare werden administrativ gelöscht, wenn sie störend oder
themenfremd sind. Eine manuelle Löschung von Kommentaren ist möglich,
wenn die Löschanfrage mit der passenden E-Mail-Adresse abgesendet wurde
und die Löschung nicht einen thematischen Zusammenhang zerstört.

Klingt schräg? Mag sein, aber ich lasse mir nicht vorschreiben, was ich bei mir zu veröffentlichen habe. Des weiteren habe ich auch einen dicken Hals bei Personen, die Geschichtsklitterung betreiben wollen. Da müssen dann schon ernsthaft triftige Gründe her, um die Abwägung zugunsten einer Änderung oder Löschung ausschlagen zu lassen.

Beschwerde

Da man sich schlecht bei mir selbst über mich beschweren kann, stellt sich die Frage, wer mir denn auf die Finger schauen darf.

Für einen eigenen Datenschutzbeauftragten bin ich … Hallo? Vergeßt es.

Trotzdem muß ich herausfinden, wer für mich zuständig ist. Denn das kann man im Fall einer Beschwerde kaum dem Nutzer überlassen. Er wird sonst von Pontius zu Pilatus geschickt und kommt nie an der richtigen Stelle an.

In meinem Fall ist das einfach: Der Landesdatenschutzbeauftragte.

Bei Beschwerden wenden Sie sich bitte an den Thüringer Landesbeauftragten
für den Datenschutz und die Informationsfreiheit (TLfDI).

Den werde ich dann noch bei meiner zuständigen Aufsichtsbehörde (TLfDI) formgerecht melden.

Noch Fragen?

Das deutsche Datenschutzrecht gilt ja schon lange, zumindest ich habe mich daran gewöhnt. Mit der europäischen Vereinheitlichung zur DSGVO ist vor allem in den letzten Monaten viel Panik entstanden. Wir geht man praktisch als Blogger damit um?

Was soll das?

Die DSGVO ist kein Teufelszeug, sondern folgt einigen klaren Prinzipen:

  • Personenbezogene Daten sollen möglichst gar nicht erhoben werden. Wo nichts anfällt, kann auch nichts missbraucht werden.
  • Wenn man schon personenbezogene Daten verarbeitet, dann sollte der Betroffene wissen, welche Daten wozu erhoben werden und was damit bis zur Löschung passiert. Dadurch kann er informiert entscheiden, ob er einen Dienst in Anspruch nimmt oder nicht.
  • Ist diese Verarbeitung von Daten nicht zwingend für das eigentliche Angebot notwendig, muss diese Verarbeitung optional gestaltet werden.
  • Wenn man schon anderen die Verarbeitung von persönlichen Daten (implizit oder explizit) gestattet, dann muss man nachträglich über seine Daten bestimmen können. Das kann der Wunsch nach Änderung, Löschung oder Übergabe (Export) sein. Ob jedem Wunsch auch immer entsprochen werden muss, ist aber nicht zwingend.
  • Wenn man sich ungerecht behandelt fühlt, muss man wissen, an wen man sich wenden kann.

Im Endeffekt handelt es sich also um ein Verbraucherschutzrecht. Dies impliziert eine gesetzliche Trennung zwischen Anbieter und Konsument. Im Internet ist diese Trennung aber nicht ganz so einfach.

Dreh- und Angelpunkt der gesamten DSGVO für den Anbieter ist die Dokumentationspflicht. Er muss erklären, warum er welche Daten erhebt.

Dabei hat er abzuwägen zwischen den Interessen des Konsumenten, seinen eigenen Interessen und evtl. den Interessen Dritter. Kann er erklären, warum diese Datenerhebung notwendig ist, benötigt er für diese Datenerhebung keine Einwilligung.

Eine Einwilligung ist nur dann notwendig, wenn die auch verweigert werden kann. Ist also die Diensterbringung in vergleichbarer Weise auch möglich, ohne diese Daten zu haben, dann liegt eine einwilligungspflichtige Datenerhebung vor. Natürlich muss diese Einwilligung dokumentiert werden und ist damit selbst dokumentationspflichtig.

Wie der Konsument den Wunsch nach Änderung und Löschung artikulieren kann, muss man dokumentieren. Es ist ebenfalls zu dokumentieren, unter welchen Bedingungen der Wunsch ausgeführt bzw. verweigert werden kann. Insbesondere bei komplexeren Systemen ist es nachträglich oft gar nicht möglich einen Teil zu entfernen. Eine Diskussion zwischen verschiedenen Nutzern kann ihren Sinn verlieren, wenn ein Teilnehmer nachträglich seine Beträge löschen oder sinnentstellend ändern lassen will. In diesem Fall überwiegt das Interesse an der Konsistenz über dem Interesse des Einzelnen. Das Recht auf Vergessen hat also Schranken in der archivarischen Dokumentation, auch wenn der Zugriff erschwert werden kann (Sperre in der Suche).

Für Widersprüche benötigt der Konsument einen Ansprechpartner, i.d.R. den zuständigen Datenschutzbeauftragten. Logischerweise darf dieser Ansprechpartner nicht mit der Person identisch sein, über die Beschwerde geführt werden soll. Es ist also grundsätzlich unzulässig gleichzeitig Verantwortlicher und Datenschutzbeauftragter des gleichen Angebots zu sein. Ein Datenschutzbeauftragter ist für kleine Angebote unnötig, in dem Fall übernehmen übergeordneten Stellen, also die Landes- oder Bundesdatenschutzbeauftragten.

Und wie mache ich das?

Man nehme sich seine Webseite her, und schau im Entwickler-Modus des Browsers erst einmal nach, welche Datenquellen die Webseite so alles einbindet. Dabei findet sich typischerweise:

  • Ressourcen (Javascript, CSS, Bilder, Fonts, ...) des eigenen Webservers
  • Cookies
  • Ressourcen (Javascript, CSS, Bilder, Fonts, ...) fremder Webseiten
  • Aktive Einbindungen anderer Dienste, wie Zählpixel, Webanalyse, Soziale Netze (Like-Count), (Facebook/Disqus)-Kommentare, Videos, etc.
  • interne Kontaktformulare
  • interne Kommentare, Bewertungen, Querverlinkungen für Artikel

Für jeden dieser Punkte muss man nun prüfen:

  • Wird der Zugriff in dieser Form gebraucht?
  • Wenn ja, dann dokumentiere ich die Zugriffsart und begründe deren Zweck. Damit ist der DSGVO hinsichtlich Abwägung und Dokumentation Genüge getan und die Datenerhebung ist ohne Einwilligung zulässig.
  • Wenn nein, dann kann ich den Zugriff entweder entfernen oder ich verlange eine Einwilligung vom Webseitenbesucher.
  • Wird die Einwilligung erteilt, dann kann ich diesen Zugriff benutzen.
  • Wird die Einwilligung nicht erteilt (oder später zurück gezogen), dann muss ich dafür sorgen dass diese Funktion auch nicht aktiviert ist.

Mir ist wichtig an dieser Stelle fest zu halten, dass die DSGVO nicht pauschal irgendetwas verbietet, sondern im Gegenteil all das erlaubt, was begründbar ist. Die DSGVO führt also dazu, dass der Webseiten-Betreiber sich über die Implikationen seines Angebot für den Konsumenten Gedanken macht!

Bei all diesen Dokumentationen sind die drei Punkte aufzuschreiben:

  • Um welche Daten handelt es sich? Wie und wo entstehen sie?
  • Warum werden diese Daten erfasst? Was ist Sinn der Aktion?
  • Wie lange werden die Daten benötigt? Wann werden sie (automatisch) gelöscht? Wie kann man sie nachträglich ändern?

Hält man sich an diese Grundsätze hat man schon fast alles richtig gemacht.

Bei Übergabe von Daten an Dritte oder die Verarbeitung von Daten durch Dritte (Webhoster, Forumsanbieter, Webanalyst, ...) ist es empfehlenswert, eine vertragliche Fixierung mittels einer Auftragsdatenverarbeitung vorzunehmen. Das wird nicht immer individuell möglich sein, jedoch gestattet die DSGVO (im Gegensatz zur bisherigen deutschen Recht) auch den Vertragsvorschlag des Anbieters zu akzeptieren. Nachfragen lohnt sich!

Wem das zu theoretisch war, der kann sich das auch ganz konkret anschauen.

Aber die Juristen!

Richtig, das ist ihr Job. Das Feld des Datenschutzes ist aktuell stark im Umbruch. Juristen neigen leider dazu, keine klare Aussage zu formulieren, stattdessen zeigen sie gern Schwachstellen in der bisherigen Lagebeurteilung auf. Das Ergebnis ist unseriöse Panikmache und massive Verunsicherung.

Dazu trägt bei, dass die zuständigen Landes- und Bundesdatenschutzbeauftragten selbst keine Erfahrungen mit dem neuen Recht haben, geschweige denn den konkreten Fall eines Webauftritts beurteilen können. Deswegen geben auch sie nur allgemeine, meist scharf formulierte Aussagen von sich, wie die folgende: Personenbezogene Daten sind gar nicht erfassen, wenn doch umgehend zu löschen, also spätestens nach 10 Jahren, wenn das Finanzamt nicht mehr auf der Dokumentation besteht.

Kurz und gut: Wenn man einen Rechtsanwalt beauftragt, dann haftet der mit seiner Versicherung für eine Fehlberatung. Sein Interesse besteht also in der Vermeidung eines Versicherungsfalls, nicht in der praktischen Umsetzung seiner Empfehlungen vor Ort. Hat man dagegen den Rechtsanwalt nicht einmal selbst beauftragt, dann …

Natürlich soll man die verschiedenen Aussagen der Juristen nicht komplett verwerfen, jedoch schadet es nicht, sie mit einer gehörigen Portion Skepsis zu betrachten. Ob die betreffenden Vorschläge überhaupt auf den eigenen Sachverhalt anwendbar sind, ist meist gar nicht so klar.

Fazit

Ich bin durch mein eigenes Blog, meine eigenen Projekte auf diesem Webserver durch gegangen und habe meine eigene Datenschutzformulierung geschrieben. Dabei sind mir einige Einsprengsel sozialer Netze aufgefallen, die ich bisher nur ausgeblendet, aber nie richtig abgeschaltet hatte. Jetzt sind sie komplett weg.

Dann habe ich die restlichen Dinge angeschaut und beschlossen, dass ich die weiter haben will. Kommentare unter Artikeln sind mir wichtig, also erkläre ich wie sie funktionieren und was ich als erhaltenswert ansehe. Eine Änderung zur vorherigen Lage stellte das nicht da, ich hab's halt nur mal aufgeschrieben.

Bei Cookies bin ich in der glücklichen Lage, auf sie weitestgehend verzichten zu können. Es gibt aber z.T. lange Cookies, die dokumentiert werden mussten. Dabei habe ich gleich noch den Default-Wert zum Setzen des Cookies ausgeschaltet. Man muss ihn aktiv auswählen. Auch keine schlechte Idee.

Richtig problematisch schienen mir anfangs die Einbindungen externer Inhalte wie Youtube-Videos und CSS/Fonts. Also habe ich versucht, diese Dinge auf meinem Server allein zu erledigen und bin krachend gescheitert. Da mich der Teil technisch weit überfordert, habe ich einen validen Grund die externen Inhalte einzubinden, wie sie halt gebraucht werden. Die DSGVO hat da entsprechende Abwägungsklauseln. Dokumentiert und fertig.

Was man aber nie machen sollte ist: Einfach alles hinschmeißen. Das Internet ist groß und interessant geworden, weil wir nie aufgegeben haben. Lassen wir uns nicht von einer unbegründeten Angst ins Bockshorn jagen.

Beim Durchsehen der Logfiles stieß ich darauf, dass wiki.mozilla.org nicht erreichbar ist. Grund dafür ist ein externer Dienstleister und ein Fehler, über den sich die Experten uneinig sind. Natürlich hängt es mit DNSSEC zusammen.

$ host wiki.mozilla.org 100.100.100.100
Host wiki.mozilla.org not found: 2(SERVFAIL)

$ host wiki.mozilla.org 10.10.10.10
Host wiki.mozilla.org not found: 2(SERVFAIL)

$ host wiki.mozilla.org 8.8.8.8
wiki.mozilla.org is an alias for www.wiki.prod.core.us-west-2.appsvcs-generic.nubis.allizom.org.
www.wiki.prod.core.us-west-2.appsvcs-generic.nubis.allizom.org is an alias for wiki-prod-1394614349.us-west-2.elb.amazonaws.com.
wiki-prod-1394614349.us-west-2.elb.amazonaws.com has address 52.89.171.193
wiki-prod-1394614349.us-west-2.elb.amazonaws.com has address 34.213.203.225
wiki-prod-1394614349.us-west-2.elb.amazonaws.com has address 54.68.243.126

$ host wiki.mozilla.org 1.1.1.1
wiki.mozilla.org is an alias for www.wiki.prod.core.us-west-2.appsvcs-generic.nubis.allizom.org.
www.wiki.prod.core.us-west-2.appsvcs-generic.nubis.allizom.org is an alias for wiki-prod-1394614349.us-west-2.elb.amazonaws.com.
wiki-prod-1394614349.us-west-2.elb.amazonaws.com has address 34.213.203.225
wiki-prod-1394614349.us-west-2.elb.amazonaws.com has address 52.89.171.193
wiki-prod-1394614349.us-west-2.elb.amazonaws.com has address 54.68.243.126

$ host wiki.mozilla.org 9.9.9.9
Host wiki.mozilla.org not found: 2(SERVFAIL) 

Das ist ein Chaos, oder etwa nicht?

Was sagt denn DNSViz?

wiki.mozilla.org-2018-04-20-18_49_55-UTC

Die Erklärungen zu den Fehlerdreiecken umfassen:

  • Die Liste der Nameserver für allizom.org unterscheidet sich bei der Mutterzone "org" von der realen Zone. Dieser Glue-Mismatch ist aber nicht tragisch.
  • Bestimmte Antworten für SOA etc. werden bei der unsignierten Zone nicht beantwortet. Das wird als kritisch bewertet, ist es aber in der Regel nicht, da diese Anfragen für die Namensauflösung nicht notwendig sind.

Woran scheitert also ein Teil der Nameserver?

unbound info: validation failure <wiki.mozilla.org. A IN>:
 no NSEC3 closest encloser from 184.26.160.65 for DS nubis.allizom.org.
 while building chain of trust 

Was ist denn nubis?

wiki.mozilla.org.  CNAME  www.wiki.prod.core.us-west-2.appsvcs-generic.nubis.allizom.org.
;; Received 107 bytes from 2600:1401:2::f0#53(ns1-240.akam.net) in 16 ms 

Ahja, eine Zwischenzone auf dem Weg zum eigentlichen Ziel.

www.wiki.prod.core.us-west-2.appsvcs-generic.nubis.allizom.org.  CNAME  wiki-prod-1394614349.us-west-2.elb.amazonaws.com.
;; Received 275 bytes from 2600:9000:5302:cf00::1#53(ns-719.awsdns-25.net) in 17 ms 

Der entscheidende Teil ist, dass allizom.org signiert ist.

allizom.org.  SOA infoblox1.private.mdc2.mozilla.com. sysadmins.mozilla.org. 2018032753 180 180 1209600 3600
allizom.org.  RRSIG   SOA 7 2 3600 20180423125954 20180420115954 42215 allizom.org. E...
;; Received 563 bytes from 23.211.133.65#53(use4.akam.net) in 22 ms 

Allerdings scheint die Implementierung der beteiligten Nameserver (oder gar der Quelle, also der Infoblox) defekt zu sein, denn die notwendigen Nichtexistenzbeweise über die Abwesenheit einer sicheren Delegierung (also eine unsichere Delegierung) fehlen.

Genau genommen handelt es sich um ein empty non-terminal, also einen DNS-Namen, den der keine eigenen Datensätze enthält. Stattdessen existiert er ausschließlich virtuell. Denn die reale Delegierung lautet:

appsvcs-generic.nubis.allizom.org. NS   ns-795.awsdns-35.net.
appsvcs-generic.nubis.allizom.org. NS   ns-1743.awsdns-25.co.uk.
appsvcs-generic.nubis.allizom.org. NS   ns-426.awsdns-53.com.
appsvcs-generic.nubis.allizom.org. NS   ns-1109.awsdns-10.org.
;; Received 481 bytes from 2600:1401:2::f0#53(ns1-240.akam.net) in 16 ms

Der Name "nubis.allizom.org" entsteht ausschließlich durch die Verwendung von Punkten im längeren Namen.

DNSSEC ist das aber völlig egal: Der Name ist ein gültiger Name im DNS, also muss darüber eine Aussage her. Und wenn es ein Nichtexistenzbeweis ist. Deswegen verlangt DNSSEC, dass auch für derartige virtuellen "empty non-terminals" entsprechende DNSSEC Records erzeugt werden.

Und genau die fehlen hier.

nubis.allizom.org-2018-04-20-19_30_18-UTC-1

Damit kann ein validierender Resolver nicht beweisen, dass die unsichere Delegation der Zone "appsvcs-generic.nubis.allizom.org" korrekt ist. Es könnte ja ein Man in the Middle versuchen, die mögliche Existenz einer sicheren Delegierung für "nubis.allizom.org" auszufiltern!

An dieser Stelle unterscheiden sich die Implementierungen der DNS-Resolver.

  • Es gibt welche, die jedes noch so kleine Detail prüfen. Wie unbound, den ich für die Server 10.10.10.10 und 100.100.100.100 benutze. Oder knot, der bei 1.1.1.1 läuft.
  • Und es gibt welche, die nur dem eigentlichen Pfad folgen und sich für die Infrastruktur auf andere interne Mechanismen verlassen. Wie Google und Cloudflare.

Interessant ist, dass bei Cloudflare und Google eigene DNS-Implementierungen laufen, die nicht auf die klassischen Opensource-Produkte zurück greifen. Auch Infoblox fährt sein eigenen Süppchen. Und Route66 von Amazon ist auch eine Eigenentwicklung.

Ich bin sehr an einigen Details interessiert, warum die Eigenentwicklungen genau versagen: Die einen beim Erzeugen oder Verteilen, die anderen beim Validieren.

Merke, Mozilla: Größe ist nicht alles.

Während der ICANN Diskussionen@AtLarge kam die Frage auf, wie man als einfacher Nutzer testen kann, ob man von dem DNSSEC Key Rollover der Root Zone betroffen ist. Das ist erstaunlich schwierig oder vollkommen trivial. Je nachdem was man will.

Das Rollover Problem

DNSSEC funktioniert im Grundsatz so, dass die Elternzone einen Verweis auf den aktiven Schlüssel der Kindzone setzt. Auf diese Weise kann man in der Kindzone der Schlüssel leicht gewechselt werden, indem man parallel den Verweis in der Elternzone aktualisiert.

Für die Root-Zone ist es nicht so einfach, weil es schlicht keine Elterzone für die Root gibt. Das Schlüsselmaterial der Root kommt stattdessen aus den (Festplatten-)Speichern der Resolver-Server. Aber wie kommt es da rein?

Zum einen kann man das Schlüsselmaterial manuell eintragen. Das hat man anfangs auch gemacht. Die Daten fanden sich in Zeitungen, auf Webseiten etc. pp. Inzwischen wird das Schlüsselmaterial von den Software- / Betriebssystemherstellern vorinstalliert mit ausgeliefert. Eine noch andere Möglichkeit besteht darin, während der Erstinstallation den aktuellen Schlüssel ungeprüft abzurufen und zu speichern.

Das Problem besteht nun darin, den Schlüssel zu wechseln. Die Abermillionen von Installationen müssen also neue Schlüsseldaten bekommen. Normalerweise eine unmögliche Aufgabe. Seit einigen Jahren gibt es aber ein automatisiertes Verfahren: RFC5011. Im Kern besagt der RFC, der Resolver soll alle Schlüssel, die er mit Hilfe der bekannten Schlüssel validieren kann, abzuspeichern hat. Damit kennt und vertraut er den neuen Schlüsseln, sobald er sie sieht.

Ob das in der Praxis funktioniert, wurde nicht wirklich getestet. Dieser Root KSK Rollover ist der erste Versuch, das zu tun. Und natürlich muss man damit rechnen, dass es schief geht. Es kann aus ganz unterschiedlichen Gründen schief gehen, z.B. könnte der Festplattenbereich durch den Resolver nicht beschreibbar sein.

Wenn es schief geht, kann der Resolver keinerlei DNS Anfragen mehr beantworten. Gar keine. Und nun stelle man sich vor, dieser betroffene Resolver steht bei einem großen Internetprovider: Es gibt einen Blackout für alle Kunden dieses Providers.

Konsequenzen

Wie viele solche Resolver es gibt, ist nicht bekannt. ICANN hat also beschlossen, den für letzten Oktober geplanten Rollover auszusetzen.

Neuere Methoden, ob ein Resolver den neuen Schlüssel schon gelernt hat, wurde in den letzten Monaten entwickelt und ausgerollt. Allerdings ist die Verbreitung dieser neuen Methoden auf die gut gepflegten Systeme beschränkt, die sowieso kein Problem mit dem Rollover haben werden. Eine Aufklärung des problematischen Dunkelfelds ist nicht zu erwarten.

Nun steht die Frage im Raum, ob und wann ein neuer Anlauf genommen wird. Neue Daten sind jedenfalls nicht zu erwarten.

Andererseits besteht das Problem, dass immer mehr Geräte auf den Markt kommen, die gar nicht in der Lage sind einen Root Schlüssel zu wechseln. Hier stehen die vielen unsupporteten IoT-Geräte im Vordergrund. Je länger man also mit dem Rollover wartet, desto mehr Anbieter können einen Rollover ignorieren. Nur ein regelmäßiger Wechsel zwingt die Industrie und die Admins zu eine korrekten Vorgehensweise.

Ängste

Das Thema ist emotionsgeladen:

  • Will ich riskieren, dass mein Internet ausfällt?
  • Wer wird mich (als Admin) verantwortlich machen, wenn es zu Ausfällen kommt?
  • Wer wird mich (als ICANN) verantwortlich machen, wenn es zu Ausfällen kommt?
  • Wie viele Leute werden einfach DNSSEC ausschalten, anstatt das Problem richtig zu beheben?

Dazu muss vorrangig die Frage beantwortet werden, ob man überhaupt betroffen ist.

Dazu gibt es eigentlich nur zwei Fälle:

  • Mein ISP (Resolver) kann DNSSEC und validiert. Dann kann es passieren, dass der KSK Rollover schief geht.
  • Mein ISP (Resolver) validiert DNSSEC nicht. Dann betrifft der Rollover mich (und ihn) gar nicht.

Um diese beiden Fälle einfach zu überprüfen, habe ich auf Anregung von Alan Greenberg eine Webseite erstellt, die den aktuellen Stand beim Nutzer ermittelt und den betreffenden Fall anzeigt.

Wie man den Stand von DNSSEC ermittelt

Natürlich kann man nicht aktiv DNS im Browser sprechen, um diese Fälle zu unterscheiden. Eine aktive Programmierung jeder Art fällt also schon mal flach.

Was man aber machen kann, ist Teile der Webseite so abzulegen, dass ein DNSSEC validierender Resolver diese nicht abrufen kann. Ich habe mich dazu entschieden eine Webseite mit unterschiedlichem CSS zu machen.

<link rel="stylesheet" href="dnssec.css">
<link rel="stylesheet" href="http://css.fail.donnerhacke.de/dnssec-fail.css">

Der zweite Teil des CSS überschreibt die vorherige Einstellung:

$ cat dnssec.css
.failed { display: none; }
.dnssec { display: block; }
$ cat dnssec-fail.css
.failed { display: block; }
.dnssec { display: none; }

Er kann aber nur abgerufen werden, wenn der Resolver keine DNSSEC Validerung macht.

Um das hin zu bekommen, muss absichtlich ein stabiler Fehler im DNSSEC-Setup erzeugt werden. Der Fehler muss so stabil sein, dass er den normalen Betrieb und automatische Korrekturmaßnahmen überlebt. Ich habe mich zu einer fehlerhaften Delegation entschieden:

$ORIGIN donnerhacke.de.
fail            NS      avalon.iks-jena.de.
                NS      broceliande.iks-jena.de.
                DS      12345 8 2 1234...

Die delegierte Zone ist dann nicht signiert, obwohl die Elternzone behauptet, sie müsse es sein.

Das schaut dann so aus:

fail.donnerhacke.de

Ein validierender Resolver kann das nicht auflösen und antwortet:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 10476
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;css.fail.donnerhacke.de. IN AAAA

;; Query time: 49 msec
;; SERVER: 100.100.100.100#53

Ein nicht validierender Resolver kommt dagegen zu folgendem Ergebnis:

donnerhacke.de.         NS      avalon.iks-jena.de.
donnerhacke.de.         NS      broceliande.iks-jena.de.
;; Received 185 bytes from 2001:678:2::53#53(a.nic.de) in 25 ms

css.fail.donnerhacke.de. CNAME  pro.donnerhacke.de.
pro.donnerhacke.de.     AAAA    2001:4bd8:1:1:209:6bff:fe49:79ea
donnerhacke.de.         NS      broceliande.iks-jena.de.
donnerhacke.de.         NS      avalon.iks-jena.de.
;; Received 219 bytes from 2001:4bd8:52:1:20a:e4ff:fe80:bec8#53(broceliande.iks-jena.de) in 1 ms

Die abgerufene Webseite wird also, in Abhängigkeit von den DNSSEC-Fähigkeiten des Resolvers, unterschiedlich aussehen.

Und nun gehe hin und teste Deinen Resolver: *click*

Die ASAs von Cisco können ja Portchannels, d.h. mehrere Leitungen zu Einer bündeln. Außerdem können Sie Failover, ein Gerät kann für ein anderes einspringen. Beides zusammen ist allerdings trickreich, da es im ungünstigen Fall zu Verbindungsabbrüchen führt.

Aufbau

Zwei ASAs im Active/Standby-Failover sind an getrennte Switche angeschlossen. Zur Erhöhung der Bandbreite wird ein Interface als LACP-Bündel zum übergeben. Ist die primäre ASA aktiv, funktioniert es prächtig.

asa# sh port-channel summary 
Group  Port-channel  Protocol  Span-cluster  Ports
------+-------------+---------+------------+------------------------------------
1      Po1(U)            LACP          No     Gi0/0(P)   Gi0/1(P)   
asa# failover exec mate show port-channel summary
Group  Port-channel  Protocol  Span-cluster  Ports
------+-------------+---------+------------+------------------------------------
1      Po1(U)            LACP          No     Gi0/0(P)   Gi0/1(P)   

Die Interfaces haben folgende Eigenschaften:

asa# sh interface | in Interface|MAC
Interface GigabitEthernet0/0 "", is up, line protocol is up
        MAC address 00.01.01, MTU 1500
Interface GigabitEthernet0/1 "", is up, line protocol is up
        MAC address 00.01.02, MTU 1500
Interface Port-channel1 "outside", is up, line protocol is up
        MAC address 00.01.01, MTU 1500

und

asa# fail exec mate sh interface | in Interface|MAC
Interface GigabitEthernet0/0 "", is up, line protocol is up
        MAC address 00.02.01, MTU 1500
Interface GigabitEthernet0/1 "", is up, line protocol is up
        MAC address 00.02.02, MTU 1500
Interface Port-channel1 "outside", is up, line protocol is up
        MAC address 00.02.01, MTU 1500

Wie man sieht übernimmt der Port-Channel die MAC Adresse des ersten Interfaces. Soweit so dokumentiert.

asa-portchannel-active

Wie man sieht, tauchen die beiden MAC Adressen der Interfaces am jeweiligen Switch auf. Die ASA antwortet im ARP mit der MAC Adresse des Port-Channels und alles ist gut.

Failover

Bei Umbauten kam es vor, dass die ASAs umschalteten. Das ist beabsichtigt und stellt kein Problem dar.

Die aktive ASA ist einfach das andere Gerät, der Status incl. der IPs und MAC Adressen wechselt zwischen den beiden ASAs und es funktioniert.

asa-portchannel-failover

Man sieht sehr schön, wie die Haupt-MAC des Portchannel wechselt und nun zur aktiven ASA zeigt.

Ein Blick in die ASA selbst bestätigt den Wechsel:

asa# sh interface | in Interface|MAC
Interface GigabitEthernet0/0 "", is up, line protocol is up
        MAC address 00.02.01, MTU 1500
Interface GigabitEthernet0/1 "", is up, line protocol is up
        MAC address 00.02.02, MTU 1500
Interface Port-channel1 "outside", is up, line protocol is up
        MAC address 00.01.01, MTU 1500

und

asa# fail exec mate sh interface | in Interface|MAC
Interface GigabitEthernet0/0 "", is up, line protocol is up
        MAC address 00.02.01, MTU 1500
Interface GigabitEthernet0/1 "", is up, line protocol is up
        MAC address 00.02.02, MTU 1500
Interface Port-channel1 "outside", is up, line protocol is up
        MAC address 00.01.01, MTU 1500

Achtung! Da die Funktion der ASAs gewechselt hat ist jetzt die aktive ASA auf der Hardware des zweiten Geräts. Deswegen haben sich die Hardware-MAC der Interfaces nicht verschoben, wohl aber die Funktion (mate ist jetzt das, was vorher aktiv war).

Probleme

Denkt man genauer über das nach, was da zu sehen ist, bleiben Fragen:

  • Warum wechseln die MAC Adressen der realen Interfaces nicht? Die MACs aller anderen Interfaces wechseln nämlich.
  • Warum erscheinen die MAC Adressen der Interfaces beim Switch? Eigentlich sollte doch nur die MAC des Port-Channels auftauchen.

Tatsächlich gibt es zeitweise Ausfälle, bei denen keine Außenkommunikation mehr möglich ist. Und da sieht es real so aus:

asa-portchannel-failover-fail

Die MAC Adresse des aktiven Port-Channels zeigt wieder auf die alte ASA, die aktuell passiv ist. Und die verwirft natürlich alle Pakete.

Wenn kurze Zeit später die aktive ASA ein Paket aussendet, lernen die Switche wieder um und es funktioniert wieder alles. Bis zum nächsten Vorfall.

Lösung

Ganz offensichtlich sendet eine ASA neben dem Port-Channel auch Daten über die Interfaces selbst aus. Und dabei benutzt sie die nicht wechselnden MAC-Adressen der Interfaces!

Man kann darüber diskutieren, ob es sich um einen Bug handelt. Man kann auch anfangen zu untersuchen, welche Art von Paketen die ASA auf den individuellen Ports eines LACP-Bundles aussendet. Das ist alles spannend, aber nicht zielführend.

Man muss die MAC des Port-Channels von der MAC der Interfaces trennen, und das geht!

asa(conf)# int Po1
asa(config-if)# mac-address 00.01.00 standby 00.02.00

Und das schaut dann so aus:

asa-portchannel-failover-ok1

Cool nicht?!

Die neue MAC taucht separat von den Interface-MACs auf und damit sollte ein Umschalten auch klappen:

asa-portchannel-failover-ok2

Tatsächlich springt nur die virtuelle, manuell gesetzte MAC des Port-Channels um.

Und die Probleme sind weg.

Seit einiger Zeit wird eine Webseite mit offenbar unliebsamen Inhalt, die wir hosten, angegriffen. Nach einem lockeren Anfang kam die inzwischen obligatorische Traffic-Bombe. Und die lies sich erstaunlich leicht entschärfen.

Entwicklung eines DDoS

Dieser Distributed Denial of Service ist eine Protestaktion. Das Ziel ist bekannt, die mögliche Ursache auch, der Initiator des Angriffs allerdings nicht. Also müssen wir mit den Folgen leben.

Zuerst fing es mit einem dauerhaften Abruf der Webseite (F5-Bombe) einiger weniger Quellen an. Da die betroffene Seite statisch ist, war die Last des Webservers zwar hoch, aber nicht bedrohlich.

Als nächstes schwenkte der Angriff auf HTTPS um, was den Server wegen der TLS-Bearbeitung stärker belastete.

Kurz darauf kamen die Anfragen aus aller Welt. Offenbar hatte der Angreifer ein Botnet von übernommen PCs und Webservern zugeschaltet. Nun war es nervig.

Als nächstes kam es zu einer verbesserten Form von Syn-Floods: Der TLS Verbindungsaufbau wurde komplett durchgeführt, aber keine Webseite abgefragt. Das führte zu einem ersten Ausfall der Verfügbarkeit, da nun die Maximalanzahl der Webserver-Prozesse/Threads in der Warteschleife fest saßen.

Die Gegenmaßname war eine Limitierung von TCP-Syns pro Host und Zeiteinheit mit dem recent-Modul von iptables. Zusätzlich wurden die entsprechenden Hosts, die zu viele 408-Einträge im Webserverlog hinterließen, per Script und iptables geblockt (und bei Inaktivität automatisch freigegeben). Selbstverständlich gibt auch der Abruf der angegriffenen Webseite selbst schon Strafpunkte.

Jeden Werktag gegen 16 Uhr kommt eine Verfügbarkeitsabfrage über einen der vielen Ist-Mein-Server-Erreichbar-Dienste. Kurz danach beginnt eine neue Variante des Angriffs. Meist sucht sich der Angreifer eine andere Webseite auf diesem Shared-Hosting-Webserver aus und bearbeitet diese.

Dabei kann der Angreifer auch mal eine Seite erwischen, die PHP und datenbanklastig ist. Das stört sehr, wird aber von dem inzwischen installierten Block-Skript kurzfristig eingefangen.

Und dann knallte es rein: Unmengen von UDP/GRE und anderen verbindungslosen Protokollen schlugen auf die IP ein. Es wurde ernst.

Umgang mit der Traffic-Welle

Glücklicherweise hält die Traffic-Welle immer nur kurze Zeit an. Es genügt aber, im Netz der Uplink-Carrieren Störungen zu verursachen.

Mit dem Einsatz von Paketfiltern (für z.B. UDP) gegen die betroffene IP möglichst weit außen, konnten die Auswirkungen gedämpft werden. Die kurzen Störungen zu Beginn der täglichen Welle blieben aber im Netz der Uplinks.

Zur leichteren Separierung des Traffics bekam die Webseite eine neue IP. Aber welche?

Der Massentraffic kommt i.d.R. von IoT-Geräten: Schlecht gewarteten und vor allem schlecht entwickelten Kleinstgeräten mit Internet-Anschluss. Könnte das ein Ansatzpunkt der Verteidigung sein?

Die meisten IP-Stacks sind inzwischen (1993) classless, d.h. sie müssen zu jeder IP die Netzmaske kennen, damit sie die Pakete routen können. Früher war das anders: Da ergab sich aus der IP die Netzmaske von allein.

Darüber hinaus werden beim Anschluss von IP-Netzen an einer Broadcast-Netztopologie (z.B. Ethernet) bestimmte IP-Adressen reserviert: Die letzte IP im Netz (Hostteil besteht nur aus 1-Bits) ist die Broadcast-Adresse.

Des weiteren gilt die erste Adresse im Netz (Hostteil  besteht nur ais 0-Bits) als Netzadresse. Diese soll nicht verwendet werden, weil einige IP-Stacks die Adressen intern invertiert ablegten und somit Netz- und Broadcast-Adressen nicht auseinander halten konnten. Um mit diesen Hosts weiter arbeiten zu können, wird bis heute generell nicht an die Netzadresse gesendet.

Es war also nahe liegend, als neue IP Adresse die a.b.c.0 aus einem (ehemaligen) Class-C Netz zu verwenden.

Gesagt, getan. Die Traffic-Spitzen sind weg.

Fazit

Es ist gelungen, Angriffe durch kaputte System an der Quelle zu unterbinden. Eben weil die Systeme auch noch anders kaputt sind.

Inzwischen hat sich der TCP-Angriff auch auf IPv6 ausgebreitet, alles vorher war immer nur IPv4.

Warten wir's ab.

Hinweis für Manager: Es nützt nichts zu fragen, ob der Angriff vorbei ist. Die Frage ist sinnlos.

Die Commerzbank verlangt für beleghafte Überweisungen Geld. Das kann ich akzeptieren. Ich habe schon jahrelang am Automaten die Aufträge selbst erfasst. Onlinenbanking hat jahrelang nicht für mich funktoiniert. Jetzt tut's. Und jetzt soll das auch noch kostenpflichtig werden.

Rückblick

Mit der Dresdner Bank war ich als Kunde immer zufrieden, nicht nur, weil ich meine feste Ansprechpartnerin dort kannte.

Kurz vor der Jahrtausendwende kam Online-Banking (in Form von HBCI) auf und ich wollte das auch mal ausprobieren. Also hab ich mich an die Bank gewendet und einen Smartcard-Leser mit seriellem Anschluss per Post bekommen. Als ich den zwei Monate nicht einmal benutzt hatte, rief jemand schüchtern aus dem Rechenzentrum in Frankfurt an: Herr Donnerhacke, ich kenn' Sie ja aus dem Usenet. Sie haben unser Gerät bekommen und nie benutzt. Haben Sie Sicherheitsbedenken oder gar etwas schlimmes gefunden?

Das hatte ich natürlich nicht. Mein Problem war, dass das Teil an einer NeXTstation nicht lief. Aber da konnte er mir nicht helfen. So blieb ich bei beleghafter Kontoführung und dann die Benutzung der Automaten. Da hin zu gehen ist nicht aufwendig, wenn es in der Nähe der Arbeitsstelle ist.

Später ging die Bank in der Commerzbank auf und ich bin mit gegangen. Man ist ja bequem. Einen feste Ansprechpartner brauchte ich nicht mehr, freute mich aber die paar Mal, die ich dort war, immer an die gleiche und kompetente Person zu gelangen.

Irgendwann mochte ich den doch etwas weiteren Fußweg nicht mehr und beantragte wieder mal Online-Banking. Es stellte sich heraus, dass bis auf einen extra PIN/TAN-Brief nichts weiter geschah, als dass man die gleiche Oberfläche wie am Automaten nun auch zu Hause hatte. Intern ist beides Online-Banking nur halt von verschiedenen Zonen aus. Das ist clever und gestattete mir, Online-Banking von außerhalb Deutschlands zu untersagen.

Etwas später wurde TAN durch iTAN und mTAN abgelöst. ChipTAN, wie es die Sparkasse anbietet, war leider nicht im Angebot. Noch etwas später kam PhotoTAN.

Diskriminierung

Und heute lese ich in der Bank-Mitteilung:

Die Commerzbank empfiehlt ihren Kunden im Onlinebanking die Nutzung der photoTAN.
Sie beruht auf modernsten Sicherheitsstandards, ist kostenlos und es 
gilt die Commerzbank Sicherheitsgarantie. 
Mit der photoTAN ist Banking mit dem Smartphone ohne Zusatzgeräte möglich.
Die mobileTAN als bisherige Alternative zur TAN-Generierung kann von Kunden
weiterhin genutzt werden, ist künftig jedoch nicht mehr kostenlos. 
Wechseln Sie jetzt und testen Sie unsere PhotoTAN-App auf www.commerzbank.de

Ab 1.05.2018 werden wir den Versand einer (angeforderten, tatsächlich genutzten)
mobileTAN per SMS mit 0,09 EUR bepreisen.
Sollten Sie mit dieser Änderung nicht einverstanden sein, sprechen Sie uns gern
bis zum 30.04.2018 an. Bis zu diesem Termin haben Sie die Möglichkeit zu widersprechen,
oder das Konto fristlos und kostenfrei zu kündigen. 
Widersprechen oder kündigen Sie nicht, gilt Ihre Zustimmung zu der Vertragsänderung
als erteilt. Das geänderte Preis- und Leistungsverzeichnis kann in unseren 
Geschäftsräumen eingesehen werden und wird auf Wunsch ausgehändigt oder zugesandt.

Hallo? Ich muss ein Smartphone haben und eine Software von Euch installieren, damit ich Euch Kosten spare?

Wenigstens erkennt Ihr, dass Eure Anwendung nicht auf allen Smartphones laufen wird. Ihr schreibt selbst:

Wenn Sie kein Mobiltelefon besitzen, auf dem Sie die Commerzbank photoTAN-App
installieren können, haben Sie die Möglichkeit, bei Anmeldung zur photoTAN
ein preisgünstiges Lesegerät zu erwerben.

Bevor ich jetzt schaue, ob es für mein Handy überhaupt Eure Software gibt (Nein, das ist kein NeXTphone), lese ich nochmal nach, dass ihr bei mTAN die gleichen Sicherheit garantiert wie bei PhotoTAN.

Das ist deswegen witzig, weil ihr bei PhotoTAN schreibt, dass Eure Software das Hauptsicherheitsrisiko implementiert hat:

Auf Ihrem Smartphone können Sie Überweisungen noch schneller und einfacher durchführen
als am Computer. Nutzen Sie dafür die kostenlose Banking-App der Commerzbank.
In Verbindung mit der photoTAN-App entfällt das Scannen der Grafik. Durch eine
ausgeklügelte Technik sind die Apps direkt miteinander gekoppelt.

Selbst Wikipedia weiß:

Werden allerdings beim mobilen photoTAN-Banking sowohl die Banking- wie auch die photoTAN-Funktion via App auf einem einzigen Smartphone zusammengeführt, sodass die photoTAN-App und die Banking-App direkt miteinander kommunizieren, lassen sich die Überweisungen wieder manipulieren. Solche Apps werden zum Beispiel von der Deutschen Bank, der Commerzbank und der Norisbank bereitgestellt.

Und selbstverständlich gibt es die App nur für Android und iOS. Nicht für Windows Phone, Symbian, etc.

So und nun müssen wir reden. Zumindest müsst Ihr auf meinen Widerspruch, der bei Euch eingehen wird, reagieren. Sonst bleibt alles beim Alten. Klar?