Inspecionar portas não padrão com o Sophos Firewall

O Sophos Firewall inspeciona HTTP, HTTPS, FTP, SMTP/S, POP e IMAP nas respetivas portas padrão. Quando uma aplicação utiliza um destes protocolos noutra porta, service-param pode atribuir adicionalmente essa porta ao serviço de inspeção clássico.

O comando não abre uma porta de forma geral. Não cria um objeto de serviço nem uma regra de firewall e não ativa uma policy web, TLS ou de e-mail. Para o tráfego ser inspecionado, a correspondência da regra, a porta de destino permitida e o caminho de inspeção responsável têm de estar alinhados. Para regras web novas, determina-se primeiro se o fluxo é processado pelo DPI Engine ou Web Proxy.

⚠️ service-param é uma atribuição global. Uma porta adicional não afeta apenas um host ou uma regra de firewall. Antes da alteração, documentam-se as utilizações existentes da porta, as policies afetadas e uma reversão executável.

Quando service-param é adequado

O comando é adequado quando uma aplicação conhecida utiliza realmente HTTP, HTTPS, FTP, SMTP, SMTPS, POP ou IMAP numa porta TCP não padrão e o serviço clássico correspondente tem de inspecionar esse tráfego. Exemplos típicos são um portal HTTPS interno na porta 8443 ou uma configuração explícita de e-mail numa porta adicional.

Uma porta TCP aberta não prova a utilização do protocolo esperado. Se na porta 8443 existir tráfego binário proprietário, atribuí-la a HTTPS pode interromper ligações em vez de acrescentar proteção. Para tráfego web, verifica-se também se o DPI Engine já deteta o protocolo ou se é realmente necessário adicionar uma porta de serviço ao proxy. Para e-mail, distingue-se SMTP com STARTTLS de SMTPS com TLS desde o início da ligação. Mail Protection em modo MTA explica o caminho de e-mail.

service-param não é adequado quando uma regra de firewall apenas precisa de permitir uma porta de destino adicional. Em Hosts and services > Services, cria-se um objeto de serviço TCP adequado e utiliza-se na regra. A atribuição de inspeção só é adicionada quando o proxy ou serviço de e-mail responsável também precisa de processar a porta não padrão.

Registar o estado inicial na Device Console

O comando é executado através de 4. Device Console. Antes de qualquer alteração, o comando seguinte mostra as portas de serviço existentes e outros valores globais:

show service-param

Regista-se a saída completa com o build SFOS, a hora e a referência da alteração. É especialmente importante verificar se a porta pretendida já está atribuída a outro serviço. A mesma porta não é atribuída por suspeita simultaneamente a HTTP, HTTPS, SMTP e SMTPS.

A Sophos documenta estes nomes de serviço para o SFOS 22:

FTP
HTTP
HTTPS
IMAP
POP
SMTP
SMTPS
IM_MSN
IM_YAHOO

IM_MSN e IM_YAHOO são designações legacy na CLI. Não constituem um ponto de partida para um novo design de mensagens instantâneas. As aplicações novas são protegidas por regras de firewall, Application Control, TLS Inspection e a deteção de protocolos efetivamente suportada.

Adicionar uma porta adicional

A sintaxe básica documentada para os serviços suportados é:

set service-param <service> add port <portID>
set service-param <service> delete port <portID>

Para um portal HTTPS confirmado em TCP 8443, um piloto controlado tem, por exemplo, este aspeto:

show service-param
set service-param HTTPS add port 8443
show service-param

A regra de firewall também precisa de um serviço que permita TCP 8443 como porta de destino. Para HTTPS, determina-se qual o caminho de inspeção que desencripta, qual o certificado esperado e se a aplicação utiliza Certificate Pinning. Uma página web visível não prova nem a desencriptação nem a análise de malware.

O marcador portID na sintaxe Sophos é utilizado na Device Console com o valor concreto da porta. A porta só é adicionada depois de um Packet Capture ou a documentação da aplicação confirmar o protocolo e a porta de destino.

Não misturar opções globais com o teste da porta

Para HTTPS, a Sophos indica adicionalmente deny_unknown_proto on|off e invalid-certificate allow|block. SMTPS também dispõe de invalid-certificate allow|block. SMTP oferece outras opções globais para Failure Notifications, Fast ISP Mode, Notification Port e Strict Protocol Check.

Estes valores resolvem um problema diferente de add port e não são alterados no mesmo piloto. Em particular, invalid-certificate allow pode tolerar globalmente erros de certificado, enquanto deny_unknown_proto e strict-protocol-check alteram o tratamento de ligações não conformes. Uma ligação bem-sucedida após várias alterações simultâneas seria difícil de atribuir e poderia reduzir silenciosamente a proteção.

A sintaxe oficial também inclui:

set service-param HTTPS deny_unknown_proto <on|off>
set service-param HTTPS invalid-certificate <allow|block>
set service-param SMTPS invalid-certificate <allow|block>
set service-param SMTP failure_notification <on|off>
set service-param SMTP fast-isp-mode <on|off>
set service-param SMTP notification-port add port <portID>
set service-param SMTP strict-protocol-check <on|off>

Antes de uma destas alterações globais, avaliam-se separadamente a saída atual exata, os remetentes ou aplicações web afetados, o impacto na segurança e as indicações do suporte. Por isso, o artigo não apresenta estes comandos como valores padrão recomendados.

Validar o efeito com um fluxo real

O teste começa com exatamente uma origem piloto e uma regra de firewall com logging. Antes e depois da alteração, utilizam-se o mesmo destino, a mesma porta de destino e uma ligação nova. No Log Viewer, Firewall Rule ID, a ação web ou de e-mail e a hora têm de corresponder ao piloto.

Para HTTPS, verificam-se também o emissor do certificado, o handshake TLS e a ação Block ou Allow esperada. Se a análise de malware fizer parte do design, executa-se um teste EICAR controlado exatamente através dessa porta. O EICAR só confirma o caminho antivírus normal, não todas as funções TLS, de policy ou ML. Para SMTP, SMTPS, POP e IMAP, utiliza-se uma mensagem de teste claramente identificável e acompanha-se em Mail Logs, Quarantine e, quando aplicável, Mail Spool.

Um Packet Capture confirma que o cliente utiliza realmente a porta de destino prevista. Se apenas o Firewall Log mostrar Allow, ainda não existe prova de que o proxy ou serviço de e-mail seguinte tenha inspecionado o conteúdo. Testar regras Sophos Firewall de forma controlada combina a correspondência de regras, Log Viewer e Packet Capture.

Reverter a atribuição da porta

A reversão remove do serviço correto apenas a porta adicionada pela alteração:

set service-param HTTPS delete port 8443
show service-param

Depois, estabelece-se novamente o mesmo fluxo de teste. A conectividade tem de regressar ao estado inicial documentado. As permissões temporárias do serviço de firewall, regras piloto e exceções são removidas separadamente; delete port não elimina estes objetos.

Se a adição da porta já falhar, registam-se o erro e show service-param. Muitas vezes, a porta já é tratada como padrão ou está atribuída a outro serviço. A entrada existente não é eliminada sem verificação, pois outro caminho de inspeção pode depender dela.

Checklist operacional

• A aplicação, o protocolo e a porta de destino real estão confirmados.
• show service-param e o build SFOS estão registados antes da alteração.
• Serviço de firewall, correspondência da regra e atribuição de inspeção são tratados separadamente.
• A porta não está já atribuída a um serviço incompatível.
• No piloto muda apenas add port, não uma opção global de certificado ou protocolo.
• Teste positivo, teste negativo, log de inspeção e Packet Capture estão preparados.
• O comando delete port correspondente e o caminho de retorno inalterado estão prontos.

FAQ