Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes
-
@bmeeks You can try another scenario. Install pfSense CE 2.6.0, install Suricata, and then upgrade until you reach 23.01. You have more config migrations with this approach. I have my config created a few versions back.
-
@nrgia said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@bmeeks You can try another scenario. Install pfSense CE 2.6.0, install Suricata, and then upgrade until you reach 23.01. You have more config migrations with this approach.
That's sort of what I'm doing, but using just the
config.xmlfile and importing/restoring an older one. I don't actually have any pfSense Plus testing VMs. I'm using 2.7.0 for that now as 23.01 and 2.7.0 are pretty much the same at the moment.I do so much destroying and recreating the test VMs that having to upgrade each one to Plus each time would be a hassle.
-
@bmeeks said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@nrgia said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@bmeeks You can try another scenario. Install pfSense CE 2.6.0, install Suricata, and then upgrade until you reach 23.01. You have more config migrations with this approach.
That's sort of what I'm doing, but using just the
config.xmlfile and importing/restoring an older one. I don't actually have any pfSense Plus testing VMs. I'm using 2.7.0 for that now as 23.01 and 2.7.0 are pretty much the same at the moment.I do so much destroying and recreating the test VMs that having to upgrade each one to Plus each time would be a hassle.
I feel you, we, the users with whiteboxes tend to test less due to this cumbersome upgrade path, instead of simple installer images.
-
@steveits If am reading your reply correctly, the best practice is to run suricata only on the LAN interface then?
-
@returntrip Yep. No need to scan packets twice, no need to scan packets that will be dropped by the firewall, and on LAN the alert will show the LAN IP not the NATted IP of the router WAN.
I suppose there's an argument to use WAN if one has lots of internal interfaces and limited memory...?
-
@returntrip said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@steveits If am reading your reply correctly, the best practice is to run suricata only on the LAN interface then?
Suricata sits in front of the firewall no matter which interface it is configured on. Packets inbound on an interface (meaning coming from the NIC on the their way into pfSense) encounter Suricata first. That means when you run Suricata on the WAN it is going to see and analyze all the Internet noise that exists there. And most, if not all, of that noise traffic is not allowed through the firewall, so why waste CPU resources and RAM having Suricata scan that Internet noise the firewall rules are probably going to drop anyway?
Better to run IDS/IPS instances on the internal interfaces such as LAN or DMZ and others. As @SteveITS mentioned, about the only time running Suricata on the WAN would make sense is if you have a large number of internal interfaces, but limited RAM and/or CPU. In that case running a single instance on the WAN might make sense due to the resource constraints.
Besides the NAT issue mentioned, another problem with running it on the WAN is all that Internet noise is going to generate a lot of logging data and eat up local disk space. Again, this is because no firewall rules have been applied at the point Suricata is seeing the interface traffic. Putting the instance on an internal interface lets the firewall do the initial traffic filtering, and then Suricata only looks at traffic the firewall allowed, cutting down on useless alerts and what gets logged.
-
Many thanks @bmeeks your reply is really clear and I now understand the reasoning behind WAN vs LAN only monitoring. I have 4 internal interfaces I want to screen so maybe I could monitor only the WAN interface then but then I would not know what internal IP am alert is generated for. Is there any way to overcome this "drawback" , besides monitoring every single internal interface?
-
@returntrip said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
Many thanks @bmeeks your reply is really clear and I now understand the reasoning behind WAN vs LAN only monitoring. I have 4 internal interfaces I want to screen so maybe I could monitor only the WAN interface then but then I would not know what internal IP am alert is generated for. Is there any way to overcome this "drawback" , besides monitoring every single internal interface?
No, unless you want to run the same rules for all the interfaces and they happen to be VLANs. In that case, you could put Suricata on the physical parent interface and it would see the traffic for all VLANs defined on that parent. But that does require that you want the same rules for all the internal networks (or at least all the VLANs defined on that parent).
But also consider carefully tuning the rules you have enabled on interfaces. Customize the rules for the vulnerabilities on that network. Most folks tend to enable way more rules than they actually require. The less rules Suricata has to work through, the smaller the drain on CPU resources and RAM.
-
@bmeeks very nteresting. Am running pfsense as a router on a stick with only 1 physical interface which provides 1 vlan for wan and 4 vlans for internal..... so I guess it would be much easier for me to monitor the parent interface for everything. I do not think I would need separate rules per IF.
-
@returntrip said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@bmeeks very nteresting. Am running pfsense as a router on a stick with only 1 physical interface which provides 1 vlan for wan and 4 vlans for internal..... so I guess it would be much easier for me to monitor the parent interface for everything. I do not think I would need separate rules per IF.
Well, in your case with everything on one physical interface, you gain nothing.
Suricata runs the interface in promiscuous mode anyway. So there is no real advantage to changing anything in your case.
But that is not the most secure setup. Having WAN and LAN mixed at Layer 2 is not a good idea in my view.
-
@bmeeks I hate this setup, but I have some limitation due to HW I use for pfSense and cabling. I need to get my ISP NTU moved next to my pfsense. At the moment I have three switches between the NTU and FW.... Here is my setup in case you want to get depressed:
https://forum.netgate.com/topic/138244/2-switches-between-router-on-a-stick-and-modem?_=1677266087572
The only difference is that the switch attached to the NTU is a Cisco 2960G IIRC.
So would it be sufficient to monitor only the LAN VLAN IF and all would be covered?
-
@returntrip said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@bmeeks I hate this setup, but I have some limitation due to HW I use for pfSense and cabling. I need to get my ISP NTU moved next to my pfsense. At the moment I have three switches between the NTU and FW.... Here is my setup in case you want to get depressed:
https://forum.netgate.com/topic/138244/2-switches-between-router-on-a-stick-and-modem?_=1677266087572
The only difference is that the switch attached to the NTU is a Cisco 2960G IIRC.
So would it be sufficient to monitor only the LAN VLAN IF and all would be covered?
Yes, monitoring the LAN would actually cover all the networks on that parent. Suricata will place the physical interface in promiscuous mode when it starts, and thus will see all the traffic traversing the parent.
-
-
@darcey said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@bmeeks Will 6.0.10 be made available for pfSenseCE 2.6?
I believe the changes that might help with this were introduced in suricata 6.0.8.Suricata issue 4421.
Akismet did not allow me to post two links in one post. -
Regarding using Suricata on WAN, correct me if I am wrong but one reason to do so is if you want it to inspect traffic when using a public facing instance of HAProxy.
-
@darcey said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
@bmeeks Will 6.0.10 be made available for pfSenseCE 2.6?
I believe the changes that might help with this were introduced in suricata 6.0.8.Yes, later versions of Suricata have addressed the high idle CPU usage by reverting an earlier change in the flow manager code.
As for getting a newer version of Suricata in pfSense 2.6.0, I will have to investigate to see what's feasible. Depends to some degree on what, if any, shared dependency library minimum version numbers might have changed in Suricata.
I would love to get Suricata updated in the 2.6 CE branch, but backporting the GUI code is a large task as the change in PHP from 7.4 in pfSense 2.6 to 8.1 in pfSense 2.7 CE and 23.01 Plus resulted in wholesale rewriting of large chunks of code. And those rewrites are not directly compatible with PHP 7.4.
If 2.7 CE rapidly advances through testing from the current BETA phase to RELEASE, then updating Suricata will be a non-issue as the package is current in the 2.7 snapshots. But if 2.7 CE development gets significantly delayed on the way from BETA to RELEASE, then updating of some packages in 2.6 CE may need revisiting. There is a possible solution to the PHP problem by creating a specialized compatibility module of functions to accomplish in 7.4 what is happening in 8.1.
-
@lawrencesystems said in Suricata 6.0.10_1 Update for pfSense Plus 23.01 - Release Notes:
Regarding using Suricata on WAN, correct me if I am wrong but one reason to do so is if you want it to inspect traffic when using a public facing instance of HAProxy.
Yes, there are certainly instances where running Suricata or Snort on the WAN may make sense for a particular network configuration. But this is more likely to be the case for pfSense used in a business network as opposed to a home network.
I would venture it to be very rare to need a Suricata or Snort instance running on the WAN in the typical home network. I won't say "never", but I would say "very rare"
. -
@bmeeks Thanks. That would seem not worth it then. Looking forward to CE 2.7...
-
Hi @bmeeks ,
I am afraid the Pass List improvements broke things here. I am using legacy mode. I have long had the trouble that /24 networks did not work in the pass list so on top of the /24 I put specific /32 IPs in the pass list for important machines.
While conducting tests I can reproducibly block my laptop even though it is part of the /24 network and the pass list has this specific IP in it as well. At least the latter worked up until this upgrade.
The correct pass list is enabled in the settings. And via "View" I can confirm that both the home network /24 and my laptops /32 is in it.
Running 23.01.
-
@j-koopmann:
Will you please share that Pass List? I would like to reproduce the conditions in my test virtual environment as best I can.I have never been able, for some reason, to reproduce this issue of Pass List entries not working. They always work in my testing
.
