@bmeeks Thank you for the fast update.

I'm posting this observation separate from my earlier reply because the first dealt solely with adding a FQDN alias to a pass list.

From your shared screenshots from the BLOCKS tab, I assume you are running Suricata on the WAN and capturing these scans from that interface. Understand that Legacy Mode Blocking in Suricata depends on the pfSense pf firewall engine to actually implement the blocks of traffic. Suricata is not blocking the traffic itself. It is simply pulling out the IP addresses in the packets and adding them to a pf firewall table called snort2c.

The default firewall rule in place on the WAN drops all unsolicited inbound traffic already. So, you have the default DROP rule that is going to drop this scan attempt, then you have Suricata adding the IP to an internal pf table that is mapped to another firewall rule that is also going to just drop this traffic. Why do that? You are creating double work on your firewall by essentially dropping the same traffic twice. If you don't actually have any open ports on the WAN side that accept unsolicited inbound traffic, what's to be gained by this double blocking?

Lastly, these SCAN rules are somewhat prone to false positives. The Snort portscan preprocessor is notorious for false positives. There exists "normal" web traffic these days that such rules will misinterpret and trigger on producing a false positive. I suspect that is what's happening in this case.

@SteveITS Thanks, then I will try to install it.

@bmeeks Right! The sg-2100 has the mvnat variant.
I did however improve the stability of the system by making some changes to my auto backup config. Turning of 'creating a backup after each config change', has enabled me to update suricate rules without it crashing. I'll test this evening to see up to which point!

The Snort package on pfSense does not provide the capability for a custom rules download URL.

However, it does provide you with a process to create custom rules. The normal method is via the GUI by selecting a Snort interface to edit and then choosing the RULES tab. In the Category drop-down selector choose "Custom Rules" to view, add, or edit custom rules. The interface provides a textbox where you can paste in text rules. The rules are then saved within the config.xml file for the firewall as Base64 encoded text.

@michmoor said in Unable to load Rules page if no Category is selected.:

@bmeeks
Ive had that syntax as well but had the same error.
Using your syntax

[130204 - Suricata-Main] 2024-03-06 12:55:15 Error: detect: error parsing signature "alert tls any any -> 192.168.50.240 any (msg:"TLS 1.2 Traffic Detected"; tls.version: 0x0303; gid: 1 sid: 1000002; rev:1;)" from file /usr/local/etc/suricata/suricata_38311_igc0/rules/custom.rules at line 1

Interesting, I thought from past experience Suricata would take the GID and really just skip it. Don't recall it complaining about it, but then when I wrote all this code it was way back when Suricata was at the version 2.x stage from upstream.

@bmeeks Thanks for your reply, I have not seen SIGBUS errors before, this is the first time. You were right, it's running on Intel CPU. So I guess I'll wait and see, if it happens again then I'll try to with another RAM module.

@viragomann This has been resolved. I was switching from snort to suricata and I had both packages installed temporarily. Once snort was completely removed it worked as expected.

Thank You,

@RobertK-1 said in Suricata 7.0.2 service stop problem:

@bmeeks -- I've managed to reproduce the problem, and essentially, it's a user error on my part. It turned out that the enabled hardware checksum offloading option caused the interface to bounce during Suricata service stop. If the interface happens to be a WAN interface, then rc.newwanip and rc.start_packages come into play, resulting in a silent Suricata restart. Following best practices and have hardware checksum offloading disabled can help avoid all of these issues.

Thank you for the feedback. The info you provided helped me piece together what is going on.

Some time back Suricata upstream made some changes around the PCAP packet capture mode of operation. PCAP is used in Legacy Blocking Mode with Suricata. When Suricata attempts to bring up a configured interface, it checks for certain options being enabled and attempts to disable them when necessary. Hardware offloading is one of those options. When you disable interface options, FreeBSD will cycle the interface. That leads to the double-start (or apparent restart) issue you were seeing.

It's not something the GUI package code is doing. It's something the Suricata binary used from OISF upstream is doing. Turning off all those NIC hardware offloading options within pfSense is the best fix as then the Suricata binary sees they are not enabled, so it does not attempt to disable them.

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.