Redhat-Webseite des Session-Replaying bezichtigt

Da haben es Forscher der Princeton Universität mal genauer genommen und eine Menge bekannter Webseiten auf sogenanntes Session-Replaying untersucht. Dummerweise sind davon nicht nur hierzulande eher unbekannte Webseiten zu finden, sondern auch Teamviewer, wordpress.com, wp.com, conrad.de, comodo.com, Skype & Microsoft und Redhat .

Was ist Session-Replaying ?

Session-Replaying bezeichnet Trackingtechniken in Javascript, die alle Tastatureingaben, alle Mausbewegungen usw. aufzeichnen und zur Auswertung an einen Drittanbieter übermittelt. Natürlich ohne vorher zu fragen, ob die das dürfen. Mit den Daten kann man als Webseitenbetreiber auswerten lassen, wo die eigenen Seiten besonders gut oder besonders schlecht sind. Soweit, so „naja“. Jetzt zeichnen die Scripte aber auch Fehleingaben auf, also z.B. alles was in der Zwischenablage ist und per Copy&Paste unabsichtlich kopiert wird, bspw. auch Passwörter.

Was damit für Schindluder getrieben werden kann, kann sich jeder selbst ausmalen, dem das Copy&Paste schon einmal seine Dienste versagt hat. Das geht nämlich leider schneller, als einem Lieb ist.

Für Redhat kommt der Dienst von clicktale.net ins Spiel. Dieser wurde von Princeton mit dem Vermerk : „evidence of session recording“ versehen.

Gegenmaßnahmen

Wenn es nach dem jüngsten FireFox Update auf 57 gegangen wäre: Keine.

Glücklicherweise hat Giorgio Maone sein Plugin NoScript auf die neue Firefox Api angepaßt. Damit kann man die Tracking-Domains sperren, bzw. erst gar nicht aktivieren. Also, alle die an Giorgio gezweifelt haben, sollten vor Ihm auf die Knie fallen und um Entschuldigung bitten. Der Mann und sein Plugin können Euch jeden Tag den Arsch retten! Das Teil ist für den Datenschutz der Goldstandard. Wundert mich eigentlich, daß die Bundesdatenschutzbeauftragte das nicht für jeden Behörden PC vorschreibt. Das wäre ja mal was 🙂

Die Liste

Wer sich die Liste ansehen will, die ist hier erhältlich:

https://webtransparency.cs.princeton.edu/no_boundaries/session_replay_sites.html

Ihr werdet noch mehr prominente Namen finden z.B. addidas.com , dominos.com ( Ex-Joeys ) , symantec.com, mongodb.com, cpanel.net, magento.com, bitdefender.com, acrobat.com, worldoftanks.com und wenig verwundernd kaspersky.ru .

Linux – DNS-DeTracking mit nscd

Das Problem

Wenn man alle seine DNS Anfragen über einen einzigen Anbieter abwickelt, kann der leicht herausbekommen, wofür man sich interessiert, da er ja jede Domain kennt, mit der man „reden“ will.

Wenn man von einem DNS Anbieter, sei es die Deutsche Telekom oder Google, nicht vollumfänglich getrackt werden will, kann man nur seinen eigenen DNS-Cache betreiben, oder laufend den DNS Anbieter wechseln ? Oder gibt es da vielleicht noch eine dritte Möglichkeit ?

Methode 1:

Jeder kann sich einen DNS Cache auf dem eigenen PC installieren. Der Nachteil ist, es ist nicht besonders effizient und bei einigen DSL-Anbietern kann man auch nicht selbst die DNS Auflösung machen. In letzterem Fall solltet Ihr Euch auf jeden Fall einen Tunnel in die freie Welt aufbauen, z.b. per VPN. Einen eigenen Server der dafür ausreicht kann man sich schon für 6,50 € im Monat mieten. Ihr braucht  dann noch sowas : UDP Traffic per SSH tunneln, Die Vorratsdatenspeicherung umgehen oder VDS: Schnell ein VPN aufsetzen . Es geht zwar nicht um die Vermeidung der VDS, aber das Prinzip ist das gleiche. Aber wenn Ihr sowieso schon einen eigenen Server habt, laßt den das DNS Cache übernehmen.

Wieso ist das nicht effektiv ?

Ein DNS Cache macht nur dann Sinn, wenn viele Klienten in einem Netzwerk das Cache benutzen, denn der eigentliche Sinn ist, daß nicht jeder Rechner die Root-DNS kontaktiert, sondern das man möglichst viele Anfragen lokal selbst beantworten kann, weil man bereits einmal danach gefragt hat. Das geht zum einen schneller, zum anderen spart es Traffic ein. Das man seinen Fußabdruck dabei kleiner hält, fällt praktischerweise nebenbei ab. Je mehr einen DNS Cache benutzen, desto mehr gehen auch die eigenen Anfragen in der Masse unter.

Methode 2:

Ein Script, daß laufend die /etc/resolv.conf  neu und die DNS Servernamen in der Reihenfolge zufällig hinein schreibt, ist mit ein bisschen Bash-Foo machbar. Dauer ca. 15 Minuten.

Methode 3:

Schauen wir uns mal die /etc/resolv.conf an, finden wir dort:

; generated by /usr/sbin/dhclient-script
nameserver 9.9.9.9
nameserver 8.8.8.8
nameserver 8.8.4.4

Wenn man nichts weiter auf seinem Rechner installiert hat, wird in genau dieser Reihenfolge ein DNS nach dem Anderen abgefragt, wenn der vorherige DNS nicht rechtzeitig antwortet.

Das Verhalten kann man aber ändern:

options rotate
nameserver 9.9.9.9
nameserver 8.8.8.8
nameserver 8.8.4.4

Jetzt würde ein entsprechend gut programmierter Resolver, das ist der Programmteil, der die DNS Auflösung macht, zufällig aussuchen, welchen der DNS er benutzt. Trägt man hier also viele öffentliche DNS Server in dieser Liste ein, verteilt man alle DNS Anfragen auf diese Server, was jedem einzelnen logischerweise die Möglichkeit nimmt, ein umfangreiches Profil zu erstellen.

Dummerweise juckt diese Anweisung kaum einen Resolver. Das geht sogar soweit, daß der erste in der Liste mal einfach überlesen wird 🙂 Also muß eine Lösung her, die diese Anweisung respektiert: NSCD

dnf install nscd
systemctl start nscd
systemctl enable nscd

Ab jetzt werden DNS Abfragen über den NameserverCacheDämonen abgewickelt, und der fragt zufällig die DNS in der Liste an. Da es sich auch um einen Cache handelt, fragt er im Laufe der Zeit ( TTL eines Eintrags ) nur einmal die Rootserver an ( Kleiner Fußabdruck ) .

Damit wäre das Trackingproblem erledigt, wenn Ihr viele DNS Server zur Verfügung habt.

Einen eigenen DNS Cache auf dem PC zu betreiben, ist nicht weiter wild, man müßte nur den named installieren und starten. Da aber bei DNS Abfragen einiges unterwegs schief gehen kann, ist eine starke DNS Infrastruktur wie bei Google durchaus ein starker Partner.

Welche Methode für Euch die richtige ist, müßt Ihr wissen.

Follow-Up: Tor vs. AfD – NSA-Style

Heute erreichte mich ein Anruf der Kriminalpolizei Braunschweig zu dem AfD Vorfall vom 9. Oktober 2017. Wie bereits im letzten Artikel Tor vs. AfD – NSA Style angedeutet, hat die Staatsanwaltschaft Braunschweig das ungefragte Verbreiten der politischen Parolen als Computersabotage nach §303b StGb eingestuft.

Die politischen Parolen, die auf unschuldige Webseiten einprasseln, haben sich in den letzten Wochen mehrfach geändert, aktuell ist es wieder „AfD-Verbotsverfahren_JETZT!“ . Der Aufwand diese Parolen zu blocken, ist im Verhältnis zum Nutzen, eigentlich zu hoch. Das Apache Webserver Modul mod_security  könnte dies leicht für jede Webseite erledigen, mit dem Nachteil, daß Millionen von Webanfragen unnötigerweise geprüft würden und so die Last auf den Webservern steigt. Da diese Wortsperre leicht umgangen werden könnte, erscheint eine Sperrung der Webstats für die Suchmaschinen Bots deutlich kosteneffektiver, da deutlich weniger Webanfragen geprüft werden müßten. Der Komplottkreislauf aus „öffentlichen Webstats-Googleranking-AfD Abwertung“ wäre damit auch effektiv unterbunden und wer schaut schon in seine Webstats rein 😉

Die Ermittlungen

Wenn auch leider, aber nicht unerwartet, sind der Polizei hier die Hände gebunden, da ihr die technischen Ressourcen fehlen, das TOR Netzwerk als ganzes zu überwachen. Wenig verwunderlich wurde TOR genau deshalb ausgewählt. Es wurde ja ursprünglich erschaffen, damit niemand es so überwachen kann, daß er den wahren Urheber eines Webzugriffes feststellen kann. Die Einzigen, die dies könnten, wären die üblichen Verdächtigen, wie eine unheilige Allianz aus BND, NSA und GCHQ usw.

Falls jemand eine größere Datenmenge zur Verfügung stellen will, im BIB-Impressum steht eine Emailadresse. Bevor Sie das tun, kontaktieren Sie bitte vorher Ihren Hausanwalt, ob Sie das auch dürfen.