Werbung blocken mit avm firewall

[cando]

Ich habe das mal mit netfilter/iptables auf der 7270 gemacht (die lösen symbolische dns namen auf), habs aber wieder aufgegeben, da die liste einfach zu gross wird.

Ein guter Proxy wäre da besser, (hab auch mal den privoxy ausprobiert, hatte aber den Eindruck, dass der ziemlich bremst, obwohl ich nur eine knapp 400kpbs DSL Leitung habe und jede hardware dafür schnell genug wäre).

Ein transparenter proxy auf dem router wäre eigendlich am besten (ohne dass man den im Browser eintragen müsste) und der Ansatz die firewall zu bemühen ist auch OK, wenn die Konfiguration nicht so mühsam wäre...

Win WinDoof gab es früher mal den WebWasher als lokaler proxy, der brauchbare Ergebnisse geliefert hat. Nur wollte die Firma irgendwann Geld verdienen und haben sich auf appliances für Geschäftskunden fokussiert...

 

[Borner]

@zirkon

Privoxy eignet sich dafür hervorragend.

Oh, verdammt...
da hat die automatische (Rechtschreib-)korrektur wohl etwas zu viel beim lesen weg-korrigiert.
das iv in Privoxy hab ich glatt überlesen! :-/
Danke für den wink.

Ein transparenter proxy auf dem router wäre eigendlich am besten

Die avm Firewall kann doch auch Ports weiterleiten. Schonmal versucht, Pakete mit Zielport 80 auf den Proxy-port umzubiegen?

 

[cando]

Ja, das geht schon... Ich hab es aber noch nicht gemacht, da ich den Leistungs-Unterschied zwischen proxy und direkt surfen testen wollte.

Wie gesagt, es schien mir, dass der Proxy bei meiner Leitung einfach zu sehr bremst (vermutlich wegen der vielen Namensauflösungen beim Filtern, die die schmale Leitung unnötig dicht machen).

Man müsste auch mal testen, ob er schon die Anfrage blockt oder nur die ankommenden Pakete (was die verschlechterte Performance erklären würde)...

Man braucht den Proxy ja auch nicht nur für port 80, sondern auch für 443 (https) etc.

Ich hab nicht weiter probiert, weil die erhoffte "Beschleunigung" durch das weglassen der Werbebanner & Spam sich nicht eingestellt hat, sondern eher das Gegenteil der Fall war.

 

[Borner]

Man braucht den Proxy ja auch nicht nur für port 80, sondern auch für 443 (https) etc.

https über transparente proxys ist eher schwieriger, bzw. geht gar nicht.
der proxy müßte dazu die ssl-verbindung vom client terminieren und für die anfrage zum webserver eine eigene ssl-verbindung aufbauen.
das beherrscht nach meinem wissen aktuell nur der squid in der neusten generation.
Ob das im squid bereits soweit gereift ist, dass es auch transparent funktioniert, kann ich nicht beurteilen.
die üblichen https-anfragen (wo offiziell ein proxy eingetragen ist) wurden bisher im hintergrund einfach nur durchgereicht.

 

[cando]

Schon klar. Er soll ja nicht https seiten cachen und die Inhalte dieser Seiten auswerten, sondern nur durchreichen und Aufrufe zu spam / webung blocken. Die IP header werden ja nicht verschlüsselt, so dass eine "firewall" mit hilfe der proxy software eigendlich drin sein sollte.

 

[Silent-Tears]

Ausprobieren und gucken, wie die Performance in den Kelelr geht. Oder eben auch nicht.

 

[cuma]

Evtl auch interessant: klick

 

[Borner]

@cando

Ja, der IP Header kann verarbeitet werden - eben wie beim blocken über die Firewall. Der Vorteil bei einem Proxy ist natürlich, nicht nur pauschal IP's, sondern aufgrund bestimmter URL-Muster zu blocken. Die sind dann natürlich nicht mehr Bestandteil des IP Headers, bei https zudem verschlüsselt und können beim transparenten proxy nicht verarbeitet werden.
Mittels Griff in's Blaue würde ich aber sagen, dass selbst die IP basierte Filterung für https über einen transparenten proxy nicht funktioniert. Vielleicht täusche ich mich, wie sich andere proxys da verhalten. Zumindest beim squid kenne ich es so, dass er bei https Aufrufen über den transparenten Weg zuverlässig die Arbeit verweigert-verständlicher Weise.

Ausprobieren und gucken, wie die Performance in den Kelelr geht. Oder eben auch nicht.

Genau, darauf wird's hinaus laufen.

 

[cando]

Ja, das ist mir schon alles klar. Die Namensauflösung zur IP Adresse macht ja der Browser über eine DNS Anfrage um die physikalische Auflösung für den Verbindungsaufbau zu realisieren. Wenn ein proxy eingetragen ist, wird der request an den proxy gesendet, der seinerseits die Auflösung über dns bewerkstelligt.

Beim transparenten proxy wird die Auflösung vom Browser gemacht, da der ja nichts vom Proxy weiss. In diesem Fall kann der Proxy eigentlich nur mit den IP Adressen hantieren (HTTPS durchreichen) oder eben die Daten-Inhalte der Pakete auswerten (HTTP-Header) um z.B. eine Entscheidung für Cachen zu treffen. Er könnte auch selbst ein DNS reverse lookup für die IP-header machen und danach filtern.

Ausgefeiltere Proxys machen eine Man-In-The-Middle "Atacke" auch für HTTPS, indem sie sich als Server ausgeben (ein eigenes Zertifikat verwenden zum client) und damit den Verkehr dechifrieren, danach ihrerseits als client eine SSL Verbindung zum Server aufbauen und verschlüsselt die Daten übertragen / empfangen / umcodieren und zum Browser mit dem eigenen Zertifikat verschlüsselt zurücksenden. Das Problem dabei ist, dass der Client nie die Gültigkeit des tatsächlichen Zertifikates prüfen kann und am Proxy ein Sicherheitsloch entsteht. Außerdem ist eine Authentifizierung mit Client Certificates am Server nicht mehr möglich, da der Proxy in der Regel nicht über die privaten Schlüssel der User verfügt. Auch das Cachen der Inhalte von SSL Seiten ist nicht vorteilhaft, meist sind diese eh dynamisch, ohne decodieren kann man das expiration flag nicht auswerten, und decodiert gespeichert sind sie ein Sicherheitsrisiko.

Deshalb ist eigentlich ein SSL Proxy eher eine Krücke, die sinnvoll nur als Forewarder / Firewall eingesetzt werden sollte.