ET Info and ET Policy are good for threat hunting. For example, im testing out a SIEM. Some of the alerts i get 03/27/2023-09:12:46.731218 [] [1:2019401:37] ET POLICY Vulnerable Java Version 1.8.x Detected [] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 192.168.50.241:51450 -> 192.229.211.108:80 03/27/2023-14:13:39.739567 [] [1:2018959:4] ET POLICY PE EXE or DLL Windows file download HTTP [] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 34.104.35.123:80 -> 192.168.50.241:56415 Like @SteveITS methioned these are not bad per se.

@urbaman75: Generally speaking, HOME_NET contains the IP addresses of hosts on your internal networks that you want to protect. EXTERNAL_NET contains the IP addresses of the "bad guys", or hosts outside your local networks. Most rules for Suricata and Snort look similar to this: alert tcp $EXTERNAL_NET any -> $HOME_NET any .... The first part is the action for the rule. In this example that action is ALERT. Other valid actions are PASS, DROP, or REJECT. The next part is the protocol. In this example, the rule will only trigger when the protocol is TCP. There are many other valid protocols rules may use. The next two parts are the Source IP address and Port that must match. In this example, the source of the traffic must be an IP address that is within the EXTERNAL_NET variable. As I mentioned in an earlier post, that variable is typically given the value "!HOME_NET" which means any IP address not in the HOME_NET variable is considered to exist in EXTERNAL_NET. The "any" is the source port. It may be a specific port or "any" - which of course matches any source port. The final two parts are the destination IP address and port. As described above for EXTERNAL_NET, this example rule requires the destination IP to be an IP address contained in the HOME_NET variable. Again, the destination port in this example is "any". Taken together the parts I outlined above constitute the first "conditional criteria" that must all be true for the rule to trigger. If any of the conditions I described above are not met, then the rule will never trigger. For example, if the source IP is not within $EXTERNAL_NET, then the rule will not fire. Or if the target or destination IP is not within $HOME_NET, the rule will not fire. This is why I lecture folks on the dangers of modifying either EXTERNAL_NET or HOME_NET without understanding what they are for and the consequences of getting them configured wrong. Putting the wrong thing in either of these two variables can render the IDS/IPS powerless to detect threats.

@michmoor said in Trying to get snort to block local client if they have a trojan: will Suricata/Snort drop the flow even tho these are directly connected networks on the firewall and not external (WAN side) No, in Legacy Mode Blocking it will not unless the default Pass List is replaced by a custom one in the manner @jimmychoosshoes describes in his post just above this one. The default behavior for the IDS/IPS packages is to NOT block host IPs from locally-attached networks. They will block external IPs, however, and that accomplishes what is normally required for protection. But when using Inline IPS Mode, there is no Pass List logic involved. Any malicious traffic would be dropped (not forwarded), but only if the detection rule is properly triggered. But one issue with detection is the composition of the HOME_NET variable. That variable will, by default, contain all the locally-attached subnets. And EXTERNAL_NET will, by default, be defined as !HOME_NET (which means all IPs not defined in HOME_NET are in EXTERNAL_NET). Many IDS/IPS rules are written with $HOME_NET and $EXTERNAL_NET as part of the triggering condition along with traffic direction. For example, the vast majority of rules start like this: alert tcp $EXTERNAL_NET any -> $HOME_NET any ..... The very first condition of this rule is that the traffic flow must be from an IP defined in the $EXTERNAL_NET variable towards an IP defined in the $HOME_NET variable. So, the source IP must be in EXTERNAL_NET and the destination IP must be in HOME_NET. Because locally-attached subnets are all included in $HOME_NET by default, this condition would not be satisfied in your example of a device in SERVER communicating with a device in LAN, and the rule would never trigger. While the default behavior of Pass Lists and the HOME_NET variable could certainly be changed by altering the code of the packages, it would generate no end of howling from the majority of users because as I described earlier, Legacy Mode blocking blocks the IP completely. All traffic is blocked. That will result in a lot of problems for your users. And there are just too many false positives these days for that change in default behavior to be workable. The whole premise of the IDS/IPS packages today in pfSense is to protect from external threats. External in this context means beyond the network perimeter as in "the Internet". The packages are not set up by default to block internal threats from one local network over to another. But you can customize the configuration to accomplish that if you desire. Simply create as many custom Pass Lists as required and then assign them to interfaces. Remember that Pass Lists are simply collections of IP addresses, so a custom Pass List can be selected and applied as the HOME_NET variable if needed. That's how you would customize the content of the $HOME_NET variable used in rules. I would probably never monkey with EXTERNAL_NET, though. Leave it set to "default" and that will result in it always being set to !HOME_NET (which is almost always what you want).

@bmeeks Ok wiil do, soory about the mixup

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.