Använda Sophos Firewall webbkategorier och omedelbara varningar

Webbkategorier styr vilka webbplatser användarna får öppna. Omedelbara varningar lägger till e-postaviseringar för ett litet antal medvetet övervakade kategorier. Kategori, webbpolicy, brandväggsregel, loggning och e-postleverans måste stämma överens för att funktionerna ska vara tillförlitliga.

Det är särskilt användbart i skolor, känsliga verksamhetsdelar eller miljöer där vissa webbförfrågningar inte ska förbli oupptäckta fram till månadsrapporten.

En kategori ensam ändrar inte trafiken. En webbpolicy måste koppla kategorin till en åtgärd och sedan tilldelas en matchande brandväggsregel. TLS-inspektion, QUIC-hantering och loggning avgör dessutom vad brandväggen kan identifiera och senare rapportera.

För allmän planering av webbpolicyer passar först Ställa in Sophos Firewall Web Protection med webbpolicyer. För regelbasen hjälper Förstå och konfigurera Sophos Firewall-regler korrekt. Denna artikel fokuserar på den operativa webb-delen: kategorier, URL-grupper, omedelbara varningar, utvärdering och reaktion.

Orientering

Klargör först vilken uppgift varje webbfunktion har. Då undviker du att blanda ihop kategorier, URL-grupper, webbpolicyer och Instant alerts.

Tydlig åtskillnad av begrepp

Sophos använder flera webbobjekt som lätt kan blandas ihop i vardagen.

• Webbkategori: Kategori för domäner, URL:er eller nyckelord. Många kategorier kommer från Sophos, egna kategorier är möjliga. Tillåta, blockera, begränsa eller rapportera webbåtkomster baserat på risk eller innehåll.
• URL-grupp: Lista med domäner som kan användas i webbpolicyer eller TLS-undantag. Explicit tillåt- eller blocklistor när specifika domäner är viktigare än kategorier.
• Webbpolicy: Regelverk för användare, grupper, kategorier, URL-grupper, filtyper, innehållsfilter och åtgärder. Styra webbåtkomster och koppla till en brandväggsregel.
• Omedelbara varningar: E-postmeddelande för åtkomster till övervakade kategorier. Snabb rapportering vid särskilt känsliga eller riskfyllda kategorier.
• Log Viewer och rapporter: Utvärdering av det faktiska beslutet. Kontrollera om kategori, policy, användare och brandväggsregel fungerar som förväntat.

En webbpolicy fungerar först när den är vald i en lämplig brandväggsregel under Security features > Web filtering. Webbpolicyn i sig är alltså inte en brandväggsregel som hanterar trafik i drift.

När webbkategorier är meningsfulla

Webbkategorier är särskilt användbara när webbåtkomster inte bara ska tillåtas eller blockeras generellt. Typiska scenarier:

• Blockera kategorier för skadlig kod, nätfiske och bedrägeri.
• Begränsa anonymiseringstjänster, proxies och kringgåendetjänster.
• Övervaka särskilt kategorier för Command-and-Control eller spionprogram.
• Blockera kategorier som vuxeninnehåll, spel om pengar (Gambling) eller kontrollerade substanser beroende på miljö.
• Tillåta affärskritiska molnapplikationer men begränsa privata moln- eller fildelningstjänster.
• Övervaka särskilt känsliga kategorier med omedelbara varningar i skolor eller övervakade miljöer.
• Begränsa bandbredd för vissa webbkategorier genom trafikformning.

Kategorier bör inte sättas på block eller varning utan eftertanke. Annars uppstår många träffar som ingen kan granska meningsfullt. Bättre är ett litet, tydligt set med ägare, reaktionsväg och granskning.

Förutsättningar

Innan konfigurationen bör dessa punkter klargöras:

• Web Protection eller ett lämpligt Sophos Firewall-paket är licensierat.
• Det finns en klient- eller användarregel som ska använda webbfiltrering.
• Användar- eller gruppmatchning är planerad om policyer ska gälla användarbaserat.
• Log firewall traffic är aktiv i den relevanta brandväggsregeln.
• Under System services > Log settings är minst Content filtering valt för Local reporting. Välj samma loggtyp i motsvarande målkolumn för Central Reporting eller Syslog.
• E-postmeddelanden fungerar om omedelbara varningar ska användas.
• Den använda modellen stöder omedelbara varningar; XGS 87 och XGS 88 stöder inte funktionen.
• För långsiktig utvärdering är Central Firewall Reporting eller Syslog planerat.
• Beslut har fattats om hur QUIC och TLS-inspektion ska hanteras.

För central utvärdering passar Aktivera Central Firewall Reporting. Om loggar ska skickas till ett eget SIEM är Skicka Sophos Firewall Syslog till SIEM den bättre anslutningsartikeln.

Planera policydesign

Innan alerts konfigureras bör man definiera vilka kategorier som är relevanta, vem som får notiser och vad som ska hända efter en alert.

Planera kategorier och URL-grupper

För administratörer är det viktigt när en egen webbkategori och när en URL-grupp passar bättre.

En egen webbkategori är meningsfull när:

• Domäner eller nyckelord ska användas som kategori i flera webbpolicyer.
• Kategorin ska vara synlig i rapporter och loggar.
• Ett trafikformningskoncept efter kategori är planerat.
• En övervakad kategori för omedelbara varningar ska skapas.

En URL-grupp är oftast bättre när:

• Endast specifika domäner samlas.
• En liten tillåt- eller blocklista behövs.
• Listan också ska användas för TLS-undantag.
• Nyckelordsmatchning ska undvikas.

Vid rena domänmatchningar är URL-grupper mer direkta och enklare att granska än kategorier med nyckelord. Använd nyckelordskategorier endast i blockeringsregler, inte tillåt-regler: frågeparametrar kan annars tvinga fram oönskad åtkomst.

En URL-grupp innehåller giltiga domäner. Reguljära uttryck är inte tillåtna; posterna utvärderas med OR, så en enda träff räcker. Den aktuella SFOS 22-hjälpen anger inget fast maximum. Det är inget löfte om obegränsade listor. För stora eller dynamiskt underhållna listor bör man kontrollera om en importerad kategoridatabas eller ett threat feed passar bättre.

Skapa och använd URL Groups säkert visar hela processen för att skapa, använda i Web Policy och TLS samt testa gruppen.

Skilj mellan fasta, dynamiska och saknade kategorier

De flesta inbyggda kategorier bygger på en URL-sökning. ActiveX, Applets, Cookies och HTTPUpload är däremot dynamiska kategorier: brandväggen tilldelar dem genom innehållsinspektion. En URL-sökning ensam bekräftar därför inte att en sådan innehållsregel träffar en verklig begäran. ALLWebTraffic betyder all HTTP-trafik, inte bara tidigare okända webbplatser.

None och Uncategorized är olika resultat. Vid None lyckades sökningen, men URL-databasen saknar kategoriinformation. Vid Uncategorized misslyckades sökningen. Skilj mellan saknad databasklassificering och ett kategoriseringsproblem innan ett undantag skapas; inget av resultaten bevisar att en webbplats är säker.

Välj kategorier efter deras betydelse

En kategori är inget allmänt säkerhetsomdöme om allt innehåll i en tjänst. Dessa skillnader är viktiga när policyåtgärder väljs:

• CRL and OCSP gäller kontroll av återkallade certifikat; Software updates gäller uppdateringar av vanliga program. Dessa förfrågningar behövs normalt. Download freeware & shareware undantar uttryckligen uppdateringssidor för operativsystem, antivirus och andra verksamhetskritiska program. En nedladdningsblockering får inte oavsiktligt hindra uppdateringar.
• Content delivery omfattar oftast sekundärt eller inbäddat innehåll från andra webbplatser. En generell blockering kan störa godkända sidor; kontrollera faktisk målvärd och huvudsida i loggarna före ett undantag.
• Command & control betyder kända styrservrar för malware, Spyware & malware sidor med skadligt innehåll och Phishing & fraud bland annat nätfiske- och bedrägerisidor. Newly registered websites och Parked Domain är däremot risksignaler, inte bevis på malware.
• Business cloud apps, Personal cloud apps och Personal network storage skiljer verksamhetsappar, personliga molntjänster och privat nätverkslagring. Besluta utifrån dataläckagerisk och verksamhetsbehov, inte bara ordet ”moln”.
• Anonymizers och Translators kan kringgå filter; Image search, Portal sites och sökmotorer kan visa innehåll från andra kategorier. Att tillåta huvudsidan betyder därför inte att varje inbäddat mål ska tillåtas.
• Live audio, Live video, Video hosting, Surveillance och Voice & video calls skiljer streaming, video på begäran, övervakning och kommunikation. Om shaping eller blockering passar beror på tjänsten som behövs. Webbplatser för kasinon, hotell och semesteranläggningar hör till Travel om de varken erbjuder spel om pengar online eller tips om vadslagning eller spel. Hotellnamnet ensamt bevisar inte klassificeringen.

Kort ordlista för felsökning och känsliga miljöer

• Gambling omfattar onlinespel om pengar och lotterier med riktiga eller virtuella pengar; information och råd om vadslagning, lotterier, spel om pengar och nummerspel; virtuella kasinon och offshorebaserade spelverksamheter; sporttips för vadslagning och vadslagningspooler samt virtuella sport- och fantasyligor med stora belöningar eller betydande insatser. Games omfattar webbplatser för att spela eller ladda ner spel, tillhandahålla spel eller anordna speltävlingar, ge speltips och råd eller tillhandahålla fuskkoder samt tidskrifter om onlinespel. Skilj spel om pengar från övrigt spelinnehåll när kategoriåtgärden väljs.
• HTTPUpload gäller begränsningar av HTTP-uppladdningar och är dynamisk; IPAddress gäller webbplatser som öppnas via IP-adresser. Det är olika regelfall, inte synonymer för saknad klassificering.
• Pro-suicide & self-harm omfattar webbplatser som uppmuntrar självmord eller självskada. Skolor kan övervaka möjliga risker för elever med kategorin. Sidor om psykisk hälsa, hjälp och stöd hör inte hit enbart på grund av ämnet. En träff kräver mänsklig granskning, inte en automatisk slutsats om en incident.
• Sex education omfattar bilder och texter om korrekt användning av preventivmedel, till exempel p-piller och spiral, samt diskussioner om hur man talar med sin partner om sjukdomar, graviditet och respekt för personliga gränser. Kommersiella webbplatser som säljer sexuella produkter är undantagna och hör normalt till Sexually explicit. Den kategorin omfattar vuxenprodukter som sexleksaker, CD-ROM-skivor och videor; sexuella tjänster som videokonferenser, eskorttjänster och strippklubbar; erotiska berättelser och textbeskrivningar av sexuella handlingar; sexuellt explicita tecknade bilder, animationer och nätgrupper, inklusive diskussionsgrupper och forum; sexuellt eller erotiskt innehåll med hel eller partiell nakenhet; skildringar av sexuella handlingar, även med djur eller föremål som används sexuellt; sexuellt exploaterande eller våldsamma texter och bilder; bondage, fetischer och genital piercing; naturistwebbplatser med nakenhet samt erotisk eller fetischinriktad nakenfotografi. Även material som skildrar sexuella övergrepp mot barn och material om pedofili, inklusive IWF-listan, ingår. Webbplatser om sexuell hälsa, bröstcancer och sexuellt överförbara infektioner är undantagna, utom när de innehåller grafiska exempel.
• Intolerance & hate omfattar webbplatser som förespråkar eller uppviglar till förnedring eller angrepp mot grupper eller institutioner utifrån exempelvis religion, ras, nationalitet, kön, ålder, funktionsnedsättning eller sexuell läggning. Även politiska eller sociala överlägsenhetsideologier som utestänger andra på dessa grunder, förintelserevisionism eller förintelseförnekelse och annan historierevisionism som uppmuntrar hat ingår. Kategorin omfattar också tvång eller rekrytering till gäng eller sekter, militant och extremistiskt innehåll samt uppenbart hänsynslöst eller grovt kränkande material, inklusive bristande erkännande av eller respekt för motstridiga åsikter och övertygelser. Med gäng avses här grupper med ett gemensamt namn, tecken eller symbol vars huvudsakliga verksamhet är grova brott och vars medlemmar enskilt eller tillsammans begår brott i gruppens namn. Med sekter avses grupper som rekryterar och håller kvar medlemmar genom vilseledning, manipulation och otillbörlig påverkan så att deras personlighet och beteende förändras, där ledarskapet är allsmäktigt, ideologin totalitär och individens vilja underordnad gruppen, och som ställer sig utanför samhället. Nyheter, historiskt material och pressrapportering som kan innehålla dessa inslag är undantagna, utom grafiska exempel. Rapportering är inte automatiskt ett uttryck för stöd.
• Radio & audio hosting omfattar legitimt ljud och musik på begäran, med Spotify och Pandora som dokumenterade exempel på sådana tjänster, till skillnad från direktsändningar av evenemang eller program i Live audio. Exemplen beskriver kategorins betydelse och garanterar inte tjänsternas aktuella klassificering. Online Chat omfattar webbaserad chatt och direktmeddelanden; Voice & video calls gäller internettelefoni och videosamtal. Välj efter den kommunikationsform som behövs.
• Unauthorized software stores omfattar distribution av program och appar för datorer och mobila enheter vars legitimitet är tveksam, med potentiellt skadliga eller trojaniserade nedladdningar. Inte varje icke godkänd butik är bevisligen skadlig. Skilj kategorin från nödvändiga, godkända Software updates för vanliga produkter.

Använd bara ofarliga, godkända testfall och kontrollerade testresurser för känsliga kategorier; besök aldrig olagligt eller påfrestande material. Låt en person granska kategori, sammanhang och möjliga felklassificeringar före eskalering. Vanliga ämnesdefinitioner i katalogen och historiska tjänsteexempel utelämnas av redaktionella skäl; de är inte bara navigering och presenteras inte som en fullständigt översatt taxonomi.

Spara befintlig policy före breda ändringar och använd ofarliga, godkända mål för att testa både avsedd träff och nödvändiga uppdateringar och certifikatkontroller. Återställ vid avbrott den berörda kategoriåtgärden och upprepa testerna i stället för att stänga av all webbfiltrering.

Generative AI som webbkategori i SFOS 23.0

SFOS 23.0 dokumenterar Generative AI som en inbyggd webbkategori för webbplatser och tjänster där användare kan skapa eller omvandla innehåll med hjälp av promptar. Webbplatser vars huvudsakliga syfte inte är generativ AI är uttryckligen undantagna från kategorin. En extra AI-funktion i en annan tjänst räcker därför inte för att anta att tjänsten tillhör denna kategori. Kategorin garanterar inte att all AI-användning upptäcks.

Denna URL-klassificering från Sophos används genom en Web Policy. Den ska skiljas från applikationssignaturer och applikationskategorin Generative AI i Application Control. En anpassad webbkategori med samma namn synkroniseras inte automatiskt med applikationskatalogen. En domänlista som administratören underhåller i en URL-grupp eller anpassad kategori är också ett separat objekt med egen ansvarig och granskningsdatum, inte den inbyggda kategorin.

Kontrollera effekten på den installerade versionen i ett begränsat pilotförsök innan en bred blockering införs:

1. Kontrollera kategorin under Web > Categories och använd Diagnostics > URL category lookup för en godkänd, ofarlig test-URL. Sökningen visar endast klassificeringen, inte det faktiska policybeslutet; en anpassad kategori kan avgöra vilket resultat som visas.
2. Kontrollera kategorin, HTTP/HTTPS-åtgärderna och regelordningen under Web > Policies. Policyn måste vara vald i den matchande brandväggsregeln under Security features > Web filtering. Kontrollera Enable logging and reporting, Log firewall traffic och Content filtering under System services > Log settings > Local reporting.
3. Komplettera Policy tester med en kontrollerad, verklig klientbegäran och kontrollera använd kategori, Web Policy, brandväggsregel och åtgärd i Log Viewer. Utvärdera besluten från Application Control separat. Vid avvikelser, kontrollera först anpassade kategorier, regelordning, undantag och TLS/QUIC-väg i stället för att anta fullständig AI-detektering.

Kontrollera generativ AI förklarar valet mellan webbkategori, Application Filter och kompletterande domänlista samt arbetsgången för pilotförsöket.

Blockera, varna eller bara rapportera?

Inte varje kategori behöver samma behandling. En bra webbskyddsdesign skiljer hårda säkerhetsbeslut från indikationer och ren utvärdering.

• Blockera: Använd blockering för skadlig kod, nätfiske, kända kringgåendetjänster och klart förbjudna kategorier. En legitim sida kan blockeras om kategorin är felaktig.
• Varning: Använd varningar för gråzoner, utbildningsmiljöer och medvetet tillåtna kategorier. Användare kan vänja sig vid varningarna och klicka reflexmässigt vidare.
• Omedelbar varning: Välj få kategorier där någon faktiskt måste reagera. För många varningar leder till varningströtthet.
• Endast rapportering: Använd rapportering för trendanalys, användningsrapporter och svaga signaler. Träffar blir synliga först senare.

I produktionsmiljöer är ofta ett litet, tydligt urval bättre än en maximal katalog. Om ingen utvärderar en varning bör kategorin inte köras som omedelbar varning. Om en kategori alltid ska blockeras är en varning endast meningsfull om det leder till en konkret uppföljning.

En fast systemgräns gäller för webbplatser som Sophos klassificerar som särskilt allvarlig kriminell aktivitet: brandväggen blockerar dem oavsett webbpolicy eller undantag och döljer domännamnet i loggar och rapporter. Ett saknat domännamn är därför inte ett loggningsfel i detta fall.

Konfiguration

Konfigurationen består av fyra delar: kategori eller URL-grupp, webbpolicy, brandväggsregel och valfria Instant alerts. Först när delarna stämmer överens får de effekt på trafiken i drift.

Skapa eller anpassa webbkategori

Menyvägen är:

Web > Categories

Grundläggande steg:

1. Redigera befintlig kategori eller välj Add.
2. Ge ett namn.
3. Välj klassificering.
4. Valfritt, välj en trafikformningspolicy.
5. Välj konfigurationstyp.
6. Lägg till domäner eller nyckelord.
7. Valfritt, aktivera Instant alerts.
8. Spara.

För egna kategorier bör namnet tydligt beskriva syftet. Namn som Custom1 eller Blocklist hjälper inte senare. Bättre är namn som Alert_Self_Harm, Block_Proxy_Anonymizer eller Allow_Business_Cloud_Exceptions.

Domäner kontrolleras mot domännamnet i URL:en och inkluderar automatiskt underdomäner. Nyckelord kontrolleras däremot mot hela URL:en inklusive sökväg och frågor. Detta kan vara användbart men genererar lättare falska träffar.

Om en extern URL-databas används kontrollerar brandväggen denna lista var 48:e timme för uppdateringar. Detta intervall kan inte ändras. För offentliga blocklistor bör man ändå kontrollera om Ställa in och säkert driva Sophos Firewall Threat Feeds är bättre.

En anpassad kategori ersätter inte Sophos standardkategori för en URL. En URL kan tillhöra flera kategorier. Brandväggen utvärderar kategorier i kategorilistans ordning, och loggar och rapporter visar kategorin som användes för policybeslutet. Testa därför en verklig begäran igen efter ändringar av poster eller ordning.

Med Local database är högst 2,000 poster möjliga. En lokal .txt-fil innehåller en post per rad, medan en .csv-fil innehåller kommaseparerade poster på en enda rad. External URL database accepterar en .txt-, .csv-, .tar-, .gz- eller .bz2-fil som är tillgänglig via HTTP eller FTP, men stöder inte autentisering mot källservern. Ogiltiga poster ignoreras.

Storleken på den externa cachen beror på brandväggens RAM-minne. Sophos anger att de flesta modeller med mer än 4 GB RAM kan cacha upp till 122,880 poster. Kontrollera den faktiskt tillgängliga gränsen i /log/nSXLd.log innan en stor lista används i produktion.

Kontrollera poster och importer

Classification hjälper till att filtrera och hantera kategorier. Traffic shaping policy anger användningsgränser och bandbredd för upp- och nedladdning; behåll None om ingen begränsning avses. Configuration type är från början Local. Ange en post i Search/Add och välj Add, eller importera en lokal fil med Browse. För en extern databas läggs i stället källans URL till där.

Domänposter kan innehålla en sökväg eller fråga, till exempel example.com/research eller example.com/search?q=report; ett protokollprefix som https:// hör inte hemma i posten. Detta är syntaxexempel, inte godkända testmål. Nyckelord måste börja med en bokstav, siffra eller _. Ogiltiga tecken, ogiltiga domänposter och tomma rader tas bort. Om en lokal fil innehåller fler än 2,000 poster importeras endast de första 2,000. Arkiv för externa databaser måste innehålla textfiler. Den externa databasen har ingen fast postgräns; det gör uttryckligen inte dess RAM-beroende cache obegränsad.

Skapa inte en tillåt-lista med nyckelord: dessa kontroller är mindre effektiva och granskar även frågeparametrar. En tillåten kategori med nyckelordet research kan träffa blocked.example/?tag=research, trots att själva domänen borde vara blockerad. Använd nyckelordskategorier endast i blockeringsregler, inte för att tillåta åtkomst. En URL-grupp passar bättre för undantag som bara gäller domäner. Dokumentera poster och befintlig policy före importen; kontrollera därefter den sparade listan, en förväntad träff och en utebliven träff. Återställ tidigare poster vid felaktiga träffar i stället för att lätta på blockeringar generellt.

Kategorispecifik blockeringssida

Under Advanced settings > Override default notification page kan ett eget meddelande ersätta standardmeddelandet när kategorin blockerar en webbplats. Platshållarna {category}, {user} och {url} visar kategori, användarnamn och blockerad URL. Ta bara med nödvändiga uppgifter: användare och URL:er kan avslöja känslig information. Spara tidigare meddelande och inställning, och kontrollera sedan med ett ofarligt mål som blockeras i ett kontrollerat test. Återställ tidigare text eller standardsida om visningen är olämplig; ett ändrat meddelande tillåter inte webbplatsen.

Konfigurera webbpolicy

Menyvägen är:

Web > Policies

En webbpolicy innehåller regler för användare, grupper, aktiviteter, kategorier, URL-grupper, filtyper, innehållsfilter, åtgärder och scheman.

Grundläggande steg:

1. Skapa ny webbpolicy eller redigera befintlig policy.
2. Lägg till regel.
3. Välj användare eller grupper om policyn ska vara användarbaserad.
4. Välj kategorier eller URL-grupper.
5. Ställ in åtgärd för HTTP.
6. Kontrollera separat åtgärd för HTTPS.
7. Ställ in schema om nödvändigt.
8. Under Advanced settings, aktivera Enable logging and reporting om policyn ska visas i loggar och rapporter.
9. Aktivera regeln.
10. Kontrollera regelposition.
11. Spara.

Enable logging and reporting i webbpolicyn och Log firewall traffic i brandväggsregeln fyller olika funktioner. Kontrollera båda medvetet när spårbar utvärdering krävs.

Ordningen inom webbpolicyn är avgörande. Regler utvärderas uppifrån och ner. En bred tillåt-regel ovanför en specifik blockregel kan leda till att blockregeln aldrig träder i kraft.

Om användare är inställda i brandväggsregeln och i webbpolicyn måste man medvetet testa effekten. Användare i brandväggsregler kan ha företräde framför användare i webbpolicyer. Vid oklara träffar bör man därför inte bara kontrollera webbpolicyn utan även brandväggsregeln.

Aktivera webbpolicy i brandväggsregel

Menyvägen är:

Rules and policies > Firewall rules > [Rule] > Security features > Web filtering

Grundläggande steg:

1. Öppna relevant klient- eller serverregel.
2. Kontrollera Source zone, Source network, Destination zone och Services.
3. Aktivera Log firewall traffic.
4. Under Web filtering välj önskad webbpolicy.
5. Medvetet aktivera eller motiverat inaktivera Block QUIC protocol.
6. Kontrollera inställningar för Malware Scan och HTTPS-Scan.
7. Spara.
8. Testa med Policy tester, Log Viewer och verklig klienttrafik.

QUIC är en vanlig störfaktor för webbfiltrering. När webbläsare kommunicerar över UDP 443 stämmer inte alltid logik och synlighet med förväntningarna på klassisk HTTPS över TCP. För detaljer passar Blockera Sophos Firewall QUIC och HTTP/3 korrekt.

Om HTTPS-innehåll eller fullständiga URL-sökvägar är relevanta räcker inte alltid webbkategorisering. Då måste TLS-inspektion planeras. Detta bör inte ske i förbifarten eftersom certifikat, undantag, dataskydd, prestanda och supportprocesser påverkas. Utrullningen beskrivs i Införa Sophos Firewall TLS-inspektion korrekt.

Exempel: tillåt kategorier endast för en forskningsgrupp

Ett begränsat gruppundantag är säkrare än en generell tillåt-regel. Dokumentera först befintlig policy, brandväggsregelns position och gruppinställningar, och bekräfta att testanvändarna identifieras korrekt. Research, Web categories och Web research group är fritt valda exempelnamn.

1. Skapa Research under Authentication > Groups > Add. Välj Surfing quota och Access time medvetet och klicka på Save. Unlimited internet access och Allowed all the time är möjliga exempelvärden, inte krav för ett kategoriundantag: obegränsad användning och åtkomst dygnet runt kräver separat godkännande.
2. Skapa Web categories under Web > Policies > Add policy och välj Add rule. Den nya regeln ligger överst, är från början avstängd och skulle med sina ursprungliga inställningar blockera all HTTP-trafik för alla användare. Ändra urvalet innan den aktiveras.
3. Öppna All web traffic > Add new item i Activities, avmarkera All web traffic och välj endast godkända kategorier under Show only > Web category. Bekräfta med Apply selected items.
4. Välj Allow HTTP i Action, kontrollera den separata HTTPS-åtgärden medvetet, aktivera Status och spara. Utelämna inte loggning eller övriga regler av misstag.
5. Välj rätt IPv4- eller IPv6-familj och Add firewall rule under Rules and policies > Firewall rules. Begränsa Web research group till nödvändiga källnät, zoner, mål och tjänster. Använd Add new item i användar-/gruppvalet, avmarkera Any, välj Research och Apply selected items. Tilldela policyn under Security features > Web filtering.
6. Flytta efter Save regeln med draghandtaget före den allmänna arbetsplatsregeln, inte okontrollerat före andra säkerhetsregler. Testa med en gruppmedlem och en icke-medlem: endast den godkända gruppen ska nå den tillåtna kategorin; andra kategorier och användare måste fortfarande följa avsedd grundpolicy. Bekräfta regel-ID, kategori och åtgärd i Log Viewer.

Vid oväntat tillåten åtkomst, inaktivera den nya gruppundantagsregeln och återställ dokumenterad ordning eller policytilldelning. Upprepa båda användartesterna. Gruppmedlemskap ensamt bevisar inte att rätt brandväggsregel träffades.

Det dokumenterade exemplet kallar användartilldelningen Identity och policyvalet Advanced. Avsnittsnamn kan skilja sig mellan gränssnitt. Det viktiga är ett begränsat användar-/gruppval och tilldelning av Web Policy under Web filtering på den installerade versionen; aktivera inte undantaget om tilldelningen är oklar.

Aktivera omedelbara varningar

Omedelbara varningar aktiveras på kategorinivå. De är avstängda som standard för alla kategorier. Filterikonen bredvid Instant alerts under Web > Categories hjälper till att visa och kontrollera övervakade kategorier.

Menyvägen är:

Web > Categories

Grundläggande steg:

1. Redigera kategori.
2. Välj kategori medvetet för övervakning.
3. Aktivera Instant alerts.
4. Spara.
5. Öppna System services > Notifications list.
6. Aktivera Email notifications högst upp på sidan.
7. Sök efter Web – Instant alerts.
8. Markera kryssrutan under Email.
9. Kontrollera e-postserver, avsändare och mottagare under Administration > Notification settings.
10. Generera en testbegäran och kontrollera nästa aviseringsbatch, som skickas var femte minut.

Brandväggen skickar e-postmeddelanden för övervakade kategorier i batcher var femte minut. Detta intervall kan inte ändras. En varning är därför inget realtidslarm med noggrannhet på sekundnivå, utan ett snabbt e-postmeddelande jämfört med enbart efterföljande rapporter.

Omedelbara varningar är inte tillgängliga på XGS 87 och XGS 88. Om funktionen saknas på en av dessa modeller är e-post- eller aviseringskonfigurationen därför inte nödvändigtvis felaktig.

Omedelbara varningar bör endast aktiveras för kategorier där en definierad mottagare faktiskt kan reagera. En stor varningslista utan ansvar leder oftast till varningströtthet.

Analys och drift

Alerts är bara användbara om de granskas, klassificeras och hanteras konsekvent i den dagliga driften.

Dataskydd och intern ansvarighet

Webbkategori-varningar kan innehålla användare, käll-IP, tidpunkt, kategori och beroende på synlighet även målinformation. Detta är användbart för säkerhet och drift, men kan beroende på organisation väcka arbetsrättsliga eller dataskyddsrelaterade frågor.

Innan funktionen används i ordinarie drift bör därför följande klargöras:

• Vem får se webblarm?
• Vilka träffar granskas endast tekniskt och vilka behandlas som säkerhetsfall?
• Hur länge lagras varnings-e-post, rapporter eller SIEM-händelser?
• Är utvärderingen samordnad med HR, dataskydd eller interna riktlinjer?
• Hur förhindrar man att enskilda harmlösa träffar övertolkas?

Tekniskt är inställningen snabbt aktiverad. Operativt bör den dock behandlas som en liten övervakningsprocess: mottagare, syfte, reaktionsväg och lagring måste passa ihop.

Fastställa varningstriage

Omedelbara varningar bör inte behandlas lika. En enskild kategoriträff kan vara ett harmlöst felklick, en felklassificerad tjänst, ett policyproblem eller ett verkligt säkerhetsfall. Därför bör det definieras i förväg vilka träffar som ska granskas omedelbart och vilka som bara går in i den normala granskningen.

En enkel triage hjälper:

• Hög: Hit hör skadlig kod, nätfiske, Command-and-Control samt exploaterings- eller spionprogramkategorier. Granska Log Viewer, användaruppgifter, Endpoint-status och andra säkerhetsloggar skyndsamt.
• Medel: Hit hör anonymiseringstjänster, proxy, fildelning, privat molnlagring eller upprepade försök att kringgå policyn. Granska mönster, klargör användarkontexten och skärp policyn vid behov.
• Låg: Hit hör enskilda gråzoner utan upprepning. Ta med dem i rapportering eller veckogranskning i stället för att eskalera omedelbart.
• Falsklarm: En affärskritisk sida kan vara felaktigt kategoriserad. Överväg en riktad URL-grupp eller kategoriändring; skapa inte en bred tillåt-regel.

Denna indelning bör inte bara finnas i en administratörs huvud. En kort driftsnotering är meningsfull: övervakade kategorier, mottagare, reaktionstid, eskaleringsväg, tillåtna undantag och granskningsdatum. Detta håller det klart om en varning bara ska dokumenteras, tekniskt korrigeras eller behandlas som en incident.

Använda URL Category Lookup före policytestet

Med en aktiv Web Protection-prenumeration visar Diagnostics > URL category lookup vilken kategori Sophos tilldelar en viss URL. Ange den fullständiga test-URL:en i Search URL och klicka på Search. Resultatet visar kategorins namn och beskrivning. Om URL:en tillhör både en anpassad kategori och en standardkategori visar sökningen den anpassade kategorin.

Lookup bekräftar endast kategoriseringen. Det bevisar inte vilken brandväggsregel eller web policy en verklig klient matchar, om ett undantag gäller eller hur TLS, QUIC och den faktiska trafikvägen fungerar. Efter lookup följer därför Policy tester, ett kontrollerat klientanrop och utvärdering i Log Viewer.

Testa och utvärdera

Efter varje ändring bör man inte bara spara utan också kontrollera effekten.

Lämpliga kontrollsteg:

1. Öppna Diagnostics > Tools > Pop-out tools > Policy tester. Web > Policies > Policy tester är en alternativ genväg till samma verktyg.
2. Ange URL, användare, tidpunkt, käll-IP-adress och källzon och testa sedan Firewall, SSL/TLS, and web. Web policy only utelämnar avsiktligt brandväggsreglerna.
3. Besök en lämplig webbplats på en testklient.
4. Öppna Log viewer.
5. Kontrollera webbfilter-, brandväggs-, SSL/TLS-inspektions- och applikationskontrolloggar.
6. Kontrollera i brandväggsregeln om träffen ligger på den förväntade regeln.
7. Vid omedelbara varningar, kontrollera e-postinkorgen.
8. Kontrollera i Sophos Fusion (tidigare Sophos Central) eller SIEM om händelserna kommer dit.

Policy tester modellerar transparent webbtrafik och tar inte hänsyn till SD-WAN-rutter. Verktyget ersätter därför inte ett verkligt trafikflöde. Om en regel inte matchar, en SD-WAN-rutt väljer en annan väg eller TLS/QUIC ändrar vägen syns skillnaden ofta först i Log Viewer eller en packet capture. För sådana fall passar Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture.

För loggfilernas tilldelning hjälper Sophos Firewall Troubleshooting: Services och Logs. Där är bland annat awarrenhttp.log, webproxy.log och nSXLd.log för webb- och kategoriseringsfrågor inordnade.

Fastställa reaktion på omedelbara varningar

En omedelbar varning är bara användbar om det är klart vad som ska hända efteråt. Annars uppstår ytterligare e-posttrafik men ingen bättre säkerhet. Innan aktivering bör därför en enkel reaktionsprocess definieras.

För varje övervakad kategorityp bör minst följande fastställas:

• Vem får varningen?: Förhindrar distributionslistor utan ansvar.
• Hur snabbt måste man reagera?: Skilj kritiska träffar från sådant som kan hanteras i den rutinmässiga efterföljande analysen.
• Vilka loggar granskas?: Log Viewer, Central Reporting, Syslog eller serviceloggar ger olika djup.
• När är en träff en incident?: Inte varje kategoriträff är automatiskt en säkerhetsincident.
• Vem får godkänna ett undantag?: Förhindrar snabba, breda tillåt-regler utan riskbedömning.
• När granskas kategoriurvalet?: Minskar varningströtthet genom för breda varningsset.

En pragmatisk process ser ut så här:

1. Registrera varning med användare, käll-IP, kategori, URL eller domän och tidpunkt.
2. Kontrollera i Log Viewer vilken brandväggsregel och webbpolicy som gällde.
3. Om tillgängligt, använd Central Reporting eller SIEM för tidsmässig inordning.
4. Bedöm om det är ett enskilt fall, ett upprepat mönster eller ett falsklarm.
5. Vid felkategorisering, arbeta endast riktat med URL-grupp eller kategoriändring.
6. Vid märkligt mönster, utvärdera användarkontext, Endpoint-status och andra säkerhetsloggar.
7. Dokumentera beslut: ignorera, observera, blockera, undantag, incident.

För teknisk detaljanalys hjälper Sophos Firewall Troubleshooting: Services och Logs, Aktivera Central Firewall Reporting och Skicka Sophos Firewall Syslog till SIEM. Om det är oklart om rätt brandväggsregel träffades passar Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture.

Driftsrekommendation

För produktionsmiljöer är en trestegsmodell meningsfull:

1. Blockera: Blockera skadlig kod, nätfiske, bedrägeri, Command-and-Control, anonymiseringstjänster och andra klart riskfyllda kategorier.
2. Övervaka: Förse få känsliga kategorier med omedelbara varningar.
3. Utvärdera: Granska webb-rapporter, Central Reporting eller SIEM regelbundet.

Den viktigaste gränsen är organisatorisk: En varning behöver en mottagare, en reaktionstid och ett beslut om vad som händer med träffar. Annars blir omedelbara varningar bara ytterligare e-postbrus.

Checklista

• Web Protection-licens kontrollerad.
• Relevant brandväggsregel identifierad.
• Webbpolicy skapad eller anpassad.
• Webbpolicy vald i brandväggsregeln.
• Log firewall traffic aktiverad i regeln.
• Block QUIC protocol medvetet beslutad.
• TLS-inspektion medvetet planerad eller medvetet inte använd.
• Kritiska kategorier definierade.
• Omedelbara varningar aktiverade endast för få tydliga kategorier.
• System services > Notifications list > Web – Instant alerts aktiverad via e-post.
• Test utfört med Policy tester.
• Test utfört med verklig klienttrafik.
• Log Viewer kontrollerad.
• Central Reporting eller Syslog kontrollerad om central utvärdering förväntas.
• Ägare och reaktionsväg för varningar dokumenterad.

Återställ ändringar säkert

Dokumentera kategorins status, webbpolicyn och dess tilldelning i brandväggsregeln innan ändringen. Då kan man återställa enbart det som behövs utan att stänga av all webbfiltrering.

1. För att bara stoppa dessa varningar, inaktivera Instant alerts för kategorin under Web > Categories. Stäng inte av Email notifications globalt om andra systemhändelser använder e-post.
2. Om kategoriposter eller regelordningen ändrades, återställ de dokumenterade posterna och positionerna.
3. Om en annan webbpolicy tilldelades brandväggsregeln, återställ den tidigare under Rules and policies > Firewall rules > [Rule] > Security features > Web filtering.
4. Upprepa de ursprungliga testerna i Policy tester och på klienten och bekräfta sedan den förväntade åtgärden i Log Viewer.

En avisering som skapades före återställningen kan fortfarande komma i nästa femminutersbatch. Kriteriet för en lyckad återställning är att en ny kontrollerad begäran åter får den dokumenterade policyåtgärden. Om Instant alerts har inaktiverats får begäran inte utlösa ett nytt e-postmeddelande med webbvarning.

Felsökning

Om det förväntade resultatet saknas kontrolleras loggning, regelmatchning och policybeteende steg för steg.

Typiska fel

• Webbpolicy fungerar inte: Policyn är inte vald i brandväggsregeln. Kontrollera brandväggsregeln under Web filtering.
• Kategori tillåts trots att den borde blockeras: En bred tillåt-regel står ovanför blockregeln. Kontrollera ordningen i webbpolicyn och bland brandväggsreglerna.
• Ingen omedelbar varning: Kategorin övervakas inte, Email notifications är globalt avstängt eller händelsens kryssruta Email är inte markerad. Kontrollera Web > Categories, System services > Notifications list och därefter Administration > Notification settings.
• Ingen användaruppgift i loggen: Användaren känns inte igen eller regeln matchar inte utifrån användare. Kontrollera autentisering, STAS, Captive Portal eller klientlösa användare.
• HTTPS tillåts oväntat: Lämplig TLS-inspektion eller HTTPS-åtgärd saknas. Kontrollera webbpolicy, SSL/TLS-inspektionsregler och dekryptering.
• Webbfilter fungerar ofullständigt: QUIC eller en felaktig trafikväg kan vara orsaken. Kontrollera Block QUIC protocol, tjänster och Log Viewer.
• För många varningar: Kategoriurvalet är för brett. Minska varningslistan och utse en ansvarig.
• Domän saknas i logg/rapport: Domännamnet döljs för en särskilt kritisk kategori. Kontrollera kategorin och Sophos dokumenterade beteende.

Sophos blockerar alltid webbplatser i kategorin highly objectionable criminal activity och döljer domännamnet i loggar och rapporter. Om en post i detta område visas anonymiserad kan detta alltså vara avsiktligt.

Vanliga frågor