Irgendwie schaffe ich es nicht die Seite https://www.google.com/adsense/search/async-ads.js in der Blocklist der Fritzbox zu blocken. Hat das mal jemand probiert? Eingetragen ist: google.com/adsense/search/async-ads.js FB7490 FW 7.01 Man findet zu dieser URL auch nichts im Zusammenhang mit Fritzboxen Cache löschen usw. alles schon probiert Wie man http von https bzw. www als Subdomain einzeln unterscheiden soll ist auch schleierhaft.
:
Bearbeitet durch User
Abdul K. schrieb: > Eingetragen ist: > google.com/adsense/search/async-ads.js Warum nicht www.google.com/adsense/search/async-ads.js? Abdul K. schrieb: > Wie man http von https bzw. www als Subdomain einzeln unterscheiden soll > ist auch schleierhaft. www als Subdomain unterscheidet man, indem man es hinschreibt, genau wie google als Subdomain. Zwischen http und https kann man wohl nicht unterscheiden. Ist es denn wichtig für dich, dass dieser Link nur für https gesperrt ist, nicht aber für http?
Rolf M. schrieb: > wischen http und https kann man wohl nicht > unterscheiden. Wie bitte? Das sind komplett unterschiedliche Ports. Abgesehen davon müsste man den https-Datenstrom erst entschlüsseln um einzelne Resourcen auf der Domain zu blocken. Das ist ohne größeren technischen Aufwand nicht möglich.
Kalle schrieb: > Rolf M. schrieb: >> wischen http und https kann man wohl nicht >> unterscheiden. > > Wie bitte? Das sind komplett unterschiedliche Ports. > > Abgesehen davon müsste man den https-Datenstrom erst entschlüsseln um > einzelne Resourcen auf der Domain zu blocken. Das ist ohne größeren > technischen Aufwand nicht möglich. Es geht nicht darum, wie die Kommunikation implementiert ist oder was nötig ist, um so eine Filterung umzusetzen, sondern darum, ob man es in der Blacklist der FritzBox angeben kann. Und das kann man eben nicht.
Rolf M. schrieb: > sondern darum, ob man es in der Blacklist der FritzBox angeben kann. Meist ist es doch egal ob die üble Werbung als http od. https kommt, WENN der SERVER bekannt ist? Mit Pfadangabe kann man natürlich die Quelle genauer ausschließen. Hier Beispiele www.plingplong.de/plang http://service.avm.de/help/de/FRITZ-Box-Fon-WLAN-7490/014/hilfe_internet_filter_blacklist
Abdul K. schrieb: > https://www.google.com/[...] > in der Blocklist der Fritzbox zu blocken. > Hat das mal jemand probiert? Kann und darf nicht funktioniern. Denn alles was die FB zu sehen bekommt ist eine SSL Verbindung zu www.google.com - und die will man ja eher nicht global blockieren. Diese Art von URL Blocking muss im Broser selbst passieren - oder in einem SSL-brechenden Proxy, der einen aber oftmals für Phishing- Attacken exponiert. Denn SSL-brechender Proxy überträgt prinzipbendingt nicht mehr das originale Zertifikat. Fazit: Falsche Baustelle.
Soll das heißen die FB sieht bei https nicht den ganzen Pfad, sondern nur die Domain?
Rolf M. schrieb: > Abdul K. schrieb: >> Eingetragen ist: >> google.com/adsense/search/async-ads.js > > Warum nicht www.google.com/adsense/search/async-ads.js? > Weil AVM beschreibt, man könne www weglassen. Habs aber auch mit probiert und keinen Unterschied festgestellt. > Abdul K. schrieb: >> Wie man http von https bzw. www als Subdomain einzeln unterscheiden soll >> ist auch schleierhaft. > > www als Subdomain unterscheidet man, indem man es hinschreibt, genau wie > google als Subdomain. Zwischen http und https kann man wohl nicht > unterscheiden. Ist es denn wichtig für dich, dass dieser Link nur für > https gesperrt ist, nicht aber für http? Der Link könnte auch für http gesperrt sein.
Abdul K. schrieb: > Rolf M. schrieb: >> Abdul K. schrieb: >>> Eingetragen ist: >>> google.com/adsense/search/async-ads.js >> >> Warum nicht www.google.com/adsense/search/async-ads.js? >> > > Weil AVM beschreibt, man könne www weglassen. Ich bin von der Dokun inzwischen etwas verwirrt. Einerseits heißt es da: "Pfadangaben: Wird in der Internetadresse ein Pfad angegeben, dann wird genau die angegebene Domäne oder Subdomäne berücksichtigt. Andere eventuell vorhandenen Subdomänen werden nicht berücksichtigt." Andererseits lese ich dort auch gerade: "Prefixe weglassen: Die Prefixe http://, https:// oder www dürfen nicht verwendet werden." Warum www jetzt ein "Prefix" sein soll, erschließt sich mir allerdings nicht. > Habs aber auch mit probiert und keinen Unterschied festgestellt. Hast du die Blacklist auch richtig zugeordnet? Abdul K. schrieb: > Soll das heißen die FB sieht bei https nicht den ganzen Pfad, sondern > nur die Domain? Das klingt eigentlich logisch. Diesen an sich doch recht wichtigen Umstand scheint die Doku nicht zu erwähnen.
Die AVM Doku ist widersprüchlich. Habe denen eine email geschrieben, mal sehen. Die Blacklist habe ich bei der Fehlersuche komplett leer gemacht und nur den ungewünschten Pfad reingeschrieben. Für mich war www.* bislang eine Subdomain. Einfach schlimm die Werbepest!!
Abdul K. schrieb: > Einfach schlimm die Werbepest!! Was du suchst nennt sich Adblocker und Scriptblocker. Als Beispiele seien als Firefox Addons "uBlock Origin" und "uMatrix" genannt. Alternativ kannst du dir auch mal Pi-Hole anschauen: https://pi-hole.net/ Wenn du auf "selber machen" keine lust hast: eBlocker https://www.eblocker.com/de/
Kaj schrieb: > Alternativ kannst du dir auch mal Pi-Hole anschauen: > https://pi-hole.net/ Das löst aber auch nicht das https-Problem. Wenn von einem per https ausliefernden Server Inhalt A akzeptiert, aber Inhalt B unterdrückt werden soll, dann geht das entweder nur mit einem Proxy, der das Zertifikat auflöst oder mit einem Adblocker o.ä. im Webbrowser.
Rufus Τ. F. schrieb: > https-Problem 1.Was verschlüsselt ist, wie https ist schwerer zu kontrollieren. 2.Aber den Unterorder von www.google.com/adsense/search/ könnte man zum Test schon mal ausschließen? Wenn der Browser dort im Ordner nicht mehr lesen kann, sollte auch der Skript async-ads.js wahrscheinlich nicht funktionieren (außer mit faulen Tricks).
oszi40 schrieb: > 2.Aber den Unterorder von www.google.com/adsense/search/ könnte man zum > Test schon mal ausschließen? Ein HTTP-Get-Request ist genauso verschlüsselt wie die Antwort darauf. Im Request steht der Pfad "/adsense/search/..." drin. Und damit ist Dein Zugriff auf einen Unterordner außerhalb des Browsers nicht mehr erkennbar. Nimm einen Adblocker wie z.B. ublock.
Abdul K. schrieb: > Soll das heißen die FB sieht bei https nicht den ganzen Pfad, > sondern nur die Domain? Sieht man bei https überhaupt die Domain und nicht nur die Ziel IP? Bei Google ist das kein großer Unterschied, aber auf einem Server mit mehreren Seiten sollte da Domain doch nicht mehr rauszufinden sein, oder?
Dussel schrieb: > Sieht man bei https überhaupt die Domain und nicht nur die Ziel IP? Naja, vorher muss die Domain halt erstmal per DNS zu einer IP aufgelöst werden.
Eine andere Möglichkeit, bestimmte Seiten zu blockieren wäre, ein Eintrag in hosts bei Windows, falls Windows verwendet wird. Befindet sich unter C:\Windows\System32\drivers\etc Beispiel für Eintrag. 127.0.0.1 wwww.google-analytics.com
vn nn schrieb: > Dussel schrieb: >> Sieht man bei https überhaupt die Domain und nicht nur die Ziel IP? > > Naja, vorher muss die Domain halt erstmal per DNS zu einer IP aufgelöst > werden. Ist das noch nicht verschlüsselt? Klar, dann kann es auslesen, aber bei der bestehenden Verbindung doch nicht mehr.
OS schrieb: > Eine andere Möglichkeit, bestimmte Seiten zu blockieren wäre, Damit kann man nicht "bestimmte Seiten", sondern nur bestimmte Domains blockieren. Eine Unterscheidung zwischen http://www.google.com/analytic-spyware und http://www.google.com/interessantes-zeug ist damit nicht möglich.
Dussel schrieb: > Ist das noch nicht verschlüsselt? Nein, DNS ist noch nicht verschluesselt, wird aber dran gearbeitet, z.B. DNS over TLS (DoT), DNS over HTTPS (DoH) oder DNSCrypt DoT: https://en.wikipedia.org/wiki/DNS_over_TLS DoH: https://en.wikipedia.org/wiki/DNS_over_HTTPS DNSCrypt: https://en.wikipedia.org/wiki/DNSCrypt
Dussel schrieb: > Abdul K. schrieb: >> Soll das heißen die FB sieht bei https nicht den ganzen Pfad, >> sondern nur die Domain? > Sieht man bei https überhaupt die Domain und nicht nur die Ziel IP? Wenn auf einer IP mehrere Domains gehostet sind muss der Browser SNI unterstützen um vom Server das richtige Zertifikat zu bekommen. Dabei wird der Hostname unverschlüsselt übertragen. Wenn nur eine Domain zu einer IP zugeordnet ist, ist der Hostname auch anhad der IP klar. So oder so du kennst anschließend den Hostname. https://de.wikipedia.org/wiki/Server_Name_Indication
Rufus Τ. F. schrieb: > Eine Unterscheidung zwischen > > http://www.google.com/analytic-spyware > > und > > http://www.google.com/interessantes-zeug > > ist damit nicht möglich. Deshalb auch die andere Schreibweise, wwww.google-analytics.com ist was anderes als google.com/ usw... Wenn ich wwww.google-analytics.com in Hosts eintrage dann komme ich schon noch auf google.com aber analytics ist blockiert.
Dussel schrieb: > Sieht man bei https überhaupt die Domain und nicht nur die Ziel IP? Dank SNI sieht man die komplette Domain. Damit kann man auf einer IP unterschiedlichen Domains verschiedene Zertifikate zuordnen - das brauchen z.B. die Shared Hoster. Edit: Zu langsam getippt :-(
:
Bearbeitet durch User
Dank ESNI wird zukünftig möglicherweise auch der Hostname nicht mehr im Klartext übertragen, falls sich das durchsetzt: https://tools.ietf.org/html/draft-ietf-tls-esni https://blog.mozilla.org/security/2018/10/18/encrypted-sni-comes-to-firefox-nightly/
Tja da sieht man mal wieder, das der ganze Cryptokram seine Vorteile hat, wenn es um den Schutz der eigenen Daten geht, aber genauso viele Nachteile, da die bösen Buben diese Techniken für Ihre Zwecke misbrauchen können. Die allereinzigste und schon genannte Lösung wäre da ein Proxy, der die Verschlüsselung aufhebt, da er sich als Endpunkt ausgit und dann wieder mit eigenen Zertifikaten verschlüsselt. Das ist aber eher unschön und steht im Wiederspruch zur Ende zu Ende Verschlüsselung. Admins größerer Netzwerke werden es in Zukunft nicht leichter haben...
:
Bearbeitet durch User
Sven L. schrieb: > Die allereinzigste und schon genannte Lösung wäre da ein Proxy, der die > Verschlüsselung aufhebt, da er sich als Endpunkt ausgit und dann wieder > mit eigenen Zertifikaten verschlüsselt. Das ist aber eher unschön und > steht im Wiederspruch zur Ende zu Ende Verschlüsselung. Es ist genau der man-in-the-middle-attack, den SSL ja eigentlich verhindern soll. Damit wird der Proxy, was die Sicherheit der Verschlüsselung betrifft, zum single point of failure. Wer an den rankommt, bekommt die gesamte SSL-Kommunikation des Unternehmens unverschlüsselt geliefert. > Admins größerer Netzwerke werden es in Zukunft nicht leichter haben... Die machen schon ein Weilchen genau das, was du beschreibst. Den Proxy braucht man da beispielsweise auch, um die Daten einem Virenscan zu unterziehen.
Schön, daß ihr auch keine Lösung habt ;-) uBlock origin ist natürlich am Werkeln, ich möchte aber auch ne Lösung für das gesamte Netzwerk, z.B. Handies.
Sven L. schrieb: > Die allereinzigste und schon genannte Lösung wäre da ein Proxy, der die > Verschlüsselung aufhebt, da er sich als Endpunkt ausgit und dann wieder > mit eigenen Zertifikaten verschlüsselt. Das ist aber eher unschön und > steht im Wiederspruch zur Ende zu Ende Verschlüsselung. Das ist eben nicht die "allereinzigste" Lösung, Alternativen wurden hier schon genannt. Abdul K. schrieb: > Schön, daß ihr auch keine Lösung habt ;-) Lösungen wurden hier schon genannt.
Rolf M. schrieb: > Es ist genau der man-in-the-middle-attack, den SSL ja eigentlich > verhindern soll. Damit wird der Proxy, was die Sicherheit der > Verschlüsselung betrifft, zum single point of failure. Wer an den > rankommt, bekommt die gesamte SSL-Kommunikation des Unternehmens > unverschlüsselt geliefert. Eben, alles unschön. Rolf M. schrieb: > Die machen schon ein Weilchen genau das, was du beschreibst. Den Proxy > braucht man da beispielsweise auch, um die Daten einem Virenscan zu > unterziehen. Die Daten wieder einzupacken geht dann nur mit eigenen Zertifikaten, der Browser meckert, wenn man im keine eigene CA-Zertifikate installiert. Jan H. schrieb: > Das ist eben nicht die "allereinzigste" Lösung, Alternativen wurden hier > schon genannt. Naja die einzge zentrale Lösung eben... Das man auf der Clientseite was machen kann wurde ja nicht bestritten.
Abdul K. schrieb: > ich möchte aber auch ne Lösung > für das gesamte Netzwerk, z.B. Handies. Wenn es nur "deine" Smartphones sind, einfach Firefox (nicht Quantum) + uBlock und uMatrix auf dem Smartphone installieren. Nicht schoen, aber man kann halt nicht alles haben. :( Sonst musst du eben auf Loesungen wie Pi-Hole oder eBlocker zurueckgreifen oder du baust dir einen eigenen Proxy. Das Proxys nicht nur ein Sicherheitsgewinn, sondern auch ein Sicherheitsproblem darstellen wurde ja schon genannt. Man denke nur an die ganzen Artikel, wo Anti-Viren Software (oder Security Appliances) genau wegen dem Aufbrechen der Verschluesselung zum Sicherheitsproblem werden. Zum eBlocker: Man koennte sich den auch mal selber bauen https://www.eblocker.com/de/selbstbau/ eine gratis Lizenz nehmen, und sich dann mal anschauen wie die Filterlisten aussehen, und ob man die ohne weiteres erweitern kann, ohne dass die Software dann wegen der Lizenz meckert. Die Lizenz ist ja nur ein Abo fuer die Filterlisten.
Kaj schrieb: > Wenn es nur "deine" Smartphones sind, einfach Firefox (nicht Quantum) + > uBlock und uMatrix auf dem Smartphone installieren. Kann man halt nicht auf jedem Smartphone. Bei iOS geht das z.B. nicht, da gibt es zwar auch Adblocker, die aber taugen recht wenig.
Was muß man in ublock origin eingeben, wenn man z.B.: https://www.mikrocontroller.net/wikifiles/9/9c/Remote-IRMP-Screenshot1.png blockieren möchte? Also www.mikrocontroller.net/wikifiles/9/9c/Remote-IRMP-Screenshot1.png funktioniert nicht. Die gesamte Domain www.mikrocontroller.net blockieren funktioniert durch Eingabe von www.mikrocontroller.net Ist die Grammatik zwischen ublock und ublock origin unterschiedlich? Da gibts Beispiele mit www.google.de/robots.txt∧$domain=domains.google.de und welche mit www.google.de/robots.txt$domain=domains.google.de Ist beides richtig, also das UND implizit?
Kaj schrieb: > Abdul K. schrieb: >> ich möchte aber auch ne Lösung >> für das gesamte Netzwerk, z.B. Handies. > Wenn es nur "deine" Smartphones sind, einfach Firefox (nicht Quantum) + > uBlock und uMatrix auf dem Smartphone installieren. Die FF-Versionen >= Quantum können ebenfalls mit uBlock und uMatrix verwendet werden. Die Portierung der AddOns hatte nur wenige Tage (oder waren es Stunden) gedauert.
Abdul K. schrieb: > Was muß man in ublock origin eingeben, wenn man z.B.: > https://www.mikrocontroller.net/wikifiles/9/9c/Remote-IRMP-Screenshot1.png > blockieren möchte? > > www.mikrocontroller.net/wikifiles/9/9c/Remote-IRMP-Screenshot1.png Da muß ^$document dahinter. Ist echt schwer zu finden, die Doku ist grauenhaft.
Sven L. schrieb: > Rolf M. schrieb: >> Die machen schon ein Weilchen genau das, was du beschreibst. Den Proxy >> braucht man da beispielsweise auch, um die Daten einem Virenscan zu >> unterziehen. > > Die Daten wieder einzupacken geht dann nur mit eigenen Zertifikaten, der > Browser meckert, wenn man im keine eigene CA-Zertifikate installiert. Ja, das installiert die IT auf den Client-Systemen gleich mit. Als Anwender merkt man das dann gar nicht.
Und was wäre der einfachste Weg für ein eigenes Zertifikat?
Eigene Zertifikate bekommt man von let's encrypt. Um seinen eigenen zertifikatsauspackenden Proxy im lokalen Netz mit so einem Zertifikat zu betreiben, muss man das Ding halt im lokalen Netz unter dem gleichen Namen ansprechen können, wie den, den man alle drei Monate zur Zertfikatserneuerung nutzt, d.h. man braucht irgendeinen dyndns-Dienstleister. Das aber ist durchaus handhabbar.
Ich glaube aber nicht, das man das Zertifikat für eine andere Domain bekommt, da letsencrypt und Co eine sog. ACME-Challange macht, da muss man zum zertifizieren in einem Ordner auf seine Domain eine Datei hochladen, damit man zeigt, das Domain und der jenige, der das Zertifikat anfragt zusammen passen.
Der öftere Zertifikatstausch kann auch Arbeit machen oder so schön wie bei MS mal vergessen werden... Welch Wunder, wenn dann das Gerät nicht erreichbar ist!
Rufus Τ. F. schrieb: > Eigene Zertifikate bekommt man von let's encrypt. Um seinen eigenen > zertifikatsauspackenden Proxy im lokalen Netz mit so einem Zertifikat zu > betreiben, muss man das Ding halt im lokalen Netz unter dem gleichen > Namen ansprechen können, wie den, den man alle drei Monate zur > Zertfikatserneuerung nutzt, d.h. man braucht irgendeinen > dyndns-Dienstleister. > > Das aber ist durchaus handhabbar. Aber warum sollte man sich für intern ein Zertifikat von letsencrypt holen, und dann immer über den externen Namen gehen zu müssen? Da kann man sich auch einfach selber eins erstellen und intern nutzen.
Rolf M. schrieb: > Da kann > man sich auch einfach selber eins erstellen und intern nutzen. Man muss halt auf jedem Rechner sein CA-tertifikat ausrollen!
Das ist die Antwort von AVM: Seit FRITZ!OS 6.80 filtert die FRITZ!Box einzelne HTTPS-Adressen in Black- und Whitelist, statt wie bisher alle HTTPS-Anfragen entweder vollständig zu sperren oder vollständig zu erlauben. Die in Black- und Whitelist hinterlegten Internetadressen werden mittels SNI (Server Name Indication) nun auch für HTTPS-Anfragen berücksichtigt. SNI ist eine Erweiterung von TLS, die es dem Browser oder einer App erlaubt, den angefragten Domainnamen beim Verbindungsaufbau unverschlüsselt an den Server zu übertragen, so dass der Server das passende Zertifikat auswählen und bei Verschlüsselung verwenden kann. Bitte beachten Sie, dass lediglich 2ndLevel-Domains mit TLD (Top-Level-Domain) geblockt werden (z.B. "facebook.com", "google.com ) können. Das Blocken einer Domain ohne TLD ist nicht möglich (z.B. "avm", "google"). 3rd-Level-Domains / Subdomains lassen sich nicht dezidiert blocken (z.B. "mail.google.com ", "www.avm.de "). Es lassen sich also nur komplette Domains filtern, nicht jedoch einzelne Adressen bzw. Verzeichnispfade. Der HTTPS-Filter greift nur auf Port 443 und alle HTTPS-IP-Adressaufrufe werden immer gesperrt (z.B. "https://212.42.244.80 ").
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.