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.

Run the following command from the shell or    Diagnostics -> command prompt: **  snort -V**

My first guess is you have a duplicate Snort instance running.  That can happen in some rare circumstance with rapid package restart commands. To test this, stop Snort using the icon on the SNORT INTERFACES tab. Next, open a CLI console session and issue this command: ps -ax | grep snort It should show no running Snort processes.  If it does, then you have found the problem.  You would need to kill the duplicate process. If you do not see two processes, report back. The correct way to disable entire rule categories is to uncheck them on the CATEGORIES tab, then click SAVE. Bill

@bmeeks: Could you elaborate a bit more on exactly what steps you performed in relation to the statement above? Thanks, Bill Sorry, coffee hasn't fully kicked in yet. I was only using a WAN interface setup until yesterday when I added the LAN interface to my setup. I will follow up this afternoon when I get home early from work and reconnect my LAN cable which seems to not be connected at the moment. Damn cat!

Thank you Bill. Disabled reputation and snort started. PV.

This is a feature I've thought about but have not gotten around to actually implementing in code.  It is on my long-range TODO list.  If another Snort user on here feels like coding, I welcome submissions and so does the pfSense team. Bill

If you know the characteristics of the traffic you might be able to get it out of Diagnostics > States

Thanks, I will check into it. In the mean time snort is working fine for me. Increased the stream memory cap. It seems to be working fine now but I do have to wonder what else might be broken.

Start to use the IDS in non-blocking mode for a couple weeks. This will give you time to fine-tune the rulesets according to the network characteristics.