Upgrade from 2.4.4-p2 to 2.4.4-p3 causes barnyard db issues?
-
I had a time sync issue that is now sorted out - this time sync issue existed before the upgrade and was resolved after the upgrade.
Since the upgrade my logs have been flooded with these:
barnyard2 35527 OpSyslog_Alert(): Invoked with Packet[0x36d9000] Event[0x0] Event Type [0] Context pointer[0x36f1700]
Sometimes the memory addresses are different but today it's all about the ones in the above log message.
I have tried restarting snort/barnyard. Rebooting the system. Re-installing snort (it kept the config-and I changed nothing).
Anybody experiencing this or know what to do?
I've done some searching on the PFSense forums and google and a lot of posts mention deleting the snort.u2 file after stopping barnyard and snort, then changing the barnyard cache size to what I assume is higher (config event_cache_size: 60960) however it is not clear to me where I would do that as all the post talk about a file I cannot find in the system anywhere. I just manually looked for it and didn't see it in the directories I browsed.
One posted snippet quoted from github "decreased session time out and maximum size of packet in snort.conf"
ref for above: https://github.com/firnsy/barnyard2/issues/143
When I did the upgraded I rebooted immediately after. I noticed these in my system logs while trouble shooting the ntpd error. I just checked my ntpd logs and they are clean as a whistle.
Any help would be appreciated (I am making notes for future troubleshooting) I am no expert with snort/barnyard. I know enough to do a general configuration it in PFSense and suppress any rule I need suppressed and that's about it.
Snort itself seems to be working fine. I see it blocking in my logs, just barnyard is going nuts on me. My CPU is over 20% usage for the first time ever that I've noticed.
Posted below is a filtered (barnyard) log snippet: - it started immediately after the upgrade/reboot yesterday morning.
Feb 28 08:41:05 barnyard2 35527 OpSyslog_Alert(): Invoked with Packet[0x36d9000] Event[0x0] Event Type [0] Context pointer[0x36f1700]
Feb 28 08:38:27 barnyard2 35527 OpSyslog_Alert(): Invoked with Packet[0x36d9000] Event[0x0] Event Type [0] Context pointer[0x36f1700]
Feb 28 08:34:05 barnyard2 35527 OpSyslog_Alert(): Invoked with Packet[0x36d9000] Event[0x0] Event Type [0] Context pointer[0x36f1700]
Feb 28 08:33:36 barnyard2 35527 OpSyslog_Alert(): Invoked with Packet[0x36d9000] Event[0x0] Event Type [0] Context pointer[0x36f1700]
Feb 28 08:33:24 barnyard2 35527 OpSyslog_Alert(): Invoked with Packet[0x36d9000] Event[0x0] Event Type [0] Context pointer[0x36f1700]
Feb 28 08:33:24 barnyard2 35527 OpSyslog_Alert(): Invoked with Packet[0x36d9000] Event[0x0] Event Type [0] Context pointer[0x36f1700]
Feb 28 08:32:55 barnyard2 35527 OpSyslog_Alert(): Invoked with Packet[0x36d9000] Event[0x0] Event Type [0] Context pointer[0x36f1700]
Feb 28 08:32:06 barnyard2 35527 OpSyslog_Alert(): Invoked with Packet[0x36d9000] Event[0x0] Event Type [0] Context pointer[0x36f1700]
Feb 28 08:31:34 barnyard2 35527 OpSyslog_Alert(): Invoked with Packet[0x36d9000] Event[0x0] Event Type [0] Context pointer[0x36f1700]
Feb 28 08:30:26 barnyard2 35527 OpSyslog_Alert(): Invoked with Packet[0x36d9000] Event[0x0] Event Type [0] Context pointer[0x36f1700 -
barnyard2 is deprecated and not updated from a long time, it will be removed by (correction)-> @bmeeks in the near future, the preferred method is to use eve json
just disable barnyard2 -
oooohhhhhhh - I thought barnyard2 was part of the Snort logging. I WILL disabled it if it's deprecated and not likely to get fixed, but will that affect sorts logging facilities?
-
afaik alert / block / log view are not affected
-
tyvm.
-
Barnyard2 has not been updated in FreeBSD ports for several years, so it is by any measure abandoned there in my opinion. I have kept it around in Snort and Suricata mainly for legacy users. It supports reading the Snort Unified2 binary log file and then exporting the data to a database or to syslog. However, due to nothing being updated in FreeBSD ports for Barnyard2, it is using an outdated MySQL client among other things. Hence it is starting to break. Your issue could very well be the result of some dependent shared library used by Barnyard2 getting updated with the newer pfSense release (which will bring in updated ports).
@kiokoman is partially correct about the deprecation. But it is the upstream Suricata team that is formerly removing Unified2 logging support beginning with Suricata 6.0. When that happens, I will remove Barnyard2 support from the Suricata package as Suricata aims to support EVE JSON logging only.
Snort is still an open question. Snort3 seems somewhat stalled out in my view. At least there is no movement yet towards making it RELEASE. It is still in BETA and has been for quite some time. The Snort 2.x branch gets updates, but nothing has been added to improve logging efficiency in that version. Snort3 does support JSON logging.
So all in all it would appear that Barnyard2 is suffering a slow and painful death with no updates. So if using Snort and wanting something beyond the basic logging available in the GUI, I would look at something like an ELK stack to replace Barnyard2. You can send Snort logs directly to syslog.
-
yeah, i called you on purpose to explain things better
and i used the wrong nickname 
