Proxyeinstellungen per DHCP verteilen für Android, Mac und Windows
Hallo in die Runde!
Kann man irgendwie Proxy-Einstellungen per DHCP verteilen? Ich habe was von der WPAD.DAT gelesen, die aber unter Android wohl nicht funktionieren soll. Dann habe ich aber etwas von einer PAC-Datei gelesen, wo die Aussagen im Netz etwas widersprüchlich sind, ob das von allen Systemen unterstützt wird. Der Hintergrund ist folgender:
Wir haben in unserer Schule diverse Accessoints, die (unter anderem) ein wLAN für BYOD-Geräte ausstrahlen. Der Internetverkehr der Schüler-Endgeräte muss aber trotzdem über unseren Time-for-Kids-Schulfilter gefiltert werden. Ein transparenter Proxy wäre zwar möglich, filtert aber laut Time for Kids keinen HTTPS-Verkehr. Da aber inzwischen viele WebSites per HTTPS bereitgestellt werden, muss das natürlich funktionieren. Dazu muss der Schulfilter aber bei den Endgeräten als Proxy eingetragen sein. Das muss aber sinnvollerweise automatisch, also ohne Zutun des Benutzers passieren.
Schöne Grüße von der Elbe!
Winfried
Kann man irgendwie Proxy-Einstellungen per DHCP verteilen? Ich habe was von der WPAD.DAT gelesen, die aber unter Android wohl nicht funktionieren soll. Dann habe ich aber etwas von einer PAC-Datei gelesen, wo die Aussagen im Netz etwas widersprüchlich sind, ob das von allen Systemen unterstützt wird. Der Hintergrund ist folgender:
Wir haben in unserer Schule diverse Accessoints, die (unter anderem) ein wLAN für BYOD-Geräte ausstrahlen. Der Internetverkehr der Schüler-Endgeräte muss aber trotzdem über unseren Time-for-Kids-Schulfilter gefiltert werden. Ein transparenter Proxy wäre zwar möglich, filtert aber laut Time for Kids keinen HTTPS-Verkehr. Da aber inzwischen viele WebSites per HTTPS bereitgestellt werden, muss das natürlich funktionieren. Dazu muss der Schulfilter aber bei den Endgeräten als Proxy eingetragen sein. Das muss aber sinnvollerweise automatisch, also ohne Zutun des Benutzers passieren.
Schöne Grüße von der Elbe!
Winfried
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 376830
Url: https://administrator.de/contentid/376830
Ausgedruckt am: 23.11.2024 um 05:11 Uhr
12 Kommentare
Neuester Kommentar
Hallo,
ssl verschlüsselten Traffic kannst Du nur filtern (von URL Filtern mal abgesehen), wenn Du die Verschlüsselung aufbrichst.
Dazu musst Du den Endgeräten ein Zertifikat unterschieben und den Benutzern vortäuschen, sie würden trotzdem verschlüsselt mit dem Server sprechen.
Ich würde an Deiner Stelle die Finger davon lassen, zumindest was BYOD Geräte anbelangt.
Was Schuleigene Geräte anbelangt mag das gehen, ich halte das trotzdem für untragbar, zumindest wenn es um private Aktivitäten der Benutzer geht.
Übrigens sollte "viele Websites per HTTPS " nicht mehr lange gelten, dann gilt "alle Websites".
Schöne Grüße vom Flughafen.
Andreas
ssl verschlüsselten Traffic kannst Du nur filtern (von URL Filtern mal abgesehen), wenn Du die Verschlüsselung aufbrichst.
Dazu musst Du den Endgeräten ein Zertifikat unterschieben und den Benutzern vortäuschen, sie würden trotzdem verschlüsselt mit dem Server sprechen.
Ich würde an Deiner Stelle die Finger davon lassen, zumindest was BYOD Geräte anbelangt.
Was Schuleigene Geräte anbelangt mag das gehen, ich halte das trotzdem für untragbar, zumindest wenn es um private Aktivitäten der Benutzer geht.
Übrigens sollte "viele Websites per HTTPS " nicht mehr lange gelten, dann gilt "alle Websites".
Schöne Grüße vom Flughafen.
Andreas
Außerdem kannst du bei Android keinen systemweiten Proxy setzen, die Einstellungen gelten dann nur für Google Chrome, aber nicht für Apps!
Der Eingriff: Du musst dem Gerät ein Zertifikat importieren und dies vertrauenswürdig machen.
http://www.openschoolproxy.de/index.php?one=sslfilterung.html
In dem Ihr mit der https Filterung faktisch eine "man in the middle" Attacke ausführt macht Ihr Euch nicht nur eventuell strafbar, sondern Ihr sorgt auch dafür das Eure Schüler zukünftig gefährdeter im Internet sind als notwendig.
Warum: Ihr hebelt den Sinn der Verschlüsselung aus und zeigt Euren Schülern das das "ok" ist. Warum sollte ein Schüler zukünftig bei SSL-Warnhinweisen vorsichtig sein, wenn in der Schule sowas ja auch kommt?
Zu meinen mit einem einfachen Jugendschutzfilter und dem Aufbrechen der Vertrauensstellungen zwischen Client und Server sei Eurer Pflicht genüge getan, ist, sorry, unverantwortlich.
http://www.openschoolproxy.de/index.php?one=sslfilterung.html
In dem Ihr mit der https Filterung faktisch eine "man in the middle" Attacke ausführt macht Ihr Euch nicht nur eventuell strafbar, sondern Ihr sorgt auch dafür das Eure Schüler zukünftig gefährdeter im Internet sind als notwendig.
Warum: Ihr hebelt den Sinn der Verschlüsselung aus und zeigt Euren Schülern das das "ok" ist. Warum sollte ein Schüler zukünftig bei SSL-Warnhinweisen vorsichtig sein, wenn in der Schule sowas ja auch kommt?
Zu meinen mit einem einfachen Jugendschutzfilter und dem Aufbrechen der Vertrauensstellungen zwischen Client und Server sei Eurer Pflicht genüge getan, ist, sorry, unverantwortlich.
Man kann ja auf dem Router oder Switch einen Zwangs Redirect machen von Port TCP 80 und TCP 443 Traffic für dieses Netz. Damit erreicht man das gleiche. Das ist in der Wirkung gleich dem Cisco WCCP Kommando.
Ohne WCCP macht man das einfach über eine ACL um den o.a. Traffic zu selektieren und gibt ihn dann per Policy Routing mit einem Next Hop zwangsweise an den Proxy. Fertsch...
Mit der richtigen HW eine Sache von ein paar Minuten.
Ohne WCCP macht man das einfach über eine ACL um den o.a. Traffic zu selektieren und gibt ihn dann per Policy Routing mit einem Next Hop zwangsweise an den Proxy. Fertsch...
Mit der richtigen HW eine Sache von ein paar Minuten.
Moin,
Nein, machen sie sich nicht, sofern die Maßnahme in der von den Schülern und ihren Eltern zu unterzeichnenden Nutzungsbedingung bekannt gemacht wird. Stimmt der Anwender zu, dann darf ich alles, was sonst datenschutzrechtlich verboten ist.
Ist da ein Stammzertifikat installiert, dann kommt da auch keine Meldung.
Ich würde das so lösen: Kein Router per DHCP verteilen. Damit ist schonmal die direkte Verbindung ins Internet unterbunden. Dann auf dem Proxy die Aufrufe abfangen. Die Aufrufe werden dann an den Server per https weitergeleitet allerdings direkt vom Proxy. Also nicht vollständig transparent. Nun kann der Proxy die Seiten entschlüsseln und auf Inhalt prüfen. Dann werden sie unverschlüsselt weiter an den Client gereicht. Das schreibt man in einfachen Worten in die Vereinbarung und gut ist.
Liebe Grüße
Erik
Zitat von @St-Andreas:
In dem Ihr mit der https Filterung faktisch eine "man in the middle" Attacke ausführt macht Ihr Euch nicht nur eventuell strafbar,
In dem Ihr mit der https Filterung faktisch eine "man in the middle" Attacke ausführt macht Ihr Euch nicht nur eventuell strafbar,
Nein, machen sie sich nicht, sofern die Maßnahme in der von den Schülern und ihren Eltern zu unterzeichnenden Nutzungsbedingung bekannt gemacht wird. Stimmt der Anwender zu, dann darf ich alles, was sonst datenschutzrechtlich verboten ist.
sondern Ihr sorgt auch dafür das Eure Schüler zukünftig gefährdeter im Internet sind als notwendig.
Warum: Ihr hebelt den Sinn der Verschlüsselung aus und zeigt Euren Schülern das das "ok" ist. Warum sollte ein Schüler zukünftig bei SSL-Warnhinweisen vorsichtig sein, wenn in der Schule sowas ja auch kommt?
Warum: Ihr hebelt den Sinn der Verschlüsselung aus und zeigt Euren Schülern das das "ok" ist. Warum sollte ein Schüler zukünftig bei SSL-Warnhinweisen vorsichtig sein, wenn in der Schule sowas ja auch kommt?
Ist da ein Stammzertifikat installiert, dann kommt da auch keine Meldung.
Ich würde das so lösen: Kein Router per DHCP verteilen. Damit ist schonmal die direkte Verbindung ins Internet unterbunden. Dann auf dem Proxy die Aufrufe abfangen. Die Aufrufe werden dann an den Server per https weitergeleitet allerdings direkt vom Proxy. Also nicht vollständig transparent. Nun kann der Proxy die Seiten entschlüsseln und auf Inhalt prüfen. Dann werden sie unverschlüsselt weiter an den Client gereicht. Das schreibt man in einfachen Worten in die Vereinbarung und gut ist.
Liebe Grüße
Erik
Hallo,
wie die meisten "Systemadministratoren" an Schulen beschäftigt auch mich das Problem mit der Filterung.
Bisher dachte ich, dass man https-Verbindungen nur filtern kann durch eine "man in the middle" Attacke oder einen Zwangsproxy.
Die Probleme der "man in the middle" Attacke sind oben schon zur Sprache gekommen.
Beim Zwangsproxy mit Verteilung der Wpad.dat Datei per DNS oder DHCP macht vor allem Android Probleme. Die sind teilweise nicht fähig, die Einstellungen für den Proxy automatich vorzunehmen.
Aqui erwähnt die Möglichkeit von Zwangs Redirect von https. Zu meiner Schande muss ich gestehen, dass diese Möglichkeit mir bisher nicht bekannt ist. Könnte mir hier jemand einen Link für eine verständliche Erläuterung geben. Idealerweise sogar eine Anleitung für z.B. Pfsense oder IPFire?
Vielen Dank!
wie die meisten "Systemadministratoren" an Schulen beschäftigt auch mich das Problem mit der Filterung.
Bisher dachte ich, dass man https-Verbindungen nur filtern kann durch eine "man in the middle" Attacke oder einen Zwangsproxy.
Die Probleme der "man in the middle" Attacke sind oben schon zur Sprache gekommen.
Beim Zwangsproxy mit Verteilung der Wpad.dat Datei per DNS oder DHCP macht vor allem Android Probleme. Die sind teilweise nicht fähig, die Einstellungen für den Proxy automatich vorzunehmen.
Aqui erwähnt die Möglichkeit von Zwangs Redirect von https. Zu meiner Schande muss ich gestehen, dass diese Möglichkeit mir bisher nicht bekannt ist. Könnte mir hier jemand einen Link für eine verständliche Erläuterung geben. Idealerweise sogar eine Anleitung für z.B. Pfsense oder IPFire?
Vielen Dank!
Die sind teilweise nicht fähig, die Einstellungen für den Proxy automatich vorzunehmen.
Macht ja nix wenn du ihn auf der Firewall oder dem Router zwangsredirectest.Könnte mir hier jemand einen Link für eine verständliche Erläuterung geben
Lies dir WCCP bei Cisco durch. Ist das gleiche Prinzip nur das Cisco dafür ein festes Komamndo hat und bei "normalen" Routern oder Firewalls man das mit ACLs und Policy Based Routing macht Das PBR Grundprinzip ist auch hier erklärt:
Cisco Router 2 Gateways für verschiedene Clients
In der pfSense kreierst du ganz einfach eine Firewall Regel in der du aus dem Source IP Netz die Ports TCP 80 und TCP 443 filterst. Unter den Advanced Rules gibst du dann dafür ein dediziertes Gateway an was dann dein Proxy ist.
Et voila...fertig ist die HTTP(S) PBR Zwangsroute auf den Proxy.
Vielen Dank für die Informationen.
An der Schule setze ich IPFire ein. Dort ist es mit der GUI scheinbar nicht möglich, die gefilterten Daten an ein anderes Gateway zu senden.
Ich erstelle jetzt ein Testnetz mit Pfsense und eigenständigem Proxy. Da probiere ich das dann mal aus. Soweit ich das verstanden habe, kann ich auf der Pfsense selbst den Proxy aber nicht setzen. Die Daten müssen an einen Rechner mit eigener IP. Oder?
An der Schule setze ich IPFire ein. Dort ist es mit der GUI scheinbar nicht möglich, die gefilterten Daten an ein anderes Gateway zu senden.
Ich erstelle jetzt ein Testnetz mit Pfsense und eigenständigem Proxy. Da probiere ich das dann mal aus. Soweit ich das verstanden habe, kann ich auf der Pfsense selbst den Proxy aber nicht setzen. Die Daten müssen an einen Rechner mit eigener IP. Oder?
Dort ist es mit der GUI scheinbar nicht möglich
Mit einer pfSense wäre das nicht passiert kann ich auf der Pfsense selbst den Proxy aber nicht setzen.
Doch das geht natürlich auch !Du kannst dir über die Package Verwaltung den Proxy dort direkt installieren