The portscan preprocessor in Snort seems to have a "hair trigger", and in my opinion at least, it produces more than a few false positives.  There are some tuning tweaks available on the PREPROCESSORS tab for a Snort interface.  You can research what the settings do in the Snort documentation posted at snort.org.  I have greatly dialed down the sensitivity settings on the portscan preprocessor on my home firewall.  That has reduced the false positive rate for me. One thing that may contribute to the high false-positive rate with Snort on pfSense is the method used to sniff incoming packets.  Snort puts the interface into promiscuous mode.  This means it's going to see everything, including stuff not really meant for that interface. Bill

@gad_d: Still didnt find any solution to why the Snort update is blocked by squid will be happy if anyone has some direction thanks Does squid log any message that might give a hint what it does not like about the SSL handshake Snort uses for its updates? Bill

I have answered part of my own question.  I used nmap to discover that the device in question is an Amazon Fire TV - not sure why it does not show up on the DHCP lease list. However, I am not sure if these alerts are something to be concerned about?  They seem to be DNS queries for a site with a .pw TLD.  I am not sure why an Amazon Fire TV would be trying to access such a domain.

Thanks.

Yep, that big spike in CPU consumption is exactly what I saw on my home firewall.  Something is weird inside Barnyard2 in my opinion, but like I said, I have not delved into the code to see if I can find out what it is. Bill

Looking into this issue is next on my list after getting Snort converted to Bootstrap.  That is taking priority, and I'm trying not to make any other PHP code changes or add bug fixes until the GUI is good on pfSense 2.3-BETA and Bootstrap. It apparently broke when the web server daemon changed in 2.2.6. Bill

@vingaard: Would anyone in the forum be able to assist me, so both rules fire a alarm in Snort,  I have a gut feeling that the "flow:established" keyword are the differentiator, but i would expect that the PFsense Snort would be able to understand this? many thanks in advance. Well in that case, why dont you remove the threshold and diagnose only the flow…your second rule should be alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:"NF - POLICY - malicious web page access"; flow:to_server,established; content:"GET"; nocase; http_method; content:"evilpage.tld"; nocase; http_header; classtype:policy-violation; metadata:NF,25042015; sid:56001811; rev:1;) F.

Hello, This might be due to a (unintended) extra space as mention in this post https://forum.pfsense.org/index.php?topic=106195.0

Well, after testing the options a few times, I am sad to report that the hardware offloading options with the intel pro/1000 pt is not working for me. The network appeared to function fine otherwise, but the amount of those 0 byte packets generated is unnerving. This is on a AMD kabini system, if it makes a difference.

Thanks for the update, we really appreciate it :) If I can help somehow I'll be glad to. Br,Greg

If your are testing snort, maybe you should skip the "block for 1h" part for "offenders" or reduce to some minutes. I'm already aware of how much false positives there are. Let's say my new modus operandi is to add myself to the exclusion list first and foremost  ;-)

Thank you.  My suggestion would be: 1)  add a global option in pfBlockerNG for blocking entire domains where a DNSBL includes say abcdef.com (I think it has to be global option rather than per list, otherwise you run into trouble on de-duping as you say) 2)  do the combination/de-duping/suppression etc as per normal (so people can override the global behaviour on a per domain basis by suppressing e.g. abcdef.com, but adding ads.abcdef.com) 3)  at the point where pfBlockerNG translates the de-duped list into a conf file to pass to Unbound, check each domain being added:   - if it is a domain: then add it into the conf file with a local zone too - i.e. block the lot   - if it is a subdomain: then add it into the conf file with just a local data entry - i.e. just block the particular subdomain mentioned I suspect you may need to build a list of top level domains into pfBlockerNG to do the last part.  You can't just count dots unfortunately, as abc.co.uk has two (but is still a domain), whereas abc.com only has one. On the crashing point, one way to deal with that is to sort the de-duped list by domain (e.g. invert the character order of each domain string, then sort, then invert back).  Then when you apply the logic in (3), what you'll get is one zone redirect per domain, followed by all the data entries pertaining to that domain - hence no crash. Just a thought as to how you might do it - I suspect it might be a bit more complicated! Good luck, and thank you! Andrew

FOlks, I ws seeing this same exact problem running on an e1000 adapter as well.  I found disabling hardware checksumming in PFSENSE under ->SYSTEM->ADVANCED->NETWORKING stopping all my stream errors.  Its too bad this is an able to be set on an interface by interface basis, as I really only need this on the WAN inetrface, but pfsense is running on beefy hardware and so far everything seems fine performance wise. This was a really tricky error to find, so I wanted to make sure others that try and run suricata on a virtualized pfsense have an easier time than me fixing it. Thanks Mike

I think I found the problem - I forgot to hit save on one of the tabs.  All good now

The problem seems to have been an extra space that got inserted when I copied and pasted my oink code from the snort website.

Here is the solution I found so far : Install the mailreport package. Then setup a rule to email (daily email), log extract from system with a following filter criteria : snort[

Problem again came up. Snort is exiting every few minutes on the same fault message. Jan 31 12:25:45 SnortStartup[32739]: Snort START for WAN(7152_xn0)... Jan 31 12:25:45 snort[33000]: Could not read appName. Line Snort Differs AppKey paltalkfiletransfer -> paltalkfiletran Jan 31 12:25:57 kernel: xn0: promiscuous mode enabled Jan 31 12:29:23 kernel: pid 43186 (snort), uid 0: exited on signal 11 Jan 31 12:29:23 kernel: xn0: promiscuous mode disabled I'm so fed up, worked for a few days without any problem and now the same sh… again.  :-X