@xokia said in Alerts not being blocked: @xokia I think I may know what's going on. These are ageing out of the block list I had it set to 3 hrs. I increased it to 12 hrs That was going to be my first question: what interval has been set for "clear blocked hosts"? When an IP has not seen any additional traffic during the interval set for clearing blocked hosts, then the cron task will remove that IP from the snort2c pf table.

@PiotrIr Thanks for your post and thanks for everyone who replied. Helped me tremendously diagnosing my network performance issues. Performance stats gave me the root cause. I had the "SCADA Preprocessors" (I have no reason to) cause a massive decrease in speed. ...

What you desire is not really possible with Legacy Mode Blocking as it currently operates. It uses a pf table to implement the blocking. That table is created when pfSense initializes or reloads the firewall filter. IP addresses are added to the table, and because the table is the SOURCE and DESTINATION target of some built-in pfSense firewall rules, those IP addresses get blocked when inserted into the snort2c table. There is currently no sense of which interface those block rules apply to. They are global as you surmised. Implementing such a feature would be quite programming intensive as it would require a number of changes both in pfSense itself as well as the IDS/IPS packages.

The "352" is not a line number in the active rules file in this case. Instead, it is alerting you to an error in the Lua scripting for your OpenAppID rules. Something is wrong in OpenAppID, not in the ET Open ruleset. And remember that the Snort binary will always FAIL TO START when it encounters any type of error parsing the supplied rules. This is just the way it was engineered. Suricata will print errors, skip the offending rule, and keep loading the things that are okay. Snort will NOT do that. When it encounters any kind of error, it exits.

@bmeeks You are right. I have "zero" experience with managing an IPS. I really didn't understand what you meant before till I read your post about passlists. I was able to create a custom rule that pass DNS query to my specific domain. Thanks.

@bmeeks I really appreciate your help with answer my questions yesterday. Had to change a few backend services to listen on port 80 or another custom port (if its docker) that still sends data in the clear; in my case port 5100 So to answer anyone else's questions that stumble upon this post. Have Suricata listen in on the backend communications where the servers are located and make sure that backend communication is in clear text and not https. Some folks like to enable https on the backend as well but then you hurt your IDS chances of scanning payloads and alerting. As of now netmap only works on physical interfaces - no vlans. no trunking. I ended up breaking traffic flow to my DMZ segment yesterday due to netmap errors.

This appears to be an extraordinarily out-of-date system! You need to update both pfSense itself and then after that the Snort package. Current versions are 2.7.2 for pfSense and 4.1.6_17 for the Snort package. You are so far behind that pfSense cannot even read the new upgrade info to realize it is outdated. As for Snort, package versions are locked to the pfSense version they were compiled with. Snort in that pfSense branch is years out of date and will never be updated. The current underlying Snort binary version is 2.9.20 and the rules for Snort are locked to the binary version. It's possible the 2.9.9.0 rules package has been deprecated by the Snort team. In your case, the best course of action would be to backup the config, save it offline, then download and install the 2.7.2 CE version of pfSense. After installation, you can try importing the old config backup. Edit: I logged into the Snort VRT site and the rules archive for 2.9.9.0 has been removed. The oldest file there now is 2.9.11 while the current version is 2.9.20. Because rules versions are locked to the binary version, you can only use Snort VRT rules packages that match your binary version. Thus you will have to update both pfSense and Snort to their latest versions if you wish to continue using the package with updated rules.

A new package version (7.0.4_1) has been posted that contains the fix for this problem.

@bmeeks You are correct, I apologize. There were no red blocks in the alerts tab. I wrote that late last night. I will post the log tonight.

@nasheayahu said in Enabled Snort and Suricata Disabled?: @bmeeks said in Enabled Snort and Suricata Disabled?: What version of the Suricata package is installed on your system? [image: 1711426596717-screenshot_20240325_221429.png] Is there another way to verify the version installed? Also, note, I'm running pfSense with Suricate 7.0.4 in a virtual lab on a openSUSE Leap 15.5 Host Server, and its running fine, and no widget crashes. Hmm. That is the most recent version. The error is caused by a blank line in the alerts.log file for the interface. I've never deteremined how the blank line happens, but one theory is maybe during log rotation. You can do either of these to fix the Dashboard Widget problem: Open the file /var/log/suricata/suricata_xxxxx/alerts.log in an editor and find and remove any blank lines in the file. The xxxxx part of the directory path will be the physical interface name and a UUID identifying the specific Suricata interface. Go to the ALERTS tab and click the icon to clear out all alerts. That will erase the file and Suricata will start a new empty file.

@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.