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 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 transporte, 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. UDP 514 é comum; com TLS, TCP 6514 é usado com frequência, mas a configuração do Collector é o que determina os valores.

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: LOCAL0 a LOCAL7 podem diferenciar firewalls ou grupos de locais. A atribuição precisa ser idêntica no Collector e na documentação.
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. Isso pode fazer com que logins e eventos operacionais normais fiquem ausentes.
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.

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.

Falhas comuns de visibilidade

Log Suppression: O SFOS pode agrupar eventos de firewall idênticos e consecutivos. Isso afeta o Log Viewer, o Sophos Central 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.
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 Central 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.

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, 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.

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.

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 formato configurado.
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.

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.

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.