Run the following command from the shell or    Diagnostics -> command prompt:

**  snort -V**

My first guess is you have a duplicate Snort instance running.  That can happen in some rare circumstance with rapid package restart commands.

To test this, stop Snort using the icon on the SNORT INTERFACES tab.

Next, open a CLI console session and issue this command:

It should show no running Snort processes.  If it does, then you have found the problem.  You would need to kill the duplicate process. If you do not see two processes, report back.

The correct way to disable entire rule categories is to uncheck them on the CATEGORIES tab, then click SAVE.

Bill

@bmeeks:

Could you elaborate a bit more on exactly what steps you performed in relation to the statement above?

Thanks,
Bill

Sorry, coffee hasn't fully kicked in yet. I was only using a WAN interface setup until yesterday when I added the LAN interface to my setup. I will follow up this afternoon when I get home early from work and reconnect my LAN cable which seems to not be connected at the moment. Damn cat!

Thank you Bill.
Disabled reputation and snort started.

PV.

This is a feature I've thought about but have not gotten around to actually implementing in code.  It is on my long-range TODO list.  If another Snort user on here feels like coding, I welcome submissions and so does the pfSense team.

Bill

If you know the characteristics of the traffic you might be able to get it out of Diagnostics > States

Thanks, I will check into it. In the mean time snort is working fine for me.

Increased the stream memory cap. It seems to be working fine now but I do have to wonder what else might be broken.

Start to use the IDS in non-blocking mode for a couple weeks. This will give you time to fine-tune the rulesets according to the network characteristics.

Yes, if you are not put off by the extra work, removing Snort and NOT saving the current config would be best overall.  You would reinstall Snort and then configure it from scratch.

The manual fix would require editing the config.xml file and then renaming some directories.  It's doable, but must all be done manually.  The impacted directories will be under /var/log/snort and /usr/pbi/snort_amd64/etc/snort.  I am assuming a 64-bit installation.  If you have 32-bit instead, then that snort_amd64 directory is snort_i386.

If you look at the directory structure under the two paths I referenced, you will see the old physical NIC name as part of the path.  Depending on your old NIC card, the string might be "em0", "re1", etc.  There are several variations according to the model of network card in your old box.  The numbers (0, 1, etc.) in the NIC strings would be interfaces.  For instance, on my box em0 is my WAN and em1 is my LAN.  Both are Intel NICs.

So you have to rename these folders to match up with your new NIC drivers.  Then in the config.xml in the _<installedpackages><snortglobal></snortglobal></installedpackages>_section you will see all the interfaces defined and the matching NIC name as well.  Those would have to be changed to match your new NIC drivers.

Bill

Many thanks.  I was looking to do this, and then stumbled across the pfBlockerNG package which seems to do the trick out of the box.

The lists available here seem quite good and work well with pfBlockerNG:  https://blocklist.sigmaprojects.org

Thanks for your help.

Thanks for the reply, with blocking turned off everything started working great a couple of hours after. I will continue to tweak to get it right eventually.

No, those are not the files.  The one with "u2" in the name is a Barnyard2 Unified Log file.  Those are binary.  The filename should be "alert".  Try stopping and restarting Snort.

Bill

It is strange the file disappeared.  Glad you got the problem sorted out.

Bill

No, there is no way to put Aliases in the template.  At the time the template is being read/used by the code, all Aliases have already been de-referenced into their actual string values.  In other words, they are no longer "aliases" at that point.

You will have to put them as straight strings just as if you were using Snort on a plain FreeBSD box with no GUI.

Bill

These are typically noisy rules that can be disabled.

Thanks BBcan177.  I came back to post that link, but you beat me to it… :D.  Apparently the pfSense Team is doing some house cleaning related to how packages are versioned.  They decided to drop the binary version tag and just show the GUI package tag.  The actual Snort package is not updated.  Only the tags in the Package Repository have been edited, and that makes the package manager in the firewall "think" a new version is posted.

Bill

Glad you got it sorted out, and thanks for the feedback!  It may help others who encounter the same problem.

Bill

@Ruddimaster:

Hi Bill,

thanks for your reply.
so in that case, I'm not able to protect my web server, if my costumer (web designer) use a dynamic Internet access, because they work intensive on that machine and therefore rapidly blocked.

Or is there a work around?

Dirk

Is there a specific rule that is firing?  If so, just suppress the alert or even disable the rule.  You can even do that for multiple rules if you determine they are false positives.  If the rules are firing on actual threats, then it's a good thing the customers are blocked… ;).

I am going to guess that you are probably seeing alerts from the HTTP_INSPECT preprocessor since you mentioned a web server.  Many of those rules will false positive with today's web content.  They enforce a very rigid adherence to all the RFCs, and unfortunately lots of web content today does not always strictly adhere to the RFCs.

Bill

@ghkrauss:

Gentlemen:

A heads up with respect to Suricata. I have Suricata the most current verison (Pfsense Package List) installed. It does not seem to run correctly with Pfsense 2.2.2. It installs, updates, a shows to be running but registers no alerts in a period of hours. We have a 100 M/s fiber connect so there is more than ample traffic. I reverted to Pfsense 2.2 and apparent normal operation returns.

I have and additional question. When using Pfsense 2.2 and Suricata the following alerts are produced

SURICATA STREAM ESTABLISHED retransmission packet before last ack

Show I add these to a suppress list? What caused this repeating messages? Can I fix this issue?

Thanks for any help

G. Howard Krauss

That alert is from the Suricata stream processor.  You will the triggering rule and many others in the stream-events.rules file (look on the CATEGORIES tab and then select stream-events in the drop-down).  You can disable that rule and any others that you consider false positives or noise.  Suricata is extraordinarily chatty with these stream alerts.

Bill

Full install, virtual on hyperv 2012 r2, HD with 20+ GB free space.

Not a huge deal, I am getting pretty good at rebuilding after things get wonky after upgrades - has happened 3 times in past 12 months (different things each time). Am back in business now. Gave me an excuse to clean a few leftovers out of the config file too.

Since no one else is reporting 2.2.2 breaking suricata, it must have been something specific to my install…