@bmeeks Hi, thanks for all the advice, I will definitely remove some rules that are not used. As I said, the problem has been solved with regard to downloads via sites and via torrents, but if I perform a speedtest from speedtest.com for example, the use of the two interfaces reaches 80% and this did not happen before. Basically, now the problem appears only during a speedtest and I don't understand what can cause it since the same amount of bandwidth of the speedtest is also used to download with torrent and in this case snort uses a maximum of 30% of the CPU per interface. Edit: Even when I only set the Policy to Balanced and without ET and Community Rules snort uses 40%.

Glad you got it working for you. BOTH is the best choice for the "Which IP to Block" setting as I explained above.

@publictoiletbowl said in snort and pfblockerNG in one box: hello im totally newbie on pfsense and im learning now running snort and pfblocker in one box could be a problem later on? please give me some advice base on your experience. thank you If you are also a newbie to administering an IDS/IPS such as Snort, I would suggest you not enable the blocking mode. At least not for several weeks. During that period of no blocking, examine the ALERTS tab daily to see what types of alerts are being logged. Research them and determine if they represent potential false positives for your network environment. For those rules generating what you determine to be false-positive alerts, you will want to disable the rule entirely or suppress the alert for certain hosts as you feel appropriate. Administering an IDS/IPS is really for an expert in network security. It certainly is a skill that takes a long time to learn. For the majority of home networks, I don't recommend use of an IDS/IPS. If you are a curious type and want to invest the time to learn about the tool, then have at it. But be prepared for a lot of stuff to get blocked when you enable the blocking mode. Figuring out what is a false positive and what is an actual issue is where the "expert" earns his keep in the IDS/IPS world.

@Waqar-UK said in Snort not updating today: Thanks I will wait for the certificate to propagate Certs, https or whatever TLS is, is never cached. Because you can't cache it .... the cache-in-the-middle can't find info like a time stamp or a (image) file : its all encrypted - just a binary stream. The next time you visit the server it will include the new cert, the browser won't yell and all will be fine again.

See here : https://forum.netgate.com/topic/158412/cert-expired-on-snapshots-pfsense-org?_=1605624244707

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.