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

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

ids-ips-network-flow-legacy-mode.png

ids-ips-network-flow-ips-mode.png