[Berlin-wireless] Immer wieder: Filesharing

Sven-Ola Tuecke sven-ola
Do Feb 4 10:47:47 CET 2010


Hey,

bin gestern abend gebeten worden, die Funktion des "zapp"-Skriptes naeher zu 
erlaeutern. In etwas weniger technischen Worten. Ganz abseits von der 
Tatsache, dass ich einfach mal wieder Laune hatte ein bisschen Skriptfummelei 
zu machen.

Das Problem ist uns allen bekannt: die Technik des Filesharing wird gerne dazu 
genutzt, digitale Inhalte wie Musik, Filme oder Software zu tauschen. Wenn 
der Tauschverkehr dann ueber die Gateways abgewickelt wird, bekommt man "von 
aussen" nur die IP des Gateway-Betreibers mit. Der Gateway-Betreiber wiederum 
bekommt dann "als letzte sichtbare Ansprechperson" Aerger.

Als Betreiber eines Gateways hat man sicher eine gewisse Aufsichtspflicht (das 
naehere regelt ein Bundesgesetz) - das sagt einem schon der "Common Sense". 
Darum gibt es bei uns auch zunaechst mal eine ganz klar formulierte 
Policy: "Kein Filesharing ueber die Gateways". Diese Policy  wird ja auch 
z.B. ueber die "Nervseite->OK ich bin brav") kommuniziert. Auszerdem kann 
sich heutzutage jeder Trottel einen VPN-Endpunkt kaufen (available fuer 5,-- 
monatlich bei Ihrem bevorzugten IP-Fachhaendler) und dann darueber machen was 
gewuenscht wird. Wahlweise hilft der Direkt-Tausch von Festplatten.

Jedenfalls braucht unser Gateway-Betreiber Unterstuetzung, um diese 
Aufsichtspflicht zu bedienen. Und genau das macht dieses Skript. Das ist 
keine absolute "sorglos" Loesung. Es ist nur eine Administrator-Hilfsmittel, 
dass man punktuell einsetzen kann. Im Uebrigen darf man die Aufsicht ja auch 
nicht so weit treiben, dass man das Fernmeldegeheimnis dritter bricht.

Zur Technik: 

Das Skript tut nichts geheimnisvolles. Ich vergleiche es mal mit 
der "Heuristik-Funktion" in einem der allgegenwaertigen Virenscanner. 

Auf den Gateways muss ja der Verkehr von mehreren internen IP-Adresse auf eine 
einzelne im Internet gueltige IP-Adresse "uebersetzt" werden. Dazu merkt sich 
das Gateway kurzzeitig, welcher interne Datenverkehr zu welchem extern (im 
Internet sichtbaren) Datenverkehr gehoert. Das nennt sich "Connection 
Tracking" oder NAT. Das Skript untersucht nun diese Uebersetzungstabelle, 
entdeckt und sanktioniert ein bestimmtes Kommunikationsverhalten. 

Hintergrund: Filesharing-Programme haben bestimmte Kommunikationsmuster. Sie 
nehmen in kurzer Zeit Kontakt zu vielen verschiedenen Kommunikationspartnern 
auf. Gleichzeitig kommen von vorher unbekannten Kommunikationspartnern 
Verbindungsanfragen herein. Letztere koennen vom Gateway gar nicht 
weitergeleitet/uebersetzt werden, weil ja ohne vorherige Anfrage dazu keine 
interne IP bekannt ist. Aus diesem Grunde muesste man fuer effektives 
Filesharing auch eine einwaerts gerichtete Umleitung am Gateway 
konfigurieren.

Einige Filesharing-Programme gehen dabei sehr aggressiv vor. Wenn man 
beispielsweise die "VHT/DHT"-Funktion von Bittorrent nutzt kann das soweit 
gehen, dass der Gateway-Router unter der Last der Uebersetzungs-Eintraege 
zusammenbricht. Dies - und die uebermaessige Funkbandbreiten-Nutzung durch 
Filesharing - macht diese Technik ganz allgemein in unseren Funknetzwerken 
unpraktikabel. Behindert sie doch zusaetlich auch alle andere Nutzer.

Es gibt natuerlich auch andere Anwendungen, die ein aehnliches 
Kommunkationsmuster aufweisen. Beim Neustart eines Web-Browsers 
beispielsweise. Dieser versucht saemtliche zuvor geoeffneten Tabs aufzumachen 
und kontaktet dabei eine Unmenge von Websites. Der Abruf einer Liste mit 
RSS-Feeds. Eine Kommunikation mit dem Programm "Tor" vielleicht. Das Skript 
versucht, diese Anwendungen und Filesharing-Anwendungen zu unterscheiden - es 
ist aber keineswegs ausgemacht dass das immer erfolgreich ist. Auf Deutsch: 
da sind Erfahrungswerte als Konstanten eingebaut. Und die muss man an die 
tatsaechlichen Gegebenheiten anpassen. Wenn das Skript also 
jemanden "erwischt": seid freundlich und reagiert zeitnah. Untersucht, warum 
das Skript eine Blockade ausgelöst hat und erhoeht bei Bedarf den 
BOGOTHRESH-Wert - steht vorne im Skript.

Auszerdem funktioniert das Ganze nur, wenn das Filesharing mit vielen 
Gegenstationen stattfindet. Ein einsamer Torrent mit 2 Seedern und einem 
Leecher wird sicher nicht entdeckt. Aber vermutlich machen die die 
Inhalteanbieter-Schergen (Rechtanwaelte + Verwerter) sowieso nur bei den 
High-Volume-Torrents mit. Inwieweit das wiederum verwerflich ist mag ich mir 
gar nicht ausdenken <SCNR>

Hoffentlich hilfts...
// Sven-Ola





Mehr Informationen über die Mailingliste Berlin