@barakat_abweh said in Snort actions in the logs: @bmeeks thanks bro I'll consider it, but also the netgate team should consider giving that option to the users and consider the upgrade to snort3 so we can benefit the multithreading feature available in snort3 About a year ago I started work on a Snort3 package, but grew very frustrated with the effort and abandoned it. I've since cooled down a bit (or maybe time has erased the memory of that former pain ... ), and so I've started back on some very preliminary work on Snort3. Nothing even remotely close to release, though. I've decided that an easier path for Snort3 might be to just let users start with a fresh, clean plate. Don't migrate any settings except maybe the pfSense interfaces where Snort was configured, and if they match up close enough, perhaps migrate the rules configuration. Things are just too different in Snort3 to cleanly migrate all of the Snort 2.9.x settings. It was attempting to code that migration that led to my high frustration level.

The fix for this issue has now been posted to both the DEVELOPMENT and RELEASE branches of pfSense CE and pfSense+. The GUI package version is 4.1.4_3.

To maybe make you feel better, I run Snort on my LAN with the IPS Balanced policy along with some of those ET-Open categories I mentioned earlier. I see maybe one or two DROPs per month in my logs. Ironically, if you see lots of DROPs, that really should make you quite nervous about the overall security of your network. Because that would mean a lot of your LAN hosts either are, or were, visiting questionable sites or doing questionable things (and thus may be infected with malware of some sort). Edit: some additional info ... I mentioned in one of my earlier posts above that my favorite policy was "IPS Policy Connected". That's the policy I recommend to all users new to administering an IDS/IPS. So that's the context of "favorite" in my earlier post. Once you gain experience with the IDS/IPS, you can move to something like "IPS Policy Balanced". I don't suggest anyone go beyond that unless you are protecting military secrets or access to all the UFOs stored at Area 51 ... .

@andrea-1 I have too problem how you! Localization set eng or not? If not try set eng in pfsense and pass list can create.

The default values in Snort for "max_queued_bytes" should be sufficient for most all situations. A common cause for seeing this error from Snort's Stream5 preprocessor is asymmetrical routing. Snort is seeing only one side of the conversation, and thus keeps queueing up bytes and never closing the session to recover memory. Likely Snort is never seeing the FIN/ACK part of the session transaction, as that would be the key to tell Snort the session is done and thus Snort can release the queue memory back into the pool for the next session to use. So when not seeing the end of previous sessions, and thus not cleaning up and recovering that memory, Snort will continue to allocate new buffer space for each session. Eventually it runs out of space, and that's the error you are seeing logged. You can increase the amount of session queue memory, but I think that would be just a temporary fix. Examine your setup for asymmetrical routing. You can capture on the interface and examine the traffic in Wireshark to see if both sides of a session's conversation are being seen.

You've given us not a single log entry, so there is no possible way to know what might be wrong. Go to the LOGS VIEW tab, select the suricata.log file in the drop-down there, and post its contents back here. If Suricata is encountering a startup error, it should be logged there. Also check your pfSense system log under STATUS > SYSTEM LOGS. Post anything Suricata-related back here. If you are getting current alerts, you may have a zombie process running. Check that with this command run from a shell prompt on the firewall: ps -ax | grep suricata If you see any running Suricata processes, kill them. Edit: Oh, and last thing ... make sure you are running the very latest Suricata package. That will be version 6.0.0_12.

@bmeeks said in Can pfSense integrate with another device? (mirrored-port⇄API): packets will leak unless you slow the network traffic down to a trickle and hold packets up on one box while the other box is inspecting them and then sending instructions over some kind of back chan Thanks, this is incredibly informative. Just to be clear, my edge device and firewall is pfSense and it's also the one running Suricata (not inline though). I'm just experimenting with stuff for fun, and sure, anything's going to be super inefficient if it's not within kernel's reach but it must be at least better than diverting back and forth the full stream of data. The big really big enterprise firewall-routers, something like TNSR or these 30-something core ASICs out there usually don't have these features. They do seem like they'd benefit from this approach but that's just speculation of mine, I came here to learn in the first place, I've nothing to teach. Thanks again!

@bmeeks Thanks, I didn't notice that option in interface settings. I did that and now I am monitoring the behavior of Suricata. Cheers

@bmeeks Thank you very much for your attention and help, thanks to this I have been able to carry out my laboratory perfectly. Thank you very much !!!!

@wrightsonm said in Suricata log rotation bug: @bmeeks I would say that your suggestion isn't particularly good design practice. There is already ajax being used on this page - see check_status() function. The start / stop buttons should really get submitted as an ajax request that then updates the icons on the page onc completion rather than submitting the entire page and causing the described problem. Secondly, the issue that the php page is at risk of a type of replay attack that is triggered when refreshing the page, that then causes multiple services to be started is less than ideal. The main php script should really take advantage of the logic contained within $_POST['check'] and use that to determine whether or not to start a new process to prevent the possibility of multiple services being started - i.e. add validation. The code tries, as best it can within the limitations of PHP, to see if another instance is running before starting an instance. The problem is that the only way the code really has to determine if another process is running for the interface is to look for the PID file created in /var/run. Each interface has a randomly generated UUID associated with it at interface creation. That UUID is used to name the PID file, so the code can tell which interfaces have Suricata running, and be able to control them individually. However, it takes some amount of time for Suricata to start and create that PID file. If the user quickly refreshes back-to-back, there is no PID file yet from the first process, and so not seeing an existing PID, it assumes there is no existing process and thus starts a new process. Then you have two. The Ajax section was added a few years ago to improve GUI responsiveness. It works by actually creating a new background PHP process to start the Suricata daemon. The Ajax loop then checks for the existence of the aforementioned PID file to determine whether Suricata is running or not. Prior to that, the GUI just sat there and "spun" with the web page totally unresponsive until the PHP function calls returned. That was not ideal, either. If you have a better solution, please feel free to submit a Pull Request here: https://github.com/pfsense/FreeBSD-ports/tree/devel/security/pfSense-pkg-suricata. User contributions are welcomed.

@bmeeks thanx, it's working fine now...

I opened a separate bug to cover this as it was getting conflated with the PHP issue whoch is a separate (and solvable) problem: https://redmine.pfsense.org/issues/12157 Steve

@fst said in Snort will not start - PFSense 21.05 / FreeBSD 12.2: Thanks again. You're welcome. Sorry for not getting it working! Regards, fireodo

@bmeeks Thanks Bill, I actually had a sneaking suspicion I'd seen it and had it in my to do list to check it so thanks for confirming.

@bmeeks Cool. Again, thanks for all the effort on this!

@gertjan said in ET INFO Outbound RRSIG DNS Query Observed: @stewart said in ET INFO Outbound RRSIG DNS Query Observed: Spectrum uses have PUMA chipsets and fall apart Oh .... that name does ring a bell. Isn't that chipset/modem part of the top ten on badmodens.org (or something like that). Why yes. Yes it is. I believe PUMA chipsets is the sole reason that site exists. @gertjan said in ET INFO Outbound RRSIG DNS Query Observed: @stewart said in ET INFO Outbound RRSIG DNS Query Observed: You can't just say Well ..... 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. @stewart said in ET INFO Outbound RRSIG DNS Query Observed: modem buckles under the weight of simple DNS traffic This intrigues me. Dono what the ratio of "DNS traffic"/"All traffic is". 1 or 2 %, maybe ? I should investigate. It's not the overall amount of bandwidth that's used. It's that DNS throws out a bunch of UDP packets in quick succession when doing the resolving and the modems become unresponsive during that time. ** with probably far to many bells and whistles.