I have a SG2440, pfSense 2.4.2…4g of RAM...now I am up to 92% of RAM usage. CPU seems fine...thanks for sharing what you are running seems like you run a lot and a rock solid configuration. I googled your HP Pavilion a6242n...you are running that with 3G of RAM? I have to assume you added more...

I am running pfBlocker and Snort...but it looks like Snort is taking up most of the resources.

I have a lot of rule running but struggled to find rules that are more for management and rules for threats...I understand there is some overlap but are there rules I just don't need for my use?

Looking at your setup...I like the sound of Squid antivirus but struggled with just setting up the antivirus part, is this possible?

@FireBean:

Then why was it even suggested? There is no way to get Snort to tag traffic in a sense for the FIREWALL to drop the traffic in the propper queue?

No, not without rewriting the binary.  It's an IDS/IPS, not a traffic shaper.  The Level 7 inspecting part you saw in the blog post is about inspecting traffic against specific applications for alerting on it or blocking it, not for shaping it.  So the OpenAppID feature of Snort would allow it to identify and drop Facebook traffic or other social media apps, for example.

Bill

@bmeeks:

On the CATEGORIES tab for a Snort interface you will see a column over on the far right labelled Snort SO Rules if you have Snort VRT rules enabled on the GLOBAL SETTINGS tab.  All the categories under that vertical column are the shared-object rules.  If you don't have the VRT rules enabled, then the column is hidden.  So if you are only using Emerging Threats rule, the column is hidden.

Give Suricata a try.  It should work better, but there may still be some issues with ARM hardware.  I've seen some posts with issues in other packages related to ARM hardware.  There are some compiler settings that will likely need tweaking by the pfSense team in order to get all the packages to compile properly for ARM hardware.  There are apparently some byte-alignment issues to contend with in ARM land that Intel land is happy with.

ARM is not a clone of Intel like the AMD processors.  With Intel or AMD, it's pretty much identical in terms of instruction set and memory access requirements.  ARM is a completely different CPU platform and has its own instruction set and a different set of memory access requirements.

Bill

Thanks Bill. Suricata does the trick.

Are you guys by chance modifying and then saving the example files provided on the SID MGMT tab?  They are really intended as examples.  If you edit them to customize the content I suggest saving your changed file with a new name and selecting that name in the corresponding drop-down selectors at the bottom of the page.

The pkg tool used in FreeBSD (and by extension, pfSense) attempts to keep track of all the files it copied/created when installing a package.  It will then attempt to delete all those files when the package is uninstalled or upgraded.  However, if a file has been modified by something outside of the pkg installer routines (as in you, the user, made a change and saved a modified version of the file), then pkg will not remove it.  This might cause issues on the next upgrade of the package.

I have run the package install/uninstall/upgrade process many times in my test virtual machine environment and I've never encountered this error.  I have had pkg leave some files hanging around after an uninstall if I had modified those files myself, though.

Edit:  adding some extra information to my original reply
This error is being thrown by the pkg manager utility that installs all the packages for pfSense.  This is all way before any of the actual Suricata package itself is ready to run, so the error is coming from the pkg-static utility.  It's like it is not installing everything.

Bill

@gsiemon:

Bill,  Thankyou for the quick response.

While appending suricata-4.0 seems to work, on closer inspection of the ET Mailing list entry I think it would be better to base the Rules URL on the full Suricata version number.  They give the following examples:

Suricata 4.0: https://rules.emergingthreatspro.com/$oinkcode/suricata-4.0.0/ Suricata 3.2.3: https://rules.emergingthreatspro.com/$oinkcode/suricata-3.2.3/ Suricata 2.0.11: https://rules.emergingthreatspro.com/$oinkcode/suricata-2.0.11/

Reference: https://lists.emergingthreats.net/pipermail/emerging-sigs/2017-October/028424.html

Perhaps a longer term fix is to append the current package version number to the URL?

Greg

Thank you for the update and the link to the mailing list.  I will look into this.  For now, the issue should be fixed with the new package update released today.

Bill

The code originally threw up an error when an FQDN alias was used.  Maybe that logic got lost when the GUI code was converted over to the Bootstrap interface in pfSense.  I will need to dig into it and see why the error is not flagged when saving the Pass List edit with an FQDN alias.

One possibilty is that if the aliases are nested (meaning actual IP addresses mixed in with an FQDN alias) the code is getting tripped up.  Just out of curiosity, have you tried using a single FQDN alias (in other words, no mixed IP addresses in with it) to see if that generates an error when saving the edited Pass List?

Bill

There is a sticky : Using Snort VRT Rules With Suricata and Keeping Them Updated https://forum.pfsense.org/index.php?topic=124054.0

@jonspeegle:

I can't find anything that explains why this is not working. I'm going to setup a test lab to see if I can duplicate. Could there possible be a bug with the snort implementation in pfsense?

I'm not going to say that is impossible, but it would have to be assumed as unlikely since other rules are firing for you.  If I understood you correctly, once you fixed the HOME_NET issue, you have only that single rule that is not firing the same on both sensors.

If it is a bug, it could be in either place (the DMZ sensor may be incorrectly triggering, or the pfSense sensor my be incorrectly missing it). Does the other sensor use libcap?  I know that's what Snort is using on pfSense.

Bill

thanks. it helped with torrents :)

It should not have blocked your WAN IP, but if it does that anyway, you can manually remove the block two ways.  On the BLOCKS tab you can clear individual or all blocks.  Under DIAGNOSTICS > TABLES from the pfSense menu select the snort2c table in the table name drop-down and clear its contents.  That will remove all blocks inserted by Suricata.

I also recommend folks go to the GLOBAL SETTINGS tab and set the "clear blocks" interval to something 1 hour or less.  That way a cron job will run at that interval and remove blocks that have seen no action during the configured interval.

In your case I'm guessing the power loss and subsequent reboot of your firewall cleared out the snort2c table since that table lives in RAM only.  Blocks from Suricata or Snort are automatically cleared when the firewall reboots.

Bill

Thank you for the quick update

Thank you for the quick update

still open … and keeps crashing.

Either remove bro-ids from options of barnyard2 or try to fix it. Last would more the sufficient way.

Thanks

@bmeeks:

My own Snort VRT rules last updated on November 21.  So probably nothing to worry about.  Either nothing has been needed on the rule creation front for a while, or the Snort VRT folks took a long holiday for Thanksgiving in the U.S. …  :)

You can follow the Snort VRT rules releases here:  https://www.snort.org/downloads/#rule-downloads

Bill

Thank you. As it turns out, yes, I was simply being impatient:

Starting rules update…  Time: 2017-11-29 04:30:00
Downloading Emerging Threats Open rules md5 file emerging.rules.tar.gz.md5...
Checking Emerging Threats Open rules md5 file...
There is a new set of Emerging Threats Open rules posted.
Downloading file 'emerging.rules.tar.gz'...
Done downloading rules file.
Downloading Snort VRT rules md5 file snortrules-snapshot-2990.tar.gz.md5...
Checking Snort VRT rules md5 file...
There is a new set of Snort VRT rules posted.
Downloading file 'snortrules-snapshot-2990.tar.gz'...
Done downloading rules file.
Extracting and installing Emerging Threats Open rules...
Installation of Emerging Threats Open rules completed.
Extracting and installing Snort VRT rules...
Installation of Snort VRT rules completed.
Copying new config and map files...
Updating rules configuration for: WAN ...
Updating rules configuration for: LAN ...
Restarting Suricata to activate the new set of rules...
Suricata has restarted with your new set of rules.
The Rules update has finished.  Time: 2017-11-29 04:32:20

Thank you again for all your very informative help.

Thankyou !

Will be using it to teach myself some things

@kejianshi:

I looked into that, of course, but it was very automatic.  Anything I'd have wanted to add was already there.

Yeah, it was… Since I turned NAT off and made into IP Public, I should put that IP in HOME_NET list.

@EWBtCiaST:

Bill,

Thanks for the reply. I don't think that's the problem as I'm in the U.S. and I was just able to download the rules using a test virtual machine with the same public IP as the one that doesn't work.

Are you running any other blocking packages?  pfBlockerNG, for example.  Some of the IP lists there have blocked access to rules downloads for folks using them.  Do you have a proxy of some sort in use?

The download process is just a simple call to the curl() functions in PHP with the rules URL.  The exact same code is used for all the rules downloads, so if one works that means the underlying code is good.  Otherwise, no downloads would work.

Bill

Related: https://forum.pfsense.org/index.php?topic=139273.15