Konfigurera och testa Clientless Users på Sophos Firewall

En skrivare, server eller annan fast enhet kan ofta inte logga in på brandväggen. Clientless Users ger ändå sådan trafik en begriplig identitet: Sophos Firewall kopplar ett konfigurerat användarnamn till den synliga käll-IP-adressen och kan använda identiteten i regler, Live Users och loggar.

Detta är inte autentisering. Den som tar över den konfigurerade IP-adressen eller visas bakom samma NAT-adress kan få samma koppling. Clientless Users passar därför endast för enheter med stabila adresser som är under kontroll. För växlande personliga enheter, delade IP-adresser eller privilegierad åtkomst är en riktig inloggningsmetod ett bättre val.

⚠️ Clientless Users är inte Clientless SSL VPN. Clientless Users kopplar internt en IP-adress till en identitet. Clientless SSL VPN publicerar däremot RDP-, SSH- eller filserverbookmarks i VPN Portal.

Clientless User i åtta steg

1. Fastställ enheten, ägaren, nödvändiga mål och den käll-IP-adress som brandväggen ser.
2. Konfigurera adressen statiskt eller bind den entydigt med en DHCP-reservation.
3. Skapa en liten grupp av typen Clientless under Authentication > Groups.
4. Skapa exakt en pilotanvändare med denna IP under Authentication > Clientless users > Add.
5. Skapa en separat loggad brandväggsregel med exakt källa, Match known users och clientless-gruppen.
6. Kontrollera användaren under Current activities > Live users och det verkliga flödet i Log Viewer.
7. Sätt kortvarigt användaren till Inactive och bekräfta att identitetsregeln inte längre matchar.
8. Aktivera användaren igen, validera regeln på nytt och dokumentera kopplingen, ägaren och granskningsdatumet.

När Clientless Users passar

Clientless Users är användbart när en brandväggsregel eller rapport behöver en stabil enhetsidentitet men enheten inte kan utföra en användarinloggning. Vanliga kandidater är skrivare, övervakningsappliances, laboratorieutrustning eller strikt begränsade infrastrukturservrar.

Funktionen passar bara om samtliga följande punkter är uppfyllda:

• Brandväggen ser alltid samma entydiga käll-IP-adress för trafiken.
• Adressen är statisk eller bunden genom en kontrollerad DHCP-reservation.
• Adressen representerar inte flera enheter bakom NAT eller en proxy.
• Identiteten får bara åtkomst till de mål och tjänster som enheten verkligen behöver.
• En annan enhet kan inte ta över adressen utan att det upptäcks.
• Ett positivt och negativt test med ett verkligt dataflöde är möjligt.

För normala domänklienter passar STAS vanligtvis bättre. Om nätverksåtkomsten redan ger RADIUS Accounting kan RADIUS SSO Accounting bygga användar-IP-kopplingen dynamiskt. Captive Portal erbjuder en interaktiv inloggning.

Clientless Users är ingen genväg för att ersätta saknad segmentering. En skrivare hör fortfarande hemma i en lämplig zon eller ett separat nät och behöver en snäv regel. Den IP-baserade identiteten kompletterar kontrollen men ersätter den inte.

Funktion och säkerhetsgräns

Sophos Firewall visar en aktiv Clientless User som Live User utan interaktiv inloggning. När ett paket matchar den konfigurerade IP-adressen blir det kopplade användarnamnet tillgängligt för användarbaserade regler och rapportering.

Detta ger inget kryptografiskt bevis för enheten eller personen:

• Det finns inget lösenord och ingen andra autentiseringsfaktor.
• Kopplingen verifierar ingen personlig Windows- eller Entra-session.
• En IP-ändring tolkas inte automatiskt som ett enhetsbyte.
• En delad NAT- eller proxy-IP kan inte skilja på enskilda endpoints.
• En Clientless User är inte en Remote Access VPN-användare.

Om personbaserade regler krävs bör Clientless Users endast användas i välkontrollerade undantagsfall. För en person med en fast arbetsplats måste DHCP-kopplingen vara stabil, men identiteten beskriver fortfarande IP-adressen och inte personen framför skärmen.

Exempel och utbytbara värden

Proceduren använder en skrivare som endast får nå DNS, NTP och en intern utskriftsserver:

• Username: Printer-Accounting
• synlig IP-adress: 192.0.2.50
• clientless-grupp: Clientless-Devices
• brandväggsregel: Printer-Accounting_to_Services
• Source network: hostobjekt Printer-Accounting_192.0.2.50
• mål: intern DNS-/NTP-tjänst och avsedd utskriftsserver
• granskning: ägare och nästa granskningsdatum i regelbeskrivningen

192.0.2.50 tillhör det officiella IPv4-dokumentationsintervallet och är inte en produktionsadress. Ersätt den med den fasta IP-adress som brandväggen ser som källa för det verkliga flödet. För IPv6 krävs en fast IPv6-adress, en separat IPv6-regel och en separat validering.

Exempelnamnen visar syftet men är inga produktkrav. I en verklig miljö bör användaren, gruppen, hostobjektet och regeln namnges enligt ett konsekvent namnschema.

Förbered adress och grupp

Bekräfta den synliga käll-IP-adressen

Skapa exakt ett kontrollerat dataflöde från enheten innan identiteten konfigureras. Dokumentera minst Source IP, In interface, mål, tjänst och tidigare Firewall Rule ID i Log Viewer eller Packet Capture.

Stoppa här om den synliga källan är en NAT-, proxy- eller delad gatewayadress. Koppla inte denna adress till en enskild Clientless User. Annars får alla enheter bakom den samma identitet.

Skapa vid DHCP en reservation för just denna enhet. Det räcker inte att bara ange en ledig adress från poolen i brandväggen: Om DHCP-servern senare tilldelar den till en annan klient ärver klienten identiteten och eventuellt regelbehörigheterna.

Skapa en clientless-grupp

Skapa en separat grupp under Authentication > Groups > Add:

1. Ange Clientless-Devices som Name.
2. Välj Clientless som Group type.
3. Ställ bara in nödvändiga gruppolicies.
4. Spara med Save.

Användarspecifika policies har företräde framför den tilldelade gruppens policies. Gruppen bör därför ha ett tydligt gemensamt grundsyfte. Avvikelser för en enskild användare dokumenteras och testas separat.

Clientless Users stöder inte Surfing quota, Access time eller Network traffic policy. Om en fast enhet bara ska kommunicera under vissa tider används ett Schedule i den snävt avgränsade firewallregeln. Access Time för användare och grupper gäller däremot vanliga användare, grupper och gästanvändare. Surfing Quota och Network Traffic Quota kräver också en stödd användar- eller grupptilldelning.

Hantera användargrupper och huvudgruppen korrekt i Sophos Firewall förklarar varför Normal, importerade och Clientless-grupper representerar olika identitetsmodeller. Den här artikeln fokuserar fortsatt på hela det IP-baserade Clientless-flödet.

Lägg till en enskild Clientless User

Ställ in fälten så här under Authentication > Clientless users > Add:

1. Username: Printer-Accounting
2. IP address: den fasta enhetsadress som bekräftats tidigare
3. Group: Clientless-Devices
4. Name: ett begripligt visningsnamn för enheten
5. Email: ange bara en verklig adress till den ansvariga om den behövs för funktioner som Quarantine Digest
6. Quarantine digest: aktivera bara medvetet; för en vanlig skrivare är funktionen normalt avstängd
7. Spara med Save.

Därefter kan användaren öppnas igen och kompletteras med understödda användarspecifika inställningar. En ändring betraktas först som lyckad när Live Users, regelmatchningen och den verkliga trafiken åter stämmer.

Använd Add range endast med tydlig motivering

Authentication > Clientless users > Add range skapar enskilda Clientless Users för alla adresser mellan From IP och To IP. Sophos tilldelar den valda gruppen och varje skapad användare kan därefter redigeras separat.

En vanlig DHCP-pool är inte lämplig. Ett intervall skulle i förväg behandla varje senare tilldelad adress som en känd identitet. Add range passar bara för ett helt reserverat och dokumenterat adressblock med samma syfte, kontrollerad tilldelning och efterföljande individuell kontroll. För den första utrullningen är Add med exakt en IP fortfarande det säkra alternativet.

Skapa en snäv brandväggsregel

Förstå och konfigurera Sophos Firewall-regler säkert förklarar den allmänna regellogiken. Skapa för exemplet en separat regel ovanför en mer generell skrivar- eller LAN-regel:

• Rule name: Printer-Accounting_to_Services
• Action: Accept
• Log firewall traffic: aktiverat
• Source zone: enhetens verkliga zon
• Source networks and devices: Printer-Accounting_192.0.2.50
• Destination zone: zonen för de avsedda tjänsterna
• Destination networks: endast DNS-/NTP-målet och utskriftsservern
• Services: endast nödvändiga portar
• Match known users: aktiverat
• Users or groups: Clientless-Devices eller den enskilda pilotanvändaren

Käll-IP-adressen och användarvillkoret kan medvetet användas tillsammans. IP-adressen begränsar det tekniska ursprunget, medan identiteten gör regeln och rapporteringen begriplig. En bred källa Any eller destination Any behövs inte för en fast enhet.

Kontrollera efter att regeln sparats att ingen mer generell regel ovanför matchar först. Endast Firewall Rule ID i Log Viewer eller Packet Capture visar vilken regel som bearbetar det verkliga flödet. Testa en Sophos Firewall-regel ger den vägledda proceduren.

Positivt och negativt test

Kontrollera identitet och tillåtet flöde

1. Sök efter Printer-Accounting och förväntad IP under Current activities > Live users.
2. Skapa exakt ett avsett flöde från enheten.
3. Jämför användare, Source IP, Firewall Rule ID, regelnamn, tjänst och action i Log Viewer.
4. Kontrollera att målet tar emot förfrågan och att returvägen fungerar.
5. Testa en tjänst eller ett mål som inte är avsett och bekräfta förväntad drop.

Posten i Live Users räcker inte i sig. Den bekräftar den aktiva kopplingen men inte regelpositionen, tillåten tjänst eller datavägen.

Använd statusändring som negativt test

Logga inte ut en Clientless User med Disconnect i Live Users. Välj pilotanvändaren under Authentication > Clientless users och använd Change status för att sätta den till Inactive.

Användaren får därefter inte längre visas som Clientless User i Live Users. En ny testanslutning får inte heller längre matcha den användarbaserade pilotregeln med denna identitet. Sätt sedan användaren till Active igen och upprepa det positiva testet.

Testet får inte leda till en oväntad allow genom en mer generell regel. Om anslutningen ska fortsätta vara tillåten efter inaktivering måste den avsedda fallbackregeln dokumenteras och också testas medvetet.

Felsök systematiskt

Användaren saknas i Live Users

• Kontrollera att status under Authentication > Clientless users är Active.
• Jämför konfigurerad IP med källan som faktiskt syns i paketet.
• Sök efter ett duplicerat Username eller en IP som redan används.
• Granska IPv4- och IPv6-trafik separat.
• Kontrollera det konkreta interna User ID-värdet om det finns många användar- och gruppobjekt. User ID-gränsen diagnostiseras inte utifrån en grov objekträkning.

Enligt den aktuella SFOS-hjälpen syns Clientless Users som Live Users direkt efter konfigurationen. En omstart av tjänsten, ett databasingrepp eller upprepade borttagningar och återskapanden ingår inte i den normala konfigurationsvägen.

Användaren syns, men fel regel matchar

• Kontrollera Match known users, vald användare eller grupp och regelstatus.
• Jämför Source zone, Source network, Destination zone, mål och tjänst med det verkliga flödet.
• Kontrollera regelpositionen och en mer generell regel ovanför.
• Filtrera inte bara på användarnamnet i Log Viewer; jämför även Firewall Rule ID och Source IP.
• Skapa en ny anslutning eftersom befintliga sessioner inte utvärderas automatiskt på nytt.

Brandväggsregeln matchar inte ger den fördjupade felsökningslogiken.

Fel enhet får identiteten

IP-kopplingen är inte tillräckligt kontrollerad. Kontrollera DHCP-lease, reservation, statisk konfiguration, duplicerad IP, NAT och proxy. Inaktivera regeln eller sätt Clientless User till Inactive tills det är klarlagt vilken enhet som använder källadressen.

Skapa inte ett större intervall för att fånga växlande adresser. Det breddar det felaktiga tillitsantagandet och försvårar senare attribuering.

QoS tillämpas inte vid många Clientless Users

Sophos dokumenterar NC-148705 som åtgärdat i SFOS 22.0 MR1 Build 490: En QoS Policy tillämpades inte när antalet Clientless Users översteg 3000. Release notes anger inget intervall med berörda versioner.

Om exakt denna symptombild stämmer ska firmwareversion och build dokumenteras och en stödd uppdatering till minst MR1 Build 490 eller en senare kompatibel version planeras. Ett QoS-problem med färre användare eller på en annan build bevisar inte NC-148705; kontrollera policytilldelning, regelmatchning och Traffic Shaping på normalt sätt.

Tolka loggar och HA

access_server.log innehåller autentiserings-, auktoriserings- och accountinghändelser. För dataflödet är brandväggsloggen, Log Viewer och Packet Capture fortfarande avgörande. Sophos Firewall-serviceloggar förklarar loggtilldelningen.

I ett HA-kluster utförs konfiguration och drift på aktuell Primary. Sophos dokumenterar ingen garanti för att Live Users- eller sessionstillstånd för Clientless Users överlever en failover utan avbrott. Efter en kontrollerad failover kontrolleras Clientless User, regelmatchning, verkligt flöde och lokala loggar på den nod som bearbetade händelsen på nytt.

Drift och rollback

Varje Clientless User behöver en ägare, ett syfte och ett granskningsdatum. När en enhet byts ut, flyttas till ett annat nät eller inte längre behöver regeln får kopplingen inte bara ligga kvar.

Kontrollerad rollback:

1. Dokumentera berörd regel, grupp, rapporter och Traffic Shaping-beroenden.
2. Sätt Clientless User till Inactive.
3. Testa Live Users-statusen och det verkliga dataflödet negativt.
4. Ändra regeln eller användarvillkoret till avsett efterföljande tillstånd.
5. Ta bort Clientless User när den inte längre behövs.
6. Ta bort gruppen först när ingen annan användare eller policy behöver den.
7. Rensa DHCP-reservation, hostobjekt och dokumentation separat.

Ta inte bort en produktionsidentitet under en pågående incident innan Source IP, Rule ID och loggar har säkrats. Begränsa först åtkomsten och bevara bevisen om kopplingen är oklar.

FAQ