The alert simply describes a condition where a potential buffer overflow was observed. This could be a false positive or it could represent an actual attempt at compromise. To figure out which it was, start by doing research on Google about the rule that fired. Use the GID and SID to narrow the search. The GID is 124 and the SID is 3. GID 124 is the SMTP preprocessor. More than likely it is a false positive. If you get one or two now and then, I would chalk it up to false positives. If you get several in a row, or get them quite often, I might investigate further.

The permanent fix for this issue was merged in Suricata package version 4.1.2_2 which is now posted. This issue is resolved.

@wafflez19 Go to the FLOW/STREAM tab and start increasing the TCP Stream Flow Memcap setting. The default is 32 MB (if I recall correctly), but with high core-count processors the default value may need doubling or even quadrupling in order for Suricata to start. The default value works fine on dual and quad-core processors, but higher core counts need much more Stream Memory. In your case, witih 16 cores, I would start with 256 MB and go up from there until Suricata starts reliably. Search this sub-forum for the same error (stream memcap) and you should find posts similar to yours with the solution. One of the posts in the past included the formula to use for calculating the amount of required memory based on your CPU core count.

Generic Protocol Command Decode : ET INFO Session Traversal Utilities for NAT (STUN Binding Response)

What time of day do you have configured for your automatic update? I've found that anything around midnight US Eastern time will frequently fail as that is apparently when the file is being updated on the Amazon Web Services site. No proof of this theory, just an idea ... . The fact a manual update suceeds for you leads me to think you may have that midnight problem. Try moving the update to some other time. I use 0130 (1:30 AM US Eastern Time) and mine never fails. A long time ago, my midnight updates frequently failed. Earlier this week, late at night while testing some Snort code changes, I was uninstalling and re-installing Snort on a virtual machine over and over. Things were going great until around midnight (about 15 minutes before and after, to be exact), then the rules download would fail with the 500 error for the MD5 file just like you are getting. I continued my coding and testing anyway since I didn't need the Snort Subscriber rules for testing, and after about 12:30 AM the downloads started working again.

@msf2000 said in Suricata frequent crashes: What can I do to minimize the risk of these bus errors? Any memory settings? Rule sets to enable/disable? No, nothing really unless you knew precisely which rule or rules were causing the problem. But to complicate things even more, it could be the data in a network packet that causes the issue. It will be pretty random. I know it's not the answer you want, but the only way for now to really not have the problem is to run Suricata on hardware with an Intel-based CPU. That can be an Atom, i5, i7, etc.

@johnpoz said in DNS Servers being blocked: @justme2 said in DNS Servers being blocked: With the roots and TLD servers, they only see the "lower level(s)". A forwarder sees the entire FQDN requested - of every request. RE: minimization, correct. Should have more clearly (or perhaps more generically correctly) stated that the roots and TLD infrastructure may see the full FQDN, but no other 3rd party would have full visibility of all the queries generated by an organization. Generally, roots/TLD infrastructure are uninterested parties due to mandatory involvement. Pfsense unbound config is pretty good out of the box.. I change it to not listen on all, and only the interfaces I want and only query outbound on interface(s) I need. Also change from transparent mode to static type. I also turn off the automatic ACLs and do my own. Yes, when it comes to recursion performance - unbound is particularly good. When tuned on a dedicated box for load - it can be phenomenal for recursion.

The issue I encounter seems related to others who have tried to run inline mode without netmap support; traffic passes for a brief period of time and then all traffic flow stops.

@boobletins Ideally I would like to solve both of the issues, but the WAN latency is a higher priority. I think they are interrelated, but I have no idea which is causing the other. dmesg | grep interrupt igb0: Using MSIX interrupts with 5 vectors igb1: Using MSIX interrupts with 5 vectors igb0: Using MSIX interrupts with 5 vectors igb1: Using MSIX interrupts with 5 vectors igb0: Using MSIX interrupts with 5 vectors igb1: Using MSIX interrupts with 5 vectors vmstat -i interrupt total rate irq1: atkbd0 6 0 irq9: acpi0 2 0 irq16: ehci0 3845256 1 irq23: ehci1 1831351 1 cpu0:timer 2673498411 1035 cpu1:timer 377015655 146 cpu3:timer 376025919 146 cpu2:timer 375885908 146 irq264: isci0 1 0 irq266: igb0:que 0 186663825 72 irq267: igb0:que 1 39564243 15 irq268: igb0:que 2 46355532 18 irq269: igb0:que 3 49144499 19 irq270: igb0:link 2 0 irq271: igb1:que 0 285667733 111 irq272: igb1:que 1 67109876 26 irq273: igb1:que 2 43993156 17 irq274: igb1:que 3 62085685 24 irq275: igb1:link 8 0 irq276: ahci0 9574415 4 Total 4598261483 1781

If your ISP is pulling shady shenanigans, you can: Get a new ISP that doesn't engage in shenanigans Use a VPN to tunnel past their shenanigans /shenanigans

@tsmalmbe The confusion stems from the somewhat primitive way the plugin has to handle blocking. The blocking plugin is actually written as a Snort logging output plugin, and it gets a copy of every alert that is triggered. Unfortunately, the rule "action" is not part of the alert data that is sent to the plugin. So it cannot know if the alert it was copied on was from an alert action rule, a drop action rule or a pass action rule. So it has to treat every alert notice it receives as a "block" or "drop" action. So in your case, the alert is actually just a notification, but the blocking plugin does not know that. So it has to assume the alert is something it needs to block.

Yes, you can specify SSL/TLS settings One limitation I've run into is that you cannot easily send the same logs to multiple destinations directly from Filebeat. You have to either run multiple instances on the firewall or duplex it from eg a central Logstash service to other locations. It has load balancing built-in, but not duplexing.

Great thanks. I certainly understand the ramifications! However my network is designed into segments, for example there is a DMZ, this has an internal addressing scheme. If this zone started poking around other internal zones it would mean there is a breach so I'd want it blocked.

@tsmalmbe said in Snort: Two firewalls, missing a lot of rules although similar configuration/setup (Solved): This was it. What a simple solution for once. Glad you got it sorted out. Snort or Suricata and RAM disks are not good matches. I always recommend no RAM disk when running either of those two packages.

@nambi said in Snort Blocking too much.: @nogbadthebad said in Snort Blocking too much.: Create a VPN, IPsec or OpenVPN, don't allow access through the firewall so you can view your CCTV cameras. If Snort is blocking too much don't set Block Offenders and leave it running for a week or two, then decide what rules to switch off before enabling blocking. Thank You I currently have a VPN for this access but was hoping to leave my mail server and CCTV access open. Read up on how to use Snort and how to use Suppression Lists. Google is your friend for that. Lot's of tutorials out there on how to do that. For your mail server and CCTV systems, look at what rules are alerting (and thus blocking). Determine if they in fact represent false positives in your environment. If so, you can suppress those rules using three different techniques. You can suppress the alert entirely for any IP address, you can suppress the alert when the destination IP address is a specific host or subnet, or you can suppress the alert when the source IP address is a specific host or subnet. There are also suppress (also called thresholding) options for only alerting after a specific number of alerts in a given time period have occurred. In short, there are many options for tuning an IDS/IPS like Snort or Suricata. Google "thresholding and suppression" for Snort. An IDS/IPS is not a package you install and then walk away from and expect it to work without any hassles. Every IDS/IPS requires tuning by an experienced network security admin using knowledge about the unique network environment being protected by the system.

@bmeeks Then I'll just wait. We just started rolling out the 2.4.4 updates to our managed routers when 2.4.4_1 came out. We're holding off on upgrading to it until we finish testing in our office (after the first of the year). Maybe by that time you'll have the 4.1.0 update out and we can just roll with that. Thanks!