Right, I admit : I say so, because it, pfSense, ships in a configuration that works out of the box. They choose this build-in setup because it's probably valid for most of us.
And that's valid for me.
( so extra true ^^)
I realize that there may be a bit of a language barrier if you're primary language is French. I realize if read a certain way it could be an argumentative statement. It wasn't meant to be so, so please don't take offense.
Don't worry, I live in France, so I know that there as as many exceptions as habitants.
Still .... using a modem that goes haywire because you throw some off the mill, plain vanilla DNS requests through it makes me wonder :
You pay your ISP - or your ISP pays you ? ;)
Do you have to use this type of modem ? (I've read somewhere, sometimes that you probably do not have any choice).
Residential customers can use an approved modem. Commercial customers must use the ones provided by the ISP.
IMHO : a more basic router/firewall a pfSense doesn't exist **. I guess it's even setting that reference right now.
What I should have said above :
On the Resolver settings page : un check the DNSSEC option, as it it worthless anyway.
The "ET INFO Outbound RRSIG DNS Query Observed" log line will go away.
Your WAN IP should appear if Snort is running on the WAN interface. If you move it to LAN, you'll see LAN IPs, and it won't see/scan traffic that was blocked by the firewall.
You misunderstand, I think. I'm not saying that I see the WAN IP in the Alerts (which I do since it's on the WAN). I'm saying I sometimes see the WAN IP in the snort2c block table. In that Suricata actually places the WAN IP on the block list and won't accept any traffic to or from the WAN IP for the duration of the block time. If he's running IDS on the WAN and the WAN IP is getting blocked then it won't accept any traffic at all on the WAN. I'm wondering if that is what he is seeing since he is talking about the snort2c block table and not the Alerts or Block lists.
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!
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.
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.
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
Many thanks for your help!
Indeed this must be a rule or some rules. I've disabled "IPS Policy - Balanced" category" and don't have this issue now. I've checked for zombie process and this doesn't look as the case.
I just wander - is any way to find the rule which actually causes the issue without disabling one by one?
There is a performance stats preprocessor that can be enabled on the PREPROCESSORS tab. I don't have any experience with using it, though. It supposedly gives some "per rule" performance information when you let Snort run for a while. Here is a link to the official Snort documentation from the Snort team: http://manual-snort-org.s3-website-us-east-1.amazonaws.com/node20.html. You could try adding the special configuration commands required to enable "per rule profiling" in the advanced Passthrough Options box at the bottom of the INTERFACE SETTINGS tab.
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.
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.
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.
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.
@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.
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.
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.