If your still having this problem edit your snort interface and check under your "WAN preprocs" that you don't have Application ID Detection enabled.

Mine seems to have been enabled with the last update and just realised now.

pfSense 2.1.* is no longer supported so you are running a really old version of Snort. Upgrade your pfSense and try again with the latest version of the package.

If you want to see internal LAN IPs before NAT, you need to run on LAN as well.

Hmmm, WTF… There's something badly rotten with UFS.

@doktornotor:

Excellents, thanks! Going to do the same for suricata as well?

Yeah, I will port the same fixes/features in Snort over to Suricata.  The Suricata GUI code was cloned from Snort's anyway, so they share a ton of functions with identical code.

Bill

Scratch my earlier reply.  I forgot how my own code works …  :-[

The Widget code first verifies an alert log file exists for the interface, then it tails the configured number of entries from it and writes those "tailed" entries to a temp file in the [b]/tmp directory.  The code then verifies the temp file exists in /tmp and then opens it for reading.  The opening for reading is failing in your case, but the error says it's failing because the file does not exist.  However, before the open is attempted, a call is made to verify the file exists, so I really don't know what is going on in your case.

I can add another layer of error-checking to the Widget code and will do so in the next update.

Bill

Snort puts monitored interfaces into promiscuous mode.  This could, I suppose, generate a few more NIC interrupts as the card will be processing all packets instead of just packets sent to its MAC address.

Bill

The entire tarball is not saved (it is downloaded to and extracted in a folder under /tmp and then deleted).  However, the individual rules files (category files) extracted from the raw tarball are save here on the firewall:  /usr/pbi/snort-amd64/etc/snort/rules.  Change the amd64 to i386 if you have a 32-bit install.

Bill

Thanks for the AC-BNFA-NQ this seems to help us here as well.

I want to contribute something I observed and can reproduce:

Situation

HW (old PC) based pfSense in a branch office

Win 2012 R2 U1 based pfSense in our DC

Snort

HW based is running stable with AC-NQ even though it has only 2 Cores and 8GB memory at all

Hyper-V based is running on 12 Cores and 16GB memory, but Snort failed with AC-NQ, the AC-BNFA-NQ does the trick, now it can be not only activated (about 2minutes) faster on all interfaces, instead of one only, it now can be activated on all interfaces and it is running stable now for 3d, usually it turned itself off every 2h to 6h.

A strange side effect on IPSec stability?  :o

We reported https://redmine.pfsense.org/issues/4790 (Titel: Established IPSec Tunnel refused transporting further traffic out of sudden.. it than refuses any rule based traffic to anywhere!).

Even though it should be impossible from my point of view, we observed that since the only configuration change on both tunnel ends is the Snort thing it seems to be an obvious side effect.

This seems to be fixed now as well - and I find this is 'a bit' disturbing..

If you go into categories, select one and click on the icon top right, what happens?

I think it should work  :P

What probably happened is that when we updated the time zone data, your old named zone was moved/renamed/deleted and it defaulted since it didn't know what else to do.

We don't make those edits ourselves, however. We get that data from FreeBSD so it must have changed upstream somewhere.

On WAN? Yes, that's not a problem. That's correct. As said, you need to get this working on LAN to see LAN IPs. Explained above, plus explained here by Snort/Suricate maintainer. Really don't think there's much else to add here.

P.S. Getting rid of double-NAT is a good thing regardless of IDS alerts.

A couple of issues can cause this.  One is Snort did not get restarted when the last change was made to the suppress list.  This should have automatically happened, but perhaps did not.  A second more rare possibility is that you have a duplicate zombie Snort process running and that process is blocking/alerting.

You should have exactly one Snort process per interface where Snort is enabled.  Check that with this command from the CLI:

ps -ax |grep snort

If you see extra Snort processes, stop Snort then kill any remaining zombie processes and then restart Snort.

Bill

There should be sync messages written to the system logs (especially on the destination machine).

I probably forgot to add a "sync trigger" to the new OpenAppID code. I will check that so that when it is enabled/disabled, a sync is forced.

Bill

@simby:

Bill can you please share your list or. PM? Please,..

Here is what I have on my home firewall.  I have not added or removed entries in quite some time…

#"(http_inspect) JAVASCRIPT WHITESPACES EXCEEDS MAX ALLOWED" suppress gen_id 120, sig_id 10 #"(http_inspect) HTTP RESPONSE HAS UTF CHARSET WHICH FAILED TO NORMALIZE" suppress gen_id 120, sig_id 4 #"(http_inspect) NON-RFC DEFINED CHAR" suppress gen_id 119, sig_id 14 #(http_inspect) IIS UNICODE CODEPOINT ENCODING suppress gen_id 119, sig_id 7 #"BROWSER-IE Microsoft Internet Explorer userdata behavior memory corruption attempt" suppress gen_id 1, sig_id 16482 #"ET TROJAN Suspicious Malformed Double Accept Header" suppress gen_id 1, sig_id 2008975 #"GPL WEB_CLIENT PNG large colour depth download attempt" suppress gen_id 1, sig_id 2103134 #"FILE-IDENTIFY download of executable content" suppress gen_id 1, sig_id 11192 #"FILE-IDENTIFY Portable Executable binary file magic detected" suppress gen_id 1, sig_id 15306 #ET SCAN Behavioral Unusually fast Terminal Server Traffic, Potential Scan or Infection suppress gen_id 1, sig_id 2013479 #ET SCAN Behavioral Unusually fast Terminal Server Traffic, Potential Scan or Infection suppress gen_id 1, sig_id 2013479 #ET INFO Packed Executable Download suppress gen_id 1, sig_id 2014819 #(smtp) Attempted response buffer overflow: 1448 chars suppress gen_id 124, sig_id 3 #(http_inspect) UNESCAPED SPACE IN HTTP URI suppress gen_id 119, sig_id 33 #(http_inspect) TOO MANY PIPELINED REQUESTS suppress gen_id 119, sig_id 34

@somosane:

Jim Thompson speaks about QI integration on his blog entry on https://blog.pfsense.org/?p=1724

Will the pfSense Snort packages have QI detection before upstream integration? Not sure how to interpret the blog post.

I won't try to speak for Jim, but my guess is the answer to your question depends on whether or not QI detection is merged into the FreeBSD port of Snort before it makes it into upstream.  If or when that might happen, I have no idea.  I do know that pfSense likes to stay in sync to the maximum extent possible with FreeBSD ports.

Bill

Thanks :)

Thanks everyone for their inputs, especially bmeeks . I recently purchase the gold subscriptions :) ,  time for me to do some reading before asking some noob questions.

Cheers