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.

@nogbadthebad Thats was i think, because the .onion is encrypted too.
Thank you very much for your help, appreciated.

@bmeeks
Thanks for your insights!

If the Alias exists on the child, then Snort should see it and be able to use it. Are the interface names the exact same on the two firewalls? Snort expects sync'd boxes to be absolutely identical in every way including interface assignments and names.

All the XMLRPC Sync does is copy over the relevant piece of the config.xml file for Snort to the child firewall or firewalls.

@bmeeks Thank you for your reply

Yes, using IPS

Aparently, I do have sufficient memory available

dmesg | grep memory real memory = 8589934592 (8192 MB) avail memory = 8125104128 (7748 MB) real memory = 8589934592 (8192 MB) avail memory = 8125104128 (7748 MB) Found the option and enabled it. forced an update of the rules

No more unbound restart, No more unbound errors. Will keep monitoring this for a few days, but given your unambiguous answer, very confident this is solved. Hope some other users will benefit from this to.

Thank you so much for providing this solution. As always, thanks for your time and effort.

@molykule That's the behavior it is supposed to do ... did you checked the log when it stops? Are you using the Snort subscriber rules?

@w4rh0und I think it should also be icmp $External_net any -> ... this may help you: https://suricata.readthedocs.io/en/suricata-6.0.0/rule-management/adding-your-own-rules.html

@dwighthenry61 said in Snort Package v4.1.3 Update -- Release Notes:

@bmeeks I upgraded to the latest version of PfSense+ 21.02.2-RELEASE (arm)
built on Mon Apr 12 07:50:07 EDT 2021 so now I can install Snort and see it on the Services list. Trouble now however is that after configuring it won't start.

Look at the post immediately above yours and you will see why. Nothing has changed on that front. Snort nor Suricata will run on the SG-3100 hardware (or any ARM 32-bit appliance).

This issue is unlikely to get fixed, so if you want to run an IDS/IPS package, you will want to get something besides 32-bit ARM hardware to run it on.

@impatient said in LAN traffic graph stops working if Suricata inline mode is enabled:

@nollipfsense
Not on either of mine.

This is a graph image with Suricata on WAN and Snort on LAN both with in-line mode.

Screen Shot 2021-04-17 at 11.10.28 PM.png

Make sure you have disabled all NIC offloading options such as checksums and segmentation on the SYSTEM > ADVANCED > NETWORKING tab.

@pzanga said in seeing fewer alerts than I would expect with Snort on WAN:

@bmeeks
No worries. I appreciate the fact you took the time to help with this, and we did find an answer and I learned some things. So, if this is working as designed I will just run with it as is. I guess my last question would be "how significant is the lack of SO rules in terms of Snort's functioning as an IDS/IPS (i.e. are there significant threats that are potentially being missed)?".

Well, the SO rules do cover certain unique threats. Whether you actually have exposure to them is something you would have to investigate. But since you can't use them anyway, with your ARM hardware, no sense worrying about it unless you change hardware to an Intel/AMD platform.

@bmeeks I still run into the same thing after restarting it. I can't keep restarting it because it seems to happen again immediately.