@bmeeks yep. They are correctly concentrating on the IDS. For what it’s worth, app filtering should take place on the endpoint much like ssl inspection. So perhaps not a great loss

@pzanga said in No snort alerts for months. Is this normal?: @bmeeks Finally have some time this weekend to test this and have a question. I noted in an older forum post you mention custom rules needing a unique SID. Does that apply in this case, where I would just be editing the conditional of some current rules vs. creating a truly custom rule? Thanks again. If you alter the rule text by copying it into the Custom Rules section on the RULES tab, then yes, you must create a new and unique SID. Or else you will need to be sure the original SID is disabled and not being loaded if you elect to keep the existing SID for a rule you are editing. You do not want the IDS/IPS package to encounter a duplicate SID when loading rules. When you create custom rules, they are written to a separate file that is loaded by the IDS/IPS during startup. After loading the normal rules file, the custom rules file is then loaded and processed. You cannot have duplicate SIDs in those files. The cardinal rule is that you can never have a SID value used more than once in an existing loaded rule set.

@tse-0 said in Suricata Rules Update Drops Internet Connection (briefly): @bmeeks cheers! I found this thread after analysing why I was losing data buffered by telegraf when I brought down my InfluxDB service overnight. I have more than enough metrics buffer configured … Turns out it was a consequence of Suricata restarting the interfaces, which (based on pfsense logs) also causes all my packages to be shut down and restarted… so out go any buffered telegraf metrics… So - TLDR - turning on live swap also cures the need for package reload … which may be important to some. Yes, this is a trick I have often recommended when using Inline IPS Mode as the native netmap device used by that mode will restart the underlying interface each time netmap is initialized. Suricata initializes netmap on each enabled interface as it starts when using Inline IPS Mode. But recently some users have reported similar interface restarting behavior when using Legacy Mode Blocking. That mode uses libpcap, and in the past it never restarted the interface when Suricata initialized PCAP. But Suricata upstream made some libpcap modifications a while back to fix a bug, and one possible fallout from that fix might be restarting the interface when PCAP is activated.

@michmoor said in eve.json log not exported: @bmeeks thanks bill I’ll give it a whirl. What’s interesting is that this is on a low throughput interface and yet the log file grows to almost a gig. Is there a way to tame the eve log file? Should it even be tamed considering it contains important meta data. The only way to tame is to reduce the options enabled on the INTERFACE SETTINGS tab for EVE Logs and perhaps reduce the rules. But I would start with reducing some of the logging depending on circumstances.

Hi, wanted to update to this post because @bmeeks really helped me out here and maybe this will help someone else. I played with disabling various services and it turns out that my problem was caused by vnstatd. I removed that package and my pfsense and suricata has been 100% stable ever since. Not sure what the issue was with that package but I wasn't really using it anyway. Thanks again for the help with this! Really nice to have everything staying stable.

@bmeeks said in Date format Suricata: For example, if you had alerts from January through May, your sorting would be "off". You're right!

@john24634 sorry for a very late reply. Thanks.

@greenflash said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes: @bmeeks In my case the doubled interfaces bug was also fixed with 6.0.10_3 Thanks a lot for your work! Glad you are all set. Thank you for the feedback.

Highly likely this is a false positive. I believe this rule is simply looking for DNS destinations, and as Conficker is now so old and most (if not all) of the C&C sites are gone and likely replaced by legit hosts/traffic these days, the usefulness of the rule can be questioned.

@bitslammer said in Can't Run Suricata 6.0.10_3: @bmeeks Decided not to wait. Went the manual route and it worked fine with those edits. Thanks again. Okay. The manual edit is fine. The updated code makes those checks in a different manner so that PHP is happy and does not complain. That's necessary because of the changes in PHP 8.1 as compared to the 7.4 used in older pfSense editions. The change in PHP behavior is why there are so many GUI code changes in 23.01 (and coming in 2.7 CE) and reports of little annoying bugs related to PHP errors.

@bmeeks That's great! Thx.

@bmeeks Thanks a lot!

@justme2 said in Suricata Pass Lists and Alias (URL/URL Table): Fair enough, sounds good. Thanks! I have it working in a new Suricata package for 23.01 and 2.7 CE Devel. This feature will be in the next update of Suricata that shows up for 23.01 pfSense Plus and 2.7 CE snapshot users. The package version will be 6.0.10_3. Here are some screenshots showing the new feature in action. Defined the URL Table alias under FIREWALL > ALIASES > URLs: [image: 1677348113605-firewall_alias_url_table.png] Assigned the URL Table alias to a custom Pass List on the PASS LISTS tab: [image: 1677348193358-pass_list_url_table_alias.png] Assigned the custom Pass List to the LAN interface in Suricata under INTERFACE SETTINGS: [image: 1677348230198-custom_pass_list_assigned.png] Here is the content of the custom Pass List when using View List on the INTERFACE SETTINGS tab for the LAN: [image: 1677348270718-custom_pass_list_content.png] And here is the suricata.log startup info for the LAN interface showing the custom blocking plugin read and processed the new "IP_Zoom" table alias: [image: 1677348329520-interface_suricata_log.png] Looking under DIAGNOSTICS > TABLES shows there are 3525 entries in this URL Table: [image: 1677348530162-diagnostics_tables_ip_zoom.png]

@bmeeks Restarted the PfSense and now the rules are presented in /usr/local/share/suricata/rules/ and i activated them in the GUI Everything is working fine, thank you for the help.

I will repeat here for clarity something I've mentioned in some other Suricata posts. The Suricata package consists of two unique and separate components. One is a GUI front-end written in PHP. That GUI is what you interact with. It is used to store and manage configuration information for the Suricata interfaces. When you click Save after making a configuration change, the GUI PHP code consolidates all the config parameters and writes them to the suricata.yaml file for the interface. The other piece of the package is the Suricata executable binary that runs as a service. This piece comes from the upstream Suricata developers. That binary is distributed to run on my different operating systems, but it is purely a command-line interface that uses a combination of the suricata.yaml config file and arguments passed on the command line to control its operation. The GUI part of Suricata on pfSense just generates that YAML file and then starts the binary piece with the appropriate command-line arguments. I mention this as a lot of folks seem to misunderstand the distinction between the GUI part they see and binary part they do not. But the binary is where all the real work happens.

@steveits posted there first, before i found out how to check the space, but couldn't delete it afterwards