In diesem Kapitel widmen wir uns der Web Contentfilter Funktionalität.
Wir sprechen über feste Filter, Hostgruppen und den dynamischen Einsatz der Surfkontrolle im Unterricht.
Zur Veranschaulichung verwenden wir wieder unsere Standard Konfiguration.
Ein Windows Client und ein iOS Tablet hinter einem Access Point.
In der Beispielkonfiguration befindet sich der Windows PC im Kupfernetz INT0 mit einer statischen IP und einem DHCP Server.
Die Schnittstelle steht bezüglich der Webauthentifizierung auf "Immer Blocken (Proxy)" mit aktiviertem transparenten Proxy.
Das bedeutet: Eine Proxy Konfigurationsdatei bzw. Proxy PAC liefert die Direktive "Direkte Kommunikation".
Die Firewall wird in diesem Fall alle Web Requests auf dem HTTPS Port abfangen
und den im Standardfall nicht authentifizierten Geräten eine Sperrseite übermitteln.
In der Einstellung "Immer durchlassen (Proxy)" kehrt sich diese Logik um.
Grundsätzlich ist der Webzugriff erlaubt, es sei denn, die Webseite befindet sich auf einer globalen Blacklist.
Genug der Theorie! Ein paar Beispiele werden diese verdeutlichen.
Angefangen mit der Einstellung "Immer blocken (Proxy)" ohne Stammzertifikat –
also aktives Scannen der Inhalte einer HTTPS-Verbindung, jedoch weiterhin mit transparentem Proxy.
Der Client kommuniziert also nativ über den HTTPS Port ohne Proxy Zusätze.
Auf der Workstation sieht das nun wie folgt aus:
Ein Zugriff auf www.heise.de resultiert in einer Proxy Sperrseite "REJECT_ALWAYS_DENY",
weil das Interface auf "Immer blocken" steht.
Da es sich um eine von der Firewall generierte Antwort auf eine HTTPS Seite von Heise handelt,
muss die Firewall diese mit dem eigenen Stammzertifikat signieren.
In diesem Fall ist dieses Stammzertifikat bereits auf dem PC installiert.
Auf der Firewall Seite ist dieser Request im Proxy Log verzeichnet worden.
Filtern wir die URL im aktuellen Surf Log auf "heise", sehen wir hier die blockierten Requests
und können diese gleich bequem für die ganze Domain in die globale Whitelist übernehmen.
Ein %-Zeichen in der Whitelist entspricht einem Wildcard Platzhalter.
Also werden alle Webseiten freigeschaltet die auf "heise.de" enden.
Auf dem Client ist nun heise zu sehen.
Allerdings fehlt die eine oder andere Zusatzwebseite für Werbung oder zusätzlichen Content.
Diese kann ebenfalls einfach per Surf Log erlaubt werden.
Soweit zur grundlegenden Basisfunktion.
Als nächstes schauen wir uns das Thema HTTPS Stammzertifikate an.
Das HTTPS Protokoll für sichere Webseiten leistet nicht nur die Verschlüsselung der Daten,
sondern auch die Serververifizierung.
Also eine Garantie dafür, dass der antwortende Server auch der ist, wofür er sich ausgibt.
Im Fehlerfall erhält der User vom Browser eine Zertifikatswarnung,
welche im Browser bei den meisten Webseiten für die einmalige Anfrage ausser Kraft gesetzt werden kann,
um die Seite dennoch anzuzeigen.
Die Verifizierung geschieht durch einen vertrauenswürdigen Dritten: Eine Zertifikats-Validierungsstelle.
Diese hat den Server einmalig geprüft und das Zertifikat ausgestellt.
Der Client Browser vertraut der Validierungsstelle ebenfalls
und hat deshalb das sogenannte Stammzertifikat der Validierungsstelle werksseitig installiert.
Um einer OctoGate Firewall die Möglichkeit zu geben, den HTTPS Datenverkehr komplett zu scannen,
muss der Client also auch der OctoGate vertrauen und deren Stammzertifikat installiert haben.
Bei Windows, Linux und MAC-Systemen geht das problemlos.
Bei iOS und Android leider nicht.
Für diesen Fall gibt es das OctoGate SNI Scanning.
Durch eine ausgefeilte Technologie ist es möglich, Webzugriffe zu filtern ohne die Nutzdaten entschlüsseln zu müssen.
In der OctoGate Oberfläche wählen Sie dazu einfach "Ohne Stammzertifikat".
Zertifikate können über die unterschiedlichsten Wege auf den Client kommen.
Hinter einer OctoGate gibt man einfach "info.octogate.online" an.
Mit dem Klick auf "SSL Zertifikat" ist ein direkter Download für alle gängigen Betriebssysteme möglich.
Alternativ geht das auch im Kontextmenü der OctoGate Weboberfläche oder im Zertifikatsmanager unter dem Punkt "Netzwerke".
Wichtig für Kunden, die bisher auf OctoGate 3 Systemen gearbeitet haben:
Bitte tragen Sie dafür sorge, dass Sie das aktuellste OctoGate Zertifikat, gültig bis 2032, verwenden.
Zurück zum Contentfilter und Szenarien, die sich eher an die Praxis anlehnen.
Nehmen wir ein Szenario mit der OctoGate als eigenständigem Domänencontroller mit 242 Usern
inklusive Klassengruppen und Surfprofilen einer kleinen Schule.
Der Windows-Test-PC wird Mitglied dieser Domäne.
Die OctoGate übernimmt den DNS Dienst und bedient auch die Microsoft spezifischen Einträge für die Domain citest.local.
Das hier gezeigte Setup entstammt übrigens unseren Demodaten, welche jede OctoGate mitbringt und bei Bedarf installiert.
Nach einem Neustart des PCs und der Anmeldung als Domänen Administrator,
muss zunächst das Netzwerk INT0 auf Domain Authentifizierung umgeschaltet werden.
Bei diesem Protokoll (NTLM bzw. Kerberos) ist ein Proxy Pflicht.
Die OctoGate konfiguriert das automatisch und liefert clientindividuell die korrekte Proxy PAC aus.
Eine Userverifizierung geht am einfachsten über die URL "info.octogate.online".
Die Workstation und der angemeldete Benutzer wurden korrekt identifiziert
und einer Domain Benutzergruppe und einem Surfprofil zugeordnet.
Nun ordnen wir den Administrator, neben seinen bestehenden Gruppen, der Domain Gruppe "Verwaltung" zu.
An einer Nutzergruppe hängen immer zwei Profile.
Sein Sicherheitsprofil, das definiert, welche Seiten und Buttons der User in der Firewall sehen darf
und sein Surfprofil, das definiert welche Webseiten erlaubt oder verboten sein sollen.
In der Spalte "Priorität" legt man die Wichtigkeit der Gruppenzugehörigkeit eines Users fest.
Verwaltung wird für den Admin zur Toppriorität.
Ein Refresh der Info Page auf Client Seite bestätigt das.
Nun wenden wir uns dem Surfprofil des Users mit dem Namen "Lehrer" zu.
Es handelt sich um ein Positiv-Profil: "Alles erlaubt ausser" einer Liste von Blacklist Kategorien und einzelner Webseiten.
Wir fügen Nachrichten hinzu und probieren es aus.
Für das Netz INT0 haben wir "Freigabe beantragen" aktiviert.
Läuft ein User auf eine gesperrte Seite, kann er beim dafür zuständigen Nutzer eine Prüfung beantragen.
Wir testen das und klicken auf den Button.
Für eine Webseite gibt es immer nur einen Freigabeantrag.
Nachfolgende Sperrseiten der Nutzer bekommen den erwähnten Button nicht mehr zu sehen.
Im Weiteren kann man hier einstellen, ob die Freigabe zeitlich limitiert, lokal oder global erfolgen soll.
Gehen wir in unserem Szenario weiter davon aus, dass es in dem Kupfernetz INT0 nicht nur Windows PCs als Mitglied einer Domäne gibt,
sondern auch Drucker und Whiteboards, welche Zugang zum Internet benötigen.
Aktuell würde dies nie funktionieren,
da solche Geräte nicht zu einer Windows NTLM oder Kerberos Authentifizierung fähig sind.
Für solche Fälle gibt es bei der OctoGate die Hostgruppen –
eine nutzerdefinierte Sammlung von IPs, Subnetzen bzw. MAC Adressen, welche man beispielsweise dafür nutzen kann,
um im INT0-Netzwerk Ausnahmen zu definieren.
Diese überschreiben in diesem Fall für das gegebene Subnetz die AD-Authentifizierung beim Interface
und vergeben stattdessen für das definierte Subnetz fest eine Nutzergruppe und somit ein Surfprofil samt HTTPS-Scanningmethode.
Die Änderung ist sofort auf Clientseite sichtbar.
Der Windows PC ist nun Mitglied der Hostgruppe und erhält seine Surfprofilzuordnung nicht mehr von der Domäne.
Dennoch: Ein Single Sign On in die OctoGate Oberfläche funktioniert immer noch.
Als letzten Punkt stellen wir Ihnen den Surf-Simulator vor:
Ein Werkzeug zur Analyse von Surfprofileinstellungen und deren Auswirkungen.