Syslogs are not showing up

[Dmitry Lev Ari]

Hey all,

I have installed a new wazuh instance for testing before going production, i configured the syslog settings as follows:

  <remote>
    <connection>syslog</connection>
    <port>514</port>
    <protocol>tcp,udp</protocol>
    <allowed-ips>my network ip/24</allowed-ips>
    <local_ip>wazuh ip</local_ip>
  </remote>.

From pfSense i configured Syslog forward to "wazuh ip" and nothing, no events whatsoever. I tested from the pfsense machine with "nc -zv" and from my main windows machine with telnet and wazuh is accepting at port 514. 

Wazuh version - v4.3.0

used the OVA image from website.

what have I missed?

Thanks 

[Mariano Koremblum]

Hi Skrymor,

Do you have an example log of pfSense that the manager should receive?

I will be waiting for your answer,

Mariano Koremblum

[Adam Pielak]

You should have WARN in ossec.log :

wazuh-remoted: WARNING: (9002): Only secure connection supports TCP and UDP at the same time. Default value (TCP) will be used.

So separate protocol:

  <remote>
      <connection>syslog</connection>
      <port>514</port>

      <protocol>udp</protocol>
      <allowed-ips>0.0.0.0/0</allowed-ips>
  </remote>

  <remote>
      <connection>syslog</connection>
      <port>514</port>

      <protocol>tcp</protocol>
      <allowed-ips>0.0.0.0/0</allowed-ips>
  </remote>

[Dmitry Lev Ari]

Thanks for the answers guys:

@mariano - right now nothing is arriving so I am unsure what logs but from what i see at pfsense:

Example:
2022-05-12 23:00:42.817089+00:00
sshguard
42707
Attack from "myip" on service unknown service with danger 10.
2022-05-12 23:00:42.817362+00:00
sshguard
42707
Blocking " myip " for 240 secs (3 attacks in 1 secs, after 2 abuses over 1163 secs.)
2022-05-12 23:05:07.876983+00:00
sshguard
42707
myip  : unblocking after 265 secs
2022-05-13 09:53:36.319781+00:00
php-fpm
360
/index.php: Successful login for user 'admin' from:  myip   (Local Database)

end of example.

Now this is from within Syslog of pfsense and from its gui so its already formatted for the GUI.

@kleszczka - 

Added one for tcp and one for udp and still nothing.

here is the current configuration:

 <remote>
    <connection>secure</connection>
    <port>1514</port>
    <protocol>tcp</protocol>
    <queue_size>131072</queue_size>

  </remote>
 
  <remote>
    <connection>syslog</connection>
    <port>514</port>
    <protocol>tcp</protocol>
    <allowed-ips>0.0.0.0/0</allowed-ips>

    <local_ip>mywazuhip</local_ip>

  </remote>
 
  <remote>
    <connection>syslog</connection>
    <port>514</port>
    <protocol>udp</protocol>
    <allowed-ips>0.0.0.0/0</allowed-ips>

    <local_ip> mywazuhip </local_ip>
  </remote>

My current network has 3 devices that try to send syslogs ( pfsense and x2 hp switches )

and 4 agents with OSSEM client that all work good and send logs.

Thanks

[Mariano Koremblum]

Hi again!

First of all, Kleszczka, thanks for collaborating with our community!

Let’s try the following. Could you please enable the logall_json option on your manager’s ossec.conf file and then reset your manager?

In case you can, then check on your /var/ossec/logs/ossec.log file that your manager is actually listening to the ports you’ve set. To check that, you could try doing:

# cat /var/ossec/logs/ossec.log | grep 514
2022/05/13 13:40:59 wazuh-remoted: INFO: Started (pid: 10973). Listening on port 514/UDP (syslog).
2022/05/13 13:40:59 wazuh-remoted: INFO: Started (pid: 10972). Listening on port 514/TCP (syslog).

And you should see an output similar to the previous one. Take into account that, if you have restarted multiple times your manager with a similar configuration, such messages can appear many times, please check that the last ones are actually new ones (not old logs).

In case of everything looks well, you can now check If your manager is actually receiving the messages by sending a remote log (you would need to use another endpoint to send such logs). This can be done by doing the following:

• Remote terminal

  # echo "TESTING-REMOTE-SYSLOG" | nc -w 0 YOUR_WAZUH_MANAGER_IP 514
  

• Manager’s terminal

  # cat /var/ossec/logs/archives/archives.json | grep "TESTING-REMOTE-SYSLOG"
  {"timestamp":"2022-05-13T13:47:04.005+0000","agent":{"id":"000","name":"10-u20-manager"},"manager":{"name":"10-u20-manager"},"id":"1652449624.98890","full_log":"TESTING-REMOTE-SYSLOG","decoder":{},"location":"192.168.10.1"}
  

  If everything works correctly, it should print on your manager’s terminal a similar output as the previous one.

Please, let us know how it goes, so we can continue analyzing the problem!

I will be waiting for your reply,

Mariano Koremblum

​

[Dmitry Lev Ari]

Hey  Mariano ,

Here is my results from all testing:

ossec.log | grep 514:

2022/05/13 09:48:05 wazuh-remoted: INFO: Started (pid: 11529). Listening on port 514/TCP (syslog).
2022/05/13 09:48:05 wazuh-remoted: INFO: Started (pid: 11528). Listening on port 1514/TCP (secure).
2022/05/13 09:48:05 wazuh-remoted: INFO: Started (pid: 11530). Listening on port 514/UDP (syslog).

Remote terminal i ran the command.

at managers terminal when doing the grep "testing-remote-syslog" nothing comes up:

[root@wazuh-server ~]# cat /var/ossec/logs/archives/archives.json | grep "TESTING-REMOTE-SYSLOG"
[root@wazuh-server ~]#

Again thanks for the help.

[Mariano Koremblum]

Ok, from the remote terminal, now please do the following:

# nmap -p 514 YOUR_WAZUH_MANAGER_IP

It should show something like the following:

PORT     STATE SERVICE
514/tcp open  upnp

If not, if it says “filtered” instead of “open” then probably you are having a firewall issue.

I will be waiting for your reply,

Mariano Koremblum

​

[Dmitry Lev Ari]

Hey,

Seems like its open:

Some more information that maybe can assist, all agents are at same vlan as well the ones that send syslogs.

its all hosted on esxi with allowed syslogs:

Thanks

[Mariano Koremblum]

Dmitry, just to be sure, this remote terminal is indeed not in the same manager's device, right?

[Dmitry Lev Ari]

Hey,

That's correct,

The IP of the manager is x.x.x.115

the IP of the remote device "sqlserver" is x.x.x.129

Both are on the same vlan.

Thanks

[Mariano Koremblum]

Hi Dmitry,

What is the output you get when you perform the netcat command?:

echo "TESTING-REMOTE-SYSLOG" | nc -w 0 YOUR_WAZUH_MANAGER_IP 514

I will be waiting for your reply

​

[Dmitry Lev Ari]

Hey mariano,

Here is the results:

[root@wazuh-server ~]# cat /var/ossec/logs/archives/archives.json | grep "TESTING-REMOTE-SYSLOG"

{"timestamp":"2022-05-16T18:33:10.438+0000","agent":{"id":"000","name":"wazuh-server"},"manager":{"name":"wazuh-server"},"id":"1652725990.76797","full_log":"TESTING-REMOTE-SYSLOG","decoder":{},"location":"myremoteserver"}

seems like it did pass.

[Mariano Koremblum]

Hi Dmitry,

So it seems that Wazuh's remote Syslog messages reception is working correctly. Don't you get to see any pfSense message on the archives?

Please, let us know

[Dmitry Lev Ari]

Hey, i do see them on archives but nothing at events on wazuh, do i need a decoder/rule for this?

[Mariano Koremblum]

Dmitry,

On the archives every single log that arrives at the manager is stored, no matter if it produces an alert or not. If such a log produces an alert, after being decoded and matched against the rules, then it is stored on the alerts files and then indexed and displayed on the Wazuh dashboard.

In your case, you are indeed receiving the logs on your manager but these logs are not producing any alert, probably because of a lack of decoders and rules for such logs.

To make your own custom rules and decoders I would strongly recommend you to read the following links:

• https://documentation.wazuh.com/current/user-manual/ruleset/getting-started.html
• https://wazuh.com/blog/creating-decoders-and-rules-from-scratch/
• https://documentation.wazuh.com/current/user-manual/ruleset/custom.html
• https://documentation.wazuh.com/current/user-manual/ruleset/testing.html

If you still need help with creating the rules and decoders you can always ask for our assistance,

Best Regards,

Mariano Koremblum

​

[Mariano Koremblum]

PS: If you do not need the "logall" options anymore, I encourage you to disable them (on your manager's `ossec.conf` file), and then restart your manager. Such an option is good for debugging but it may take a lot of disk space as it stores every single log.

Best regards,

Mariano Koremblum

[Dmitry Lev Ari]

Thanks mariano, Trying to figure out how-to create decoders and alerts as we speak.

[Mariano Koremblum]

If you have any example log, from which you want to generate an alert, I can help you out to create a decoder and a rule for it.

Best Regards,