Enviar Syslog seguro do Sophos Firewall para um SIEM

Com o Syslog, o Sophos Firewall envia eventos para um servidor de logs externo, um SIEM ou um SOC. Para que a integração seja realmente útil, quatro elementos precisam estar alinhados: transporte, seleção de logs, formato e parser. Por isso, este artigo começa diretamente pela configuração e mostra em seguida como identificar logs ausentes ou interpretados de forma incorreta.

O Log viewer local continua importante para a análise em tempo real. O Central Firewall Reporting é adequado para relatórios do Sophos Fusion (anteriormente Sophos Central); o Syslog é a escolha certa para retenção própria, correlação entre diferentes fabricantes e detecção por SIEM.

Configurar o servidor Syslog

Primeiro é preciso definir o IP de destino ou FQDN, a porta, o formato de log esperado e um parser adequado. O firewall precisa de uma rota para o Collector, e ambos os sistemas precisam de uma fonte de horário funcional. Normalmente, o SFOS usa UDP 514 para Syslog. Essa tela não oferece uma seleção de transporte separada: Secure log transmission ativa ou desativa a transmissão criptografada por TLS. No exemplo TLS oficial da Sophos para syslog-ng, é usada a porta 6514; a porta e o listener sempre precisam corresponder ao próprio Collector.

Abrir System services > Log settings.
Selecionar Add.
Atribuir um nome exclusivo, como siem-primary.
Inserir o Collector em IP address/domain.
Selecionar Port, Facility, Severity level e Format conforme o sistema de destino.
Ativar Secure log transmission se o Collector TLS estiver preparado.
Salvar.
Em Log settings, ativar os tipos de log desejados na coluna desse servidor Syslog.

O SFOS oferece suporte a até cinco servidores Syslog externos. Vários destinos fazem sentido quando cumprem funções diferentes, como um arquivo local e um Collector MDR. Enviar todos os logs indiscriminadamente para todos os destinos aumenta o volume, os custos e o risco à privacidade.

Facility, severidade e formato

Facility: As opções incluem DAEMON, KERNEL, USER e LOCAL0 a LOCAL7. Por exemplo, LOCAL1 e LOCAL2 podem diferenciar dois firewalls. Mantenha a atribuição consistente no Collector e na documentação operacional.
Severity level: A seleção representa a severidade mínima. Error também envia Critical, Alert e Emergency, mas não eventos Information ou Notice. Debug inclui todos os níveis. Uma severidade mínima alta demais pode ocultar logins e eventos operacionais comuns.
Format: Estão disponíveis Standard syslog protocol e Device standard format (legacy). O formato esperado pelo parser do SIEM é o que importa. Uma alteração posterior pode interromper pesquisas, dashboards e regras de detecção.

Secure log transmission

O TLS é recomendável para conexões de produção por redes inseguras ou compartilhadas, porque os logs podem conter endereços internos, nomes de usuário, URLs e eventos de segurança. No entanto, não basta ativar a opção: o Collector precisa aceitar TLS na porta escolhida, e os dois lados precisam conseguir validar os certificados.

Para a conexão Secure Syslog documentada pela Sophos, aplicam-se estas condições:

O certificado de servidor do Collector e sua cadeia de certificados precisam ser confiáveis para o firewall.
O FQDN configurado precisa corresponder ao certificado. Sem LINCE, o SFOS verifica o Common Name; com LINCE, pode corresponder o Common Name ou o Subject Alternative Name.
Em Certificates > Certificate authorities, é baixada a CA Default da Sophos. O Collector precisa confiar no arquivo Default.pem extraído dessa CA, porque a Sophos a utiliza no seu lado da conexão.
Somente depois disso, Secure log transmission é ativado com a porta TLS preparada.

No exemplo oficial do syslog-ng, Default.pem e a CA externa ficam no diretório de CAs do Collector; peer_verify(required-trusted) força a validação do certificado. Outros produtos Collector usam seus próprios Trust Stores. Um FQDN que aparece somente no SAN não funciona sem LINCE, e um endereço IP configurado não corresponde a um certificado que contém apenas um nome DNS.

Antes de ativar o LINCE para este fim, verificar o limite da certificação, os algoritmos permitidos e o reinício SSH do modo LINCE. O modo não é apenas um interruptor de syslog e não deve ser ativado sem acesso administrativo independente.

Se um SIEM na nuvem não oferecer suporte direto a esse procedimento, o firewall pode enviar os logs internamente para um Collector local, que os encaminha de forma criptografada. Um trecho sem criptografia deve ser curto, segmentado e documentado.

Definir os tipos de log e a visibilidade

O destino é ativado em duas etapas:

A regra ou função correspondente precisa gerar o evento. Nas regras de firewall, isso exige Log firewall traffic; nas regras de SSL/TLS Inspection, Log connections.
Em System services > Log settings, o tipo de log correspondente precisa ser selecionado na coluna do servidor Syslog.

Se uma das duas etapas estiver ausente, o Collector não poderá receber o evento. Para um piloto, basta começar com um conjunto pequeno e definido de forma consciente:

Firewall e Events: eventos de regras, atividades de administradores e usuários, além de eventos de autenticação, VPN, DHCP e DNS.
IPS, Content filtering, Web server protection e Zero-day protection: decisões de segurança e de políticas.
Active threat response: correspondências de MDR, NDR Essentials, Sophos X-Ops e Third-Party Threat Feeds.
System health, Wireless, Heartbeat e SD-WAN: estado operacional adicional quando esses módulos são utilizados.

Outros módulos só devem ser adicionados quando houver um objetivo de pesquisa, alarme ou auditoria. Ao analisar eventos de DoS, também é necessário verificar a configuração de Spoof Protection e DoS. Para Third-Party Threat Feeds e NDR e Active Threat Response, além do transporte de logs, são necessárias pesquisas e alarmes específicos.

Âmbito do ATR: Ativar o registo de origens remotas apenas para combinações de módulo e caminho de tráfego cujo suporte esteja estabelecido. O texto ATR da Sophos e a matriz de tráfego SVG contradizem-se quanto às direções de correspondência do X-Ops; este conflito continua por resolver. As afirmações sobre MDR, NDR ou feeds de terceiros não comprovam suporte equivalente no X-Ops. Manter controlos restritivos de firewall, DNAT/WAF e Device Access independentes do comportamento contestado do feed. Os casos contestados exigem uma verificação autorizada e controlada do módulo, da direção de correspondência, dos logs e do efeito real, além de um esclarecimento fiável; até lá, a proteção não deve depender desse comportamento. NDR e Active Threat Response explica o contexto seguro.

Falhas comuns de visibilidade

Log Suppression: O SFOS pode agrupar eventos de firewall idênticos e consecutivos. Isso afeta o Log Viewer, o Sophos Fusion e o Syslog. Portanto, o parser e a detecção também precisam considerar log_occurrence.
Active Threat Response: Remote Source Match para tráfego DNAT ou WAF de entrada não fica ativo por padrão. Sem essa seleção, as correspondências de origem relevantes ficam ausentes nos módulos e caminhos de tráfego suportados. Respeitar também o âmbito do ATR acima ao investigar tipos de correspondência ausentes; selecionar a opção não comprova suporte para as direções contestadas do X-Ops.
Wireless: Os logs de Access Points e SSIDs não estão disponíveis no Log Viewer local. Eles precisam ser enviados de forma direcionada ao Sophos Fusion ou Syslog e verificados no destino.
Content filtering e SSL/TLS: O tipo de log selecionado não substitui o logging na regra de firewall ou de Inspection correspondente.
Web Proxy: Para tráfego web nas portas 80 ou 443, o log Firewall pode mostrar Allowed enquanto o Web Filter bloqueia a mesma solicitação. Correlacione os eventos Firewall e Web Filter para determinar a decisão de política efetivamente aplicada.

Verificar o formato e o parser

Um teste do parser não deve apenas demonstrar que algum texto chegou. Os valores principais precisam ser pesquisáveis como campos separados. Este exemplo abreviado e anonimizado corresponde ao Standard syslog protocol para um evento de regra de firewall:

device_name="BRANCH-01" timestamp="2026-08-03T09:15:21+0200" device_model="XGS136" device_serial_id="C00000000000000" log_id="010101600001" log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" log_version=1 severity="Information" fw_rule_id="12" fw_rule_name="LAN_to_WAN_Web" nat_rule_id="4" src_ip="10.10.20.25" dst_ip="203.0.113.10" protocol="TCP" src_port=53144 dst_port=443 con_event="Stop" log_occurrence="1"

O formato legacy utiliza, entre outros, device, date, time, timezone, device_id e priority. Campos como status, user_name, nat_rule_id ou log_occurrence também dependem do tipo de log e do evento. Eles não devem ser tratados como obrigatórios para todos os eventos no formato padrão. Para a aceitação inicial, configure o parser apenas com os campos principais abaixo; torne obrigatórios outros campos específicos do tipo de log somente depois de os confirmar com um evento de teste real.

Para a aceitação, dependendo do caso de uso, são especialmente importantes:

Identidade: device_name, device_model, device_serial_id
Classificação: log_id, log_type, log_component, log_subtype, severity
Política: fw_rule_id, fw_rule_name, nat_rule_id
Conexão: src_ip, dst_ip, portas, protocolo e usuário
Horário e frequência: timestamp, fuso horário e log_occurrence

log_id contém tipo de log, componente, subtipo, severidade e Message ID. Com isso, as regras de detecção ficam mais estáveis do que pesquisas de texto livre. Mesmo assim, os campos fornecidos por cada módulo precisam ser verificados com um evento real desse tipo de log.

Os doze caracteres ocupam posições fixas: os caracteres 1 e 2 formam o Log Type ID, 3 e 4 o Component ID, 5 e 6 o Subtype ID, o carácter 7 o Priority ID e os caracteres 8 a 12 o Message ID. Assim, 010101600001 é lido como 01 / 01 / 01 / 6 / 00001. O parser tem de preservar os zeros à esquerda e as larguras fixas dos campos; como verificação adicional, devem ser avaliados log_type, log_component, log_subtype e severity.

O módulo Syslog Events não é idêntico a configuration-audit.log. Os valores anteriores e posteriores só estão disponíveis para objetos-chave compatíveis, como regras de firewall, interfaces e IP hosts, e não para todas as alterações de configuração. O escopo e a análise são abordados no artigo sobre Audit Trail Logs.

Vários firewalls e HA

Em um ambiente com vários appliances, cada evento precisa ser atribuído claramente ao firewall, local, cliente e cluster HA. Portanto, hostname, número de série, modelo e Facility devem estar documentados e disponíveis como filtros no SIEM. A partir do SFOS 22.0, device_name identifica o hostname do firewall que gerou o log. Após um upgrade, verifique se o parser processa esse campo em vez de continuar usando apenas device_serial_id ou o cabeçalho Syslog como chave do asset.

Depois de um failover HA, restore ou troca de hardware, é preciso verificar se os eventos continuam associados ao asset existente ou aparecem como um sistema novo ou duplicado. O mesmo se aplica depois de uma alteração no hostname ou no formato Syslog.

Testar a integração com eventos reais

Um Collector com status verde não comprova a seleção correta de logs nem o funcionamento do parser. Para a aceitação:

Documentar um firewall piloto e o estado inicial: nome do servidor, destino, porta, TLS, Facility, Severity, Format e todos os tipos de log ativados na coluna desse servidor.
Enviar inicialmente Firewall e Events para o destino.
Acionar uma regra de teste com logging e Source, Destination e Service definidos.
Verificar no SIEM o dispositivo, horário, tipo de log, ação, Rule ID, Source e Destination.
Gerar um drop definido e estabelecer e encerrar uma conexão VPN.
Testar pelo menos um evento de segurança de IPS, Content filtering ou Active threat response, se o módulo for utilizado em produção.
Depois, ativar outros tipos de log gradualmente e observar o volume e o resultado do parser.

Para testar regras, é útil consultar o guia sobre Log Viewer, Policy Test e Packet Capture. Um teste negativo também é importante: uma conexão esperada é bloqueada de forma deliberada e precisa aparecer como drop com a regra correta.

Em projetos de HA ou migração, a aceitação deve incluir um teste de failover, restore ou troca de hardware. Depois disso, o SOC ainda precisa reconhecer qual dispositivo e qual local geraram o evento.

Reverter uma alteração sem criar uma lacuna nos dados

Não altere o formato, a severidade mínima e a seleção de logs ao mesmo tempo. Se uma das cinco vagas de servidor estiver livre, adicione um segundo destino para a migração do parser ou do Collector e mantenha ambos em paralelo inicialmente. Assim, é possível comparar os dados brutos, os campos preenchidos, os timestamps e o volume sem alterar o destino que está funcionando.

Somente depois da aceitação, desative os tipos de log na coluna do destino antigo. Mantenha a entrada desse servidor durante um período de observação acordado. Se faltarem eventos, o parsing falhar ou o volume for inesperado, reative ali exatamente os tipos de log documentados anteriormente e desfaça a seleção no novo destino. Se não houver uma vaga de servidor livre, registre os valores atuais antes de cada alteração individual e restaure-os por completo em caso de falha; não exclua a entrada nem altere o parser ao mesmo tempo.

Operação, retenção e falhas

Uma integração Syslog precisa de um Owner, uma retenção definida e uma resposta aos alarmes. Também deve estar claro quem avalia falsos positivos e ajusta as regras de detecção. Os logs de firewall podem conter dados pessoais, endereços internos, nomes de usuário, URLs e atividade de VPN. Portanto, os direitos de acesso, os prazos de exclusão, a separação de tenants e os custos do SIEM devem ser esclarecidos antes de um rollout amplo.

A operação precisa detectar não apenas ataques, mas também a ausência de dados:

monitorar uma atividade mínima esperada por firewall;
verificar separadamente se tipos de log importantes, como Firewall, Events, IPS ou Active threat response, estão atualizados;
monitorar campos centrais do parser para identificar valores vazios ou renomeados de forma inesperada;
gerar alertas sobre a expiração de certificados e o estado do Collector;
voltar a gerar eventos de teste depois de atualizações de firmware, parser ou certificados.

O próprio monitoramento também precisa ser testado: se um tipo de log esperado ou um firewall parar deliberadamente de enviar dados, o alarme de ausência definido deve ser acionado.

Dados brutos sem campos interpretados também representam uma falha. Uma atualização do parser pode manter o transporte intacto enquanto dashboards e regras de detecção deixam de gerar correspondências.

O Syslog não substitui os Service Logs locais nem um arquivo de troubleshooting para o suporte. Para registros NetFlow v5 de regras de firewall com logging direcionado, usa-se NetFlow; para amostras de interface e padrões de tráfego, sFlow. O estado do hardware e das interfaces também pode ser monitorado por SNMP.

Isolar os erros de forma direcionada

Nenhum log chega: Verificar o destino, a porta, o transporte, o roteamento e o firewall do lado oposto. Depois, confirmar se o tipo de log desejado está ativo na coluna Syslog. Se o Collector estiver atrás de uma VPN ou rede de gerenciamento, considerar também a rota, a SD-WAN Policy e o Source NAT.

Somente determinados eventos estão ausentes: Primeiro, verificar o logging na regra de firewall ou de Inspection afetada e, em seguida, o tipo de log em Log settings. Para ATR, verificar também o Match Type necessário.

Primeiro, confirmar se o módulo e o caminho de tráfego são suportados. Respeitar o âmbito do ATR acima: a ausência de logs não resolve o conflito do X-Ops, e as direções contestadas não justificam simplesmente ativar outros tipos de correspondência.

Logs brutos chegam, mas faltam campos: Comparar o formato configurado, a versão do parser e a versão do firmware. Campos padrão e legacy não devem ser esperados no mesmo perfil de parser.

TLS não conecta: Verificar a porta TLS e o serviço do servidor e, depois, a cadeia de certificados, o FQDN, Common Name, SAN e o modo LINCE. Além disso, o Collector precisa confiar na CA da Sophos Default.pem. Ao trocar certificados, verificar os dois Trust Stores e o processo de renovação.

Os timestamps não correspondem: Verificar o NTP no firewall e no Collector, o fuso horário do SIEM e a normalização do parser. Horários incorretos impedem uma correlação confiável com logs de Endpoint, servidor e identidade.

Muitos logs ou muito ruído: Não desativar tudo indiscriminadamente. Primeiro, avaliar os tipos de log não utilizados, as regras desnecessariamente ruidosas, os casos de uso do SIEM e log_occurrence; depois, reduzir a seleção de forma direcionada.