To hopefully add some additional clarity to my response above relative to Snort package deprecation in pfSense -- A good analogy might be the current state of the legacy ISC DHCP daemon and the new Kea component. The ISC DHCP daemon is still present in pfSense and likely will remain available for quite some time in the future. But ISC has announced that Kea is their future, and it's where all future development effort from them will be concentrated going forward. pfSense has made the decision to add Kea and to eventually deprecate the legacy ISC DHCP product. Similarly, for Snort, the upstream Talos/Cisco team has made it clear that Snort3 is where their future development efforts will concentrate. I expect the old Snort 2.9.x tree to get very limited "love" (if it gets any at all) going forward. But as long as the 2.9.20 binary code compiles in whatever FreeBSD version pfSense is using at a given point in time, and the code runs without crashing, I suspect the Snort 2.9.x package will continue to be available on pfSense. On pfSense there are two pieces of the Snort package puzzle. There is the GUI component the user interacts with (written in PHP), and then the binary daemon (written in C) where all the actual packet inspection happens. The binary daemon comes from the upstream Talos/Cisco folks. All the PHP code does is create the snort.conf file and then launch the binary daemon. There may be occasional updates to the PHP code (for example, this most recent one) to address known bugs within that piece. The binary piece on pfSense also contains a custom plugin I wrote that handles the Legacy Mode blocking duty. Sometimes that custom plugin may get a fix (as it did in this release), but no new Snort binary traffic inspection features or support for new protocols are going to show up unless the Talos/Cisco upstream team makes an update for the Snort 2.9.x binary tree. I don't expect that to happen often, and it is less and less likely as time progresses. Already it's been nearly two years since any change was made in Snort 2.9.x upstream.

@wheel5up said in What's the number in the suricata config file path and log file pat: @bmeeks outstanding! Thank you. I want to monitor this file with Zabbix. Can this value be determined from command line? I was looking in the docs and I couldn't find anything on that identifier. My fear is I'll setup a logfile monitor, and a package update will change that number and break my monitoring. The number will never change as part of a package update. The only way the number will get changed is if you delete the Suricata interface instance and then recreate a new one on the same interface. The new instance would get a new UUID. So long as that interface exists, its UUID will remain constant. That's the point of the UUID in the code. Everything to do with that particular Suricata instance is tagged with the UUID. That includes both the logging directory and the configuration directory. You will notice that each has the UUID as part of the path (along with the physical interface name from FreeBSD).

@bmeeks said in Missing blocking mode setting in Suricata 7.0.3?: With the Enable checkbox cleared, then every single control on that tab is disabled as then the Suricata interface itself will be disabled and not start. I'm just saying that this behavior, afaict, is limited to Suricata. For instance if I uncheck 'Enable' for dhcp server, I'm still able to adjust all of the settings.

Do you have the option to enable syslog logging enabled for the interface? You must specifically enable the logging of alerts to syslog. But be aware that the FreeBSD syslog daemon truncates syslog entries after a certain message length. I don't recall off the top of my head what that value is, but it does result in some of the alert messages being cut off in the syslog record. Later Edit: went back and found the message length. It was 480 bytes for IPv4 and 1180 for IPv6. This turned out to be a bug in that the RFC behavior was misunderstood or else not implemented correctly. Here is the FreeBSD bug tracker: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241937. Not sure what the current status of this bug is within the pfSense kernel code.

@RobertK-1 it’s not a new recommendation just a new warning. See: https://docs.suricata.io/en/suricata-7.0.2/performance/packet-capture.html “11.2.3. Offloading Network cards, drivers and the kernel itself have various techniques to speed up packet handling. Generally these will all have to be disabled. LRO/GRO lead to merging various smaller packets into big 'super packets'. These will need to be disabled as they break the dsize keyword as well as TCP state tracking. Checksum offloading can be left enabled on AF_PACKET and PF_RING, but needs to be disabled on PCAP, NETMAP and others.”

It might be useful, but trying to incorporate regex parsing where you accept others' regex arguments has proven to be "prickly" in PHP. It seems hard to handle the escape codes properly. You will note that the current code uses regex parsing itself, but those expressions are built into the code. They are not being supplied by the user. That's the part that has proven hard to get right (at least for me). I've had to modify the code around modify.sid at least twice as I recall in both packages because users complained about the implementation. It centered around properly detecting escape delimiters and the behavior of them when the regex was evaluated within PHP. So, long story shortened a bit, I'm not enough of a regex expert (far, far from one, actually) to have confidence I would get such code working correctly in all situations.

This bug will be fixed in the next Suricata package update which is posted for the Netgate developer team to review and merge. The new package version with the fix will be 7.03. Look for it to post in the near future.

@bmeeks said in 7.0.2_3 update "broke" IPS (netamap) on LAN interface (?): It won't go high enough because the NIC driver itself refuses to use the larger values. Okay I'll play with this a bit more I saw somewhere that under CentOS this NIC goes up to 1024, as this is therefore the upper limit: [NETMAP_RING_POOL] = { .name = "%s_ring", .objminsize = sizeof(struct netmap_ring), .objmaxsize = 32*PAGE_SIZE, .nummin = 2, .nummax = 1024,

@SteveITS Thanks, just changed the setting and given the router a reboot.

@SteveITS said in Suricata process dying due to hyperscan problem: https://docs.netgate.com/pfsense/en/latest/releases/2-7-1.html#troubleshooting Thank you for the link. This resolved my problem. Regards, Tim

Drifter worries me this could make firewalls have issues if they are really inspecting stack after delivery

@RobertK-1 We've found the stream events cause a lot of issues so routinely disabled those. The disable.conf file as noted above, is permanent. Otherwise for your case the rule IDs may change and/or they add more.

@darkphox said in Sanity check on suppressing alerts: I have a few specific rules that alert very frequently. I'd like them to continue functioning (drop connections) without spamming my alerts tab, if possible. Hmm... no way to do that directly in the GUI on pfSense. You could perhaps custom modify those particular rules to try adding the noalert option to the actual rule text. @darkphox said in Sanity check on suppressing alerts: After about a year of functioning normally, it began blocking my internal device IP when a rule triggered (when using either the default or a custom passlist). I've been trying to chase this down. Unfortunately I have never been able to replicate the problem in my test environment. Not being able to replicate the issue makes troubleshooting it and finding a solution very difficult. I'm relegated to bascially guessing for potential causes. So far my guesses have not found the true issue as random users experience random blocks of pass list hosts.

@jimp still happening intermittently; only on the interface rules page only when changing rules to view from the dropdown gives a blank screen when it happens and the web developers screen returns nothing on the blank screen. has only started since I changed the interface from legacy to inline not able to repeat consistently, so i have not been able to see the web developerer screen before/after it happens yet.

@MaxBishop said in Suricata - bans LAN device -new behavior on new pf install: @bmeeks OK, how do I get it. Here is the link: https://drive.google.com/file/d/1L-rCf8rF-_C93TFISOx4iWPRgW95sFww/view?usp=sharing This will pull from my Google Drive folder. Here are the instructions for installing (and then later removing) the test binary. To begin, download the suricata-7.0.2_7.pkg file from the link above and transfer it to your firewall placing it in the /root directory. IMPORTANT: make sure you transfer the file in binary (unaltered) form! So, if using WinSCP for the transfer from a Windows PC, choose "Binary" for the transfer type. Stop all running Suricata instances by executing this command from a shell prompt on the firewall: /usr/local/etc/rc.d/suricata.sh stop Install the updated version of the Suricata binary using the command below at a shell prompt on the firewall: pkg-static install -f /root/suricata-7.0.2_7.pkg That command forcibly updates the binary portion of Suricata with a new package leaving the GUI portion unaltered. Return to the pfSense GUI and restart Suricata on the interfaces using the icons on the INTERFACES tab. Report back if there is any change in behavior. I sort of don't really expect a change, but maybe we get lucky. This has proven to be an extraordinarily difficult nut to crack in the past (evidenced by the fact I still have not found a true root cause and thus effective solution). Not being able to reproduce it on my end is what makes finding the bug so hard. I have consulted with the upstream Suricata developers, and they told me the Radix Tree code is thread-safe. Be sure you leave the passlist-debugging: yes option set in suricata.yaml to give me the maximum level of debugging log messages to work with. To revert, you will need to first remove the Suricata package, verify the updated binary was also removed, then install the package again from the pfSense menu under SYSTEM > PACKAGE MANAGER. Remove the package using the SYSTEM > PACKAGE MANAGER menu option. Next, run this command from a shell prompt: pkg-static delete suricata-7.0.2_7 That insures the updated test binary is truly removed. If you receive a "not found" or "not installed" error, that simply means the updated binary was removed when the package was removed. Return to the SYSTEM > PACKAGE MANAGER menu and install Suricata again from the official pfSense repo. This will pull down the current RELEASE package version.

@Ramosel try to add the false positive to the surpass list. It won’t block it anymore on Snort

@wolfsden3 have you inspected your surpass list and make sure you don’t have extra space or a mistake in that list. I had an issue with one doing this for AppID the surpass list had a half deleted rule i removed and it was causing issues for me until I deleted it and corrected the spaces. I kept having it block a app until I fixed it.

https://rules.emergingthreatspro.com/open-nogpl/snort-2.9.0/emerging.rules.tar.gz.md5 6b3a1466f57848cb5d0924c76bdc97ec This is the correct hash