OK, thanks for your help.  I'll give it a try.

Created a PR to get this removed from the 2.1.x packages feed, since the package is useless now. https://github.com/pfsense/pfsense-packages/pull/1065

That worked.  I was able to delete the Suricata package.  I'm left with what's causing my package downloads to fail, but will create a different topic for that after a 7 GB CentOS download completes in a few hours, if that is successful. Thank you!

What strikes me - people who wrote this really don't seem to have ever run a recursive resolver? Because, exactly as described, you end up with all root DNS servers blocked, plus whole slew of others => totally broken DNS.  Anyone can kill DNS for everyone on the network merely by resolving a bunch of blacklisted domains. If you wanted to prevent damage, you'd block the actual traffic to hosts in that domain. Not block completely innocent DNS servers. [image: 1314029819767.png]

Perhaps you should just stop updating the rules until upstream guys come back to senses. Already reported by someone else as well with different .so - see https://forum.pfsense.org/index.php?topic=98920.0

Bill, you can also use Suricata 2.1beta4. Been using it on linux boxes for months, w/0 trouble. More stable and feature rich than 2.0.8, including CIDR IP Rep, etc.. Considering inline operation in IPS mode. Its now a real must. Malware as small as 20kb get pass the snort hybrid mode of pfsense… F.

@bmeeks: @Music: Will you also be upgrading it to snort 3.0? No, not in the near-term.  No upgrade on pfSense until Snort 3.0 goes full production and is not ALPHA or BETA software.  Also will not happen until the FreeBSD ports maintainer for Snort updates the package here.  Finally, there is a distinct possibility that Snort 3.0 will lose the ability to block offenders on pfSense.  I have not investigated this in detail, but I do know that the Snort team is deprecating the output plugins API that the custom blocking module for pfSense depends on.  If the API hooks the current blocking module depends on are not in Snort 3.0, then blocking won't work. Bill oh when that happens it will become kinda useless. Multithreathed option in snort would be nice that it might run smoother/faster etc when you have more then 1 core in the box you use.

Yeah, we are telling you to pick one and use it… Other than that, you still provided ZERO information to debug any issues.

@MilesDeep: Snort.  So to disable the rule means to force allow the traffic? That's one way of looking at it.  The actual effect is that rule is removed from the list that traffic is evaluated against.  Since the rule is not evaluated against traffic, it can't "fire" and trigger an alert.  This is a per-interface setting, so if you run Snort (or Suricata) on multiple interfaces you can have a rule enabled on one and disabled on another. Bill

Did you by chance disable all the logging options on the INTERFACE SETTINGS tab for that Suricata interface?  Can you post a screenshot of the Logging Settings from that screen? Bill

I update it on 2.1.5 and works great

Hi, NOT a single problem on pfsense x64 v2.15 & Suricata and now updated to pfsense x64 v2.2.4 and Suricata 2.1.6.

Never mind.  It looks like the versioning is correct. Thanks for explaining the downloads. "Services: Suricata 2.0.8 RELEASE pkg v2.1.6 - Intrusion Detection System"

@doktornotor: Upgrade your pfSense. :) Yes just did fixed the issue Thanks

Thanks!  :D

@simby: Bmeeks, will be this in this release? It's not in the currently open Pull Request. Bill

So limited API functionality in a way then. Ok thanks for letting me know, I'll add some exception rules for the monitoring system.  :)

https://www.defcon.org/images/defcon-19/dc-19-presentations/Duckwall/DEFCON-19-Duckwall-Bridge-Too-Far.pdf P115 How can we defend this? • Basically it’s a physical attack – If somebody can plant a malicious device on your network you’re already screwed What has probably not crossed the authors mind is that an insecure network can be used to make a benign device a malicious device, by adding/altering some software. As I've already established there is nothing for vmware workstation to protect against arp poisoning as mentioned in a previous post, that is one area I am looking at amongst a few others, and virtualisation techniques have certainly come along a long way. So far logs for one of the device's are filling up nicely, caught some traffic which needs investigating, only 6 packets throughout the day out of several GB's but still got to get another device setup to do the packet capture with ssl bridging wanside. Learning iptables has been fun, I've never seen so many webpages making it seem complicated. I quite like iptables its quite easy once you figure it out at the command line.

Very strange! Yes, I setup passlist on interface. And restarted it. Yes, the IPs are on "Blocked" tab. But on 08/17 I edit the alias to ad some other IPs, restarted snort again, and voilá. Now it's working perfectly!!!