Sophos Firewall Surfing und Network Traffic Quota einrichten

Mit einer Surfing Quota begrenzt man die nutzbare Internetzeit eines authentifizierten Benutzers. Eine Network Traffic Quota begrenzt dagegen die übertragene Datenmenge. Beide Policies werden einem Benutzer oder einer Gruppe zugewiesen und eignen sich beispielsweise für Schulungsräume, Gäste oder klar definierte Nutzungspakete.

Für zeitlich begrenzte Gäste werden Kontoerstellung, Gültigkeit, Captive Portal und Bereinigung separat geplant. Der vollständige Lifecycle steht unter Gastbenutzer auf Sophos Firewall erstellen und sicher betreiben; dieser Artikel konzentriert sich auf die Kontingente.

Der Kurzweg für eine kontrollierte Einführung lautet:

1. Festlegen, ob Zeitverbrauch, Datenmenge oder beides begrenzt werden soll.
2. Unter Profiles > Surfing quota beziehungsweise Profiles > Network traffic quota eine neue Pilot-Policy erstellen.
3. Die Policy unter Authentication > Groups einer kleinen Pilotgruppe oder unter Authentication > Users einem einzelnen Testbenutzer zuweisen.
4. Benutzer neu authentifizieren und unter Current activities > Live users die erkannte Identität prüfen.
5. Eine benutzerbasierte Firewall-Regel mit Log firewall traffic für den Test verwenden.
6. Unter Authentication > Users den Benutzer öffnen und mit View usage den Verbrauch kontrollieren.
7. Grenze, erneuten Zyklus und Rollback testen, bevor weitere Benutzer aufgenommen werden.

⚠️ Reset user accounting setzt sowohl verbrauchte Surfing-Zeit als auch Network-Traffic-Zähler zurück. Das ist eine Zustandsänderung und kein allgemeiner Diagnoseknopf. Vor einem Reset werden Benutzer, aktuelle Werte, Zeitpunkt und Grund dokumentiert. Eine produktiv gemeinsam verwendete Quota wird ebenfalls nicht direkt verändert; für Tests verwendet man eine separate Pilot-Policy.

Welche Funktion zur Anforderung passt

Vier ähnlich klingende Funktionen lösen unterschiedliche Aufgaben:

• Access Time erlaubt oder sperrt Benutzer während festen Uhrzeitfenstern. Sie zählt keinen Verbrauch.
• Surfing Quota gibt einem Benutzer ein konsumierbares Zeitkontingent für Internetzugriff.
• Network Traffic Quota gibt einem Benutzer ein konsumierbares Datenkontingent.
• Traffic Shaping begrenzt oder priorisiert Bandbreite. Eine niedrige Datenrate ist keine Datenquote.

Daneben gibt es in einer Web Policy die Aktion Quota für zeitlich begrenzten Zugriff auf bestimmte Webkategorien. Diese Policy Quota gehört zur Web-Proxy-Logik und ist nicht dieselbe Funktion wie die benutzerbezogene Surfing Quota dieses Artikels.

Eine Quota erstellt weder eine Firewall-Regel noch eine Benutzeridentität. Die Firewall muss den Benutzer erkennen, der Netzwerkpfad muss erlaubt sein und der Testtraffic muss die erwartete Regel treffen. Erst dann lässt sich die Quota sinnvoll prüfen.

Beispiel und Voraussetzungen planen

Das durchgängige Beispiel verwendet eine kleine Pilotgruppe mit zwei getrennten Policies:

• Gruppe: Quota_Pilot
• Testbenutzer: quota-pilot
• Surfing Quota: Students_InternetTime
• Cycle type: Cyclic (repeat access)
• Cycle hours: 24
• Maximum access time: 02:00
• Network Traffic Quota: Students_DataVolume
• Restriction: Total network traffic
• Cycle type: Cyclic
• Cycle period: Day
• Quota per cycle: 5000 MB
• Maximum quota: Unlimited

Die Werte sind bewusst kleine Dokumentationsbeispiele: pro 24-Stunden-Zyklus stehen zwei Stunden Internetzeit und pro Tag 5000 MB Datenvolumen zur Verfügung. Namen, Zeit, Datenmenge, Zyklus und Gesamtgrenze werden an die tatsächliche Nutzungsvereinbarung angepasst. Für eine reine Produktionspolicy darf man keine kleinen Testgrenzen übernehmen, ohne deren Auswirkung zu prüfen.

Vor der Konfiguration werden diese Punkte kontrolliert:

1. Der Pilotbenutzer kann sich mit der vorgesehenen Authentifizierungsmethode anmelden.
2. Unter Current activities > Live users erscheinen Benutzername und Quelladresse.
3. Unter Authentication > Users stimmt bei AD-Benutzern das Feld Group.
4. Eine passende benutzerbasierte Firewall-Regel erlaubt den Testverkehr und hat Log firewall traffic aktiviert.
5. Bestehende Surfing-, Network-Traffic-, Access-Time- und Traffic-Shaping-Zuweisungen sind dokumentiert.
6. Der vorherige Zustand und ein alternativer Testbenutzer sind bekannt.

Ist der Benutzer nicht als Live User sichtbar, wird zuerst die Authentifizierung korrigiert. Eine Quota kann unbekannten oder nur IP-basiert behandelten Traffic nicht zuverlässig einem normalen Benutzerkontingent zuordnen.

Surfing Quota erstellen

Eine Surfing Quota zählt konsumierte Internetzeit. In der SFOS-22-Hilfe ist dasselbe Objekt sowohl unter Profiles > Surfing quota als auch unter Web > Surfing quotas dokumentiert. Verwendet wird der Einstieg, den der eingesetzte Build in WebAdmin zeigt.

Cyclic oder Non-cyclic wählen

• Cyclic (repeat access): Das Zeitkontingent wird in wiederkehrenden Zyklen neu bereitgestellt. Ungenutzte Zeit wird nicht in den nächsten Zyklus übertragen.
• Non-cyclic (one-time access): Das Zeitkontingent gilt einmalig. Nach dem Verbrauch wird der Benutzer getrennt.

Zusätzlich begrenzt Validity period, wie viele Tage die Policy gültig ist. Maximum access time legt die nutzbare Zeit fest. Ist das Maximum erreicht, wird der Benutzer auch dann getrennt, wenn die Gültigkeitsdauer noch nicht abgelaufen ist.

Für das Pilotbeispiel:

1. Profiles > Surfing quota > Add öffnen. Falls der Build die Funktion unter Web > Surfing quotas zeigt, dort Add auswählen.
2. Name auf Students_InternetTime setzen.
3. Als Description beispielsweise Pilot: 2h per 24h, Owner IT eintragen.
4. Cycle type auf Cyclic (repeat access) setzen.
5. Cycle hours auf 24 setzen.
6. Validity period für den Pilot bewusst festlegen oder Unlimited nur wählen, wenn keine Ablaufgrenze benötigt wird.
7. Maximum access time auf 02:00 setzen.
8. Mit Save speichern.

Die gespeicherte Policy wirkt noch nicht. Erst die Zuweisung an einen Benutzer oder eine Gruppe verbindet das Zeitkontingent mit einer Identität.

Network Traffic Quota erstellen

Eine Network Traffic Quota zählt die übertragene Datenmenge. Sie begrenzt nicht die Geschwindigkeit. Ein Benutzer kann sein Kontingent deshalb schnell oder langsam verbrauchen; für ein Bandbreitenlimit wird zusätzlich eine passende Traffic-Shaping-Policy geplant.

Gesamtverkehr oder Upload und Download getrennt begrenzen

• Total network traffic: Ein gemeinsames Kontingent zählt Upload und Download zusammen.
• Individual network traffic (Upload & download): Upload und Download erhalten getrennte Grenzen. Das passt nur, wenn die Anforderung diese Richtungen wirklich getrennt behandelt.

Auch hier gibt es zwei Zyklusmodelle:

• Cyclic: Das Kontingent gilt pro ausgewähltem Zyklus. Verfügbar sind Day, Week, Month oder Year. Ungenutzte Datenmenge wird nicht übertragen.
• Non-cyclic: Das Kontingent gilt für einen einzelnen Zykluszeitraum.

Quota per cycle bestimmt das Kontingent pro Zyklus. Eine optionale Maximum quota setzt zusätzlich eine Gesamtgrenze und muss höher sein als die Zyklusquote. Wird die Zyklus- oder Gesamtgrenze ausgeschöpft, trennt die Firewall den Benutzer. Für eine erneute Verbindung vor dem regulären Reset ist Reset user accounting nötig.

Für das Pilotbeispiel:

1. Profiles > Network traffic quota > Add öffnen.
2. Name auf Students_DataVolume setzen.
3. Als Description beispielsweise Pilot: 5000 MB per day, Owner IT eintragen.
4. Restriction auf Total network traffic setzen.
5. Cycle type auf Cyclic setzen.
6. Cycle period auf Day setzen.
7. Quota per cycle auf 5000 MB setzen.
8. Maximum quota für dieses wiederkehrende Beispiel auf Unlimited lassen. Wird eine Gesamtgrenze benötigt, muss sie oberhalb der Zyklusquote liegen.
9. Mit Save speichern.

5000 MB entspricht im Beispiel 5 GB. In einer realen Policy wird die Zahl aus dem genehmigten Kontingent abgeleitet und in der von WebAdmin erwarteten Einheit eingetragen. Eine getrennte Upload-/Download-Policy erhält dagegen für beide Richtungen eigene begründete Werte.

Quoten einer Gruppe oder einem Benutzer zuweisen

Gruppe als normalen Betriebsweg verwenden

Für Benutzer mit demselben Kontingent ist eine Gruppen-Policy leichter zu betreiben als viele Einzelwerte:

1. Authentication > Groups öffnen.
2. Die Gruppe Quota_Pilot erstellen oder eine klar abgegrenzte Pilotgruppe bearbeiten.
3. Bei Surfing quota Students_InternetTime auswählen.
4. Bei Network traffic Students_DataVolume auswählen.
5. Andere Access-Time-, Traffic-Shaping-, Remote-Access- oder Portalwerte nicht beiläufig ändern.
6. Speichern.
7. Den Pilotbenutzer neu authentifizieren und die tatsächlich verwendete Gruppe kontrollieren.

Wie lokale und importierte Gruppen, Main Group und Benutzer-Overrides zusammenspielen, erklärt Sophos Firewall Benutzergruppen sicher verwalten. Der eigentliche AD-Import bleibt im Ablauf Active Directory mit Sophos Firewall verbinden.

Benutzer-Override hat Vorrang

Unter Authentication > Users können Surfing quota und Network traffic für einen einzelnen Benutzer abweichend gesetzt werden. Diese Benutzerwerte haben Vorrang vor der Gruppen-Policy.

Wenn eine Gruppenänderung nur bei einem Benutzer nicht greift, wird deshalb zuerst dessen Benutzerobjekt geprüft. Ein Override eignet sich für eine dokumentierte Ausnahme oder einen Pilot, kann aber langfristig versteckte Sonderfälle erzeugen. Soll wieder die Gruppen-Policy gelten, wird der Benutzer kontrolliert auf den vorherigen Vererbungszustand zurückgesetzt.

Bei Active Directory zählt nur die Main Group

Surfing Quota und Network Traffic verwenden bei AD-Benutzern keine Other group memberships. Es gilt die Main Group, die unter Authentication > Users im Feld Group erscheint, oder eine explizite Benutzer-Policy.

Die Reihenfolge unter Authentication > Groups > Reorder kann die Main Group verändern und damit mehrere Policies gleichzeitig beeinflussen. Sie wird deshalb nicht als schneller Quota-Fix verschoben. Nach einer geplanten Gruppenänderung wird der Benutzer neu authentifiziert und die Main Group erneut geprüft.

Clientless Users sind ausgeschlossen

Clientless Users unterstützen weder Surfing Quota noch Network Traffic. Für ein festes Gerät ohne Benutzeranmeldung werden Netzwerkpfad, Schedule und gegebenenfalls Traffic Shaping in einer engen Firewall-Regel geplant. Die Benutzerquoten werden nicht als IP-basierter Ersatz verwendet.

Verbrauch prüfen und Grenze abnehmen

View usage in WebAdmin

Für die Verbrauchsanzeige benötigt Sophos eine benutzerbasierte Firewall-Regel mit aktiviertem Log firewall traffic. Danach:

1. Den Pilotbenutzer neu authentifizieren.
2. Unter Current activities > Live users Benutzername und Quelladresse kontrollieren.
3. Authentication > Users öffnen und den Pilotbenutzer auswählen.
4. View usage öffnen.
5. Bei Surfing Quota zugewiesene Zeit, Ablauf und verbrauchte Internetzeit prüfen.
6. Bei Network Traffic Cycle renewal, Upload, Download und zugewiesene Quota prüfen.
7. Einen kleinen erlaubten Testtransfer erzeugen und die Änderung erneut kontrollieren.
8. Im Log Viewer Benutzer, Source, Destination, Service, Firewall Rule ID, Action und Zeitstempel abgleichen.

Die Monatsansicht zeigt zusätzlich Quell-IP, Start, Stop, Dauer sowie Upload und Download. Ein Verbrauchswert allein beweist jedoch noch nicht, dass der vorgesehene Pfad und die richtige Regel verwendet wurden. Deshalb gehören View usage, Log Viewer und ein echter Testfluss zusammen. Die Regelabnahme erklärt Sophos Firewall-Regel sauber testen.

Benutzerkontrolle im User Portal

Im User Portal kann ein Benutzer unter Internet usage je nach Kontotyp und Policy die zugewiesene und verbrauchte Surfing-Zeit, die Zykluserneuerung sowie Upload-, Download- und Restkontingent prüfen. Das reduziert Rückfragen, ersetzt aber nicht die Admin-Abnahme von Zuweisung, Main Group, Regel und Logs.

Verbrauchsgrenze kontrolliert testen

Für einen Grenztest wird eine separate Pilot-Policy mit bewusst kleinem, aber ausreichendem Kontingent verwendet. Der Test darf keine produktive Gruppe treffen.

1. Ausgangswerte in View usage dokumentieren.
2. Einen klar begrenzten HTTP- oder HTTPS-Testfluss starten.
3. Verbrauch und Log Viewer während des Tests beobachten.
4. Das Erreichen der Grenze und die erwartete Trennung bestätigen.
5. Nicht von einer sekundengenauen Umschaltung ausgehen; die Firewall prüft Autorisierung periodisch.
6. Den nächsten regulären Zyklus oder einen ausdrücklich genehmigten Reset prüfen.
7. Pilot-Policy und vorherige Zuweisung danach zurücksetzen.

Reset user accounting sicher verwenden

Reset user accounting setzt Surfing-Zeit und Network-Traffic-Verbrauch des Benutzers zurück. Bei einer ausgeschöpften Network Traffic Quota ist dieser Reset nötig, wenn der Benutzer vor dem nächsten regulären Zyklus wieder verbunden werden soll.

Ein kontrollierter Reset lautet:

1. Benutzer, Ticket, Grund, aktuelle Quotenwerte und Zeitpunkt dokumentieren.
2. Prüfen, ob der reguläre Zykluswechsel abgewartet werden kann.
3. Sicherstellen, dass wirklich der richtige Benutzer ausgewählt ist.
4. Unter Authentication > Users den Benutzer öffnen.
5. View usage aufrufen und die Ausgangswerte sichern.
6. Reset user accounting nur mit der vorgesehenen Freigabe auslösen.
7. Benutzer neu authentifizieren und die neuen Zähler kontrollieren.
8. Einen kleinen Testfluss sowie Firewall Rule ID und Logs prüfen.

Der Reset korrigiert keine falsche Main Group, keine fehlende Benutzererkennung und keine blockierende Firewall- oder Web-Policy. Werden diese Ursachen nicht vorher geklärt, kehrt das Problem trotz zurückgesetztem Zähler zurück.

Fehler systematisch eingrenzen

Quota wird scheinbar nicht gezählt

Zuerst unter Current activities > Live users prüfen, ob die erwartete Identität und Quelladresse sichtbar sind. Danach kontrollieren, ob der Traffic eine benutzerbasierte Firewall-Regel mit Log firewall traffic trifft. Fehlt Logging oder läuft der Flow über eine andere Regel, kann View usage unvollständig bleiben.

Anschliessend Gruppen-Policy, Benutzer-Override und bei AD die Main Group vergleichen. Die Quota wird nicht vorschnell kleiner gesetzt, nur um eine Wirkung zu erzwingen.

Gruppen-Quota wirkt nur bei einzelnen Benutzern

Eine explizite Policy am Benutzer hat Vorrang. Unter Authentication > Users beide Quotenfelder und die Main Group prüfen. Bei AD werden Other group memberships nicht ausgewertet. Nach einer Gruppenänderung den Benutzer neu authentifizieren.

Benutzer wird unerwartet getrennt

Unter View usage prüfen, ob Cycle quota, Maximum quota oder Maximum access time erreicht wurde. Danach Access Time, Web Policy, Firewall-Regel und Authentifizierung getrennt kontrollieren. Ein Captive Portal kann auch bei falschen Credentials oder anderen Authentifizierungsproblemen erscheinen; die Quota ist nicht automatisch die Ursache. Den vollständigen Anmeldepfad erklärt Sophos Firewall Captive Portal einrichten und testen.

Verbrauch passt nicht zur Erwartung

Prüfen, ob Total network traffic oder getrennte Upload-/Download-Grenzen konfiguriert sind. Danach Monatsdetails, Quell-IP, Firewall Rule ID und den tatsächlichen Testtransfer vergleichen. Eine Network Traffic Quota zählt Datenmenge, nicht nur sichtbare Browserdownloads; Hintergrundverkehr des authentifizierten Benutzers kann ebenfalls zum Verbrauch beitragen.

Reset hilft nur kurzfristig

Wenn der Benutzer nach dem Reset schnell wieder getrennt wird, werden Policy-Werte, Zyklus, Maximum, Benutzer-Override und tatsächlicher Verbrauch geprüft. Der Zähler wird nicht wiederholt zurückgesetzt, bevor die Ursache verstanden ist.

Rollback und Betrieb

Ein kontrollierter Rückweg stellt den vorherigen Vererbungs- und Zählerzustand nachvollziehbar wieder her:

1. Vorherige Surfing- und Network-Traffic-Zuweisung für Pilotbenutzer oder Pilotgruppe wiederherstellen.
2. Bei AD den Benutzer neu authentifizieren und die Main Group prüfen.
3. View usage und den aktuellen Verbrauch dokumentieren.
4. Nur falls für den Test vereinbart, das Accounting kontrolliert zurücksetzen.
5. Einen kleinen Testfluss ausführen und Firewall Rule ID sowie Logs kontrollieren.
6. Pilot-Policies erst entfernen, wenn keine Benutzer- oder Gruppenabhängigkeit mehr besteht.
7. Ticket, Owner, Grenzwerte und Testergebnis aktualisieren.

Im Betrieb braucht jede gemeinsam verwendete Quota einen verständlichen Namen, eine Description, einen Owner und eine dokumentierte Begründung für Zyklus, Kontingent und Gesamtgrenze. Änderungen werden mit Pilotbenutzer, positivem Verbrauchstest und negativem Grenztest abgenommen.

Betriebscheckliste

• Zeitverbrauch und Datenverbrauch wurden getrennt geplant.
• Surfing Quota und Network Traffic Quota haben verständliche Namen und Owner.
• Zyklus, Validity, Quota per cycle und Maximum sind begründet.
• Die Policies sind der richtigen Gruppe oder dem richtigen Benutzer zugewiesen.
• Benutzer-Overrides wurden geprüft.
• Bei AD stimmt die Main Group; Other group memberships werden nicht vorausgesetzt.
• Clientless Users werden nicht mit Benutzerquoten geplant.
• Der Pilotbenutzer erscheint als Live User.
• Die benutzerbasierte Firewall-Regel protokolliert den Testtraffic.
• View usage, User Portal, Firewall Rule ID und echter Verbrauch passen zusammen.
• Reset user accounting wird nur dokumentiert und freigegeben verwendet.
• Vorheriger Zustand und Rollback sind dokumentiert.

Häufige Fragen