Jungendschutzfilter trotz HTTPS

Jetzt habe ich auch gemerkt, dass ipfire keine https URLs filtert… Ist also ein ziemlich zahnloser Tiger, wenn die Schule die Schüler allein im Computerraum arbeiten lassen will.

Was ich in den anderen Threads hier gelesen habe, verstehe ich so, dass als richtige Lösung eigentlich nur ein externer DNS-Server funktioniert (opendns.com oder BelWü).

Was genau können denn diese externen DNS-Server, das der eigene Server nicht könnte? Das könnte ich meiner Schulleitung im Moment noch nicht wirklich plausibel erklären…

Hallo Linus,

Was genau können denn diese externen DNS-Server, das der eigene Server
nicht könnte? Das könnte ich meiner Schulleitung im Moment noch nicht
wirklich plausibel erklären…

eine https Verbindung ist eine Ende zu Ende (Client zu server)
verschlüsselte Verbindung: da kann ein Proxy ohne weiteres erst mal
nicht rein schauen: also kann nicht gefiltert werden.

Filtert aber der DNS, so kann man die DNS Frage nach www.ferkel.com
„falsch“ beantworten und so die gewünschte Verbindung, trotz https, auf
einen anderen Server auflösen, der die Sperrseite anzeigt.
Das ist auch, wenn man in der Firewall den ZUgang zu udp Port 53 (DNS)
aus dem grünen Netz unterbindet, nicht ohne weiteres umgehen: vor allem
nicht durch Eintrag eines anderen DNS am Client.
Dieser andere DNS wäre ja aufgrund der Sperrung des POrts nicht erreichbar.

LG

Holger

1 „Gefällt mir“

Hallo Linus,

Der DNS-Server von BelWü (129.143.4.3) liefert einfach nur die „falsche“ IP (nämlich seine eigene), wenn irgendwelche Hostnamen abgefragt werden, die nicht jugendfrei sind:

18:04/0 server ~ # nslookup www.sex.com
Server:		129.143.4.3
Address:	129.143.4.3#53

Non-authoritative answer:
Name:	www.sex.com
Address: 129.143.4.3

Der Aufruf im Browser wird also auf die BelWü-Seite umgeleitet (also nicht echt „gefiltert“).

Viele Grüße

Andreas

1 „Gefällt mir“

Heißt das, die https-Verbindung ist nur vom Client zum DNS-Server verschlüsselt? Ich dachte, wenn ich z.B. eine https-Verbindung mit meiner Online-Bank habe, wäre die Verbindung zwischen mir und deren Server Verschlüsselt…

Hallo Linus,

eine https Verbindung ist eine Ende zu Ende (Client zu server)
verschlüsselte Verbindung

Heißt das, die https-Verbindung ist nur vom Client zum DNS-Server
verschlüsselt?

nein: zum Server, nicht zum DNS Server … das wäre dann DNSSEC: aber
auch dann könnte man filtern, weil man den DNS Server vorgibt: also
bestimmen kann, welcher befragt wird: und da schreibt man den filternden
rein.

Ich dachte, wenn ich z.B. eine https-Verbindung mit
meiner Online-Bank habe, wäre die Verbindung zwischen mir und /deren/
Server Verschlüsselt…

ja: genau so ist das.
Trotzdem muss dein Browser, bevor er den Server
sparkasse-waltenbuettel.de ansprechen kann, erstmal den DNS fragen, wie
den die IP des Servers der Domain sparkasse-waltenbuettel.de ist.
und das ist es, was wir „umleiten“ auf einen filternden DNS.
Bei dem steht dann z.B., dass die Domain garkeiner Sparkasse gehört,
sondern einer kriminellen Gummibärchenbande, die Anleitungen zum
selbstherstellen von Gummibärchen verbreitet: also Terrorismus!
Dann wird die IP eines eigenen Servers zurückgegeben: und der
präsentiert die Blockseite.

LG

Holger

Vielen Dank für diese weiteren Erklärungen!
(Was man doch alles während eines Informatik-Studiums nicht gelernt haben kann…) :slight_smile:

Aber das bringt mich noch mal zu meiner Anfangsfrage (die vielleicht mehr Unwissenheit voraussetzt, als es hier für möglich halten wird): Warum könnte ich nicht meinen eigenen DNS-Server in einer VM laufen lassen? Wäre das der hier besprochene Man-In-The-Middle-Eingriff? Aber warum sollten die Schüler dann meinem DNS-Server weniger vertrauen als dem BelWü DNS-Server?

Hallo Linus,

Aber das bringt mich noch mal zu meiner Anfangsfrage (die vielleicht
mehr Unwissenheit voraussetzt, als es hier für möglich halten wird):
Warum könnte ich nicht meinen eigenen DNS-Server in einer VM laufen
lassen?

ja, das kannst du: wenn du dir zutraust einen solchen filternden DNS am
laufen zu halten und vor allem: die SPerrlisten zu pflegen.
Ich hab in der Schule genug zu tun, da bin ich froh, wenn ich sowas
auslagern kann.

Wäre das der hier
https://ask.linuxmuster.net/t/https-transparenter-proxy-und-firewall/402/2
besprochene Man-In-The-Middle-Eingriff? Aber warum sollten die Schüler
dann meinem DNS-Server weniger vertrauen als dem BelWü DNS-Server?

nein: den DNS zu manipulieren ist kein Man-in-the-Middle, da keine
verschlüsselte Verbindung aufgebrochen wird: diese wird vor dem Aufbau
schon verhindert.
Man gelangt also nie an sensible Daten.
Das ist was ganz anderes.

LG

Holger

Hallo Linus,

so sieht das aus, wenn man OpenDNS nutzt.

Gruß

Alois

Hallo Holger,
wenn Du https filtern willst, ist das ungefähr so! Die Verschlüsselung muss im Proxy aufgemacht werden und der verschlüsselt dann zu deiner Datenbank neu. Dies kommt einem Man-in-the-Middle-Angriff gleich. Aber prüft schon wessen Zertifikat sein Browser da grün anzeigt :wink:
LG Jürgen

Hallo Jürgen,

wenn Du https filtern willst, ist das ungefähr so! Die Verschlüsselung
muss im Proxy aufgemacht werden und der verschlüsselt dann zu deiner
Datenbank neu. Dies kommt einem Man-in-the-Middle-Angriff gleich. Aber
prüft schon wessen Zertifikat sein Browser da grün anzeigt :wink:

das weiß ich: aber es geht hier ja um einen filternden DNS und der
bricht keine verschlüsselte Verbindung auf udn erhält keine sensiblen
Daten außer der INformation, welche Seite den aufgerufen werden soll.

LG

Holger

Hallo Holger,

ich muss noch mal nachfragen. Wenn die https-Anfrage vom Client zum DNS-Server nicht verschlüsselt ist, warum kann ipfire dann nicht in die https-Anfrage reingucken, um die Anfrage ggf. zu blocken oder umzuleiten?

Vielleicht mal so:

Die Anfrage beim DNS-Server entspricht dem Nachschlagen einer Nummer im Telefonbuch, das läuft (ohne DNSSEC) komplett unverschlüsselt ab, d.h. jeder kann mitlesen.

Der eigentliche Aufruf der Seite mit https kommt erst danach und entspricht dem Anruf bei der Nummer, die du im ersten Schritt bekommen hast. Da kann dann nicht mitgelesen werden, was übertragen wird (aber natürlich zwischen welchen Teilnehmern die Verbindung besteht).

D.h. die DNS-Abfrage könnte der ipfire abfangen und ggfs. einfach eine falsche IP zurückgeben (so machen wir das im Prinzip ja mit dem BelWü-Nameserver auch), in die Übertragung via https kann er nicht reinschauen, da die ja dann Ende-zu-Ende-verschlüsselt zwischen Client und HTTP-Server abläuft.

Andreas

1 „Gefällt mir“

Hallo Andreas,

danke für die Antwort!

D.h. der ipfire url-filter ist einfach so implementiert, dass er nicht auf die DNS-Anfragen guckt, sondern nur auf den darauf folgenden „wirklichen“ Traffic?

Aber technisch möglich wäre es schon, eine Firewall wie ipfire so zu implementieren, dass auch in den DNS-Anfragen geguckt würde, ob verbotene URLs (egal ob http oder https) angefragt werden; nur hat sowas bisher niemand für nötig gehalten?

Viele Grüße
Linus

Aber genau das kann ipfire ja (aus mir bisher nicht zugänglichen Gründen) offensichtlich nicht… :thinking:

Dazu müsste auf dem ipfire ein eigener DNS-Server laufen, was aber nicht der Fall ist. Am ipfire wird ja lediglich konfiguriert, welchen externen Nameserver er verwenden soll.

Außerdem müsste dann auch, wie Holger weiter oben bereits geschrieben hat, irgendwer den ipfire mit einer Liste der unerwünschten Webserver versorgen.

Viele Grüße

Andreas

Das mit der Liste unerwünschter URLs hat ipfire ja bereits drin (Shallalist, die automatisch täglich geupdated wird). Was wäre denn so schwer daran, in die Anfragen reinzugucken, bevor ipfire die URLs an den DNS-Server weiterleitet?

Hallo Linus,

Das mit der Liste unerwünschter URLs hat ipfire ja bereits drin
(Shallalist http://www.shallalist.de/, die automatisch täglich
geupdated wird). Was wäre denn so schwer daran, in die Anfragen
reinzugucken, bevor ipfire die URLs an den DNS-Server weiterleitet?

nix, wenn man es kann…

Ich traue mir nicht zu einen filternden DNS Server auf zu setzen oder zu
pflegen.
DNS ist ein sehr sensibler Bereich, wo man viel falsch machen kann.

LG

Holger

Muss denn der Filter gleich selbst ein DNS-Server sein? Die Anfragen gehen doch irgendwie bei ipfire durch, bevor sie an den eigentlichen DNS-Server weitergeleitet werden, oder? Kann man sie nicht einfach da abfangen und bei einem Treffer der Blacklist gar nicht erst an den DNS-Server schicken?

Hallo Linus,

Ich traue mir nicht zu einen filternden DNS Server auf zu setzen oder zu
pflegen. DNS ist ein sehr sensibler Bereich, wo man viel falsch
machen kann.

Muss denn der Filter gleich selbst ein DNS-Server sein? Die Anfragen
gehen doch irgendwie bei ipfire durch, bevor sie an den eigentlichen
DNS-Server weitergeleitet werden, oder? Kann man sie nicht einfach da
abfangen und bei einem Treffer der Blacklist gar nicht erst an den
DNS-Server schicken?

dein „Filter“ müßte ja, im Falle eines positiven Eintrags, die DNS
Tätigkeit übernehmen: also eine falsche IP (die deines
Blockseitenanzeigenden Webservers) zurückmelden.

Frag doch mal die Suchmaschine deiner Wahl, wie man einen filternden DNS
aufbaut, oder wie man dem IPFire bei bringt DNS Anfragen ab zu fangen
und vor zu filtern.

Viele Grüße

Holger

Hallo Holger, und danke für die Antworten trotz später Abendstunde! :slight_smile:

Es wäre mir ehrlich gesagt egal, ob die Schüler beim Zugreifen auf verbotene Seiten eine Blockseite angezeigt bekommen, oder ob es einfach nur wie ein nicht erreichbarer DNS-Server aussieht (also Timeout bei der Anfrage).

Im Netz gesucht habe ich tatsächlich parallel zu meinen Fragen hier auch schon. Bisheriges Ergebnis:

  • Im ipfire Forum habe ich das hier gefunden. Aber da müsste ich mich erst mal näher mit befassen, um zu verstehen, worüber die überhaupt reden…

  • Wenn ich stattdessen einen eigenen lokalen DNS-Server mit Shallalist betreiben will, könnte das hier hilfreich sein. Das verwendet dnsmasq.

Hat jemand eine Meinung dazu, welcher dieser beiden Spuren es sich eher lohnt nachzugehen?