Hmm...that crash is not coming from Suricata package code. The PHP file referenced there is part of the pfSense built-in cross-site request forgery code. That file is not included as part of the Suricata package.

Thanks, I will work on it and follow up if I have more questions

@bmeeks said in Which networks get an IDS: Not necessarily. The rules are written assuming the traffic is being scanned in the clear. Good point. I didnt consider that aspect. When looked at it that way then without a Suricata/TLS Decryption process flow then yes...Suricatra would be all but useless to defend. Suricata can at least read DNS or TLS headers to determine a possible threat but in the coming years that will be ineffective once the TLS handshake process is fully encrypted. That just leaves DNS which any publicly available list can be used..... I think i see your point here Bill. For now, its better to have it then to not (defense in depth) so Suricata as deployed will remain. I did find this in their documentation to do TLS decrypt with Suricata link There doesnt seem to be a lot of projects i can find that does TLS decryption and then packet forwarding to Suricata.

@gwaitsi said in Suricata causing crashes - Uncaught ValueError: date_create_from_format():: @bmeeks might explain it. the was a crash the other day for another reason I would delete the alerts log file and let it repopulate with new data. You can try clearing the alerts using the control on the ALERTS tab. But it's entirely possible the code in that tab might crash or complain about the corrupt file since the dashboard widget and the ALERTS tab both read the same alerts log file. If that happens, you will need to manually delete the file from a shell prompt. You can find it in a subdirectory under /var/log/suricata/ named with the interface name and a UUID.

@pftdm007 said in snort exits and doesnt restart after daily ruleset update: @bmeeks The issue re-occured again but this time I ran the CLI command which gave: 9364 - SNs 0:08.14 /usr/local/bin/snort -R _49826 -D --daq pcap --daq-mode passive --treat-drop-as-alert -l /var/log/snort/snort_em4.20049826 --pid-path /var/run --nolock-pidfile --no-interface-pidfile -G 49826 -c /usr/local/etc/snort/snort_49826_em4.200/snort.conf -i em4.200 42037 - S 0:00.00 sh -c ps -ax | grep snort 2>&1 42270 - S 0:00.00 grep snort 81192 - SNs 4:17.87 /usr/local/bin/snort -R _57388 -D --daq pcap --daq-mode passive --treat-drop-as-alert -l /var/log/snort/snort_em4.10057388 --pid-path /var/run --nolock-pidfile --no-interface-pidfile -G 57388 -c /usr/local/etc/snort/snort_57388_em4.100/snort.conf -i em4.100 I take that snort is indeed running on em4.100 and em4.200 ??? Yes, that means Snort is actually running on both interfaces. I need to deep-dive into the PHP code a bit to check out the behavior. It is possible that with recent changes I inadvertently introduced a bug with querying the running status of the Snort processes with the code on the INTERFACES GUI tab. I will fire up my virtual machine and do some testing. I see that earlier in the thread you said you are running pfSense 2.6.0, so I will check there first.

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