Deep Packet Injection Werbung

lockdoc

lockdoc

Well-Known Member
Hi,

ich bekomme in letzter Zeit immer mehr Webung in diverse Browserseiten (wahrscheinlich von meinem ISP) injected und wollte mal fragen, ob ich mich dagegen irgendwie wehren kann, da das doch recht nervig ist.

Mit "wehren" meine ich sowas wie am System was aendern und keinen Beschwerdebrief schreiben xD
 
Erst Frage: In welcher Jurisdiktion geschieht das. Zweite Frage: Welche Art der Lösung strebst du an (Umgehen oder rechtliche Schritte). Sicher das nicht nur deine AdBlock listen veraltet sind?
 
@Crest. das ist hier in China und ich suche eine Loesung dass an meiner Kiste zu unterbinden, falls es denn moeglich ist.
Die Werbung ist auessert sich mit einer Art Javascript Popup in der rechten unteren Ecke und ist meisst ueber 3G Angebote fuer Handies.
Oefters friert mir dabei auch die Seite ein. Nach einem Reload ist die Werbung weg
 
lockdoc schrieb:
ch bekomme in letzter Zeit immer mehr Webung in diverse Browserseiten (wahrscheinlich von meinem ISP) injected und wollte mal fragen, ob ich mich dagegen irgendwie wehren kann, da das doch recht nervig ist.

Mit "wehren" meine ich sowas wie am System was aendern und keinen Beschwerdebrief schreiben xD
Zum Vergrößern anklicken....

Falls Dein Zugangsprovider einen HTTP-Proxy anbietet und Du diesen verwendest => einfach ohne den Proxy surfen.

Falls Dein Zugangsprovider einfach alle DNS-Anfragen auf einen eigenen "Proxy" umbiegt => anderen Nameserver verwenden.

Falls Dein Zugangsprovider Dir einen transparenten Zwangsproxy vorsetzt oder keinen HTTP- und/oder DNS-Traffic direkt durchlaesst => Provider wechseln.

Falls Dein Zugangsprovider tatsaechlich den Traffic zwischen DIr und den Webservern manipuliert, dieses so nicht in den AGB vermerkt oder vertraglich festgelegt ist, und der Provider sich in Deutschland befindet: Strafanzeige stellen; das waere dann naemlich unbefugte Manipulation von Daten, was in DE unter Strafe steht (den entsprechenden Paragraphen muesste ich noch raussuchen).
 
Richte dir einen lokalen HTTP-Proxy auf deinem Rechner ein, der das Javascript per Regex rausfiltert. Recht gut geht das zum Beispiel mit Privoxy.
 
www/privoxy

Hält viel schon 'out of the box' ab, ist einfacher und kleiner als squid.
 
@Kamikaze
Bei https ist es bis jetzt nicht aufgetreten, darum auch meine Annahme von der manuellen Injection.

Im Moment warte ich ja auf die naechste Werbung, damit ich mir mal den Source ankucken kann und mir eine privoxy rule hinzufuegen kann, aber wie es immer so ist, wenn man es braucht kommt es nicht X_X
 
lockdoc schrieb:
@Kamikaze
Bei https ist es bis jetzt nicht aufgetreten, darum auch meine Annahme von der manuellen Injection.
Zum Vergrößern anklicken....
Ja, darauf wollte ich hinaus. In meinen Augen stützt das auch deine These.

Du sagst beim 2. Laden geht das Problem weg. Benutzt du Firefox? Dann installiere mal das Modify Headers Plugin (bei FreeBSD auch in den Ports) und schicke einen Cache-Control=no-cache Header mit.
 
lockdoc schrieb:
+ als DNS nutze ich die beiden google Server 8.8.8.8 und 8.8.4.4
+ Proxies nutze ich nicht vom Provider

Ich weiss selbst gar nicht, ob man das ueberhaupt konfigurationstechnisch unterbinden kann.

Edit:
Ich hatte noch was dazu gefunden, dass das auch woanders so ist:
http://www.dslreports.com/shownews/Mediacom-Injecting-Their-Ads-Into-Other-Websites-112918
http://www.techdirt.com/blog/?tag=ad+injection
Zum Vergrößern anklicken....

Servus locdoc,

also ich tippe mal auf Profilbildung:

Mittels zwischengeschalteter transparenter Webproxies wird das Aussehen der angesteuerten Webseiten durch Einbettung von Javascript- oder HTML-Code in den Datenstrom heimlich manipuliert und im Ergebnis
Werbung gezeigt, die auf der eigentlichen Webseite nicht vorkommt. Das wäre im Vergleich zur Briefpost so, als ob die Post jeden Briefumschlag öffnet und auf die darin liegenden Briefe Werbung aufdruckt.

Quelle siehe angehängtes PDF Dokument

CU

Ergänzung

so mal ein Verweiss zu einem Unternehmen das sich auf DPI spezialisiert hat und seine Tools Providern anbietet schaue mal unter Produkte

# http://www.ipoque.com/resources/white-papers
 

Anhänge

  • BednerDeepPacketInspection.pdf
    1,4 MB · Aufrufe: 442
Zuletzt bearbeitet:
rudy schrieb:
Mittels zwischengeschalteter transparenter Webproxies wird das Aussehen der angesteuerten Webseiten durch Einbettung von Javascript- oder HTML-Code in den Datenstrom heimlich manipuliert und im Ergebnis
Werbung gezeigt, die auf der eigentlichen Webseite nicht vorkommt. ...
Zum Vergrößern anklicken....
Die Vermutung hat der OP von Anfang an.

Worauf willst du denn hinaus?
 
Kamikaze schrieb:
Die Vermutung hat der OP von Anfang an.

Worauf willst du denn hinaus?
Zum Vergrößern anklicken....

Servus

ja ich weiß, in dem Dokument sind auch die rechtlichen Aspekte dabei berücksichtigt auch nicht unwichtig so kann die sich jeder Interessierte durchlesen und erhält auch weitergehende Informationen.

CU
 
Das ist ja erschreckend! Hätte nicht gedacht, dass jemand Content in HTTP einschießt. Bei uns ist Modifikation der Kommunikationsübermittlung eindeutig illegal.

Des Weiteren ist die Sicherheit hier anzuzweifeln. Es ist ein großes Problem, wenn man Content kriegt, der vom Gegenüber nicht abgeschickt worden ist. Das Vertrauen hier ist nicht vorhanden.

Ich würde nur noch HTTPS nutzen und zwar ohne Tunneling durch Proxys (hier muss man vorsichtig sein und einmal sniffen ob Daten beim Proxy im Klartext ankommen und der dann HTTPS weiter macht; das wäre unerwünscht).

So etwas scheint Internet vielleicht billiger zu machen, aber ich würde zu einem anderen Provider raten, der so etwas nicht macht, auch wenn es teurer ist.

Außerdem, mit JavaScript kann man allerlei Unfug treiben, bis zum Auslesen von lokalen Dateien und Clipboards etc. Man kann auch Tasten/Mausbewegungen mitloggen uvm.
 
nakal schrieb:
Das ist ja erschreckend! Hätte nicht gedacht, dass jemand Content in HTTP einschießt. Bei uns ist Modifikation der Kommunikationsübermittlung eindeutig illegal.
Zum Vergrößern anklicken....

Das wird hierzulande auch gemacht, allerdings aus finanziellen Hintergründen. Ich weiss nicht, obs heute noch genauso ist, aber t-mobile hatte das mal bei den UMTS-Geschichten. Aufgefallen wars mir, als JS-Geschichten via UMTS nicht funktionierten. Mit curl die Seiten einmal mit umts und einmal mit ner normalen Strippe gezoggen, es kam ein reichlicher diff dabei raus. Eigenes JS wurde eingebunden und wohl aus trafficgründen Bildquellen umgeleitet auf ne IP im reservierten Bereich. Die Bilder, die dort gecached waren differierten auch von den Originalen, sie waren stärker komprimiert.
 
Ich kann mir durchaus vorstellen, dass dieses Vorgehen, das Prinzip nachdem Web funktioniert kaputt macht (siehe: RESTful design und HTTP). Außerdem bin ich auf keinen Fall einverstanden damit, dass jemand die Ressourcen fälscht.

Irgendwann muss man wahrscheinlich komplett HTTP durch HTTPS ersetzen, weil gegen endgültige Dummheit und Unbelehrbarheit hilft nur Gewalt.
 
Nur den Sourcecode auf der Projektseite oder was meinst du mit "was dafuer"?
Aber wenn dir das gefällt, kennst du schon B.A.T.M.A.N. und Netsukuku? Für beide gibt es Code, aber letzteres dürfte leider ziemlich tot sein.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben