@lcs said in Suricata inline with VLANs: @bmeeks You've guessed that right. I'm not too happy about the legacy mode. Sometimes when I have a false positive hosts are blocked and the min time is 15 min which is causing some issues. Maybe I can run suricata on the WAN and use VLANs on LAN. I wish I had happier news. I've done quite a bit of research about netmap, especially over the early summer last year when I worked with the Suricata team on implementing multiple host rings support in Suricata. The way the netmap device is plumbed into the FreeBSD network stack makes working with VLANs natively and transparently not really possible. This is especially true if the hardware NIC driver does hardware VLAN tagging. The tags get copied by the driver into a part of kernel space that netmap does not see. Add to that the fact FreeBSD moved NIC drivers over to a new wrapper API library called iflib. That required rewriting many drivers. And during the rewrite phase some bugs were introduced, including some regressions. Those are still being worked out. The bugs affected things other than just netmap, though. Netmap was really designed for a slightly different use case than what is currently being done in Suricata and Snort on pfSense (and on the "other Sense" product, too). On the two firewall distros netmap is used to intercept traffic between the NIC driver and the kernel network stack. That is called host stack mode. That mode is where the VLAN troubles live. The way netmap was originally conceived was to simply route traffic between two physical NIC ports at super high speed bypassing the kernel network stack completely. It would essentially just bridge two NIC ports. But on a typical firewall appliance that is wasteful of valuable NIC ports.

i ended up deleting this instance and creating a new one. that worked perhaps the configuration file was corrupted during the update? dont know but it works fine now

@bmeeks thank you! I wanted to have Solved in the title because my original problem will probably happen to more people.

I performed a quick test of suricata running on 1 and 2 (virtually idle) interfaces, to compare default config vs explicit management cpu affinity. pfSense guest is assigned 2 cpu and 4GB RAM. For each combination, I waited for suricata to settle down, then noted: CPU use of the VM process on the proxmox hypervisor top -c -p $(pgrep -d',' -f 'name fw') CPU use of an individual suricata process on the pfsense VM top -aSH # suricata interfaces hypervisor suricata per process cpu config (qemu proxmox) (pfsense vm) ---------------------------------------------------------------------------- 1) 0 13% 0% 2) default 1 45% 6.5% 3) default 2 50% 5.4% 4) A 1 26% 4.4% 5) A 2 40% 3.6% 6) B 2 40% 4.4% config A) vtnet*/suricata.yaml (same for each interface) threading: set-cpu-affinity: yes cpu-affinity: - management-cpu-set: cpu: [ "0" ] config B) vtnet2/suricata.yaml threading: set-cpu-affinity: yes cpu-affinity: - management-cpu-set: cpu: [ "0" ] vtnet3/suricata.yaml threading: set-cpu-affinity: yes cpu-affinity: - management-cpu-set: cpu: [ "1" ] CPU use of each suricata process in pfsense remains fairly consistent across all configurations. However, setting a suricata management cpu affinity seems to have a marked effect on the cpu use reported for the pfsense guest (qemu process on proxmox hypervisor). This is most noticable for 1 suricata interface, less so with two. Also specifying different cpu management affinity for each of the two processes had little effect. Though this guest is only assigned 2 CPUs anyway. Assigning 3 CPUs, I'm guessing I would see similar improvement in 6) vs 3) as I do 4) vs 2) Just to add, I wonder if cpu pinning in the underlying VM config on proxmox might achieve similar results?

@bmeeks that what it was

@skogs Hey mate, sorry for not giving you any meaningful information, but you guessed it right. SID 2035190 was the one that caused issues to me. And yes, we were using lets encrypt for some of our stuff. Thanks for the valuable info though. I'm pretty beginner on firewalls. I have a senior admin who mostly look into such sort of things, but I'm trying to be as helpful as I can!

I swear this update wasn't available when I posted the above... I'm probably a knuckle dragging fool but since yesterday a package update for Suricata showed up. Bumping from pfsense-pkg-suricata 6.0.4 to 6.0.4_1 fixed up my issue.

@minilulatsch said in Snort - OpenAppID negation: @bmeeks Yep, did that, my idea was to simply set $HTTP_PORTS to the port range 1-65535 so that all traffic is inspected (no idea how bad this would be for performance, it was just for testing). However, it's not that easy. The ports in this variable are written to snort.conf, which can't hold more than 32000 characters in one line, which is way less than needed for all 65535 ports. That means, if you do what I did and set $HTTP_PORTS to 1-65535, Snort will not be able to start on the corresponding interface as the config file cannot be loaded. There are limits on the size of things, so you need to more carefully analyze what you actually want to look for and then modify the variables appropriately. Looking for HTTP traffic on every conceivable port is not really realistic in my view.

Ok disregard last about it not happening on bare metal. It did last night. In GUI, Suricata is down for the interface, but process is running. No PID file in /var/run The proxmox Pfsense node has remained stable so the Live-reload rules might have helped. I will also enable it on the bare metal machine.

The suggestion about HOME_NET and EXTERNAL_NET was a long shot mentioned just in case you had done some customization. The default settings usually work fine and capture all of the local firewall interfaces via pfSense system API calls. It also grabs things like defined DNS servers, so that's why those external DNS servers are there. They must be defined elsewhere in the pfSense configuration. Here are two simple flow diagrams that illustrate how packets flow when either of the IDS/IPS packages are installed on pfSense. [image: 1643988981439-ids-ips-network-flow-legacy-mode.png] [image: 1643989011104-ids-ips-network-flow-ips-mode.png]

@digidax said in snort: restarting needed if IP list edited?: @bmeeks OK, will take a look into the logs to see, if the updates of the list are imported successful. OT Question: in the blocked tab, I see the "Last 500 Hosts Blocked by Snort ". In the browser, I can use CTRL+f to search for an IP. a) is it possible, as a future feature, to get a search filed for an IP when the list is larger, > 2000 entries? I don't really understand why you would want the block list to grow like that. The suggested setup is to enable the automatic cron task (on the GENERAL SETTINGS tab) that clears blocked hosts who have seen no traffic for the interval specified in the parameter on that tab. For example, if you choose 1 hour, then any IP in the block list that has seen no traffic for the last hour will be automatically removed from the block list after the interval has expired. There is really no point in maintaining huge block lists. If the same host attacks again, then Snort will detect and block it again. It is usually sufficient to block a host for 15 minutes to an hour. If you have not already, I strongly recommend you enable that setting and configure it for either 30 minutes or 1 hour max. Snort blocks by making a pfSense system call and inserting the offending IP into a pf table called snort2c. That table is created by pfSense during bootup, and it is a RAM construct. So when the firewall is restarted, that table is recreated from scratch. b) can I use a command line command to search for a blocked IP and remove it from snort's blocklist? You can manage the pf firewall engine using the pfctl utility. Here is a link to its documentation: https://www.freebsd.org/cgi/man.cgi?query=pfctl&sektion=8. Thanks, Frank

Might be a browser caching issue -- maybe with stored credentials and auto-login enabled for the browser. There is nothing in the Suricata package at all related to logging in to pfSense. The suricata_interfaces.php page is the default landing page when you click Suricata under the SERVICES menu in pfSense. Did you perhaps have multiple tabs open? Or maybe had an open, but expired, tab on the Suricata Interfaces page and then opened a different tab to login to the firewall GUI?

@enicolau said in suricata not starting: @bmeeks Thanks for responding, I'm using pfsense, from the gui there is no more data that it doesn't start, there is nothing else, so I start it by ssh but I can't think of much else I don't think you understand how Suricata works on pfSense. You MUST use the GUI for everything. You CANNOT do things from the command-line -- including starting it by SSH. The suricata.yaml file you see in /usr/local/etc/suricata is not the file used by the Suricata processes on pfSense. Each configured instance (in the GUI) has its own unique subdirectory underneath /usr/local/etc/suricata/, and all of the configuration information for that instance resides in the subdirectory. At startup time, the suricata.yaml file is created from scratch using information stored by the GUI code in the firewall's config.xml file. The errors in the startup log clearly indicate issues with your NIC driver. It is not playing well with Suricata. I have no idea why, but it is not. Notice these two lines: 27/1/2022 -- 08:44:41 - <Error> - [ERRCODE: SC_ERR_THREAD_INIT(49)] - thread "RX#01-vtnet1" failed to initialize: flags 0145 27/1/2022 -- 08:44:41 - <Error> - [ERRCODE: SC_ERR_FATAL(171)] - Engine initialization failed, aborting... That SC_ERR_FATAL error is why Suricata is not starting, and that error is ocurring when Suricata attempts to initialize that card. Your second problem is attempting to run Suricata using the UNIX socket. That is not currently supported on pfSense. 27/1/2022 -- 08:46:55 - <Info> - Running in live mode, activating unix socket 27/1/2022 -- 08:46:55 - <Info> - Using unix socket file '/var/run/suricata/suricata-command.socket' And you appear to be trying to pass BPF parameters via the command-line based on this line in the startup log: 27/1/2022 -- 08:46:55 - <Info> - BPF filter set from command line or via old 'bpf-filter' option. That option is not supported on pfSense either. And the filter you are providing has a syntax error as evidenced by this line in the log file: 27/1/2022 -- 08:44:41 - <Error> - [ERRCODE: SC_ERR_BPF(127)] - bpf compilation error can't parse filter expression: syntax error Here is a link with instructions for setting up Suricata on pfSense. It may help you understand how to properly do this. https://lawrencesystems.com/suricata-network-ids-ips-installation-setup-and-how-to-tune-the-rules-alerts-on-pfsense-2020/

@jcascante said in Snort fails to start: @bmeeks Hello, just to let you know the workaround works I put a higher value in the "overlap-limit", then save the configuration, returned the value to zero, check the snort.conf file and this time it saved the value. Finally, I started the service and now it's working Thanks for your help Glad you got it working. That was an unusual issue. Sounds like something weird got saved in the config.xml file for that particular parameter.

Well I'm not smart enough to make a custom feed; but did find good stuff to ease my mind. Suricata Rules SID 2527000 and 2527001 The message portion states ET Threatview.io High Confidence Cobalt Strike C2 IP group 1 and group 2. So...that is what I was looking for. Comes into the system with the emerging-threatview_CS_c2.rules category. Mystery solved. Thanks for the brainpower expended.

@patch I am learning how to use Haproxy's reverse proxy and using private domain (secret TLS/SNI) to help make the PBX more secure in the DMZ...very interesting...I'll post in the proxy section questions I may have.