Configurar e testar o Application Control no Sophos Firewall
Application Control no Sophos Firewall identifica aplicações independentemente da porta. Isto permite, por exemplo, permitir, bloquear ou registar ferramentas de controlo remoto, aplicações de tunneling, streaming, armazenamento cloud, mensageiros ou contornos de browser arriscados.
O benefício prático só surge quando o Application Control está ativo na regra de firewall correta, a aplicação é realmente reconhecida e os logs são analisados. Uma política de filtro de aplicações armazenada por si só não bloqueia nada.
Resposta rápida
O Application Control é utilizado em dois passos:
- Em Applications > Application filter, planeie ou crie uma política de filtro de aplicações.
- Na regra de firewall apropriada, em Other security features, selecione Identify and control applications (App control).
Em vistas de navegação mais antigas, esta área pode aparecer em Protect > Applications > Application filter. Depois, é necessário testar com um cliente real se o tráfego passa por essa regra e se a aplicação é corretamente reconhecida no Log Viewer. Para tráfego encriptado, a inspeção TLS pode ser crucial, pois a firewall pode ver menos detalhes dependendo da aplicação.
Quando o Application Control é útil
O Application Control é especialmente útil quando as portas por si só não são suficientes. Muitas aplicações usam HTTPS, destinos variáveis ou infraestrutura cloud. Uma regra de porta simples só vê 443, mas não se é um serviço empresarial permitido, uma ferramenta de controlo remoto ou um armazenamento cloud indesejado.
Casos típicos de uso:
- Bloquear TeamViewer, AnyDesk, Tor ou ferramentas de proxy
- Restringir streaming ou redes sociais em determinadas redes
- Controlar armazenamento cloud
- Limitar mensageiros ou jogos em redes de convidados ou escolares
- Ativar reconhecimento de aplicações para relatórios e análises
- Preparar Traffic Shaping para aplicações reconhecidas
Se o objetivo não é reconhecimento ou bloqueio, mas sim priorização ou limitação de largura de banda, consulte Configurar Application Traffic Shaping no Sophos Firewall.
Pré-requisitos
Antes da configuração, verifique os seguintes pontos:
- Licença adequada com Web Protection ou Application Control
- Regra de firewall afetada é conhecida
- Log firewall traffic está ativo para a regra de teste
- Aplicação ou categoria desejada está claramente definida
- Cliente de teste e destino de teste estão definidos
- Para aplicações HTTPS, está claro se a inspeção TLS será usada
- As assinaturas de aplicações e as Pattern Updates funcionam
Verifique o estado da licença em System > Administration > Licensing. Nos pacotes típicos do Sophos Firewall com Web Protection, o Application Control está incluído. A lógica de licenciamento específica deve ser verificada antes da implementação em produção, especialmente em caso de subscrições expiradas ou licenças de teste.
Planear o filtro de aplicações
Um bom filtro de aplicações não é apenas uma longa lista de bloqueios. Primeiro, deve estar claro o que se deseja alcançar.
- Bloquear ferramentas de controlo remoto arriscadas: Bloquear aplicações ou categorias específicas
- Restringir Wi-Fi de convidados: Bloquear categorias indesejadas, deixar serviços básicos permitidos
- Apenas registrar aplicação: Usar
Allowcom logging e relatórios inicialmente - Evitar falso positivo: Seleção mais restrita de aplicações em vez de categoria ampla
- Priorizar aplicação crítica para o negócio: Combinar Application Control com Traffic Shaping
Para redes produtivas, um modo de observação é frequentemente útil: ativar o Application Control primeiro, verificar logs e relatórios, depois bloquear de forma direcionada. Assim, é possível ver que aplicações aparecem realmente e se um bloqueio interromperia processos legítimos.
Em critérios amplos, também se deve considerar a manutenção posterior. Novas aplicações são automaticamente consideradas em Application Filter Policies e regras de firewall através de atualizações da base de dados de assinaturas de aplicações. Se uma regra bloquear, por exemplo, todas as aplicações High-Risk, uma nova assinatura High-Risk poderá ser bloqueada posteriormente sem mais alterações manuais à policy. Isto pode ser desejado, mas tem de ser conhecido no processo de change e revisão.
Planear rollout em fases
O Application Control não deve ser ativado de uma só vez para todas as redes. É melhor um rollout pequeno com um grupo de teste claro, logging visível e uma decisão definida de quando a observação se torna bloqueio.
Um procedimento prático:
- Inventário: Descobrir que aplicações aparecem realmente. Filtro de aplicações com logging, ainda sem bloqueio amplo
- Piloto: Verificar utilizadores selecionados ou uma rede de teste. Bloquear aplicações arriscadas específicas, controlar de perto ID da regra e logs
- Implementação: Aplicar política confirmada na rede alvo. Ativar filtro na regra produtiva, documentar exceções
- Operação: Monitorar efeitos e efeitos colaterais. Verificar regularmente relatórios, Log Viewer, Central Reporting ou Syslog
Antes da implementação, deve estar claro que aplicações devem permanecer permitidas. Isto geralmente inclui serviços de atualização, suporte remoto, ferramentas de colaboração, armazenamento cloud, telefonia ou aplicações específicas do setor. Se estas dependências só se tornarem visíveis após o bloqueio, o Application Control rapidamente parece um fator de perturbação em vez de uma função de proteção.
Para a aceitação, vale a pena uma lista de decisões curta: que aplicação será bloqueada, que grupo de utilizadores é afetado, que exceção é permitida, quem é o responsável técnico e quando a policy será revista? Esta documentação é mais importante do que um primeiro filtro perfeito.
Distinguir Application Filter, Application Object e Shaping
Os termos são próximos, mas resolvem tarefas diferentes. Esta distinção poupa muita resolução de problemas:
- Application Filter: define que aplicações são permitidas, bloqueadas ou registadas. Típico para ferramentas de controlo remoto, armazenamento cloud ou um modo de observação.
- Application Object: agrupa aplicações como objeto. Útil para grupos reutilizáveis quando a mesma seleção é necessária várias vezes.
- Application-based Traffic Shaping: prioriza ou limita aplicações reconhecidas. Típico para priorização de Teams, limitação de streaming ou throttling de Wi-Fi de convidados.
- Synchronized Application Control: complementa a deteção de aplicações com dados de sistemas Sophos Endpoint através do Security Heartbeat. Isto ajuda especialmente em programas que a firewall só reconheceria de forma genérica ou nem sequer reconheceria.
Para uma política simples de bloqueio ou allow, o Application Filter é o ponto de entrada mais importante. Application Objects e Traffic Shaping só se tornam relevantes quando a seleção de aplicações deve ser reutilizada ou a largura de banda deve ser controlada de forma específica.
Synchronized Application Control não substitui regras de firewall bem desenhadas. Requer Sophos Central, Security Heartbeat e cobertura adequada por Sophos Endpoint. Aplicações recém-detetadas aparecem em categorias próprias, como SyncAppCtl discovered, e não devem ser bloqueadas às cegas. Primeiro verificar, depois categorizar e só então incluir no Application Filter.
As aplicações detetadas recebem automaticamente uma etiqueta de estado: New para aplicações ainda desconhecidas, Mapped para aplicações atribuídas automaticamente a uma categoria e Customized para entradas ajustadas manualmente. A Sophos suporta o Synchronized Application Control para até 15.000 aplicações e guarda apenas as últimas cinco ocorrências por aplicação e endpoint para poupar espaço de armazenamento. Este limite é especialmente relevante quando é preciso reconstruir, para fins forenses, quantas vezes uma aplicação ocorreu num endpoint.
Criar filtro de aplicações
Caminho do menu:
Applications > Application filter
Em vistas de navegação mais antigas, o caminho pode aparecer como Protect > Applications > Application filter.
Procedimento:
- Abrir Add.
- Atribuir um nome descritivo, por exemplo,
Block_Remote_Control_Tools. - Escolher uma policy existente como template, por exemplo uma Allow-All-Policy como ponto de partida para regras de bloqueio específicas.
- Guardar a policy.
- Abrir novamente a policy e adicionar uma regra dentro do filtro.
- Selecionar aplicação, categoria, risco, Characteristics, Technology, Classification ou Smart Filter.
- Definir a ação, por exemplo
DenyouAllow. - Definir o Schedule, caso a regra só deva aplicar-se temporariamente.
- Guardar a regra e, em seguida, guardar a policy.
Ao lidar com categorias, deve-se ter cuidado. Uma categoria ampla pode afetar mais aplicações do que o esperado. Para testes iniciais, aplicações individuais ou grupos bem definidos são frequentemente melhores do que um grande bloco coletivo.
Ao adicionar uma regra, há duas formas típicas de trabalhar. Select All com filtros é adequado quando se pretende abranger um grupo inteiro, por exemplo Category File Transfer, Characteristics Transfer files e Technology Browser Based. Select Individual Application é melhor quando apenas aplicações individuais, como AnyDesk, TeamViewer ou um serviço cloud específico, devem ser afetadas. O Smart Filter procura pelo nome e pela descrição de uma aplicação; não substitui uma validação técnica da lista de resultados.
O filtro Classification aplica-se apenas a aplicações cloud. Se uma Cloud-App for reclassificada posteriormente, o Sophos Firewall também atualiza regras baseadas nessa Classification. Estas regras são práticas, mas mais dinâmicas do que uma lista fixa de aplicações individuais.
Exemplo: bloquear transferências de ficheiros baseadas no browser
Um bom primeiro exemplo é bloquear transferências de ficheiros baseadas no browser numa rede de convidados ou de clientes. Neste caso, não se bloqueia genericamente toda a categoria File Transfer; a seleção é limitada a transferências de ficheiros baseadas no browser.
Configuração no Application Filter:
- Abrir Applications > Application filter.
- Criar uma policy, por exemplo
Block_File_Transfer. - Escolher uma policy Allow adequada como modelo.
- Guardar a policy e abri-la novamente.
- Abrir Add para uma nova regra de filtro.
- Usar Select All e limitar a seleção com Category: File Transfer, Characteristics: Transfer files e Technology: Browser Based.
- Definir Action como
Deny. - Definir Schedule como
All the time, se não for necessária programação horária. - Guardar a regra de filtro e depois guardar a policy.
Este exemplo é deliberadamente mais restrito do que um bloqueio global de todas as aplicações de transferência de ficheiros. Em muitas empresas, serviços legítimos de cloud, atualização, backup ou colaboração seriam afetados. Antes da utilização produtiva, o filtro deve ser testado no Log Viewer com clientes reais.
Ativar na regra de firewall
O Application Control só tem efeito quando o filtro é selecionado numa regra de firewall.
Caminho do menu:
Protect > Rules and policies > Firewall rules
Procedimento:
- Abrir a regra de firewall pela qual o tráfego afetado realmente passa.
- Abrir a secção Other security features.
- Selecionar o filtro de aplicações em Identify and control applications (App control).
- Ativar Log firewall traffic, pelo menos para teste e aceitação.
- Guardar a regra.
- Testar com um cliente definido.
A ordem das regras é crucial. Se o tráfego já for processado por uma regra mais geral acima, ele não alcançará a regra com Application Control. Nesse caso, a configuração no WebAdmin parece correta, mas não tem efeito.
Quando é criada uma nova regra LAN-WAN, o NAT deve ser considerado separadamente. Os exemplos da Sophos usam frequentemente Create linked NAT rule com MASQ para acesso simples à Internet. Em regras produtivas existentes, não se deve criar novas regras NAT sem validação; deve verificar-se que regra SNAT/MASQ já se aplica a esse tráfego.
Para Application-Control-Policies baseadas em utilizadores ou grupos, a regra de firewall tem de fazer realmente match ao contexto do utilizador. Match known users e uma autenticação funcional são tão importantes como o próprio Application Filter. Sem contexto de utilizador, a policy aplica-se apenas a critérios de rede, zonas e serviços.
Em regras novas, deve escolher-se conscientemente entre IPv4 e IPv6. O Application Control é ativado na respetiva regra de firewall. Se um cliente seguir por IPv6 um caminho diferente do IPv4, o teste pode parecer correto apesar de parte do tráfego passar ao lado da regra esperada.
Os fundamentos sobre Source, Destination, Services, Security Features e ordem das regras estão em Entender e configurar regras de firewall do Sophos Firewall de forma segura.
Verificar conscientemente a correspondência da regra
Antes de guardar, a regra deve ser lida como um caso de teste:
- Source zone e Source network: O cliente de teste deve vir realmente por esta zona e por esta rede
- Destination zone e Destination network: Destinos amplos podem funcionar, mas são mais difíceis de rastrear
- Services: Para tráfego web, TCP 80/443 é frequentemente relevante; QUIC usa UDP 443
- Web policy, IPS e TLS Inspection: Várias Security Features podem influenciar o mesmo fluxo
- Log firewall traffic: Sem logging, o efeito é difícil de comprovar no Log Viewer
Quando o Application Control é introduzido pela primeira vez, a primeira regra deve ser preferencialmente um pouco mais estreita e fácil de medir. Uma regra LAN-to-WAN enorme com muitas exceções torna a aceitação claramente mais trabalhosa.
Inspeção TLS e reconhecimento
O Application Control pode reconhecer certas aplicações mesmo sem inspeção TLS completa. No entanto, para muitos serviços modernos de HTTPS e cloud, a firewall sem desencriptação vê apenas informações limitadas, como endereço IP, SNI, dados de certificado, nome do host ou metadados de ligação.
Isto nem sempre é suficiente para um reconhecimento fiável. Se uma aplicação não for reconhecida como esperado via HTTPS, deve verificar-se:
- O tráfego passa pela regra de firewall correta?
- O Application Control está ativo nessa regra?
- A aplicação é reconhecida fundamentalmente pela Sophos?
- A inspeção TLS é necessária e justificável para esse tráfego?
- Existem QUIC ou HTTP/3 que dificultam o controlo?
- Web Policy, IPS ou DNS Protection estão atuando adicionalmente?
A inspeção TLS deve ser introduzida gradualmente e com exceções. O procedimento adequado está em Introduzir corretamente a inspeção TLS no Sophos Firewall. Para QUIC e HTTP/3, consulte Bloquear corretamente o protocolo QUIC e HTTP/3 no Sophos Firewall.
Nas aplicações cloud, a diferença é particularmente visível: dados básicos de bytes e utilização exigem sobretudo que o firewall logging esteja ativo. Informações mais precisas de upload/download e tipo de ficheiro só são vistas de forma fiável quando o HTTPS é desencriptado. Algumas aplicações transferem ficheiros através de mecanismos próprios; nesses casos, campos de detalhe podem ficar vazios ou parecer incompletos apesar de existir tráfego.
Para Cloud-App-Reporting, recomenda-se por isso uma combinação de três pontos: ativar Log firewall traffic, desencriptar HTTPS onde for organizacional e tecnicamente aceitável, e usar uma Web Policy que não seja simplesmente None. Isto torna os dados de Application Control claramente mais úteis em operação.
Testar efeito
Após a ativação, não se deve apenas esperar pelo feedback dos utilizadores. Um teste bem feito poupa muito tempo.
Procedimento prático:
- Defina o cliente de teste e o IP de origem.
- Inicie a aplicação conscientemente ou aceda ao destino.
- No Log viewer, filtre por IP de origem, destino, serviço e aplicação.
- Verifique qual ID de regra de firewall foi atingida.
- Verifique se o Application Control reconhece a aplicação.
- Anotar Application ID, categoria, ação e Application Filter.
- Em caso de bloqueio, verificar se o bloqueio é tecnicamente pretendido.
- Em caso de deteção incerta, complementar com Packet Capture, logs de serviço e, em logging central, os campos de Syslog.
Os eventos de Application Control aparecem no Log Viewer como eventos de Application ou Content Filtering. Para a aceitação, são sobretudo relevantes Firewall Rule ID, utilizador, aplicação, categoria, risco, ação, origem e destino. Em avaliações Syslog ou SIEM, devem também ser verificados campos como fw_rule_id, application_name, application_filter_policy, application_category, application_risk, status e appresolvedby. Este último ajuda a perceber se a aplicação foi detetada, por exemplo, por assinatura, lógica proxy ou Synchronized Application Control.
O Application Control frequentemente usa ips.log no caminho técnico. A atribuição de logs está em Solução de problemas do Sophos Firewall: Serviços e Logs. Para delimitação com Log Viewer e Packet Capture, consulte Testar regra do Sophos Firewall com Log Viewer, Policy Test e Packet Capture.
Passar da observação para o bloqueio
A passagem da simples deteção para o bloqueio deve ser feita de forma consciente. Em muitos ambientes, é melhor usar primeiro o Application Control como ferramenta de observação e reporting. Depois, devem ser bloqueadas apenas as aplicações cujo risco, grupo de utilizadores e dependência de negócio estejam claros.
Antes de bloquear, deve verificar-se:
- Que utilizadores, redes ou dispositivos usam realmente a aplicação?
- Que regra de firewall e que Rule ID aparecem no Log Viewer?
- A aplicação é detetada de forma fiável ou apenas como categoria genérica?
- Existe utilização empresarial legítima, casos de suporte ou ferramentas do fabricante?
- A aplicação deve ser bloqueada em todos os locais ou apenas em redes de convidados, escolares, clientes ou servidores?
- Quem aprova uma exceção e quando será revista novamente?
Um fluxo prático limpo é: primeiro recolher dados de log, depois bloquear uma aplicação individual ou um pequeno grupo e, em seguida, validar com um cliente de teste e Log Viewer. Se um bloqueio for demasiado amplo, não se deve desativar todo o Application Filter, mas ajustar especificamente a aplicação, categoria ou posição da regra afetada.
Quando o Application Control não se aplica
Em caso de problemas, não se deve desativar imediatamente todo o filtro. Primeiro, deve-se verificar onde o processo falha.
- Nenhuma entrada de log para a ligação de teste: Falta logging ou o tráfego não chega à regra de firewall. Verificar Rule ID, zona de origem e Packet Capture
- Log Viewer mostra outra Rule ID: Uma regra mais geral está acima. Corrigir ordem das regras e critérios de correspondência
- A aplicação permanece
unknownou genérica: O reconhecimento não é suficiente sem mais contexto. Verificar TLS Inspection, QUIC e assinaturas de aplicações - O bloqueio afeta demasiados serviços: Categoria ou Smart Filter demasiado amplo. Usar aplicações individuais ou grupos menores
- Após uma Pattern Update, subitamente é bloqueado mais tráfego: Uma regra ampla baseada em Risk, Category ou Classification abrange novas assinaturas. Verificar critérios da regra e processo de change.
- Faltam detalhes de Cloud-App: Sem HTTPS-Decryption ou sem Web Policy, os detalhes de upload, download e tipo de ficheiro são limitados. Verificar Cloud-App-Reporting e estado TLS.
- O bloqueio só funciona em alguns clientes: Regra, zona, grupo de utilizadores ou caminho do browser diferente. Comparar cliente de teste, utilizador e caminho de rede
- IPv6 comporta-se de forma diferente do IPv4: Pode existir uma regra IPv6 separada, outro caminho DNS ou outro caminho do browser. Testar conscientemente ambos os protocolos ou considerar IPv6 corretamente no conjunto de regras.
O ponto de verificação mais importante é a Rule ID. Se a regra esperada não for atingida, a política de Application Control quase nunca é a verdadeira causa.
Tratar falsos positivos corretamente
Se o Application Control bloquear tráfego legítimo, não se deve desativar imediatamente todo o filtro.
Ordem sensata:
- Documente a aplicação afetada e a entrada de log.
- Verifique qual regra de firewall e qual filtro de aplicação estão envolvidos.
- Verifique aplicação, categoria e ação no filtro.
- Verifique se a aplicação é reconhecida de forma diferente pela inspeção TLS.
- Defina exceção o mais restrita possível: aplicação, rede de origem, grupo de utilizadores ou destino.
- Documente o responsável e a data de revisão para a exceção.
Uma exceção para Any ou uma categoria ampla resolve rapidamente o caso atual, mas enfraquece o controlo permanentemente. É melhor uma exceção pequena e justificável com uma razão clara.
Erros comuns
- Filtro de aplicação criado, mas não selecionado na regra: Sem efeito no tráfego. Ativar filtro na regra de firewall real
- Tráfego passa por outra regra: Filtro nunca é alcançado. Verificar ID da regra no Log Viewer
- Categoria muito ampla bloqueada: Serviços cloud ou empresariais legítimos afetados. Usar aplicações individuais ou grupos mais restritos
- Filtros dinâmicos mal compreendidos: Risk, Category ou Classification podem produzir novos acertos através de atualizações de assinaturas e Cloud Apps. Rever regularmente.
- Reconhecimento HTTPS sobrestimado: Aplicação não é reconhecida de forma fiável. Verificar inspeção TLS e comportamento QUIC
- Falta de logging: Efeito permanece invisível. Ativar logging de regra para teste e operação
- Exceção muito ampla: Função de proteção é praticamente anulada. Definir exceção restrita e com data de revisão
Verificação operacional
O Application Control deve ser verificado regularmente. As aplicações mudam, os serviços cloud usam novos endpoints, os utilizadores utilizam novas ferramentas e as assinaturas são atualizadas.
Deve-se documentar:
- Propósito do filtro de aplicações
- Regras de firewall afetadas
- Aplicações bloqueadas ou permitidas
- Exceções conhecidas
- Responsável técnico
- Data de revisão
- Última alteração relevante
Se o Application Control for usado para aplicações críticas de negócios, redes escolares ou requisitos de conformidade, o Central Reporting, Syslog ou SIEM também devem ser verificados. Para avaliação central, consulte Ativar Central Firewall Reporting ou Configurar Syslog e SIEM no Sophos Firewall.
Lista de verificação
- Estado da licença verificado.
- Regra de firewall afetada claramente identificada.
- Filtro de aplicações criado com propósito claro.
- Template, filtros dinâmicos e critérios da regra documentados.
- Filtro selecionado na regra de firewall correta.
- Logging de regra ativo.
- Cliente de teste e aplicação de teste definidos.
- Log Viewer verificado para ID de regra e Application Control.
- Utilização real, owner e regra de exceção clarificados antes do bloqueio.
- Percurso IPv4 e IPv6 verificado, se ambos estiverem ativos na rede.
- Inspeção TLS e QUIC avaliados, se o reconhecimento HTTPS for incerto.
- Cloud App Reporting verificado se necessário com HTTPS-Decryption e Web Policy.
- Exceções documentadas de forma restrita.
- Data de revisão definida.