Snort actions in the logs
-
So I'm currently working on building an addon for pfsense and splunk and I managed to do a lot of work.
Unfortunately some data is missing when sending it through syslog to splunk.
that is to log under the interface log tab (just masked the ips and ports)
08/20/21-16:41:52.567863 ,1,2500116,5896,"ET COMPROMISED Known Compromised or Hostile Host Traffic TCP group 59",TCP,ip,port,ip,port,Misc Attack,2,alert,Allowand that is the log in the system log and splunk(also masked the ips and ports)
2021-08-20T16:49:36.097873+03:00 hostname snort 66639 - - [1:2500116:5896] ET COMPROMISED Known Compromised or Hostile Host Traffic TCP group 59 [Classification: Misc Attack] [Priority: 2] {TCP} ip:port -> ip:portis there any way to get snort to log the missing data such ass allert and allow to the system logs so I can send them to splunk with the rule log?
-
@barakat_abweh said in Snort actions in the logs:
is there any way to get snort to log the missing data such ass allert and allow to the system logs so I can send them to splunk with the rule log?
No, not without altering the C source code of the underlying Snort binary. The data logged is fixed.
Another alternative for you is to adapt your Splunk plugin code to read the Unified2 (*.u2) binary log format. You can configure Snort to write a unified2 log for each interface. That log contains the action and some other alert data.
But for longer term, I would also consider looking into some kind of EVE JSON option. Snort3 logs in that format, and so does Suricata. Snort2 is going to have a more limited life. I would expect the upstream Snort team to begin slowly moving Snort2 towards some scheduled EOL in the not too distant future.
-
@bmeeks
thanks bro I'll consider it, but also the netgate team should consider giving that option to the users and consider the upgrade to snort3 so we can benefit the multithreading feature available in snort3 -
@barakat_abweh said in Snort actions in the logs:
@bmeeks
thanks bro I'll consider it, but also the netgate team should consider giving that option to the users and consider the upgrade to snort3 so we can benefit the multithreading feature available in snort3About a year ago I started work on a Snort3 package, but grew very frustrated with the effort and abandoned it. I've since cooled down a bit (or maybe time has erased the memory of that former pain ...
), and so I've started back on some very preliminary work on Snort3. Nothing even remotely close to release, though.I've decided that an easier path for Snort3 might be to just let users start with a fresh, clean plate. Don't migrate any settings except maybe the pfSense interfaces where Snort was configured, and if they match up close enough, perhaps migrate the rules configuration. Things are just too different in Snort3 to cleanly migrate all of the Snort 2.9.x settings. It was attempting to code that migration that led to my high frustration level.
