Hi, I have the same error, I have 2 pfsense server, the pfsense-A doesn't have that problem and Update all.
But the pfsense-B(VM) have a pfsense out of the box whitout any config extra, just snort. this server have the same Snort Oinkmaster Code that Pfsense-A, maybe that's the problem?

Suricata upstream removed CUDA support two years ago. Here is the upstream pull request that removed it: https://redmine.openinfosecfoundation.org/issues/2382.

So with the feature removed from upstream, that also makes it unavailable on pfSense. But the pfSense package never supported CUDA anyway. There are currently no plans for such support.

@Simbad said in reinstalling snort problem:

Hi!

After reinstalled snort, i dont see snort in menu & recive this error:

PHP ERROR: Type: 1, File: /usr/local/pkg/snort/snort.inc, Line: 2340, Message: Allowed memory size of 402653184 bytes exhausted (tried to allocate 301989888 bytes) @ 2020-01-12 08:29:01

How can I complete the installation without previous configuration?

It looks like from that message that PHP itself ran out of available memory. That particular line of code in the snort.inc file indicates you have something miconfigured perhaps in your SID MGMT files.

You can try these steps to recover.

Make a backup of the firewall's config.xml file. Under DIAGNOSTICS > EDIT open /conf/config.xml. Search through that file and find this line in the XML code: <auto_manage_sids>on</auto_manage_sids> Change the "on" to "off" and save the file.

That will tell Snort not to use SID MGMT. Delete the package and reinstall.

Since your installation is not completing, you likely don't have a Snort menu option under SERVICES, so you will be stuck with manually editing the config.xml file. That is very dangerous, so make a backup before making any modifications to the file.

@jpgpi250 said in Is this something that will be part of suricata in the future?:

On reddit, there is a topic, discussing code, added to suricata to detect, among other things, DOH connections. I wonder if this feature will ever make it into the pfsense version of suricata, detecting and possibly blocking DOH might be a real benefit for users that absolutely want to prevent it. GitHub code here.

Only if and when that code is merged into the offical upstream release of Suricata. The pfSense package uses the upstream binary. The only patch applied is to incorporate the custom blocking plugin.

So if Suricata upstream accepts and merges that programmer's code edits, then it will appear in pfSense when the Suricata package updates to the latest upstream binary. If the programmer does not submit it to the Suricata upstream team via their Github site, then it will never make it into pfSense.

The solution was just upgrade to pfSense 2.5-dev...now, running Suricata inline mode WAN and Snort inline mode LAN...like it so far, especially having Snort preprocessors on LAN in inline mode.

The option to specify a custom file-store logging directory is now available in the latest 4.1.6_1 version of the Suricata package. See the Release Notes in this post: https://forum.netgate.com/topic/149490/suricata-v4-1-6_1-package-update-release-notes.

@kiokoman

THX! System is up and running :)

The Suricata package has a SYNC tab where you can configure the package to send its settings to one or more identical pfSense hosts. The two boxes must be identical in terms of hardware up to and including NIC types and port assignments (i.e., which one is LAN, WAN, etc.). All the SYNC does is copy settings such as configured interfaces and rules.

There is no sort of state sync or any other type of realtime data exchange between the synced packages. So not exactly HA in the true sense, but it does give you a twin version of the package should the active firewall go down and the standby takeover. However, in terms of Suricata, there would be a traffic disruption of sorts since the standby version coming online will have no idea what TCP streams the other host was seeing/handling. And there is no synchronization of blocked hosts.

Thanks for the feedback

i took a look at the multiple snort interfaces, and they werent using all that much. There were a couple plugin processes that were using a lot, and i thought at least one had a memory leak, because when i rebooted the memory use went down. But after a couple days, same thing.
so amazon to the rescue; plugged in another 16gb which was dirt cheap, and now it is using about 31% of the 24gb, so all is well. cpu usage was never an issue (about 23% as i write this, i have seen it goes as high as 80% but thats rare and very temporary)

so im done, i have everything installed i needed (and some plugins i just wanted to play with), and it runs everything im throwing at it, so im happy.

Lucky i got this version; not sure the less powerful ones would do what i am asking.

@lucas1 said in Snort Subscriber rules:

@NogBadTheBad

It was:
Downloading Snort Subscriber rules md5 file snortrules-snapshot-29120.tar.gz.md5...

has become:
Downloading Snort Subscriber rules md5 file snortrules-snapshot-29150.tar.gz.md5...
Done downloading rules file.

The reason was found by another employee.
It's called try guess.

Oh... you were not running the current version of the Snort binary. I assumed you were, so my mistake on that.

The Snort team periodically ages out and discontinues rules support for older Snort versions. The rules are tied to specific binary versions, so you can't use the Snort rules from the 2.9.12 binary with the later 2.9.15 binary.

So the moral of that story is keep your Snort package updated to the current version. I do my best to keep the Snort version in pfSense-RELEASE current so the rules downloads/updates will work.

The 422 HTTP error was the Snort web site's roundabout way of saying that file version your Snort package was requesting was not present.

Now, if you are using Snort Subscriber rules with Suricata, then it is your responsibility to log into the Snort rules web site periodically and check which version is current for the 2.9.x rules. You then have to manually configure Suricata to download the correct version. See this Sticky Post at the top of this forum: https://forum.netgate.com/topic/110325/using-snort-vrt-rules-with-suricata-and-keeping-them-updated. One big warning! DO NOT use the Snort 3.0 rules with Suricata! You will completely break your Suricata installation if you try that. The only way to recover it would be to remove it and install everything fresh again.

Your post was a bit ambiguous as to whether you were running the Snort package or if you were running Suricata and using the Snort rules. I made an assumption that may have been incorrect.

Thank you so much guys for your reply. I will go ahead a disable the rule.

@scorpoin said in Pfsense Snort not blockig:

@NollipfSense said in Pfsense Snort not blockig:

You said you just installed Snort...how do you know it's not blocking? Did you visited a site that's supposed to be blocked, yet you went to the site?

Its not blocking when I try to connect my openvpn client it does connect me to my vpn server which suppose to be blocked as per rule?

Regards

The default Pass List will whitelist locally attached networks including your VPN. If you don't want that default action, then you will need to create your own custom pass list.

Modbus is for industrial control systems. It is not used in business or home networks (typically).

This forum is for users of Snort on pfSense only. There is no support for Windows versions of Snort available here.

@mind12 said in Suricata blocks traffic without alert:

@bmeeks said in Suricata blocks traffic without alert:

2024772

Never mind, that command just changed all the flowbit rules to alert using the dropsid.conf.
I was confused by the name of the file dropsid.conf that it can't change anything to alert only to drop.

It's the drop-down selector where you pick the file that determines the action (changes for drop, enable or modify) and not the filename. You can choose any file for the action and whatever matches the PCRE in that file produces are then used for finding and modifying rules.

For some reason, there're no pcap files in /var/log/snort/snort_*/
Log management tab is:
cb7ae7d7-5e59-41f6-9bf5-31eed92ca9c7-image.png
Snort is running:
ad0354a4-833a-4b9e-8f3b-d32c8bd015cb-image.png

Could anyone point me on how to enable them, please?

Thanks for your reply and your explanations. Even if it is not the answer I wished, it helps not loosing anymore time searching in a wrong direction.

Thanks

Have a nice day

Screen Shot 2019-12-13 at 2.20.10 PM.png

Hello

No more crash this weekend. I have launched a manual backup on friday to test and the memory usage hasn't increased. I will still wait for a week but I think the solution is good.

Thanks a lot to @bmeeks for the help.