Junos Rules and Decoder how they work

[Ronald Simmons]

I am ingesting Juniper Logs to the archive index on my Wazuh server, but the decoder never launches. I have the predecoder data but no decoder launches

Rule 0640-junos_rules.xml
Decoder 0490-junos_decoders.xml

I guess I don't understand the rule Id that kicks off the decoder I see four rule id's

    <rule id="67100" level="0">
    <rule id="67101" level="10">
    <rule id="67102" level="0">
    <rule id="67103" level="5">
 are these id's part of the juniper syslog or are they something else. I could use a better understanding of the process

[Olamilekan Abdullateef Ajani]

Hello,

First, those rule IDs you shared are part of the Junos rules. What could be happening here is the type of logs being ingested does not match any of those rules, so the investigation needs to start from archives.json file to review how the logs are ingested and if corrections need to be made or to review the syslog configuration on the source, which is the Juniper device.

If you have not already, we need to enable Wazuh archive and check the logs there that are related to Junos.

You can enable the archive log by editing the /var/ossec/etc/ossec.conf file.
<ossec_config>
  <global>
    <logall>yes</logall>
    <logall_json>yes</logall_json>
  </global>
</ossec_config>
Then restart the Wazuh-manager. systemctl restart wazuh-manager

cat /var/ossec/logs/archives/archives.json | grep "part of your log"
Verify that you have the logs, and please share a sample or two, then disable archiving by setting the values to no.

Please let me know what you find.

[Ronald Simmons]

Here is my Global it has a few more items at the moment but it is yes for both logall and logall_jason

<ossec_config>
  <global>
    <jsonout_output>yes</jsonout_output>
    <alerts_log>yes</alerts_log>

    <logall>yes</logall>
    <logall_json>yes</logall_json>

    <email_notification>no</email_notification>
    <smtp_server>smtp.example.wazuh.com</smtp_server>
    <email_from>wa...@example.wazuh.com</email_from>
    <email_to>reci...@example.wazuh.com</email_to>
    <email_maxperhour>12</email_maxperhour>
    <email_log_source>alerts.log</email_log_source>
    <agents_disconnection_time>15m</agents_disconnection_time>
    <agents_disconnection_alert_time>0</agents_disconnection_alert_time>
    <update_check>yes</update_check>
  </global>

[Olamilekan Abdullateef Ajani]

Hello, 

That is a good start since you have that already setup, next is to filter for the Junos logs, as I have also stated earlier.

cat /var/ossec/logs/archives/archives.json | grep "part of your log"

Depending on the log type, you can also filter by the source IP too. Verify that you have the logs, and please share a sample or two, then disable archiving by setting the values to no.

Please let me know what you find.

[Ronald Simmons]

Thank you for your help I have been replying to your questions but I don't see my reply's in this conversation so I'm not even sure that you will get this. but you told me to enable <logall>yes</logall> and   <logall_json>yes</logall_json>. That was set in my ossec.conf by default and it is where my syslog data is going if I set them to no won't it stop ingesting juniper syslog data?

[Olamilekan Abdullateef Ajani]

Hello

I got your private messages. Private messages wont show up here, you have to reply all before you can see it in the thread.

To the main issue, setting them to no will not stop your logs from ingesting, it only means they won't write to archives any longer, which in turn saves you storage space, because with logall/logall_json set to yes, it means all logs, whether they match a rule or not, will be written to that file, and it consumes space and could cause disk performance issues in the future. So we always advice you set those to no.

If they are on no, you will be able to get an alert so far as the logs match any rule. The configuration is useful at the initial stage when you are still trying to map logs to rule and filter for noise.

That said, you are yet to share the sample log requested from archives.json file, this will help me understand how the logs are ingested and to properly map them to a rule. You can send them privately as you initially did.

Regards,