That fixed it — thanks everyone & happy holidays!

In terms of protocol decoders and logging options, Suricata wins hands down. The one feature Snort has that Suricata lacks is the OpenAppID Layer 7 capability. But that feature is really only of use in certain business environments where there is a desire to either prohibit, or severely limit, social media and streaming content access for employees during working hours. OpenAppID really has no valid application in home networks the way I see it.

The threading features net out a wash (or dead heat, if you prefer). But don't put too much faith in multithreading itself when talking about network traffic. There is the reality that a given flow must be processed by the same thread. And to really take advantage of threading with multiple flows, you need an OS stack and NIC driver combination that is very good at implementing RSS in order to actually spread the traffic load over available CPU cores. Having a multithreaded application is only the beginning of what is required to actually realize substantial performance boosts.

Any IDS/IPS package is really running on borrowed time in terms of the future unless you are willing to implement a full man-in-the-middle scheme to break the end-to-end encryption that is so common with all traffic these days. Even DNS traffic is becoming encrypted more and more often. Email has been encrypted for quite a long time now. And nearly 100% of web traffic is HTTPS (so encrypted as well). Without MITM, an IDS/IPS has practically zero visibility into packet payloads. The best it can do is examine the unencrypted header sections (source and destination IP addresses and ports), and maybe catch a glimpse of the initial cert info exchange between server and client to see what domain is being visited. That's pretty much how OpenAppID works. It's not actually looking at the raw data - just some header stuff.

I am not a fan of Snort3. The complete change in how you configure it sort of soured me on it because porting 2.9.x installations over to Snort3 is a large pain (I'm talking here from the point of view of auto-migrating someone's pfSense installation, for example). I also think the Snort team took way too long to get Snort3 out. I'm afraid they may have missed the boat as Suricata adoption increased during that long drought of Snort3's alpha and beta development time.

@bmeeks

This fine tuned it. The issue was with SQUID and SSL use. I needed to just add in the aliasis inside of squid's general setting to pass the traffic to the firewall and not proxy it for Disney plus. It fixed it, no more random issues, and I still have the proxy for the desktop and laptops.

Screenshot_20211219-114824.png

Yeah, this bug is fixed in the DEVEL snapshot branch. To be honest I was thinking that fixed version had been merged over to RELEASE, but it has not.

I will ask the Netgate team to merge the new Suricata package over into RELEASE. In the meantime, making the edit suggested by @SteveITS will correct the issue.

@jonathanlee

And, if they move to make this reply as a DOS move it to HTTP get requests at that point and disable this reply for a pre set timer.

@jc1976 said in Suricata - Snort IPS Policy selection:

they seem to be just templates

exactly, templates created by Bill (do you know that he is the package maintainer here? Suricata and Snort :))

and

pls. take a look for example at one of my home configurations that I uploaded and you'll find out everything

dropsid.conf.txt (in TXT, but TXT does not read, I just put it up in this format because of the forum software)

++++edit:
rename it simply this: dropsid.conf

+++edit2:

or if you want to preserve the original template file (would be a good idea) then, for example:

mydropsid.conf or etc.

@jdeloach said in Snort on LAN, WAN or DMZ?:

@bmeeks
Bill, I agree with you that LAN is the interface that Snort should be run on for the reasons that you state. It would save a lot of confusion for new users if YOU ALL (not sure who YOU ALL is) would update the documentation, help tips in the package and defaults to state this. Right now, all the documentation, help tips and defaults state to configure Snort to run on the WAN interface.

The same should be updated for the Suricata package as well.

You can open Redmine requests to have the documentation updated if desired.

Across interfaces on the same box, "no". Across interfaces on different firewalls, "yes" (provided the two firewalls have identical NIC hardware and the same interface layout).

You can clone an existing interface when creating a new one. That makes the new interface identical to its parent. But this is a one-time event. They do not then auto-sync with each other going forward.

You could accomplish synchronzing rules using the SID MGMT tab feature. Simply assign the same SID conf files to each interface.

@stephenw10

Thanks everyone

snortupdated.JPG

@bmeeks Don't get me wrong I love to talk shop it is its own language talking about firewalls with other people. Thank you for all you do. Have a great day. On Palo Alto's side you have to install certificates on the devices so it is encrypted again as it leaves the firewall to the lan side. Maybe the proxy is encrypted also.

@bmeeks lol ok, thank you very much!

@nrgia said in Suricata 6.0.3_4 Package Update Release Notes (currently for DEVEL only):

@bmeeks said in Suricata 6.0.3_4 Package Update Release Notes (currently for DEVEL only):
The idea for enabling this option would be to not burden the signature analysis/compare engine with needlessly testing packets the OS is probably going to discard anyway and never forward.

I understand, but now I'm concerned about the following use case:

If a special crafted payload is sent in order to avoid the engine, this option will help to evade Suricata.

Are you sure the packets will be droped by the OS? I mean I inderstood the performance gain, but there is any reason for concern about security?

I don't want to trade security for some performance gain.

Just asking you're opinion here, nothing else.

Thanks

You are way overthinking this ... 🙂. The default forever in the package has been to "not drop invalid" (the checkbox was essentially "not checked" because it did not exist), so just leave it unchecked if you are concerned. I simply added the ability for more control over how the application is configured. And don't forget that the overwhelmingly vast majority of all traffic passing through your firewall is encrypted, so Suricata is not inspecting most payloads anyway since it can't peer into encrypted data.

@digdug3 I do have the standalone http log option disabled. I have basic logging (for http and several other ptotcols) enabled for eve output on one interface.
If I disable/reduce logging on an interface, I'd expect to see a load reduction in proportion to the volume of traffic on the interface, be it suricata 5 or 6. However the interface concerned is low traffic and the proportion of http is fairly low. I'm going to play around with it next time though. Thanks.

I read the link back to AbuseIPDB posted in one of the replies in this thread. I don't really see how this fits into the general Suricata use case on pfSense. Sure Suricata can load up some IP list (providing it's in the correct format as specified for IP reputation lists), but the binary has no method of feeding anything back to the AbuseIPDB eco-system.

The best you can do is scrape the text logs, but in my opinion you should not be doing all that work on your firewall. I say that because invariably such tools want to drag in all kinds of dependent packages, and each dependent package you add is a potential attack vector. You increase the attack surface of your firewall and thus reduce security. Better in my view to export the firewall and Suricata logs to an external SIEM type system, and then do your log scraping and reporting from there. That system could also report things back to AbuseIPDB.

In the IT Security world I came from, your firewall has one job. And that job is keeping external traffic out (unless explicitly allowed in), and controlling what internal traffic can go where. Reporting, pretty graphs, and all that GUI fluff should be handled on an external system that is not the firewall.

@bmeeks That's strange, i've disabled:

app-layer-events
stream-events
files

since 2015 (using jflsakfja's list)

@asmirnov said in Suricata doesn't see the traffic:

Sorry, I meant packets. The goal is to understand whether suricata recognizes the contents of packets, maybe I configured something wrong and it does not check

I found this link describing where ERSPAN stats are captured by Suricata: https://forum.suricata.io/t/erspan-type-ii-decpasulation-processing/242. You could try enabling the stats.log feature (on the INTERFACE SETTINGS tab) to see what Suricata is seeing and logging with respect to ERSPAN.

@pfsenseuser2021 said in Snort is not working properly:

I’ve read some posts about snort and vlans and I can’t understand, why the parent interface is involved. As I know on linux a vlan interface should operate like any other network interface - so I can’t understand, why suricata or snort should have problems with this configuration.

I don't understand this either but that is the recommendation. I too have limited NICs on the physical host. I elimnated all vlan configuration within pfsense by virtualising it and making each vlan a member of a separate bridge on the hypervisor. That way, in pfsense, every interface is a assigned regular network adapter, albeit vtnet. Having said that, I've since encountered perfomance issues with suricata 6 (though not with v5) when running in a VM.