I have not done so personally, but the general idea is you install a filebeat client on pfSense and configure that client to ingest the EVE JSON logs on the firewall. You will find them under /var/log/suricata/suricata_xxxx/ on the firewall where the suricata_xxxx part will be a unique subdirectory for each configured Suricata interface that includes the physical interface name combined with a random UUID number. Here is a general overview link for filebeat: https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-overview.html. You have to tell the client what kind of logs to ingest and where to pull them from. Here is the documentation for that: https://www.elastic.co/guide/en/beats/filebeat/current/configuration-filebeat-options.html. Unfortunately, many of these packages change their input formatting somewhat frequently, so you will likely have to dig around on Google to find the "current" config parameters needed to ingest Suricata 6.0.x EVE logs. Here is the documentation for establishing an output destination for filebeat: https://www.elastic.co/guide/en/beats/filebeat/current/configuring-output.html. The basic process is to install and configure the client on the pfSense firewall, and then configure the client to output (or send) ingested log data from the pfSense firewall over the network to your ELK stack running on the Ubuntu machine. I added a note to my internal Suricata package issue tracking to investigate a primitive means to at least allow display of the captured payloads in the GUI if that option is enabled. There will be only limited usefulness there, though, because the vast majority of the time the payload is going to be encrypted.

I prefer not to futher contaminate this thread with this conversation because your problem has nothing to do with "commented out" rules. Yours is a completely different issue. Feel free to create a new post thread if you want to continue this.

@michmoor said in clarification needed on direction of rules and usefulness: @bmeeks Understood. In my mind, because the firewall is stateful I was thinking that the rules although are evaluated from EXTERNAL to INTERNAL, there was some value of having the rule applied on the internal lan as the firewall would see the return traffic. So are you saying it operates from a purely stateless way, rule evaluated from source to destination (external to internal) and that's it. There needs to be a rule matching from HOME to External? Lastly, from your standpoint, PFblockerNG and some of the ET rule sets have IP blocking. I assume there is overlap. Does it matter if the suricata rules are enabled for those IPs as well? Assuming there is no resource constraint on the firewall. I am not understanding why you bring in stateful connections and rules. It seems to me you are confusing the IDS/IPS with the firewall. They are not the same at all! In fact, most commercial enterprises run the IDS/IPS on a completely separate box and not on the firewall. The IDS/IPS (Suricata in your case), is totally ignorant of firewall states and even firewall rules. It simply evaluates packets as they flow across the physical interface Suricata is monitoring. And it is only looking at the IP header info in the packet to determine how far to evaluate that packet against the Suricata rules (not the firewall rules, the firewall rules are totally irrelevant to Suricata). Suricata, especially when running in IPS mode, does not interact with the firewall engine at all. Not one bit. Actually Suricata sits out in front of the firewall. Here are two diagrams that show Suricata lives "outside", on the NIC-side of the firewall and thus sees traffic before the firewall rules have been applied. [image: 1647271178377-ids-ips-network-flow-ips-mode.png] [image: 1647271187125-ids-ips-network-flow-legacy-mode.png] In terms of your pfBlocker question, if you use only simple IP lists in Suricata, then there would be perhaps 100% overlap between what it does and what pfBlocker does. But most folks would not do that. If you use pfBlocker, then you might apply other rules in Suricata that are not simple IP lists. But as we discussed much earlier in this thread, encryption severely hinders the ability of Suricata or any IDS/IPS package to peer into the packet payload.

@bmeeks Thanks. That’s what I figured but wanted to be sure it wasn’t some newbie mistake. May move to all VLANs and not run anything on the parent interface so I can separate things more at the cost of system resources. I’m sure the over spec 7100 can handle that for my home 🤪.

@bmeeks Just to confirm your idea, it does appear that the third-party block was automatically removed after some time period (~24 hours) as I am again able to check the geoIP status in Suricata without getting the quota/membership message.

@jobathenoob Thanks. Yeah, I opted for just using them internally. It’s just a home network on overkill anyhow. . To be honest, I haven’t had any real issues beyond suppressing some of the more mundane stuff like some http_inspect false positive annoyances. I pay for the snort ruleset and stick with the predetermined profiles. Between snort and pfblocker it can easily drag even a decent machine down if you overdo it. My network has a four port NIC and I use separate Wi-Fi routers in bridge mode to have, for example, a separate Wi-Fi network for IoT devices versus my regular network. This allows me to prohibit an insecure IoT device from making connections to other things that matter on different segments and such. It’s way more than the average Joe needs, but it prevents some back door made in china sensor from connecting to my laptop. It also means snort on multiple interfaces… I’m much happier now though with my changes. I trimmed pfblocker back a bit too. The wife is much happier with fewer random things breaking. . And I’m using maybe 15-30% of ram, cpu or swap at any moment so it’s not struggling at all. Steve

@translating-it said in custom rule does not seem to work: @bmeeks How do I get this capture? I only see an option for packets that generate an alert, but not for those which don't generate one. You don't do the captures in Snort. You do those in pfSense itself under DIAGNOSTICS > PACKET CAPTURE.

@michmoor said in Snort IPS Inline mode not working as expected.: @michmoor So I just solved the first issue. GID and SID are separate fields but I was putting in for example, 1:2403392, all in one field. So putting just 2403392 in the SID field I get the logs. Any reason why there isn't just one field that says GID:SID and search on that? Abit confusing. Item 2 is still an issue. Short of disabling the rule individually there doesn't seem to be a way to apply the action via the Alerts tab. For item #1: The logic treats GID and SID as separate fields because they are returned that way in the logging from the Snort binary. Makes searching easier. You can put values in both fields and they will be combined using AND logic. So if you put "1" in the GID field and "2500012" in the SID field, that will return the matches. But in reality, you will never want to put anything in GID field most of the time because ALL general rules use GID "1". Only the Snort preprocessor built-in rules use different GID values. For item #2: Not sure exactly what is happening, but changing the action from either place works. At least it used to. I would need to fire up a virtual machine and test again to verify. How exactly are you determining what the default action is? Are you looking at the rules on the file system? If so, you are likely not looking in the correct location. The current set of "active" rules for an interface lives in a sub-directory underneath /usr/local/etc/snort/ and then in a /rules/ subdirectory found there -- specifically in a file called snort.rules.

@xpxp2002 said in Suricata not respecting pass list: @bmeeks I understand. I see that in the Suricata logs during startup. I rebooted the firewall this morning to see if it would help, but I'm still seeing the same behavior. Is there anything else I can/should check? Or is this almost certainly a bug? Nothing I am aware of on the user side assuming the Pass List contains all the necessary networks. I really think the problem is buried within the logic of the Radix Tree utility code supplied with the Suricata binary. There is an active bug report on it being worked by the Suricata team. I'm hoping the fixes they put in for their own use of the Radix Tree will also percolate down to the tree code behaving better with my Suricata custom blocking module.

@bmeeks Hello, thanks for the detailed explanation, I updated the Pfsense (nothing broke ) and also gave my machine 1GiB more RAM and the Interfaces are now stable and didn’t crash a single time! Only thing that wonders me now is why my Proxmox PVE (A VM management OS) did show that only half of the available RAM was used when in fact Pfsense showed 99%. When I use top and look at the Mem stats, I see that the memory itself is the same as reported to Proxmox but there is an additional (about the same size) portion of „laundry“ memory in use, whatever this means. Anyway the problem I described is now solved thanks again guys.

@bmeeks for logging it makes sense to send it off to “enter syslog server of your choice” but what system is there to send pcaps off for analysis? I understand what you’re stating from a security php perspective but then the heavy lifting is still on the consumer (pfsense user) to figure out how to make the IDS a useful tool. Seems counterintuitive then to have it but then it’s not convenient enough to use.

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