Enviar Syslog do Sophos Firewall para um SIEM

Com o Syslog, um Sophos Firewall pode enviar eventos para um servidor de log externo, um SIEM ou uma plataforma de segurança. Isso é especialmente importante quando os logs precisam ser armazenados por mais tempo, pesquisados centralmente, correlacionados com outros sistemas ou usados para auditorias e resposta a incidentes.

O Log viewer local é bom para análise rápida diretamente no firewall. Central Firewall Reporting é prático quando o Sophos Central é usado como plataforma de relatórios. O Syslog é a melhor escolha quando há um SIEM próprio, um SOC, um processo de detecção gerido ou uma arquitetura de log de múltiplos fornecedores.

Qual artigo de logging é adequado?

O logging no Sophos Firewall consiste em várias camadas. Dependendo da questão, o Syslog nem sempre é o melhor ponto de partida:

Assim, a avaliação permanece clara: o Log Viewer responde ao caso atual de pacote ou política, logs locais ajudam no diagnóstico mais profundo do módulo, Central Reporting é conveniente para avaliações Sophos, e Syslog fornece a camada externa de longo prazo e SIEM.

Quando o Syslog é útil

O Syslog é valioso não apenas para grandes ambientes. Mesmo com poucos firewalls, um servidor de log central pode ajudar a armazenar eventos por mais tempo e de forma independente do dispositivo.

Casos de uso típicos:

• armazenamento central de logs por semanas, meses ou anos
• correlação com logs de endpoint, servidor, identidade, proxy, nuvem ou switch
• casos de uso de SIEM para ataques, varreduras de porta, logins VPN, eventos WAF ou acertos de Threat Feed
• análise externa por SOC, MDR ou equipes internas de segurança
• rastreabilidade após atualizações de firmware, failover, restauração ou troca de hardware
• forense, quando os logs locais do firewall não são mais suficientes

Para casos agudos de solução de problemas, os logs locais ainda são importantes. Qual arquivo de log local pertence a qual módulo do firewall está em Solução de problemas do Sophos Firewall: Serviços e Logs. Se os logs precisam ser protegidos para suporte ou análise externa, Proteger logs do Sophos Firewall para suporte e análise é adequado.

Syslog, Central Reporting ou logs locais?

Os três métodos respondem a perguntas diferentes. Na prática, muitas vezes se usa vários deles em paralelo.

O Syslog não substitui o Log Viewer. Ele o complementa. O Log Viewer mostra rapidamente qual regra ou módulo decidiu. O Syslog garante que essas informações estejam disponíveis externamente mais tarde.

Pré-requisitos

Antes da configuração, os seguintes pontos devem ser esclarecidos:

• O servidor Syslog ou SIEM é acessível.
• O IP de destino ou FQDN é estável e documentado.
• Porta e transporte estão definidos, frequentemente UDP 514 ou TLS em uma porta própria.
• O firewall pode rotear e alcançar o servidor Syslog.
• No sistema de destino, existe um parser adequado ou pelo menos um armazenamento de dados brutos.
• A duração de armazenamento e os requisitos de proteção de dados estão definidos.
• Está claro quais tipos de log são realmente necessários.

Para destinos SIEM externos ou baseados em nuvem, deve-se prestar atenção especial à criptografia de transporte, IP de origem, roteamento, DNS e verificação de certificados.

Esclarecer proteção de dados, armazenamento e responsabilidade

O Syslog não é apenas um encaminhamento técnico. Logs de firewall podem conter endereços IP internos, nomes de usuários, sistemas de destino, URLs, categorias, logins VPN, eventos de administrador e acertos de segurança. Portanto, antes da conexão produtiva, deve estar claro quem pode ver esses dados e por quanto tempo eles serão armazenados.

Antes do lançamento, esclarecer:

Especialmente em modelos MSP, SOC ou MDR, essa responsabilidade não deve ficar em aberto. Um SIEM sem proprietários claros gera dados, mas não uma reação confiável.

Planejar o lançamento em fases

Para firewalls produtivos, um pequeno piloto é melhor do que enviar imediatamente todos os tipos de log para todos os destinos. Assim, é possível controlar parsers, nomes de campos, ruído e custos antes que o SIEM seja planejado como uma fonte confiável.

Um fluxo de trabalho sensato:

1. Primeiro, um firewall piloto é selecionado.
2. Nome do host, fonte de tempo, versão do firmware e formato de log são documentados.
3. O destino Syslog é configurado com transporte seguro.
4. O início ocorre com poucos tipos de log, por exemplo, Firewall, Eventos e VPN.
5. Eventos de teste definidos são gerados e verificados no sistema de destino.
6. Parser, campos, carimbos de tempo, fuso horário e device_name são validados.
7. O volume de logs e o ruído são observados por alguns dias.
8. Depois, outros tipos de log como IPS, Web, WAF, resposta ativa a ameaças ou saúde do sistema são adicionados.
9. Somente após um piloto bem-sucedido é que se expande para outros firewalls.

Em ambientes com vários firewalls, não basta verificar se os dados chegam. É importante saber se cada evento é atribuído corretamente ao local, dispositivo, nó HA, cliente ou locatário.

Adicionar servidor Syslog

A configuração é feita na interface web do Sophos Firewall.

1. Abra System services > Log settings.
2. Selecione Add.
3. Dê um nome único, por exemplo, siem-primary ou syslog-soc.
4. Insira o IP address/domain do servidor Syslog.
5. Defina a Port de acordo com o sistema de destino.
6. Escolha a Facility conscientemente.
7. Defina o Severity level.
8. Selecione o Format.
9. Opcionalmente, ative Secure log transmission se o destino suportar TLS.
10. Salve.

O Sophos Firewall pode configurar vários servidores Syslog externos. Na documentação atual, são previstos até cinco servidores Syslog. No entanto, não se deve conectar indiscriminadamente a qualquer destino, mas definir para cada destino qual é o propósito.

Configurações importantes

Facility

A Facility ajuda o servidor Syslog a distinguir fontes de log ou categorias. Em ambientes simples, um valor padrão geralmente é suficiente. Em ambientes maiores, pode ser útil separar firewalls ou grupos de locais usando diferentes valores de LOCAL0 a LOCAL7.

É importante que regras de SIEM, parsers e documentação usem a mesma lógica. Se cada firewall usar uma Facility diferente aleatoriamente, a avaliação se torna desnecessariamente difícil.

Severity level

A Severity define a partir de qual gravidade os logs são enviados. Para fins de segurança e solução de problemas, um limiar muito alto é perigoso, pois eventos importantes de informação ou aviso podem faltar. Para ambientes muito barulhentos, um limiar muito baixo pode gerar ruído desnecessário.

Geralmente, um piloto com uma seleção mais ampla de logs é sensato, seguido por uma redução consciente com base em acertos reais e casos de uso de SIEM.

Format

O Sophos Firewall oferece, de acordo com a documentação atual, dois formatos:

• Standard syslog protocol
• Device standard format (legacy)

Para novas integrações, deve-se primeiro verificar qual formato o sistema de destino ou o parser existente espera. Se um SIEM já tiver um parser para o Sophos Firewall, a expectativa dele é o que importa. Uma mudança de formato após o início da produção pode quebrar painéis, consultas de pesquisa e regras de detecção.

Secure log transmission

Quando Secure log transmission está ativo, os logs são enviados criptografados para o servidor Syslog. Para isso, o sistema de destino deve aceitar TLS na porta configurada, fornecer um certificado de servidor adequado e usar uma cadeia de certificados em que o firewall confie. Antes do go-live, não basta apenas marcar a opção no firewall, mas também verificar o nome do certificado, a cadeia de confiança, a porta, o parser e o processo de renovação do destino Syslog.

Para laboratórios internos, o UDP pode ser tecnicamente suficiente. Para conexões produtivas de SIEM ou SOC, no entanto, o Syslog não criptografado em redes inseguras não é uma boa base, pois os dados de log podem conter endereços IP internos, usuários, destinos, URLs ou eventos de segurança.

Com TLS, o nome do destino Syslog é importante. O Sophos verifica, dependendo do modo, o Common Name ou o Subject Alternative Name do certificado em relação ao domínio do servidor Syslog. Se no firewall for inserido um endereço IP, mas o certificado contiver apenas um nome DNS, a conexão pode falhar. Portanto, para destinos TLS-Syslog produtivos, deve-se planejar um FQDN estável, um certificado de servidor adequado e uma renovação de certificado documentada.

Selecionar tipos de log

Após adicionar o servidor Syslog, o trabalho ainda não está concluído. É necessário definir em System services > Log settings quais tipos de log serão enviados para esse destino.

Importante: Uma regra de firewall só gera logs de tráfego significativos se Log firewall traffic estiver ativado na regra. Para a inspeção SSL/TLS, o logging também deve estar ativo na regra de inspeção correspondente. A seleção de logs em Log settings determina para onde esses logs serão enviados.

Tipos de log típicos para um SIEM:

Se eventos DoS ou de spoofing forem avaliados, a própria proteção técnica também deve ser verificada. O procedimento está em Verificar proteção contra spoofing e configurações DoS do Sophos Firewall.

Se Third-Party Threat Feeds, NDR e Active Threat Response ou WAF forem usados, o SIEM deve avaliar esses eventos de forma direcionada. Apenas enviar logs não é suficiente. São necessárias consultas de pesquisa claras, alertas, responsabilidades e ajustes contra falsos positivos.

Armadilhas importantes de visibilidade

Em projetos de Syslog, muitas lacunas não surgem no transporte, mas antes: o firewall não gera o evento esperado, o tipo de log não é enviado para o servidor Syslog ou o SIEM interpreta os campos incorretamente.

Logging de regras e módulos

Regras de firewall e regras de inspeção SSL/TLS devem gerar logs por si mesmas. Em System services > Log settings, escolhe-se depois se esses logs serão enviados localmente, para o Sophos Central ou para servidores Syslog. Se uma regra de firewall não tiver Log firewall traffic, o servidor Syslog não pode exibir um histórico completo de tráfego de firewall.

Para eventos de política web, também é relevante se a regra de firewall associada gera logs de tráfego. Caso contrário, pode-se ver menos eventos de filtragem de conteúdo ou web no SIEM do que o esperado.

Supressão de logs

O Sophos Firewall pode suprimir vários logs idênticos consecutivos. Isso economiza armazenamento e processamento, mas pode confundir casos de uso de SIEM se valores de contagem, frequência ou comportamento de burst precisarem ser avaliados. A função afeta o Log Viewer, Sophos Central e servidores Syslog externos.

Antes de um lançamento produtivo de SIEM, deve-se definir:

• Quais eventos de firewall podem ser suprimidos?
• Quais regras de detecção precisam de cada conexão individual?
• O SIEM trabalha com valores de contagem ou apenas com eventos individuais?
• Como é documentado que a supressão de logs está ativa?

Active Threat Response

Logs de Active Threat Response são especialmente úteis quando Threat Feeds, NDR Essentials ou feeds externos são usados. A Sophos distingue diferentes tipos de correspondência, por exemplo, acertos de destino para tráfego de saída e acertos de origem para tráfego de entrada.

Importante: A correspondência de fonte remota para tráfego de entrada não está automaticamente ativa. Se o tráfego WAF ou DNAT for monitorado contra Threat Feeds, essa visibilidade deve ser verificada conscientemente. Caso contrário, faltam exatamente os acertos de entrada que um SOC geralmente espera.

Logs de Wireless

Logs de Wireless não são automaticamente visíveis no Log Viewer local. Logs de Access Point e SSID devem ser enviados especificamente para o Sophos Central ou Syslog e verificados separadamente no sistema de destino, se eventos de Wireless forem relevantes para operação, suporte ou conformidade.

Ambientes com múltiplos firewalls

Em ambientes com múltiplos firewalls, cada evento deve poder ser atribuído claramente a um dispositivo. Para isso, nome do host, número de série, modelo e outros campos são relevantes. O guia SFOS-Syslog descreve, entre outros, campos como device_name, device_model e device_serial_id.

Recomendações práticas:

• Definir claramente o nome do host do firewall.
• Considerar local ou função no nome do host.
• Definir uma estratégia uniforme de Facility ou tagging.
• Verificar no SIEM se os eventos podem ser filtrados por firewall, local e cluster.
• Distinguir claramente entre clusters HA e firewalls standalone.

Especialmente após uma troca de hardware ou restauração, essa atribuição é importante. Caso contrário, os eventos no SIEM podem parecer sistemas novos ou duplicados.

Testar configuração

Após salvar, a conexão deve ser testada conscientemente. Um sistema de destino verde por si só não prova que os logs corretos com os campos corretos estão chegando.

Pontos de teste:

1. No firewall, abra System services > Log settings.
2. Certifique-se de que o servidor Syslog está visível.
3. Para um tipo de log inofensivo, ative o Syslog para teste.
4. Acione uma ação definida, por exemplo, uma regra de firewall registrada ou um acesso de teste.
5. Verifique no sistema de destino se o evento chega.
6. Verifique campos como tempo, nome do host, device_name, origem, destino, ID da regra, ação e tipo de log.
7. Verifique carimbos de tempo e fuso horário no SIEM.

Para testes de regras, Testar regra do firewall com Log Viewer, Policy Test e Packet Capture é útil. Se nenhum evento for gerado, a causa geralmente não está no transporte Syslog, mas no logging desativado na regra ou no tipo de log incorreto.

Operação e monitoramento

Uma conexão Syslog não é uma configuração única. A operação deve ser monitorada e verificada regularmente.

Pelo menos estes pontos devem ser documentados:

• Quem é o proprietário da plataforma de logs?
• Quais firewalls enviam logs?
• Quais tipos de log são enviados?
• Qual é a duração do armazenamento?
• Quais parsers, painéis e alertas estão vinculados a isso?
• Como se reconhece que nenhum log está mais chegando?
• Como as mudanças de formato após atualizações de firmware são verificadas?
• Quem avalia falsos positivos e ajusta regras de SIEM?

Após atualizações de firmware, deve-se verificar aleatoriamente se eventos importantes ainda são analisados corretamente. Isso é especialmente válido para regras de SIEM produtivas que dependem de nomes de campos, tipos de log ou formatos específicos.

Solução de problemas

Nenhum log chega ao SIEM

Primeiro, verifique o endereço IP, porta, roteamento e regras de firewall entre o Sophos Firewall e o servidor Syslog. Depois, verifique se o tipo de log correto está ativado para o servidor Syslog em System services > Log settings.

Apenas determinados eventos estão faltando

Então, geralmente o logging de módulo ou regra não está ativo. Em regras de firewall, Log firewall traffic deve estar ativado. Para eventos de Web ou SSL/TLS, a política ou regra de inspeção correspondente também deve gerar logs.

Logs chegam, mas são analisados incorretamente

Verifique o formato, a versão do parser e a versão do firmware. Se foi feita uma troca entre Standard syslog protocol e Device standard format (legacy), o parser do SIEM deve corresponder.

Syslog TLS não conecta

Verifique FQDN, certificado, Common Name, Subject Alternative Name, cadeia de certificados e porta. Se o firewall espera um nome DNS, mas o servidor Syslog foi inserido apenas por endereço IP, a verificação do certificado pode falhar. Além disso, verifique se o sistema de destino realmente aceita TLS na porta configurada.

Carimbos de tempo estão incorretos

Verifique NTP no firewall, fuso horário no SIEM e lógica do parser. Tempos incorretos tornam a correlação com logs de endpoint, servidor ou identidade pouco confiável.

Muitos logs ou muito ruído

Não desative tudo imediatamente. Primeiro, verifique quais tipos de log são realmente necessários, quais regras estão gerando logs desnecessariamente e se a supressão de logs é sensata. Depois, reduza de forma direcionada.

Lista de verificação

• O servidor Syslog ou SIEM é acessível.
• Transporte, porta e criptografia estão definidos.
• O formato corresponde ao parser do SIEM.
• A estratégia de Facility está documentada.
• Tipos de log relevantes estão ativados em System services > Log settings.
• Regras de firewall importantes têm Log firewall traffic ativo.
• Regras de inspeção SSL/TLS geram logs próprios, se necessário.
• A supressão de logs é avaliada e documentada conscientemente.
• Os tipos de correspondência de Active Threat Response correspondem aos casos de uso de SIEM.
• Proteção de dados, acesso e duração de armazenamento estão esclarecidos.
• Firewall piloto, eventos de teste e parser do SIEM foram validados.
• Eventos de teste chegam ao sistema de destino.
• Campos como nome do host, device_name, origem, destino, ação e ID da regra são reconhecidos corretamente.
• Carimbos de tempo e fuso horário estão corretos.
• O monitoramento detecta quando nenhum log está mais chegando.
• Após atualizações de firmware, a função do parser é verificada.

FAQ