@bmeeks said in Suricata-6.0.0_11 Package Update Release Notes: It will show up in the near future. This has been done, once again, we got your usual work... :-) (quality above all else) Thank you Bill, if something is missing we will shout

@bmeeks said in Snort-4.1.4 Update Package Release Notes: Yes, it will be included in the current release (both CE and pfSense+) in the near future. I'm sure the team has been busy with the recent 2.5.2 version going RELEASE, and have not pulled over some package updates. Good to hear! I will drop the Netgate team an email asking them to move Snort-4.1.4 over to 2.5.2. Thank you very much! And also THANK YOU for your work! Nice Weekend, i wish, fireodo

@theonemcdonald tun_wg0: flags=80c1<UP,RUNNING,NOARP,MULTICAST> metric 0 mtu 1500 description: WREGRD options=80000<LINKSTATE> inet 10.128.128.1 netmask 0xffffffff inet6 fd1f:c547:3e98:b32f:: prefixlen 64 groups: wg WireGuard nd6 options=101<PERFORMNUD,NO_DAD> Gave it a local link ipv6 but the issue persists. If I delete the tun_wg0 the issue goes away.

@drewsaur There is the + icon to Suppress a rule for an IP, in the source and destination IP columns, if that helps.

The System Log Facility setting controls "where" the entries are logged. Or more accurately, what "tag" they are given in syslog. So with the default of LOG_AUTH, those alerts are going to be given that tag, so when filtering in pfSense's system log, they will show up that way. The "General" view in pfSense grabs everything (if I recall) regardless of the "tag" it was given when logged. But those other tabs do let you filter by the facility tag.

@hichem said in Snort (4.1.3_5) + SG-3100 (21.05-RELEASE (arm)) = exited on signal 10: @steveits Patch already done 5 days ago, but snort stop after a few minutes. For SuricataI win reinstall it and told you the error. Pay attention to the errors in the log. Signal 11 is a segmentation fault. That was happening from the PHP PCRE engine. The patch referenced earlier in this thread fixes that Signal 11 problem. It does NOT fix the Signal 10 issue. That is caused by opcode choices made by the compiler for the 32-bit ARM processor used in the SG-3100 appliance. There is no easy fix for that. I've explained why in several other threads. If running an IDS/IPS is important to you, then get off of ARM 32-bit hardware and move to either an Intel/AMD platform, or a 64-bit aarch64 platform. The Signal 10 error has been an issue with Snort (and sometimes Suricata) since the release of the 32-bit ARM hardware appliances. I've tried one patch in the past that consists of disabling compiler optimizations by essentially telling the llvm compiler to compile Snort with the debugging flags enabled. That appeared to have worked for a while, especially under FreeBSD-11 (which the 2.4.5 branch of pfSense used). It appears that as of FreeBSD-12 (which the new 2.5.x branch and higher of pfSense is using), that old debugging compiler flag may no longer be effective.

@bmeeks Awesome, thank you sir! I somehow overlooked this ridiculously obvious tab... still trying to wrap my head around this system. This solved my problem, thanks for the help!

yeah that is exactly what happens, the first suricata instance to start is the one showing the stats, unfortunately the suricata plugin does not support multiple sources so the only way is to start another telegraf instance not managed by pFsense

@bmeeks Thanks for the tip. I got the format all fixed up thanks to the docs. RTFM works... if you know where it is. ;)

@bmeeks Stunning painless fix. Greatly appreciated.

Thanks @bmeeks. That's a shame. Would be a great feature to be able to add !pcre:covid-19 domain or similar above the other values to ignore as a first match. Hopefully a valid feature request!

@bmeeks Thank you kindly! :)

@bmeeks Thankyou, that answers my questions, really appreciate the response

@gwaitsi said in Suricata Rule Set Update Fails: @bmeeks I changed the time to 00:18, but also upgraded to 2.60 dev tree. Problem is solved, but not sure if changing the time or upgrading was the reason. My guess is changing the time was the solution. Currently, the Suricata package is the same on both the 2.5.x and 2.6.x pfSense branches.

@noexit said in Beginning to Snort: RaspberryPi or equivalent "Low Power" appliance Netgate has ARM appliances using pfSense Plus. Otherwise the open source pfSense is available on AMD64.

@coyote1abe said in Need to know if I am being spoofed or hacked: @bmeeks Thanks for your response. I do worry because as soon as the file was requested there this notification "spo_pf -> Firewall interface IP address change notification monitoring thread started.". why would the system behave like this? What change is going on? Really appreciate your help. Those messages are completely normal. Snort automatically loads all the firewall interface IPs into a default in-memory Pass List. So that is what you see being loaded there. Those will be the interface IP addresses (IPv4, IPv6 and loopback) defined on your firewall. <spo_pf> is the name of the custom blocking module I wrote for Snort on pfSense. A thread is started by that module to monitor the firewall interface IPs in case one changes. Realistically, the only one that usually changes is the WAN IP, but it monitors them all just in case.

@hrv231 said in [bug] snort 4.1.2_3 on pfsense 2.4.5-p1: @bmeeks Thank you for your time and help! Does it matter to leave it as it is, or do you recommend to edit some php files and hardcode a new memory number, and then reboot pfsense? Any change you made would get overwritten with the next pfSense update. I would just leave it as is. You should still be able to open and view the individual rules files. Or another option is to get to a shell prompt (via the console or SSH), and then view the file in vi. You can find the file in /usr/local/etc/snort/snort_xxxx/rules/snort.rules. The "xxxx" part will be the physical interface name and a UUID value.

@kylarem Did you select every rule on the planet for Suricata, Snort, and Zeek? I can understand and appreciate running both Suricata and Snort; however, for a home network, why on Earth do you need three IDS/IPS? I suggest searching the forum for best practice IDS/IPS.