Wie komme ich an mein Config-File?

FilterSurf-Redirector Konfigurationsdatei
Version V2.14.1 (26.03.2006)
FilterSurf GbR: Christian Ludwig, Dominik Herrmann
www.filtersurf.de

Diese Datei dient zur Konfiguration des Redirector-Skripts. Bitte achten Sie auf die korrekte Schreibweise, da Syntaxfehler zu Problemen führen können. Kontrollieren Sie die einwandfreie Funktion des FilterSurf-Redirectors im system log (unter Linux /var/log/syslog oder /var/log/messages).

Bitte lesen Sie die Kommentare zu den einzelnen Parametern. Dort ist die Funktionsweise genau erläutert und es werden Beispiele zur Verwendung gegeben. Bei Fragen wenden können Sie auch die Entwickler kontaktieren. Mit dem Online-Konfigurator auf unserer Internetseite (http://www.filtersurf.de/configurator.php) können Sie eine fertige conf-Datei erstellen lassen.

1. PROXY-SERVER

Wenn ein HTTP-Proxy-Server ("Zwangs-Proxy") für die Kommunikation mit dem Internet benötigt wird und dieser für die Verbindung zum FilterSurf-Server verwendet werden soll, dann muss der Proxy-Server hier eingetragen werden.

Falls Sie sich nicht sicher sind, ob Sie hier etwas eintragen müssen: Ein Eintrag ist nur dann nötig, falls eine direkte Verbindung ohne Verwendung des Proxy-Servers unmöglich ist. Sie können es zuerst ohne eingetragenen Proxy-Server versuchen. Falls der Redirector dann nicht funktioniert (Ausgabe in /var/log/messages beachten!), dann sollten Sie es mit einem Eintrag hier noch einmal versuchen.

Ist kein Proxy-Server vorhanden oder wird er nicht benötigt, dann müssen die Zeilen proxy_server_ip und proxy_server_port mit "#" auskommentiert werden.

Technischer Hinweis:
Hier KEINEN Hostnamen (z.B. proxy.local.net) eintragen, sondern unbedingt die IP-Adresse (z.B. 10.0.0.1)!
Proxy-Authentifikation wird derzeit nicht unterstüzt.

2. KATEGORIEN

Das hier ist eine Bitmaske, die angibt, welche Kategorien gefiltert werden sollen:

 Kategorie 1: porno/adult                (1)
 Kategorie 2: aggressive/violence        (2)
 Kategorie 3: search engines             (4)
 Kategorie 4: hacking/warez              (8)
 Kategorie 5: forums/chats              (16)
 Kategorie 6: onlineauctions            (32)
 Kategorie 7: (web)mail                 (64)
 Kategorie 8: gambling/time waste      (128)
 Kategorie 9: proxies/anonymizer       (256)

Beispiel: Um porno/adult, search engines und forums/chats zu sperren:
$categories = 1 + 4 + 16;

Wenn $googlesafesearch aktiviert ist (das ist die Standardeinstellung), dann wird automatisch veranlasst, dass die google Safesearch aktiviert wird (Details: http://www.google.com/help/customize.html). Um Safesearch zu deaktivieren, diesen Wert auf 0 setzen.

3. LOKALE BLACKLISTE

Dies ist eine Liste mit zusätzlich zu filternden Adressen (zusätzlich zu den oben ausgewählten Kategorien).

Verwendungshinweise:
Ein Eintrag der Form a.b.c sperrt alle Adressen, die so ENDEN, also auch x.y.a.b.c.

Beispiel: Eintrag 'filtersurf.de' sperrt z.B.:
www.filtersurf.de, www.test.filtersruf.de

Beispiel: Eintrag 'www.filtersurf.de' sperrt:
www.filtersurf.de, ABER NICHT: filtersurf.de

Die Markierungen (begin/end locallist) werden bei der FilterSurf- Box für die korrekte Funktion benötigt. Unbedingt unangetastet lassen!

Beispiel-Eintrag:
@locallist = (
 'url1.de', 'url2.de', 'url3.de'
);

Seit Version 2.13 unterstützt der Redirecor auch eine Blackliste, die in eine Datei ausgelagert ist. Es ist derzeit jedoch noch nicht möglich, die Blackliste aus mehrere Dateien zu laden.

Syntax:
@locallist = includefile("filename");

Erstellen Sie dann die Datei "filename" und tragen Sie die URLs zeilenweise (Unix-Format! Separator: \n) ein.

Achtung: Bei Verwendung großer lokaler Listen kann es zu Einbußen bei der Geschwindigkeit kommen, da der lokale Suchalgorithmus noch nicht auf Performance optimiert ist.

4. LOKALE WHITELISTE

Liste mit Seiten, die auf keinen Fall gefiltert werden sollen: Es gilt die Filter-Konvention wie oben.

Hier sollten auch Webserver eingetragen werden, die im lokalen Netzwerk (LAN) vorhanden sind. Diese sollen ja i.d.R. ohne Filterung erreichbar sein.

Die Markierungen (begin/end localwhitelist) werden bei der FilterSurf- Box für die korrekte Funktion benötigt. Unbedingt unangetastet lassen!

www.filtersurf.de verwendet das BPjM-Modul. Dieses Modul bewirkt die Filterung der von der Bundesprüfstelle für jugendgefährdende Medien (BPjM) indizierten Telemedien (Online-Angebote). Die Einträge umfassen sowohl jugendgefährdende Angebote als auch solche, deren Verbreitung nach Jugendmedienschutz-Staatsvertrag der Länder (JMStV) unzulässig ist. Informationen zur BPjM und zum Indizierungsverfahren finden Sie unter www.bundespruefstelle.de.

Wichtiger Benutzungshinweis:
www.filtersurf.de erlaubt die Verwendung einer sog. "lokalen" Whiteliste, die von jedem FilterSurf-Benutzer (Systemadministrator) selbst gepflegt werden kann. In diese Whiteliste können Internet- Domains aufgenommen werden, die nicht gesperrt werden sollen. Mit solchen Einträgen ist es daher möglich, einzelne Einträge den Endbenutzern zugänglich zu machen, auch wenn Sie ohne Whitelist gesperrt worden wären. Wenn sich ein Systemadministrator Sicherheit verschaffen möchte, ob ein beabsichtigter Whitelist-Eintrag mit dem BPjM-Modul kollidiert, kann er die fragliche URL in einer Einzelabfrage an die BPjM schicken: liste@bundespruefstelle.de.

Beispiel-Eintrag:
@localwhitelist = (
 'url1.de', 'url2.de', 'url3.de'
);

Seit Version 2.13 unterstützt der Redirector auch Whitelisten, die in eine eigene Datei ausgelagert sind. Weitere Hinweise zur Syntax befinden sich im Kommentar bei der lokalen Blackliste.

5. STATUS und ACCESS LOG

Wenn der Redirector alle Web-Zugriffe protokollieren soll, dann muss der Parameter $access_log auf '1' gesetzt werden.

Der Dateiname des Logfiles sollte dann noch in /etc/syslog.conf gesetzt werden. Der Redirector verwendet standardmäßig die syslog Facility local0. Falls eine andere Facility gewünscht ist, kann dies mit dem Parameter $syslog_facility eingestellt werden. Auf den meisten Systemen passt wohl die Voreinstellung (local0). Fehlermeldungen erscheinen dann in /var/log/messages oder /var/log/syslog.

Ist keine Protokollierung erwünscht (Vorteil: bessere Performance), so muss der Parameter access_log mit # auskommentiert werden.

Auf jedem Fall geloggt werden Status-Meldungen, Warnungen und Fehler, die der Redirector im Betrieb erkennt.

Um aus /var/log/messages die interessanten Zeilen (die angewählten Internetseiten und das Filter-Ergebnis) zu ermitteln, kann man mit dem grep-Kommando das Log entsprechend aufbereiten.

6. SONSTIGE PARAMETER

Die optimale Performance des FilterSurf-Redirectors wird erreicht, wenn der FilterSurf-Cache-Daemon (fscached) verwendet wird. Hier wird der Socket des Daemons eingestellt. Die Standardeinstellung kann meistens unverändert übernommen werden. Wenn der fscached nicht verwendet wird, muss man $fscached_sock = ''; schreiben oder den Parameter auskommentieren. Mit $fscached_max_entries wird festgelegt, wie viele Hosts im Cache maximal gespeichert werden. Die $fscached_expiration_time gibt an, wie lange ein Eintrag maximal im Cache gespeichert bleibt (in Sekunden).

Es ist möglich, verschiedene Designs der Access Denied (Zugriff verweigert) Seite anzeigen zu lassen. Dies wird nur für OEM-Lösungen benötigt, die eine eigenes Design für die access_denied.php Seite benötigen. Falls Sie Interesse an einem solchen eigenen Design haben, wenden Sie sich bitte an die Entwickler.

Default: Standard-Design

Filter-Bypass (auch bekannt als temporäre Whitelist) Diese Funktion erlaubt es, gesperrte Seiten nach Eingabe eines festgelegten Benutzernamens und Passworts sofort freizuschalten. Dazu muss hier ein Benutzername und Passwort festgelegt werden, das dann auf der Zugriff-Verweigert-Seite zur Authentifizierung eingegeben werden muss. Bitte achten Sie auf ausreichende Sicherheit: Wenn Sie die Zugangsdaten in dieser Datei abspeichern, sollten Sie die Unix-Zugriffsrechte anpassen, so dass nur der squid-User (oft "squid" oder "proxy") auf diese Datei zugreifen darf:

chown squid redirector.conf; chmod 0700 redirector.conf

Alternativ können Sie Benutzername und Passwort in einer separaten Datei abspeichern (wiederum wie oben eingeschränkte Unix-Rechte setzen, damit kein Unbefugter die Zugangsdaten lesen kann!). In der Datei muss der Benutzername in der 1. und das Passwort in der 2. Zeile stehen. Wenn Sie die Datei bypass.conf nennen, können Sie sie folgendermaßen einbinden:

@bypasscredentials=includefile("bypass.conf");

Wenn Sie die Zugangsdaten hier hinterlegen wollen, lautet die Syntax wie folgt:

$bypasscredentials_user="username"; $bypasscredentials_pass="password";

Hier können Sie festlegen, wie lange der Bypass aktiv sein soll. Derzeit gilt der Bypass immer für das gesamte Netzwerk für die angegebene Dauer.

Einheit: Sekunden

6. SERVER-NAME UND USER-ID

Welcher FilterSurf-Server soll verwendet werden? Der Hauptserver wird über den DNS-Namen fsredir.dyndns.org angesprochen. Dies ist auch der Default-Wert.

Falls Sie einen eigenen FilterSurf-Server betreiben wollen, wenden Sie sich bitte an die Entwickler (Kontaktinfos finden Sie am Anfang dieser Datei).

Für erhöhte Ausfallsicherheit kann ein Fallback-Server angegeben werden. Wenn der 1. Server nicht erreichbar ist, wird auf den Fallback-Server umgeschaltet. Falls dieser auch nicht erreichbar ist, wird die angefragte URL entweder gesperrt oder freigegeben.

Dieses Verhalten wird mit $defaultaction festgelegt, mögliche Werte sind ACCESS_GRANT oder ACCESS_DENY (default: "ACCESS_GRANT").

Druch $connectiontimeout kann man angeben, wie viele Sekunden auf die Antwort des FilterSurf-Servers gewartet werden soll. (default: 20)

Der Fallback-Server wird dann aktiviert, wenn $fallbackthreshold direkt hintereinander stattfindende Aufrufe fehlgeschlagen sind.

Der Fallback-Server wird $resolveinterval Sekunden verwendet. Dann wird wieder auf den $filtersurfserver zurückgeschaltet. Default: 43200, also 12 Stunden

Wenn der verwendete FilterSurf-Server eine Authentifizierung verlangt, dann muss der Nachfolgende Parameter mit einer gültigen User-ID besetzt werden. Andernfalls sollte er mit # auskommentiert werden. Die User-ID wird bei jeder HTTP-Anfrage an den FilterSurf-Server geschickt.

Falls Sie neben der userid auch einen username erhalten haben, muss dieser ebenfalls eingetragen werden. Ansonsten können Sie dieses Feld leer lassen.