@keyser

Yes, unfortuantely. I'll look into it.

Thank you.

@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.

@jeffshead
That is correct. Snort/Suricata operates outside the firewall so to speak so it cannot inspect ssl traffic. There is no mechanism within pfsense to decrypt a flow and send to an engine to inspect. This largely,in my opinion, makes the threat prevention aspect of pfsense quite useless. It would be more useful to have your endpoint mitigation tools on the clients do the protection.

@bmeeks I created a list that matches the current rule stub.

Attached here. It works with custom area.

Sorcerer's code file -->> textrules2.txt

@dennism14
Does your home router have a public IP that is it accessible from outside? If he doesn't it won't work with BGP or forwarding naturally.
In this case you can only go with VPN.

If I understand your post correctly, you have devices on your internal networks (LAN) that communicate with a database server located elsewhere on the Internet (accessible via your WAN).

If this true, then you need to simply add the IP address of the remote DB server to a Pass List by creating a list on the PASS LIST tab, accepting the default checked options, adding the IP address of the remote DB to the list using the controls at the bottom of the EDIT LIST screen, then save the new list. Now go to the INTERFACE SETTINGS tab in Snort for your WAN (since your are running Snort on that interface) and select the newly created Pass List in the drop-down selector there. Save that change and restart Snort on the interface.

You do NOT need to be changing the HOME_NET nor EXTERNAL_NET variable settings. Changing those is almost never required. And changing them from the defaults without a full understanding of what they are for and how they work will result in a setup that will NOT trigger rules properly. The fact you altered them in an attempt to solve the problem you describe indicates you may not understand what those parameters are actually for. They define the networks to be protected (HOME_NET) and the networks that are assumed hostile (EXTERNAL_NET). The default setup puts every address/network not defined in HOME_NET in EXTERNAL_NET. Literally, in the PHP code, $EXTERNAL_NET is defined as !$HOME_NET (the leading '!' character indicates a logical NOT operation).

@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.