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.

@steveits said in Snort2c Hosts being blocked: @stewart said in Snort2c Hosts being blocked: find the WAN IP as being blocked 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.

I want to report that I am working offline with the Suricata developer team looking into this issue, and also the one affecting netmap operation in the Suricata 6.x binary.