Hello Bill,

that would be nice ;) many thanks for your dedication.

Thanks doktornotor for the bug report.  It does appear I have some more work to do there with validation of aliases.

Bill

Thanks fsansfil,

yes i think youre right. All alerts came together and was shown as one. I will have a look at this and try to download again.

Great thanks! I just get nervous when upgrading SNORT as once there was a bug that would clear my block list when it wanted to no matter which option I choose for keeping the list.

Replied to you PM on this topic.

Bill

I do recall seeing on the Barnyard2 Github page that OpenAppID events are not supported by Barnyard.

Your new error seems to be related to the general issues the newer Barnyard2 code seems to have with SQL.  I became so frustrated with Barnyard2 and Snorby on my own home firewall installation that I just disabled Barnyard2 last month.  Got tired of restarting it and clearing the signature reference table and all the other hassles.

Bill

Go to the RULES tab in Snort.  In the Category drop-down, select Custom Rules.  That will open a text window where you can type in your rule.  Click SAVE and you're done… ;).

Bill

@Beerman:

Had some troubles to update the package.

Output of the installation process stops sometimes at "…waiting for snort to start...". Sometimes it stops at "... generating interface configuation...".

Even the attempt to remove the package, was sometimes not successful. Output stops at some point. Second try, works...

I tried several times the installation, but no success... Snort was running, but no entry in the web-config.

Then I restarted "php-fpm", and use the IE (before I was using Firefox - v.38.0.5) and installation was OK and did not take long...

I don´t know what helped... My guess is the change of browser, because on console I saw the whole installation process and snort did run after that, but the output stuck.

Unfortunately I tried both together... :-(

I checked again, today.

Removing and installation fails with Firefox 38.0.5

Output at removing of the package stops at:

Starting package deletion for snort-2.9.7.3-amd64...

Output at installation of the package stops at:

Please wait while Snort is started...

But with IE11 removing and installing of the package worked.

Installation took ~ 5 min.

All rules are logged exactly the same way in the same places (ALERTS tab and also the system log if you have that option enabled).  If you don't have alerts from your Snort VRT Community rules, then either none of the those rules have yet been triggered, or you don't have them actually enabled.  The Community set ships with the vast majority of the rules disabled.  You must enable the ones you want to use.  You do this on the RULES tab by selecting the Community rules in the CATEGORY drop-down and then enabling the rules you want to use.

The IPS Policy rules do not false positive very often, so it is normal for them to be quiet.

Bill

@SixXxShooTeR:

increasing the stream memory cap from 32MB to 64MB fixed the issue.

Yes, the old default stream memory setting is too small as of the 2.0.7 release of Suricata.  I will update the default size and make it some larger in the next package update.

Bill

Thx for reply,
ok i understand it now. But the Problem is, that the SRC is my dynamic external IP-Adress, which change ever 24h. So if i understand you right and i whould set the SRC for e.g. Downloads on the supress list, it would block after 24h again. Is it possible to show the real ip from internal lan and not only the external of my isp?

I fired up my VM again and changed every single editable setting on the LOG MGMT tab and they all saved.  I am unable to duplicate your problem.  Is there perhaps a caching server somewhere between you and the firewall that might be serving up a stale copy of the page?  Something like Squid, for example?

Try clearing your browser cache and refreshing the page to see if the changes took.

Bill

The specific character code I'm talking can only be seen if you view the data in a Hex Editor.  The character is "invisible" when viewed in plain-text mode.  It's a trick used to get IP addresses to wrap properly in the narrow confines of the table cells on the ALERTS tab.  I have code that is supposed to strip that out prior to "pasting" content into a Suppress List.  Perhaps for some reason that failed in your case, or there may be some other character in there.

The Suppress List is encoded in the XML configuration as a Base64 string.  You can use an online Base64 decoder site to turn the encoding into regular text.  You can then view that regular text in a Hex Editor.

Bill

Forget the last, I clicked on start WAN1 and both stayed on this time.  Weird.

I will soon be posting the Snort 2.9.7.3 update for the pfSense team to review, merge and then build updated PBI packages.

Bill

The addresses in the packets themselves determine source versus destination.  Maybe I am misunderstanding what you are wanting.

Perhaps what you are asking is how to see alerts so that the WAN is not the only HOME_NET address shown.  To do that, you must run Snort on the LAN interface.  Only there can it display addresses before the NAT rules are applied.

Do a search here on the forum for "snort wan vs lan" and you should get some threads to look through.

Bill

Welps - with openappid, snort crapped out about 2 hours after being fired up. Will try a lengthy test with AppID off.

@alexolivan:

Effectively that part was missing…

The problem but is when users do have dynamic IPs assigned by ISPs... it is impossible to track them or assign them to a white list, as they're dynamic...

But what makes me worry is the feel of no control... the only trace I have is a crude entry on the syslog firewall pointing to snort.2c table as block reason.
My pfblocker or suricata logs do not claim those IPs as alert/blocks... so it is simple and crude firewall block by the sole fact of belonging to snort.2c table... and I do not know what makes an IP to enter this table...

Could you please explain what this table is?

Thank you very much!

I think they were from the SNORT/Suricata Blocked List, if you turn the 'Block Offenders' on.

Figured out my second issue.

Signature Group Header MPM Context was set to Full for just the 1 interface, which is why it was the only one having the problem. Changed it to Auto and now all is well.