Duplicate parser node message when restarting syslog-ng

[Jeff H]

I have Suricata running on a pfSense firewall. Suricata logs it's alerts to the pfSense syslog and the pfSense is set to send syslog to Security Onion.

The logs are showing up in ELSA, but the Suricata logs were not being parsed as such and were not showing up on the Snort/Suricata search (class=snort).

The Suricata syslog alerts looked identical to the Snort alerts that are already accounted for in /etc/elsa/patterns.d/elsasecurityonion-patterndb.xml except they were identifying themselves as 'suricata' and not 'snort' so I followed the instructions to add a custom ELSA parser changing the pattern name from 'snort' to 'suricata' and now the logs are showing up under the snort class in ELSA.

Everything seems to be working fine now, but when I restart syslog-ng I get the following error:

* Stopping system logging syslog-ng [ OK ]
* Starting system logging syslog-ng Duplicate parser node in radix tree; type='2', name='s3', value='10780'
Duplicate parser node in radix tree; type='2', name='i1', value='10779'

I'm assuming this is due to my copying the rule and changing the name, but I wasn't able to identify where exactly the problem was or how to fix it.

Any help is much appreciated.

Jeff

[Gary Faulkner]

If you are able to it might be more practical to edit the suricata.yaml
file on the pfSense device to identify the logs as snort instead of
suricata.

You'd be looking for a section in the suricata config like this (just
set identity to snort):

# a line based alerts log similar to fast.log into syslog
- syslog:
enabled: yes
# reported identity to syslog. If ommited the program name (usually
# suricata) will be used.
identity: "snort"
facility: local5

Specific to your error message those duplicates are actually for a
different set of classes than SNORT:

From the classes table in the sylog DB:
|10779 | SYSMON_NETWORK | 0 |
| 10780 | WINDOWS_PROCESS | 0 |

I think I recall seeing the same error on a normal restart a while back
(no edits to patterndb on my own) and it being related to a bug that was
fixed with an SO update. I want to say it was when the Windows Process
parser was added in one SO update that caused the error and was then
fixed shortly after in the next update. I may have been using the
dev/test repos at that point though for testing newer parsers.
Alternatively did you add your class, field maps etc to MySQL and happen
to use those particular IDs when inserting your new class into MySQL?

Regards,
Gary

[Jeff H]

Replies inline

On Tue, Dec 15, 2015 at 6:47 PM, Gary Faulkner <gfaulk...@gmail.com> wrote:

If you are able to it might be more practical to edit the suricata.yaml
file on the pfSense device to identify the logs as snort instead of
suricata.

You'd be looking for a section in the suricata config like this (just
set identity to snort):

  # a line based alerts log similar to fast.log into syslog
  - syslog:
      enabled: yes
      # reported identity to syslog. If ommited the program name (usually
      # suricata) will be used.
      identity: "snort"
      facility: local5

I tried to do this as I did some Google searching and thought it would work. But I think the pfSense dynamically generates the suricata.yaml file from the options selected in the webgui. As far as I can tell there isn't an option in the gui to set the identity, so when I changed in manually in suricata.yaml it reverted back after a reboot. I think there should be a way to change it in the template file that is used to generate the suricata.yaml, but I wasn't able to find where to make that change.

I think I'd prefer to the have the parser in ELSA rather than modifying Suricata. Right now there is only one, but in the future that could grow, so modifying ELSA should be easier than having to hit all the individual instances of Suricata.

Specific to your error message those duplicates are actually for a
different set of classes than SNORT:

From the classes table in the sylog DB:
|10779 | SYSMON_NETWORK          |         0 |
| 10780 | WINDOWS_PROCESS         |         0 |

I think I recall seeing the same error on a normal restart a while back
(no edits to patterndb on my own) and it being related to a bug that was
fixed with an SO update. I want to say it was when the Windows Process
parser was added in one SO update that caused the error and was then
fixed shortly after in the next update. I may have been using the
dev/test repos at that point though for testing newer parsers.
Alternatively did you add your class, field maps etc to MySQL and happen
to use those particular IDs when inserting your new class into MySQL?

I didn't modify MySQL at all since I was reusing the exact parsers from Snort. 

This is a brand new system I installed from the Security Onion ISO on Monday and fully updated. I just ran soup again (it installed some OS updates but now security onion updates) and rebooted and the message persists when I restart syslog-ng. 

On 12/15/2015 6:28 PM, Jeff H wrote:
> I have Suricata running on a pfSense firewall. Suricata logs it's alerts to the pfSense syslog and the pfSense is set to send syslog to Security Onion.
>
> The logs are showing up in ELSA, but the Suricata logs were not being parsed as such and were not showing up on the Snort/Suricata search (class=snort).
>
> The Suricata syslog alerts looked identical to the Snort alerts that are already accounted for in /etc/elsa/patterns.d/elsasecurityonion-patterndb.xml except they were identifying themselves as 'suricata' and not 'snort' so I followed the instructions to add a custom ELSA parser changing the pattern name from 'snort' to 'suricata' and now the logs are showing up under the snort class in ELSA.
>
> Everything seems to be working fine now, but when I restart syslog-ng I get the following error:
>
>  * Stopping system logging syslog-ng                                                                                                                                                                                                                                [ OK ]
>  * Starting system logging syslog-ng                                                                                                                                                                                                                                       Duplicate parser node in radix tree; type='2', name='s3', value='10780'
> Duplicate parser node in radix tree; type='2', name='i1', value='10779'
>
> I'm assuming this is due to my copying the rule and changing the name, but I wasn't able to identify where exactly the problem was or how to fix it.
>
> Any help is much appreciated.
>
> Jeff
>

--
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
To post to this group, send email to securit...@googlegroups.com.
Visit this group at https://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.

[Doug Burks]

On Tue, Dec 15, 2015 at 7:28 PM, Jeff H <jeff...@gmail.com> wrote:
> Everything seems to be working fine now, but when I restart syslog-ng I get the following error:
>
> * Stopping system logging syslog-ng [ OK ]
> * Starting system logging syslog-ng Duplicate parser node in radix tree; type='2', name='s3', value='10780'
> Duplicate parser node in radix tree; type='2', name='i1', value='10779'

Hi Jeff,

I just replicated this issue, so I've created Issue 836 to work on this:
https://github.com/Security-Onion-Solutions/security-onion/issues/836

The fix should be included in BDR2 (the next major release).

In the meantime, I think this is probably just a cosmetic issue and
can be ignored.

--
Doug Burks
Need Security Onion Training or Commercial Support?
http://securityonionsolutions.com