This forum is for all security enthusiasts to discuss Fortinet's latest & evolving technologies and to connect & network with peers in the cybersecurity hemisphere. Share and learn on a broad range of topics like best practices, use cases, integrations and more. For support specific questions/resources, please visit the Support Forum or the Knowledge Base.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Hi Mebin,
I have your same problem. Did you solved it?
Using a similar configuration to the one provided above by Robert and using the to_syslog_snare() directive I get as log, for example, from a Windows server:
2024-11-12T10:56:21+01:00 MYSERVER MSWinEventLog#0111#011System#0111#011Tue Nov 12 10:56:21 2024#0117036#011Service Control Manager#011N/A#011N/A#011Information#011ctx-desk.nso.local#011N/A#011#011The nxlog service entered the stopped state.#011609646
where I have #011 as TAB delimiter and FortiSIEM cannot interpret the log. It can understand that it is a Windows type Log but does not recognize the Event Type..
In the configuration above in theory the directive Exec $Message =~ s/(\t|\R)/ /g; should serve to convert the TABs and CRs to spaces, but it seems not to work, because in fact I find in the logs #011 and #015..
Did you manage to solve the problem somehow? I use CE version 3.2.2329 as an Nxlog agent.
Kind regards,
Fabio.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.