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.

Yes, if you are not put off by the extra work, removing Snort and NOT saving the current config would be best overall.  You would reinstall Snort and then configure it from scratch. The manual fix would require editing the config.xml file and then renaming some directories.  It's doable, but must all be done manually.  The impacted directories will be under /var/log/snort and /usr/pbi/snort_amd64/etc/snort.  I am assuming a 64-bit installation.  If you have 32-bit instead, then that snort_amd64 directory is snort_i386. If you look at the directory structure under the two paths I referenced, you will see the old physical NIC name as part of the path.  Depending on your old NIC card, the string might be "em0", "re1", etc.  There are several variations according to the model of network card in your old box.  The numbers (0, 1, etc.) in the NIC strings would be interfaces.  For instance, on my box em0 is my WAN and em1 is my LAN.  Both are Intel NICs. So you have to rename these folders to match up with your new NIC drivers.  Then in the config.xml in the _<installedpackages><snortglobal></snortglobal></installedpackages>_section you will see all the interfaces defined and the matching NIC name as well.  Those would have to be changed to match your new NIC drivers. Bill

Many thanks.  I was looking to do this, and then stumbled across the pfBlockerNG package which seems to do the trick out of the box. The lists available here seem quite good and work well with pfBlockerNG:  https://blocklist.sigmaprojects.org Thanks for your help.