Envie Sophos Firewall Syslog com segurança para SIEM

Com Syslog, um Sophos Firewall pode enviar eventos para um servidor de log externo, um SIEM ou uma plataforma de segurança. Isto é particularmente importante se os registos forem retidos por longos períodos de tempo, pesquisados ​​centralmente, correlacionados com outros sistemas ou utilizados para auditorias e resposta a incidentes.

O Visualizador de logs local é bom para análises rápidas diretamente no firewall. Central Firewall Reporting é conveniente ao usar Sophos Central como plataforma de relatórios. O Syslog, por outro lado, é a melhor escolha se você tiver seu próprio SIEM, um SOC, um processo de detecção gerenciado ou uma arquitetura de log entre fabricantes.

Qual artigo de registro se encaixa?

O logon no Sophos Firewall consiste em vários níveis. Dependendo da pergunta, Syslog nem sempre é a melhor forma de começar:

• Analise conexão única, Rule ID ou decisão web/IPS ao vivo: Sophos Firewall Teste de regra com Log Viewer, testador de política e Packet Capture
• Atribuir arquivos de log e serviços locais: Solução de problemas de Sophos Firewall: Services e registros
• Fazer backup de logs para suporte ou análise externa: Sophos Firewall Fazer backup de logs para suporte e análise
• Acompanhe alterações de configuração e ações administrativas: Sophos Firewall Verificar registros de trilha de auditoria
• Use relatórios baseados no Sophos Central em vários firewalls: Sophos Firewall Ativar e operar o Relatório Central
• Enviar logs de longo prazo para SIEM, SOC ou servidor de log: Este artigo
• Analise fluxos de tráfego em vez de eventos individuais de firewall: Configurar monitoramento sFlow em Sophos Firewall
• Verifique o status do hardware e da interface por meio de monitoramento: Sophos Firewall Configuração de monitoramento de hardware SNMP

Isso mantém a avaliação limpa: o Log Viewer responde ao pacote atual ou caso de política, os logs locais ajudam com diagnósticos mais profundos do módulo, o relatório central é conveniente para avaliações Sophos e o Syslog fornece a camada externa de longo prazo e SIEM.

Quando Syslog faz sentido

Syslog não vale a pena apenas para ambientes grandes. Mesmo com alguns firewalls, um servidor de log central pode ajudar a reter eventos por mais tempo e independentemente 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 SIEM para ataques, varreduras de portas, logins VPN, eventos WAF ou ocorrências de feed de ameaças
• avaliação externa por SOC, MDR ou equipes de segurança interna
• Rastreabilidade após atualizações de firmware, failover, restauração ou substituição de hardware
• Análise forense quando os logs do firewall local não são mais suficientes

Os logs locais continuam importantes para casos de solução de problemas graves. Qual arquivo de log local pertence a qual módulo de firewall pode ser encontrado em Sophos Firewall Solução de problemas: Services e registros. Se você deseja fazer backup de logs para suporte ou análise externa, Sophos Firewall Fazer backup de logs para suporte e análise é adequado.

Syslog, Central Reporting ou logs locais?

Os três caminhos respondem a perguntas diferentes. Na prática, vários deles são frequentemente usados em paralelo.

• Log viewer: análise rápida em direto na firewall, mas sem arquitetura central de longo prazo.
• Ficheiros de log locais: análise detalhada via Advanced Shell ou caso de suporte, mas dependente do estado e do armazenamento da firewall.
• Central Firewall Reporting: relatórios Sophos Central e visão simples de várias firewalls, mas ligados ao Sophos Central, à licença e aos limites de armazenamento.
• Syslog / SIEM: retenção própria, correlação, deteção e auditoria. Para isso são necessários parsers, operação, monitorização e casos de uso claros.

Syslog não substitui, portanto, o Log Viewer. Complementa-o. O Log Viewer mostra rapidamente que regra ou módulo tomou a decisão. Syslog garante que esta informação permanece disponível externamente mais tarde.

Requisitos

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

• O servidor Syslog ou SIEM está acessível.
• O IP de destino ou FQDN está estável e documentado.
• O porto e o transporte são fixos, muitas vezes UDP 514 ou TLS no seu próprio porto.
• O firewall pode rotear e alcançar o servidor Syslog.
• Existe um analisador adequado ou pelo menos um armazenamento de dados brutos no sistema de destino.
• O NTP funciona em firewall e plataforma de destino.
• O período de conservação e os requisitos de proteção de dados são definidos.
• Está claro quais tipos de log são realmente necessários.

Para destinos SIEM externos ou baseados em nuvem, atenção especial deve ser dada à criptografia de transporte, IP de origem, roteamento, DNS e verificação de certificado. Alguns fornecedores de SIEM ou MDR esperam deliberadamente o Syslog não criptografado para um coletor ou sensor local que então encaminha os dados. Então a rota não criptografada deve ser curta, segmentada internamente e documentada.

Esclareça a proteção, armazenamento e responsabilidade de dados

Syslog não é apenas um redirecionamento técnico. Os logs do firewall podem conter endereços IP internos, nomes de usuário, sistemas de destino, URLs, categorias, logins VPN, eventos administrativos e ocorrências de segurança. Portanto, antes da conexão produtiva, deve ficar claro quem tem permissão para ver esses dados e por quanto tempo eles ficarão armazenados.

Esclareça antes do lançamento:

• Armazenamento: Por quanto tempo os registros operacionais, de auditoria ou de resposta a incidentes devem permanecer disponíveis?
• Acesso: Quais pessoas ou equipes podem ver logs brutos, consultas de pesquisa e painéis?
• Proteção de dados: Os registros contêm informações pessoais, IDs de usuário, endereços IP de origem ou URLs?
• Capacidade multicliente: Os locais, clientes, locatários ou clusters HA estão claramente separados no SIEM?
• Custo: Os volumes de log, EPS, armazenamento ou consultas de pesquisa são cobrados pelo provedor SIEM?
• Alerta: Quem responde aos alarmes e em que prazo?
• Exclusão: Como os logs antigos são removidos após o período de retenção expirar?

Esta responsabilidade não deve ser deixada em aberto, especialmente com os modelos MSP, SOC ou MDR. Um SIEM sem um proprietário claro produz dados, mas nenhuma resposta confiável.

Planeje a implementação em fases

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

Um processo sensato:1. Primeiro, um firewall piloto é selecionado. 2. O nome do host, a fonte de horário, a versão do firmware e o formato do log são documentados. 3. O destino Syslog está configurado com transporte seguro. 4. Começa com alguns tipos de log, por exemplo firewall, eventos e VPN. 5. Os eventos de teste definidos são gerados e verificados no sistema de destino. 6. Analisador, campos, carimbo de data/hora, fuso horário e device_name são validados. 7. O volume e o ruído dos registros são observados durante alguns dias. 8. Tipos de log adicionais, como IPS, Web, WAF, resposta ativa a ameaças ou integridade do sistema, são então adicionados. 9. Somente após um piloto bem-sucedido é que ele será implementado em outros firewalls.

Se você tiver vários firewalls, não deve apenas verificar se os dados estão chegando. O que é importante é se cada evento está atribuído ao local, dispositivo, nó HA, cliente ou locatário correto.

O piloto deve conter pelo menos um evento operacional normal, um evento de segurança e um evento de erro. Caso contrário, o transporte parece saudável, mas os campos importantes posteriores só faltam em caso de emergência.

Adicionar servidor Syslog

A configuração ocorre na interface web Sophos Firewall.

1. Abra System services > Log settings.
2. Selecione Adicionar.
3. Atribua um nome exclusivo, por exemplo siem-primary ou syslog-soc.
4. Insira endereço IP/domínio do servidor Syslog.
5. Defina Porta para corresponder ao sistema de destino.
6. Escolha Instalações conscientemente.
7. Defina Nível de gravidade.
8. Selecione Formato.
9. Opcionalmente, ative Secure log transmission se o destino suportar TLS.
10. Salve.

Sophos Firewall pode configurar vários servidores Syslog externos. A documentação atual fornece até cinco servidores Syslog. No entanto, você não deve conectar todos os objetivos aleatoriamente, mas sim determinar o propósito por trás de cada objetivo.

Se você tiver vários destinos, deverá separar conscientemente a seleção de log para cada destino. Um servidor de log local pode precisar de todos os logs de firewall e VPN, enquanto um coletor MDR espera apenas tipos de log relevantes para a segurança. Se todos os alvos receberem cegamente os mesmos dados, os custos, o risco de privacidade e o ruído do analisador aumentarão.

Configurações importantes

Instalação

O recurso ajuda o servidor Syslog a distinguir fontes ou categorias de log. Em ambientes simples, um valor padrão geralmente é suficiente. Em ambientes maiores, pode fazer sentido separar firewalls ou grupos de locais usando valores diferentes de LOCAL0 a LOCAL7.

É importante ressaltar que as regras, analisadores e documentação do SIEM usam a mesma lógica. Se cada firewall usar um recurso diferente, a avaliação se tornará desnecessariamente difícil.

Nível de gravidade

A gravidade determina a gravidade com que os logs são enviados. Para fins de segurança e solução de problemas, um limite muito alto é perigoso porque informações importantes ou eventos de aviso podem ser perdidos. No entanto, para ambientes muito barulhentos, um limite muito baixo pode gerar uma quantidade desnecessária de ruído.

Geralmente faz sentido ter um piloto com uma seleção mais ampla de registros e, em seguida, uma redução consciente com base em ocorrências reais e casos de uso do SIEM.

O limite deve ser entendido como gravidade mínima. Por exemplo, se Error for selecionado, a firewall também envia mensagens mais críticas como Critical, Alert e Emergency, mas não eventos informativos normais. Para muitos casos de uso SIEM, os eventos Information e Notice são importantes, porque logins VPN, eventos de regras ou estados do sistema podem estar ausentes de outra forma.

formato

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

• Protocolo syslog padrão
• Formato padrão do dispositivo (legado)

Para novas integrações, você deve primeiro verificar qual formato o sistema de destino ou o analisador existente espera. Se um SIEM já tiver um analisador de firewall Sophos, sua expectativa terá precedência. Uma mudança de formato após a entrada em operaçã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 fazer isso, o sistema de destino deve aceitar TLS na porta configurada, entregar um certificado de servidor adequado e usar uma cadeia de certificados na qual o firewall confie. Antes de entrar no ar, você não deve apenas verificar o firewall, mas também o nome do certificado, a cadeia de confiança, a porta, o analisador e o processo de renovação do destino Syslog.

O UDP pode ser tecnicamente suficiente para laboratórios internos. No entanto, Syslog não criptografado em redes inseguras não é uma boa base para conexões SIEM ou SOC produtivas porque 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. Sem o modo de conformidade LINCE ativo, a Sophos Firewall verifica o Common Name do certificado em relação ao domínio do servidor Syslog; neste caso padrão, o Subject Alternative Name não é usado como substituto. Com LINCE ativo, o Common Name ou o Subject Alternative Name pode corresponder. Se for inserido um endereço IP na firewall, mas o certificado contiver apenas um nome DNS, ou se um certificado só corresponder por SAN, a ligação pode falhar consoante o modo. Para destinos TLS Syslog produtivos, planeie um FQDN estável, um certificado de servidor correspondente e um processo documentado de renovação de certificados.

Ao mesmo tempo, o sistema alvo deve realmente compreender o procedimento escolhido. Algumas integrações SIEM requerem um coletor local e não oferecem suporte direto ao firewall Secure log transmission. Então, a melhor solução geralmente é: o firewall envia internamente para o coletor, o coletor criptografa ainda mais para a nuvem ou plataforma SOC. Esta arquitetura deve ser incluída no documento operacional, caso contrário será posteriormente assumido incorretamente que todas as seções da rota estão criptografadas.

Selecione os tipos de log

Depois de adicionar o servidor Syslog, o trabalho não foi concluído. Você deve especificar em System services > Log settings quais tipos de log serão enviados para este destino.

Importante: uma regra de firewall só cria logs de tráfego significativos se Log firewall traffic estiver ativo na regra. Para SSL/TLS Inspection, Log connections também deve estar ativo na regra de inspeção adequada. A seleção de logs em Log settings determina depois se estes logs são enviados localmente, para Sophos Central ou para servidores Syslog.

Tipos de log típicos para um SIEM:

• Firewall: conexões permitidas e rejeitadas, correspondência de regras, eventos DoS
• IPS: Ataques detectados ou bloqueados
• Filtragem de Web/Conteúdo: Tráfego da Web, categorias, eventos de política da Web
• Inspeção SSL/TLS: Decisões e erros de inspeção TLS
• Proteção de servidor web: Eventos WAF para serviços publicados
• Autenticação/Eventos: Eventos de administrador, usuário e sistema
• VPN: Eventos de acesso remoto e site a site VPN
• Resposta ativa a ameaças: Acessos de feeds de ameaças MDR, NDR Essentials, Sophos X-Ops e feeds de ameaças de terceiros
• Saúde do sistema: CPU, memória, usuários, interfaces e partições

Se DoS ou eventos de falsificação forem avaliados, o próprio fortalecimento técnico também deverá ser testado. O processo está em Sophos Firewall Verifique as configurações de Spoof Protection e DoS.

Se Feeds de ameaças de terceiros, NDR e Active Threat Response ou WAF forem usados, o SIEM deverá avaliar especificamente esses eventos. Apenas enviar logs não é suficiente. Requer consultas de pesquisa, alarmes, responsabilidades claras e ajuste contra alarmes falsos.

Verificar conscientemente os campos do parser

Os eventos Syslog Sophos contêm campos diferentes conforme o tipo de log. Para parsers e dashboards, log_id, log_type, log_component, log_subtype, severity, status, device_name, device_model, device_serial_id, fw_rule_id, fw_rule_name, nat_rule_id, src_ip, dst_ip, user_name e timestamps são especialmente relevantes.

log_id é mais do que um número aleatório. O ID é composto por tipo de log, componente, subtipo, severity e Message ID. Isto ajuda quando um SIEM deve criar regras de deteção, dashboards ou normalizações estáveis em vez de apenas pesquisar texto livre.

Na aceitação, não basta verificar se chegam dados raw. O ponto decisivo é se os campos chegam realmente como campos separados no SIEM. Se fw_rule_id ou nat_rule_id ficarem apenas no texto raw, pesquisas e alarmes posteriores funcionam muitas vezes pior do que o esperado.

Um evento firewall anonimizado pode ter, em formato raw, este aspeto:

date=2026-07-01 time=14:23:11 log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" status="Allow" device_name="SFOS-XGS" device_serial_id="C00000000000000" 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" dst_port="443" user_name="AVANET\\test.user"

O exemplo não substitui a referência oficial de campos. Mostra, porém, que informações devem estar visíveis como campos separados durante o teste do parser.

Conjunto inicial típico para piloto SIEM

Para um piloto, um conjunto inicial pequeno e deliberado é melhor do que uma ativação completa sem avaliação.

• Iniciar: Firewall, Eventos, VPN. Verifique o nível de ruído, eventos de regras, administrador e visibilidade do VPN
• Segurança: IPS, Web, proteção de servidor Web, resposta ativa a ameaças. Validar casos de uso de segurança e campos de analisador
• Operação: Integridade do sistema, DHCP, DNS, Autenticação. Adicionar contexto operacional e de identidade
• Ajuste fino: módulos adicionais conforme necessário. ativar somente se houver finalidade de busca, alarme ou auditoria

Após cada fase, deve-se verificar se o SIEM reconhece os campos corretamente e se alguém está realmente utilizando os novos eventos. Os tipos de log não verificados não agregam valor, apenas volume adicional.

Armadilhas de visibilidade importantes

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

Registro de regras e módulos

As regras de firewall e as regras de inspeção SSL/TLS devem gerar o registro em log. Em System services > Log settings você pode escolher se esses logs serão enviados localmente, em Sophos Central ou para o servidor Syslog. Se uma regra de firewall não tiver Registrar tráfego de firewall, o servidor Syslog não poderá 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 registo de tráfego. Caso contrário, você poderá ver menos eventos de filtragem da Web ou de conteúdo no SIEM do que o esperado.

Supressão de log

Sophos Firewall pode suprimir várias entradas de log consecutivas idênticas. Isso economiza memória e processamento, mas pode ser confuso em casos de uso de SIEM quando valores de contagem, frequência ou comportamento de burst precisam ser avaliados. A função funciona em servidores Log Viewer, Sophos Central e Syslog externos.

Antes de uma implementação produtiva do SIEM, você deve, portanto, determinar:

• Quais eventos de firewall podem ser suprimidos?
• De quais regras de detecção cada conexão individual precisa?
• O SIEM funciona com valores contados ou apenas com eventos individuais?
• Como é documentado que a supressão de log está ativa?

Active Threat Response

Os logs de resposta ativa a ameaças são particularmente úteis ao usar feeds de ameaças, NDR Essentials ou feeds externos. A Sophos diferencia diferentes tipos de correspondência, por exemplo, resultados de destino para tráfego de saída e resultados de origem para tráfego de entrada.

Importante: o Remote Source Match para tráfego de entrada não é ativado automaticamente. Se o tráfego WAF ou DNAT for monitorado contra feeds de ameaças, essa visibilidade deverá ser verificada conscientemente. Caso contrário, os acessos recebidos que um SOC frequentemente espera estarão ausentes.

Registros sem fio

Os registros sem fio não são automaticamente visíveis no Log Viewer local. Os logs de ponto de acesso e SSID devem ser enviados especificamente para Sophos Central ou Syslog e examinados separadamente no sistema de destino se os eventos sem fio forem relevantes para operações, suporte ou conformidade.

Ambientes multi-firewall

Em ambientes com vários firewalls, cada evento deve ser atribuído exclusivamente a um dispositivo. Nome do host, número de série, modelo e outros campos são relevantes para isso. Dependendo do tipo de log, campos como device_name, device_model e device_serial_id podem aparecer em eventos Syslog. O SIEM não deve apenas armazenar esses campos, mas também torná-los utilizáveis ​​para filtros, painéis e alarmes.

Recomendações práticas:

• Defina o nome do host do firewall de forma limpa.
• Considere a localização ou função no nome do host.
• Definir uma instalação uniforme ou estratégia de etiquetagem.
• No SIEM verifique se os eventos podem ser filtrados por firewall, localização e cluster.
• Distinguir claramente entre clusters HA e firewalls independentes.

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

Para clusters HA, também deve ser testado como os eventos aparecem após um failover. O que importa é se as operações e o SOC continuam a reconhecer o mesmo local ou se um nome de host, número de série ou novo ativo diferente aparece repentinamente no SIEM.

Configuração de teste

Depois de salvar, a conexão deve ser testada deliberadamente. Um sistema de destino verde por si só não prova que os logs corretos com os campos corretos chegam.

Pontos de teste:

1. Abra System services > Log settings no firewall.
2. Certifique-se de que o servidor Syslog esteja visível.
3. Para um tipo de log seguro, ative Syslog como teste.
4. Acione uma ação definida, por exemplo, uma regra de firewall registrada ou teste de acesso.
5. Verifique no sistema de destino se o evento chega.
6. Verifique campos como hora, nome do host, device_name, origem, destino, Rule ID, ação e tipo de log.
7. Verifique a data e o fuso horário no SIEM.
8. Em eventos firewall, verificar se fw_rule_id, fw_rule_name, nat_rule_id, src_ip, dst_ip, status e log_occurrence são pesquisáveis separadamente.

Para testes de regras, Testar regra de firewall com Log Viewer, Policy Test e Packet Capture é útil. Se nenhum evento ocorrer, a causa geralmente não é o transporte Syslog, mas sim o log desativado como regra ou o tipo de log errado.

Eventos de teste significativos

Um bom teste de aceitação cria não um log qualquer, mas exatamente os eventos que serão pesquisados posteriormente.

• A regra de teste registrada permite uma conexão: Origem, Destino, Serviço, Ação, Rule ID e Firewall claramente visíveis
• Acertos de regra de eliminação definidos: Evento de queda aparece com direção e horário corretos
• Usuário VPN conecta e desconecta: Usuário, tipo de túnel, horário e firewall são detectados
• Política da Web ou Evento de Teste IPS: O tipo, categoria ou assinatura do log foi resolvido corretamente pelo analisador
• ATR ou teste de ameaça, se disponível: Hit aparece no caso de uso esperado e não gera alarme falso
• HA teste de failover ou restauração, se planejado: Os eventos permanecem atribuídos de forma rastreável ao local, cluster e dispositivo. Para regras SIEM produtivas, você também deve documentar um resultado de teste negativo: O que acontece se um evento esperado não ocorrer? Só então ficará aparente se um analisador, coletor ou tipo de log falhou silenciosamente.

Operações e monitoramento

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

Pelo menos estes pontos devem ser documentados:

• Quem é o proprietário da plataforma de log?
• Quais firewalls enviam logs?
• Quais tipos de log são enviados?
• Qual período de retenção se aplica?
• Quais analisadores, painéis e alarmes estão anexados a ele?
• Como você reconhece que os logs não chegam mais?
• Como são verificadas as alterações de formato após as atualizações de firmware?
• Como são monitoradas as expirações de certificados, as atualizações do coletor e as alterações do analisador?
• Quem avalia os falsos positivos e ajusta as regras SIEM?

Após as atualizações de firmware, verificações aleatórias devem ser feitas para verificar se eventos importantes ainda estão sendo analisados ​​corretamente. Isso é especialmente verdadeiro para regras SIEM produtivas que dependem de nomes de campos, tipos ou formatos de log específicos.

Detetar falha silenciosa de logs

Para a operação deve existir um indicador simples de falha:

• Por firewall: definir o número mínimo esperado de eventos por período, por exemplo eventos Firewall ou System.
• Por tipo de log importante: verificar se Firewall, VPN, Web, IPS ou Active threat response continuam a fornecer eventos regularmente.
• Por parser: monitorizar se campos centrais como device_name, Source, Destination, Action e Rule ID continuam preenchidos.
• Por collector: detetar se um collector local deixa de aceitar dados ou deixa de os encaminhar.
• Após alterações: usar atualização de firmware, atualização de parser, troca de certificado, restore de firewall e failover HA como motivo para novo teste de aceitação.

Uma boa operação SIEM não alerta apenas para eventos suspeitos, mas também para eventos em falta. Se uma firewall produtiva deixar subitamente de enviar logs, isso também é um evento operacional.

Solução de problemas

Nenhum registro chega no SIEM

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

Se o servidor Syslog estiver acessível por meio de um túnel VPN ou de uma rede de gerenciamento separada, verifique também a rota, a política SD-WAN, o NAT de origem e o firewall do contador. Da perspectiva Sophos Firewall, Syslog é tráfego de saída normal; ele deve realmente chegar ao coletor.

Apenas alguns eventos estão faltando

Então, o log do módulo ou da regra geralmente não fica ativo. Para regras de firewall, Registrar tráfego de firewall deve ser definido. Para eventos da Web ou SSL/TLS, o log de política ou regra de inspeção apropriado também deve ser gerado.

Os logs chegam, mas são analisados incorretamente

Verifique o formato, a versão do analisador e a versão do firmware. Se alternar entre Protocolo syslog padrão e Formato padrão do dispositivo (legado), o analisador SIEM deverá corresponder a ele.

TLS-Syslog não conecta

Verifique FQDN, certificado, Common Name, Subject Alternative Name, modo LINCE, cadeia de certificados e porta. Na maioria dos ambientes sem LINCE, o Common Name deve corresponder ao domínio configurado; um nome que só corresponde no SAN não basta. Se a firewall espera um nome DNS, mas o servidor Syslog foi inserido apenas via endereço IP, a verificação do certificado também pode falhar. Verifique também se o sistema de destino realmente aceita TLS na porta configurada.

Se um provedor SIEM não suportar diretamente Secure log transmission, não se deve tentar resgatar o analisador com formatos aleatórios. É melhor ter um coletor local suportado, um projeto de transporte diferente ou uma decisão clara sobre qual rota interna permanece não criptografada.

Os carimbos de data e hora estão incorretos

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

Muitos registros ou muito ruído

Não desative tudo imediatamente. Primeiro verifique quais tipos de log são realmente necessários, quais regras registram desnecessariamente e se a supressão de log faz sentido. Em seguida, reduza especificamente.

Lista de verificação

• O servidor Syslog ou SIEM está acessível.
• Transporte, porta e criptografia são corrigidos.
• Para TLS: FQDN, certificado, cadeia de confiança e renovação são verificados.
• O formato corresponde ao analisador SIEM.
• A estratégia da instalação está documentada.
• Os tipos de log relevantes são ativados em System services > Log settings.
• Regras de firewall importantes têm Log de tráfego de firewall ativo.
• As regras de inspeção SSL/TLS geram seus próprios logs, se necessário.
• A supressão de logs é avaliada e documentada conscientemente.
• Os tipos de correspondência de resposta a ameaças ativas correspondem aos casos de uso SIEM.
• A proteção de dados, o acesso e o período de conservação foram esclarecidos.
• Firewall piloto, eventos de teste e analisador SIEM foram validados.
• Os eventos de teste chegam ao sistema de destino.
• Campos como Hostname, device_name, Source, Destination, Action e Rule ID são reconhecidos corretamente.
• Campos importantes do parser como log_id, log_type, log_component, fw_rule_id, nat_rule_id, src_ip, dst_ip, user_name, severity e status são pesquisáveis separadamente.
• HA, o cenário de restauração ou substituição de hardware está incluído no modelo de mapeamento SIEM, se necessário.
• O carimbo de data e hora e o fuso horário estão corretos.
• O monitoramento detecta quando não chegam mais logs.
• A função do analisador é verificada após atualizações de firmware.

Perguntas frequentes