Utilizar corretamente IP hosts, serviços e grupos na Sophos Firewall

Os IP hosts e serviços atribuem nomes compreensíveis a endereços, redes e portas. Assim, uma regra de firewall mostra diretamente que origem pode comunicar com que destino e serviço.

A decisão importante é o âmbito adequado: um único endereço é criado como IP, uma sub-rede como Network, um intervalo contínuo de endereços como IP range e um pequeno conjunto de endereços individuais como IP list. Em TCP e UDP, um serviço descreve normalmente o Destination Port fixo; o Source Port dinâmico permanece inalterado.

Para uma nova regra, o caminho mais curto e seguro começa no menor objeto de host adequado, passa por um serviço existente ou personalizado e termina numa regra de firewall estritamente limitada. Só depois devem ser considerados casos especiais, como System Hosts, MAC Hosts e grupos reutilizáveis. Antes de qualquer alteração posterior, Object Usage mostra que regras e políticas dependem do objeto.

Escolher o objeto de host adequado

Em Hosts and services > IP host estão disponíveis quatro tipos:

IP: exatamente um endereço IPv4 ou IPv6, por exemplo um servidor, uma impressora ou um sistema de administração.
Network: uma sub-rede completa com a respetiva máscara, por exemplo 198.51.100.0/24.
IP range: um intervalo contínuo, por exemplo de 203.0.113.10 a 203.0.113.20.
IP list: vários endereços individuais não contíguos. Uma lista suporta no máximo 800 endereços IP e não pode pertencer a um IP Host Group. A ajuda atual do SFOS 22 contém a frase «For IP list, use only class B IP addresses.» Como a Sophos não esclarece esta formulação obsoleta baseada em classes de rede, não se deve concluir que são suportadas listas IPv4 ou IPv6 arbitrárias.

Um FQDN Host é mais adequado quando o endereço de destino muda e existe um nome DNS estável. A resolução, os carateres universais e os limites são explicados em Utilizar corretamente FQDN Hosts e Wildcard FQDNs.

Como regra geral, deve ser utilizado o menor objeto estável que descreva completamente o tráfego necessário. Um objeto do tipo IP abrange apenas um endereço e é demasiado restrito para uma sub-rede completa; uma rede /24 seria desnecessariamente abrangente para um único servidor.

Criar um IP host passo a passo

O exemplo seguinte representa um único servidor de teste:

Abrir Hosts and services > IP host e selecionar Add.
Introduzir host_test_web como Name.
Definir IP version como IPv4.
Selecionar IP como Type.
Introduzir 192.0.2.10 em IP address.
Guardar com Save.

Os endereços seguintes das redes 192.0.2.0/24, 198.51.100.0/24 e 203.0.113.0/24 estão reservados para exemplos de documentação. Numa configuração de produção, todos os nomes, endereços e tamanhos de rede devem ser substituídos pelos valores da rede real.

Network, range e IP list

Os campos mudam consoante o tipo selecionado:

Network: net_test_branch com 198.51.100.0 e /24 representa toda a rede de teste. Deve ser introduzido o endereço de rede, não o endereço do gateway.
IP range: range_test_admins de 203.0.113.10 a 203.0.113.20 representa um conjunto contínuo.
IP list: em list_test_hosts, introduzir apenas endereços do próprio ambiente verificado, separados por vírgulas. Devido à ambiguidade da indicação sobre a classe B na ajuda atual, a lista concreta deve ser criada na versão do SFOS utilizada e validada com uma regra de teste. A lista é adequada para alguns endereços individuais fixos, não para indicadores de compromisso que mudam continuamente.

Para endereços IP, domínios ou URLs maliciosos mantidos dinamicamente, a função mais adequada são os Threat Feeds na Sophos Firewall. Uma IP list manual não é atualizada automaticamente.

IP Host Groups

Em Hosts and services > IP host group, podem ser agrupados hosts com a mesma finalidade funcional. Um grupo pode, por exemplo, conter todos os sistemas de administração permitidos e ser depois utilizado em várias regras.

Aplicam-se três limites importantes:

Hosts IPv4 e IPv6 não podem estar no mesmo IP Host Group.
Um host normal pode pertencer a vários grupos.
Um objeto do tipo IP list não pode ser adicionado a um IP Host Group.

Os grupos devem ter um significado comum. Um grupo que reúna servidores, clientes e exceções temporárias pode poupar cliques, mas mais tarde dificulta a compreensão do motivo pelo qual uma regra permite o acesso.

Compreender os hosts de sistema e de interface

O SFOS cria automaticamente vários objetos de host. Estes objetos não devem ser recriados como Custom Hosts normais nem alterados no local errado:

Os Interface Hosts seguem a configuração IP em Network > Interfaces e são alterados nessa página. Zonas e interfaces na Sophos Firewall explica a relação entre ligação, zona e regra.
Se o desenho do fornecedor e da rede exigir que um endereço adicional seja associado localmente a uma interface física, este deve ser configurado como IP alias à interface física. Se um campo NAT não disponibilizar o respetivo Interface Host, deve criar-se também um Custom IP Host com esse endereço e um nome claro. Usar o mesmo nome é apenas uma convenção útil, não um requisito técnico.
##WWAN1 é mantido dinamicamente para a interface Cellular WAN.
##ALL_SSLVPN_RW, ##ALL_SSLVPN_RW6, ##ALL_IPSEC_RW e ##ALL_RW representam hosts dinâmicos de Remote Access.
Outros System Hosts não podem ser alterados ou eliminados como objetos próprios.

Os hosts dinâmicos de Remote Access não podem ser adicionados a outro IP Host Group. Os Physical Interface Hosts não estão disponíveis em determinados campos NAT, incluindo Translated source e Translated destination. Nesse caso, pode ser necessário um IP host separado com o mesmo endereço. O nome deve mostrar claramente a relação com a interface para que não pareça um endereço independente.

Para hosts internos na sub-rede do alias, o SFOS tem de ser o gateway predefinido. Se um equipamento a montante usar a firewall como gateway, necessita de um endereço IP de cada sub-rede de alias afetada. Após a substituição de uma firewall, entradas ARP obsoletas nos equipamentos a montante podem deixar o IP alias temporariamente inacessível. Nesse caso, deve verificar-se e atualizar-se primeiro a respetiva cache ARP, em vez de alargar desnecessariamente a regra NAT.

Para rotas SD-WAN de saída para a internet, a Sophos também recomenda usar Internet IPv4 group ou os hosts predefinidos incluídos como destino em vez de Any. Assim, a rota fica limitada a destinos IPv4 públicos e não conduz tráfego interno pelo mesmo caminho apenas porque o objeto de destino é demasiado abrangente.

Utilizar MAC hosts para dispositivos visíveis diretamente

Um MAC host descreve um dispositivo na camada 2 e pode conter um único endereço ou uma lista. Só é adequado quando a firewall vê o verdadeiro endereço MAC de origem. Atrás de um router, VPN ou NAT, normalmente vê o MAC do próximo salto e não o do cliente original. Por isso, um IP host ou uma rede costuma ser o objeto mais estável para regras encaminhadas.

Em Hosts and services > MAC host > Add, atribui-se ao objeto um nome descritivo e escolhe-se MAC address ou MAC list. O endereço pode usar dois pontos, como 00:16:76:49:33:CE, ou hífenes, como 00-16-76-49-33-CE; várias entradas são separadas por vírgulas. Uma MAC list suporta no máximo 1 000 endereços MAC.

Um MAC host não é uma identidade de dispositivo. Um endereço MAC pode ser copiado ou falsificado e pode mudar com estações de ancoragem, máquinas virtuais ou endereços Wi-Fi privados. O objeto é adequado como critério de correspondência restrito num segmento controlado, mas não como única autenticação ou limite de segurança.

Criar um serviço com o Destination Port correto

Antes de criar um novo serviço, deve verificar-se se já existe um serviço padrão adequado. Um Custom Service é útil quando uma aplicação necessita de outra porta ou de uma combinação especial de protocolos.

O exemplo seguinte cria o serviço TCP para iPerf3:

Abrir Hosts and services > Services e selecionar Add.
Introduzir svc_iperf3_tcp como Name.
Definir Type como TCP/UDP e Protocol como TCP.
Manter inalterado o Source Port predefinido 1:65535.
Introduzir 5201 como Destination Port.
Guardar com Save.

O cliente escolhe normalmente o Source Port de forma dinâmica. Se o serviço também o limitasse a 5201, uma ligação normal deixaria de corresponder. A porta fixa do servidor deve, por isso, ser introduzida em Destination Port. Um Source Port restrito só está correto quando o protocolo o exige expressamente e o tráfego real confirma esse comportamento.

Para um teste UDP do iPerf3, também é criado svc_iperf3_udp com protocolo UDP e Destination Port 5201. Como o iPerf3 continua a utilizar uma ligação de controlo TCP durante o teste UDP, ambos os serviços são agrupados:

Abrir Hosts and services > Service group e selecionar Add.
Introduzir grp_iperf3 como Name.
Selecionar svc_iperf3_tcp e svc_iperf3_udp.
Guardar com Save.

O procedimento completo de medição está descrito em Speedtest iPerf3 através da Sophos Firewall.

Um Service Group pode combinar serviços predefinidos e personalizados, e um serviço pode pertencer a vários grupos. Services e Service Groups não distinguem entre IPv4 e IPv6; a versão IP é determinada pelos objetos de host e pelo contexto da regra. Os Service Groups predefinidos não podem ser alterados nem eliminados, pelo que uma combinação própria requer um novo grupo.

Também não é possível alterar ou eliminar serviços predefinidos nem serviços já utilizados em Security Policies. Em vez de contornar uma dependência, deve criar-se o Custom Service necessário, substituir de forma controlada o objeto anterior nas políticas dependentes e verificar depois a indicação Usage atualizada.

IP, ICMP e ICMPv6

Além de TCP e UDP, um Custom Service pode descrever um número de protocolo IP ou tipos e códigos ICMP/ICMPv6. Estes tipos destinam-se a protocolos que não utilizam uma porta TCP ou UDP. Os valores devem provir da documentação técnica da aplicação e não ser deduzidos a partir de um único teste falhado.

Utilizar objetos numa regra de firewall

Um objeto de host ou serviço não permite tráfego por si só. Só produz efeito quando é utilizado como critério de correspondência numa regra. Um exemplo restritivo poderia ser:

Source zones: LAN
Source networks and devices: net_test_branch
Destination zones: DMZ
Destination networks: host_test_web
Services: HTTPS
Log firewall traffic: ativado

As zonas, os endereços e o serviço são adaptados à rede real. O tráfego de resposta de uma ligação com estado permitida é devolvido automaticamente. No entanto, esta regra não permite novas ligações independentes da DMZ para a LAN. Uma regra NAT, por si só, também não concede autorização; continua a ser necessária uma regra de firewall adequada.

O SFOS verifica as regras de firewall de cima para baixo e termina a procura na primeira correspondência. Por isso, a nova regra específica deve ficar acima de uma regra mais abrangente que, caso contrário, processaria primeiro o mesmo fluxo. Compreender e configurar regras da Sophos Firewall em segurança explica a ordem, as funções de proteção e os testes.

Depois de guardar, deve verificar-se uma tentativa de ligação real no Log Viewer. Os filtros pelo endereço de teste, porta e regra permitem isolar o fluxo correto; na vista detalhada, devem verificar-se Rule ID, Source, Destination e Service. Assim, é possível distinguir um objeto mal definido de tráfego processado por outra regra. Se uma ligação for interrompida sem que a firewall reconheça um evento Destroy, a entrada final da sessão pode não aparecer; Packet Capture e Live Connections permitem então uma verificação mais fiável.

Atualizar Object Usage antes de alterações

Um objeto pode ser utilizado em regras de firewall e NAT, VPN, rotas SD-WAN ou outras configurações. Antes de o alterar ou eliminar, devem ser verificadas as respetivas dependências.

A coluna Usage na lista de objetos mostra o número conhecido de referências. Este contador só é atualizado automaticamente uma vez por dia. Antes de uma alteração:

Selecionar Refresh junto a Usage.
Abrir o contador atualizado do objeto afetado.
Expandir as categorias e verificar cada regra ou política dependente.
Só depois decidir se o objeto pode ser alterado, substituído ou eliminado.

Nem todas as dependências podem ser alteradas diretamente na vista Usage. Algumas, incluindo WAN gateways e configurações CLI, têm de ser abertas separadamente no local de configuração indicado. Um contador igual a zero só é uma base fiável depois de um Refresh manual.

Gerir os objetos em segurança

Evitar erros comuns

Host em vez de Network: Um endereço IP individual não abrange automaticamente a sub-rede associada.
Endereço de rede ou máscara incorretos: Num objeto Network, o endereço de rede e o prefixo têm de corresponder à segmentação real.
Source Port restrito: Em ligações cliente-servidor normais mantém-se 1:65535; limita-se o Destination Port.
Demasiado Any: Um objeto de host preciso perde o seu valor de segurança se a origem ou o serviço continuarem desnecessariamente abrangentes.
Objeto de sistema duplicado: O SFOS mantém os hosts de interface e Remote Access, pelo que não devem ser copiados sem um motivo concreto.
IP list como Threat Feed: Uma IP list permanece estática e não substitui indicadores de ameaças atualizados automaticamente.
Dependências não atualizadas: Antes de alterar ou eliminar um objeto, selecionar sempre Refresh em Object Usage.

Prefixos descritivos como host_, net_, range_, svc_ e grp_ não são um requisito técnico, mas facilitam a pesquisa e a revisão. Mais importante do que o esquema específico é utilizar de forma consistente os nomes, as finalidades e os âmbitos em todo o conjunto de regras.

Manter um inventário reduzido e compreensível

O SFOS suporta até 16 000 hosts no conjunto de todos os tipos. Trata-se de um limite da plataforma, não de um objetivo de planeamento. Para a operação diária, uma base de objetos reduzida e compreensível é mais valiosa do que muitas entradas difíceis de distinguir. Os objetos que já não são necessários devem ser substituídos ou removidos de forma controlada, apenas depois de atualizar e verificar o respetivo Usage.