Sophos Firewall Clientless Users einrichten und testen

Ein Drucker, Server oder anderes festes Gerät kann sich oft nicht an der Firewall anmelden. Clientless Users geben solchem Traffic trotzdem eine verständliche Identität: Sophos Firewall ordnet einen konfigurierten Benutzernamen der sichtbaren Quell-IP zu und kann diese Identität in Regeln, Live Users und Logs verwenden.

Das ist keine Authentifizierung. Wer die konfigurierte IP übernimmt oder hinter derselben NAT-Adresse erscheint, kann dieselbe Zuordnung erhalten. Clientless Users passen deshalb nur zu stabil adressierten und kontrollierten Geräten. Für wechselnde persönliche Geräte, gemeinsam genutzte IPs oder privilegierten Zugriff ist ein echtes Anmeldeverfahren die bessere Wahl.

⚠️ Clientless Users sind nicht Clientless SSL VPN. Clientless Users bilden intern eine IP auf eine Identität ab. Clientless SSL VPN veröffentlicht dagegen RDP-, SSH- oder File-Server-Bookmarks im VPN Portal.

Clientless User in acht Schritten

1. Gerät, Owner, benötigte Ziele und die auf der Firewall sichtbare Quell-IP festlegen.
2. Die Adresse statisch konfigurieren oder per DHCP-Reservation eindeutig binden.
3. Unter Authentication > Groups eine kleine Gruppe vom Typ Clientless anlegen.
4. Unter Authentication > Clientless users > Add genau einen Pilotbenutzer mit dieser IP erstellen.
5. Eine eigene, geloggte Firewall-Regel mit exakter Source, Match known users und der Clientless-Gruppe anlegen.
6. Den Benutzer unter Current activities > Live users sowie den echten Flow im Log Viewer prüfen.
7. Den Benutzer kurz auf Inactive setzen und bestätigen, dass die Identitätsregel nicht mehr greift.
8. Benutzer wieder aktivieren, Regel erneut abnehmen und Zuordnung, Owner und Review-Termin dokumentieren.

Wann Clientless Users passen

Clientless Users sind sinnvoll, wenn eine Firewall-Regel oder ein Report eine stabile Geräteidentität benötigt, das Gerät aber keinen Benutzerlogin ausführen kann. Typische Kandidaten sind Drucker, Monitoring-Appliances, Laborgeräte oder eng begrenzte Infrastrukturserver.

Die Funktion passt nur, wenn alle folgenden Punkte stimmen:

• Die Firewall sieht für den Traffic immer dieselbe eindeutige Quell-IP.
• Die Adresse ist statisch oder über eine kontrollierte DHCP-Reservation gebunden.
• Hinter der Adresse befinden sich nicht mehrere Geräte per NAT oder Proxy.
• Die Identität erhält nur die Ziele und Dienste, die das Gerät wirklich benötigt.
• Ein anderes Gerät kann die Adresse nicht unbemerkt übernehmen.
• Positiv- und Negativtest sind mit einem echten Datenflow möglich.

Für normale Domain-Clients ist STAS meist passender. Bei Netzwerkzugängen, die bereits RADIUS Accounting liefern, kann RADIUS SSO Accounting die Benutzer-IP-Zuordnung dynamisch aufbauen. Eine interaktive Anmeldung liefert das Captive Portal.

Clientless Users sind keine Abkürzung für eine fehlende Segmentierung. Ein Drucker gehört weiterhin in eine passende Zone oder ein eigenes Netz und erhält eine enge Regel. Die IP-basierte Identität ergänzt diese Kontrolle, ersetzt sie aber nicht.

Funktionsweise und Sicherheitsgrenze

Sophos Firewall führt einen aktiven Clientless User ohne interaktive Anmeldung als Live User. Matcht ein Paket die konfigurierte IP, steht der zugeordnete Benutzername für benutzerbasierte Regeln und Auswertungen zur Verfügung.

Dabei entsteht kein kryptografischer Beweis für Gerät oder Person:

• Es gibt kein Passwort und keinen zweiten Faktor.
• Die Zuordnung prüft keine persönliche Windows- oder Entra-Sitzung.
• Eine IP-Änderung wird nicht automatisch als Gerätewechsel verstanden.
• Eine gemeinsame NAT- oder Proxy-IP kann keine einzelnen Endgeräte unterscheiden.
• Ein Clientless User ist kein Remote-Access-VPN-Benutzer.

Wer personenbezogene Regeln braucht, sollte Clientless Users nur in gut kontrollierten Ausnahmefällen verwenden. Bei einem Menschen mit festem Arbeitsplatz muss die DHCP-Zuordnung stabil sein, trotzdem bleibt die Identität eine Aussage über die IP und nicht über die Person vor dem Bildschirm.

Beispiel und austauschbare Werte

Der Ablauf verwendet einen Drucker, der nur DNS, NTP und einen internen Printserver erreichen darf:

• Username: Printer-Accounting
• sichtbare IP-Adresse: 192.0.2.50
• Clientless-Gruppe: Clientless-Devices
• Firewall-Regel: Printer-Accounting_to_Services
• Source network: Hostobjekt Printer-Accounting_192.0.2.50
• Ziel: interner DNS-/NTP-Dienst und vorgesehener Printserver
• Review: Owner und nächster Prüfungstermin in der Regelbeschreibung

192.0.2.50 liegt im offiziellen IPv4-Dokumentationsbereich und ist keine produktive Geräteadresse. Der Wert muss durch die feste IP ersetzt werden, welche die Firewall beim echten Flow als Source sieht. Bei IPv6 braucht es eine feste IPv6-Adresse, eine eigene IPv6-Regel und eine getrennte Abnahme.

Die Beispielnamen zeigen den Zweck, sind aber keine Produktvorgabe. In einer realen Umgebung sollten Benutzer, Gruppe, Hostobjekt und Regel nach einem konsistenten Namensschema benannt werden.

Adresse und Gruppe vorbereiten

Sichtbare Quell-IP bestätigen

Vor der Identitätskonfiguration wird genau ein kontrollierter Datenflow vom Gerät erzeugt. Im Log Viewer oder Packet Capture sind mindestens Source IP, In interface, Ziel, Service und bisherige Firewall Rule ID festzuhalten.

Ist die sichtbare Source eine NAT-, Proxy- oder gemeinsame Gateway-Adresse, hier stoppen. Diese Adresse darf nicht einem einzelnen Clientless User zugeordnet werden. Sonst erhalten alle dahinterliegenden Geräte dieselbe Identität.

Bei DHCP wird eine Reservation für genau dieses Gerät angelegt. Eine freie Adresse aus dem Pool nur in der Firewall einzutragen reicht nicht: Wenn der DHCP-Server sie später einem anderen Client vergibt, übernimmt dieser die Identität und damit möglicherweise die Regelrechte.

Clientless-Gruppe anlegen

Unter Authentication > Groups > Add wird eine eigene Gruppe erstellt:

1. Als Name Clientless-Devices eintragen.
2. Als Group type Clientless wählen.
3. Nur die benötigten Gruppenrichtlinien setzen.
4. Mit Save speichern.

Benutzerspezifische Richtlinien haben Vorrang vor den Richtlinien der zugewiesenen Gruppe. Deshalb sollte die Gruppe einen verständlichen gemeinsamen Baseline-Zweck erhalten. Abweichungen am einzelnen Benutzer werden dokumentiert und separat getestet.

Clientless Users unterstützen keine Surfing quota, Access time oder Network traffic policy. Soll ein festes Gerät nur zu bestimmten Uhrzeiten kommunizieren, wird ein Schedule in der engen Firewall-Regel verwendet. Access Time für Benutzer und Gruppen gilt dagegen für normale Benutzer, Gruppen und Gastbenutzer. Auch Surfing Quota und Network Traffic Quota setzen eine unterstützte Benutzer- oder Gruppenzuweisung voraus.

Warum Normal, importierte Gruppen und Clientless unterschiedliche Identitätsmodelle sind, ordnet Sophos Firewall Benutzergruppen und Main Group richtig verwalten ein. Dieser Artikel bleibt beim vollständigen IP-basierten Clientless-Ablauf.

Einzelnen Clientless User anlegen

Unter Authentication > Clientless users > Add werden die Felder wie folgt gesetzt:

1. Username: Printer-Accounting
2. IP address: die feste, zuvor bestätigte Geräteadresse
3. Group: Clientless-Devices
4. Name: ein verständlicher Anzeigename des Geräts
5. Email: nur eine reale zuständige Adresse eintragen, wenn sie für Funktionen wie Quarantine Digest gebraucht wird
6. Quarantine digest: nur bewusst aktivieren; für einen normalen Drucker bleibt die Funktion meist aus
7. Mit Save speichern.

Danach lässt sich der Benutzer erneut öffnen und um unterstützte benutzerspezifische Einstellungen ergänzen. Eine Änderung wird erst als erfolgreich gewertet, wenn Live Users, Regelmatch und echter Traffic erneut stimmen.

Add range nur mit klarer Begründung

Authentication > Clientless users > Add range erzeugt für alle Adressen zwischen From IP und To IP eigene Clientless Users. Sophos weist die gewählte Gruppe zu; jeder erzeugte Benutzer kann danach einzeln bearbeitet werden.

Ein normaler DHCP-Pool ist dafür kein geeigneter Kandidat. Eine Range würde jede später vergebene Adresse vorab als bekannte Identität behandeln. Add range passt nur zu einem vollständig reservierten, dokumentierten Adressblock mit gleichartigem Zweck, kontrollierter Vergabe und anschliessender Einzelprüfung. Für den ersten Rollout bleibt Add mit genau einer IP die sichere Variante.

Enge Firewall-Regel erstellen

Die allgemeine Regelmechanik erklärt Sophos Firewall-Regeln verstehen und sicher konfigurieren. Für das Beispiel wird eine eigene Regel oberhalb einer allgemeineren Drucker- oder LAN-Regel angelegt:

• Rule name: Printer-Accounting_to_Services
• Action: Accept
• Log firewall traffic: aktiviert
• Source zone: die tatsächliche Gerätezone
• Source networks and devices: Printer-Accounting_192.0.2.50
• Destination zone: Zone der vorgesehenen Dienste
• Destination networks: nur DNS-/NTP-Ziel und Printserver
• Services: nur die benötigten Ports
• Match known users: aktiviert
• Users or groups: Clientless-Devices oder der einzelne Pilotbenutzer

Source-IP und Benutzerbedingung dürfen bewusst gemeinsam verwendet werden. Die IP begrenzt den technischen Ursprung, die Identität macht Regel und Reporting nachvollziehbar. Eine breite Source Any oder ein Ziel Any ist für ein festes Gerät nicht nötig.

Nach dem Speichern wird kontrolliert, dass keine allgemeinere Regel oberhalb greift. Welche Regel den realen Flow verarbeitet, zeigt nur die Firewall Rule ID im Log Viewer oder Packet Capture. Der geführte Ablauf steht unter Sophos Firewall-Regel testen.

Positiv- und Negativtest

Identität und erlaubten Flow prüfen

1. Unter Current activities > Live users nach Printer-Accounting und der erwarteten IP suchen.
2. Vom Gerät genau einen vorgesehenen Flow erzeugen.
3. Im Log Viewer Benutzer, Source IP, Firewall Rule ID, Rule name, Service und Action vergleichen.
4. Prüfen, ob das Ziel den Request erhält und der Rückweg funktioniert.
5. Einen nicht vorgesehenen Dienst oder ein nicht vorgesehenes Ziel testen und den erwarteten Drop bestätigen.

Die Live-User-Anzeige allein genügt nicht. Sie bestätigt die aktive Zuordnung, aber nicht die Regelposition, den erlaubten Dienst oder den Datenpfad.

Statuswechsel als Negativtest verwenden

Ein Clientless User wird nicht über Disconnect in Live Users abgemeldet. Unter Authentication > Clientless users wird der Pilotbenutzer ausgewählt und mit Change status auf Inactive gesetzt.

Danach darf er nicht mehr als Clientless User in Live Users erscheinen. Eine neue Testverbindung darf die benutzerbasierte Pilotregel nicht mehr mit dieser Identität matchen. Anschliessend wird der Benutzer wieder auf Active gesetzt und der Positivtest wiederholt.

Dieser Test darf nicht zu einem unerwarteten Allow über eine allgemeinere Regel führen. Wenn die Verbindung nach der Deaktivierung weiterhin erlaubt sein soll, muss die dafür vorgesehene Fallback-Regel bewusst dokumentiert und ebenfalls geprüft werden.

Fehler systematisch eingrenzen

Benutzer fehlt in Live Users

• Status unter Authentication > Clientless users auf Active prüfen.
• Konfigurierte IP mit der im Paket tatsächlich sichtbaren Source vergleichen.
• Nach doppeltem Username oder bereits verwendeter IP suchen.
• IPv4- und IPv6-Traffic getrennt betrachten.
• Bei sehr vielen Benutzer- und Gruppenobjekten die konkrete interne User ID prüfen. Das User-ID-Limit wird nicht anhand einer groben Objektzahl diagnostiziert.

Clientless Users sind nach aktueller SFOS-Hilfe direkt nach der Konfiguration als Live Users sichtbar. Ein Service-Restart, Datenbankeingriff oder wiederholtes Löschen und Neuerstellen gehört nicht zum normalen Einrichtungsweg.

Benutzer ist sichtbar, aber die falsche Regel greift

• Match known users, ausgewählten Benutzer oder Gruppe und Regelstatus prüfen.
• Source zone, Source network, Destination zone, Ziel und Service mit dem echten Flow vergleichen.
• Regelposition und eine allgemeinere Regel oberhalb kontrollieren.
• Im Log Viewer nicht nur nach dem Benutzernamen filtern, sondern Firewall Rule ID und Source IP vergleichen.
• Eine neue Verbindung erzeugen, weil bestehende Sessions nicht automatisch neu ausgewertet werden.

Die vertiefte Fehlerlogik steht unter Firewall-Regel matcht nicht.

Falsches Gerät erhält die Identität

Dann ist die IP-Zuordnung nicht ausreichend kontrolliert. DHCP-Lease, Reservation, statische Konfiguration, doppelte IP, NAT und Proxy prüfen. Die Regel wird deaktiviert oder der Clientless User auf Inactive gesetzt, bis eindeutig feststeht, welches Gerät die Source-Adresse verwendet.

Keine grössere Range anlegen, um wechselnde Adressen einzufangen. Das verbreitert die falsche Vertrauensannahme und erschwert die spätere Zuordnung.

QoS greift bei sehr vielen Clientless Users nicht

Sophos dokumentiert NC-148705 als in SFOS 22.0 MR1 Build 490 behoben: Bei mehr als 3000 Clientless Users wurde eine QoS Policy nicht angewendet. Die Release Notes nennen keine betroffene Versionsspanne.

Passt genau dieses Fehlerbild, werden Firmwareversion und Build gesichert und ein unterstütztes Update mindestens auf MR1 Build 490 beziehungsweise eine spätere kompatible Version geplant. Ein QoS-Problem bei weniger Benutzern oder auf einem anderen Build beweist NC-148705 nicht; dann sind Policy-Zuweisung, Regelmatch und Traffic Shaping normal zu prüfen.

Logs und HA einordnen

access_server.log enthält Authentifizierungs-, Autorisierungs- und Accounting-Ereignisse. Für den Datenflow bleiben Firewall-Log, Log Viewer und Packet Capture entscheidend. Die Logzuordnung erklärt Sophos Firewall Service-Logs.

In einem HA-Cluster werden Konfiguration und Betrieb auf dem aktuellen Primary durchgeführt. Sophos dokumentiert für Clientless Users keine Garantie, dass Live-User- oder Sessionzustände einen Failover unterbrechungsfrei überstehen. Nach einem kontrollierten Failover werden Clientless User, Regelmatch, echter Flow und die lokalen Logs des zum Ereigniszeitpunkt verarbeitenden Nodes erneut geprüft.

Betrieb und Rückbau

Jeder Clientless User braucht einen Owner, einen Zweck und einen Review-Termin. Bei Geräteersatz, Netzwechsel oder Aufgabe der Regel wird die Zuordnung nicht einfach liegen gelassen.

Der kontrollierte Rückbau:

1. Betroffene Regel, Gruppe, Reports und Traffic-Shaping-Abhängigkeiten dokumentieren.
2. Clientless User auf Inactive setzen.
3. Live-User-Status und echten Datenflow negativ prüfen.
4. Regel oder Benutzerbedingung auf den vorgesehenen Nachfolgezustand umstellen.
5. Nicht mehr benötigten Clientless User löschen.
6. Gruppe erst entfernen, wenn kein anderer Benutzer oder keine Policy sie mehr benötigt.
7. DHCP-Reservation, Hostobjekt und Dokumentation separat bereinigen.

Eine produktive Identität wird nicht während eines offenen Incidents gelöscht, bevor Source IP, Rule ID und Logs gesichert sind. Bei unklarer Zuordnung zuerst den Zugriff begrenzen und den Beweisstand erhalten.

FAQ