Configure SSL/TLS for rsyslog
If you need, you can configure SSL/TLS with RSyslog for a secure communication:
How to Configure rsyslog Server to Accept Logs via SSL/TLS
Troubleshooting Syslog data collectionWe need to check if the Manager is receiving the log entries and if it is converting them in Alerts. The manager works in this way:
- The manager receives the log entry
- The log entry is evaluated against the decoders in order to know there is any decoder that can parses the log. If not, the log entry is dropped.
- If any decoder is matched, then it is evaluated against the rule set, and if it matches with any rule, the log entry is converted into an Alert, and grabbed in the alerts.json|log file.
That being said, we need to know first, if the logs are reaching the Wazuh Server, for this, a TCP dump is needed:
tcpdump -i any <protocol> -nn port 514 -AA
This command must be run in the Wazuh Manager serverIf you see packets incomming from the IP of the device sending the syslog, we need to check if the logs are being processed by the Wazuh Manager. To check this, we can enable the archives.json file, which will be populated with ALL the log entries received by the manager. To enable it, we need to modify the configurations of the ossec.conf file:
vi /var/ossec/etc/ossec.conf
<ossec_config>
<global>
...
<logall_json>yes</logall_json>
...
</global>
Then we need to restart the Wazuh Manager service:
systemctl restart wazuh-manager
After restarting the Wazuh Manager service, we should start seeing some log entries in the archives.json file:
cat /var/ossec/logs/archives/archives.json | grep '"location":"<DEVICE-IP"'
{"timestamp":"2021-07-04T20:39:03.960+0000","rule":{"level":3,"description":"syslog: Physical root login.","id":"2505","firedtimes":1,"mail":false,"groups":["syslog","access_control"],"pci_dss":["10.2.2"],"gpg13":["7.8"],"gdpr":["IV_32.2"],"hipaa":["164.312.b"],"nist_800_53":["AU.14","AC.6"],"tsc":["CC6.8","CC7.2","CC7.3"]},"agent":{"id":"012","name":"kefbir","ip":"10.10.10.90"},"manager":{"name":"theshire"},"id":"1625431143.753095","full_log":"Jul 4 20:39:03 kefbir login[424406]: ROOT LOGIN on '/dev/tty1'","predecoder":{"program_name":"login","timestamp":"Jul 4 20:39:03","hostname":"kefbir"},"decoder":{},"location":"<DEVICE-IP>"}
The key here, is to look for the IP of the device is sending the syslog, you can grep to the string '"location":"<DEVICE-IP>"'
If it is there, you will see (as in our example) the rule and decoder matching it, in our example:
"rule":{"level":3,"description":"syslog: Physical root login." ...
"decoder":{}
If no information about the decoder and/or rule, it means no decoder is matching it, and there is no rule to convert it to an alert.Creating Decoders and Rules
If the logs are arriving to archives and not the alerts file, you need to create a decoder (and a rule or set of rules) for matching the logs from your log file:
Once you created a decoder and rules for those logs, they will match the rules and will be converted into an alert and you will see this reflected in the alerts.json file:
cat /var/ossec/logs/alerts/alerts.json | grep '"location":"/tmp/test-log.log"'
Hope this helps!.