Syslog from generic network device

[Giorgio Biondi]

Hi,

I have tried to send at wazuh manager some syslog.. data is recorded in file /var/ossec/log/archives/archives.log but don't find way to search it in the GUI.

A generic syslog from (for example) router or firewall wold be recorded in database or not?

A have tried with syslog from firewall Sonicwall - follow a classic syslog record from it

2019 Feb 15 09:45:17 srv31->10.12.14.1   id=firewall sn=C0EAE4599999 time="2019-02-15 09:45:17 UTC" fw=2.228.169.242 pri=5 c=512 m=1233 msg="Unhandled link-local or multicast IPv6 packet dropped" n=56642 srcV6=fe80::9851:b780:9d9d:a29e src=:49702:X0-V514 dstV6=ff02::1:3 dst=:5355 srcMac=90:e6:ba:32:5c:45 dstMac=33:33:00:01:00:03 proto=udp/5355

Any search by any field in this record on the gui, not find anything..

All the best.

gb

[Juan Carlos]

Hello Giorgio,

The events visible in the GUI are those that generated an alert by the Wazuh Analysis Daemon.

For this to happen the incoming message must trigger a rule that has a level higher than the one you have configured as your threshold (by default this is 3).

When using the logall Wazuh will populate /var/ossec/log/archives/archives.log with every message it receives and also add to each of these information with the date, source and destination of the message.

This option is useful for debugging purposes or creating custom rules and decoders but may cause unnecessary storage usage if left enabled indefinitely.

From the line you copied I see the actual message being received by Wazuh is:

id=firewall sn=C0EAE4599999 time="2019-02-15 09:45:17 UTC" fw=2.228.169.242 pri=5 c=512 m=1233 msg="Unhandled link-local or multicast IPv6 packet dropped" n=56642 srcV6=fe80::9851:b780:9d9d:
a29e src=:49702:X0-V514 dstV6=ff02::1:3 dst=:5355 srcMac=90:e6:ba:32:5c:45 dstMac=33:33:00:01:00:03 proto=udp/5355

This message doesn't match any default rule or decoder and it doesn't follow the format of a valid syslog message ( https://tools.ietf.org/html/rfc5424#section-6.5 ).

In order to be able to analyze it new decoder would have to be created for it. More information on how to this can be found here:

https://documentation.wazuh.com/current/user-manual/ruleset/custom.html

Best Regards,

Juan Carlos Tello

Also, for normal opa

[Giorgio Biondi]

Hi Juan,

I have understand.. 

so I will never find events from my device until it triggers at least a level 3 rule .. but unfortunately it seems that Sonicwall does not follow the syslog standard .. you know what I have to do to ensure that if a syslog record arrives from Sonicwall is it stored in the database in order to find it with the GUI? Also I saw that there is a Sonicwall decoder ... it does not work?

[Giorgio Biondi]

I have tried to change 0295-sonicwall_decoders.xml (get from this page https://github.com/wazuh/wazuh-ruleset/issues/162) and after make a ossec-logtest but no better result..

[root@srv31 decoders]# /var/ossec/bin/ossec-logtest

2019/02/17 16:15:04 ossec-testrule: INFO: Started (pid: 22438).

ossec-testrule: Type one log per line.

id=firewall sn=C0EAE4599999 time="2019-02-17 16:14:45 UTC" fw=2.228.19.242 pri=5 c=0 m=1257 msg="ICMPv6 packet dropped due to policy" n=17973 srcV6=fe80::ca54:4bff:fe9b:16ac src=::X2 dstV6=ff02::1 dst=::X2 srcMac=c8:54:4b:9b:16:ac dstMac=33:33:00:00:00:01 proto=ipv6-icmp type=130 icmpCode=0 uuid="912f71d0-40ea-106f-0700-c0eae4599e78" rule="873 (WAN->MULTICAST)" note="packet not allowed by policy"

**Phase 1: Completed pre-decoding.

       full event: 'id=firewall sn=C0EAE4599999 time="2019-02-17 16:14:45 UTC" fw=2.228.19.242 pri=5 c=0 m=1257 msg="ICMPv6 packet dropped due to policy" n=17973 srcV6=fe80::ca54:4bff:fe9b:16ac src=::X2 dstV6=ff02::1 dst=::X2 srcMac=c8:54:4b:9b:16:ac dstMac=33:33:00:00:00:01 proto=ipv6-icmp type=130 icmpCode=0 uuid="912f71d0-40ea-106f-0700-c0eae4599e78" rule="873 (WAN->MULTICAST)" note="packet not allowed by policy"'

       timestamp: '(null)'

       hostname: 'tech2srv31'

       program_name: '(null)'

       log: 'id=firewall sn=C0EAE4599999 time="2019-02-17 16:14:45 UTC" fw=2.228.19.242 pri=5 c=0 m=1257 msg="ICMPv6 packet dropped due to policy" n=17973 srcV6=fe80::ca54:4bff:fe9b:16ac src=::X2 dstV6=ff02::1 dst=::X2 srcMac=c8:54:4b:9b:16:ac dstMac=33:33:00:00:00:01 proto=ipv6-icmp type=130 icmpCode=0 uuid="912f71d0-40ea-106f-0700-c0eae4599e78" rule="873 (WAN->MULTICAST)" note="packet not allowed by policy"'

**Phase 2: Completed decoding.

       No decoder matched.

[Juan Carlos]

Hello Giorgio,

It seems the syslog message from your example contains the body of a Sonicwall message but is missing the Timestamp, Hostname and Program Name.

It is possible that a program like rsyslog is being used to relay these messages and the template being used only includes the %msg% section.

You can either have the Wazuh Manager receive the messages directly from the Sonicwall device by configuring a remote syslog collection:

https://documentation.wazuh.com/current/user-manual/capabilities/log-data-collection/how-it-works.html#remote-syslog

If you're using rsyslog, have the template include the necessary components.

If you have an rsyslog template configured in /etc/rsyslog.conf make sure the template includes all parameters:

$template sonicwall,"%TIMESTAMP% %fromhost-ip% %programname%:%msg%\n"

Or not to use a template at all.

I hope this helps,

Best Regards,

Juan Carlos Tello

[Juan Carlos]

Hello Giorgio,

I hope you don't mind that I've included the google group back into the conversation so this conversation can benefit the whole community.

I was looking at the decoder currently part of the ruleset and noticed that it would decode your message if it didn't have the timezone information (even if it doesn't comply with the syslog format).

So it may be that different versions of Sonicwall will output time differently or it may some setting in the configuration.

There is a Pull Request to the wazuh-ruleset (#274 ) to further fix Sonicwall decoding, thanks to your query so I've made a further commit to it to also match messages with timezone.

While that PR is reviewed and included in future updates, instructions on the recommended procedure for changing an existing decoder can be found here:

https://documentation.wazuh.com/current/user-manual/ruleset/custom.html#changing-an-existing-decoder

A simple change to the decoder would be:

<decoder name="sonicwall">
  <type>firewall</type>
  <prematch>^id=\w+ sn=\w+ time="\.+" fw=\S+ pri=\d </prematch>
  <plugin_decoder>SonicWall_Decoder</plugin_decoder>
</decoder>

A more complete change would be using this file: https://raw.githubusercontent.com/wazuh/wazuh-ruleset/01854eec040d68b5c09de3694a2d686d0d1c809b/decoders/0295-sonicwall_decoders.xml

The previous message would still classified as one with a sonicwall status=5, which is a notice and by default isn't currently logged (it has an alert level="0").

To change this behavior you could create a custom child rule to match only a subset of these notice messages depending on your needs, or overwrite the existing rule to log all sonicwall notice messages, by adding the following to an xml file in /var/ossec/etc/rules/:

<rule id="4805" level="3" overwrite="yes">
  <if_sid>4800</if_sid>
   <status>^5</status>
  <description>SonicWall notice message.</description>
 </rule>

Best Regards,

Juan Carlos Tello

On Sun, Feb 17, 2019 at 8:36 PM Giorgio Biondi wrote:

Hi Juan,

My Sonicwall send directly log in the ip address of wazuh server. And my wazuh server have in the ossec.conf follow configuration:

 <remote>

    <connection>syslog</connection>

    <allowed-ips><IP-RANGE></allowed-ips>

    <port>514</port>

    <protocol>udp</protocol>

  </remote>

and if i put 'logall' Sonicwall log goes in the archies.log file.. 

Anyway, I have other network device: how make for view in the GUI this log?

PS: Exist a Sonicwall decoder but seems not working..

[Giorgio Biondi]

Hi Juan

wow.. with your modify, now logtest decode Sonicwall message.. I try on line and update you..

All the best.

gb

[Giorgio Biondi]

Hi Juan,

logtest work but in the GUI not find anything about my firewall but him send.. in the archives (logall ON) exist..

maybe it's me that I do not know what to look for? 

In tab 'discovery' search my serial number.. it should be there ..

:-(

[Giorgio Biondi]

Hi Juan,

i have found!!!

must search for rule.id=4801 

Work fine now..

gb 

[Juan Carlos]

Good to know :-)

I was replying on both making sure the rule was overwritten to raise the alert level and also that the GUI (Kibana) will only search for exact matches of mapped fields.

So if you want to search for something that won't match exactly a decoded field you can use asterisks around your term (for example : *33:33:00:01:00:03* )

Best Regards,

Juan Carlos Tello

[Giorgio Biondi]

Hi Juan,

thanks for your time.. 

I have another news.. Sonicwall log differ from SonicOS version: from 5.9 work fine.. but 6.5 not work.. 

Seems equal but surely isn't..

tomorrow try to understand why..

all the best.

gb

[Giorgio Biondi]

Hi,

I have get 2 syslog strin from my firewall: the firse is SonicOs 6.5 (not work) the second with 5.9 (work)

2019 Feb 18 12:27:40 tech2srv31->10.12.14.1   id=firewall sn=C0EAE4599999 time="2019-02-18 12:27:40 UTC" fw=2.228.169.242 pri=5 c=0 m=1197 msg="NAT Mapping" app=2 n=2826842 src=10.12.14.80:61560:X0-V500:TECH2SRV20 dst=8.8.8.8:53:X3:google-public-dns-a.google.com proto=udp/dns note="Source: 2.228.169.242, 37570, Destination: 8.8.8.8, 53, Protocol: 17" rule="22 (LAN->WAN)"

**Phase 1: Completed pre-decoding.

       full event: '2019 Feb 18 12:27:40 tech2srv31->10.12.14.1   id=firewall sn=C0EAE4599999 time="2019-02-18 12:27:40 UTC" fw=2.228.169.242 pri=5 c=0 m=1197 msg="NAT Mapping" app=2 n=2826842 src=10.12.14.80:61560:X0-V500:TECH2SRV20 dst=8.8.8.8:53:X3:google-public-dns-a.google.com proto=udp/dns note="Source: 2.228.169.242, 37570, Destination: 8.8.8.8, 53, Protocol: 17" rule="22 (LAN->WAN)"'

       timestamp: '2019 Feb 18 12:27:40'

       hostname: 'tech2srv31'

       program_name: '(null)'

       log: 'tech2srv31->10.12.14.1   id=firewall sn=C0EAE4599999 time="2019-02-18 12:27:40 UTC" fw=2.228.169.242 pri=5 c=0 m=1197 msg="NAT Mapping" app=2 n=2826842 src=10.12.14.80:61560:X0-V500:TECH2SRV20 dst=8.8.8.8:53:X3:google-public-dns-a.google.com proto=udp/dns note="Source: 2.228.169.242, 37570, Destination: 8.8.8.8, 53, Protocol: 17" rule="22 (LAN->WAN)"'

**Phase 2: Completed decoding.

       No decoder matched.

2019 Feb 18 11:49:35 tech2srv31->10.12.14.2 id=NSA3500BR sn=C0EAE4588888 time="2019-02-18 11:44:21 UTC" fw=172.29.169.2 pri=1 c=32 m=1388 msg="IPSec VPN Decryption Failed" n=887984144 src=37.186.204.2 dst=172.29.168.2 note="Replay check failure."

**Phase 1: Completed pre-decoding.

       full event: '2019 Feb 18 11:49:35 tech2srv31->10.12.14.2 id=NSA3500BR sn=C0EAE4588888 time="2019-02-18 11:44:21 UTC" fw=172.29.169.2 pri=1 c=32 m=1388 msg="IPSec VPN Decryption Failed" n=887984144 src=37.186.204.2 dst=172.29.168.2 note="Replay check failure."'

       timestamp: '2019 Feb 18 11:49:35'

       hostname: 'tech2srv31'

       program_name: '(null)'

       log: 'tech2srv31->10.12.14.2 id=NSA3500BR sn=C0EAE4588888 time="2019-02-18 11:44:21 UTC" fw=172.29.169.2 pri=1 c=32 m=1388 msg="IPSec VPN Decryption Failed" n=887984144 src=37.186.204.2 dst=172.29.168.2 note="Replay check failure."'

**Phase 2: Completed decoding.

       No decoder matched.

**Phase 3: Completed filtering (rules).

       Rule id: '1002'

       Level: '2'

       Description: 'Unknown problem somewhere in the system.'

[Juan Carlos]

Hi Giorgio,

When messages are logged with the logall option (into /var/ossec/archives/archives.log ) they include extra information regarding time, source and destination (2019 Feb 18 11:49:35 tech2srv31->10.12.14.2). These are not part of what is analyzed so if you are going to use /var/ossec/bin/ossec-logtest you much exclude it.

The two messages you've sent trigger rule 4801 and 4805 when I've tried them. Like this:

echo 'id=firewall sn=C0EAE4599999 time="2019-02-18 12:27:40 UTC" fw=2.228.169.242 pri=5 c=0 m=1197 msg="NAT Mapping" app=2 n=2826842 src=10.12.14.80:61560:X0-V500:TECH2SRV20 dst=8.8.8.8:53:X3:google-public-dns-a.google.com proto=udp/dns note="Source: 2.228.169.242, 37570, Destination: 8.8.8.8, 53, Protocol: 17" rule="22 (LAN->WAN)"' | /var/ossec/bin/ossec-logtest

echo 'id=NSA3500BR sn=C0EAE4588888 time="2019-02-18 11:44:21 UTC" fw=172.29.169.2 pri=1 c=32 m=1388 msg="IPSec VPN Decryption Failed" n=887984144 src=37.186.204.2 dst=172.29.168.2 note="Replay check failure."' | /var/ossec/bin/ossec-logtest

I hope this helps clarify.

Best Regards,

Juan Carlos Tello

[Giorgio Biondi]

Hi Juan,

so work fine.. thanks Juan for clarify. 

All the best..

[Giorgio Biondi]

Hi at all..

I have maked some test, and have understand it: with SonicOS SonicOS Enhanced 6.5.3.1-48n something not work.

After about 15 days (i'm busy with other work) I can say this: with SonicOS 5.9 all work fine and I see log on 'kibana->discovery' but with SonicOS 6.5 not even see event.

Should this event be registered by wazuh or not? In my opinion, yes..

Today have make trace with tcpdump (i'm wrong?) for search a solution:

[root@tech2srv31 ~]# tcpdump -i eth0 host 10.12.14.1 -n -A

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

12:55:40.574953 IP 10.12.14.1.syslog > 10.12.14.31.syslog: SYSLOG local0.notice, length: 283

E..7.0@.@.!N

...

........#p.<133>  id=NSA3600  sn=C0EAE4599999 time="2019-02-27 12:55:40 UTC" fw=2.228.169.242 pri=5 c=0 m=1197 msg="NAT Mapping" n=4748427 src=10.12.14.9::X0-V500 dst=217.56.236.4::X3 proto=icmp note="Source: 2.228.169.242, 63130, Destination: 217.56.236.4, 8, Protocol: 1" rule="17 (LAN->WAN)"

^C

1 packet captured

10 packets received by filter

0 packets dropped by kernel

[root@tech2srv31 ~]# /var/ossec/bin/ossec-logtest

2019/02/27 12:55:48 ossec-testrule: INFO: Started (pid: 11529).

ossec-testrule: Type one log per line.

id=NSA3600  sn=C0EAE4599999 time="2019-02-27 12:55:40 UTC" fw=2.228.169.242 pri=5 c=0 m=1197 msg="NAT Mapping" n=4748427 src=10.12.14.9::X0-V500 dst=217.56.236.4::X3 proto=icmp note="Source: 2.228.169.242, 63130, Destination: 217.56.236.4, 8, Protocol: 1" rule="17 (LAN->WAN)"

**Phase 1: Completed pre-decoding.

       full event: 'id=NSA3600  sn=C0EAE4599999 time="2019-02-27 12:55:40 UTC" fw=2.228.169.242 pri=5 c=0 m=1197 msg="NAT Mapping" n=4748427 src=10.12.14.9::X0-V500 dst=217.56.236.4::X3 proto=icmp note="Source: 2.228.169.242, 63130, Destination: 217.56.236.4, 8, Protocol: 1" rule="17 (LAN->WAN)"'

       timestamp: '(null)'

       hostname: 'tech2srv31'

       program_name: '(null)'

       log: 'id=NSA3600  sn=C0EAE4599999 time="2019-02-27 12:55:40 UTC" fw=2.228.169.242 pri=5 c=0 m=1197 msg="NAT Mapping" n=4748427 src=10.12.14.9::X0-V500 dst=217.56.236.4::X3 proto=icmp note="Source: 2.228.169.242, 63130, Destination: 217.56.236.4, 8, Protocol: 1" rule="17 (LAN->WAN)"'

[Juan Carlos]

Hello Giorgio,

Sorry for the late reply and as I just said in my previous message, thank you very much for providing these examples that will help us make better decoders.

I see in this case there are 2 spaces instead of 1 after the id field.

So to allow this (and similar issues), in your sonicwall decoder please change the first decoder to:

<decoder name="sonicwall">
   <prematch>^id=\w+\s+sn=\w+\s+time="\.+"\s+fw=\S+</prematch>
   <plugin_decoder>SonicWall_Decoder</plugin_decoder>
</decoder>

Again, thank you for contributing to our community.

Best Regards,

Juan Carlos Tello