@bmeeks: As for the GUI not showing Snort running, be aware that Snort can take a very, very long time to start.  Until it pretty much finishes the startup, it won't write the PID file that the GUI is looking for.  Until a matching PID file shows up, the GUI will display the Snort process on an interface as "not running".  Also, that screen is currently not "dynamic".  This means you need to refresh the screen periodically to see if Snort has started yet.  I have it on my to-do list to make that a dynamic screen in the future. Bill I wanted to confirm this is likely what is happening some of the time.  The start-up time after running filter updates appears to be about 10 minutes and I'm catching it during that time.  I know it was down for several days while I was away (at the start of this post). An "Updating" status in the GUI would be awesome (cause that's what GUIs are for) As often as we get poked and prodded, I'm not a fan of passing internet traffic without Snort taking a peek. Brian

Mine are Intel EXPI9400PTBLK NIC cards http://www.intel.com/content/www/us/en/network-adapters/gigabit-network-adapters/pro-1000-pt-server-adapter-brief.html Bought three of them for $9.99 each off ebay. All working awesome.

i did some little research on snort but i might have missed it on custom rules. but i agree bmeeks :) @ fsansfil. Yes that is true the one that provided the list should have adjust it and he will do that. But the people that asked it in the first place provided wrong information about the way it works i guess so he didn't added it.

@bmeeks: @ckuecker: I dont have blocking enabled at the moment.  I plan on enabling it after some time once I get my rules massaged the way I want them.  Instead of using the auto-blocking feature of snort it would be nice to be able to manually add to the blocked list. I suppose that could be added, but the way blocking currently works anything added would be lost upon a reboot or complete restart of the packet filter.  This is because the pf table used for blocking (<snort2c>) is automatically cleared out by the packet filter upon a restart.  So blocks would not be persistent across reboots. Bill</snort2c> Interesting.. I didn't know that.  However, I rarely reboot so I think that would be acceptable.

@Vlee: Any other suggestions? No other suggestions.  I know alerting and blocking do work, so if you are not getting some specific alerts I suspect maybe the conditions needed to trigger the rules you have enabled are not happening in your environment.  Is your pfSense box set up rather conventionally meaning routable WAN IP (probably dynamic one from your ISP) and the LAN is using auto-NAT (the out-of-the-box configuration for pfSense).  You don't have something weird like bridging or some proxy arrangement do you? Bill

I have since uninstalled it but have not been install it back. The installation never completes. I am able to install it via ssh though but not through the web console. Please see the attached. That is where it get stuck. Any ideas? [image: suricata.png_thumb] [image: suricata.png]

I did reinstall the package, which upgraded it to version 2.1.6 and things are working fine now. Martin

Thanks for all of the replies.  I was able to actually resolve this issue by moving Snort to a different interface.  I was already bridging my wan interface with an internal interface to be able to use my public IPs directly on my servers.  I moved Snort to the internal bridged interface instead of the external one (the wan) and left the firewall rules set up on the external interface.  The firewall on the external interface prevents any unwanted data from entering and ever making it to the internal interface.  Snort therefore no longer sees all of this garbage traffic.  I tested the whole setup by opening up the firewall on the external interface and watching all of the Snort alerts fly in.  As soon as I re-enabled the firewall, the alerts stopped.  My CPU load has been reduced by almost 75% as a result of this.  If you are using a similar setup, you may want to consider doing this as it seems to help quite a bit.

Thanks Bill, much appreciated. I've switched it to UDP and added in further monitoring to ensure I get alerted when the logging stops for a period of time.

Awesome!  Thank guys, that helps me understand a lot! @doktornotor yeah, I think it'd be nice upon reboot to maybe save the blocklist in /usr/pbi/suricata-amd64/local/etc/suricata/blocklists or something with a timestamp.  Then if you wanted to keep them it'd be as easy as creating a Alias URL table to point to that file.

@ciph: @ivor: Is there a reason you're using i386 arch pfSense? No, not really, I dont remember why I choose it when I first installed pfSense (I have been running it for about 2 years now). Maybe it wasnt stable enough back then. But I have made a new installation with 64-bit version now. I know its recommended, thanks :) Nice !

Thanks for the suggestion and the links.  I will check this out.  It would not be too hard to add the ability to provide custom download URLs for additional rules.  The only gotcha is every rules file needs to be unique so the GUI can distinguish them. Bill

You most likely have a required preprocessor disabled.  Make sure the STREAM5 preprocessor is enabled on the PREPROCESSORS tab.  In fact, users should really never disable any of the default-enabled preprocessors unless they are very highly skilled with the operation of Snort. Bill

Got the package updated during 2.2.4 upgrade. Works great.  8)

@digdug3: Yes, you are right, according to the thread they added it to Suricata 2.0 and in the unified2 chain. Can you explain where the current Suricata package is getting its blocking ip's from? Then I'll try to figure it out. From the alert-fast log chain.  The blocking plugin is in the Suricata output chain.  It may be that some additional information is buried in the Packet structure passed to the blocking plugin, but I have not investigated it that deeply yet. Bill

Also, lot of those unsupported rules should work with suricata 2.1.

@Abhishek: google /youtube is getting blocked i whitelisted 1 ip in passthrough  i guess i need to find source rule which is blocking it and remove it since google uses lot of ip range and whitelisting entire range is imposible Correct.  Identify the blocking rule on the ALERTS tab and then click the red X beside the SID to automatically disable that rule for the interface. Bill

@foresthus: Hi there, … Please give this hint. It should be the variable "VRT_DNLD_URL" (snort_defs.inc or snort.inc or snort_check_for_rule_updates.php) which must to be changed. But what ist the new url? thnx a lot. ;) The Snort VRT has removed the rules tarball for Snort versions older than 2.9.7.2, so there is no URL to give you for the 2.9.7.0 version.  With Snort, the version of the binary and the version of the rules tarball must match.  A check is done by the binary to be sure they match up.  This is not a pfSense problem, but is a decision of the Snort team. You need to upgrade your pfSense to a 2.2.x version and then update Snort to version 2.9.7.3.  By the way, version 2.9.7.5 of Snort was just released.  I will be submitting an update for the pfSense package in the near future. Bill

@bmeeks this is working great and I can see now where the vulnerable client is.  Thank you.

I honestly don't think the Snort package is at issue here.  If it was, then I would expect many complaints here of similar nature.  My personal experience is that you do generally want to avoid the period around midnight U.S. Eastern Time.  I would frequently encounter errors then on the nightly downloads.  I moved the update time to 0130 Eastern and no more issues.  I suspected the VRT folks had some kind of server maintenance task running at midnight, but that was just a guess. Since you have problems even with manual downloads, I would look at other basic connectivity problems somewhere.  Is there anything else in the chain like a proxy (Squid perhaps?), another upstream firewall, etc.? Bill