Konfigurera Sophos Firewall Web Protection med webbpolicyer

Sophos Firewall Web Protection styr vilka webbplatser, kategorier och webbinnehåll användare får åtkomst till. I praktiken är Web Protection dock inte bara en enkel kryssruta. En webbpolicy måste planeras noggrant, aktiveras i en lämplig brandväggsregel och sedan testas med verklig trafik.

Många fel uppstår eftersom en webbpolicy finns men inte tillämpas på någon aktiv brandväggsregel. Andra problem är relaterade till HTTPS, TLS-inspektion, QUIC, användarigenkänning, regelordning eller för grova undantag. Den meningsfulla processen är därför: planera policy, bygga regel, aktivera, testa och övervaka i drift.

Vilken artikel om Web Protection passar?

Web Protection överlappar med brandväggsregler, TLS-inspektion, QUIC, rapportering och undantag. Beroende på uppgift kan en mer specifik artikel passa bättre:

• Grundläggande inställning av Web Protection och webbpolicyer: Denna artikel.
• Förstå Single eller Dual Engine, skanningsfel, storleksgränser och ett verkligt malware-test: Konfigurera och testa malware-skanning i Sophos Firewall.
• Utvärdera webbkategorier, URL-grupper och omedelbara varningar: Använd Sophos Firewall webbkategorier och omedelbara varningar.
• Dekryptera och kontrollera HTTPS-trafik: Införa Sophos Firewall TLS-inspektion korrekt.
• Distribuera CA-certifikat för hanterade klienter: Distribuera Sophos Firewall CA-certifikat för TLS-inspektion.
• Klassificera QUIC och HTTP/3 vid webbfiltreringsproblem: Blockera Sophos Firewall QUIC och HTTP/3 korrekt.
• Ta reda på vilken brandväggsregel och policy som verkligen gäller: Testa Sophos Firewall-regel med Log Viewer, Policy tester och Packet Capture.
• Utvärdera webb- och säkerhetshändelser under längre tid: Central Firewall Reporting eller Skicka syslog till SIEM.

Så förblir analysen ren: Först måste det vara klart om brandväggsregeln matchar. Därefter kontrollerar man webbpolicy, kategori, användarkontext, QUIC, TLS-inspektion och loggning.

Vad Web Protection kontrollerar

Web Protection består av flera komponenter. Inte varje komponent behöver användas i varje miljö, men sambanden bör vara tydliga.

• Webbpolicy: Regler för tillåtna, varnade, blockerade eller kvotbaserade webbåtkomster.
• Webbkategorier: Sophos-kategorier och egna kategorier för webbplatser.
• URL-grupper: Egna domänlistor för riktade tillåt- eller blockregler.
• Filtyper: Kontroll av specifika nedladdnings- eller filtyper.
• Innehållsfilter: Termer eller mönster för innehållskontroll.
• Undantag: Riktade undantag från webb-, TLS- eller skanningsbeteende.
• Search engine enforcement: SafeSearch och YouTube-begränsningar.
• Advanced settings: begränsningar för Google Apps-inloggningsdomäner och Microsoft Entra ID Tenant Restrictions.
• Loggning och rapportering: Spårbarhet i Log Viewer, rapportering, Central eller SIEM.

Web Protection ersätter inte en ren brandväggsregelbas. Brandväggsregeln avgör först vilken trafik från vilken zon till vilken målzon som är tillåten. Webbpolicyn kompletterar denna regel med webbkontroll. Grunderna för regelordning, källa, destination, tjänster och säkerhetsprofiler finns i Förstå och bygga upp Sophos Firewall-regler korrekt.

Förutsättningar

Innan utrullning bör dessa punkter klargöras:

• Web Protection är licensierad eller ingår i det använda paketet.
• De berörda klientnäten har egna brandväggsregler.
• Loggning är aktiv i de relevanta reglerna.
• DNS och tid på brandväggen fungerar korrekt.
• Användarigenkänning är klar, om policyer ska gälla per användare eller grupp.
• TLS-inspektion är planerad om HTTPS-innehåll ska granskas noggrannare.
• QUIC/HTTP/3 tillåts eller blockeras medvetet.
• Det finns en pilotgrupp och en plan för att återställa den tidigare konfigurationen om verksamhetskritiska webbplatser slutar fungera.

Särskilt viktigt är separationen efter målgrupper. En webbpolicy för vanliga klienter, servrar, gäster, VPN-användare och hanteringssystem bör inte vara densamma. Servrar behöver ofta mindre webbläsarkontroll men strängare mål- och uppdateringslistor. Gäster behöver ofta kategorier och bandbreddsbegränsning men ingen åtkomst till interna resurser.

Om webbpolicyer ska reagera på användare eller grupper måste användarigenkänningen fungera. AD SSO, Captive Portal, STAS, SATC eller andra metoder bör inte upptäckas först under webbpolicyutrullningen. I Log Viewer måste det synas om en request bedömdes som känd användare, som grupp eller som Anybody respektive okänd användare.

Användarkriterierna i den matchande brandväggsregeln har företräde framför Users i webbpolicyn; policyn kan begränsa omfattningen men inte lägga till en användare som regeln utesluter.

Minsta fungerande konfiguration

Skapa policyn under Web > Policies och aktivera minst ett avgränsat Allow/Block-beslut i den.

Redigera därefter en verklig regel under Rules and policies > Firewall rules med Action: Accept, rätt Source Zone och Source Network, Destination Zone och Destination Network samt nödvändiga Services. Aktivera Log firewall traffic och tilldela webbpolicyn under Web filtering. Kontrollera bara att befintlig NAT stämmer med den nuvarande internetvägen; inför inte ett nytt NAT-beteende enbart för policyn. Dokumentera Rule ID och resultatet för samma avsiktligt tillåtna och blockerade requests före och efter ändringen från verklig käll- och användarkontext. Godkänn först när Log Viewer visar förväntad Rule ID, policy och verkliga Allow- och Block-resultat.

Planera webbpolicy

En bra webbpolicy börjar inte i gränssnittet utan med några tekniska beslut.

Definiera målgrupper

Först fastställs för vem policyn gäller:

• Standardklienter i LAN
• Hanterade bärbara datorer via VPN
• Gäst-WLAN
• Utbildningsrum eller skolmiljöer
• Servrar med utgående HTTP/HTTPS-åtkomst
• Privilegierade administratörsarbetsplatser

Om samma brandväggsregel innehåller flera mycket olika grupper blir Web Protection svår att förstå. Bättre är separata regler och policyer, till exempel LAN_USERS_WEB, GUEST_WEB eller SERVER_UPDATES_WEB.

Fastställ kategorier och URL-grupper

Kategorin highly objectionable criminal activity blockeras alltid. Varken policyregler eller undantag kan tillåta kategorin; SFOS döljer dessutom domänen i loggar och rapporter.

Sophos-webbkategorier är bra för bred styrning: Malware, Phishing, Adult Content, Anonymizer, Streaming, Social Media eller Games. URL-grupper är bättre när enskilda domäner ska tillåtas eller blockeras specifikt.

Typisk användning:

• Blockera kända riskkategorier: Webbkategori.
• Tillåta specifika SaaS-domäner: URL-grupp.
• Hantera enskild felkategoriserad domän: URL-grupp eller egen kategori.
• Begränsa streaming tidsmässigt: Webbpolicy med schema eller kvot.
• Varningssida istället för hård blockering: Webbpolicy med varningsåtgärd.

URL-grupper bör inte bli en osorterad samlingslista. Om många domäner läggs till behöver listan en ägare, ett syfte och ett granskningsdatum. För mycket stora eller dynamiska listor är Sophos Firewall Threat Feeds eller andra arkitekturkomponenter ofta mer lämpliga.

Skapa och använd URL Groups säkert förklarar hur giltiga domänvärden, OR-logik, användning i Web Policy och TLS-undantag hänger ihop.

För rena domänmatchningar är URL-grupper oftast bättre än egna Web Categories. Sophos påpekar att URL-grupper är mer performanta och kan ge färre false positives. Egna kategorier är användbara när en domän dessutom ska ingå i en egen policylogik utöver sin standardkategori från Sophos.

Keywords i egna kategorier bör användas mycket försiktigt. Keywords kontrolleras mot hela URL:en inklusive path och query. Ett allow baserat på ett keyword kan därför träffa oavsiktligt om ordet finns i en queryparameter på en annan domän. För allow-beslut är konkreta domäner eller URL-grupper oftast renare; keyword-regler passar bättre för smala blockeringsfall.

Sätt tillåt-regler försiktigt

Tillåt-regler i webbpolicyer bör vara snäva. En tillåt-regel högt upp kan göra senare blockregler ineffektiva eftersom Sophos webbpolicy-regler utvärderas uppifrån och ner. Detta är särskilt relevant om en URL-grupp, en filtypsregel eller ett kategoriundantag står ovanför andra regler.

Praktiskt beprövat:

Ett verksamhetsrelaterat tillåt-undantag ovanför kritiska blockregler gäller bara inom sitt snävt definierade tillämpningsområde. Om en riskkategori ska förbli blockerad utan undantag måste dess blockregel ligga ovanför alla matchande Allow-regler. Ordningen kontrolleras med ett tillåtet verksamhetsmål och ett blockerat mål inom undantagets tillämpningsområde; ett domänundantag får inte oavsiktligt tillåta alla filtyper eller allt innehåll på målet.

• Varnings- eller kvotregler för gråzoner.
• Allmänt tillåten webtrafik först i slutet.

Skapa webbpolicy

Webbpolicyn skapas under följande meny:

Web > Policies

Grundläggande steg:

1. Välj Add policy.
2. Ge ett beskrivande namn, till exempel LAN_USERS_STANDARD_WEB.
3. Lägg till regler.
4. Kontrollera search engine enforcement, till exempel SafeSearch eller YouTube restrictions.
5. Sätt policy quota status om Quota-åtgärder används.
6. Kontrollera Advanced settings, särskilt logging, reporting, stora nedladdningar, Google Apps och Microsoft Entra ID Tenant Restrictions.
7. Spara policyn.

En regel i webbpolicyn skapas med Add rule. Brandväggen skapar först en inaktiverad standardregel som blockerar HTTP för Anybody. Därefter justeras fälten medvetet:

1. Öppna Users och sätt medvetet Anybody, konkreta användare eller grupper.
2. Öppna Activities och välj All web traffic, User activities, Categories, URL Groups eller File types.
3. För innehåll, välj den separata fliken Content filters, välj filtret, aktivera and with content och behåll HTTPS som Use action.
4. Sätt Action för HTTP: Allow, Warn, Block eller Quota.
5. Kontrollera HTTPS-åtgärden: Use action, Allow HTTPS, Warn HTTPS, Block HTTPS eller Quota HTTPS.
6. Sätt Constraints om regeln bara ska gälla enligt ett schema.
7. Kontrollera regelpositionen inom policyn.
8. Aktivera regelns status.
9. Spara policyn.

Under Users > Add new item avmarkeras Anybody om endast specifika användare eller grupper avses. Under Activities > Add new item avmarkeras All web traffic innan enskilda Activities väljs. Bekräfta varje val med Apply selected items. Annars förblir regeln onödigt bred trots att enskilda objekt har lagts till. HTTP-åtgärderna heter Allow HTTP, Warn HTTP, Block HTTP och Quota HTTP; Use action tillämpar samma beslut för HTTPS. För Content filters är denna koppling fast och kan inte ersättas med en annan HTTPS-åtgärd.

Importera innehållsfilterlistor korrekt

Content filters hanteras under Web > Content filters och väljs sedan under Activities i webbpolicyregeln. För större termlistor stöder Sophos en enkel .txt-fil. Filen får innehålla högst 2,000 rader och varje post får vara högst 80 tecken lång, inklusive blanksteg och skiljetecken.

Importfilen innehåller en term per rad och varje rad utvärderas som exact match. Rubriker, kommentarer, metadata eller extra kolumner ska inte finnas; använd UTF-8.

Säker arbetsgång:

1. Rensa termerna i en textredigerare och placera exakt en post per rad.
2. Spara filen som .txt med UTF-8-kodning.
3. Importera listan under Web > Content filters och ge den ett tydligt namn.
4. Öppna Content filters i Activities, välj filtret, aktivera and with content och behåll Use action.
5. Testa med en pilotklient en tillåten term och en term som avsiktligt matchar, och kontrollera åtgärden i Log Viewer.

Om en import avvisas eller enskilda termer inte tillämpas ska man först kontrollera antalet rader, teckenlängden, kodningen och osynliga extratecken. En bred Allow-regel ovanför Content filter-regeln får inte kringgå listan.

För importen väljer du Add content filter, anger namnet, väljer exempelvis blocked.txt via Choose file och klickar på Apply. Kontrollera därefter uttryckligen Block HTTP och Use action för HTTPS i webbpolicyregeln, bekräfta filtret med Apply selected items, aktivera Status och spara policyn. Enbart importen aktiverar ingen blockering. För piloten är en separat, tilldelad policy lämpligare än en okontrollerad ändring av den gemensamma Default Policy.

Skapa anpassade filtyper för webben

Sophos Firewall identifierar File types utifrån filändelsen eller MIME-headern. De inbyggda typerna kan inte redigeras. Skapa en anpassad typ under Web > File types > Add från en lämplig mall och lägg till de nödvändiga filändelserna utan inledande punkt eller MIME-headrar. Samma objekt kan sedan användas i policyer för webb- och e-postskydd.

Ange ett namn i dialogrutan Add. Template är valfritt och fyller i de vanliga filändelserna och MIME-headrarna för en kategori; du kan lägga till värden för den anpassade typen. Spara sedan med Save. Skriv inte en punkt före filändelsen: pdf är rätt och .pdf är fel. Inbyggda typer fungerar som mallar och kan inte redigeras; skapa en anpassad typ när något behöver ändras.

SFOS har de inbyggda kategorierna All executable files, Audio files, Backup files, Compressed files, Configuration files, Database files, Developer files, Disk image files, Document files, Dynamic files, Encoded files, Executable files, Image files, Page layout files, Plugin files, System files, Video files och Web files. Detaljvyn under Web > File types är den operativa källan för de filändelser och MIME-headrar som är konfigurerade för tillfället. Compressed files innehåller till exempel bland annat 7z, gz, rar, tar.gz och zip, medan Document files bland annat innehåller docx, xlsx, pptx, odt, rtf och pdf. Öppna därför den konkreta inbyggda typen i den egna SFOS-versionen och jämför den med det verkliga användningsfallet innan kategorin tillåts, i stället för att enbart utgå från namnet.

Den nya filtypen har ingen effekt i sig. Den måste väljas under Activities > File types i den berörda webbpolicyregeln. Kontrollera därefter åtgärden, regelns status och ordning samt att webbpolicyn fortfarande är tilldelad den brandväggsregel som faktiskt hanterar trafiken.

Validera med en representativ nedladdning och en avsiktligt liknande fil som inte ska matcha. Kontrollera webbpolicy och åtgärd i Log Viewer. En matchning på filändelse eller MIME-header är en policyklassificering, inte ett bevis på malware eller en genomförd Zero-Day-analys. För HTTPS beror den nödvändiga insynen också på TLS Inspection-sökvägen. Om typen inte matchar ska du först jämföra regelns status och ordning, den File Type som faktiskt valts, serverns Content-Type-svar, den synliga filändelsen och TLS Inspection-statusen. En felaktig eller generell MIME-typ från servern kan göra att testet ger ett annat resultat än filnamnet antyder.

Referens för de inbyggda filtyperna

Följande referens kopplar de dokumenterade filändelserna och MIME-headrarna till de inbyggda kategorierna. Den beskriver en klassificering, inte en tillåten eller säker fil. Kontrollera värdena mot den egna installationen före ändringar. All executable files täcker även körbara Mac-/Linux-filer genom ytterligare MIME-headrar; Executable files är inriktad på Windows. Dynamic files genererar dynamiskt webbinnehåll, medan Encoded files bland annat omfattar krypterat eller binärkodat innehåll. Kategorier kan överlappa: mdf finns exempelvis under databaser och Disk Images, tar under dokument och tar.gz under komprimerade filer. I synnerhet är application/octet-stream under Backup files ett generiskt MIME-värde, inte ett säkert bevis på att det är en säkerhetskopieringsfil.

All executable files

• Filändelser: exe, cmd, bat, com.
• MIME-headrar: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/x-dosexec, application/x-mach-binary, application/x-executable.

Audio files

• Filändelser: gsm, sd2, qcp, kar, smf, midi, mid, ulw, snd, aifc, aif, aiff, m3url, m3u, wav, rm, ram, mp3, wmv.
• MIME-headrar: audio/x-gsm, audio/vnd.qcelp, audio/x-midi, application/x-midi, audio/midi, audio/x-mid, x-music/x-midi, audio/basic, audio/x-adpcm, audio/aiff, audio/x-aiff, audio/x-mpequrl, audio/wav, audio/x-wav, application/vnd.rn-realmedia, audio/x-au, audio/x-pn-realaudio, audio/mpeg3, audio/x-mpeg-3, audio/x-ms-wmv, audio/ac3, audio/x-ape, audio/flac, audio/mpeg, audio/mp4, audio/ogg.

Backup files

• Filändelser: asd, bak, bkp, bup, dba, dbk, fbw, gho, nba, old, ori, sqb, tlg, tmp.
• MIME-headrar: application/octet-stream.

Compressed files

• Filändelser: 7z, alz, deb, gz, pkg, pup, rar, rpm, sea, sfx, sit, sitx, tar.gz, tgz, war, zip, zipx.
• MIME-headrar: application/x-7z-compressed, application/x-alz, application/x-deb, application/x-gzip, application/x-newton-compatible-pkg, application/x-rar-compressed, application/sea, application/x-sea, application/x-sit, application/x-stuffit, application/gnutar, application/x-compressed, application/x-zip-compressed, application/zip, multipart/x-zip.

Configuration files

• Filändelser: cfg, clg, dbb, ini, keychain, prf, prx, psf, rdf, reg, thmx, vmx, wfc.
• MIME-headrar: application/pics-rules, application/vnd.ms-officetheme.

Database files

• Filändelser: accdb, db, mdsn, mdb, mdf, pdb, sql, sqlite.
• MIME-headrar: application/msaccess, application/x-msaccess, application/vnd.msaccess, application/vnd.ms-access, application/mdb, application/x-mdb, chemical/x-pdb.

Developer files

• Filändelser: rb, src, tcl, trx, v, vbproj, vcproj, vtm, xcodeproj, asc, cbl, cp, cpp, csproj, dev, fs, fsproj, fsx, ftl, gem, hpp, ise, ism, java, ocx, pas, pod, r.
• MIME-headrar: text/pascal, application/x-bsh, application/x-sh, text/x-script.sh, application/x-wais-source, application/x-tcl, text/x-script.tcl, application/x-shar.

Disk image files

• Filändelser: dmg, iso, mdf, nrg, nri, pvm, toast, vcd, vmdk.
• MIME-headrar: application/x-cdlink.

Document files

• Filändelser: doc, docx, wbk, xls, xlsx, ppt, pptx, oft, pub, msg, one, xsf, xsn, grv, mpp, mpt, acl, pip, bld, blg, bvp, cdd, cdf, contact, csv, dif, dmsp, efx, epub, epw, exif, exp, fdb, fxp, gbr, gpi, hdf, id2, lib, mat, mcd, menc, ndx, not, notebook, out, ovf, pdx, pfc, pps, ppsx, pptm, prj, qbw, sdf, svf, tar, tsv, vdb, odt, opml, pages, rtf, sig, tex, wpd, wps, pdf.
• MIME-headrar: application/msword, application/vnd.openxmlformats-officedocument.wordprocessingml.document, application/excel, application/vnd.ms-excel, application/x-excel, application/x-msexcel, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, application/mspowerpoint, application/powerpoint, application/vnd.ms-powerpoint, application/x-mspowerpoint, application/vnd.openxmlformats-officedocument.presentationml.presentation, application/x-mspublisher, application/onenote, application/vnd.ms-project, application/x-project, application/cdf, application/x-cdf, application/x-netcdf, video/x-dv, application/x-hdf, application/mcad, application/x-mathcad, application/vnd.openxmlformats-officedocument.presentationml.slideshow, application/vnd.ms-powerpoint.presentation.macroEnabled.12, image/vnd.dwg, image/x-dwg, application/x-tar, text/x-vcard, application/rtf, application/x-rtf, text/richtext, application/x-tex, application/wordperfect, application/x-wpwin, application/vnd.ms-works, application/pdf, application/vnd.oasis.opendocument.graphics, application/vnd.oasis.opendocument.presentation, application/vnd.oasis.opendocument.formula, application/vnd.oasis.opendocument.text, application/vnd.oasis.opendocument.spreadsheet, application/vnd.ms-excel.addin.macroEnabled.12, application/vnd.ms-excel.sheet.binary.macroEnabled.12, application/vnd.ms-excel.sheet.macroEnabled.12, application/vnd.ms-excel.template.macroEnabled.12, application/vnd.ms-powerpoint.addin.macroEnabled.12, application/vnd.ms-powerpoint.slideshow.macroEnabled.12, application/vnd.ms-powerpoint.template.macroEnabled.12, application/vnd.ms-word.document.macroEnabled.12, application/vnd.ms-word.template.macroEnabled.12, application/vnd.openxmlformats-officedocument.presentationml.template, application/vnd.openxmlformats-officedocument.spreadsheetml.template, application/vnd.openxmlformats-officedocument.wordprocessingml.template.

Dynamic files

• Filändelser: jsp, asp, php, cgi, shtml.
• MIME-headrar: text/x-script.perl, text/asp.

Encoded files

• Filändelser: bin, enc, hex, hqx, mim, mime, uue.
• MIME-headrar: application/mac-binary, application/macbinary, application/x-binary, application/x-macbinary, application/binhex, application/binhex4, application/mac-binhex, application/mac-binhex40, application/x-binhex40, application/x-mac-binhex40, message/rfc822, www/mime, text/x-uuencode.

Executable files

• Filändelser: exe, cmd, bat, com.
• MIME-headrar: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/x-dosexec.

Image files

• Filändelser: bmp, gif, jpeg, jpg, pcx, png.
• MIME-headrar: image/bmp, image/x-windows-bmp, image/gif, image/pjpeg, image/jpeg, image/x-pcx, image/png, image/jp2, image/vnd.adobe.photoshop, image/tiff.

Page layout files

• Filändelser: idml, indd, inx, isd, mdi, pmd, ptx, pub, qxb, qxd, qxp, rels, xps.
• MIME-headrar: application/x-mspublisher, application/vnd.ms-xpsdocument.

Plugin files

• Filändelser: 8bi, arx, plugin, vst, xll.
• MIME-headrar: application/x-visio.

System files

• Filändelser: bashrc, cab, cpl, cur, dll, dmp, drv, hlp, key, lnk, msp, prf, profile, scf, scr, sys.
• MIME-headrar: application/vnd.ms-cab-compressed, application/x-msdownload, application/hlp, application/x-helpfile, application/x-winhelp.

Video files

• Filändelser: dat, mov, avi, qt, smi, sml, smil, flc, fli, vfw, mpeg, mpg, m15, m1u, m1a, m75, mls, mp2, mpm, rm, wmv, flv, swf.
• MIME-headrar: application/x-troff-msvideo, video/avi, video/msvideo, video/x-msvideo, video/quicktime, application/smil, application/x-simile, Video/flc, video/fli, video/x-fli, video/mpeg, video/x-mpeg, video/x-mpeq2a, application/vnd.rn-realmedia, video/flv, application/x-shockwave-flash, video/x-flv, video/x-ms-asf, video/3gpp, video/mp4, video/mj2.

Web files

• Filändelser: alx, asax, asmx, aspx, atom, att, axd, chm, dwt.
• MIME-headrar: application/atom+xml.

Samla User Activities tydligt

Under Web > User activities > Add samlar en User activity Web Categories, File types och URL Groups i en återanvändbar aktivitet. Dessa element utvärderas med OR; en enda matchning räcker. Namnet syftar alltså inte på en inloggad användare utan på en samling webbkriterier.

Välj sedan User Activity under Activities i webbpolicyregeln. Det passar när samma kombination används i flera policyer. Validera med minst en matchning för varje ingående objekttyp och ett liknande fall som inte ska matcha.

Ange ett beskrivande namn, exempelvis RISK_WEB_CONTENT, i dialogrutan, välj de kategorier, filtyper eller URL Groups som behövs via Add new item och spara med Save. Show: All begränsar vid behov vilka objekttyper som visas. En aktivitet kan exempelvis samla kategorin Spyware/Malware och en egen lista med blockerade testdomäner: redan ett av dessa kriterier utlöser webbpolicyregelns blockeringsåtgärd. Använd ofarliga mål som du själv kontrollerar för testerna; öppna ingen verklig malware-sida.

Kontrollera regelordning och migrerade policyer

Webbpolicyregler utvärderas uppifrån och ned. Om exempelvis en Allow-regel för filtypen .mdb ligger ovanför en regel som blockerar en kategori, förblir .mdb-nedladdningar från den kategorin tillåtna. I DPI-läge kan den första anslutningen till kategorin tillåtas tills filtypen är känd; om filen därefter inte matchar avbryter brandväggen anslutningen utan att visa en blockeringssida. Om kategorin alltid ska blockeras måste dess regel ligga ovanför filtypens Allow-regel.

För migrerade äldre policyer gäller dessutom en hård gräns på 128 regler per policy. Om källan innehåller fler regler använder SFOS endast de första 128. Intilliggande regler för User Activities, Categories, URL Groups, File types och Dynamic Categories bör därför medvetet slås samman till kombinerade Activities före eller efter migreringen. Regelantal, ordning och verkliga Allow- och Block-tester ingår i migreringsvalideringen.

Återkommande tidsfönster skapas som ett separat schema. Förfarandet och avgränsningen mot en tidsstyrd brandväggsregel beskrivs i Konfigurera scheman för regler och policyer i Sophos Firewall.

En webbpolicy i sig har ingen effekt. Policyn måste sedan användas i en brandväggsregel. Detta är ett av de vanligaste konfigurationsfelen.

Slå endast samman intilliggande regler med samma användartilldelning, HTTP-/HTTPS-åtgärd och tidsvillkor. Skillnader i Content filters, Constraints eller ordning får inte gå förlorade. Säkerhetskopiera eller dokumentera den gamla policyn före sammanslagningen och dokumentera representativa matchningar och icke-matchningar för varje Activity. Kontrollera dessa beslut igen efter sammanslagningen; ett lägre regelantal är i sig inget bevis på likvärdig skyddseffekt.

Ställ in Advanced settings medvetet

Enable logging and reporting inkluderar policyn i loggar och rapporter; dessutom behövs fortfarande Log firewall traffic i den matchande brandväggsregeln. Prevent downloading of large files blockerar nedladdningar som överstiger den angivna storleken. Välj gränsvärdet utifrån de nedladdningar som verksamheten faktiskt behöver och testa med ofarliga filer under och över gränsen; denna nedladdningsblockering är inte samma sak som en storleksgräns för malware-skanning.

Add X-Forwarded-For header to outgoing HTTP requests vidarebefordrar IP-adressen för den ursprungliga HTTP-begäran till målet. Denna kryssruta behövs inte för webbfiltrering. Aktivera den endast om det finns ett motiverat behov, eftersom målservern då får ytterligare klientinformation; bedöm först konsekvenserna av att vidarebefordra interna adresser och kraven på dataskydd. Dokumentera de tidigare värdena inför piloten och återställ exakt dessa ändringar vid oönskade effekter.

Aktivera webbpolicy i brandväggsregel

Brandväggsregeln finns under:

Rules and policies > Firewall rules

För normal klient-internettrafik ansvarar oftast en regel från LAN eller en klientzon till WAN. Där väljs den lämpliga webbpolicyn i avsnittet Web filtering.

Kontrollpunkter i brandväggsregeln:

• Källzon och källnätverk matchar klientnätet.
• Destinationszon är vanligtvis WAN.
• Tjänster innehåller HTTP/HTTPS eller de önskade webbtjänsterna.
• Log firewall traffic är aktiv.
• I avsnittet Web filtering är rätt webbpolicy inställd.
• Scan HTTP and decrypted HTTPS är aktiverad när web-malware- eller innehållsskanning ska fungera.
• Use Zero-day protection är bara meningsfull om filer skannas via HTTP eller dekrypterad HTTPS.
• Block QUIC protocol är medvetet inställd.
• På brandväggsregelns transparenta väg är Use web proxy instead of DPI engine aktiverad för SafeSearch, YouTube Restrictions och Google Apps-begränsningar; för andra funktioner och Direct Proxy väljs läget medvetet efter behov.
• TLS-inspektion planeras separat och förväxlas inte med webbpolicy.

Sophos Firewall aktiverar Block QUIC protocol som standard när en webbpolicy väljs i regeln eller Scan HTTP and decrypted HTTPS aktiveras. Det är ofta vettigt eftersom QUIC inte kan skannas som klassisk HTTPS-trafik. Ändå bör kryssrutan testas medvetet: webbläsare, Google-tjänster, samarbetsverktyg och enskilda SaaS-applikationer kan ändra beteende när QUIC blockeras.

Om Application Control också används i samma brandväggsregel finns en viktig överlappning: vissa Micro Apps, till exempel uppladdningar eller nedladdningar i Dropbox eller Gmail, identifieras via URL-detaljer. I DPI-miljöer kräver denna identifiering en lämplig SSL/TLS Inspection-regel med dekryptering. Application Control kan då utvärdera sådana Micro Apps även om webbpolicyn inte är den egentliga beslutspunkten.

Om en mer allmän regel ovanför den önskade webbregeln matchar, når trafiken inte webbpolicyn. I sådana fall hjälper Testa Sophos Firewall-regel med Log Viewer och Packet Capture.

Bedöma HTTPS, TLS-inspektion och QUIC

En stor del av webtrafiken är HTTPS. Utan TLS-inspektion ser brandväggen mindre innehåll. Kategorier, SNI, certifikat, mål-IP, domäninformation och metadata hjälper, men ersätter inte en fullständig innehållsgranskning.

DPI eller Web Proxy?

Vid Web Protection måste man tidigt bestämma om den berörda brandväggsregeln använder DPI Engine eller Web Proxy. Detta beslut påverkar vilka funktioner som gäller och vilka loggar som senare är relevanta.

• DPI-läge: Modern standard för många klient-internetregler. TLS-inspektion sker via SSL/TLS-inspektionsregler, kvot stöds inte.
• Web Proxy-läge: Passar miljöer med explicit proxybeteende eller policykvot; proxybeteende, webbläsar- och klientkompatibilitet samt proxyloggar måste kontrolleras medvetet.

I många installationer är DPI-läge den bättre startpunkten. Men om tidskontingenter behövs via Quota räcker inte en ren DPI-regel. Då måste Web Proxy-läge planeras och testas medvetet. Detta beslut bör fattas före utrullning eftersom en senare förändring kan skapa andra felbilder, loggar och användarupplevelser.

I en transparent brandväggsregel hanterar Transparent Web Proxy bara de klassiska portarna 80 och 443. På andra portar kan DPI Engine inspektera HTTP- och SSL/TLS-trafik om både brandväggsregeln och SSL/TLS Inspection-reglerna passar. Direct Proxy är däremot en separat, explicit väg som klienten väljer och kräver inte nödvändigtvis Use web proxy instead of DPI engine. Dokumentera därför vid varje test om klienten använder den transparenta vägen eller sin explicita proxykonfiguration.

Det fullständiga funktionsvalet, pilotmigreringen och de lägesspecifika kontrollerna finns i Jämför DPI Engine och Web Proxy korrekt.

Konfigurera Direct Web Proxy med en PAC-fil förklarar hur listener, PAC-fil, Device Access och en fungerande proxyregel hör ihop.

IPv6-only-klienter som når IPv4-only-webbmål använder en separat väg med två regler. NAT64 med Direct Web Proxy skiljer Web Policy i IPv6-regeln från Application Control och IPS i IPv4-egress.

Om Sophos Firewall ska vidarebefordra sina Web Requests till en parent proxy leder konfigurera en upstream proxy i WAN eller LAN/DMZ genom rätt regel- och NAT-väg för varje topologi.

När flera RDS-användare delar samma server-IP kan Per-Connection AD SSO för fleranvändarvärdar skilja de enskilda HTTP- och HTTPS-proxyanslutningarna åt. Metoden gäller inte trafik utanför proxyn och måste därför medvetet avgränsas mot SATC.

TLS-inspektion

Om nedladdningar, malware-skanning, vissa webbkategorier eller innehållskontroller ska granskas pålitligt måste TLS-inspektion planeras. För detta behövs ett betrott CA-certifikat på klienterna, lämpliga TLS-regler, undantag och en ren pilot.

Utrullningen finns i Rulla ut TLS-inspektion på Sophos Firewall steg för steg. För distribution och validering av CA-certifikatet passar Installera Sophos Firewall CA-certifikat för HTTPS-skanning.

QUIC och HTTP/3

Moderna webbläsare använder ofta QUIC respektive HTTP/3 över UDP 443. Detta kan störa webbfilter-, TLS-inspektions- och skanningsförväntningar om man egentligen vill kontrollera klassisk HTTPS-trafik över TCP.

I många företagsmiljöer är det vettigt att blockera QUIC i klient-internetregler så att webbläsare faller tillbaka på HTTPS över TCP. Detaljerna finns i Blockera Sophos Firewall QUIC och HTTP/3 korrekt.

SafeSearch, YouTube och Tenant Restrictions

SafeSearch och YouTube finns i Search engine enforcement; Google Apps och Entra i Advanced settings.

Typiska alternativ:

• Enforce SafeSearch för Google, Yahoo och Bing.
• Enforce YouTube restrictions för begränsat YouTube-innehåll.
• Restrict login domains for Google Apps för tillåtna Google-domäner.
• Apply Microsoft Entra ID tenant restrictions för Microsoft-moln-tenant-styrning.

XML-API-referensen för SFOS 22/23 beskriver EnforceSafeSearch som tillämplig endast när kategorierna Adult Content, Nudity och Porn nekas i Web Policy. Kontrollera dessa beslut i den policy som faktiskt har tilldelats trafiken; att aktivera alternativet och uppfylla förutsättningarna för proxy och HTTPS scanning räcker inte för att visa att detta dokumenterade villkor är uppfyllt. Kravet i API-dokumentationen garanterar inte samma gränssnittsbeteende eller körningsbeteende i alla builds. Om hjälpen för den installerade builden anger något annat ska skillnaden klargöras innan man förlitar sig på SafeSearch.

På brandväggsregelns transparenta väg kräver SafeSearch, YouTube Restrictions och Google Apps Use web proxy instead of DPI engine; en explicit Direct Proxy kan tillhandahålla dessa proxyfunktioner utan det alternativet i brandväggsregeln. Bing och Yahoo via HTTPS kräver dessutom HTTPS scanning. Hantera Entra Tenant Restrictions separat, testa verkliga Microsoft-inloggningar och behåll styrningen av identiteter och molnappar i Microsoft 365 eller Google Workspace.

För Bing och Yahoo kan SafeSearch bara tvingas på HTTPS-anslutningar om HTTPS scanning är aktiv i den berörda brandväggsregeln. Google Apps-inloggningsbegränsningar gäller endast Google-hostade domäner. Microsoft Entra ID Tenant Restrictions behöver rena tenant-värden och bör testas med verkliga Microsoft-molninloggningar, inte bara med en exempel-URL.

Under Apply Microsoft Entra ID tenant restrictions innehåller Restrict-Access-To-Tenants de tillåtna tenanterna som en kommaseparerad lista med domännamn eller domän-ID:n, högst 256 tecken totalt. Restrict-Access-Context innehåller domän-ID:t för den tenant som fastställer begränsningen, högst 50 tecken. Hämta dessa värden från den egna tenantadministrationen, inte från någon annans exempelkonfiguration. Säkerhetskopiera först de befintliga värdena; testa därefter en tillåten och en otillåten tenantinloggning i piloten och återställ vid fel endast de ändrade värdena till det tidigare läget.

Kvot och varningssidor

Webbpolicyer kan inte bara blockera eller tillåta. Med varnings- eller kvotåtgärder kan man medvetet informera användare eller tillåta tidsbegränsad åtkomst.

Meningsfulla exempel:

• Användare får medvetet bekräfta en varning för vissa gråzoner.
• Streaming eller shopping är endast tillåtet tidsbegränsat.
• Skol- eller laboratoriemiljöer tillåter vissa kategorier endast under definierade tider.

Viktigt: Policykvot stöds inte i DPI-läge. Om tidskontingenter behövs måste Web Proxy-läge användas. Detta bör beslutas tidigt eftersom DPI och Web Proxy har olika egenskaper och begränsningar.

Allowed time quota sätts på webbpolicynivå och gäller för alla regler i denna policy som använder en Quota-åtgärd. Om två kategorier behöver olika tidskvoter är separata webbpolicyer renare än en enda policy med blandade kvotförväntningar. Kvoter återställs lokalt vid midnatt och kan inte sättas till noll.

Policy Quota gäller inte Content filters eller Dynamic Categories och stöds inte av DPI. Ändringar fungerar inte med ogiltig policy, utan återstående tid eller när en Quota-session redan är aktiv.

Denna Policy Quota gäller för webbkategorier och är inte den användarbaserade Surfing Quota. Att skapa, tilldela och kontrollera förbrukningen för Surfing Quota och Network Traffic Quota följer ett separat arbetsflöde.

När ett mål med Quota-åtgärd öppnas visas först kvotsidan. Användaren väljer en tidsperiod upp till den tillgängliga kvoten och Proceed, eller avstår från åtkomst med Return to previous page. När den valda tidsperioden löper ut visas sidan igen; om kvoten är förbrukad erbjuds ingen återstående tid. En Policy Override kan i stället ge tillfällig åtkomst; då gäller inte kvoten. Override-behörigheten får därför inte aktiveras som ett fritt alternativ för alla användare.

En matchande SSL/TLS-inspektionsregel med Action > Deny blockerar fortfarande; mer kvot eller en återställning löser inte denna konflikt. Kontrollera först om TLS-blockeringen är avsiktlig utifrån verksamhetens krav. Planera endast en Web Exception som hoppar över HTTPS-dekryptering för ett uttryckligen godkänt, snävt avgränsat fall. Den tar även bort kontroller som är beroende av dekrypteringen och kan tillåta ogiltiga servercertifikat; använd den inte som standardlösning. Testa tillåten pilotåtkomst, fortsatt blockering utanför undantagets tillämpningsområde och återställningen genom att avaktivera pilotundantaget separat. Den faktiska avgränsningen för en Web Exception måste utgöras av de kriterier som den stöder, exempelvis pilotens käll-IP tillsammans med det bekräftade värdnamnsmönstret – inte kvotanvändarens grupp.

Kontrollera Policy Quota i drift

Under Web > Policy quota status visar SFOS den återstående tiden för enskilda användare i berörda Web Policies inom en 24-timmarsperiod. Den valda användaren kan återställas där med Reset. Detta är en medveten statusändring och ingen diagnosknapp: dokumentera först användare, policy, återstående tid, orsak och tidpunkt.

Denna reset gäller den tidsbaserade Policy Quota för en webbkategori. Den är inte samma sak som Reset user accounting för Surfing Quota eller Network Traffic Quota. En reset korrigerar varken fel regelordning eller saknad användaridentifiering.

Anpassa varnings- och blockeringssidor

Under Web > User notifications kan egna bilder och blockerings-, override-, quota- och varningsmeddelanden konfigureras. Platshållarna {category}, {user} och {url} infogar webbkategori, användarnamn och blockerad URL. Preview kontrollerar presentation och text, men inte om rätt Web Policy och brandväggsregel matchar produktionsanropet.

Meddelandet ska kort förklara varför åtkomsten blockerades eller varnades och var ett legitimt verksamhetsbehov kan rapporteras. Användarnamn och URL:er kan innehålla känslig information; sidan ska därför inte innehålla interna hemligheter, lösenord eller onödiga kontaktuppgifter.

För bilder aktiverar du Use custom images och väljer önskade bilder. För texter aktiverar du Use custom block message, Use custom override message, Use custom quota message eller Use custom warn message och anger texten. Öppna den tillhörande Preview-länken och testa därefter rätt meddelandetyp med en verklig pilotbegäran. Använd inga verkliga kunduppgifter i testbilder.

Begränsa Policy Overrides säkert

En användare som redan har auktoriserats av administratören skapar sin session i User Portal så här:

1. Öppna My policy overrides > Add och ange ett beskrivande sessionsnamn.
2. Behåll den förvalda åtkomstkoden eller skapa en ny med Generate access code. En egen manuellt skapad kod är endast tillåten om uttrycklig behörighet har beviljats.
3. Välj de tillåtna webbplatser och webbkategorier som behövs; mål som administratören har spärrat för overrides kan inte tillåtas.
4. Välj ett befintligt schema i listan under Restricted to time periods. Här väljs ett schema, inte ett valfritt tidsintervall som anges i fritext.
5. Spara med Apply. Ange därefter åtkomstkoden i kodfältet på blockeringssidan vid en matchande blockerad begäran.

Med Status aktiverar eller avaktiverar användaren denna override-session. Detta är inte samma sak som den administrativa hanteringen via View overrides: administratören kan oberoende av användarens val aktivera, avaktivera eller radera den session som användaren har skapat. Utan auktorisering är detta användarflöde inte tillgängligt; begränsningen till AD-huvudgruppen och enskilda användare gäller fortfarande.

Policy Overrides är ett annat verktyg än kvoter. Med Enable policy override kan auktoriserade användare skapa tillfällig åtkomst till normalt blockerade webbplatser i User Portal. Authorized users and groups begränsar vilka som får göra det och Blocked websites and categories anger mål som aldrig får åsidosättas. Allow manual access code entry aktiveras bara om användarskapade koder passar godkännandeprocessen.

Dokumentera först det tidigare läget och behöriga användare under Web > General settings > Policy overrides. Den behöriga användaren anger webbplatser eller kategorier, ett begränsat tidsintervall och en åtkomstkod för overriden i User Portal. När ett matchande blockerat mål begärs innehåller blockeringssidan ett extra fält för den koden. Om Allow manual access code entry är aktiverat får de angivna användarna skapa egna koder; om alternativet är avaktiverat måste de använda genererade koder. Detta val ska inte förväxlas med att ange en redan giltig kod på blockeringssidan.

Med View overrides kan befintliga overrides visas, aktiveras, avaktiveras och tas bort. Vid acceptanstestet ska en behörig testanvändare öppna ett matchande mål inom tidsintervallet med en giltig kod; utan kod, utanför tidsintervallet och för ett mål som aldrig får tillåtas genom en override ska den normala blockeringen fortfarande gälla. Jämför användare, Rule ID, webbpolicy, åtgärd och tid i Log Viewer. För HTTPS måste blockeringssidan kunna visas; enbart ett anslutningsavbrott ger inget inmatningsfält.

Vid återställning avaktiveras pilotoverriden via View overrides, och den ursprungliga blockeringen kontrolleras med en ny begäran. Först därefter tas en override som inte längre behövs bort, och endast de globala värden som ändrades under piloten återställs till sitt dokumenterade tidigare läge. Ta inte urskillningslöst bort andra användares befintliga overrides.

För AD-användare gäller My policy overrides bara huvudgruppen och enskilda användare, inte andra gruppmedlemskap. En matchande SSL/TLS-inspektionsregel med Action > Deny har fortfarande företräde. Om en godkänd override måste fungera i det läget planeras en snävt begränsad Web Exception som hoppar över HTTPS-dekryptering och testas separat med ett negativt fall; TLS-regeln försvagas inte generellt. Behörigheten att använda overrides begränsar inte en Web Exception; definiera dess eget tillämpningsområde utifrån käll-IP tillsammans med värdnamn/kategori och testa fall utanför detta område enligt beskrivningen nedan.

Web Exceptions och TLS-undantag

Att hoppa över HTTPS decryption tar bort beroende kontroller och tillåter ogiltiga servercertifikat; Malware and content scanning hoppar automatiskt över Zero-day protection. Hostnamnsmönster kan matcha i TLS, rena URL-sökvägar endast i HTTP eller redan dekrypterad HTTPS. URL Group är inget Web Exception-kriterium.

Web Exceptions är kraftfulla och därför farliga om de används som snabb reparation. Ett undantag under Web > Exceptions kan hoppa över skyddskontroller för matchande trafik, oberoende av vilken webbpolicy som gäller. Beroende på val hoppas HTTPS decryption, HTTPS certificate validation, Malware and content scanning, Zero-day protection eller Policy checks över.

För DPI-miljöer gäller en viktig begränsning: Web Exceptions träder bara i kraft om en webbpolicy är satt, Malware and content scanning är aktiv eller ATP är aktiv. SSL/TLS Exclusion Rules är däremot rätt plats om det bara handlar om att inte dekryptera vissa TLS-anslutningar. Den operativa skillnaden är viktig:

• SSL/TLS Exclusion Rule: undantar TLS-anslutningar riktat från dekryptering, typiskt på grund av Certificate Pinning eller inkompatibilitet.
• Web Exception: kan hoppa över webbpolicykontroller, malware-skanning, Zero-Day-analys eller certifikatvalidering.
• URL Group in Web Policy: styr Allow, Warn, Block eller Quota inom den normala policylogiken.

För Web Exceptions ska rotdomäner och alltför breda regex-mönster för URL:er undvikas: ett enkelt mönster som example.com kan även matcha text i en annan domäns sökväg eller frågesträng. Specifika värdnamnsmönster kan matcha i TLS-kontexten; rena URL-sökvägar är endast synliga med HTTP eller redan dekrypterad HTTPS. De kriterier som stöds för Web Exceptions är regex-mönster för URL:er, webbkategorier, käll-IP-adresser och destinations-IP-adresser – inte användare, användargrupper eller URL Groups.

För ett verksamhetsrelaterat tillåtande som är begränsat till en användargrupp använder du den matchande brandväggsregeln och Users i Web Policy; för ett identitetsavgränsat dekrypteringsundantag i DPI-läge använder du lämplig SSL/TLS-inspektionsregel med Don’t decrypt och uttryckliga användar-/gruppkriterier. Dessa identitetskriterier blir inte kriterier för en separat tillämpad Web Exception och begränsar inte i sig vilka kontroller den kringgår för vilken trafik.

För ett pilottest av en Web Exception kombinerar du de specifika klienternas Source IP addresses med ett bekräftat värdnamnsmönster eller en motiverad webbkategori. Testa både en icke godkänd källa och en destination utanför det faktiska matchningsområdet; en IP-adress är inte en användaridentitet. Dra inte slutsatsen av generell AND-logik att undantag för käll-IP och destinations-IP kan kombineras för TLS-undantag: den kvarstående vägledningen om TLS-undantag säger att de inte kan kombineras, och dess exakta tillämpningsområde är oklart. Om båda IP-begränsningarna krävs ska du avbryta utan att aktivera eller utöka undantaget och få ett förtydligande för den specifika programversionen. Förfarandet och matchningsbegränsningarna beskrivs i Skapa och testa Web Exceptions säkert.

Undantag kombinerar sina olika kriterier med AND. Inom en kriterietyp, till exempel flera URL Patterns, gäller däremot OR. Det är praktiskt men felkänsligt: ett undantag med URL Pattern och Source IP gäller bara om båda matchar. Ett undantag med mycket många URL Patterns kan däremot verka mycket bredare än tänkt.

Var särskilt försiktig med Policy checks. Om en Web Exception hoppar över Policy checks kan det indirekt försvaga andra regelbeslut. I kombination med Synchronized Security Heartbeat kan ett sådant undantag leda till att web requests inte blockeras som förväntat, trots att Heartbeat-kontroller är satta i brandväggsregeln.

Automatisera Web Protection målinriktat via XML API

XML API är användbart när samma granskade webbobjekt behöver underhållas på flera brandväggar. Det ersätter varken tilldelningen av Web Policy till den brandväggsregel som faktiskt är lämplig eller kontrollen av trafiken. Säkerhetskopiera det aktuella objektbeståndet, dess referenser och den gamla policyn före skrivning. Åtkomst, uppbyggnad av requests, API-version, XML-status och Audit Trail förklaras i Konfigurera XML API-åtkomst säkert och utvärdera svar. Följande objektrelationer är inte en körbar mall. Vid de uttryckligen angivna motsägelserna mellan källorna ska du först kontrollera API help för den installerade builden och inte skriva utan ett entydigt klargörande.

Objekt först, policy och tilldelning därefter

Ett hanterbart automatiseringsfall är en egen URL Group för verksamhetens mål, en egen File Type för nedladdningar och en User Activity som sammanför dessa kriterier. Läs först dessa objekt med deras faktiska namn eller skapa dem, låt därefter policyreglerna referera till dessa objekt och tilldela slutligen Web Policy på ett kontrollerat sätt till den befintliga brandväggsregel som faktiskt är lämplig. Ett nytt objekt tillåter eller blockerar inte i sig någon trafik.

• URL Group: WebFilterURLGroup innehåller Name och upprepade URL-poster under URLlist. Skrivningen URLlist är inte densamma som URLList för en extern Web Category. IsDefault markerar en inbyggd URL Group; enligt referensen är fältet skrivskyddat och ändringar av det ignoreras vid uppdatering. Det gör inte ett eget objekt till ett redigerbart standardobjekt. För lämpliga domänvärden och underhåll i UI gäller fortfarande arbetsflödet för URL Group.
• File Type: FileType samlar FileExtensionList med upprepade FileExtension-värden och MIMEHeaderList med upprepade MIMEHeader-värden. Kommentaren i XML-exemplet beskriver Template så att mallens filändelser och MIME-header tas över och separat angivna poster läggs till. Kontrollera därför den faktiska fullständiga listan efter skrivning, inte bara de tillagda värdena. Exemplet visar Blank, men parametertabellen förklarar inte Template; härled inte någon universell lista över tillåtna mallar från detta. Filändelser anges fortsatt utan inledande punkt, till exempel pdf.
• User Activity: UserActivity använder Name för det befintliga namnet och NewName för ett avsett namnbyte. Under CategoryList finns Category-objekt med Type och ID. I exemplet är typbeteckningarna web category, file type och url group åtskilda från ID, som är objektnamnet. Använd inte ett typord som objekt-ID och hitta inte på ett numeriskt ID. Exemplet kallar beskrivningstaggen Desc, medan tabellen anger Description; bekräfta vilken tagg som gäller för den specifika builden. OR-kopplingen mellan kriterierna i Activity förblir åtskild från den senare HTTP-/HTTPS-åtgärden.

Vid ett File Type-fel är dessa XML-svar särskilt relevanta: Edit File Type 202 / Message.FileTypeUpdateWithRename, Add File Type eller Edit File Type 503 / Message.FileTypeSameDetailRecordExists och 505 / Message.FileTypeInvalidExtensionOrMIMEHeader. Dessa är oförändrade referenssymboler, inte uppslagna meddelandetexter och inte HTTP-koder. Vid 202 ska gamla och nya namn samt policyreferenser läsas; vid 503 ska de redan befintliga detaljvärdena jämföras och vid 505 ska filändelser/MIME-header kontrolleras. Skapa inte bara ett andra objekt med ett annat namn.

Egna kategorier: skilj innehåll, klassificering och bandbredd åt

WebFilterCategory skiljer mellan två inmatningsvägar med ConfigureCategory: Local använder DomainList/Domain och KeywordList/Keyword; External använder URLList/URL för den externa kategorilistan. En extern list-URL är inte automatiskt ett verksamhetsrelaterat domänvärde som ska tillåtas. Den externa listans ursprung, uppdatering och innehåll måste vara spårbara. Blanda inte båda vägarna i en request utan att först kontrollera dem.

Classification klassificerar kategorin, men avgör inte Allow eller Block. Beskrivningen anger delvis andra beteckningar än enum-tabellen; denna anger Productive, Unproductive, Acceptable och Objectionable. Inte heller ConfigureCategory är helt konsekvent: exemplet visar Local/External, medan tabellen dessutom anger 0. Överför varken översatta klassificeringsnamn eller 0 som en okontrollerad ersättning. QoSPolicy refererar till en bandbreddspolicy, inte en Web Policy-åtgärd; val och effekt kontrolleras i arbetsflödet för Traffic Shaping. Först en lämplig Web Policy-regel gör kategorin till ett åtkomstbeslut.

Kategoritabellen kräver en noggrann efterkontroll av detaljerna:

• Add Category 201 / Message.WFCCategoryDetailCannotAdded och Update Category 201 / Message.WFCCategoryDetailCannotUpdated: Behandla inte alla XML-2xx-svar som fullständigt sparade domän-/nyckelords-/listvärden. Läs tillbaka objekthuvudet och varje erforderlig detaljmängd separat. Add Category 202 hänvisar liksom 200 till Message.WFCAddSuccess; det gemensamma symbolnamnet förklarar inte skillnaden mellan koderna.
• Add Category 522 / Message.WFCMaxFiveURL och 523 / Message.WFCMaxFiveKeyword, men Update Category 503 / Message.WFCMaxFiveURL och 504 / Message.WFCMaxFiveKeyword: Utvärdera operation och kod tillsammans. Symbolnamnen ensamma belägger inte någon universell aktuell gräns på fem poster; klarlägg den faktiskt tillåtna omfattningen med hjälp av buildens hjälp.
• Delete WebFilter Category 201 / Message.WFCRelationExists och 203 / Message.WFCSomeCategoryCannotDeleted: Kontrollera referenser och återstående kategorier innan du tar bort eller försöker igen. Förutsätt inte att borttagningen lyckats generellt för ett urval av flera kategorier.

Alla Message.*-symboler lämnas här avsiktligt utan uppslagning. Säkra det faktiska sparade tillståndet och svaret före ett nytt försök; upprepa framför allt inte blint en delvis genomförd kategoriändring.

Content Condition Lists: Key är inte Name

Ett ContentConditionList-objekt innehåller det synliga Name, den separata identiteten Key och ContentList med upprepade ContentString-värden. Referensen kräver Name och Key; för Delete Content Condition List anges uttryckligen Key som selektor. Bevara därför båda värdena vid läsning och dokumentation och använd aldrig det visade namnet som borttagningsnyckel utan kontroll.

API-tabellen beskriver ContentString som råa regex-värden och anger att dubbletter inte ignoreras. Den UI-import som beskrivs ovan är däremot en textlista med en Exact Match per rad. Därmed är det inte belagt att en UI-import och en API-regex-lista har identiska inmatningsformat. Klarlägg semantiken med hjälp av buildens hjälp före en övergång och testa ofarliga träffar och icke-träffar; överför inte en befintlig textlista som regex-payload utan kontroll.

Särskilt anmärkningsvärda är referensens motsägelsefulla kopplingar mellan operationer och meddelanden:

Dessa rader belägger en motsägelse i dokumentationen, inte att en Update tar bort eller att en Delete uppdaterar. Kontrollera operationen, Key, svaret och det faktiskt befintliga innehållet. Härled ingen destruktiv operation från detta utan ett entydigt klargörande för builden och starta inget automatiskt nytt försök utifrån ett symbolnamn.

WebFilterPolicy: bevara ordning och selektorer

WebFilterPolicy håller reglerna under RuleList/Rule. Varje regel refererar under CategoryList/Category till ett ID-objektnamn och en type-selektor. Policyexemplet använder WebCategory, URLGroup, UserActivity, DynamicCategory och FileType; dessa token skiljer sig från typbeteckningarna i User Activity-exemplet och taggen type skrivs där med små bokstäver. Använd skrivning, objekttyp och befintligt namn från det lästa objektet eller buildens hjälp i stället för att serialisera UI-etiketter eller påhittade ID:n.

HTTPAction och HTTPSAction är separata beslut; FollowHTTPAction beskriver deras koppling. API-exemplet anger Deny, Allow, Warn, Log och Quota. Dessa exempelvärden bekräftar inte att alla kan väljas på varje build, och Deny kan inte bara ersättas med UI-ordet Block. PolicyRuleEnabled styr regelaktiveringen, Schedule det refererade schemat och UserList/User användaromfattningen. CCLRuleEnabled och CCLList/CCL kopplar innehållsfiltren till regeln; exemplet refererar där till ett CCL-namn, medan borttagning av CCL kräver dess Key. HTTPS-beteendet för ett Content Filter måste fortfarande motsvara den UI-koppling som förklarats ovan. Bevara ordning, användaromfattning, schema, innehållsfilter och Default Action vid uppdatering och jämför hela den sparade policyn. Ett saknat fält får inte tas som grund för att anta vare sig säker bevaring eller borttagning.

För följande inmatningar ger referensen ingen motsägelsefri, körbar mall:

• DefaultAction: Tabellen anger högst ett tecken, men tillåter samtidigt Allow och Deny. Förkorta inte till ett tecken och hitta inte på någon numerisk ersättningskodning. EnableReporting visar Enable/Disable i exemplet, medan tabellen bara tillåter Enable; avstängning är därmed inte bekräftad utan kontroll av builden.
• DownloadFileSizeRestriction: XML-kommentaren anger 1 till 1536 MB, medan parametertabellen anger 0 till 1536. Betydelsen av 0 är därmed oklar; behandla det varken som obegränsat eller som ett giltigt aktivt gränsvärde. Fastställ reglaget DownloadFileSizeRestrictionEnabled och gränsvärdet tillsammans med hjälp av buildens hjälp och testa med ofarliga filer på båda sidor om den bekräftade gränsen. QuotaLimit anges i API-tabellen som 1 till 1440; kontrollera gränsen i den installerade builden. DPI stöder fortfarande inte Policy Quota.
• Tenant Controls: Office365Enabled, Office365TenantsList och Office365DirectoryId hör till Microsoft-tenantbegränsningen. För listan anger API-tabellen 4096 tecken, medan UI-hjälpen för Restrict-Access-To-Tenants anger 256; likställ inte dessa gränsvärden och härled inte ett längre produktionsvärde från API-uppgiften. Exempelvärdet för Office365DirectoryId, 456ff232-35l2-5h23-b3b3-3236w0826f3d, innehåller icke-hexadecimala tecken och är inte ett giltigt GUID-exempelvärde. Reparera det inte i tysthet, utan använd det faktiska Directory-ID:t från den egna tenantadministrationen och testa både tillåtna och otillåtna tenantinloggningar. Bekräfta UI-fältkoppling, längder och semantik i den installerade builden.

Add Policy 522 / Message.WebPoliciesLimit gäller policygränsen; härled ingen gräns för regler eller kategorier från detta. Update Policy 503 / Message.WFPQuotaLimitInvalid kräver kontroll av Quota-inmatningen. Referensen anger dessutom Update Policy from API som en egen operationsbeteckning; dess svarsrader innehåller inte denna 503-post. Det belägger inte att denna väg accepterar varje Quota. Kontrollera status, sparad policy och faktisk effekt före en ny skrivning.

Blanda inte globala skyddsalternativ och aviseringar

WebFilterSettings är området för globala webbfilterinställningar, inte en enskild WebFilterPolicy. Det innehåller bland annat PharmingProtection, Scanning, BlockUnscannableContent och PUAWhitelist med upprepade PUA-namn. En PUA-post är ett medvetet godkänt undantag, inte ett nödvändigt steg för en ny Web Policy. Val av skanner och dess effekt behandlas fortsatt i det länkade arbetsflödet för Malware Scanning; att anpassa ett meddelande är ingen anledning att samtidigt ändra globala skyddsalternativ eller PUA-listan.

WebFilterProtectionSettings är ett ytterligare, separat skanner-/skyddskontrakt med fält som ScanMode och FileSizeThreshold. Skyddsfält med liknande namn gör det inte till en synonym för WebFilterSettings eller WebFilterNotificationSettings; byt inte payloads mellan dessa objekt. Ta inte med några skanner-, storleks- eller certifikatalternativ för en ren informationstext. Även för detta skyddsobjekt måste det giltiga kontraktet hämtas från build-hjälpen, inte från exempelvärden som har övertagits utan kontroll.

Även här motsäger exemplet tabellen: BlockUnscannableContent visar Enable/Disable, medan tabellen tillåter Allow och Block (Best Protection). Likrikta inte dessa enum-värden och gissa dem inte utifrån fältnamnet. Säkra det tidigare beteendet före varje ändring och klarlägg det exakta kontraktet för builden.

WebFilterNotificationSettings avser däremot användaraviseringarna. OverrideDefaultDeniedMessage hör till DefaultDeniedMessage, OverrideDefaultWarnedMessage till DefaultWarnedMessage; anpassade texter väljs medvetet endast med motsvarande Override. Ytterligare Override-/Quota-fält finns i tabellen, men saknas delvis i exemplet: OverrideDefaultOverrideMessage/DefaultOverrideMessage och OverrideDefaultQuotaMessage/DefaultQuotaMessage. Override-/Quota-reglagen anger 0/1 som tillåtna värden, men samtidigt Enable som standardvärde. Det är ytterligare en motsägelse mellan källorna och ingen anledning att koda alla flaggor på samma sätt. För ett rent textbyte ska endast de avsedda text-/Override-fälten ändras enligt det bekräftade kontraktet för builden och motsvarande sida kontrolleras i pilottestet.

DeniedMessageImage väljer Default eller Custom. Exemplet kopplar TopImageFile och BottomImageFile till ett filnamn från en multipart-request; tabellen beskriver jpg/jpeg. För User Notifications kallar tabellen dock den övre parametern Top Image, medan exemplet använder TopImageFile. Dessa uppgifter räcker inte för att säkert konstruera partnamn, Content-Disposition, uppladdningsendpoint eller filkoppling. Klarlägg först filöverföringen med hjälp av buildens hjälp eller en officiell Collection som bekräftats för detta. Utför ingen automatiserad bildändring utan ett bekräftat uppladdningskontrakt. De liknande meddelande-/bildfälten i WebFilterSettings gör inte de båda objekten utbytbara.

DefaultWebFilterNotificationSettings är återigen separat: det erbjuder namngivna standardmeddelandetexter, till exempel WebsiteBlocked. Ett lämpligt avgränsat användningsfall är ett godkänt meddelande med rätt supportkontakt. Säkra då exakt den berörda originaltexten, ändra endast den bekräftade meddelandenyckeln, kontrollera motsvarande förhandsvisning och faktiska pilotsida och återställ vid behov exakt denna text. Meddelandetext är varken ett åtkomstgodkännande eller ett belägg för ett malware-/Zero-Day-fynd.

Läs tillbaka och verifiera varje automatiserad ändring

Läs efter varje skrivoperation tillbaka exakt det adresserade objektet med API eller i WebAdmin: jämför namn/nycklar, verksamma listor, referenser, policyordning, aktivering och den faktiska brandväggstilldelningen. Kör därefter samma tillåtna och blockerade pilotrequests som före ändringen och korrelera Rule ID, användare, Web Policy och åtgärd i Log Viewer. Ett lyckat HTTP-svar, en XML-2xx-kod eller en ej uppslagen Message.*-symbol räcker inte ensam. Vid en deländring eller ett oklart svar ska först aktuellt tillstånd och Audit Trail säkras, och därefter en riktad korrigering göras; inga blinda nya Add-/Delete-försök. Återställ endast de dokumenterade egna ändringarna, inte andra befintliga policyer, Overrides eller globala skyddsvärden.

Testa Web Protection

Efter att ha sparat bör man inte bara kontrollera om policyn finns. Avgörande är om den gäller för verklig trafik.

1. Använd Policy Tester

Den exakta sökvägen är Diagnostics > Tools > Pop-out tools > Policy tester. Firewall, SSL/TLS, and web testar den kombinerade transparenta vägen, medan Web policy only isolerar webbpolicybeslutet. Webbtestet representerar endast transparent webbåtkomst, tar inte hänsyn till SD-WAN-rutter och accepterar inte Source Networks med MAC-adresser. Om protokoll saknas används HTTP; om port saknas används standardporten för det valda protokollet.

Kör båda relevanta lägena som referens före ändringen och dokumentera resultatet och förväntad Rule ID; upprepa därefter exakt samma tester. Policy Tester är fortfarande en förkontroll och ersätter inte verkliga Allow- och Block-test från en pilotklient, eftersom NAT, TLS-inspektion, QUIC, routing eller en explicit Direct Proxy-väg kan hantera det verkliga flödet annorlunda.

2. Praktiskt test med en pilotklient

Kontrollera följande med en pilotklient:

• tillåten affärssida
• blockerad kategori
• varningskategori
• URL-grupp Tillåt
• URL-grupp Blockera
• HTTPS-sida med och utan TLS-inspektion
• Nedladdning av en ofarlig testfiltyp
• Beteende med QUIC aktiv eller blockerad

3. Kontrollera Log Viewer

I Log Viewer bör det synas:

• vilken brandväggsregel som träffades
• vilken användare som identifierades, om relevant
• vilken webbkategori eller URL-grupp som var inblandad
• om HTTPS, TLS-inspektion eller malware-skanning var inblandade
• om åtgärden tillät, varnade eller blockerade
• om en Web Exception eller TLS Exclusion tillämpades
• om en nedladdning hanterades annorlunda på grund av storlek, malware-skanningsfel eller Zero-Day-analys

För Syslog eller SIEM räcker inte URL och action. För en robust analys behövs även Firewall Rule ID, användare, kategori, webbpolicy, HTTP-metod, status, skanningsresultat, undantagsindikering och SSL/TLS-status. Om dessa fält saknas i SIEM eller normaliseras fel ser Web Protection snabbt otydligare ut i rapporteringen än den faktiskt är på brandväggen.

För djupare felsökning är även loggfiler relevanta. Tilldelningen finns i Sophos Firewall Troubleshooting: Services och Logs.

Omedelbara varningar och rapportering

Om vissa kategorier inte bara ska blockeras utan aktivt rapporteras kan omedelbara varningar vara användbara. Detta är särskilt användbart i skolor, strikt reglerade miljöer eller områden med tydlig internetanvändningspolicy.

De tre utvärderingsvägarna besvarar olika frågor:

• Snabbt e-postmeddelande vid få känsliga webbkategorier: Omedelbara varningar.
• Återkommande rapporter, trender och användar- eller kategoriutvärderingar: Central Firewall Reporting.
• Längre lagring, korrelation med andra system eller SOC-processer: Syslog eller SIEM.

Innan omedelbara varningar bör det vara klart vem som får meddelandet, vilka kategorier som verkligen utlöser en reaktion, hur falska positiva hanteras och när kategoriurvalet granskas. En bred varningslista utan ägare skapar snabbt e-postbrus men ingen bättre säkerhet.

För teknisk aktivering och triage finns Använd Sophos Firewall webbkategorier och omedelbara varningar. För långsiktiga utvärderingar bör Central Firewall Reporting eller Skicka Sophos Firewall syslog till SIEM övervägas.

Hantera ändringar och undantag i drift

Web Protection förändras ständigt i drift. Nya SaaS-tjänster tillkommer, enskilda domäner kategoriseras felaktigt, avdelningar behöver tillfälligt åtkomst och webbläsarbeteende förändras. Utan en tydlig process uppstår snabbt breda undantag som senare ingen kan förklara.

För varje ändring bör man minst dokumentera:

• Vem behöver åtkomst? förhindrar globala undantag för få användare.
• Vilken domän, kategori eller filtyp är berörd? separerar URL-grupp, webbkategori och filtyp tydligt.
• Är det ett tillfälligt eller permanent undantag? tvingar fram granskning i stället för permanenta, odokumenterade undantag.
• Vilken brandväggsregel och webbpolicy är berörda? förhindrar ändringar i fel regel.
• Hur testas det? gör framgången i Log Viewer spårbar.

En liten förändringsprocess har visat sig vara effektiv:

1. Registrera förfrågan med användare, URL, tidpunkt, affärsskäl och skärmdump eller felmeddelande.
2. Kontrollera i Log Viewer vilken brandväggsregel, webbpolicy, kategori och åtgärd som gällde.
3. Besluta om kategorin är grundläggande felaktig, om endast en enskild domän ska tillåtas eller om förfrågan avslås.
4. Om ett verksamhetsrelaterat tillåtande behövs ska det hållas snävt avgränsat i den matchande brandväggsregeln och Web Policy: en specifik URL Group i stället för en hel kategori och uttryckligen angivna Users i stället för hela LAN. Om en Web Exception behövs i stället ska dess egna stödda URL-/kategori-/IP-kriterier användas; en användargrupp eller URL Group är inte ett kriterium för en Web Exception.
5. Testa ändringen i en testregel eller pilotgrupp.
6. Efter att ha sparat, genomför ett verklighetstest och dokumentera Log Viewer, kategori, Rule ID och användarkontext.
7. Sätt ett granskningsdatum, särskilt för tillfälliga affärsundantag.

Tillfälliga undantag bör namnges tydligt, till exempel TMP_ALLOW_vendor-portal_until_2026-07-31. Permanenta affärsundantag behöver också en ägare. Om ingen är ansvarig för ett undantag bör det inte förbli permanent i policyn.

Om många enskilda domäner för samma tjänst uppstår är ofta inte webbpolicyn problemet, utan tjänstens arkitektur. Då bör man överväga om en egen brandväggsregel, en egen webbpolicy, en väl underhållen URL-grupp eller en annan kontrollpunkt passar bättre. För dynamiska IOC- eller blocklistor är webbpolicyundantag oftast fel plats; för detta passar snarare Sophos Firewall Threat Feeds.

Återställning och tillfällig nödåtkomst

En ändring i webbpolicy kan omedelbart påverka produktivt arbete. Därför bör man före större ändringar fastställa hur det gamla tillståndet återställs.

Praktiska återställningsalternativ:

• Duplicera eller dokumentera den berörda webbpolicyn före ändringen
• Testa ändringen först i en pilotregel eller liten användargrupp
• Ta inte bort den gamla brandväggsregeln eller den gamla webbpolicyn omedelbart
• Definiera tidsfönster, testanvändare och kriterier för att återställa den tidigare konfigurationen
• Efter att ha sparat, kontrollera Log Viewer, Rule ID och kategoribeslut

Vid akuta blockeringar ska du inte reflexmässigt lägga in en bred Allow-regel högst upp. Välj i första hand ett snävt, tidsbegränsat verksamhetsrelaterat tillåtande i den matchande brandväggsregeln och Web Policy, med en specifik URL Group, uttryckligen angivna Users och ett granskningsdatum. Detta är inte en Web Exception som är avgränsad till en användargrupp. Om inspektion behöver kringgås krävs egna godkända matchningskriterier som stöds samt separata positiva och negativa tester. Utvärdera det tillfälliga tillåtandet igen efteråt.

Typiska fel

Webbpolicy gäller inte

Oftast är policyn inte aktiverad i rätt brandväggsregel, regeln träffas inte, en regel högre upp tillåter trafiken eller användarkontexten passar inte. Kontrollera först Log Viewer och Rule ID.

HTTPS blockeras inte som förväntat

Utan TLS-inspektion ser brandväggen färre detaljer. Beroende på mål kan ett domän- eller kategoribeslut fungera, medan innehållsgranskning, filtyper eller vissa sökfunktioner är begränsade.

Om anslutningen inte dekrypteras kan brandväggen ändå använda SNI- eller domäninformation för policybeslut. Blockeringssidor, varningssidor, filtyper, Content Filters, malware-skanning och Zero-Day-analys behöver däremot mer synlighet. Därför bör man i Log Viewer inte bara kontrollera webbpolicyåtgärden, utan också SSL/TLS Inspection-status.

QUIC kringgår förväntningen

Om webbläsare använder UDP 443 kan trafiken behandlas annorlunda än klassisk HTTPS över TCP. I klientregler bör man medvetet besluta om QUIC blockeras.

Tillåt-regel är för högt upp

En bred tillåt-regel i början av webbpolicyn kan upphäva senare blockregler. Regelordning inom webbpolicyn är lika viktig som regelordning i brandväggsregellistan.

För många undantag

Undantag löser snabbt ett enskilt problem men kan minska skyddseffekten. Varje undantag behöver syfte, ägare och granskningsdatum. Om många undantag uppstår är ofta policystrukturen fel eller en affärsapplikation behöver en egen regel.

Särskilt riskabla är Web Exceptions som hoppar över Policy checks eller Malware and content scanning. Om det bara är HTTPS decryption som stör är en SSL/TLS Exclusion oftast smalare och lättare att förstå.

Rapportering visar inget

Då bör loggning, rapportering, brandväggsregel, policyval eller loggöverföring kontrolleras. En policy utan loggning är svår att utvärdera i drift.

Driftchecklista

• Web Protection licensstatus kontrollerad.
• Klient-, server-, gäst- och VPN-trafik utvärderad separat.
• Webbpolicy med beskrivande namn skapad.
• Kritiska kategorier och URL-grupper planerade medvetet.
• Regelordning inom webbpolicyn kontrollerad.
• Webbpolicy aktiverad i lämplig brandväggsregel.
• Log firewall traffic, webbpolicyloggning och Reporting aktiv.
• Webbpolicyregler är aktiverade och i rätt ordning.
• TLS-inspektion och CA-certifikat för pilotgrupp kontrollerad.
• QUIC-strategi definierad.
• Web Exceptions och TLS Exclusions dokumenterade separat.
• Policy Tester och verklighetstester genomförda.
• Log Viewer och rapportering kontrollerad.
• Ändringsprocess för webbpolicyundantag definierad.
• Tillfälliga undantag med utgångsdatum försedda.
• Undantag dokumenterade med ägare och granskningsdatum.

FAQ