@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.

ah that make sense

It's hard to say without having a full diagram, but what the note I linked to was essentially saying is if there is a way for a connection to be see on more than one interface, or if there is a way for the some traffic to take one route while other traffic can take another, and these alternate routes allowed traffic to escape notice by Snort, then you would have the asymmetric issue. Maybe the firewall is it, but I'm not too sure it is.

@bmeeks Thanks for the reply. But it's not really the physical (OS) interface that is recorded in the config file either - it's entry name in the pfsense interfaces config hash (e.g. "opt7"). So Suricata is already looking that up with get_real_interface() to find the OS interface name (e.g. "ovpns4"). The problem lies though in keeping things in sync - since you can change the interface description at any point, we really must use the interface value instead. I could still imagine an option for the sync process to use the interface description somehow - but this would be much more complicated than the current process.

@bmeeks "Should" still doesn't mean "must", which is especially important when you'll consider that there's no warning before actually starting blocking mode. The fact I knew about that was only because in Suritaca I had a lot timestamp alerts, which Internet told me, was related to the hardware checksum being enabled. ;) But like I said - I did turn all of them off with Suricata. I didn't know that it's also needed for Snort until I turned on blocking mode, because there was no indication for that before. I will turn them off for the testing phase! :) pfSense version: 2.4.5-RELEASE-p1/FreeBSD 11.3-STABLE BTW Thanks for the explanation!

@Cool_Corona said in Suricata needs a reboot after change to alias/suppress list: Nope. No service watchdog installed. Good! It is not compatible with the Snort or Suricata packages as they run multiple copies of their daemon when configured on multiple interfaces, and Service Watchdog does not know how to cope with that. It also gets fooled with Snort or Suricata automatically restart themselves after a rules update or if the admin does something like you were doing in the GUI to restart the service. The Watchdog package simply sees the monitored daemon disappear from its scan, so it immediately executes the shell script to restart the service. But something else may be restarting the service, and thus then two copies of the same interface daemon can get launched. In your case I'm not sure how two instances got started. But when that happens, the GUI is only able to control and communicate with one of them. Thus the other one will no longer respond to start, stop or configuration change commands (such as changing the Pass List or Suppress List, for example).

@kiokoman said in suricata show Alert on wrong interface: @bmeeks about: Interface PCAP Snaplen This value may need to be increased if the physical interface is passing VLAN traffic and expected alerts are not being received. what is a good value to put in here ? 1522 = 1500 + ethernet + vlan ? The snaplen parameter needs to be long enough to hold the standard Ethernet frame plus any VLAN overhead. There is still debate, it appears, on the web about what to use. A quick Google search will find several links. So sorry to say I can't give you a good answer. I put the field in the package to allow users to experiment if they felt the need. The default value is still what has always been with each IDS package. The field was added to allow those who wanted to experiment to do so. you said it is most efficient..to put the IDS on the parent interface is it considered wrong to have instances on each VLAN ? for example for the vlan where i have some servers running i set IPS Policy Selection to security while on the other vlans i set it as Balanced, is it better to run only one istance and set the policy to security on the parent interface ? Nothing is generally considered "wrong" with an IDS configuration. It simply comes down to RAM and CPU utilization balanced against the security needs. If it is vital that two VLANs have different security policies applied, then running an IDS instance on each with different configured rules is what it takes. However, if you find both instances have, for all intents and purposes, the same rules, why waste RAM and CPU time with an IDS instance on each VLAN? Just run a single IDS instance on the parent and see everything in the configured VLANs.

@Liceo said in Why app-stats.log doesn't appear in Alterts Tab?: I set up a new instance of pfsense from scratch with one LAN and one WAN interface on hyper-v (gen 1). I generated some facebook and netflix traffic but Snort only shows some http alerts. Maybe a hyper-v related problem. I still think it just doesn't capture SSL traffic [image: 1601668152265-snort-no-ssl-resized.jpg] Snort captures OpenAppID alerts on SSL just fine. Look at my screenshot from my own testing. Something appears to be non-standard in your setup. Do you any kind of web proxy installed?

@bmeeks said in Overlap Running Multiple Rule Sets?: @tman222 said in Overlap Running Multiple Rule Sets?: Thanks @bmeeks. So using a combination of SID Management and IPS Policies I could, for instance, run the IPS Balanced policy but auto-disable some of the categories that are represented if the attack surface is not relevant (e.g. let's say rules pertaining to IIS servers), and then just run the remainder (of the policy rules). Are you aware of a good source that explains the different rule categories? Thanks again. You would have to disable by GID:SID values instead of categories if you use an IPS policy. Rules in a policy are auto-selected based on policy metadata embedded within each rule. Unless I was really short on RAM, I would not bother with such granularity if using a policy-based approach. Documentation of everyone's rules, both Snort and Emerging Threats, is basically non-existent. You have to learn to read the rule syntax for yourself and then learn about the various exploits. In short, you have to become a blackhat hacker of a sort so that you fully understand the exploits and how they work, then you learn to use the Snort rule syntax and that combination makes you an IDS security admin. It is a very technical field with few truly qualified folks; and the good ones can command very high compensation. Thanks @bmeeks - even if using a policy approach, wouldn't disabling a couple thousand rules (if they aren't relevant) help performance since there is less work for the CPU to do? Or am I overestimating the relative impact if the rule set is already quite large (e.g. let's say 10000+ rules). I think this is a fascinating area and have enjoyed digging into the different categories and rules to try to learn more and optimize my setup. Thanks again for all your help along the way.

@powerextreme said in SNORT ET Alerts: can I set up snort to just capture when this rule is triggered? Or will it do it for all rules? No, the PCAP capture option is not rule specific. It would be for all rules. The easiest thing might be to just kick off the backup job on the Synology again and capture the traffic on the LAN interface (or whatever interface it is traversing) directly on pfSense using the network caputure feature under DIAGNOSTICS on the menu.

After some further reflection, I decided to go back to running Snort in legacy (pcap) mode for now. I was able to try out Suricata as well for comparison, but after some initial testing in inline mode I saw similar throughput limitations. Given the interesting asymmetry I saw in upload and download speeds, I plan to revisit inline mode in Snort once pfSense 2.5 is released and there is support for multiple host rx/tx rings to see if that will help improve (upload) throughput.

@buggz said in Performance on IDS/IPS: Was this change on both the WAN and LAN, or just the Snort interface, which for me is LAN. Thanks! Both. (all)

@5cub4f1y said in Suricata Not Starting, Blank Log File: It won't let me edit any post older than 3600 seconds. Oh well. Anyone viewing this will obviously be able to tell its resolved anyway, and working like a charm. :) Let me see if it will let me change it. I am supposedly a moderator for this sub-forum. Edit: Yep, let me do it.

And you get really good info ones like: 1:2009968 # Potential Corporate Privacy Violation - Src.192.168.2.45:27960 Dest.68.232.172.16:27960 ET P2P eMule KAD Network Connection Request(2) Though this is showing I am the Source? Hmm, time to thorough scan... Haha, that WAS me, playing Enemy Territory. BUSTED! hehe...