Ich hab auf dem IPFire (u.a.) den Port 443 von Grün nach Rot komplett gesperrt, d.h. keiner kommt mit https dirkt raus. Wer das trotzdem will, muss im Browser (und in jedem weiteren Clientprogramm wie apt u.s.w. ) den IPFire als https-Proxy eingestellt haben.
Leider wird bei verbotenen Adressen keine Fehlermeldung angezeigt und die Seite einfach nicht geladen, aber damit kann ich leben.
Dadurch gibt es zwar keine End-zu-End-Verschlüsselung mehr, der IPFire KÖNNTE mitlesen, aber mir ist der Jugendschutz wichtiger.
Grüße
Markus
Hallo Jürgen!
Transparenz hab ich abgeschaltet. Der IPFire lässt nichts raus, außer man nutzt Proxy UND ist dem System bekannt. Ich hab’s so eingerichtet, dass die IPs, die unbekannte Geräte bekommen, nicht durch den Proxy durchkommen.
Grüßle
hatte ich erwartet Wenn man das macht, muss sichergestellt sein,
dass alle Clients den Proxy kennen oder finden!
Von Haus aus ist WPAD in linuxmuster nicht implementiert, so dass die
automatische Proxyerkennung auch auf den Clients nicht funktioniert, auf
denen sie es könnte. Der DHCP-Client von Windows ist (immer noch?) zu
dumm, um diesen Parameter auszuwerten, wenn man ihn in dhcpd.conf
einpflegt. Linux und Mac OS haben DHCP dagegen vollständig
implementiert. Normalerweise muss der Proxy also auf den Clients
eingestellt werden.
Außerdem sind Android und leider auch einige Anwendungen zu dumm, einen
Proxy automatisch zu erkennen oder ignorieren gar ihre eigenen
Proxyeinstellungen (namentlich Smart Notebook 11!). Den DHCP-Parameter
ignoriert Android vermutlich auch. Wie iOS sich verhält, weiß ich nicht.
Firefox konnte zumindest in einigen Versionen auch in Linux nicht mit
„Einstellungen des Systems verwenden“ umgehen, sondern brauchte seine
eigenen.
Den transparenten Proxy abzustellen, ist zwar eigentlich essentiell,
wenn man dessen Umgehung einigermaßen schwer machen möchte, hat jedoch
Nebenwirkungen
So lange ich noch mit Linux-Clients arbeiten durfte, habe ich alle
Anwendungen bis auf den internen Browser von Smart Notebook in den Griff
bekommen. Nach der Umstellung auf IServ und Windows 10 gab es jedoch so
viele Anwendungen, die nicht mehr richtig liefen, dass der Proxy auf
unserem Time for Kids Schulrouter seitdem wieder transparent ist. Wenn’s
der Behörde so reicht …
In den DNS Anfragen stecken nur die Domains, nicht die URL. Also kann es nur „verbotene“ Domains geben, auf URL-Ebene kann nicht verboten werden.
Das führt zur Konsequenz dass man nur ganze Dienste sperren oder erlauben kann. Wer also Erklärvideos auf Youtube erlauben will, erlaubt auch die Pornos auf dergleichen Platform.
Wie geht ihr damit um?
Ich wundere mich, dass Port 53 gesondert gesperrt wird, sollten nicht alle Ports ins Internet gesperrt sein?
Wenn die Internetsperre an ist, schon. Ansonsten willst Du ja im „Internet“ arbeiten, dazu braucht es eben verschiedene geöffnete Ports. Gesondert musst Du den nicht sperren, es reicht imho, wenn du ihn aus „allowed ports“ rausnimmst.
LG
Max
Wenn die Internetsperre „an“ ist, sollte ja kein direkter Zugriff auf das Internet möglich sein und wenn ich im Internet arbeiten will, kann ich das nur über den Proxy. And dem vorbei sollte auch DNS / Port 53 gesperrt sein. Ok, wenn Port 53 in „allowed ports“ gelistet ist, geht DNS, aber dann ist das Internet auch nicht gesperrt, jedenfalls nicht gänzlich.
Wer das trotzdem will, muss im Browser (und in jedem weiteren
Clientprogramm wie apt u.s.w. ) den IPFire als https-Proxy
musstest Du denn auch ein eigenes Zertifikat für IPFire als https-Proxy
auf die Clients verteilen, damit der Browser das ohne weiteres mitmacht?
nein: das geht auch so: es kommt nur bei jeder Seite ein
Zertifikatsfehler, den man wegklicken muss.
So finde ich das sogar ein wenig besser: weil keiner sagen kann „das hab
ich ja garnicht gewußt, dass da jemand dazwischen hängt …“
also da gehen die Meinungen scheinbar auseinander oder ich verstehe etwas grundsätzlich nicht. Hier im IPFire Forum erklärt mir jemand, dass IPFire im non-transparent modus ohne zusätzliche Einstellungen am Client keine Zertifikatsfehler erzeugt… Wo liegt das Misverständnis?
also da gehen die Meinungen scheinbar auseinander oder ich verstehe
etwas grundsätzlich nicht. Hier im IPFire Forum https://community.ipfire.org/t/url-filter-for-https/1070/15 erklärt
mir jemand, dass IPFire im non-transparent modus ohne zusätzliche
Einstellungen am Client /keine/ Zertifikatsfehler erzeugt… Wo liegt das
Misverständnis?
ich hab den Tread im IPFire Forum gelesen.
Ich bin anderer Meinung als „xperimental“: wenn dein Proxy im nicht
transparenten Modus ist und der https Traffic über den Proxy gezwungen
wird (also in den „webproxy einstellungen“ im IPFire der Port 443
(https) nicht mehr bei den Ausnahmen steht, dann wird der Clientbrowser
einen Zertifikatsfehler anzeigen, da er eine Verbindung zum Proxy und
dieser zur Webseite herstellt.
Aber warum theoretisch darüber fabulieren: probier es aus.
Schalt den Proxy in nicht transparent, trag den IPFire als Proxy an
einem Client ein und nimm 443 in den Einstellungen bei den Ausnahmen raus.
Dann schau was passiert, wenn du eine eine https Seite vom Client aus
ansurfst.
Danach kannst du probieren, was passiert, wenn du 443 in den Ausnahmen
drin läßt: kommt die Zertifikatswarnung?
Wird gefiltert?
Hallo Holger, ich habe es jetzt probiert wie von Dir vorgeschlagen.
Das Häkchen bei „Transparent on Green“ wegmachen hat als einzigen Effekt, dass HTTP Seiten nur noch erreicht werden, wenn IPFire als Proxy eingetragen ist. HTTPS Seiten kann ich immer noch aufrufen, egal ob der Proxy eingestellt ist oder nicht. Das auskommentieren von 443 bei den erlaubten Ports hat keinen Effekt (oder was meintest Du mit Ausnahmen)?
Der Filter ist wie vorher: filtert bei HTTP (wenn es erreicht wird) und nicht bei HTTPS. Zertifikatswarnungen habe ich keine gesehen.
nur wenn der Proxy nicht transparent ist, kann meines Wissens der Haken
https filtern überhaupt greifen. Hast Du den gesetzt? Dann müsste
einmalig ein Zertifikatsfehler kommen, falls das Zertifikat, mit dem
Dein ipfire https verschlüsselt nicht von einer offiziellen
Zertifizierungssstelle beglaubigt ist. Ist das Zertifikat erst einmal
angenommen (-> sollte im Image bereits so sein!) kommen keine Fragen mehr.
Hallo Jürgen, welchen Haken meinst Du? Wo finde ich den? Ich habe jetzt (so wie von @baumhof vorgeschlagen) nur den Haken bei „Transparent auf Grün“ entfernt. (Und dann noch 443 in den erlaubten ports auskommentiert.) Viele Grüße, Linus
Das Rausnehmen von 443 aus den „allowed destination ports“ des web proxy war wohl nicht, was @baumhof meinte. Habe jetzt bei den Firewall-Regeln eine Regel erstellt, die HTTPS von Grün auf Rot blockt. Jetzt ist es tatsächlich so, dass ich auch auf HTTPS-Seiten nur noch drauf komme, wenn der Proxy im Browser eingestellt ist und der URL-Filter wird sogar angewendet. Es kommen jedoch keine Fehlerseiten wie beim Zugriff auf verbotene HTTP-Seiten, sondern einfach nur ein timeout.
Aber:
Es kommen bei den erlaubten HTTPS-Seiten tatsächlich keine Zertifikatswarnungen!
also ich habe es jetzt (auch mit Hilfe des IPFire Forums) soweit hinbekommen. Die Lösung ist erschreckend einfach und besteht aus 2 Schritten:
Stelle am Client IPFire (bei mir 10.16.1.254:800) als den Proxy sowohl für HTTP als auch für HTTPS ein.
Erstelle eine IPFire Firewall-Regel, um allen HTTPS-Traffic, der nicht über den Proxy geht, zu blocken:
Source: Standard networks: GREEN
Destination: Standard networks: RED
Protocol: -Preset- Services: HTTPS
DROP
Das wars! URL-Filter greift sowohl bei HTTP (mit Fehler-Seite) als auch bei HTTPS (Timeout)!
Ob „transparent mode“ oder nicht, spielt dabei offenbar keine Rolle.
Da ist auch nichts „Man-in-the-middle“-mäßiges dabei. Es gibt keinerlei Zertifikatswarnungen beim Surfen auf HTTPS Seiten.
Verstehen tue ich das ganze zwar immer noch nicht wirklich, aber der gewünschte Effekt ist erreicht!
PS: Damit man im Browser noch auf die Schulkonsole, CUPS, IPFire etc. kommt, muss man auf den Clients diese Ausnahmen einrichten (d.h. wo kein Proxy verwendet werden soll):
Wenn man das macht, muss sichergestellt sein,