Snort v3.2.9.9 Package Update - Release Notes (for pfSense-2.4.4 RELEASE)
-
@bmeeks
Yes I do have a Netgate appliance. I didn't realize the repos were different. -
@gfeiner said in Snort v3.2.9.9 Package Update - Release Notes (for pfSense-2.4.4 RELEASE):
@bmeeks
Yes I do have a Netgate appliance. I didn't realize the repos were different.Yeah, the main reason for the difference is because the pfSense for the Netgate appliances is slightly customized for the appliance hardware, plus it includes a special package for AWS or something like that. That separation flows over into the other packages as well. The pfSense developer who merged my Snort update forgot to also merge it to the Netgate repository. He did that around 8:00 AM EDT on Thursday, August 15th.
-
Hello,
since the last update, after about 20 minutes when the Snort service on LAN started, the following error occurred to me: kernel: igb1: promiscuous mode disabled. I have no problems on the other three network cards.What is the problem? how can i fix it?
I also tried the Snort removal and fresh installation and configuration.
Thanks for any help
-
@Simbad said in Snort v3.2.9.9 Package Update - Release Notes (for pfSense-2.4.4 RELEASE):
Hello,
since the last update, after about 20 minutes when the Snort service on LAN started, the following error occurred to me: kernel: igb1: promiscuous mode disabled. I have no problems on the other three network cards.What is the problem? how can i fix it?
I also tried the Snort removal and fresh installation and configuration.
Thanks for any help
Need more information for troubleshooting.
-
What type of hardware (CPU type) and how much RAM?
-
What other messages are displayed in the system log? The message you posted is simply the last message the kernel will print when Snort shuts down as the libpcap library is returning the interface to normal non-promiscuous mode operation. List the system log messages that preceed (in time) the message you posted.
-
-
I have i9900 and 32GB ram.
last log, after LAN snort die:
Aug 18 19:28:35 kernel: igb1: promiscuous mode disabled
Aug 18 19:28:09 barnyard2[43267]: OpSyslog_Alert(): Invoked with Packet[0x45fa000] Event[0x0] Event Type [0] Context pointer[0x460d700] -
@Simbad said in Snort v3.2.9.9 Package Update - Release Notes (for pfSense-2.4.4 RELEASE):
I have i9900 and 32GB ram.
last log, after LAN snort die:
Aug 18 19:28:35 kernel: igb1: promiscuous mode disabled
Aug 18 19:28:09 barnyard2[43267]: OpSyslog_Alert(): Invoked with Packet[0x45fa000] Event[0x0] Event Type [0] Context pointer[0x460d700]That's all? There are no other Snort messages? And that Barnyard2 message was in the pfSense system log? I would expect to see other Snort messages in your pfSense system log (at least something like "snort exited with Signal 11" or similar). Nothing in your log like that?
You say you have no problems on the other three network cards. What is different about those setups? Are they all running Snort? Are their configurations the same, or if not, what are some of the differences?
-
I have quad intel 350i network card (igb0, igb1, igb2, igb3).
This is log from system logs (with snort log).
All four configuration settings are exactly the same (clone) WAN settings.
-
@Simbad said in Snort v3.2.9.9 Package Update - Release Notes (for pfSense-2.4.4 RELEASE):
I have quad intel 350i network card (igb0, igb1, igb2, igb3).
This is log from system logs (with snort log).
All four configuration settings are exactly the same (clone) WAN settings.
So you have four identical configurations of Snort running on four different interfaces? Why? That really makes no sense unless you actually have four WAN interfaces in some kind of failover/load balancer setup.
If you do in fact have four identical setups and three work fine but the fourth does not, then something is wrong with that fourth setup. It would not be the Snort software if the exact same setup works in three other instances.
You have Snort outputting alerts to syslog and thus that is creating a lot of extra noise in the log and is likely masking the other messages relative to the Snort daemon that I was looking for.
-
I have 4 different ones to help identify the internal source.
-
@Simbad said in Snort v3.2.9.9 Package Update - Release Notes (for pfSense-2.4.4 RELEASE):
I have 4 different ones to help identify the internal source.
Then why on the WAN, too? The WAN is going to drop all unsolicited inbound anyway unless you have configured port forwards. And even if you have port forwards, if you have Snort on every LAN interface then those installations will catch bad stuff.
Suit yourself if you want four identical Snort setups, but my original comment still stands. If three of the four identical setups work and only one of them does not, then you will need to search thoroughly and find out how that fourth one is different. Something must be if it stops and others do not. The Snort binary and PHP code is identical for all four instances.
-
Thank you, I'll bury my head in logs like an ostrich in the ground,...
-
@Simbad said in Snort v3.2.9.9 Package Update - Release Notes (for pfSense-2.4.4 RELEASE):
Thank you, I'll bury my head in logs like an ostrich in the ground,...
I would recommend first temporarily turning off the option for sending alerts to syslog. Do that for all interfaces and then restart Snort on all interfaces. That will make for a quieter log where other messages will more easily stand out. Once you track down the problem with the troublesome interface, you can re-enable the syslog alert output.
