For Snort, everything is stored within the config.xml file where all other pfSense configuration information is stored. So you when you remove and reinstall Snort all the settings come back. For the other packages, I can't say as I don't maintain those.

Suricata binary reverted to 5.0.4 in the latest 6.0.0_1 GUI package. The latest Suricata-6.0.0_1 package reverts the underlying binary to 5.0.4 from the problematic 6.0.0 version. When the upstream Suricata team releases a new 6.x version (hopefully a 6.0.1 update i the near future), I will revisit updating the Suricata binary to the 6.x branch.

An updated Suricata package has now been posted that officially reverts the Suricata binary to the 5.0.4 version from 6.0.0. The new GUI package is Suricata-6.0.0_1.

Hello, After reinstalling the package, making sure that the option to keep configuration was unchecked and then uninstalled the package and all is gone. Thank you all for your assistance on this, Pasquale

@Smoothrunnings said in I have a couple of questions about snort: @bmeeks Is the performance impact not related tot he firewalls hardware? From what I understand Ubiquiti uses snort, and their UDM Pro which is more powerful than their old gen router/firewall which doesn't hurt the performance much. It's definitely not a i5-4570 inside their UDM Pro or 8GB of RAM. Thanks, Certainly the underlying hardware has a huge impact on the performance of an IDS/IPS. How Snort or any IDS/IPS impacts performance is also heavily influenced by the mode. When running in IDS mode (detection only, no blocking), the impact is very minimal unless you truly have anemic hardware. And with IDS mode, dropping packets (by the IDS) would be unnoticed. IDS mode is a parallel processing path for the packet stream. So a copy of each packet is inspected while the original packet went straight to the kernel stack. With IPS mode (intrusion prevention which means detection and blocking), there is a performance penalty. This is particularly true with inline IPS modes because every single packet pulled from the NIC has to be inspected by the IPS engine and then either passed on to the kernel network stack or dropped. The IPS engine literally sits between the NIC and the kernel stack, and every packet must go through the IPS engine (no parallel path of "copied" packets). And in this configuration, any dropped packets (as in the IPS engine could not keep up with the packet line rate) means interrupted network flow and thus a performance penalty.

Thanks @bmeeks ! You have definitely resolved all my doubts and I'm very grateful for your detailed answers. We will continue working on this setup and comment if we find any problems. Thank you!!

Have you read any of the Snort package documentation here: https://docs.netgate.com/pfsense/en/latest/packages/snort/setup.html? There is also the official Snort documentation for "rule thresholds" here: http://manual-snort-org.s3-website-us-east-1.amazonaws.com/node35.html. In the Snort package on pfSense, rule thresholds are managed via Suppress Lists. Sounds like you need to examine your ALERTS tab entries and determine which specific rule is blocking. Once you do that, you can either disable that rule entirely, or you can choose to suppress it for certain hosts. If you are a new IDS security admin, then I always STRONGLY recommend that you run Snort or Suricata for several weeks with blocking disabled. During that time look frequently at the ALERTS tab for all IDS interfaces and carefully examine what is being detected and alerted on. Investigate the alerts to determine if they are a false positive. If they are, then you need to take some type of action. Either disable the triggering rule, or suppress it (or "threshold it" to use the Snort manual's term) to control the alerting.

@johnha said in Suricata and OpenVPN: after reading a few posts ... I think the answer is to setup suricata on the lan interface rather than the wan or openvpn interfaces ? For the vast majority of home network situations, when you want to run an IDS. the LAN is the best place to put it.

@bmeeks Got it working. Thanks again.

@ng_anon said in Snort problem starting with application enable: Where do AppID SIDS (sig_ids) come from? In the 2017 appid.rules file, the SIDS are in the 70,000 range. I've read that I can create my own SIDS > 1,000,000. In general, is there a Snort master list of GIDS/SIDS somewhere? Each rule author is free to choose their own SIDs with the caveat that there can be no duplicates. So usually individuals writing their own custom rules start at 1,000,000 (one million) and go up from there. I am not aware of any "master list". There are some links you can find on Google that suggest some best practices. Certain of the low SID ranges have been reserved for the Snort team themselves. There is a little bit of info here: https://www.sbarjatiya.com/notes_wiki/index.php/Snort_general_rule_options.

@Cool_Corona said in Should performance differ so much LEGACY/INLINE IDS?: @bmeeks Hi Bill. I am aware of that but a 60% performance penalty?? [image: 1603564417927-ca71a418-2f61-4b8f-8f0b-2528b7189ce1-billede.png] This is the driver used on ESXi. Shouldnt netmap support an igb driver nowadays?? The physical driver is meaningless within an ESXi VM unless you configured hardware pass-through. Since the logs show you using the vmx driver, then it appears pass-through is not enabled. Go look up "emulated netmap adapter" to understand why these virtual NIC drivers don't perform well under netmap. A 60% penalty is not surprising with emulated adapters. And within a VM that is doubled because the vmx adapter itself is already an emulated copy of hardware (but not the real thing). So you have, in effect, an emulation running on top of another emulation. When you use a Virtual Machine, it is using virtualized hardware. You can actually select from several different virtual hardware NICs to use with a virtual machine in ESXi. The actual physical NIC in the ESXi host does not matter as no VM uses that hardware directly unless you enable pass-through to the VM. And pass-through is a one-on-one thing, so if you pass a NIC through to a given VM, then that NIC can't be used by any other VMs nor any virtual switch.

@wolfsden3 said in New Snort 4.0 + = dumb: I'm finding the new snort 4.0 + to be dumb and MUCH HARDER than the older version. It seems like this new version of Snort is trying to solve problems that didn't exist and it's making all new problems. Maybe it's just me, dunno. Any insight would be helpful. If you choose not to enable Inline IPS Mode, then there is absolutely no difference in how Snort 4.x operates compared to Snort 3.2.x -- none at all. If you choose to use the new Inline IPS Mode (and you have a netmap-supported NIC), then you do have to learn a few new things as the underlying technology behind Inline IPS Mode is fundamentally different. If you do not like the new mode, then simply do not enable it and everything will be exactly the same as it was with the older package versions.

@noor92 said in How to whitelist Anydesk (Remote Access Software) in snort?: @bmeeks Thanks for your reply, the answer was short and I ve just got it from another fellow member here, I just need to suppress the alert, please correct me if I am wrong. I would instead suggest disabling those rules. They are highly prone to false positives. Suppressing them still loads them into memory, and CPU cycles are wasted evaluating traffic against them. They just don't generate alerts when suppressed. Disabling them results in them never even being loaded up, so RAM and CPU cycles are conserved for more important rules.

@bmeeks Thank you. Live rule swapping is not active and at the time of the screenshot there was almost no traffic. So I guess it is "bugs" and "virtualization". I run so many because I don't like the flood of alerts, when it runs on WAN and I made a DMZ for every server that I run at home and also I like Suricata blocking the MS telemetry. But I noticed that on a vlan, I only have to run it on the parent interface and not on all vlans separately.

@Impatient thank you for the feedback.

@bmeeks thanks for the update

ps -p PID did not display a package owner/process that had pkg locked - or at least "killall whatIthoughtwaspackageowner"returned an error so I did kill PID and then I was able to reinstall snort some long drawn out steps found online to do this, wonder if I got lucky doing kill PID and having it work? Anyways, all is back to normal and snort is blocking again. The yellow alert is still there, but I have legacy mode and block offenders checked so all being blocked now..I wasn't sure if I had change to inline blocking, the restore from backup showed me I had not. Hopefully the S5 issue will go away also... Thanks all.