Configurar a Proteção Web do Sophos Firewall com Políticas Web

A Proteção Web do Sophos Firewall controla os sites, as categorias e os conteúdos web a que os utilizadores podem aceder. Na prática, a Proteção Web não é apenas uma única configuração. Uma política web deve ser planeada tecnicamente, ativada numa regra de firewall adequada e depois testada com tráfego real.

Muitos erros ocorrem porque uma política web existe, mas não é aplicada a uma regra de firewall ativa. Outros problemas estão relacionados com HTTPS, Inspeção TLS, QUIC, reconhecimento de utilizadores, ordem das regras ou exceções muito amplas. O procedimento sensato é: planear a política, construir a regra, ativar, testar e monitorizar em operação.

Qual artigo de Proteção Web é adequado?

A Proteção Web sobrepõe-se a regras de firewall, Inspeção TLS, QUIC, relatórios e exceções. Dependendo da tarefa, um artigo mais específico pode ser mais adequado:

• Configurar Proteção Web e Políticas Web de forma geral: Este artigo.
• Compreender Single ou Dual Engine, erros de análise, limites de tamanho e um teste real de malware: Configurar e testar a análise de malware no Sophos Firewall.
• Avaliar categorias web, grupos de URLs e alertas instantâneos: Utilizar Categorias Web e Alertas Instantâneos do Sophos Firewall.
• Descriptografar e verificar tráfego HTTPS: Implementar corretamente a Inspeção TLS do Sophos Firewall.
• Distribuir certificado CA para clientes geridos: Distribuir Certificado CA do Sophos Firewall para Inspeção TLS.
• Classificar QUIC e HTTP/3 em problemas de filtragem web: Bloquear corretamente QUIC e HTTP/3 no Sophos Firewall.
• Descobrir qual regra de firewall e política realmente se aplica: Testar regras do Sophos Firewall com Log Viewer, Policy tester e Packet Capture.
• Avaliar eventos web e de segurança por mais tempo: Central Firewall Reporting ou Enviar Syslog para SIEM.

Assim, a análise permanece clara: primeiro deve-se verificar se a regra de firewall corresponde. Depois, verifica-se a política web, categoria, contexto do utilizador, QUIC, Inspeção TLS e registo.

O que a Proteção Web controla

A Proteção Web é composta por vários componentes. Nem todos os componentes precisam ser usados em todos os ambientes, mas as inter-relações devem ser claras.

• Política Web: Regras para acessos web permitidos, avisados, bloqueados ou baseados em quotas.
• Categorias Web: Categorias Sophos e categorias próprias para sites.
• Grupos de URLs: Listas de domínios próprias para regras de permissão ou bloqueio específicas.
• Tipos de ficheiros: Controlo de tipos de download ou ficheiros específicos.
• Filtros de conteúdo: Termos ou padrões para controlo de conteúdo.
• Exceções: Exceções específicas de comportamento web, TLS ou de análise.
• Search engine enforcement: SafeSearch e restrições do YouTube.
• Advanced settings: restrições de domínios de login Google Apps e Microsoft Entra ID Tenant Restrictions.
• Registo e Relatórios: Rastreabilidade no Log Viewer, Reporting, Central ou SIEM.

A Proteção Web não substitui uma base de regras de firewall bem estruturada. A regra de firewall decide primeiro qual tráfego de qual zona para qual zona de destino é permitido. A política web complementa esta regra com controlo web. As bases sobre a ordem das regras, origem, destino, serviços e perfis de segurança estão em Compreender e construir regras do Sophos Firewall.

Pré-requisitos

Antes da implementação, estes pontos devem ser esclarecidos:

• A Proteção Web está licenciada ou incluída no pacote utilizado.
• As redes de clientes afetadas têm as suas próprias regras de firewall.
• O registo está ativo nas regras relevantes.
• DNS e hora do firewall funcionam corretamente.
• O reconhecimento de utilizadores está esclarecido, caso as políticas se apliquem por utilizador ou grupo.
• A Inspeção TLS está planeada, se os conteúdos HTTPS precisarem ser verificados mais detalhadamente.
• QUIC/HTTP/3 é conscientemente permitido ou bloqueado.
• Existe um grupo piloto e um caminho de fallback para sites críticos para o negócio.

É especialmente importante a separação por grupos-alvo. Uma política web para clientes normais, servidores, convidados, utilizadores VPN e sistemas de gestão não deve ser a mesma. Os servidores geralmente precisam de menos controlo de navegação, mas listas de destino e atualização mais rigorosas. Os convidados geralmente precisam de categorias e limitação de largura de banda, mas não de acesso a recursos internos.

Se as políticas web devem reagir a utilizadores ou grupos, o reconhecimento de utilizadores tem de funcionar. AD SSO, Captive Portal, STAS, SATC ou outros métodos não devem ser descobertos apenas durante a implementação da política web. No Log Viewer deve ser visível se um pedido foi avaliado como utilizador conhecido, como grupo ou como Anybody ou utilizador desconhecido.

Os critérios de utilizador na regra de firewall correspondente têm prioridade sobre Users na política web; esta pode restringir o âmbito, mas não incluir utilizadores excluídos pela regra.

Percurso mínimo para uma política eficaz

Criar a política em Web > Policies e ativar nela pelo menos uma decisão Allow/Block específica.

Em seguida, editar uma regra real em Rules and policies > Firewall rules com Action: Accept, Source Zone e Source Network, Destination Zone e Destination Network adequadas e os Services necessários. Ativar Log firewall traffic e atribuir a política em Web filtering. Verificar apenas se o NAT existente corresponde ao percurso atual para a Internet, sem criar um novo comportamento de NAT exclusivamente para esta política. Antes da alteração, registar a Rule ID e os resultados dos mesmos pedidos deliberadamente permitidos e bloqueados; depois, repeti-los no contexto real de origem e utilizador. A alteração só deve ser aceite quando o Log Viewer mostrar a Rule ID, a política e as decisões Allow e Block esperadas.

Planear a Política Web

Uma boa política web não começa na interface, mas com algumas decisões técnicas.

Definir grupos-alvo

Primeiro, determina-se para quem a política se aplica:

• Clientes padrão na LAN
• Notebooks geridos via VPN
• WLAN de convidados
• Salas de formação ou ambientes escolares
• Servidores com acesso HTTP/HTTPS de saída
• Postos de trabalho de administradores privilegiados

Se a mesma regra de firewall contiver vários grupos muito diferentes, a Proteção Web torna-se difícil de entender. É melhor ter regras e políticas separadas, por exemplo, LAN_USERS_WEB, GUEST_WEB ou SERVER_UPDATES_WEB.

Definir Categorias e Grupos de URLs

A categoria highly objectionable criminal activity é sempre bloqueada; nem as regras da política web nem as exceções a podem permitir, e o SFOS oculta o domínio nos registos e relatórios.

As categorias web da Sophos são adequadas para um controlo amplo: Malware, Phishing, Conteúdo Adulto, Anonimizadores, Streaming, Redes Sociais ou Jogos. Os Grupos de URLs são melhores quando domínios individuais precisam de ser permitidos ou bloqueados especificamente.

Uso típico:

• bloquear categorias de risco conhecidas: Categoria Web.
• permitir domínios SaaS específicos: Grupo de URLs.
• tratar um domínio incorretamente categorizado: Grupo de URLs ou categoria própria.
• restringir streaming por tempo: Política Web com Agenda ou Quota.
• Página de aviso em vez de bloqueio rígido: Política Web com ação de aviso.

Os Grupos de URLs não devem tornar-se uma lista de recolha desorganizada. Se forem adicionados muitos domínios, a lista precisa de um responsável, um propósito e uma data de revisão. Para listas muito grandes ou dinâmicas, Sophos Firewall Threat Feeds ou outros componentes arquiteturais são frequentemente mais adequados.

Criar e utilizar URL Groups de forma segura explica como se relacionam os valores de domínio válidos, a lógica OR, a utilização numa Web Policy e as exclusões TLS.

Para correspondências puramente por domínio, os Grupos de URLs são normalmente melhores do que categorias web próprias. A Sophos indica que os Grupos de URLs são mais eficientes e podem gerar menos falsos positivos. Categorias próprias são úteis quando um domínio deve aparecer numa lógica de política própria além da sua categoria padrão Sophos.

Keywords em categorias próprias devem ser usadas com muita cautela. As keywords são verificadas contra o URL completo, incluindo caminho e query. Um allow baseado numa keyword pode, por isso, corresponder inadvertidamente se a palavra aparecer num parâmetro de query noutro domínio. Para decisões de allow, domínios concretos ou Grupos de URLs são normalmente mais limpos; regras por keyword encaixam melhor em casos de bloqueio estreitos.

Definir Regras de Permissão com Cuidado

As regras de permissão nas políticas web devem ser restritas. Uma regra de permissão no topo pode tornar ineficazes regras de bloqueio posteriores, pois as regras da política web da Sophos são avaliadas de cima para baixo. Isso é especialmente relevante quando um Grupo de URLs, uma regra de tipo de ficheiro ou uma exceção de categoria está acima de outras regras.

Na prática, tem-se revelado eficaz:

Uma permissão para fins de negócio acima de regras de bloqueio críticas só se aplica ao seu âmbito estritamente definido. Se uma categoria de risco tiver de permanecer bloqueada sem exceções, a respetiva regra Block deve ficar acima de todas as regras Allow correspondentes. A ordem é verificada com um destino de negócio permitido e um destino bloqueado dentro do âmbito da exceção; uma permissão de domínio não deve permitir inadvertidamente todos os tipos de ficheiro ou todos os conteúdos desse destino.

• Regras de aviso ou quota para áreas cinzentas.
• Tráfego web geralmente permitido apenas no final.

Criar a Política Web

A política web é criada no seguinte menu:

Web > Policies

Procedimento básico:

1. Selecionar Add policy.
2. Atribuir um nome descritivo, por exemplo, LAN_USERS_STANDARD_WEB.
3. Adicionar regras.
4. Verificar search engine enforcement, por exemplo SafeSearch ou YouTube restrictions.
5. Definir policy quota status se forem usadas ações Quota.
6. Verificar Advanced settings, especialmente logging, reporting, downloads grandes, Google Apps e Microsoft Entra ID Tenant Restrictions.
7. Guardar a política.

Uma regra dentro da política web é criada com Add rule. O firewall cria primeiro uma regra padrão desativada que bloqueia HTTP para Anybody. Depois, os campos são ajustados de forma deliberada:

1. Abrir Users e definir conscientemente Anybody, utilizadores concretos ou grupos.
2. Abrir Activities e selecionar All web traffic, User activities, Categories, URL Groups ou File types.
3. Para conteúdo, abrir o separador Content filters, selecionar o filtro, ativar and with content e manter HTTPS em Use action.
4. Definir Action para HTTP: Allow, Warn, Block ou Quota.
5. Verificar a ação HTTPS: Use action, Allow HTTPS, Warn HTTPS, Block HTTPS ou Quota HTTPS.
6. Definir Constraints se a regra só deve aplicar-se a uma agenda.
7. Verificar a posição da regra dentro da política.
8. Ativar o estado da regra.
9. Guardar a política.

Em Users > Add new item, desmarcar Anybody quando se pretende abranger apenas determinados utilizadores ou grupos. Em Activities > Add new item, desmarcar All web traffic antes de selecionar Activities individuais. Confirmar cada seleção com Apply selected items. Caso contrário, a regra permanece desnecessariamente ampla, apesar dos objetos individuais adicionados. As ações HTTP chamam-se Allow HTTP, Warn HTTP, Block HTTP e Quota HTTP; Use action aplica a mesma decisão a HTTPS. Nos Content filters, esta associação é fixa e não pode ser substituída por uma ação HTTPS diferente.

Importar corretamente listas de filtros de conteúdo

Os Content filters são geridos em Web > Content filters e depois selecionados em Activities na regra da política web. Para listas de termos maiores, a Sophos suporta um ficheiro .txt simples. O ficheiro pode conter no máximo 2,000 linhas e cada entrada pode ter até 80 caracteres, incluindo espaços e sinais de pontuação.

O ficheiro contém um termo por linha e cada linha é avaliada como exact match. Não deve incluir cabeçalhos, comentários, metadados nem colunas adicionais; usar UTF-8.

Procedimento seguro:

1. Limpar os termos num editor de texto e colocar exatamente uma entrada por linha.
2. Guardar o ficheiro como .txt com codificação UTF-8.
3. Importar a lista em Web > Content filters e atribuir-lhe um nome descritivo.
4. Em Activities, abrir Content filters, selecionar o filtro, ativar and with content e manter Use action.
5. Com um cliente piloto, testar um termo permitido e um termo que corresponda de forma deliberada, e verificar a ação no Log Viewer.

Se uma importação for rejeitada ou alguns termos não forem aplicados, verificar primeiro o número de linhas, o comprimento dos caracteres, a codificação e os caracteres adicionais invisíveis. Uma regra Allow ampla acima da regra Content filter não deve contornar a lista.

Para importar, selecionar especificamente Add content filter, introduzir o nome, selecionar um ficheiro como blocked.txt através de Choose file e clicar em Apply. Depois, na regra da política web, verificar explicitamente Block HTTP e Use action para HTTPS, confirmar o filtro com Apply selected items, ativar Status e guardar a política. A importação, por si só, não ativa qualquer bloqueio. Para o piloto, uma política própria e atribuída é mais adequada do que uma alteração não controlada da Default Policy partilhada.

Criar tipos de ficheiro web personalizados

O Sophos Firewall identifica os File types pela extensão do ficheiro ou pelo cabeçalho MIME. Os tipos incorporados não podem ser editados. Um tipo personalizado é criado em Web > File types > Add a partir de um modelo adequado, adicionando as extensões necessárias sem ponto inicial ou cabeçalhos MIME. O mesmo objeto pode depois ser usado em políticas de proteção web e de email.

Na caixa de diálogo Add, indique um nome. Template é opcional e inclui as extensões e os cabeçalhos MIME comuns de uma categoria; pode acrescentar valores ao tipo personalizado. Em seguida, guarde com Save. Não coloque um ponto antes da extensão: pdf está correto e .pdf não. Os tipos incorporados servem de modelos e não podem ser editados; para fazer alterações, crie um tipo personalizado.

O SFOS disponibiliza as categorias incorporadas 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 e Web files. A vista de detalhes em Web > File types é a referência operacional para as extensões e os cabeçalhos MIME atualmente configurados. Por exemplo, Compressed files inclui entradas como 7z, gz, rar, tar.gz e zip, enquanto Document files inclui entradas como docx, xlsx, pptx, odt, rtf e pdf. Antes de permitir uma categoria, abra o tipo incorporado específico na sua versão do SFOS e compare-o com o caso de utilização real, em vez de confiar apenas no nome.

O novo tipo de ficheiro não produz qualquer efeito por si só. Tem de ser selecionado em Activities > File types na regra da política web correspondente. Em seguida, verificam-se a ação, o estado e a ordem da regra, bem como se a política web continua atribuída à regra de firewall que processa realmente o tráfego.

A validação usa um download representativo e um ficheiro deliberadamente semelhante que não deve corresponder. No Log Viewer verificam-se a política web e a ação. Uma correspondência por extensão ou cabeçalho MIME é uma classificação de política, não uma prova de malware nem de uma análise Zero-Day concluída. Em HTTPS, a visibilidade necessária também depende do caminho de TLS Inspection. Se o tipo não corresponder, compare primeiro o estado e a ordem da regra, o File Type efetivamente selecionado, a resposta Content-Type do servidor, a extensão visível e o estado de TLS Inspection. Um tipo MIME incorreto ou genérico fornecido pelo servidor pode fazer com que o teste se comporte de forma diferente do que o nome do ficheiro sugere.

Referência dos tipos de ficheiro incorporados

A referência seguinte associa as extensões e os cabeçalhos MIME documentados às categorias incorporadas. Descreve uma classificação, não um ficheiro permitido ou seguro. Antes de fazer alterações, conferir os valores da sua própria instalação. All executable files também abrange ficheiros executáveis Mac/Linux através de cabeçalhos MIME adicionais; Executable files destina-se a Windows. Dynamic files geram conteúdos web dinâmicos e Encoded files incluem, entre outros, conteúdos encriptados ou codificados em formato binário. As categorias podem sobrepor-se: por exemplo, mdf aparece em bases de dados e em Disk Images, tar em documentos e tar.gz em ficheiros comprimidos. Em particular, application/octet-stream em Backup files é um valor MIME genérico, não uma prova fiável de que se trata de um ficheiro de cópia de segurança.

All executable files

• Extensões: exe, cmd, bat, com.
• Cabeçalhos MIME: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/x-dosexec, application/x-mach-binary, application/x-executable.

Audio files

• Extensões: gsm, sd2, qcp, kar, smf, midi, mid, ulw, snd, aifc, aif, aiff, m3url, m3u, wav, rm, ram, mp3, wmv.
• Cabeçalhos MIME: 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

• Extensões: asd, bak, bkp, bup, dba, dbk, fbw, gho, nba, old, ori, sqb, tlg, tmp.
• Cabeçalhos MIME: application/octet-stream.

Compressed files

• Extensões: 7z, alz, deb, gz, pkg, pup, rar, rpm, sea, sfx, sit, sitx, tar.gz, tgz, war, zip, zipx.
• Cabeçalhos MIME: 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

• Extensões: cfg, clg, dbb, ini, keychain, prf, prx, psf, rdf, reg, thmx, vmx, wfc.
• Cabeçalhos MIME: application/pics-rules, application/vnd.ms-officetheme.

Database files

• Extensões: accdb, db, mdsn, mdb, mdf, pdb, sql, sqlite.
• Cabeçalhos MIME: application/msaccess, application/x-msaccess, application/vnd.msaccess, application/vnd.ms-access, application/mdb, application/x-mdb, chemical/x-pdb.

Developer files

• Extensões: 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.
• Cabeçalhos MIME: 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

• Extensões: dmg, iso, mdf, nrg, nri, pvm, toast, vcd, vmdk.
• Cabeçalhos MIME: application/x-cdlink.

Document files

• Extensões: 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.
• Cabeçalhos MIME: 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

• Extensões: jsp, asp, php, cgi, shtml.
• Cabeçalhos MIME: text/x-script.perl, text/asp.

Encoded files

• Extensões: bin, enc, hex, hqx, mim, mime, uue.
• Cabeçalhos MIME: 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

• Extensões: exe, cmd, bat, com.
• Cabeçalhos MIME: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/x-dosexec.

Image files

• Extensões: bmp, gif, jpeg, jpg, pcx, png.
• Cabeçalhos MIME: 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

• Extensões: idml, indd, inx, isd, mdi, pmd, ptx, pub, qxb, qxd, qxp, rels, xps.
• Cabeçalhos MIME: application/x-mspublisher, application/vnd.ms-xpsdocument.

Plugin files

• Extensões: 8bi, arx, plugin, vst, xll.
• Cabeçalhos MIME: application/x-visio.

System files

• Extensões: bashrc, cab, cpl, cur, dll, dmp, drv, hlp, key, lnk, msp, prf, profile, scf, scr, sys.
• Cabeçalhos MIME: application/vnd.ms-cab-compressed, application/x-msdownload, application/hlp, application/x-helpfile, application/x-winhelp.

Video files

• Extensões: dat, mov, avi, qt, smi, sml, smil, flc, fli, vfw, mpeg, mpg, m15, m1u, m1a, m75, mls, mp2, mpm, rm, wmv, flv, swf.
• Cabeçalhos MIME: 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

• Extensões: alx, asax, asmx, aspx, atom, att, axd, chm, dwt.
• Cabeçalhos MIME: application/atom+xml.

Agrupar User Activities de forma clara

Em Web > User activities > Add, uma User activity reúne Web Categories, File types e URL Groups numa atividade reutilizável. Estes elementos são avaliados com OR; basta uma correspondência. O nome não identifica, portanto, um utilizador autenticado, mas sim uma coleção de critérios web.

A User Activity é depois selecionada em Activities na regra da política web. Isto é útil quando a mesma combinação é usada em várias políticas. Para a validação, testa-se pelo menos uma correspondência por cada tipo de objeto incluído e um caso semelhante que não deve corresponder.

Na caixa de diálogo, definir um nome descritivo como RISK_WEB_CONTENT, selecionar as categorias, os tipos de ficheiro ou os URL Groups necessários através de Add new item e guardar com Save. Show: All permite limitar os tipos de objeto apresentados, se necessário. Por exemplo, uma atividade pode reunir a categoria Spyware/Malware e uma lista própria de domínios de teste bloqueados: basta um destes critérios corresponder para acionar a ação Block da regra da política. Para os testes, utilizar destinos inofensivos sob o seu controlo, sem abrir um site real de malware.

Verificar a ordem das regras e as políticas migradas

As regras da política web são avaliadas de cima para baixo. Se, por exemplo, uma regra Allow para o tipo de ficheiro .mdb estiver acima de uma regra de bloqueio de categoria, os downloads .mdb dessa categoria continuam permitidos. No modo DPI, a ligação inicial à categoria pode ser permitida até o tipo de ficheiro ser identificado; se depois o ficheiro não corresponder, o firewall descarta a ligação sem apresentar uma página de bloqueio. Se a categoria tiver de ser sempre bloqueada, a respetiva regra deve ficar acima da regra Allow do tipo de ficheiro.

As políticas antigas migradas também estão sujeitas a um limite rígido de 128 regras por política. Se a origem contiver mais regras, o SFOS usa apenas as primeiras 128. Por isso, as regras adjacentes de User Activities, Categories, URL Groups, File types e Dynamic Categories são conscientemente reunidas em Activities combinadas antes ou depois da migração. A contagem, a ordem e testes reais de Allow e Block fazem parte da validação da migração.

As janelas recorrentes são criadas como um agendamento separado. O procedimento e a diferença em relação a uma regra de firewall controlada por horário estão descritos em Configurar agendamentos para regras e políticas na Sophos Firewall.

Uma política web por si só ainda não tem efeito. A política deve ser usada numa regra de firewall. Este é um dos erros de configuração mais comuns.

Só devem ser combinadas regras adjacentes com a mesma atribuição de utilizadores, as mesmas ações HTTP/HTTPS e as mesmas condições temporais. As diferenças em Content filters, Constraints ou na ordem não podem perder-se. Antes de combinar as regras, guardar uma cópia da política antiga ou documentá-la e registar correspondências e não correspondências representativas para cada Activity. Depois de combinar as regras, verificar novamente estas decisões; uma redução do número de regras, por si só, não comprova uma eficácia de proteção equivalente.

Configurar Advanced settings de forma direcionada

Enable logging and reporting inclui a política nos registos e relatórios; continua também a ser necessário ativar Log firewall traffic na regra de firewall correspondente. Prevent downloading of large files bloqueia downloads acima do tamanho introduzido. Escolher o limite com base nos downloads efetivamente necessários para o negócio e testá-lo com ficheiros inofensivos abaixo e acima desse valor; este bloqueio de downloads não é o mesmo que um limite de tamanho para a análise de malware.

Add X-Forwarded-For header to outgoing HTTP requests transmite ao destino o endereço IP do pedido HTTP original. Esta opção não é necessária para a filtragem web. Ativá-la apenas quando houver uma necessidade justificada, pois o servidor de destino recebe assim informações adicionais sobre o cliente; avaliar previamente a transmissão de endereços internos e os requisitos de proteção de dados. Para o piloto, documentar os valores anteriores e, em caso de efeitos indesejados, reverter exatamente estas alterações.

Ativar a Política Web na Regra de Firewall

A regra de firewall está em:

Rules and policies > Firewall rules

Para tráfego normal de clientes para a Internet, geralmente uma regra de LAN ou de uma zona de clientes para WAN é responsável. Nessa regra, na secção Web filtering, é selecionada a política web apropriada.

Pontos de verificação na regra de firewall:

• A zona de origem e as redes de origem correspondem à rede do cliente.
• A zona de destino é geralmente WAN.
• Os serviços incluem HTTP/HTTPS ou os serviços web desejados.
• Log firewall traffic está ativo.
• Na secção Web filtering, a política web correta está definida.
• Scan HTTP and decrypted HTTPS está ativo quando a verificação de malware web ou conteúdo deve funcionar.
• Use Zero-day protection só faz sentido se os ficheiros forem verificados por HTTP ou HTTPS desencriptado.
• Block QUIC protocol está conscientemente definido.
• No percurso transparente da regra de firewall, Use web proxy instead of DPI engine está ativo para SafeSearch, YouTube Restrictions e restrições Google Apps; para outras funções e no Direct Proxy, o modo é escolhido conscientemente conforme a necessidade.
• A Inspeção TLS é planeada separadamente e não confundida com a política web.

O Sophos Firewall ativa Block QUIC protocol por padrão quando uma política web é selecionada na regra ou quando Scan HTTP and decrypted HTTPS está ativo. Isto é frequentemente útil, porque QUIC não pode ser verificado como tráfego HTTPS clássico. Mesmo assim, a opção deve ser testada conscientemente: browsers, serviços Google, ferramentas de colaboração e aplicações SaaS individuais podem mudar o comportamento quando QUIC é bloqueado.

Se Application Control também for usado na mesma regra de firewall, existe uma sobreposição importante: algumas Micro Apps, por exemplo uploads ou downloads no Dropbox ou Gmail, são reconhecidas por detalhes de URL. Em ambientes DPI, esse reconhecimento requer uma regra SSL/TLS Inspection adequada com desencriptação. Assim, Application Control pode avaliar essas Micro Apps mesmo que a política web não seja o ponto principal de decisão.

Se uma regra mais geral acima da regra web desejada corresponder, o tráfego não alcança a política web. Em tais casos, Testar regras do Sophos Firewall com Log Viewer e Packet Capture pode ajudar.

Classificar HTTPS, Inspeção TLS e QUIC

Uma grande parte do tráfego web é HTTPS. Sem Inspeção TLS, o firewall vê menos conteúdo. Categorias, SNI, certificados, IP de destino, informações de domínio e metadados ajudam, mas não substituem uma verificação completa de conteúdo.

DPI ou Web Proxy?

Na Proteção Web, deve-se decidir cedo se a regra de firewall afetada usa o DPI Engine ou o Web Proxy. Esta decisão influencia quais funções são aplicadas e quais registos são relevantes posteriormente.

• Modo DPI: padrão moderno para muitas regras de clientes para a Internet. A Inspeção TLS é feita através de regras de inspeção SSL/TLS, Quota não é suportada.
• Modo Web Proxy: Ambientes com comportamento de proxy explícito ou Quota de política. Verificar comportamento do proxy, compatibilidade de navegador/cliente e registos do proxy conscientemente.

Em muitas instalações, o Modo DPI é o melhor ponto de partida. No entanto, se forem necessárias quotas de tempo através de Quota, uma regra puramente DPI não é suficiente. Nesse caso, o Modo Web Proxy deve ser planeado e testado conscientemente. Esta decisão deve ser tomada antes da implementação, pois uma mudança posterior pode gerar outros problemas, registos e experiências do utilizador.

Numa regra de firewall transparente, o Transparent Web Proxy processa apenas as portas clássicas 80 e 443. Noutras portas, o DPI Engine pode inspecionar tráfego HTTP e SSL/TLS, desde que correspondam tanto a regra de firewall como as regras SSL/TLS Inspection. O Direct Proxy é, pelo contrário, um percurso separado e explícito, escolhido pelo cliente, e não exige necessariamente Use web proxy instead of DPI engine. Por isso, em cada teste deve registar-se se o cliente usa o percurso transparente ou a sua configuração explícita de proxy.

A decisão funcional completa, a migração piloto e os testes específicos de cada modo estão reunidos em Comparar corretamente DPI Engine e Web Proxy.

Configurar o Direct Web Proxy com um ficheiro PAC explica como combinar o listener, o ficheiro PAC, o Device Access e uma regra de proxy funcional.

Os clientes só IPv6 que acedem a destinos web só IPv4 utilizam um caminho próprio de duas regras. NAT64 com Direct Web Proxy separa a Web Policy na regra IPv6 de Application Control e IPS no egress IPv4.

Se a Sophos Firewall tiver de encaminhar as suas Web Requests para um parent proxy, configurar um upstream proxy em WAN ou LAN/DMZ conduz pelo caminho correto de regras e NAT para cada topologia.

Quando vários utilizadores RDS partilham o mesmo IP de servidor, o Per-Connection AD SSO para hosts multiutilizador consegue distinguir as ligações HTTP e HTTPS individuais através do proxy. O método não se aplica a tráfego fora do proxy e deve, por isso, ser conscientemente diferenciado do SATC.

Inspeção TLS

Se downloads, verificação de malware, certas categorias web ou controlos de conteúdo precisarem de ser verificados de forma fiável, a Inspeção TLS deve ser planeada. Para isso, é necessário um certificado CA fiável nos clientes, regras TLS adequadas, exceções e um piloto limpo.

A implementação está em Implementar gradualmente a Inspeção TLS no Sophos Firewall. Para distribuir e validar o certificado CA, consulte Instalar Certificado CA do Sophos Firewall para Scanning HTTPS.

QUIC e HTTP/3

Os navegadores modernos frequentemente usam QUIC ou HTTP/3 sobre UDP 443. Isso pode interferir nas expectativas de filtragem web, inspeção TLS e verificação, se se pretende verificar o tráfego HTTPS clássico sobre TCP.

Em muitos ambientes empresariais, é sensato bloquear QUIC em regras de clientes para que os navegadores voltem para HTTPS sobre TCP. Os detalhes estão em Bloquear corretamente QUIC e HTTP/3 no Sophos Firewall.

SafeSearch, YouTube e Restrições de tenants

SafeSearch e YouTube ficam em Search engine enforcement; Google Apps e Entra em Advanced settings.

Opções típicas:

• Enforce SafeSearch para Google, Yahoo e Bing.
• Enforce YouTube restrictions para conteúdos restritos do YouTube.
• Restrict login domains for Google Apps para domínios Google permitidos.
• Apply Microsoft Entra ID tenant restrictions para controlo de tenants na cloud da Microsoft.

A referência da API XML do SFOS 22/23 descreve EnforceSafeSearch como aplicável apenas quando as categorias Adult Content, Nudity e Porn são recusadas na Web Policy. Verifique estas decisões na política efetivamente atribuída ao tráfego; ativar a opção e cumprir os pré-requisitos de proxy e HTTPS scanning não basta para comprovar esta condição documentada. Confirmar este requisito da API e o comportamento da interface no build utilizado. Se a ajuda da build instalada indicar algo diferente, esclareça a diferença antes de confiar no SafeSearch.

No percurso transparente da regra de firewall, SafeSearch, YouTube Restrictions e Google Apps exigem Use web proxy instead of DPI engine; um Direct Proxy explícito pode fornecer estas funções sem essa opção da regra de firewall. Bing e Yahoo por HTTPS exigem também HTTPS scanning. As Entra Tenant Restrictions devem ser tratadas separadamente e testadas com inícios de sessão reais da Microsoft, sem substituir a governação de identidades e aplicações cloud no Microsoft 365 ou Google Workspace.

No Bing e Yahoo, SafeSearch só pode ser imposto em ligações HTTPS se HTTPS scanning estiver ativo na regra de firewall afetada. As restrições de login do Google Apps aplicam-se apenas a domínios alojados pela Google. Microsoft Entra ID Tenant Restrictions precisam de valores de tenant limpos e devem ser testadas com logins reais na cloud Microsoft, não apenas com um URL de exemplo.

Em Apply Microsoft Entra ID tenant restrictions, Restrict-Access-To-Tenants contém os tenants permitidos numa lista de nomes de domínio ou IDs de domínio separados por vírgulas, com um máximo de 256 caracteres no total. Restrict-Access-Context contém o ID de domínio do tenant que define a restrição, com um máximo de 50 caracteres. Obter estes valores na gestão do seu próprio tenant, não numa configuração de exemplo de terceiros. Guardar previamente os valores existentes; depois, testar no piloto um início de sessão num tenant permitido e outro num tenant não permitido e, em caso de erros, repor apenas os valores alterados no estado anterior.

Quota e Páginas de Aviso

As políticas web podem não apenas bloquear ou permitir. Com ações de aviso ou quota, pode-se informar conscientemente os utilizadores ou permitir acesso temporário.

Exemplos úteis:

• Os utilizadores podem confirmar conscientemente um aviso para certas áreas cinzentas.
• Streaming ou compras são permitidos apenas por tempo limitado.
• Ambientes escolares ou de laboratório permitem certas categorias apenas durante horários definidos.

Importante: A Quota de política não é suportada no Modo DPI. Se forem necessárias quotas de tempo, deve ser utilizado o Modo Web Proxy. Esta decisão deve ser tomada cedo, pois DPI e Web Proxy têm características e limites diferentes.

A allowed time quota é definida ao nível da política web e aplica-se a todas as regras dessa política que usam uma ação Quota. Se duas categorias precisarem de quotas temporais diferentes, políticas web separadas são mais limpas do que uma única política com expectativas de quota misturadas. As quotas são repostas localmente à meia-noite e não podem ser definidas como zero.

Policy Quota não se aplica a Content filters ou Dynamic Categories e DPI não a suporta. Alterações não funcionam com política inválida, sem tempo restante ou sessão Quota já ativa.

Esta Policy Quota aplica-se a categorias web e não é a Surfing Quota baseada no utilizador. A criação, atribuição e verificação do consumo de Surfing Quota e Network Traffic Quota seguem um procedimento separado.

Ao aceder a um destino com uma ação Quota, é apresentada primeiro a página de quota. O utilizador escolhe uma duração até ao limite da quota disponível e seleciona Proceed, ou desiste do acesso com Return to previous page. No final do período escolhido, a página volta a aparecer; quando a quota se esgota, deixa de ser disponibilizado tempo restante. Em alternativa, um Policy Override pode permitir acesso temporário; nesse caso, a quota não se aplica. Por isso, a autorização de override não deve ser ativada como uma alternativa indiscriminada para todos os utilizadores.

Uma regra SSL/TLS Inspection correspondente com Action > Deny continua a bloquear; aumentar a quota ou efetuar um Reset não resolve este conflito. Verificar primeiro se o bloqueio TLS é intencional do ponto de vista dos requisitos de negócio. Planear uma Web Exception para ignorar a desencriptação HTTPS apenas num caso expressamente aprovado e de âmbito restrito. Esta exceção também remove as verificações que dependem dessa desencriptação e pode permitir certificados de servidor inválidos; não a utilizar como correção padrão. Testar separadamente o acesso piloto permitido, a manutenção do bloqueio fora do âmbito da exceção e o regresso ao estado anterior através da desativação da exceção piloto. O âmbito real da Web Exception tem de ser delimitado pelos seus critérios suportados, por exemplo, o IP de origem do piloto combinado com o padrão de hostname confirmado — não pelo grupo do utilizador da quota.

Verificar a Policy Quota durante a operação

Em Web > Policy quota status, o SFOS mostra para cada utilizador o tempo restante nas Web Policies afetadas dentro de um período de 24 horas. O utilizador selecionado pode ser reposto com Reset. Trata-se de uma alteração de estado deliberada, não de um botão de diagnóstico: primeiro documentam-se o utilizador, a policy, o tempo restante, o motivo e a hora.

Este reset afeta a Policy Quota temporal de uma categoria web. Não é o mesmo que Reset user accounting para Surfing Quota ou Network Traffic Quota. Um reset não corrige uma ordem de regras errada nem a falta de identificação do utilizador.

Personalizar páginas de aviso e bloqueio

Em Web > User notifications podem configurar-se imagens próprias e mensagens de bloqueio, override, quota e aviso. Os marcadores {category}, {user} e {url} inserem a categoria web, o nome do utilizador e o URL bloqueado. A preview verifica a apresentação e o texto, mas não comprova que a Web Policy e a regra de firewall corretas correspondem ao pedido de produção.

A mensagem deve explicar brevemente por que motivo o acesso foi bloqueado ou recebeu um aviso e onde comunicar uma necessidade empresarial legítima. Nomes de utilizador e URLs podem conter informação sensível; por isso, a página não deve incluir segredos internos, palavras-passe nem contactos desnecessários.

Para as imagens, ativar Use custom images e selecionar as imagens pretendidas. Para os textos, ativar a opção correspondente, Use custom block message, Use custom override message, Use custom quota message ou Use custom warn message, e introduzir o texto. Abrir o link Preview correspondente e depois verificar o tipo de mensagem adequado com um pedido real no piloto. Não utilizar dados reais de clientes nas imagens de teste.

Limitar os Policy Overrides em segurança

Um utilizador já autorizado pelo administrador cria a sua sessão no User Portal da seguinte forma:

1. Abrir My policy overrides > Add e atribuir um nome descritivo à sessão.
2. Manter o código de acesso fornecido ou gerar um novo através de Generate access code. Um código próprio criado manualmente só é permitido mediante autorização expressa.
3. Selecionar os sites e as categorias web permitidos que sejam necessários; os destinos bloqueados pelo administrador para overrides não podem ser autorizados.
4. Em Restricted to time periods, selecionar um agendamento existente na lista. Neste campo, seleciona-se um agendamento, não se introduz um período arbitrário como texto livre.
5. Guardar com Apply. Depois, introduzir o código de acesso no campo de código da página de bloqueio ao efetuar um pedido bloqueado correspondente.

Com Status, o utilizador ativa ou desativa esta sessão de override. Isto não equivale à gestão administrativa através de View overrides: o administrador pode, de forma independente, ativar, desativar ou eliminar a sessão criada pelo utilizador. Sem autorização, este procedimento não está disponível para o utilizador; mantém-se a restrição ao grupo principal do AD e a utilizadores individuais.

Policy Overrides são uma ferramenta diferente das quotas. Com Enable policy override, utilizadores autorizados podem criar no User Portal acesso temporário a sites normalmente bloqueados. Authorized users and groups limita quem o pode fazer e Blocked websites and categories define destinos que nunca podem ser contornados. Allow manual access code entry só é ativado quando os códigos criados pelos utilizadores se enquadram no processo de aprovação.

Em Web > General settings > Policy overrides, documentar primeiro o estado anterior e os utilizadores autorizados. No User Portal, o utilizador autorizado especifica sites ou categorias, um intervalo de tempo limitado e um código de acesso para o override. Ao solicitar um destino bloqueado correspondente, a página de bloqueio contém um campo adicional para esse código. Se Allow manual access code entry estiver ativo, os utilizadores especificados podem criar os próprios códigos; se estiver desativado, têm de utilizar códigos gerados. Esta escolha não deve ser confundida com a introdução de um código já válido na página de bloqueio.

View overrides permite apresentar, ativar, desativar e eliminar overrides existentes. Para a aceitação, utilizar um utilizador de teste autorizado para aceder a um destino correspondente dentro do intervalo de tempo com um código válido; sem código, fora do intervalo e para um destino que nunca possa ser autorizado por override, o bloqueio normal deve continuar a aplicar-se. Correlacionar utilizador, Rule ID, política Web, ação e hora no Log Viewer. Em HTTPS, a página de bloqueio tem de poder ser apresentada; uma simples interrupção da ligação não oferece um campo de introdução.

Para o rollback, desativar o override piloto através de View overrides e verificar o bloqueio original com um novo pedido. Só depois eliminar um override que já não seja necessário e restaurar apenas os valores globais alterados durante o piloto ao estado anterior documentado. Não remover indiscriminadamente os overrides existentes de outros utilizadores.

Para utilizadores AD, My policy overrides aplica-se apenas ao grupo principal e a utilizadores individuais, não a outras pertenças a grupos. Uma regra de inspeção SSL/TLS correspondente com Action > Deny continua a ter prioridade. Se um override aprovado tiver de funcionar nessa situação, planeia-se uma Web Exception de âmbito restrito que ignore a desencriptação HTTPS e testa-se separadamente um caso negativo; a regra TLS não é enfraquecida de forma geral. A autorização de override não restringe a Web Exception; definir o âmbito próprio desta por IP de origem combinado com hostname/categoria e validá-lo com testes negativos, conforme descrito abaixo.

Web Exceptions e exceções TLS

Ignorar HTTPS decryption remove verificações dependentes e permite certificados de servidor inválidos; Malware and content scanning ignora automaticamente Zero-day protection. Padrões hostname funcionam no contexto TLS; caminhos URL só em HTTP ou HTTPS já desencriptado. URL Group não é critério de Web Exception.

Web Exceptions são poderosas e, por isso, perigosas quando usadas como reparação rápida. Uma exceção em Web > Exceptions pode ignorar verificações de proteção para tráfego correspondente, independentemente da política web atualmente aplicada. Conforme a seleção, são ignorados HTTPS decryption, HTTPS certificate validation, Malware and content scanning, Zero-day protection ou Policy checks.

Em ambientes DPI aplica-se uma limitação importante: Web Exceptions só têm efeito quando existe uma política web definida, Malware and content scanning está ativo ou ATP está ativo. SSL/TLS Exclusion Rules são, por outro lado, o local correto quando o objetivo é apenas não desencriptar determinadas ligações TLS. A diferença operacional é importante:

• SSL/TLS Exclusion Rule: exclui ligações TLS da desencriptação de forma direcionada, normalmente por Certificate Pinning ou incompatibilidade.
• Web Exception: pode ignorar verificações de política web, verificação de malware, análise Zero-Day ou validação de certificados.
• URL Group in Web Policy: controla Allow, Warn, Block ou Quota dentro da lógica normal da política.

Para Web Exceptions, evitar domínios raiz e padrões de expressões regulares de URL demasiado amplos: um padrão simples como example.com também pode corresponder a texto no caminho ou na query de outro domínio. Padrões específicos de hostname podem corresponder no contexto TLS; os caminhos de URL só são visíveis em HTTP ou em HTTPS já desencriptado. Os critérios suportados pelas Web Exceptions são padrões de expressões regulares de URL, categorias web, endereços IP de origem e endereços IP de destino — não utilizadores, grupos de utilizadores ou URL Groups.

Para uma permissão de negócio limitada a um grupo de utilizadores, utilizar a regra de firewall correspondente e Users na Web Policy; para uma exclusão de desencriptação limitada por identidade no modo DPI, utilizar a regra de inspeção SSL/TLS adequada com Don’t decrypt e critérios explícitos de utilizador/grupo. Esses critérios de identidade não passam a ser critérios de uma Web Exception aplicada separadamente, nem limitam, por si só, o âmbito das verificações que esta ignora.

Para um piloto de Web Exception, combinar os Source IP addresses dos clientes específicos com um padrão de hostname confirmado ou uma categoria web justificada. Testar tanto uma origem não aprovada como um destino fora desse âmbito real de correspondência; um endereço IP não é uma identidade de utilizador. Não inferir da lógica genérica AND que as exceções por IP de origem e IP de destino podem ser combinadas para exclusão TLS: as orientações mantidas sobre exclusão TLS indicam que não podem ser combinadas, e o seu âmbito exato não é claro. Se ambas as restrições por IP forem necessárias, parar sem ativar nem alargar a exceção e obter esclarecimentos específicos para a build utilizada. O procedimento e os limites de correspondência são descritos em Criar e testar Web Exceptions de forma segura.

As exceções combinam os seus diferentes critérios com AND. Dentro de um tipo de critério, por exemplo vários URL Patterns, aplica-se OR. Isto é prático, mas sujeito a erros: uma exceção com URL Pattern e Source IP só se aplica se ambos corresponderem. Uma exceção com muitos URL Patterns pode, pelo contrário, atuar muito mais amplamente do que esperado.

É preciso ter especial cuidado com Policy checks. Se uma Web Exception ignorar Policy checks, pode enfraquecer indiretamente outras decisões de regras. Em combinação com Synchronized Security Heartbeat, uma exceção desse tipo pode fazer com que pedidos web não sejam bloqueados como esperado, embora existam controlos Heartbeat na regra de firewall.

Automatizar de forma direcionada a Web Protection através da XML API

A XML API é útil quando os mesmos objetos Web validados têm de ser mantidos em várias firewalls. Não substitui a atribuição da Web Policy à regra de firewall efetivamente adequada, nem a verificação do tráfego. Antes de escrever, guardar o inventário atual de objetos, as respetivas referências e a Policy anterior. O acesso, a construção de requests, a versão da API, o estado XML e o Audit Trail são explicados em Configurar o acesso à XML API de forma segura e avaliar as respostas. As relações entre objetos seguintes não constituem um pedido completo executável. Nos casos de contradições entre fontes expressamente indicados, consultar primeiro a API help da build instalada e não escrever sem um esclarecimento inequívoco.

Primeiro os objetos, depois a Policy e a atribuição

Um caso de automatização de âmbito limitado é uma URL Group própria para destinos de negócio, um File Type próprio para downloads e uma User Activity que reúne estes critérios. Primeiro, ler ou criar estes objetos com os seus nomes reais; depois, fazer com que as regras da Policy referenciem estes objetos; e, por último, atribuir de forma controlada a Web Policy à regra de firewall existente e efetivamente adequada. Um novo objeto, por si só, ainda não permite nem bloqueia tráfego.

• URL Group: WebFilterURLGroup contém Name e entradas URL repetidas em URLlist. A grafia URLlist não é a mesma que URLList de uma Web Category externa. IsDefault identifica uma URL Group incorporada; segundo a referência, o campo é apenas de leitura e as alterações ao mesmo são ignoradas durante a atualização. Não transforma um objeto próprio num objeto predefinido editável. Para valores de domínio adequados e para a manutenção na UI, continua a prevalecer o procedimento de URL Group.
• File Type: FileType reúne FileExtensionList, com valores FileExtension repetidos, e MIMEHeaderList, com valores MIMEHeader repetidos. O comentário no exemplo XML descreve Template indicando que as extensões e os cabeçalhos MIME do modelo são incorporados e que as entradas indicadas separadamente são adicionadas. Por isso, após a escrita, verificar a lista completa efetiva, e não apenas os valores acrescentados. O exemplo apresenta Blank, mas a tabela de parâmetros não explica Template; não deduzir daí uma lista universal de modelos permitidos. As extensões continuam sem ponto inicial, por exemplo, pdf.
• User Activity: UserActivity utiliza Name para o nome existente e NewName para uma alteração de nome pretendida. Em CategoryList encontram-se objetos Category com Type e ID. No exemplo, as designações de tipo web category, file type e url group estão separadas da ID, que é o nome do objeto. Não utilizar uma palavra de tipo como ID de objeto nem inventar uma ID numérica. O exemplo designa a tag de descrição como Desc, enquanto a tabela indica Description; confirmar a tag válida para a build específica. A combinação OR dos critérios da Activity continua separada da ação HTTP/HTTPS posterior.

Em caso de erro de File Type, estas respostas XML são particularmente relevantes: Edit File Type 202 / Message.FileTypeUpdateWithRename, Add File Type ou Edit File Type 503 / Message.FileTypeSameDetailRecordExists e 505 / Message.FileTypeInvalidExtensionOrMIMEHeader. Estes são símbolos da referência inalterados, não textos de mensagens resolvidos nem códigos HTTP. No caso de 202, ler os nomes antigo e novo, bem como as referências da Policy; no caso de 503, comparar os valores de detalhe já existentes; e, no caso de 505, verificar as extensões/os cabeçalhos MIME. Não criar simplesmente um segundo objeto com outro nome.

Categorias próprias: separar conteúdo, classificação e largura de banda

WebFilterCategory distingue, através de ConfigureCategory, duas vias de entrada: Local utiliza DomainList/Domain e KeywordList/Keyword; External utiliza URLList/URL para a lista de categorias externa. Um URL de lista externa não é automaticamente um valor de domínio de negócio a autorizar. A origem, a atualização e o conteúdo da lista externa têm de ser rastreáveis. Não misturar as duas vias num request sem as verificar.

Classification classifica a categoria, mas não decide entre Allow ou Block. A descrição utiliza, em parte, designações diferentes das da tabela de enumerações; esta indica Productive, Unproductive, Acceptable e Objectionable. Também ConfigureCategory não é totalmente consistente: o exemplo apresenta Local/External, enquanto a tabela inclui ainda 0. Não transmitir nomes de classificação traduzidos nem 0 como substituto sem verificação. QoSPolicy referencia uma política de largura de banda, não uma ação de Web Policy; a seleção e o efeito são verificados no procedimento de Traffic Shaping. Só uma regra de Web Policy adequada transforma a categoria numa decisão de acesso.

A tabela de categorias exige uma verificação posterior rigorosa dos detalhes:

• Add Category 201 / Message.WFCCategoryDetailCannotAdded e Update Category 201 / Message.WFCCategoryDetailCannotUpdated: não tratar todas as respostas XML 2xx como valores de domínio/palavra-chave/lista integralmente guardados. Voltar a ler separadamente o cabeçalho do objeto e cada conjunto de detalhes necessário. Add Category 202 referencia, tal como 200, Message.WFCAddSuccess; o nome de símbolo comum não explica a diferença entre os códigos.
• Add Category 522 / Message.WFCMaxFiveURL e 523 / Message.WFCMaxFiveKeyword, mas Update Category 503 / Message.WFCMaxFiveURL e 504 / Message.WFCMaxFiveKeyword: avaliar conjuntamente a operação e o código. Os nomes dos símbolos, por si só, não comprovam um limite atual universal de cinco entradas; esclarecer a dimensão efetivamente permitida na ajuda da build.
• Delete WebFilter Category 201 / Message.WFCRelationExists e 203 / Message.WFCSomeCategoryCannotDeleted: verificar as referências e as categorias restantes antes de eliminar ou voltar a tentar. Não assumir um sucesso de eliminação global para uma seleção de várias categorias.

Todos os símbolos Message.* permanecem aqui intencionalmente por resolver. Antes de uma nova tentativa, guardar o estado efetivamente armazenado e a resposta; em particular, não repetir cegamente uma alteração de categorias parcialmente aplicada.

Content Condition Lists: Key não é Name

Um objeto ContentConditionList contém o Name visível, a identidade separada Key e ContentList com valores ContentString repetidos. A referência exige Name e Key; para Delete Content Condition List, o seletor é expressamente Key. Por isso, ao ler e documentar, preservar ambos os valores e nunca utilizar o nome apresentado como chave de eliminação sem o verificar.

A tabela da API descreve ContentString como valores Regex em bruto e afirma que os duplicados não são ignorados. Em contrapartida, a importação pela UI descrita acima é uma lista de texto com um Exact Match por linha. Assim, não está demonstrado que uma importação pela UI e uma lista Regex da API tenham um formato de entrada idêntico. Antes de uma migração, esclarecer a semântica com a ajuda da build e testar correspondências e não correspondências inofensivas; não transmitir uma lista de texto existente como payload Regex sem a verificar.

São particularmente evidentes as associações contraditórias entre operações e mensagens na referência:

Estas linhas demonstram uma contradição na documentação, não que um Update elimine ou que um Delete atualize. Verificar a operação, a Key, a resposta e os conteúdos efetivamente existentes. Sem um esclarecimento inequívoco relativo à build, não deduzir daí uma operação destrutiva nem iniciar uma nova tentativa automática com base num nome de símbolo.

WebFilterPolicy: preservar a ordem e os seletores

WebFilterPolicy mantém as regras em RuleList/Rule. Cada regra referencia, em CategoryList/Category, um nome de objeto ID e um seletor type. O exemplo da Policy utiliza WebCategory, URLGroup, UserActivity, DynamicCategory e FileType; estes tokens diferem das designações de tipo no exemplo de User Activity e, no exemplo da Policy, a tag type está em minúsculas. Utilizar a grafia, o tipo de objeto e o nome existente do objeto lido ou da ajuda da build, em vez de serializar etiquetas da UI ou IDs inventadas.

HTTPAction e HTTPSAction são decisões separadas; FollowHTTPAction descreve a ligação entre elas. O exemplo da API indica Deny, Allow, Warn, Log e Quota. Estes valores de exemplo não confirmam que todos sejam selecionáveis em todas as builds, e Deny não deve ser simplesmente substituído pela palavra Block da UI. PolicyRuleEnabled controla a ativação da regra, Schedule o agendamento referenciado e UserList/User o âmbito de utilizadores. CCLRuleEnabled e CCLList/CCL associam os filtros de conteúdo à regra; o exemplo referencia aí um nome de CCL, enquanto a eliminação da CCL exige a respetiva Key. O comportamento HTTPS de um Content Filter tem de continuar a corresponder à ligação na UI explicada acima. Ao atualizar, preservar a ordem, o âmbito de utilizadores, o agendamento, os filtros de conteúdo e a Default Action, e comparar toda a Policy guardada. A ausência de um campo não permite pressupor com segurança a sua preservação ou eliminação.

Para as entradas que se seguem, a referência não fornece um modelo executável isento de contradições:

• DefaultAction: a tabela indica um máximo de um caráter, mas permite simultaneamente Allow e Deny. Não reduzir a um caráter nem inventar uma codificação numérica alternativa. EnableReporting apresenta Enable/Disable no exemplo, enquanto a tabela permite apenas Enable; por conseguinte, a desativação não está confirmada sem verificação da build.
• DownloadFileSizeRestriction: o comentário XML indica de 1 a 1536 MB, enquanto a tabela de parâmetros indica de 0 a 1536. O significado de 0 permanece, portanto, por esclarecer; não o tratar como ausência de limite nem como um limite ativo válido. Definir conjuntamente o comutador DownloadFileSizeRestrictionEnabled e o limite com base na ajuda da build, e verificar com ficheiros inofensivos de ambos os lados do limite confirmado. A tabela da API indica valores de 1 a 1440 para QuotaLimit; confirmar o intervalo no build utilizado. O DPI continua a não suportar a Policy Quota.
• Tenant Controls: Office365Enabled, Office365TenantsList e Office365DirectoryId pertencem à restrição de tenants Microsoft. Para a lista, a tabela da API indica 4096 carateres, mas a ajuda da UI para Restrict-Access-To-Tenants indica 256; não equiparar estes limites nem deduzir da indicação da API um valor mais longo para utilização em produção. O valor de exemplo de Office365DirectoryId, 456ff232-35l2-5h23-b3b3-3236w0826f3d, contém carateres não hexadecimais e não é um valor de exemplo de GUID válido. Não o corrigir silenciosamente; utilizar a Directory-ID real da própria administração do tenant e testar inícios de sessão em tenants permitidos e não permitidos. Confirmar o mapeamento dos campos da UI, os comprimentos e a semântica na build instalada.

Add Policy 522 / Message.WebPoliciesLimit diz respeito ao limite de Policies; não deduzir daí um limite para regras ou categorias. Update Policy 503 / Message.WFPQuotaLimitInvalid exige a verificação da entrada de Quota. A referência apresenta ainda Update Policy from API como uma designação de operação própria; as respetivas linhas de resposta não contêm esta entrada 503. Isto não demonstra que esta via aceite qualquer Quota. Verificar o estado, a Policy guardada e o efeito real antes de voltar a escrever.

Não misturar opções de proteção globais e notificações

WebFilterSettings é a área de definições globais do filtro Web, não uma WebFilterPolicy individual. Contém, entre outros, PharmingProtection, Scanning, BlockUnscannableContent e PUAWhitelist com nomes PUA repetidos. Uma entrada PUA é uma exceção conscientemente aprovada, não um passo necessário para uma nova Web Policy. A seleção do scanner e o seu efeito continuam a ser abordados no procedimento de Malware Scanning associado; adaptar uma mensagem não é motivo para alterar, em paralelo, opções de proteção globais ou a lista PUA.

WebFilterProtectionSettings é outro contrato distinto de análise/proteção, com campos como ScanMode e FileSizeThreshold. Os campos de proteção com nomes semelhantes não o tornam um sinónimo de WebFilterSettings ou de WebFilterNotificationSettings; não trocar payloads entre estes objetos. Para um texto meramente informativo, não incluir opções de análise, tamanho ou certificado. Também para este objeto de proteção, o contrato válido deve provir da ajuda do build, e não de valores de exemplo adotados sem verificação.

Também aqui o exemplo contradiz a tabela: BlockUnscannableContent apresenta Enable/Disable, enquanto a tabela permite Allow e Block (Best Protection). Não uniformizar estas enumerações nem as adivinhar a partir do nome do campo. Antes de qualquer alteração, guardar o comportamento anterior e esclarecer o contrato exato da build.

Em contrapartida, WebFilterNotificationSettings destina-se às notificações dos utilizadores. OverrideDefaultDeniedMessage corresponde a DefaultDeniedMessage, e OverrideDefaultWarnedMessage a DefaultWarnedMessage; os textos personalizados só são selecionados de forma deliberada com o Override adequado. A tabela contém campos adicionais de Override/Quota que faltam parcialmente no exemplo: OverrideDefaultOverrideMessage/DefaultOverrideMessage e OverrideDefaultQuotaMessage/DefaultQuotaMessage. Os comutadores de Override/Quota indicam 0/1 como valores permitidos, mas simultaneamente Enable como valor predefinido. Esta é outra contradição entre fontes e não um motivo para codificar todas as flags da mesma forma. Para uma simples alteração de texto, modificar apenas os campos de texto/Override previstos, de acordo com o contrato confirmado da build, e verificar a página correspondente no piloto.

DeniedMessageImage seleciona Default ou Custom. O exemplo associa TopImageFile e BottomImageFile a um nome de ficheiro do request Multipart; a tabela descreve jpg/jpeg. No caso de User Notifications, porém, a tabela designa o parâmetro superior como Top Image, enquanto o exemplo utiliza TopImageFile. Estas indicações não são suficientes para construir com segurança os nomes das partes, o Content-Disposition, o endpoint de upload ou a associação de ficheiros. Esclarecer primeiro a transferência de ficheiros com base na ajuda da build ou numa Collection oficial confirmada para esse fim. Não efetuar alterações automatizadas de imagens sem um contrato de upload confirmado. Os campos de mensagem/imagem semelhantes em WebFilterSettings não tornam os dois objetos intercambiáveis.

DefaultWebFilterNotificationSettings é, por sua vez, separado: disponibiliza textos de mensagem predefinidos com nome, por exemplo, WebsiteBlocked. Um caso de utilização útil e restrito é um aviso aprovado com o contacto de suporte correto. Para tal, guardar exatamente o texto original afetado, alterar apenas a chave de mensagem confirmada, verificar a pré-visualização correspondente e a página real do piloto e, se necessário, repor exatamente esse texto. O texto da mensagem não constitui uma autorização de acesso nem prova de uma deteção de malware/Zero-Day.

Voltar a ler e validar cada alteração automatizada

Após cada operação de escrita, voltar a ler o objeto exato a que se dirigiu a operação através da API ou no WebAdmin: comparar nomes/Keys, listas efetivas, referências, ordem da Policy, ativação e atribuição efetiva à firewall. Em seguida, executar os mesmos requests de piloto permitidos e bloqueados que antes da alteração e correlacionar Rule ID, utilizador, Web Policy e ação no Log Viewer. Um sucesso HTTP, um código XML 2xx ou um símbolo Message.* por resolver, por si só, não é suficiente. Em caso de alteração parcial ou resposta pouco clara, guardar primeiro o estado atual e o Audit Trail e só depois corrigir de forma direcionada; não repetir cegamente operações Add/Delete. Apenas são revertidas as alterações próprias documentadas, não outras Policies, Overrides ou valores de proteção globais existentes.

Testar a Proteção Web

Após guardar, não se deve apenas verificar se a política existe. O crucial é se ela se aplica ao tráfego real.

1. Usar o Policy Tester

O percurso exato é Diagnostics > Tools > Pop-out tools > Policy tester. Firewall, SSL/TLS, and web testa o percurso transparente combinado, enquanto Web policy only isola a decisão da política web. O teste web representa apenas acessos transparentes, não considera rotas SD-WAN e não aceita Source Networks com endereços MAC. Se não for indicado um protocolo, utiliza HTTP; se não for indicada uma porta, utiliza a porta predefinida do protocolo escolhido.

Antes da alteração, devem executar-se ambos os modos relevantes como referência e registar-se o resultado e a Rule ID esperada; depois, repetem-se exatamente os mesmos testes. O Policy Tester continua a ser uma verificação preliminar e não substitui testes Allow e Block reais a partir de um cliente piloto, porque o NAT, a Inspeção TLS, o QUIC, o encaminhamento ou um percurso Direct Proxy explícito podem tratar o fluxo real de forma diferente.

2. Teste Real com Cliente Piloto

Com um cliente piloto, verificar:

• site de negócios permitido
• categoria bloqueada
• categoria de aviso
• Permissão de Grupo de URLs
• Bloqueio de Grupo de URLs
• Página HTTPS com e sem Inspeção TLS
• Download de um tipo de ficheiro de teste inofensivo
• Comportamento com QUIC ativo ou bloqueado

3. Verificar o Log Viewer

No Log Viewer, deve ser visível:

• qual regra de firewall foi atingida
• qual utilizador foi reconhecido, se relevante
• qual categoria web ou grupo de URLs esteve envolvido
• se HTTPS, Inspeção TLS ou verificação de malware estiveram envolvidos
• se a ação permitiu, avisou ou bloqueou
• se uma Web Exception ou TLS Exclusion foi aplicada
• se um download foi tratado de forma diferente por tamanho, erro de verificação de malware ou análise Zero-Day

Em Syslog ou SIEM, URL e action não são suficientes. Para uma análise robusta, também são necessários Firewall Rule ID, utilizador, categoria, política web, método HTTP, status, resultado da verificação, indicação de exceção e relação SSL/TLS. Se estes campos estiverem ausentes no SIEM ou forem normalizados incorretamente, a Proteção Web parece rapidamente menos clara nos relatórios do que realmente é no firewall.

Para resolução de problemas mais aprofundada, também são relevantes os ficheiros de log. A atribuição está em Resolução de Problemas do Sophos Firewall: Serviços e Logs.

Alertas Instantâneos e Relatórios

Se certas categorias não apenas devem ser bloqueadas, mas também relatadas ativamente, os Alertas Instantâneos podem ser úteis. Isso é particularmente útil em escolas, ambientes altamente regulados ou áreas com uma política clara de uso da Internet.

Os três métodos de avaliação respondem a diferentes perguntas:

• E-mail rápido para poucas categorias web sensíveis: Alertas Instantâneos.
• Relatórios recorrentes, tendências e avaliações de utilizadores ou categorias: Central Firewall Reporting.
• Retenção mais longa, correlação com outros sistemas ou processos SOC: Syslog ou SIEM.

Antes dos Alertas Instantâneos, deve-se esclarecer quem recebe a notificação, quais categorias realmente desencadeiam uma reação, como os falsos positivos são tratados e quando a seleção de categorias é revisada. Uma lista de alertas ampla sem responsável gera rapidamente ruído de e-mail, mas não melhora a segurança.

Para a ativação técnica e triagem, consulte Utilizar Categorias Web e Alertas Instantâneos do Sophos Firewall. Para avaliações de longo prazo, deve-se considerar Central Firewall Reporting ou Enviar Syslog do Sophos Firewall para SIEM.

Gerir Alterações e Exceções em Operação

A Proteção Web muda continuamente em operação. Novos serviços SaaS são adicionados, domínios individuais são categorizados incorretamente, departamentos precisam de acesso temporário e o comportamento dos navegadores muda. Sem um procedimento claro, rapidamente surgem exceções amplas que ninguém pode explicar mais tarde.

Para cada alteração, deve-se pelo menos registar:

• Quem precisa de acesso? evita exceções globais para poucos utilizadores.
• Qual domínio, categoria ou tipo de ficheiro está envolvido? separa claramente Grupo de URLs, Categoria Web e Tipo de Ficheiro.
• É uma exceção temporária ou permanente? força revisão em vez de aprovações permanentes.
• Qual regra de firewall e política web são afetadas? evita alterações na regra errada.
• Como será testado? torna o sucesso verificável no Log Viewer.

Um pequeno procedimento de mudança tem-se revelado eficaz:

1. Registar o pedido com utilizador, URL, horário, motivo de negócios e captura de ecrã ou mensagem de erro.
2. Verificar no Log Viewer qual regra de firewall, política web, categoria e ação foram aplicadas.
3. Decidir se a categoria está fundamentalmente errada, se apenas um domínio individual deve ser permitido ou se o pedido é rejeitado.
4. Se for necessária uma permissão de negócio, mantê-la restrita na regra de firewall correspondente e na Web Policy: um URL Group específico em vez de uma categoria inteira, e Users explícitos em vez de toda a LAN. Se, em alternativa, for necessária uma Web Exception, utilizar os seus próprios critérios suportados de URL/categoria/IP; um grupo de utilizadores ou um URL Group não é um critério de Web Exception.
5. Verificar a alteração numa regra de teste ou grupo piloto.
6. Após guardar, realizar um teste real e documentar Log Viewer, categoria, ID da regra e contexto do utilizador.
7. Definir uma data de revisão, especialmente para exceções temporárias de negócios.

Exceções temporárias devem ser claramente nomeadas, por exemplo, TMP_ALLOW_vendor-portal_until_2026-07-31. Exceções permanentes de negócios também precisam de um responsável. Se ninguém for responsável por uma exceção, ela não deve permanecer permanentemente na política.

Se muitos domínios individuais surgirem para o mesmo serviço, geralmente o problema não é a política web, mas a arquitetura do serviço. Nesse caso, deve verificar-se se uma regra de firewall própria, uma política web própria, um grupo de URLs bem mantido ou outro ponto de controlo é mais adequado. Para listas dinâmicas de IOC ou de bloqueio, as exceções de política web geralmente não são o local correto; para isso, são mais adequados Sophos Firewall Threat Feeds.

Rollback e acesso de emergência

Uma alteração na política web pode afetar imediatamente o trabalho produtivo. Portanto, antes de grandes alterações, deve-se definir como restaurar o estado anterior.

Opções práticas de rollback:

• Duplicar ou documentar a política web afetada antes da alteração
• Testar a alteração primeiro numa regra piloto ou pequeno grupo de utilizadores
• Não excluir imediatamente a regra de firewall antiga ou a política web antiga
• Definir janela de tempo, utilizadores de teste e critério de fallback
• Após guardar, verificar Log Viewer, ID da regra e decisão de categoria

Em caso de bloqueios urgentes, não inserir reflexivamente uma regra Allow ampla no topo. Preferir uma permissão de negócio restrita e limitada no tempo na regra de firewall correspondente e na Web Policy, com um URL Group específico, Users explícitos e uma data de revisão. Isto não é uma Web Exception limitada a um grupo de utilizadores. Qualquer desvio necessário à inspeção requer os seus próprios critérios de correspondência aprovados e suportados, bem como testes positivos e negativos separados. Reavaliar posteriormente a permissão temporária.

Erros Comuns

A Política Web não se aplica

Geralmente, a política não está ativada na regra de firewall correta, a regra não é atingida, uma regra acima permite o tráfego ou o contexto do utilizador não corresponde. Primeiro, verificar Log Viewer e ID da regra.

HTTPS não é bloqueado como esperado

Sem Inspeção TLS, o firewall vê menos detalhes. Dependendo do destino, uma decisão de domínio ou categoria pode funcionar, enquanto a verificação de conteúdo, tipos de ficheiros ou certas funções de pesquisa permanecem limitadas.

Se a ligação não for desencriptada, o firewall ainda pode usar informações SNI ou de domínio para decisões de política. Páginas de bloqueio, páginas de aviso, tipos de ficheiros, Content Filters, verificação de malware e análise Zero-Day precisam, porém, de mais visibilidade. Por isso, no Log Viewer deve-se verificar não só a ação da política web, mas também o estado SSL/TLS Inspection.

QUIC contorna a expectativa

Se os navegadores usarem UDP 443, o tráfego pode ser processado de forma diferente do HTTPS clássico sobre TCP. Em regras de clientes, deve-se decidir conscientemente se o QUIC é bloqueado.

Regra de Permissão está muito acima

Uma regra de permissão ampla no início da política web pode anular regras de bloqueio posteriores. A ordem das regras dentro da política web é tão importante quanto a ordem das regras na lista de regras de firewall.

Muitas Exceções

Exceções resolvem rapidamente um problema individual, mas podem reduzir a eficácia da proteção. Cada exceção precisa de um propósito, responsável e data de revisão. Se muitas exceções surgirem, geralmente a estrutura da política está errada ou uma aplicação de negócios precisa de uma regra própria.

São especialmente arriscadas as Web Exceptions que ignoram Policy checks ou Malware and content scanning. Se apenas HTTPS decryption causar problemas, uma SSL/TLS Exclusion é normalmente mais estreita e mais compreensível.

Relatórios não mostram nada

Então, deve-se verificar registo, relatórios, regra de firewall, seleção de política ou encaminhamento de logs. Uma política sem registo é difícil de avaliar em operação.

Lista de Verificação de Operação

• Status da licença de Proteção Web verificado.
• Tráfego de clientes, servidores, convidados e VPN avaliado separadamente.
• Política web criada com nome descritivo.
• Categorias críticas e Grupos de URLs planeados conscientemente.
• Ordem das regras dentro da política web verificada.
• Política web ativada na regra de firewall apropriada.
• Log firewall traffic, logging da política web e Reporting ativos.
• Regras da política web ativadas e na ordem correta.
• Inspeção TLS e certificado CA para grupo piloto verificados.
• Estratégia QUIC definida.
• Web Exceptions e TLS Exclusions documentadas separadamente.
• Policy Tester e testes reais realizados.
• Log Viewer e relatórios controlados.
• Processo de alteração para exceções de política web definido.
• Exceções temporárias com data de validade atribuída.
• Exceções documentadas com responsável e data de revisão.

FAQ