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.

Além dos Custom IP Hosts, também podem pertencer a um grupo os hosts predefinidos das interfaces, do Cellular WAN e da internet. A pertença a um grupo é independente da possibilidade de editar o objeto: um host de sistema que não pode ser editado diretamente não fica automaticamente excluído dos grupos. No entanto, os hosts de sistema dinâmicos de VPN Remote Access continuam excluídos.

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.

Para criar um pequeno grupo de teste IPv4 com o host_test_web criado anteriormente:

Abrir Hosts and services > IP host group e selecionar Add.
Introduzir grp_test_servers como Name; adaptar o nome à finalidade do grupo.
Definir IP version como IPv4, de acordo com o host de teste existente.
Selecionar host_test_web através de Add new item. Os membros adicionais devem partilhar a mesma finalidade e a mesma versão IP.
Guardar com Save.

Depois, reabrir o grupo e verificar a sua versão IP e os membros. Se um host pretendido não aparecer na seleção, verificar primeiro a respetiva versão IP e o tipo; não contornar a exclusão de uma IP list ou de um host de sistema VPN Remote Access com um objeto substituto desnecessariamente abrangente.

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

A lista de IP hosts mostra as interfaces físicas, incluindo módulos FleXi-Port adicionais, bem como as interfaces virtuais criadas pelo utilizador. Em Address details, são apresentados o endereço e a máscara de rede de Network > Interfaces. Se um valor for inesperado, comparar primeiro esta configuração da interface com os dados apresentados; o objeto de host mantido automaticamente não é o local para alterar um endereço.

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 é criado quando se ativa o Cellular WAN, utiliza o endereço IP da interface WWAN e é mantido dinamicamente.
##ALL_SSLVPN_RW, ##ALL_SSLVPN_RW6, ##ALL_IPSEC_RW e ##ALL_RW representam hosts dinâmicos de Remote Access.
##ALL_SSLVPN_RW contém os endereços IP atribuídos pela firewall às ligações VPN SSL de acesso remoto estabelecidas com Sophos Connect. ##ALL_IPSEC_RW contém os endereços atribuídos às ligações IPsec correspondentes. ##ALL_RW reúne os endereços atribuídos aos dois tipos de ligação; o SFOS adiciona-os dinamicamente quando as ligações são estabelecidas.
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 funcionar como gateway para o tráfego da Sophos Firewall, 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.

Ao contrário dos hosts de sistema não editáveis, os hosts de internet predefinidos podem ser alterados e eliminados. Antes de o fazer, atualizar Object Usage como descrito abaixo e verificar as regras e rotas SD-WAN dependentes. Esta exceção aplica-se aos hosts de internet, não aos hosts de sistema dinâmicos VPN/WWAN; os endereços das interfaces continuam a ser alterados em Network > Interfaces.

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.

Exemplo: bloquear um fluxo não web pelo MAC de origem

Este exemplo para SFOS 22/23 bloqueia um novo fluxo IPv4 TCP do iPerf3 de um dispositivo de teste LAN diretamente visível para um servidor de teste WAN controlado. Não é um procedimento para bloquear todo o acesso à internet: HTTP/HTTPS e Web Exceptions ficam fora deste teste. Primeiro, verificar com Packet Capture na interface de entrada o verdadeiro MAC de origem do dispositivo. Se apenas um router a montante estiver visível, esta regra não é adequada; uma porta LAN num switch não comprova, por si só, a visibilidade de camada 2. Antes da alteração, verificar a acessibilidade do servidor WAN e da porta TCP 5201. O servidor tem de executar realmente iPerf3, não um serviço web.

Em Hosts and services > MAC host > Add, introduzir mac_test_client como Name, MAC address como Type e 02:00:00:00:00:10 como MAC address, e guardar com Save. O nome e o endereço unicast administrado localmente são exemplos; substituir o endereço pelo MAC verificado do dispositivo.
Abrir Rules and policies > Firewall rules, escolher IPv4 e criar drop_mac_test_wan através de Add firewall rule > New firewall rule. Definir Action como Drop e ativar Log firewall traffic.
Definir Source zones como LAN, Source networks and devices como mac_test_client e Destination zones como WAN. Em Destination networks, selecionar o IP Host do próprio servidor de teste WAN e, em Services, svc_iperf3_tcp; criar este serviço TCP com Destination Port 5201 conforme descrito na secção seguinte. Assim, o destino e o serviço de teste não web ficam estritamente limitados. Any não é necessário neste exemplo.
Definir During scheduled time como All the time para um bloqueio permanente; caso contrário, escolher o horário adequado. Colocar a regra acima das que permitiriam primeiro o mesmo fluxo, sem deslocar exceções intencionais de maior prioridade. Top não é um requisito universal. Rule group pode permanecer em None; um grupo não substitui uma posição correta. Guardar com Save e verificar a ordem real.

Depois, iniciar a partir do dispositivo de teste uma nova tentativa de ligação TCP do iPerf3 ao mesmo servidor WAN na porta 5201, não um teste UDP ou no navegador. No Log Viewer, Drop e a Rule ID desta regra de bloqueio têm de corresponder ao fluxo. Testar o mesmo fluxo não web a partir de um segundo dispositivo não bloqueado: deve continuar a corresponder à regra Allow prevista. Utilizar novas ligações em ambos os testes, não sessões existentes. Se faltar a correspondência esperada, verificar o MAC de origem no Packet Capture, as zonas, a versão IP, o horário, o âmbito de destino/serviço e as regras anteriores.

Esta verificação comprova apenas os fluxos testados, não um bloqueio geral da web ou da internet. IPv6, outras zonas de destino, destinos e serviços não estão abrangidos e necessitam de configuração e testes próprios. Para reverter a alteração, desativar apenas a nova regra de bloqueio e verificar o estado permitido anterior com um novo fluxo TCP do iPerf3. O risco de falsificação e de identidade descrito acima mantém-se.

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.

Para criar um serviço do tipo IP em Hosts and services > Services > Add, atribuir um Name adequado, definir Type como IP, selecionar o número de protocolo necessário e guardar com Save. Trata-se do número do protocolo IP, não de uma porta de destino TCP/UDP. Depois, reabrir o serviço e comparar o número com o requisito da aplicação; ao testar numa regra estritamente limitada, verificar no Packet Capture o protocolo efetivamente observado. Se faltar a correspondência esperada, verificar primeiro o protocolo e o âmbito da regra, em vez de recorrer a Any.

Em Hosts and services > Services > Add, um serviço pode conter várias entradas do mesmo tipo selecionado. Para ICMP ou ICMPv6, selecionar primeiro o par de tipo e código necessário, adicionar outros pares com Add e eliminar entradas desnecessárias com Remove. Depois, verificar todas as entradas e guardar com Save. Assim, vários tipos de mensagem ICMP necessários podem ser descritos num único serviço, sem permitir indiscriminadamente todos os tipos. Os serviços TCP/UDP separados e o Service Group do exemplo iPerf3 continuam a ser uma alternativa clara quando se pretende reutilizar os serviços individualmente.

Nota de versão sobre a documentação da API: Na tabela guardada da API Sophos «Add Service / Update Service» para SFOS 22, a coluna Mandatory indica No tanto para ICMPType como para ICMPv6Type; para SFOS 23, indica Yes em ambos os casos. São indicações na documentação da API, não provas de uma alteração da GUI ou do comportamento em execução. Dizem respeito aos campos ICMP/ICMPv6 e não devem ser interpretadas como uma obrigação de adicionar ambas as famílias de protocolos aos serviços TCP/UDP/IP. A página não define uma regra condicional que indique quando estes campos podem ser omitidos; por isso, estas indicações não permitem deduzir instruções concretas sobre o payload ou a validação.

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.

Encontrar objetos existentes e geri-los de forma direcionada

As listas em Hosts and services > IP host, IP host group, MAC host, Services e Service group permitem pesquisar pelos atributos dos respetivos objetos. Antes de criar um novo objeto, pesquisar não só pelo nome pretendido, mas também pelos valores de endereço ou de protocolo/porta necessários, na medida em que se apliquem ao tipo de objeto. Assim, é possível identificar um objeto já adequado com outro nome. Depois de guardar, pesquisar novamente o objeto e verificar os seus valores ou os membros do grupo, conforme o caso.

Os Custom IP Hosts e IP Host Groups podem ser adicionados, alterados e eliminados; os Service Groups próprios também podem ser alterados, renomeados, receber serviços adicionais ou ser eliminados. Atualizar sempre primeiro Object Usage. Uma alteração num grupo afeta todas as regras que utilizam esse grupo, não apenas o caso de utilização que está a ser editado. Antes da alteração, registar os valores e membros existentes; depois, verificar as ligações afetadas com novas sessões. Se o âmbito estiver incorreto, reverter a alteração de forma controlada e voltar a testar. Continuam a aplicar-se as restrições descritas acima para System Hosts, Service Groups predefinidos e serviços protegidos.

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.