Proteger o acesso ao Sophos Firewall com Device Access

Administration > Device access define a partir de que zonas os serviços locais de Sophos Firewall são acessíveis. Isto inclui, por exemplo, HTTPS para WebAdmin Console, SSH para CLI, Ping, DNS, User Portal, VPN Portal e outros serviços.

Para o contexto geral de hardening, consultar o hub Sophos Firewall Hardening: melhores práticas para uma configuração segura.

Esta área é crítica para a segurança. As regras normais de firewall controlam o tráfego através da firewall. Device access controla o tráfego para a própria firewall. Se WebAdmin ou SSH estiverem acessíveis a partir de uma zona insegura, surge acesso de gestão direto ao dispositivo de segurança.

Também é importante considerar a API: a autorização de Device Access para HTTPS/WebAdmin também afeta acessos API. Desde SFOS 22, as fontes de acesso API são mantidas adicionalmente em Administration > API access, mas um host API permitido não ajuda se Device Access bloquear o acesso HTTPS local a partir dessa zona.

⚠️ WebAdmin, SSH e portais só devem ser acessíveis em redes de confiança. Para ambientes de produção, o melhor é restringir o acesso a uma rede de gestão, um IP fixo de administrador, VPN ou Sophos Central Firewall Management.

Na prática, esta separação ajuda:

• Tabela de zonas de Device Access: Geralmente permite ou bloqueia um serviço por zona, por exemplo DNS para LAN, Ping para uma zona de monitorização ou SSL VPN para uma zona de Remote Access necessária.
• Local Service ACL Exception Rule: controlar o acesso com mais precisão por origem, destino e serviço, por exemplo WebAdmin apenas da rede de gestão, SSH apenas de um IP de suporte ou SNMP apenas do sistema de monitorização.
• Regra normal de firewall: Permitir ou bloquear tráfego através da firewall, por exemplo, quando um cliente em LAN acede a um servidor em DMZ ou um serviço de internet.

Isto deixa claro: uma regra de firewall não substitui o reforço de Device Access. Se HTTPS ou SSH estiverem demasiado acessíveis através de Device Access, um cliente chega ao serviço local da firewall antes de uma regra clássica de trânsito ser sequer o ponto de verificação adequado.

Por que Device Access não funciona como regra de firewall

Uma regra de firewall típica permite ou bloqueia ligações entre zonas, por exemplo, de LAN a WAN ou de VPN a Server. Device Access é diferente: são serviços que são executados diretamente no Sophos Firewall.

Exemplos:

• Um administrador abre https://172.16.16.16:4444.
• Um cliente usa a firewall como servidor DNS.
• Um sistema de monitorização faz ping na firewall.
• Um utilizador abre User Portal ou VPN Portal.
• Um administrador liga-se através de SSH à firewall.

Este tipo de tráfego não é destinado a um servidor atrás da firewall, mas sim à própria firewall. É por isso que é controlado através da ACL de serviço local.

É também por isso que Device Access faz parte do endurecimento de base de qualquer Sophos Firewall. Um conjunto de regras limpo de LAN a WAN não protege automaticamente os serviços de gestão e de portal da própria firewall. Estes serviços devem ser conscientemente revistos e restringidos separadamente.

Compreender as autorizações de zona

No topo de Administration > Device access é possível ver uma tabela com zonas e serviços. Se um serviço for ativado para uma zona, o acesso a esse serviço local será permitido a partir dessa zona.

A tabela de zonas é prática, mas geral e adequada para zonas internas claras, como LAN, Management ou VPN. Quando um serviço deve ser acessível apenas a endereços IP, locais, países ou alvos de suporte de administradores individuais, Local service ACL exception rules são a melhor opção.

Nas Zonas Personalizadas as configurações da zona também devem ser revistas. Os serviços locais também podem ser influenciados lá. Ainda assim, Administration > Device access continua sendo o local central onde os serviços locais da firewall são conscientemente ativados ou restritos.

Exemplos típicos:

• HTTPS: acesso a WebAdmin a partir da rede de gestão. Não permitir amplamente a partir de WAN.
• SSH: CLI acesso para administradores ou suporte. Permitir apenas especificamente, de preferência com Public Key.
• Ping/Ping6: monitorização e testes simples de acessibilidade. Não ative desnecessariamente em zonas inseguras.
• DNS: Os clientes usam a firewall como resolvedor DNS. Ativar apenas para zonas internas de clientes.
• SSL VPN: Os utilizadores do SSL VPN estabelecem uma ligação com a firewall. Abra externamente apenas o necessário e proteja com MFA; verifique a porta separadamente na área de Remote Access.
• User Portal: Os utilizadores transferem configurações ou tokens VPN. Externamente, preferencialmente via VPN/ZTNA ou com forte limitação.
• VPN Portal: Utilizadores de Remote Access-VPN. Apenas se for realmente necessário e protegido com MFA.
• RED: Os dispositivos RED ligam-se à firewall. Permitir apenas locais RED reais ou fontes definidas.
• SMTP Relay: Os sistemas internos utilizam a firewall como SMTP Relay. Não permita como um relé aberto em zonas inseguras.
• SNMP: a monitorização consulta valores da firewall. Permitir apenas a partir do sistema de monitorização; os detalhes estão em Monitorização de hardware SNMP.
• Dynamic Routing: protocolos de encaminhamento entre routers e firewall. Ativar apenas nos segmentos de rede previstos para isso.

Em SFOS 22, WebAdmin, VPN Portal e User Portal suportam TLS 1.3. Isto é bom para a encriptação, mas não altera o princípio básico: um serviço acessível a partir de demasiadas fontes continua a ser uma superfície de ataque desnecessária. A encriptação de transporte não substitui uma ACL limpa.

Quais serviços podem ser restringidos usando regras ACL?

Através de Local Service ACL e ACL Exception Rules, os serviços locais da firewall podem ser controlados com muita precisão. Esses serviços são especialmente relevantes:

• DNS: a firewall responde a consultas DNS de redes que não deveria atender.
• Dynamic Routing: protocolos de encaminhamento são acessíveis a partir de segmentos incorretos.
• HTTPS: WebAdmin Console está acessível a partir de muitas fontes.
• Ping/Ping6: a firewall está desnecessariamente visível e facilmente analisável.
• RED: Os serviços RED são acessíveis a partir de intervalos de origem muito amplos.
• SMTP Relay: Configurações incorretas podem incentivar o abuso do relé.
• SNMP: dados de monitorização podem ser consultados em redes incorretas.
• SSH: CLI o acesso direto à firewall está muito aberto.
• SSL VPN: Os pontos de login VPN são globalmente acessíveis e verificados.
• User Portal: O login e as transferências do portal e as transferências VPN são expostos desnecessariamente.
• VPN Portal: O portal de Remote Access é alvo de bots e tentativas de força bruta.

Quanto mais desses serviços forem acessíveis a partir de WAN, redes convidadas, redes IoT ou zonas mal definidas, maior será a superfície de ataque. O objetivo não é desativar tudo, mas sim tornar cada serviço acessível apenas onde for realmente necessário.

Definir as fontes de acesso o mais estritamente possível

Uma regra ACL não precisa simplesmente permitir Any. Como fonte, é possível trabalhar com muita precisão, por exemplo, com:

• endereços IP de administradores individuais
• redes de gestão
• intervalos de IP
• listas de IP
• hosts FQDN
• grupos de hosts FQDN
• Hosts DNS ou grupos DNS
• objetos de país ou grupos de países
• VPN ou redes de suporte dedicadas

Isto permite limitar o acesso de forma muito mais precisa. Um exemplo: se um serviço de suporte externo vier apenas de um FQDN fixo ou de um intervalo de IP definido, toda a zona WAN não deve ter acesso a HTTPS ou SSH. Se um sistema de monitorização precisar de SNMP, uma rede inteira de servidores não deve poder consultar SNMP na firewall.

Em cenários globais de Remote Access, a delimitação é mais difícil. Algumas empresas não conseguem permitir SSL VPN ou VPN Portal apenas para a Suíça, Alemanha ou um único país, porque os colaboradores viajam pelo mundo. Nestes casos, deve-se trabalhar adicionalmente com MFA, logging, definições de portal restritivas e Threat Feeds.

Modelo de decisão para serviços locais

Para cada serviço local, deve-se decidir conscientemente qual nível de acesso é apropriado. Raramente é sensato tratar WebAdmin, SSH, User Portal, VPN Portal, DNS e SNMP da mesma maneira.

• Desativado: Apropriado se o serviço não for necessário no ambiente. Exemplo: SSH desativado permanentemente caso não seja esperado acesso a CLI.
• Apenas zona interna: adequado se o serviço for necessário para muitos clientes internos. Exemplo: DNS de LAN, caso os clientes utilizem a firewall como resolvedor DNS.
• Rede de gestão: adequada para serviços administrativos ou de monitorização. Exemplo: HTTPS, SSH e SNMP apenas a partir de Management.
• Admin-VPN: adequado se os administradores precisarem trabalhar externamente, mas não diretamente da Internet. Exemplo: WebAdmin acessível apenas via VPN.
• ACL Exception Rule: adequado se o acesso precisar vir de uma fonte muito específica. Exemplo: Um IP de suporte pode aceder temporariamente HTTPS ou SSH.
• WAN amplamente acessível: apenas para serviços reais Remote Access e com proteção adicional. Exemplo: SSL VPN para utilizadores móveis com MFA, logging e Threat Feeds.

Esta decisão deve ser documentada. Principalmente no caso de exceções do WAN, deve ser possível rastrear posteriormente porque o serviço está acessível, quem precisa dele e quando a exceção será revista novamente.

O acesso a partir de WAN é uma exceção

WAN não é apenas mais uma zona. Tudo o que é acessível a partir de WAN é encontrado por scanners, bots e ferramentas de força bruta. Por isso, WebAdmin a partir de WAN não deve ser planeado como variante operacional normal.

Se for necessário acesso de gestão externo, estas variantes geralmente são mais seguras:

• Sophos Central Firewall Management para tarefas administrativas.
• Admin-VPN com MFA e um grupo de utilizadores claro.
• Uma regra de exceção temporária de ACL para um IP de origem fixa.
• Uma rede de gestão dedicada via VPN de site para site.

Para o quadro geral de proteção, Use corretamente Sophos Firewall Health Check também é adequado, uma vez que o acesso de gestão, MFA, backups e higiene de regras são avaliados juntos lá.

A Sophos protege adicionalmente o WebAdmin contra ativação para todas as fontes WAN. Se o acesso WAN for realmente necessário, deve ser limitado por fontes específicas, como IPs individuais, redes ou objetos FQDN. Autorizações antigas de configurações anteriores devem ser revistas regularmente: a Sophos pode desativar automaticamente certas autorizações WAN amplas para WebAdmin ou User Portal após um longo período de inatividade, enquanto exceções ACL direcionadas a fontes WAN específicas podem continuar a aplicar-se.

ACL Exception Rule de serviço local

Se um serviço não deve ficar acessível para uma zona inteira, usa-se uma Local service ACL exception rule. Isto permite definir com muita precisão quem pode aceder a qual serviço local.

Caminho:

1. Abra Administração.
2. Selecione Device access.
3. Role até Local service ACL exception rule.
4. Clique em Adicionar.

Procedimento típico para uma exceção de administração estreita a partir de WAN:

1. Definir Rule name, por exemplo admin-https-from-support-ip.
2. Definir Rule position como Top, se uma regra Drop ou Allow existente puder aplicar-se antes.
3. Selecionar a IP version adequada à fonte, normalmente IPv4.
4. Definir Source zone como WAN.
5. Definir Source Network / Host como o IP concreto de administração, uma pequena rede de administração ou um objeto FQDN/IP mantido.
6. Limitar Destination host ao endereço ou interface da firewall afetado, se nem todos os destinos locais forem pretendidos conscientemente.
7. Definir Services para o serviço local necessário, por exemplo HTTPS para WebAdmin ou API, não HTTPS e SSH ao mesmo tempo por conveniência.
8. Definir Action como Accept.
9. Guardar e testar imediatamente a partir de uma fonte permitida e de uma fonte não permitida.

Uma ACL Exception Rule consiste essencialmente nestes campos:

• Rule name: nome único, por exemplo admin-https-from-mgmt.
• Rule position: ordem das regras ACL.
• Source zone: zona de onde vem o acesso, por exemplo WAN, LAN ou VPN.
• Source Network / Host: IP de administrador permitido, rede de gestão, Host FQDN ou lista de IP.
• Destination host: IP da firewall ou interface que está a ser acedida.
• Services: serviço local, por exemplo HTTPS, SSH, Ping ou DNS.
• Action: Accept ou Drop.

Para aceder ao WebAdmin pela Internet, Any nunca deve ser usado como fonte. A Sophos impede conscientemente o acesso ao WebAdmin a partir da zona WAN para todas as fontes, porque isso seria um risco elevado. Se o acesso WAN for realmente necessário, deve ser permitido apenas através de endereços IP de origem específicos, redes definidas, objetos FQDN ou outras fontes restritas.

A mesma lógica aplica-se à automação API. Um host pode estar permitido em Administration > API access e ainda assim falhar se faltar a autorização HTTPS em Device Access. Por outro lado, uma autorização HTTPS não deve tornar-se mais ampla apenas porque uma ferramenta API é ligada. Para detalhes da API, consulte limitar de forma segura o acesso API ao Sophos Firewall.

A ordem também é importante. As ACL Exception Rules são avaliadas de cima para baixo. Uma regra Drop superior pode tornar uma regra Accept posterior ineficaz. Por outro lado, uma regra Accept demasiado ampla pode anular restrições planeadas posteriormente. Por isso, a ordem das regras deve ser revista com a mesma atenção que nas regras de firewall.

O Destination host é especialmente importante quando a firewall tem várias interfaces, endereços alias, endereços VPN ou destinos de portal/gestão separados. Uma regra deve apontar com a maior precisão possível para o endereço da firewall que realmente será gerido ou usado. Caso contrário, uma autorização de origem aparentemente limitada poderá afetar subitamente mais serviços ou interfaces locais do que o pretendido.

Evitar Lockout antes da alteração

Alterações em Device Access afetam diretamente os acessos de gestão e de portal. Por isso, antes de qualquer restrição, deve ficar claro como voltar a aceder à firewall se uma regra for aplicada incorretamente.

Antes de guardar uma alteração arriscada, deve verificar:

• Está disponível um segundo administrador com um perfil de direitos apropriado?
• Existe acesso através de outra rede, como Management-LAN, Admin-VPN ou Sophos Central?
• Existe acessibilidade local à consola ou fora de banda, caso WebAdmin não esteja mais acessível?
• Está a trabalhar num cluster HA em que uma alteração de função pode alterar o caminho de acesso?
• O ficheiro de backup atual, a chave mestra de armazenamento seguro e o acesso de emergência estão documentados?
• Existe uma breve janela de manutenção em que acessos incorretos possam ser detetados imediatamente?

Especialmente em locais remotos, não se deve primeiro remover o acesso amplo e depois testar. O processo inverso é mais seguro: crie uma nova ACL Exception Rule estreita, teste o acesso permitido, confirme o segundo caminho do administrador e só então reduza a antiga autorização de zona ampla.

Implementar alterações com segurança

Alterações em Device Access podem bloquear administradores. Por isso, não devem ser feitas casualmente, mas tratadas como uma alteração de gestão.

Processo testado:

1. Documentar o acesso atual: WebAdmin, SSH, User Portal, VPN Portal, SSL VPN, DNS, SNMP e Ping.
2. Garantir que existe um segundo caminho de administração, por exemplo consola local, Admin-VPN ou Sophos Central.
3. Criar um backup antes de implementar alterações ACL maiores.
4. Criar uma nova ACL Exception Rule tão específica quanto possível.
5. Testar o acesso a partir da fonte permitida.
6. Testar o acesso a partir de uma fonte não permitida.
7. Verificar no Log Viewer se os eventos esperados estão visíveis.
8. Remover a antiga autorização de zona ampla apenas quando o novo acesso estiver confirmado.
9. Documentar a alteração com data, fonte, serviço e responsável.

Se várias firewalls ou clusters HA forem afetados, a alteração deve ser testada primeiro num sistema com boa possibilidade de reversão. Para ambientes HA, Configurar Alta Disponibilidade Sophos Firewall também é adequado, pois os acessos de gestão, alterações de função e janelas de manutenção devem ser considerados em conjunto.

Revisão após alterações em Device Access

Após um ajuste, não basta verificar apenas o seu próprio acesso ao WebAdmin. Tanto as fontes permitidas quanto as não permitidas devem ser testadas, caso contrário não ficará claro se o endurecimento realmente funciona.

• WebAdmin da rede de gestão: O acesso funciona conforme planeado.
• WebAdmin de uma rede cliente normal: O acesso é bloqueado se não for explicitamente permitido.
• SSH da rede de gestão: O acesso só funciona se SSH for permitido conscientemente.
• SSH de WAN ou rede convidada: o acesso está bloqueado.
• DNS da rede cliente: DNS funciona apenas em redes que devem utilizar a firewall como resolvedor.
• User Portal ou VPN Portal: apenas os portais necessários são acessíveis.
• SNMP do sistema de monitorização: a monitorização funciona, outras fontes estão bloqueadas.

Se um acesso funcionar de forma inesperada, não apenas a ACL Exception Rule deve ser revista. Além disso, a tabela de zonas na parte superior de Device Access, a configuração de zona personalizada, a zona VPN, o comportamento do proxy e as regras amplas Accept existentes podem ser a causa.

Uma pequena lista por serviço geralmente é suficiente para a documentação:

• HTTPS: fonte permitida mgmt-net, motivo Acesso de administrador ao WebAdmin, revisão trimestral.
• SSH: fonte permitida support-ip-temporary, motivo Caso de suporte, revisão após fecho do ticket.
• SNMP: fonte permitida monitoring-server, motivo Monitoring de hardware e interfaces, revisão semestral.
• SSL VPN: fonte permitida WAN, motivo Remote Access, revisão com verificação de log mensal.

Em cada revisão subsequente deve também ser verificado se os acessos permitidos e bloqueados estão visíveis. Para testes curtos, Log Viewer geralmente é suficiente. Para retenção mais longa ou questões de auditoria, Central Reporting ou Syslog são mais adequados, porque os logs locais rodam ou podem perder-se em incidentes.

Configuração básica recomendada

Para muitos ambientes de produção, a seguinte lógica faz sentido:

• Permitir HTTPS/WebAdmin apenas de Management, Admin-VPN ou IP de administrador fixo.
• Permitir API apenas a partir de hosts definidos de automação ou monitorização e limitar adicionalmente HTTPS de forma adequada através de Device Access.
• SSH desativado por predefinição e apenas permitido especificamente via ACL quando necessário.
• Ativar DNS apenas em zonas onde os clientes realmente usam a firewall como servidor DNS.
• Permitir Ping para sistemas de monitorização interno, mas geralmente não de WAN.
• Ativar User Portal, VPN Portal e SSL VPN apenas se forem necessários.
• Permitir RED apenas para locais ou áreas de origem onde realmente existam dispositivos RED.
• Permitir SNMP apenas para o sistema de monitorização.
• Permitir SMTP Relay apenas para sistemas internos definidos.
• Ativar Dynamic Routing apenas em segmentos de encaminhamento onde protocolos de encaminhamento dinâmico são realmente usados.
• Revisão MFA para WebAdmin, VPN Portal e Remote Access; a configuração está em Ativar MFA para Sophos Firewall WebAdmin, VPN Portal e Remote Access.
• Use Sophos Central Firewall Management se for necessário acesso de gestão externo seguro.

Para uma rastreabilidade mais longa, a estratégia de registo também deve ser revista. Os logs locais são suficientes para encontrar falhas agudas, mas não para todas as questões de auditoria ou resposta a incidentes. Se os acessos ao portal ou à gestão devem ser rastreáveis a longo prazo, Central Firewall Reporting ou Enviar Sophos Firewall Syslog para SIEM são os componentes mais adequados.

Trate SSH com cuidado especial

SSH é muito útil para resolução de problemas e suporte, mas não deve ser permanentemente aberto de forma ampla. Para SSH aplica-se o seguinte:

• Apenas o utilizador admin pode efetuar login através de SSH.
• A autenticação de chave pública é o método preferido.
• O acesso a partir de WAN deve ser apenas através de endereços IP fixos ou de origem VPN.
• Após concluir uma análise, deve verificar se SSH ainda é necessário.

Mais detalhes estão no guia Conectar Sophos Firewall por SSH.

Bots, força bruta e Threat Feeds

Na prática, muitas vezes observa-se que serviços demasiado abertos são imediatamente encontrados por bots. Os mais afetados são WebAdmin, User Portal, VPN Portal e SSL VPN. Mesmo que um serviço esteja protegido por palavra-passe e MFA, logins públicos geram tentativas de ataque, tráfego de força bruta, ruído nos logs e carga desnecessária na firewall.

Isto não significa automaticamente que esteja a ocorrer um ataque bem-sucedido. No entanto, mostra que o serviço faz parte da superfície de ataque pública. Quanto menos fontes chegarem ao login, melhor.

Se um portal tiver de estar acessível globalmente, filtros por país ou endereços IP de origem individuais muitas vezes não são suficientes. Nesses ambientes, recomendamos ainda Third-Party Threat Feeds. Os Threat Feeds fornecem à firewall Indicators of Compromise continuamente atualizados, como endereços IP, domínios ou URLs maliciosos. Scanners, botnets e atacantes conhecidos podem ser bloqueados antes de chegarem a WebAdmin, VPN Portal, SSL VPN ou outros serviços publicados.

Artigo próprio Sophos Firewall Threat Feeds explica o planeamento, lista de permissões e operação.

Erros comuns

Uma regra de firewall foi revista em vez de Device Access

Se WebAdmin, SSH, DNS ou Ping não estiverem acessíveis na firewall, uma regra de firewall normal não ajuda. O tráfego não passa pela firewall, mas termina na própria firewall. Portanto, Administration > Device access deve ser revisto.

WebAdmin permitido em muitas zonas

WebAdmin não deve ser acessível a partir de cada zona interna. Uma rede convidada, IoT ou VoIP normalmente não precisa de acesso de gestão de firewall. Mesmo internamente, deve-se presumir que pode haver clientes comprometidos. Uma rede de gestão separada ou Admin-VPN reduz significativamente esse risco.

DNS não ativado para zona cliente

Se os clientes precisarem usar a firewall como servidor DNS, DNS deve ser permitido para a zona apropriada. Caso contrário, os clientes alcançam o IP da firewall, mas não recebem uma resposta DNS. Por outro lado, DNS não deve ser permitido em zonas onde a firewall não é usado como um resolvedor DNS.

Confusão entre User Portal e VPN Portal

User Portal e VPN Portal são serviços diferentes. Dependendo do conceito de Remote Access, deve-se verificar qual portal é realmente necessário. Muitas vezes um portal é ativado porque um utilizador precisou de transferir uma configuração uma vez, mas depois permanece aberto durante anos. Estes resíduos legados devem ser removidos regularmente.

Se os portais devem permanecer acessíveis pela Internet, marcar a caixa não é suficiente. MFA, grupos de utilizadores, processo de token/provisionamento, expiração de utilizadores temporários, registo e a questão de saber se o portal ainda é necessário permanentemente após a implantação são importantes.

O caso especial de Web Proxy foi ignorado

Se Web Proxy for utilizado, os pedidos HTTP e HTTPS podem parecer internos da perspetiva do proxy. Isto pode afetar o modo como o acesso a WebAdmin, Captive Portal, VPN Portal ou User Portal é controlado. Em ambientes proxy, deve testar-se com especial cuidado que acessos são realmente possíveis.

Regra ACL formulada de forma muito ampla

Uma ACL Exception Rule com Source zone: Any, Source Network / Host: Any e Services: HTTPS, SSH quase nunca é uma boa ideia. Tais regras contornam o verdadeiro benefício de segurança da exceção ACL. Uma regra pequena e clara, com uma fonte inequívoca e apenas os serviços necessários, é melhor.

Soltar regra na posição errada

Se uma regra Descartar estiver acima de uma regra Aceitar, o acesso permitido poderá ser bloqueado de qualquer maneira. Nas ACL Exception Rules, a ordem é tão importante quanto nas regras de firewall.

Pelo contrário, uma regra Accept ampla no início da lista pode tornar as regras Drop subsequentes praticamente inúteis. Após cada alteração de regra, deve ser revista não só a nova regra, mas também a lógica de correspondência das regras superiores.

SSL VPN e VPN Portal deixados muito abertos

O Remote Access muitas vezes deve ser acessível a partir do exterior. Contudo, deve verificar-se se todos os países, redes e grupos de utilizadores realmente necessitam de acesso. Se uma limitação estreita da fonte não for possível, MFA, logging e Threat Feeds devem ser usados de forma ainda mais consistente.

Resolução de problemas

Se um serviço local não estiver acessível, esta é a sequência que ajuda:

1. O IP de destino da firewall está correto?
2. O cliente vem da área esperada?
3. O serviço é permitido em Administration > Device access para esta zona?
4. Existe uma ACL Exception Rule de serviço local apropriada?
5. Talvez uma regra de ACL superior seja aplicada com Drop?
6. O serviço está configurado em outra porta?
7. O acesso via VPN, proxy ou NAT parece diferente do esperado?
8. Log Viewer apresenta alguma indicação?
9. Packet Capture consegue ver a tentativa de ligação na interface?

Para acessos de suporte, pode ser útil criar uma ACL Exception Rule específica e eliminá-la ou desativá-la após a conclusão do suporte.

Lista de verificação operacional

• WebAdmin não amplamente acessível a partir de WAN.
• SSH permitido apenas temporariamente ou de redes de gestão/administração.
• DNS ativo apenas para zonas clientes que realmente usam a firewall como resolvedor.
• SNMP permitido apenas a partir do sistema de monitorização ou rede de monitorização.
• User Portal, VPN Portal e SSL VPN ativos apenas se forem necessários no conceito de Remote Access.
• MFA revisto para WebAdmin, VPN Portal e Remote Access.
• ACL Exception Rules nomeadas com origem, serviço e propósito claros.
• Regras de suporte temporário documentadas com data de expiração.
• Acesso testado de fontes permitidas e não permitidas.
• Registos revistos, Central Reporting ou Syslog para acesso e gestão relevantes do portal.
• Revisão trimestral planeada para WebAdmin, SSH, SNMP, User Portal, VPN Portal e SSL VPN.

Perguntas frequentes