@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

This post https://forum.pfsense.org/index.php?topic=87247.msg479068#msg479068 lists most of the domain names involved with MS updates.
This post explains you cant whitelist a domain in snort https://forum.pfsense.org/index.php?topic=88914.msg491573#msg491573

Possible work arounds.
If you have WSUS the windows update server that downloads their updates and then push them to the workstations saving MS bandwidth, perhaps you could exclude the snort check during a certain period of time?

If you dont have WSUS, and the workstations download the updates direct, perhaps having those updates carried out at a certain time of day and then having snort disable itself or the rules in question might also be an option.

You might be able to find a cron job to disable snort or some of its rules for a period of time.

Alternatively maybe you could create a route where all MS updates pass through and snort doesnt check that route?

I havent tried any of the above, they are just some ideas which might help.

I'm not logging to ramdisk, its logging to disk, I had in the past (several reboots ago) logged to ramdisk but abandoned that idea due to the fact the ramdisk at the time couldnt do a ramdisk for /tmp and normal disk for /var.

I also figured as theres 9 options each with a max of 10Mb, I figured a 100Mb directory limit should be enough, I could disable that 100MB directory limit option so theres a 100GB plus for the logs to use, just to be on the safe side and see what it does?

Edit. And I havent pulled this yet https://forum.pfsense.org/index.php?topic=101441.0 as I'm still trying to get a secure email server working.

I should know soon if the pcap issue is related to my other post with some sort of file truncation or not.

@sticcino:

The command line for finding Snort processes is like this:

ps -ax | grep snort

Do not include the "u" in the command arguments.  This will show the running Snort processes.  You are running the command with the "-aux" argument and that causes no Snort processes to display.  Run it with just the "-ax" argument.

As @doktornotor posted, Snort and Suricata are professional-grade IDS packages.  They are not "install and forget" packages.  They require constant vigilance and careful tuning in busy networks to identify false positives and weed them out with selective disabling of rules and the use of pass lists.  Remember also, when creating a PASS LIST, you must go to the INTERFACES tab in Snort and assign the new Pass List to the interface.  If you do not, then Snort does not use the Pass List.  Finally, don't forget to restart Snort on an interface when you change a Pass List.  The lists are only read and processed during start up of Snort.

Why don't you run Snort in just IDS mode for a few weeks (that is with blocking not enabled) to get a good feel for the types of alerts that fire in your network?  That will help you identify potential false positives so you can selectively disable those rules.

Bill

I have imported this scheme into mysql https://github.com/firnsy/barnyard2/tree/master/schemas
and after i connected barnyard2 to the db then the size grow from 0-7,8 but after that the db remained at 7.8 mb.

I haven't installed Snorby yet because i wanted to make sure the db was 100% working.

Yes. So install it.

In the same place where you installed it. Simply click the reinstall button.

Not yet known.  That will be up to the pfSense core developers.  I'm just a volunteer package maintainer for Snort and Suricata… :).  It has been posted here and elsewhere this is a planned feature, but no specific version/timetable has been given.

Bill

I just went through several firewalls and I don't see any errors downloading the VRT rules, but I notice the date is August of 2015.  On my dev firewall I forced an update and now even those rules are gone :(

We have not moved our 30+ firewalls to 2.2 due to the issues reported by early versions of 2.2 and VPN - I guess we need to look at this pronto, I did not realize we were running on an usnsupported version :(

Awesome ! thanks everyone for the help with that an explaining what the enable, disable order does.

glad to hear I got the syntax right with GID:SID

off to do some more tinkering with my SNORT set up :-)

You need to examine the ALERTS tab to see which specific rules are triggering alerts resulting in blocks.  You then evaluate the rule in your environment to determine if it is a false positive.  If you determine it is, you can either suppress the alert using the icons on the ALERTS tab; or you can disable the rule completely (again using the icons on the ALERTS tab is the best way).

Bill

Thanks…my issue is either pfblockerng or one of the suricata blocking rules apparently.