Getting network device logs into Wazuh (syslog input)

1,587 views
Skip to first unread message

Brian Candler

unread,
Dec 22, 2018, 7:12:01 AM12/22/18
to Wazuh mailing list
What's the recommended way to get network device logs into Wazuh - i.e. syslog input?

The parsing I need to do of firewall logs and other network device syslogs would very much suit Wazuh's mechanisms for defining log matching rules, and indeed it would be very helpful if both host logs and network logs could be processed through the same tool.

Would it be necessary for me to write network syslogs to a local file first, and use a Wazuh agent to pick them up and forward them?  Or is there a more direct way to ingest them?

Wazah's architecture page shows only logs coming in from Wazuh agents (AES-encrypted on UDP port 1514). Part of the diagram hints at syslog:

syslog.png

The user manual talks about syslog output, but not syslog input AFAICS.  So maybe the diagram is just showing syslog output?

Thanks,

Brian.

Santiago Bassett

unread,
Dec 22, 2018, 11:47:35 AM12/22/18
to Brian Candler, Wazuh mailing list
Hi Brian,

there are multiple options here: 

1.- Have Wazuh server syslog daemon (Rsyslog), write to a log file, and configure logcollector component to parse that file.

This option is pretty good, as it allows you to use Rsyslog templates to modify your logs format if needed. It also allows you to use Rsyslog filters to decide what you want to write to the file. 

On the other hand, this option can be expensive for the hard drive. Because it needs to write logs to a file it is actually  making use of read and write operations. This can be avoided using some other options below.

2.- Have Wazuh remote daemon (remoted) listening directly for incoming Syslog data.

You can configure a Remote daemon socket to listen for incoming Syslog data. This data will be processed and analyzed by decoders and rules too.

To do so you would need to add another configuration stanza like this:

<remote>
  <connection>syslog</connection>
  <port>1513</port>
  <allowed-ips>0.0.0.0/0</allowed-ips>
</remote>


This way you don't need to use Rsyslog, and you can have your network devices pointing directly to Remoted socket (listening on port 1513/udp in this case).

This option does not require to write/read events from a log file so it does not make use of the hard disk (saving disk resources). On the contrary it does not give you the opportunity to use custom filters or templates (which are features provided by Rsyslog).

3.- Use Wazuh server syslog daemon (Rsyslog), writing the output locally to Remoted syslog socket.

This is my preferred choice, as you can make use of all Rsyslog features and still not write events to a file. You can add a Syslog rule for example to /etc/rsyslog.d/wazuh.conf like this one:

if ($fromhost-ip == '10.10.10.1' or $fromhost-ip == '10.10.10.2') then @127.0.0.1:1513

This rule would redirect data from source IPs 10.10.10.1 and 10.10.10.2 to the local Remoted socket (filtering out everything else). In this scenario those IPs could be your network devices.

4.- Collecting Syslog using a Wazuh agent.

There is scenarios where you may want to use an agent to collect syslog data. You can do that too, using Rsyslog and redirecting the output to a file, read by the agent.

I hope it helps,

Santiago.


--
You received this message because you are subscribed to the Google Groups "Wazuh mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To post to this group, send email to wa...@googlegroups.com.
Visit this group at https://groups.google.com/group/wazuh.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/a9cfadb3-7d95-4454-b4b6-355663a3a212%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Brian Candler

unread,
Dec 22, 2018, 12:17:48 PM12/22/18
to Wazuh mailing list
That's really helpful, thank you!  The fact that remoted can be configured to accept standard, raw syslog is what I was missing.

Cheers,

Brian.
Reply all
Reply to author
Forward
Message has been deleted
0 new messages