@eSht:

User @stephenw10 (a Netgate employee) has posted a potential method for enabling the 2.4.4 pfSense package repo here: https://forum.netgate.com/topic/151709/2-4-5-update-caution.

You can give this a try. Just this time, snapshot your virtualized firewalls before proceeding so if things go way South you can quickly recover.

@JonSmizza said in snort started... or has it?:

@bmeeks said in snort started... or has it?:

Just please don't use RAM disks with the IDS/IPS packages. Remove those RAM disks and put those directories back on a physical disk and I bet all of your Snort issues go way.

Thank you @bmeeks. I was actually wondering if my RAM disks were the issue. I originally started with larger allocations, then reduced them. Which would explain why I was unable to reinstall snort.

I've disabled the RAM disks, rebooted, reinstalled snort and now everything is fine.

Cheers!

Glad you got everything back up ... 👍 . Please help me spread the word, "No RAM disks when using Snort or Suricata!".

It is common for the Snort Subscriber Rules to generate errors in Suricata. Search this forum here for other posts about this. Suricata is not Snort. It does not process nor understand all of the Snort rule directives and keywords. For those it does not understand or support, it spits out an error like you see and discards that rule (so that rule is not loaded). Not all the Snort rules will fail, but several hundred will fail (I forget the actual number). Exactly how many fail for you depends on which particular categories and rules you enable (or that get enabled by choosing a Snort IPS Policy).

Emerging Threats has an optimized Suricata ruleset. The Suricata package loads those optimized ET rules when you enable ET rules. Unfortunately, the free ET rules are more limited. The paid ET rules (ET-Pro) which are up-to-date are way more expensive than the Snort rules. Last I checked the ET-Pro rules were $832 per year per device. Compare that to the Snort Subscriber Rules which cost $30 per year for an individual (non-business subscription). There is no corresponding individual subscription for ET-Pro.

Your flowbit errors are likely due to the failure of other dependent rules to load. You can't do anything about this when you run Snort rules with Suricata. This is one of the limitations of Suricata in my view for small non-business users. The only affordable rules packages are not complete in their coverage. Even when you use Snort Rules, several of them won't load in Suricata.

You may be better served to switch to Snort and use the paid Snort Subscriber Rules; unless you have the coin to pay Proofpoint $832 a year for an Emerging Threats Pro subscription.

@bmeeks

Thanks for the relpy, i tried the reinstall and the install finished normaly :/.
I will try do check out the sync and reinstall again maybe it helps.

bolvar

Hi,
I post this information on this thread because we talk about pass list improvement.
When I check "VPN Addresses" to create a custom HOME_NET list, IPv4 network is OK but IPv6 network of my OpenVPN is not added.

@bmeeks said in Sort 4 Not Downloading VRT Rules:

They really serve no purpose with most of today's hardware (solidstate disk drives and other forms of modern non-volatile memory

I must say this point is well-taken.

I set something up with ELK quite a long time ago as an experiment. It worked, but to get it working I did a wholesale "copy and paste" operation on the log filters from someone's Google page. That was several years ago.

I suggest using a Google search to see if you can locate some recent examples of using ELK to parse Snort data from syslog logs. These filters are highly dependent on the precise content of the log data and the layout of the various "fields".

@NogBadTheBad Thank you for the re-assurance. I can take off my tin foil hat as you say and not waste a month compulsively re-installing pfSense which probably would be from a source with a mismatching checksum anyway.

@NollipfSense Yes.

social_networking.png

LOL I feel ya.
Thing is tho, if you do it/get it started now when Snort3 is actually released you'll be in good standing.

Or alternatively it could be radically different from the beta and need another rewrite 😦 Although I think that is not very likely.

Like I say I very much appreciate your work. Maybe you can put out the feelers for some other devs to help with the rewrite?

@andrewdr said in Record client address in snort:

@bmeeks We are running a mail server and openvpn server so maybe a bit more research before a wholesale change to snort - thanks.

You would be fine to put a Snort instance (or instances) on the firewall interfaces where those servers are located. Hopefully you have them in a DMZ of some sort. If so, then put Snort on the DMZ interface. Remember that Snort is not there to protect the firewall, it is there to protect clients behind the firewall. I say this because a firewall is generally very secure and when properly configured has a very minimal attack surface. Client machines (PCs and servers), on the other hand, have tons of attack surfaces. And the biggest attack surface of all is the human sitting at the client's keyboard clicking "yes" and "OK" to just about every single prompt ... ☺.

@bmeeks BTW Bill, it did sort itself out...I didn't needed to do anything. 😎

@justme2 I am running pfSense 2.5, and Snort 4.0...noticed the same also; however, I have not experienced any performance issue.

Screen Shot 2020-03-18 at 7.21.58 PM.png

For high alerts traffic like that you really need to export the logs off to an external processor and access them there. There is just not enough allocated PHP memory in the pfSense system to handle huge string arrays which are what get created when looking through a huge alerts list in the GUI.

You can use the Barnyard2 tab to export logs to a remote syslog server. You could also probably configure something like an ELK stack and put an export client on pfSense and offload logs that way.

Thanks for the replys! they are appreciated.

I will check them out :)

No, OpenAppID is a Snort-only feature. It was invented by Sourcefire which was later absorbed in 2013 into Cisco along with Snort . Cisco eventually open-sourced some of the OpenAppID stuff and included it in Snort. To date, the Suricata upstream development team has shown no interest in porting something similar into Suricata. If they ever do that, then it will be included in the pfSense Suricata package.

It's really packets per second (pps) that matter in these benchmarks. See, I can send 10,000 8KB jumbo frame packets chock full of data each and then claim about 655 MBits/sec of throughput (8192 bytes x 8 = 65,536 bits per packet x 10,000 packets/sec = 655 MBits/sec). However, if those same 10,000 packets were only 64-byte UDP packets, for example, now my throughput is only 5.1 Mbits/sec (64 bytes x 8 = 512 bits per packet X 10,000 packets/sec = 5.12 Mbits/sec). But in both cases the firewall is essentially doing the same amount of work by processing those 10,000 packets per second. Real world network traffic is a mixture of full-frame payloads and small payloads. When doing performance test benchmarks, especially for "selling points", some amount of "poetic license" is taken to make the results look their best.

So my point is that when comparing raw Megabits/second throughput make sure you know the frame size and the data payload size used for the test. What really matters is how many packets per second the firewall can handle. There is usually no big penalty with the size of a given packet, it's the overhead of processing the packet itself that matters most. To make sure you are comparing apples to apples, find out what frame size and data payload was used for the test. Was the frame's payload completely filled, or was it just a tiny payload?

In terms of tuning Suricata, there are a few articles to be found on the web, but don't expect some precise cookbook process of do this, then this and finally this to get petabits/sec performance ... ☺. The amount of free RAM, the number and types of enabled rules and finally the specific configuration of Suricata's various run modes and CPU core affinity settings determine packet processing throughput. There are also tweakable parameters for the various NIC drivers that influence throughput.

The pfSense Suricata package uses the same general defaults that are shipped in the Suricata source code. There is room for tweaking performance with specific hardware combinations. That tweaking would be a blend of Suricata config changes and adjustments to various sysctl parameters in the OS kernel.

look/ask here if you aren't running it under pfSense:-

https://snort.org/community