Logstash filter for pfsense suricata logs

[quentin mallet]

Greetings,
I have several pfsense routers on my network. They all run suricata and syslog. The log forwarding to securityonion is in place but their alerts do not show up in the kibana NIDS dashboard.

Currently those messages are interpreted as normal syslog messages with an event_type set to "suricata".

I identified the following files in the logstash configuration that have an influence on how things are done right now:

1001_preprocess_syslogng.conf -> rename fields and set things up

1033_preprocess_snort.conf -> Prepare the event so it can be indexed as a snort event

I need to hijack the log processing between 1001 and 1033 so the pfsense logs that contain suricata data can be indexed properly as suricata alerts and become visible on kibana like those generated by the securitonion sensors.

To that end I researched the order in which filters were applied, and from what I gathered it is done alphabetically.

I devised the following course of action:

1. Create a new filter that is applied after 1001_preprocess_syslogng.conf
and mutate.replace the type to "snort" (the message part should be processed correctly by 1033_preprocess_snort.conf).

2. Insert this filter between the two conf files described above.

I have two issues and would be grateful for any guidance regarding them:
- When naming the conf file I will put into logstash/custom, should I use the first free index between the 1001 and 1033 (that would result in a name like that: 1005_something_something_something.conf)? Don't I risk having the order scrambled when new conf files are added in a future update? If so, what would be the best practices when it comes to adding custom conf files?

- Do I put the file only on the master server or do I have to manually have to update every node? (heavy distributed deployment here).

Thanks for your help!
Quentin

[Wes Lambert]

Quentin,

To answer your questions:

1. You should be okay with taking the next available index for now -- you could always change this later if there were any issues.

2. If you are running a distributed deployment, then this conf file would need to live on all storage nodes.  If you are running a heavy distributed deployment, then this file would have to go on all heavy nodes (or at least the nodes that are receiving this data).

Thanks,

Wes

Quentin

--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
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-onion+unsubscribe@googlegroups.com.
To post to this group, send email to security-onion@googlegroups.com.
Visit this group at https://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.

--

https://twitter.com/therealwlambert

https://securityonion.net/

[quentin mallet]

Thank you for those informations, I'll keep a backup somewhere anyway but it's nice to know I should keep an eye on those conf files too.
Regards,
Quentin