A reinstall removes it and puts it back.  For some reason, in your case, the "puts it back" appears to be failing.  It is removed because when Snort is removed, the widget is useless and can even cause errors because the underlying supporting package is gone. Bill

Thank you so much David for your response. I will give it a try…. thanks again for your help.

@bmeeks: You really do not have enough RAM in that firewall to reliably run Snort.  You are getting this random behavior most likely because you are running out of memory and RAM Drive disk space.  On a Nano-based system, some of your 1 GB of RAM is used to provide the /tmp and /var disk partitions.  That further limits the free RAM available to Snort.  Also, with only 1 GB of RAM to start with, those two RAM Disk partitions are going to be a bit tight when it comes to holding the rules tarball files during updates and even when downloading and extracting the PBI package files on installs.  When you exhaust the /tmp or /var partitions during package installation, weird and random stuff can happen.  I suspect its working when you wipe the settings out because then it is not exhausting RAM during reinstallation when trying to restore the saved settings and download all the previously selected rules at once. The same Snort package has run uninterrupted for months on my firewall with three active interfaces and quite a few rules.  I have never had an issue with a Snort upgrade.  My firewall has a 40 GB conventional hard disk and 16 GB of RAM.  Prior to this one, I had a box with 4 GB of RAM and never had any issues there either.  You need lots of RAM and plenty of disk space for logging to reliably run Snort and Suricata.  NanoBSD is just not a good platform for running these two packages.  I'm not saying it can't work if you through enough RAM at it, but most NanoBSD installs don't have a lot of RAM. Bill snort was running fine for another 35+ hours .. besides i also added freeradius (it would hardly authenticate 3-5  users in the entire day ). and was working fine.. however i got 2gb ddr2 ram for my box (thats its max support. as its single port) and still all is ok .. though i havent enabled the emerging threats .. though i increased space of /var /tmp to 150 MB .. as i fear it will again break things and i would have to remove snort redo all configs. 32gb ssd is being shipped from china via slow boat. waiting for it to do a full blown installation

Reinstall worked.  One of the interfaces did not come back up immediately, but I was able to restart it. <update>  On my second site, the upgrade worked perfectly.  <end update="">Thank you.</end></update>

@Snailkhan: so doing so will put snort form IDS to IPS Mode ? BBCan177 answered your question very well in the second post of this thread. https://forum.pfsense.org/index.php?topic=94003.msg521687#msg521687

@fantasypoo: hmm.. does the same apply to Suricata ?  Default is AC Suricata is a completely different binary code base.  You can't really compare the two in this area. Bill

I have no idea why but reinstalling xml and package worked okay for me.

Yes that feature is already present in Snort/Suricata… see 'Snort Interfaces' Tab, "+" icon at Right. Ah, Thanks.

The Snort package is designed with some defaults to make things easier for most situations.  One of those defaults is the automatic inclusion of all firewall interface networks (other than the WAN) into HOME_NET and the default PASS LIST.  Your situation is different and the defaults sound like they are not what you want. You can fix this by creating custom Pass Lists on the PASS LIST tab.  When creating them, uncheck all the "default checked" options and then only check the ones you want (or none of them).  Use an Alias to contain all the addresses you want in the list. For example, assume you want to create a custom HOME_NET on the DMZ interface.  First, create an Alias under Firewall > Aliases to hold all the addresses you want in the custom HOME_NET.  Remember an alias can contain other aliases (nested aliases), so you should be able to construct a single alias containing all the IP addresses you want.  Next, create a custom pass list and call it maybe MY_HOME_NET or whatever.  In the Pass List dialog uncheck all the default-checked options (unless there are some you want).  Now select the alias you created earlier in the ADDRESS box at the bottom of the screen.  Just start typing the name and it should auto-populate with matching values.  Save the custom Pass List. Now go to the Snort interface (DMZ) where you want to use the custom HOME_NET.  Select the INTERFACE SETTINGS tab.  Scroll down to the HOME_NET drop-down selector.  Select the custom HOME_NET Pass List you created above.  Save the change and then restart Snort on the interface.  It will now be using that HOME_NET.  You can repeat the process for custom Pass List and even a custom EXTERNAL_NET if you want. Bill

@nug: Bang!  All done.  Thanks very much for this mate. Hey just a quick question..  Does Snorby end up going back and filling in the few days that were missing or is there a way I can force it to do that?  Suricata was still running during this time and has all of the alerts in the system. Barnyard2 should see the unified2 alert logs and start sending them over if they have not been auto-archived yet.  You might have to reset the place keeper by removing/resetting the waldo file.  You can probably find some more details on the web with a little searching. Bill

@sensemann: Hi, I have the same snort message. How can I find out, what domain is queried? You would have to enable full packet logging and then run the captured data through a sniffer tool such as Wireshark. Bill

I found this amusing – "pfblocker is the gate in the fence, snort is the more paranoid security guard checking papers for the stuff that was allowed through the gate." I was thinking I would have two security guards using snort and suricata! .. but I guess that isn't really the case.

Well based on you advice i managed to get Snorby up and running, although i haven't started to connect Snort yet from PfSense. Here is what i did so for in case it helps. Your mileage may (and probably will) vary. cd /usr/local/bin $ sudo apt-get install curl $ \curl -L https://get.rvm.io | bash -s stable –ruby source /usr/local/rvm/scripts/rvm $ rvm get stable --autolibs=enable $ rvm install ruby-1.9.3-p551 $ rvm --default use ruby-1.9.3 apt-get install imagemagick gem install wkhtmltopdf gem install bundler #apt-get install libxml2-dev #apt-get install libxslt-dev #mysql -u root -p create database snorby; create user 'snorby'@'localhost' IDENTIFIED BY 'XXXXXXXXX'; grant all privileges on snorby.* to 'snorby'@'localhost' with grant option; FLUSH PRIVILEGES; quit :/usr/local/bin/snorby# cd config :/usr/local/bin/snorby/config# cp database.yml.example ./database.yml :/usr/local/bin/snorby/config# cp snorby_config.yml.example ./snorby_config.yml <edited database.yml,="" changing="" username="" to="" snortuser,="" password="" snortuser's="" pw=""><edited snorby_config.yml,="" changing="" domain="" to="" localhost:3000="">#nano Gemfile REMOVE LINE - gem 'devise_cas_authenticatable', :git => 'https://github.com/Snorby/snorby_cas_authenticatable.git' ADD LINE - gem 'devise_cas_authenticatable', '~> 1.5' #bundle install #bundle exec rake snorby:setup #bundle exec rails server -e production</edited></edited>

Yeah, so what? How the heck does it matter how many of them are incompatible? They simply are incompatible, noone counts them, except for apparently you because you have no better things to do than harassing maintainers with crap, this ain't any bug but well known Suricata limitation with Snort rules. Move on and perhaps try to produce something useful, like submitting patches upstream to make those rules compatible. Besides, your testing skills miserably suck, with a short look at the log noise (which you'd like to flood syslog with!!!) shows 3/11/2015 -- 00:47:02 - <info>-- 3 rule files processed. 15947 rules successfully loaded, 1632 rules failed</info> At minimum, please stop suggesting that everyone's general syslog should be flooded with crap such as: 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"FILE-IDENTIFY GIF file magic detected"; flow:to_server,established; file_data; content:"GIF8"; depth:4; fast_pattern; content:"a"; within:1; distance:1; flowbits:set,file.gif; flowbits:noalert; metadata:service smtp; classtype:misc-activity; sid:23647; rev:5;)" from file /usr/pbi/suricata-amd64/etc/suricata/suricata_13310_em0/rules/flowbit-required.rules at line 850 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Can't use file_data with flow:to_server or from_client with http. 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"FILE-IDENTIFY RealNetworks Real Media file magic detected"; flow:to_server,established; file_data; content:".RMF"; depth:4; flowbits:set,file.realplayer; flowbits:noalert; metadata:service smtp; classtype:misc-activity; sid:23645; rev:6;)" from file /usr/pbi/suricata-amd64/etc/suricata/suricata_13310_em0/rules/flowbit-required.rules at line 853 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Can't use file_data with flow:to_server or from_client with http. 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"FILE-IDENTIFY MPEG sys stream file magic detected"; flow:to_server,established; file_data; content:"|00 00 01 BA|"; depth:4; flowbits:set,file.mpeg; flowbits:noalert; metadata:service smtp; classtype:misc-activity; sid:23640; rev:8;)" from file /usr/pbi/suricata-amd64/etc/suricata/suricata_13310_em0/rules/flowbit-required.rules at line 856 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Can't use file_data with flow:to_server or from_client with http. 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"FILE-IDENTIFY MPEG video stream file magic detected"; flow:to_server,established; file_data; content:"|00 00 01 B3|"; depth:4; flowbits:set,file.mpeg; flowbits:noalert; metadata:service smtp; classtype:misc-activity; sid:23639; rev:8;)" from file /usr/pbi/suricata-amd64/etc/suricata/suricata_13310_em0/rules/flowbit-required.rules at line 859 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Can't use file_data with flow:to_server or from_client with http. 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"FILE-IDENTIFY Adobe LZMA compressed Flash file magic detected"; flow:to_server,established; file_data; content:"ZWS"; depth:3; flowbits:set,file.swf; flowbits:noalert; metadata:service smtp; classtype:misc-activity; sid:35458; rev:1;)" from file /usr/pbi/suricata-amd64/etc/suricata/suricata_13310_em0/rules/flowbit-required.rules at line 1750 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Can't use file_data with flow:to_server or from_client with http. 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:"FILE-IDENTIFY M4A file magic detected"; flow:to_server,established; file_data; content:"ftypM4A"; depth:7; offset:4; flowbits:set,file.mp4; flowbits:noalert; metadata:service smtp; classtype:misc-activity; sid:35433; rev:2;)" from file /usr/pbi/suricata-amd64/etc/suricata/suricata_13310_em0/rules/flowbit-required.rules at line 1762 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Can't use file_data with flow:to_server or from_client with http. 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"FILE-IDENTIFY JPEG file upload detected"; flow:to_server,established; file_data; content:"|FF D8 FF E1|"; depth:4; flowbits:set,file.jpeg; flowbits:noalert; metadata:service http; classtype:misc-activity; sid:35852; rev:1;)" from file /usr/pbi/suricata-amd64/etc/suricata/suricata_13310_em0/rules/flowbit-required.rules at line 1768 3/11/2015 -- 00:47:02 - <error>-- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Can't use file_data with flow:to_server or from_client with http.</error></error></error></error></error></error></error></error></error></error></error></error></error></error> FFS. Ktnxbye.  >:(

@Vane: Thanks for the reply Bill, for current releases is it not possible to add a simple option to block hosts that trigger drop or reject rules instead of alert? Sorry if I am being redundant but I assume there is a way to distinguish between an alert and drop rule even though the packet doesn't drop. For Suricata I think it would be possible, but there would be a potentially big user learning curve.  Let me explain.  Many users of Suricata and Snort on pfSense are not full-time IDS/IPS folks (this is my opinion based on some of the questions asked here occasionally and is not meant as a slight …  ;) ).  They sort of expect to install the package, enable some rules and turn on blocking and have it start blocking hosts.  Having the default state be alerting only with blocking only possible by changing the rule actions would be a big paradigm shift. None of the popular rules packages (Snort VRT and Emerging Threats) provide rules with any kind of action keyword other than ALERT.  So if the package were changed to truly just "alert" on ALERT action keywords and only "block" on DROP action keywords, then users would have to modify their rules to achieve the same type of auto-blocking they get today. Now what I have thought about is an option to switch modes between what I call the "current legacy mode" and a mode such as what you describe where ALERT means alert and only DROP means block.  Doing this in Suricata would be easy.  The Snort package may be more difficult, though.  I took a quick look into the API code used by the blocking plugin, and it was not readily apparent that the rule "action" was provided in the alert data seen by the Snort blocking plugin.  I need to investigate that more deeply to see if I overlooked something.  The Snort code is not well commented in this particular area. Bill

@pointcheck44: I just updated to the latest version of Snort which broke this setup. I tried to edit to add the additional rule file back in, but the syntax seems to have changed. The rules selection section now looks like: # Rules Selection # {$selected_rules_sections} EOD; I wasn't sure where the $selected_rules_section referenced here is. Can I still make the changes as described in this thread to add a large custom rule list? Yes, the instructions in this thread will still work if followed precisely. Bill