@oak9 said in Converting undesired Snort blocks into suppression list entries: The only cleartext transmissions I've seen recently were around the blocks discussed earlier (updater-related stuff apparently still using HTTP). Some DNS lookups are still cleartext (if you do not have TLS enabled). Most all websites are now HTTPS including most (if not all) of the Microsoft sites. Rules can trigger off metadata without actually looking at the payload. That is what many of the ET-Info rules look at. Examples are source or destination IP addresses, protocols, ports, and certain non-encrypted metadata present in some protocols. SNI is an example of metadata associated with HTTPS connections that is still mostly unencrypted. But that is changing with the coming introduction of encrypted SNI. But metadata analysis is not effective for malware detection. After all, a blackhat hacker is not going to clearly identify his malware unless he is a complete idiot .

ultimately i still have no idea what i'm doing.. just as i think i might have gotten it, something else raises a question that makes me second guess everything.

@bmeeks Oh, I see the PASS list now, it was right below the EXTERNAL_NET in the UI. Also, thank you so much for that explanation on HOME_NET and EXTERNAL_NET. That makes sense the way you've explained it. I really apricate you taking the time to do that. :)

@jdeloach said in suricata inline confusion: @cyberconsultants @jc1976 Just in case you are not aware, Snort and Suricata are not packages that you just install, configure and then forget about like antivirus programs. These packages require constant maintenance if you want to get the full effect of what tasks they perform. i understand that. I just thought that there would be a way to more easily have the benefits of in-line scanning with the easier configuration of legacy.

@steveits I collect descriptions from suppress file: (http_inspect) PROTOCOL-OTHER HTTP server response before client 120:18 (http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE 120:3 (http_inspect) UNESCAPED SPACE IN HTTP URI 119:33 (http_inspect) BARE BYTE UNICODE ENCODING 119:4 All alerts has it's own GID:SID I know that alerts are from SpeedTest because I have done an extensive test.

@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 [image: 1680731299120-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: 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