Thank you Mr Bill, i will explore it

In a similar vein to manually creating rules as BBcan177 suggested, you can also manually create/edit a Suppress List and add thresholding values to GID:SID pairs.  After creating/editing the suppress list, make sure it is selected as "active" on the INTERFACE SETTINGS tab, and then restart Snort on the interface.

Go to the SUPPRESS tab and either edit an existing list or create a new one and add the new threshold rule.

Bill

Upgrading to 3.2.9.1_14 fixed this issue for me.  This version updates the version of snort so between _13 and _14, it bigger then just a minor change.  Would be great for future changes to snort-pfsense, to be visually apparent when larger changes were made (meaning don't only change the minor version).  I was looking at this for an hour and didn't realize the version of snort changed, outside a few big fixes.  No more errors now w/ the latest pfsense and latest snort (as of this post).

I did notice that there was a snort update, after I applied the update the snort VRT rules worked again.

@vehpbkrby:

Thank you for your help! But I do not operate your suggestions.

See.
I have a few local subnet.
192,168,0,0 \ 24
192,168,1,0 \ 24
192,168,2,0 \ 24
192,168,3,0 \ 24

Pfsense has 2 interfaces (WAN, LAN) and NAT. LAN = 192.168.1.18, gateway = 192.168.1.30 (subnet 192.168.1.0/24)
If I use the default settings home and external network is:
All computers that have Adresse 192.168.1.0/24 subnet can not use Skype. But those computers that have the addresses of the other subnets, such as my computer is 192.168.0.46 address they are using Skype - it is not blocked!

How do I set up what would snort could block Skype from all the local subnet range

Oh, I see.  You have some other subnets behind the pfSense firewall that are not locally attached.  In that case you need to add just those specific networks to HOME_NET along with the default values.  Try this –

1. Create an Alias called ExpandedHomeNet or something else that is appropriate in your view.

2. Add these networks to the new alias:  192.168.0.0/24, 192.168.2.0/24 and 192.168.3.0/24

3. Create a Pass List on the PASS LIST tab and give it a name similar to CustomHomeNet or something.  Leave all the checkboxes enabled (checked) on the Pass List Edit page. In the Address field, enter the name of the alias created in step 1.  Save the new list.

4. Go to the INTERFACES SETTINGS tab for the interface in Snort and in the Home Net drop-down, select the list created above.

5. Click the View List button beside the control and verify the list contains your WAN IP, DNS IP, the 192.168.1.0/24 network, all three of the networks added to the alias and your default gateway IP.

6. Save the changes and restart Snort on the interface.

Bill

Thanks Bill.

I was wondering about that. I'll fix by doing what you suggest.

Thanks.

No, there is no CLI debugging that I am aware of.  I had so many issues with Barnyard2 that I just stopped using it on my personal firewall.  It has not been updated in the FreeBSD ports tree for quite some time.  I don't have another alternative to suggest, but I would not really recommend using Barnyard2 right now because it has several issues in my opinion.  It goes crazy with CPU utilization after rules updates as it does a ton of SQL stuff in the database, it seems to randomly choke on stuff and just stop, and it has issues with referential integrity violations in the database when the references within Snort rules get reordered during updates.

Bill

There's a known problem with netmap. Lots of folks are waiting for the update to drop to see if it solves the issue. Seel this thread: https://forum.pfsense.org/index.php?topic=108365.15

Great, thank you!!

sorry - been a while since I check on this thread.

I was using Inline IPS mode via the em drives.

I can try the legacy mode tonight.  thanks!

i have the same issue..upgrade to (3.2.9.1_14), now the snort unable to start.. please help!!

@ProgressCity:

It Works!

I guess I fiddled with the External List a bit too much. Bill, your explanations really gave insight into some misconceptions and misunderstandings I had about the way that things were parsed with snort rules and how alerts were "matched".    Thank you sincerely for your time and patience on all of this.  I greatly appreciate your efforts!

Glad you got it working.  Generally the content of the EXTERNAL_NET is literally "!HOME_NET", which means any IP address not in HOME_NET is considered to be in EXTERNAL_NET.  In your case, EXTERNAL_NET contained only a single specific IP address; and that one happened to be just the link local IPv6 address.  So basically that rule should almost never match and fire (because the destination would never match your EXTERNAL_NET setting).

A typical Snort setup has HOME_NET set to all the local firewalled networks, and EXTERNAL_NET is set literally to !HOME_NET.  The idea is that HOME_NET contains the networks being protected, and EXTERNAL_NET represents the home of the bad guys (which is considered to be everything not in HOME_NET).  HOME_NET and EXTERNAL_NET represent "source" and "destination" hosts or networks in the rules.  For a given rule, HOME_NET might be the "source" or it might be the "destination" of the traffic the rule is checking.  Only when everything matches will the rule fire.  This includes the direction of the flow, the source and destination networks, the ports (if defined), and the content of the traffic.

So in the rule below, you need traffic containing the "content" given in the rule to be flowing from a host whose IP address is within HOME_NET from any source port to a host in EXTERNAL_NET with a destination port of 3478 in order for the rule to fire.  If anything does not match, the rule does not fire.

alert udp $HOME_NET any -> $EXTERNAL_NET 3478 (msg:"ET INFO Session Traversal Utilities for NAT (STUN Binding Request)"; content:"|00 01|"; depth:2; content:"|21 12 a4 42|"; distance:2; within:4; reference:url,tools.ietf.org/html/rfc5389; classtype:attempted-user; sid:2016149; rev:2;)

Bill

Not sure what happened, but tried restarting the service again a third time and it says that it is running now.

snort Snort IDS/IPS Daemon Running

Here is a great thread of Suppress List contributions from some other Snort users:  https://forum.pfsense.org/index.php?topic=56267.0.  This is just my personal opinion – there are lots of issues with the preprocessor rules in Snort.  They seem to alert on a bunch of stuff that is somewhat common on the web today.  There was a lively discussion about two years ago here on the forum about this and other VRT and ET rules that are really obsolete but were never removed from the rules.  These at best consume CPU resources, and at worst can false-positive.

Bill

My Snort VRT rules just updated.  No more MD5 issues.

same error for me also

Starting rules update…  Time: 2016-07-12 11:06:35
Downloading Snort VRT rules md5 file snortrules-snapshot-2983.tar.gz.md5...
Snort VRT rules md5 download failed.
Server returned error code 403.
Server error message was: 403 Forbidden
Snort VRT rules will not be updated.
Downloading Snort OpenAppID detectors md5 file snort-openappid.tar.gz.md5...
Snort OpenAppID detectors md5 download failed.
Server returned error code 403.
Server error message was: 403 Forbidden
Snort OpenAppID detectors will not be updated.
Downloading Snort GPLv2 Community Rules md5 file community-rules.tar.gz.md5...
Snort GPLv2 Community Rules md5 download failed.
Server returned error code 403.
Server error message was: 403 Forbidden
Snort GPLv2 Community Rules will not be updated.
Downloading Emerging Threats Open rules md5 file emerging.rules.tar.gz.md5...
Checking Emerging Threats Open rules md5 file...
There is a new set of Emerging Threats Open rules posted.
Downloading file 'emerging.rules.tar.gz'...
Done downloading rules file.
Extracting and installing Emerging Threats Open rules...
Installation of Emerging Threats Open rules completed.
Copying new config and map files...
Updating rules configuration for: WAN ...
Updating rules configuration for: LAN ...
Restarting Snort to activate the new set of rules...
Snort has restarted with your new set of rules.
The Rules update has finished.  Time: 2016-07-12 11:07:08

snort security 3.2.9.1_14

@battles:

Thanks.  I was trying to individually suppress a rule for my isp address in Services / Snort / Alerts, and upon clicking the + button, I got this error:

The following input errors were detected:
Suppress List 'wansuppress_57828044c1f52' is defined for this interface, but it could not be found!

Wonder what this is about?

Maybe a previously created/assigned suppress list that was later deleted.  Go to the INTERFACE SETTINGS tab for the Snort interface and set the SUPPRESS LIST to "default" and save the change.  Now go back to the ALERTS tab and try the suppress action again.  When you click the suppress icon on the ALERTS tab, it will auto-create a Suppress List file for the interface and assign it if one does not already exist.  If one is defined in the config.xml, then it will use that one instead.  In your case, one was defined in the config.xml for the interface but the actual content was not in the config.xml file.  This usually means the old list was deleted.

Bill

Looks like snort 3.2.9.1_14 just became available which contains snort-2.9.8.3.  I was able to download my Snort VRT rules and start Snort.