@JonathanLee said in Seeking Insight on IPV6 Suricata Alerts – "Excessive Retransmissions" and "Wrong Direction First Data":

SURICATA Applayer Wrong direction first Data

Here is the link in the Suricata docs for this stream rule alert: https://docs.suricata.io/en/latest/rules/app-layer.html#applayer-wrong-direction-first-data.

The short version of the story is that even today, after several attempted fixes within Suricata, the coders of client/server software apps seem to still be able via crappy coding to craft network flows that trip up the Suricata parser. This is basically a harmless error.

As @SteveITS said, the best thing is to disable all the Suricata stream event rules. They are informational anyway and don't necessarily indicate malicious traffic.

@mmarco said in Suricata scheduling rules:

@bmeeks thank you for the very good explanation.

Yes , it fully makes sense what you say. So my idea will not work 😞 .

I don't know how to recalculate rules, so my first thought was to simply save two configuration profiles in some other folder and then swap them, but then I realized that these rules get updated, and if I do this, I will be using outdated rules.

So the only way would be to "tell" frontend to rebuild rules once I change SID management configuration, but I don't know how to trigger that, except perhaps to try to simulate request on GUI.

You could adapt the official Suricata rules management tool from upstream, suricata-update to potentially accomplish what you wish. Here is a link to the official documentation for that tool: https://docs.suricata.io/en/latest/rule-management/suricata-update.html. That tool is packaged and deployed within the Suricata package on pfSense. So, the code is there. It's just not normally used on pfSense.

You will have to adapt and customize the usage of that tool a bit in order to have it work within the confines of the existing GUI code and the logic used with the Suricata package on pfSense. But if you point that tool to the master rules repository and to the output rules directory for a Suricata instance on pfSense, in theory it should be able to construct a suricata.rules file for you. You would just need to duplicate the dropsid.conf and any other SID management files you created in the GUI out to plaintext files in a directory that suricata-update can access and use. I've never tried this, but I believe it could be make to work with some customization.

I have considered a few times in the past attempting to incorporate this upstream tool into the Suricata GUI package code, but have not yet seriously attacked the problem nor analyzed it deeply enough to identify any potential show stopper issues.

That alert is coming from the built-in QUIC-events rules that ship with the Suricata binary.

The events rules are simply informational in nature and don't indicate any malware or other compromise. I suggest disabling that rule or else using the "suppress by SID" feature on the ALERTS tab to prevent the alert the resulting block of a host.

Suricata by default places the physical interface in promiscuous mode, so all traffic traversing the physical interface is seen by all Suricata instances running on the physical interface. That means there is no benefit to creating separate Suricata instances for each VLAN, because a single instance will see the traffic from all VLANs.

You can, to a limited extent, tailor how a given Suricata instance responds to traffic by using customized HOME_NET and/or EXTERNAL_NET variables and making sure all the rules you are enabling use the $HOME_NET and $EXTERNAL_NET conditionals in the rule text.

@farazb59 The “stream” events ruleset seems to generate a lot of false positives. Consider just turning it off, which is what we do.

Curious how any traffic goes through the secondary, if it hasn’t become master?

This issue is corrected in a forthcoming package update. I've posted a Pull Request for review and merging by the Netgate developer team here: https://github.com/pfsense/FreeBSD-ports/pull/1313. Look for a new 7.0.2 package version to appear soon.

@bitslammer said in pfSense Suricata Crashes on Malformed Block List Entry:

@bmeeks I'm guessing the rules that I enabled have grown over time so I'll try to trim them. Oddly this doesn't happen every time which you'd kind of expect. It's a Netgate 3100 so it looks like I need to look at some other options since this isn't upgradeable. Thanks for the quick reply adn happy holidays.

Several memory parameters have new increased minimums in Suricata 7.x. You are probably seeing the impact of those on the SG-3100. Same issue exists for SG-1100 users, too. 4GB is the new minimum, and even that might get cramped with lots of rules (more than 15,000).

If I were spec'ing a box today for someone who wanted to run IDS/IPS (and most folks want to run pfBlockerNG with DNSBL, too), then I would set 8 GB as a new minimum RAM requirement. The new default ZFS install will also chew up much more RAM than the old UFS setup.

Edit: also looking once again at your log snippet post, I see it seemed to be updating the rules as I see a "rule reload" message. RAM usage will increase during rule swaps, especially if "live rule swap" is enabled.

Here is a link to the generic pfSense documentation for the IDS/IPS packages (Snort and Suricata): https://docs.netgate.com/pfsense/en/latest/packages/snort/index.html.

Because those two packages share so much common GUI code, the way they operate is extraordinarily similar. That point is noted in the documentation linked above.

Just be aware that Suricata (and Snort) on pfSense runs a customized binary with a special output plugin compiled in for Legacy Mode Blocking. Also, the GUI in pfSense does everything "behind the scenes" that a user would normally do via command-line editing of configuration files on other Linux or FreeBSD distros. So, many of the online guides you might find for configuring Suricata have limited usefulness on pfSense (at least in terms of providing specific steps to achieve some particular configuration) because they refer you to direct file edits. Those don't work on pfSense because the GUI code rewrites all the local configuration files each time you save a change in the GUI or start the binary. Thus any hand-edits you may have made will be immediately lost.

At best these online generic Suricata guides can give you the overall concept, but then you need to find how some feature is implemented within the package GUI on pfSense. Posting specific questions back to this forum is a great way to get help and learn to use the package. There are quite a few Snort and Suricata users on pfSense. There are also some pinned Sticky Posts at the top of this sub-forum describing how to use certain features of both packages. Remember that anything you see posted for Snort operation likely applies about the same to Suricata. There are some differences, but the overall workflow of the GUI is the same in both IDS/IPS packages.

@giyahban said in Netmap (Suricata) cause crash:

didnt know its not recommended to have vlan with inline mode.

Inline IPS Mode has some limitations. The biggest is that VLANs and other virtual interfaces are not currently well supported. Things like a Bridge or LAGG setup will not work well. VLANs are especially problematic. There is some work happening within FreeBSD's netmap code to make things better, but none of those experimental updates are present in the pfSense kernel yet.

If you want to use Inline IPS Mode, you should only deploy it on plain-vanilla Ethernet interfaces (meaning no VLANs defined and not a member of a LAGG or Bridge). You may get by with running Suricata on the physical parent interface only and NOT on each defined VLAN interface.

@stephenw10 @bmeeks Just a feedback: After I updated my box with the latest RC, it seems the memory issue was fixed and suricata is not being killed by kernel anymore. It is being running for 5 days and no issues since the upgrade. The memory consumption it looks back to normal similar when it was running with 22.05 version. On previous RC, I noted at some point the memory consumption of box was growing continually and gradually until it reached close to 97% just before Suricata process died.

If you mix internal networks into EXTERNAL_NET, you very likely will increase the number of false positive alerts from routine traffic.

If you have specific design goals, it is very easy to provide your own customized rules. You add them by choosing Custom Rules in the drop-down on the RULES tab and then typing in or pasting in the rules you need. They will be combined with any other rules from previously selected categories.

Thanks @bmeeks. That's a shame.

Would be a great feature to be able to add !pcre:covid-19 domain or similar above the other values to ignore as a first match.

Hopefully a valid feature request!

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.

@kiokoman Ugh, thank you! Working now!

The next update to the Suricata 5.x package on pfSense will contain a new option for configuring Suricata to export performance stats over a Unix socket to Telegraf. It will support the input.suricata plugin.

Suricata can produce EVE JSON logs, and that data can be either written to a conventional text file or it can be made available to a Unix socket. So if someone produces a log data parser for EVE JSON, then Suricata can easily be adapted to feed data over the Unix socket. I am not familiar with Telegraf since I've never used it. So I don't know what it is capable of in terms of digesting Suricata's EVE JSON logs. The new feature I mentioned came from a Redmine Feature Request submitted a while back. And that request was specifically for Suricata performance stats (things like packets processed, packets dropped due to load, etc.).

@bmeeks

Kk Sounds good,

Thanks my friend will check it out, and I will ask my isp about that because I am seeing a whole range of ips in the same scope as my public wan ip as well as ips that look to be going to different ip addresses not related to me at all and are on the same subnet as my public wan.

Thanks again.

I have the same problem but also my google home is blocking, i have added some IP adresses of google but not helped me.

Anyone a suggestion about that? I think i am not the anyone that this problem have with Google services.