Proxy-Einstellungen in Firefox schützen

Problem:
Beim IE ist mittels GPedit recht einfach die "Verbindungen"-Seite zu sperren, sodass die Schüler die Proxy-Einstellungen nicht verändern können.
Firefox hält sich allerdings nicht an die Einstellungen dieser Seite, sondern verwaltet den Proxy selber. Bis Version 1.5 im Karteireiter Allgemein unter Extras-Einstellungen, seit Version 2.0 im Karteireiter Erweitert-Netzwerk-Einstellungen.
Diese Seite lässt sich zwar global für alle User je Client vorgeben, allerdings können die User die Einstellungen verändern oder stilllegen. Wie lässt sich dies verhindern?

Lösung:
Mit den geeigneten Suchbegriffen lassen sich bereits Beschreibungen für die Problemlösung finden, ich stütze mich hier u.a. auf den Lösungsansatz von Mac-o-Net und Chris Ilias, baue aber unsere spezielle Fragestellung ein.

1. Schritt: Wir basteln uns eine Vorlage.
In einem Texteditor erstellen wir folgende Zeilen:

//

lockPref("network.proxy.backup.ftp","192.168.0.200");
lockPref("network.proxy.backup.ftp_port",8080);
lockPref("network.proxy.backup.gopher","192.168.0.200");
lockPref("network.proxy.backup.gopher_port", 8080);
lockPref("network.proxy.backup.socks","192.168.0.200");
lockPref("network.proxy.backup.socks_port", 8080);
lockPref("network.proxy.backup.ssl","192.168.0.200");
lockPref("network.proxy.backup.ssl_port", 8080);
lockPref("network.proxy.ftp","192.168.0.200");
lockPref("network.proxy.ftp_port", 8080);
lockPref("network.proxy.gopher","192.168.0.200");
lockPref("network.proxy.gopher_port", 8080);
lockPref("network.proxy.socks","192.168.0.200");
lockPref("network.proxy.socks_port", 8080);
lockPref("network.proxy.ssl","192.168.0.200");
lockPref("network.proxy.ssl_port", 8080);
lockPref("network.proxy.http","192.168.0.200");
lockPref("network.proxy.http_port", 8080);
lockPref("network.proxy.share_proxy_settings",true);
lockPref("network.proxy.type",1);
lockPref("browser.startup.homepage","http://arktur.schul-netz.de");

Erklärung:Der Proxy hat die IP 192.168.0.200 und den Port 8080 (wenn nicht, dann einfach abändern). Durch die Vorgabe "lockPref" wird Firefox angewiesen, die Einstellung zu sperren, im entsprechenden Menüfenster sind dann Änderungen des Users (auch mit Admin-Rechten!) nicht mehr möglich - das gleiche gilt übrigens auch für die entsprechenden Einträge in about:config!

Die Datei speichern wir unter "mozilla.txt".

2. Schritt: Wir wandeln die Vorlage um.
(Achtung: Original-Post gilt für alte Firefox-Versionen. Siehe Edit unten!)
Firefox akzeptiert Configurationsdateien nur kodiert (byte-shifting mit einem Versatz von 13), am bequemsten geht das mit dem Automatic Mozilla Configurator, Datei hochladen, umwandeln lassen und als mozilla.cfg abspeichern - und zwar im gleichen Verzeichnis wie die firefox.exe - also im Normalfall unter C:\Programme\Mozilla Firefox.

3. Schritt: Ergänzen der all.js.(Achtung: Original-Post gilt für alte Firefox-Versionen. Siehe Edit unten!) 
Nun müssen wir Firefox mit der neuen Datei noch bekanntmachen. Wir öffnen in einem normalen Texteditor die Datei all.js aus dem Verzeichnis C:\Programme\Mozilla Firefox\greprefs. Ganz ans Ende der Datei hängen wir die Zeile:pref("general.config.filename","mozilla.cfg");
(bitte danach vorsichtshalber eine Leerzeile freilassen!)

Das war's auch schon! Beim nächsten Start von Firefox sind die Proxy-Einstellungen gesperrt. Und zwar bei allen Usern auf diesem Rechner.

Wenn man das auf mehreren Rechnern im Netzwerk erledigen muss, hilft eine kleine Batch-Datei auf einem Netzlaufwerk (hier als Laufwerk P: gemountet) mit folgendem Inhalt:

copy p:\mozilla.cfg "C:\Programme\Mozilla Firefox" /y
copy p:\all.js "C:\Programme\Mozilla Firefox\greprefs" /y
pause

Erklärung:
Man beachte die Anführungszeichen! Der Pfad enthält ein Leerzeichen. Damit das Firefox als Teil des Pfades und nicht als fehlerhafte Optionsangabe des Befehls copy angesehen wird, bedarf es der Anführungszeichen!
Die Option /y verhindert eine Nachfrage beim Überschreiben bereits existierender Dateien.
Achtung! Die all.js unterscheidet sich zwischen Firefox 1.5 und 2.0! Man sollte sie also nicht miteinander vermischen!

Edit (04.01.2013):

Das oben Aufgeführte gilt in aktuellen Firefox-Versionen (derzeit: 17.0.1) so nicht mehr! Es geht jetzt einfacher: 

• Schritt 1 bleibt wie oben beschrieben, allerdings wird die Datei nicht als mozilla.txt, sondern gleich als mozilla.cfg gespeichert, der Byteshift aus dem 2. Schritt ist jetzt überflüssig! Die Datei wird im Verzeichnis C:\Programme\Mozilla Firefox gespeichert.
• Eine Anpassung der all.js ist nicht mehr notwendig (und auch nur noch schwer möglich, weil sie in der Datei omni.jar verpackt ist), stattdessen speichert man einfach eine Datei mit dem Namen local-settings.js und folgendem Inhalt:
  
  

  //
  pref("general.config.obscure_value", 0);
  pref("general.config.filename", "mozilla.cfg");

  
  in das Verzeichnis C:\Programme\Mozilla Firefox\defaults\pref\
• Die batch-Datei lautet jetzt: 

copy p:\mozilla.cfg "C:\Programme\Mozilla Firefox" /y
copy p:\local-settings.js "C:\Programme\Mozilla Firefox\defaults\pref" /y
pause

Proxy-Server mit Filterfunktion

Ausgangslage:

Auf einem schwächlichen alten PC lief bei uns bisher Windows XP mit dem Jana-Proxy. Über einige wenige Sperrbegriffe konnten wir zumindest das vormals recht beliebte Chatten auf kwick.de in der Schule unterbinden. Es ist unserer Meinung nach nicht Aufgabe der Schule, den Schülern die Infrastruktur zum privaten Chat zur Verfügung zu stellen.
Über Eintragungen in den entsprechenden Konfigurationsdateien von Firefox und dem Sperren der Konfigurationsseite sowie eine Policy für den IE zwingen wir den Browsern den Proxy auf.

Problem:
Unser alter Content-Filter entspricht nicht wirklich den Vorgaben des Jugendschutzes, wir haben zwar ein paar einschlägige Begriffe gesperrt, die im schulischen Bereich nichts zu suchen haben, hier gibt es aber deutlich effektivere Methoden als unsere.
Eine Positivliste kommt nicht in Frage, das würde den Sinn einer Internetrecherche konterkarieren.
Also muss ein besserer Filter her. Unser Arktur hat den mit Squid und SquidGuard bereits eingebaut. Aber unser Versuch, den Arktur-Proxy auf unserem Server zu aktivieren, hat dazu geführt, dass sich nach einiger Zeit niemand mehr auf Arktur einloggen konnte und sogar das DHCP der Clients fehlschlug.

Lösungsansatz:
Ein eigenständiger Arktur-Rechner, der nur die Proxy-Funktion übernimmt, sonst nichts.

Anmerkung: Es gibt zwar die Zwei-Server-Lösung von Arktur, diese hat aber aus unserer Sicht zwei gravierende Probleme.
Sie ist so gut wie überhaupt nicht dokumentiert. Wie arbeiten die beiden Server zusammen? Auf welchem Rechner muss die Internetverbindung aktiviert werden, wie kann ich die Benutzerkennungen zwischen den Servern abgleichen...? Hilfe zu diesen Fragen war auch über die Liste nicht zu bekommen.
Der bisherige Arktur muss umbenannt werden, da der neue Kommunikationsserver zwingend Arktur heißt. Da hängt aber ein ganzer Pferdeschwanz weiterer Probleme dran.

Der neue Arktur (nennen wir ihn Lauraproxy) war schnell aufgesetzt (auf einem etwas moderneren Rechner als der alte Jana-Proxy) und umbenannt, die erste Netzwerkkarte erhielt die gleiche IP wie der alte Proxy, die zweite Netzwerkkarte wurde an ein anderes VLAN gehängt (aber nur, weil fürs erste VLAN gerade keine Buchse frei war) und bekam dort eine freie IP.
Als DNS-Server wurde beim Erstellen des Internetzugangs (Option "Router") der DNS-Server des Berufsschulnetzes eingetragen, als Adresse des Routers das zuständige Gateway des VLANS.

1. Folgeproblem
Leider war der Server danach noch nicht aus anderen VLANs erreichbar, weder per Ping noch per http.
Hier half das Überarbeiten der /etc/route.conf, die genauso wie der Haupt-Arktur auf unser VLAN eingestellt werden musste, damit der Lauraproxy weiß, dass er alle Anfragen an die unterschiedlichen VLANs an das Gateway des ersten VLANs schicken muss.

2. Folgeproblem
Nun war der Lauraproxy per Ping und http von überall aus erreichbar. Allerdings führten Webseitenaufrufe für das Internet über den Lauraproxy ins Leere, er konnte keine DNS-Namensauflösung durchführen.
Die Lösung kam am nächsten Tag über die Liste:
Die Datei /etc/resolv.conf braucht noch den Eintrag des DNS-Servers hinter dem Punkt nameserver. Warum das nicht zusammen mit den Einstellungen für den Internetzugang erledigt wird, bleibt mir rätselhaft.

Erfolg und Finetuning
Nun klappt es auch mit dem Lauraproxy, sogar spürbar schneller als mit dem alten Proxy, die Filterlisten von Squidguard funktionieren ebenfalls gut - zumindest bei einschlägigen Suchbegriffen in Google.
Allerdings blendet Firefox keine Fehlerseite a la "Böse Anfrage!!!" ein, sondern meldet nur, dass der Server (Lauraproxy) einen Loop verursacht - das sagt den Schülern wenig. Aber sie können die gesperrte Seite nicht aufrufen, und darum ging es ja schließlich. Daran gilt es aber noch zu feilen.