Skapa och hantera lokala användare på Sophos Firewall

En lokal användare lagras direkt på Sophos Firewall och autentiseras mot den lokala användardatabasen. Det passar för små miljöer, pilotkonton, enskilda externa medarbetare eller en medvetet underhållen reservåtkomst. Att skapa kontot ger dock inte i sig någon åtkomst. Grupp, autentiseringsmetod, portal eller klient, brandväggs- eller VPN-policy och den efterföljande kontrollen måste passa ihop.

Den säkra korta vägen är:

1. Fastställ användningsfall, målgrupp och nödvändig tjänst.
2. Förbered en restriktiv grupp av typen Normal under Authentication > Groups.
3. Ange ett permanent användarnamn under Authentication > Users > Add och välj User type: User.
4. Tilldela ett individuellt starkt lösenord och rätt grupp.
5. Lämna policyfälten på användaren oförändrade om gruppens värden ska gälla.
6. Begränsa Simultaneous sign-ins och Sign-in restriction medvetet.
7. Kontrollera under Authentication > Services att Local är valt för den tjänst som används.
8. Konfigurera portal, användarregel eller Remote Access-policy separat och så snävt som möjligt.
9. Testa en positiv och en negativ inloggning samt verklig trafik med ett pilotkonto.
10. Aktivera först därefter MFA, skapa fler användare och dokumentera avvecklingen.

⚠️ Användarnamnet kan inte ändras senare. Därför fastställs namnstandard, kontotyp och ansvar innan kontot sparas. Ett nytt konto med ett annat namn skapar en ny identitet och kan dela upp regler, kvoter, VPN-tilldelningar, loggar och granskningsspår.

När en lokal användare passar

Lokala användare kräver varken Active Directory eller en extern RADIUS- eller LDAP-server. Det gör dem enkla, men flyttar all hantering av lösenord, MFA, grupper, inaktivering och granskning till brandväggen. Det är praktiskt för några få medvetet hanterade konton. Vid många medarbetare eller frekventa in- och utträden är en central katalog vanligtvis lättare att underhålla.

En normal lokal användare passar till exempel för:

• ett pilotkonto för Captive Portal, User Portal eller Remote Access;
• en liten miljö utan katalogtjänst;
• en enskild extern leverantör med tydlig tidsperiod och ansvarig;
• en dokumenterad reservåtkomst när en extern användarkälla tillfälligt är otillgänglig.

Ett lokalt konto rekommenderas inte som gemensamt samlingskonto för flera personer. Delade inloggningsuppgifter försvårar lösenordsbyte, MFA, kvoter, granskning och ren avveckling.

Blanda inte användartyper

SFOS har flera liknande användartyper som löser olika uppgifter:

• En normal lokal användare loggar in med användarnamn och lösenord och får policyer via en normal grupp eller medvetna användarundantag.
• En gästanvändare är tidsbegränsad, använder Guest User-inställningarna och används normalt via Captive Portal.
• En Clientless User identifieras via en IP-adress och utför ingen interaktiv inloggning.
• En lokal administratör får User type: Administrator och en Device Access-profil för WebAdmin-rättigheter.
• En AD-, LDAP-, RADIUS- eller Entra-användare autentiseras av en extern källa. Beroende på metod skapas den lokala posten först vid den första lyckade inloggningen.

För en person som ska logga in på Captive Portal eller en VPN-tjänst används User type: User. Det ger inte kontot WebAdmin- eller SSH-åtkomst.

Planera exempel och förutsättningar

Följande exempel använder:

• användarnamn pilotuser01;
• visningsnamn Local Pilot User;
• e-postadress pilotuser01@example.com;
• grupp Local_Pilot_Users;
• brandväggsregel Local-Pilot-to-WAN;
• tillåten inloggningskälla 10.20.30.0/24.

example.com är en reserverad dokumentationsdomän och 10.20.30.0/24 används här endast som ett privat exempelnät. Ersätt användarnamn, e-postadress, grupp, regel och nät med värden från den egna miljön. Användarnamnet är medvetet funktionsneutralt och innehåller ingen e-postadress, så att ett senare e-postbyte inte ändrar inloggningsidentiteten. I produktion bör namnstandarden passa helpdesk, avveckling och befintliga katalognamn.

Följande behöver klargöras innan kontot skapas:

• Vilken tjänst autentiserar användaren: Captive Portal, User Portal, VPN Portal, SSL VPN, IPsec eller en annan åtkomst som stöds?
• Vilken normal grupp bär den gemensamma baslinjen?
• Vilken brandväggs- eller Remote Access-policy tillåter den senare åtkomsten?
• Från vilka IPv4-adresser får kontot logga in?
• Hur många samtidiga inloggningar behövs i praktiken?
• Krävs lokal MFA och via vilken portal sker den första registreringen?
• Vem inaktiverar kontot och kontrollerar befintliga sessioner vid avveckling?

Hantera användargrupper och Main Group på Sophos Firewall förklarar den gemensamma grupplogiken. För normala lokala användare används en grupp av typen Normal. En grupp av typen Clientless hör till den IP-baserade modellen och är inte rätt baslinje för detta inloggningsflöde.

Skapa den lokala användaren

Kontot skapas under Authentication > Users > Add:

1. Ange pilotuser01 vid Username.
2. Ange Local Pilot User vid Name.
3. Ställ in User type på User.
4. Ange och bekräfta ett långt, individuellt lösenord från den fastställda lösenordsprocessen.
5. Ange pilotuser01@example.com eller den verkliga ansvariga adressen vid Email.
6. Välj Local_Pilot_Users vid Group.
7. Ändra policy- och Remote Access-fält bara när ett dokumenterat användarundantag är avsett.
8. Ställ in Simultaneous sign-ins och Sign-in restriction på lämpligt sätt.
9. Spara med Save.

SFOS avvisar vanliga lösenord och ord som upptäcks i ordlistekontrollen. Artikeln visar medvetet inget exempellösenord. Ett lösenord som kan kopieras från dokumentation blir omedelbart en känd hemlighet och är ingen säker mall.

Gruppvärden eller användarundantag

I användarposten kan Surfing quota, Access time, Network traffic och Traffic shaping samt flera Remote Access-fält anges. Användarspecifika värden har företräde framför gruppvärden. Om gruppen ska förbli den underhållbara baslinjen åsidosätts dessa fält inte i förebyggande syfte.

Ett användarundantag passar för ett tydligt dokumenterat undantag, till exempel en snävare Access Time under ett tillfälligt uppdrag. Dokumentera:

• vilket fält som avviker från gruppvärdet;
• varför undantaget behövs;
• när det ska granskas eller tas bort;
• hur det ursprungliga gruppvärdet blir aktivt igen.

Access Time för användare och Surfing- respektive Network Traffic-kvoter förklarar varje policy fullständigt. Tilldela bara en policy som redan är förstådd i användarobjektet.

Begränsa antal och källa för inloggningar

Simultaneous sign-ins begränsar samtidiga sessioner. Global setting övertar värdet som gäller för nya användare under Authentication > Services. Alternativt kan ett eget värde eller Unlimited väljas. Obegränsade sessioner behövs sällan för en normal personlig användare och gör delade inloggningsuppgifter svårare att upptäcka.

Sign-in restriction begränsar de IPv4-adresser som användaren får logga in från:

• Any node: tillåt inloggning från alla nåbara källor;
• User group nodes: ärv gruppvärdet;
• Selected nodes: ange enskilda avsedda IPv4-adresser;
• Node range: tillåt ett sammanhängande IPv4-intervall.

I exemplet används det verkliga administrations-, användar- eller VPN-källnätet i stället för att blint kopiera 10.20.30.0/24. Ett för snävt urval blockerar legitima inloggningar. Any node utökar däremot bara den möjliga inloggningskällan och ersätter inte en brandväggsregel, portal-ACL eller MFA.

Aktivera inte MAC binding för detta grundflöde. Det stöder klientbaserad autentisering, men inte Remote Access VPN eller Captive Portal. Om det aktiveras utan MAC-adress binder SFOS automatiskt den först identifierade MAC-adressen vid den första inloggningen. På mobila enheter, efter ett byte av wifi eller på delade klienter kan detta snabbt bli ett oväntat beroende.

Koppla autentiseringsmetod och åtkomst

En sparad användare kan bara logga in på en tjänst som faktiskt frågar den lokala databasen. Välj därför Local för den avsedda tjänsten under Authentication > Services.

Områdena är separata:

• Firewall authentication methods för brandväggstrafik och Captive Portal;
• User portal authentication methods för User Portal;
• VPN portal authentication methods för VPN Portal;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods för dessa VPN-metoder;
• SSL VPN authentication methods för Remote Access SSL VPN.

Flera källor frågas i den visade ordningen. Ett lyckat test på User Portal visar därför inte automatiskt att samma användare är korrekt konfigurerad för SSL VPN eller IPsec.

Portal, regel eller VPN-policy förblir separat

Den lokala identiteten öppnar ingen nätverkssökväg. Captive Portal kräver dessutom Device Access, Web Authentication och en lämplig användarregel. Hela arbetsgången finns i Konfigurera och testa Captive Portal på Sophos Firewall.

User Portal och VPN Portal är också separata tjänster. Portalmodellen för Sophos Firewall förklarar portar, syfte, Device Access och WAN-gränser. Remote Access-policyer hanteras i respektive VPN-guide och betraktas inte som färdiga bara för att ett fält har ställts in i användarobjektet.

För en användarbaserad brandväggsregel definieras källa, destination, tjänst och användare eller grupp så snävt som möjligt. Log firewall traffic förblir aktivt under verifieringen. Grunderna finns i Förstå och konfigurera Sophos Firewall-regler säkert.

Verifiera med positiva och negativa tester

Ett synligt konto med status Active är ännu inget bevis på att allt fungerar. Pilotkontot testas via exakt den tjänst som senare ska användas:

1. Logga in som pilotuser01 i ett privat webbläsarfönster eller från en ren testklient.
2. Kontrollera användarnamn, käll-IP och Client Type under Current activities > Live users.
3. Kontrollera lyckad inloggning, lokal autentisering och tidpunkt i Log Viewer > Authentication.
4. Skapa den avsedda trafiken och kontrollera den förväntade regeln eller policyn i brandväggs- eller VPN-loggen.
5. Använd en uttryckligen otillåten källa eller funktion som negativt test.
6. Om en kvot eller Access Time är aktiv testas effekten separat innanför och utanför gränsen.
7. Dokumentera resultat, använd grupp, användarundantag och autentiseringsmetod.

En negativ inloggning bör inte misslyckas enbart därför att ett avsiktligt felaktigt lösenord användes. Kontrollera också att en otillåten källa, en användare utan rätt grupp eller en oavsedd funktion faktiskt inte får åtkomst. På så sätt skiljs lösenordskontrollen från policy- och regelverkan.

Om det fortfarande är oklart om den lokala databasen, tjänstevalet, användarstatusen, gruppen eller först den efterföljande regeln fallerar, ger systematisk felsökning av autentiseringsfel på Sophos Firewall hela kontrollkedjan. För djupare analys innehåller /log/access_server.log händelser för autentisering, auktorisering och redovisning; Log Viewer är fortfarande första steget.

Hantera lösenord, MFA och användning

En lokal användare kan själv ändra lösenordet under User Portal > Personal > Change Password. Det gäller den lokala databasen, inte externt autentiserade AD-, LDAP- eller RADIUS-konton. User Portal görs bara nåbar från de nödvändiga zonerna och öppnas inte brett mot WAN enbart för lösenordshantering.

För ytterligare skydd kan kontot väljas under Authentication > Multi-factor authentication. Med Generate OTP token with next sign-in registrerar användaren token via User Portal eller VPN Portal. MFA för Sophos Firewall förklarar hashalgoritm, portalåtkomst, återställning och pilotfas. MFA aktiveras först när den normala inloggningen och återställningsvägen fungerar.

Under Authentication > Users > <användare> > View usage visas tilldelade kvoter, Surfing-tid och dataförbrukning. För att uppgifterna ska visas måste trafiken matcha en användarbaserad brandväggsregel med Log firewall traffic. Reset user accounting startar om räknarna för Surfing och Network Traffic och används därför inte som en generell inloggningskorrigering.

Inaktivera och ta bort kontot på ett säkert sätt

När en person slutar eller kontots syfte upphör tas kontot inte bort direkt utan kontroll:

1. Kontrollera beroenden i regler, grupper, Remote Access-policyer, kvoter, MFA och dokumentation.
2. Välj användaren under Authentication > Users och gör den inaktiv med Change status.
3. Utför en ny inloggning som negativt test.
4. Kontrollera befintliga sessioner under Current activities > Live users och koppla vid behov från en normal användare med Disconnect.
5. Kontrollera brandväggs- och VPN-loggar efter fler försök eller kvarvarande trafik.
6. Ta bort kontot först när beroendena är utredda, eller behåll det inaktivt enligt lagringsprocessen.

Inaktivering ska inte behandlas som en garanti för att alla befintliga anslutningar avslutas automatiskt. Sessioner, tunnlar och trafik kontrolleras separat. Efter en återaktivering upprepas de positiva och negativa testerna.

Användare och grupper delar interna ID:n. Enbart ett stort antal objekt bevisar inte ett problem. Om en användare däremot visar ett User ID över 65535 och inte autentiseras, används den separata arbetsgången för Sophos Firewalls User ID-gräns, i stället för att ändra lösenord eller regler på måfå.

Avgränsa fel efter symtom

Användarnamn och lösenord avvisas

Kontrollera under Authentication > Users att kontot är lokalt, aktivt och finns med det förväntade användarnamnet. Kontrollera därefter för den aktuella tjänsten under Authentication > Services om Local är valt. En lyckad inloggning på en annan portal bevisar inte detta tjänsteval.

Inloggningen fungerar, men användarregeln matchar inte

Kontrollera identitet, käll-IP och Client Type under Current activities > Live users. Kontrollera sedan regelposition, Source Zone, användare eller grupp och Firewall Rule ID i Log Viewer. En nätverksregel ovanför användarregeln kan redan ha tagit över flödet.

En gruppändring får ingen effekt

Leta efter användarspecifika värden för kvot, Access Time, Traffic Shaping eller Remote Access. Dessa undantag har företräde framför gruppen. Värdet återställs till grupparv först efter jämförelse med det dokumenterade undantaget.

Användaren kan logga in från en oväntad källa

Kontrollera Sign-in restriction både på användaren och gruppen. Kontrollera dessutom den tjänst som faktiskt används, Device Access och nätverksregeln. En inställning på Any node kompenseras inte automatiskt av MFA eller en snäv brandväggsregel.

View usage förblir tomt

Kontrollera att användaren identifieras som Live User och att trafiken matchar en användarbaserad regel med Log firewall traffic. Kontrollera sedan tidsperiod, kvottilldelning och faktisk testtrafik. Reset user accounting skapar inga saknade loggar och reparerar ingen felaktig regel.

Operativ checklista

• Kontots användningsfall, ägare och slutdatum är dokumenterade.
• Användarnamn och användartyp valdes medvetet före lagring.
• En grupp av typen Normal bär den gemensamma baslinjen.
• Användarundantag undviks eller motiveras.
• Simultaneous sign-ins och Sign-in restriction passar användningsfallet.
• Local är valt för varje nödvändig autentiseringstjänst.
• Portal, brandväggsregel eller VPN-policy har konfigurerats separat.
• Positiv och negativ inloggning samt verklig trafik har kontrollerats.
• Live Users, Authentication Log och den förväntade regeln eller policyn stämmer överens.
• MFA och återställning har testats om MFA används.
• En ansvarig person hanterar lösenordsbyte, användning och avveckling.
• Inaktivering, befintliga sessioner och senare borttagning är separata steg.

Vanliga frågor