Gerir os System Modules do Sophos Firewall com segurança

O Sophos Firewall utiliza System Modules como helpers de protocolo quando a firewall precisa de acompanhar informação adicional ou considerar ligações dinâmicas. O SFOS 22 lista dns, h323, irc, pptp, sip e tftp. Estes módulos são carregados por predefinição.

Um módulo carregado não é uma regra de firewall nem uma recomendação para utilizar o protocolo correspondente. Não substitui uma regra NAT, uma rota ou uma política de segurança. Descarregar todos os helpers aparentemente não utilizados também não é uma medida de hardening sensata. A definição é global e pode afetar inesperadamente aplicações existentes.

⚠️ Regra operacional: Primeiro registar o estado e o fluxo concreto com falhas. Alterar no máximo um módulo, repetir o mesmo fluxo e repor o estado original se não houver melhoria.

Classificar corretamente os seis módulos

Em sip e h323, o helper é muitas vezes indicado demasiado cedo como causa ou solução. O processo completo com NAT, RTP, timeouts, porta SIP personalizada, Packet Capture e chamadas de teste está em Resolver problemas VoIP com SIP e RTP.

Registar a baseline na Device Console

Os comandos pertencem a 4. Device Console, não à Advanced Shell. O acesso é feito por SSH ou através de admin > Console, no canto superior direito do WebAdmin. Para SSH, permitir SSH para a zona necessária em Administration > Device access > Local service ACL; a consola web requer HTTPS nessa secção. Não abrir o acesso para além da origem de administração necessária.

Antes de uma alteração, ler o estado global:

system system_modules show

Guardar todo o output, mesmo quando apenas um módulo está a ser investigado. Assim permanece visível se um sistema migrado ou anteriormente alterado difere da predefinição. loaded apenas comprova o estado do módulo, não que o helper processe um fluxo específico ou cause a falha. Se o SIP tiver sido carregado anteriormente com uma porta personalizada, registar também o seu valor exato a partir da documentação de configuração existente. Não alterar o SIP se não for possível determinar esse valor de forma fiável, pois nesse caso não se pode preparar um caminho de retorno que preserve o estado.

Registar também IP de origem e destino, porta, protocolo, Rule ID, NAT ID, hora e o teste exato da aplicação. Sem um fluxo reproduzível não é possível avaliar uma alteração global com fiabilidade. Log Viewer, Policy Test e Packet Capture são adequados para a validação técnica.

Carregar ou descarregar exatamente um módulo

Os comandos básicos seguem o mesmo padrão. A tabela é uma referência, não um bloco para executar na totalidade.

Antes da execução, verificar o build instalado com a ajuda incorporada: introduzir o comando pretendido e usar ? para mostrar os argumentos suportados. Não enviar variantes incompletas por tentativa; a Sophos avisa que um comando incompleto da Device Console pode bloquear o daemon access_server. Depois de exatamente uma alteração, executar novamente system system_modules show e repetir o fluxo da aplicação já documentado. Alterações paralelas ao NAT, regras, routing, timeouts ou PBX dificultam a atribuição e devem ser evitadas.

A Sophos documenta expressamente que load e unload do SIP persistem após um reinício. A página SFOS 22 não apresenta a mesma declaração precisa para os restantes módulos. Ler novamente o seu estado após um reinício planeado em vez de assumir a persistência.

Não deduzir portas personalizadas de uma sintaxe abreviada incompleta

A página lista para IRC, SIP e TFTP termos adicionais como port, portname, default ou show, mas não explica completamente a sua forma exata. Estes valores não devem ser adivinhados. A Device Console mostra a sintaxe do build instalado com ?.

Para SIP, a Sophos publica separadamente o comando exato system system_modules sip load ports <custom_port>. Esta decisão pertence à análise VoIP, não a um teste geral de helpers. Substituir o placeholder pela porta de sinalização realmente utilizada pelo fornecedor ou PBX.

Conhecer os limites do SIP antes do teste

Por predefinição, o SIP helper utiliza a porta UDP 5060. Traduz os endereços IP locais no cabeçalho SIP para endereços públicos e cria na firewall uma ligação de voz dinâmica esperada. Assim, o seu efeito vai além do simples reconhecimento da sinalização.

Dois limites são essenciais no diagnóstico:

• O helper só suporta portas multimédia SIP no intervalo 1024–65535. Se uma porta multimédia configurada estiver fora deste intervalo, a firewall descarta os pacotes e o Event Log mostra Invalid Traffic.
• O helper não suporta mensagens SIP ou SDP distribuídas por mais de um pacote. Isto pode ocorrer com SIP sobre TCP. A Sophos indica uma ligação de controlo SIP por UDP como alternativa; esta só deve ser usada se for suportada pelo fornecedor, PBX ou SBC.

Uma porta de sinalização personalizada e o intervalo multimédia RTP são valores diferentes. <custom_port> no comando de carregamento é a porta de sinalização SIP realmente utilizada; não se deve deduzir dela um intervalo RTP.

Verificar o efeito e o caminho de retorno

Um teste adequado verifica mais do que o output da CLI. Depois de carregar ou descarregar, verificar o estabelecimento da ligação, o tráfego nas duas direções, Rule e NAT ID, drops e a aplicação afetada. Para SIP ou H.323, incluir registo, ligações de entrada e saída e multimédia bidirecional. Para DNS, verificar pedido e resposta com o nome esperado. Para TFTP, verificar também a transferência do ficheiro.

Se o sintoma não mudar ou surgirem novas falhas, repor apenas o módulo alterado no estado anteriormente registado:

• Se estava carregado com a definição predefinida, voltar a carregá-lo com o comando ... load correspondente.
• Se estava descarregado, voltar a descarregá-lo com o comando ... unload correspondente.
• Se o SIP estava carregado numa porta de sinalização personalizada, repor exatamente o valor guardado com system system_modules sip load ports <previous_custom_port>. Substituir <previous_custom_port> pelo valor da baseline, não por um novo valor de exemplo.

Depois, executar system system_modules show e o mesmo fluxo de teste. O output da CLI deve corresponder à baseline guardada e o teste não deve ter acrescentado uma falha ao caminho original da aplicação. Um reinício não substitui este rollback.

Se o comportamento mudar mas a causa permanecer incerta, guardar os estados anterior e posterior, o build do firmware, os logs e o Packet Capture. Um helper descarregado globalmente não deve permanecer como solução definitiva apenas porque um teste curto pareceu melhor.

No SIP, o sintoma orienta a verificação seguinte: Invalid Traffic com ausência de multimédia conduz primeiro à porta multimédia configurada e ao intervalo 1024–65535. Se o registo por TCP falhar ou mensagens SIP/SDP longas forem interrompidas, verificar o limite de um único pacote. Se o estado apresentado do módulo estiver correto mas o comportamento não mudar, confirmar primeiro a porta de sinalização realmente utilizada e o caminho Rule/NAT afetado.

FAQ