Like user @ekke mentioned, if you are sensible about the rules you enable then you can achieve your target throughput. If you enable every rule category, then "no", you won't achieve your target throughput. By "sensible" I mean things like not enabling rules that inspect for issues that will not be a threat to your environment. For example, if you do not have Internet-facing and public DNS and mail servers, then there is no need to run any rules that scan for threats targeting mail or DNS servers. If you do not have Internet-facing and public web servers, then you don't need any web server rules. There are other cases, too, where some threats may not be a problem in your network environment. One thing you will have to do with that many cores is bump up the Stream Memcap parameter. Here is a link to an older thread on the subject: https://forum.netgate.com/topic/124850/suricata-fails-to-start.

At the hypervisor level, running in promiscuous mode allows the VM to see traffic not destined for its MAC address. The most common use cases for this are: HA - It's required for CARP to function L2 Bridging - Otherwise traffic for non-firewall hosts will be dropped as they have different MAC addresses. It's not necessary for packet captures or an IDS. That's promiscuous mode of the interface at the OS level, not in the hypervisor.

Hi, A little hammering on a mail server isn't necessarily a bad thing. It helps to keep you, and itself, in shape. I'm not running myself a mail server behind pfSense, I hide it behind an empty iptables firewall (really : true, it's empty when the machine starts). I'm using world's famous fail2ban to scan the mail server log file, and when fail2ban finds suspicious actions like rejected mail connections then it will load the IP into the firewall for some time. This is the result. Blocking some 5k IP's right now, and counting. It will be holiday soon, so some new scores will be reached in a week or so. fail2ban scans all log files of all server type applications, from SSH to mail to web server and some others. Blocking suspicious IP's was solved a decade or two ago. Just let the tools work for you ^^ Btw : setting up the tools is one thing. You, as an admin, has to read => yep, read ! - the logs to see for new behavior, and if found one, add new filters for it. It's a never ending story. Live is hard when you don't (know how to) script.

@bmeeks Thanks for the insight.

@oldrik said in Setup and configure snort on pfsense to detect an intrusion detection attemps within a LAN: @kiokoman pls if i understand well, does it mean that snort can't actually alert and block an attack such as a portscan performed by a user on a LAN network to another user on the same LAN ???? if that is the case, how can snort be configure to alert and block a user on a LAN from another user on the same LAN who perform an attack such as a portscan ??? Thanks in advanced Snort runs on the firewall. The firewall is not in the traffic path if two machines on the same LAN talk to each other. Only the LAN switch is in that pathway. The only time the firewall can see traffic from a LAN client is when that client is communicating with an IP address that is NOT part of the LAN. That would be a different LAN subnet where the firewall is the route to the different subnet, or some host out on the Internet (which means the traffic is traversing the WAN interface). So since Snort would not see one LAN client port scanning another LAN client (in the same subnet), it can't do anything about it. If you wanted to monitor traffic between LAN hosts on the same network, then you will need a managed switch that provides a span port (or port mirroring). You would then configure mirroring on the switch and set up a separate installation of Snort on say a Linux host on the LAN and connect that host to the span port on the switch. Only then could Snort on the Linux host see traffic between other LAN hosts.

@karel said in Suricata - Block on drop not being respected for certain rules: I was able to reproduce this every time. I've just suppressed those alerts for now. Thanks for the feedback. I will see about reproducing this in my test virtual machines and look for a cause. Might be something within the binary itself. It will be a few days before I have time for the testing, though.

@jwj said in Is it possible to block DoH and DoT, using SURICATA: I'm not holding my breath for relevant updates to privacy legislation. Too much money in surveillance capitalism and politics. Very very true! Also the lawmakers don't understand any of it.. Kind of hard to pass legislation on tech that is all just magic to you.. We are just doing what the users want! We are providing a service - they agreed to it, etc. etc. Oh by the way here is some $ for that thing you wanted to get done.. We are here to help! ;) Also problem is the tech "can" be used for good!!! What your watching on TV is minor shit in the big picture.. Guns can save your life from that bear, they can be used to feed your family... But they can also be used by bad guy to kill you.. Same goes for some of this tech - its all double edge swords.. They can cut the stuff you want to cut, but they can also cut you bad!

Well, first off your problem does not sound like a Snort problem. If you disable Snort on all interfaces do things work then? If not, you have to troubleshoot that first and only then come back and enable Snort. If you have any sort of Proxy package installed on your firewall, that's the first place I would start my troubleshooting. The fact you mention issues with basic package installation makes me think either connectivity issues at the hardware layer or something related to a proxy since you mentioned https_proxy in your post.

@Shazams said in suricata/snort/etpro rules - how to be?: Hello! I use the latest version suricata. I would like to expand the set of rules. Snort has two subscription options: $ 30 and $ 400. What is the difference in the rules between two subscriptions? I have to give you the smart alec answer first ... LOL. The difference is $370 ... . Okay, now that I've had my fun for the day, the real answer is there is no difference. The Snort team just has a different rate structure for private (as in individuals) versus commercial (business) users. Read the fine print on their licensing site. If you are purchasing a Snort subscription for a business, you should pay the higher rate. A pricing structure such as this is not too uncommon. Microsoft had something similar for students versus other users for their Office products. @Shazams said in suricata/snort/etpro rules - how to be?:> Does it make sense to apply the rules from etpro, if I purchased a snort subscription. p.s. Normal user. Unless you are Jeff Bezos or Bill Gates and just flush with cash, I think you will find an ET-Pro subscription fairly expensive (as in $2369.99 per year). That is way too rich for my wallet as an individual user. So in my case, and it's the same for the majority of users here, I would choose Snort over ET-Pro. Nothing wrong with using Snort and the free ET-Open rules, though. If I were the firewall admin for a larger business, and I had the budget, I would opt for the ET-Pro rules and use them along with Snort. It can never hurt to have multiple eyes looking out for trouble, or in this case multiple signatures.

No, it is not. Just two "ordinary" interfaces -> WAN & LAN.

@Snowaks said in Suricata Snort VRT Rules Problem/Missing Fixed!: So one question I had now that 3.0 is out for snort will the 2.9 train no longer get updated ?? at least I've seen was snortrules-snapshot-29140.tar.gz and was almost a year old. Snort3 is not actually "out" yet. It is still in Beta and has been in a Beta for about a year. The Snort 2.9.x rule sets and source will continue to be updated for a while. And DO NOT attempt to use the Snort3 rules with Suricata. You will break it badly if you try that. Suricata cannot work properly with Snort3 rules. The snortrules-snapshot-29140.tar.gz file is not a year old. Not sure where you think you are seeing that. The file is updated approximately twice per week. Snort 2.9.13 is the current binary version, and those rules are also updated about twice a week. Since there is a 2.9.14 rule set posted on the Snort site, I suspect a release update for the binary is about to drop (that would be Snort 2.9.14).

Normally what you would do in a double nat setup is yeah put pfsense wan IP in the dmz host of the router upstream.. This way you only need to mess with 1 place for port forwards. But sure if you need port X to be forwarded on pfsense to something behind, then you would make sure the nat upstream forwards port X to pfsense wan IP first.

@Actionhenk said in Snort3 Package Status Update: does this version support multithreading ? Yes, Snort3 is multithreaded. But don't expect a huge performance gain from that. Suricata is multithreaded, and in several independent tests I've seen posted on the web in the past where it was compared with the current single-threaded Snort 2.x, there was not a lot of difference in packet throughput. Even multithreaded applications still have some bottleneck points where things have to come back down to a single thread. While multithreaded is not a bad thing, and it can help in some situations, I just don't think it is the quite the "super thing" that some folks think it is.

uninstalled suricata and installed snort, seems to be working

@ravi said in Compiling Software on the Firewall: Under this section, one thing is mentioned that create binaries in a FreeBSD similar to pfSense's FreeBsd. Copy those binaries to pfsense. Does it work?. I will take bro ids and create binaries and copies it to pfsense. Thank you. Note: Section : " Compiling software on the Firewall" from pfsense website Above view from First paragraph of "Compiling Software on the Firewall" section 0f this link "https://docs.netgate.com/pfsense/en/latest/development/compiling-software-on-the-firewall.html"

Done fresh installation. Snort came. Thank you.

@ravi You mean other than via the Package Manager available from System | Package Manager | Available Packages ?

@bhjitsense said in Disk full with packet logs: Thanks. That took care of it. In the GUI, is there not an easy way to view/export the .pcap files that have been logged? No. You can see the files using DIAGNOSTICS > EDIT FILE from the pfSense menu, but there is nothing within the Suricata GUI for looking at the .pcap files. It is the admin's responsibility to either view them using some CLI tool or export them off the box over to another server for analysis with third-party tools. The PHP system of the firewall does not provide a great programming environment for opening up and viewing large files.

Bill, I just rebooted and Suricata is now running! [image: 1562524823426-screen-shot-2019-07-07-at-1.38.08-pm.png]