@steveits said in Error log help:

https://redmine.pfsense.org/issues/13377

ok thanks! I'll give it a shot when i get home.

@jc1976 There was a thread in recent weeks. IIRC one scenario was when the router had lots of internal interfaces, so running once on WAN was better than running 10-20 instances.

It runs outside the firewall so on WAN it will end up scanning packets that will be dropped by the firewall. Also it cannot identify the LAN IP since it can only see the NATted WAN IP.

@bmeeks thanks for the explanation. Since yesterday the limit seems to work, just checked.

99% chance it is a false positive. A quick Google search for that rule alert description turns up a lot of other false positive posts going back over several years.

@bmeeks said in I would like to check if Suricata is able to analyze SSL communication:

Here is a great read about CAs from Wikipedia: https://en.wikipedia.org/wiki/Certificate_authority.

Yeah : great 👍 😊
When I post this message on this "forum.netgate.com", I use most of all that stuff without needing to know whats going on.

I'm pretty sure that the reader of that wiki page must have to have some knowledge about the subject. If not, he'll be lost after the very first two phrases.

@dbmandrake @jimmychoosshoes @phodge

049f1f8c-728f-452f-a423-d415de931fd0-image.png

Found the actual contact attempt in the pihole logs .. the wife's Macbook Air. Hmm, time to exorcise that laptop.

@nsuttner said in After upgrade from pfsense 22.05 to 23.01 - SNORT is getting a core dump!!!!:

@mcury
Hello,

i'm a little confused now, but I understand the basics. So I need to make this change in the Makefile for the Snort binary. Sorry, where can I find this file, i'm not that deep into the matter!

Thanks so much,
Norbert

No, there is nothing you can do on your end. The pfSense developer team will make the change on their package builder infrastructure for the SG-3100, and then a new version of the Snort package will appear under SYSTEM > PACKAGE MANAGER. It may take a few days for this to transpire.

@edils0n-lima

Não ative o Snort na WAN. Isso é inútil, pois a ação padrão do firewall é bloquear. Coloque o Snort na sua LAN.

Do not enable Snort on the WAN. That is pointless to do as the default action of the firewall is to block. Place Snort on your LAN.

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:

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:

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.