Is Suricata package updates blocked by an internal decision?
-
Following up to a reddit post here:
https://www.reddit.com/r/PFSENSE/comments/13psw4d/upgrade_suricata_to_the_last_version/
I want to understand if there is an internal decision to block any updates to Suricata package until the next release in September, and what was the reason behind this decision.Suricata is not a default installed package or a critical one like Unbound for example. It cannot break pfSense if the user do not install it.
Also the updates to Suricata were released to Development branch first, tested there, and after that moved to Stable branch.
So I'm just asking myself, what impact or risk this package would have triggered a decision like this? If any at all....
-
-
That linked Reddit thread contains some inaccurate assumptions.
I am not a Reddit subscriber/user, so I do not routinely visit that site nor do I comment there.
There is nothing new in Suricata 6.0.11 as compared to 6.0.10 regarding netmap and Suricata. I created the Suricata netmap code changes two years ago, submitted them upstream into Suricata, and incorporated them into the pfSense version of Suricata at that time (back in August of 2021). We have been using a custom netmap patch in Suricata on pfSense since then that was the same code that is now in 6.0.11 from Suricata upstream. There was one "fix" provided for 6.0.11 Suricata, but that fix was also incorporated early into the 6.0.10 patch used on pfSense. Today, in terms of the netmap code, the only difference between 6.0.10 in pfSense and 6.0.11 from Suricata upstream is that now upstream contains all of the custom netmap patch we had been using on pfSense. Thus the rollout of 6.0.11 on pfSense was done by simply removing the custom netmap patch file we had been using.
The package branches for pfSense are locked to their respective pfSense/FreeBSD code bases. There are RELEASE and DEVEL branches for both pfSense CE and pfSense Plus. But those are all different branches (four in total) and cannot be just cross-polinated easily.
During the final stages of testing for the recent 23.05 pfSense Plus rollout, the Netgate team did lock package updates. This is normal. Now that 23.05 is moved to RELEASE, I can ask the Netgate team to migrate the Suricata 6.0.11 package update from DEVEL over to RELEASE for pfSense 23.05 Plus. But we cannot do this for the current 2.6.0 CE branch because that branch is behind in both FreeBSD and PHP versions. The current 6.0.10 and 6.0.11 Suricata packages won't work in pfSense 2.6.0 CE.
-
@johnpoz said in Is Suricata package updates blocked by an internal decision?:
@NRgia the IPS packages are maintained by @bmeeks - he would be the guy to get info on reasons or why the packages are not on whatever specific version.
Thank you @johnpoz I know who maintains the package, but I was not targeting him. As quoted, there was a moderator that said, something like the pfSense team decided that no package updates will happen between releases. If that was to be true, I fail to see how @bmeeks had any word in it.
-
-
@NRgia said in Is Suricata package updates blocked by an internal decision?:
With your permission @bmeeks can I link your response to that reddit thread, to settle this down?
Sure. What I stated is my understanding and is how things have historically worked. I am not aware of any recent changes to the process.
I've sent an email to Netgate asking them to migrate the latest 6.0.11 Suricata package over to the 23.05 RELEASE branch.
-
I have pending Pull Requests with the Netgate team to update Suricata to the latest 6.0.12 version from upstream.
This should happen in the next day or two. I've asked for the update to be deployed to both the 2.7 CE and 23.09 Plus DEVEL Snapshot branches and the pfSense Plus 23.05 RELEASE branch.
The Pull Requests are here:
https://github.com/pfsense/FreeBSD-ports/pull/1264
https://github.com/pfsense/FreeBSD-ports/pull/1265Unfortunately the new Suricata package requires PHP 8.1 or higher and is thus not compatible with the 2.6.0 CE branch.
-
@bmeeks Thank you Bill
-
The Pull Requests I mentioned and linked in an earlier post above have been merged. Look for new package builds to appear after the next package build cycle.
I think those are now done perhaps once per day ???
-
@bmeeks said in Is Suricata package updates blocked by an internal decision?:
I have pending Pull Requests with the Netgate team to update Suricata to the latest 6.0.12 version from upstream.
This should happen in the next day or two. I've asked for the update to be deployed to both the 2.7 CE and 23.09 Plus DEVEL Snapshot branches and the pfSense Plus 23.05 RELEASE branch.
The Pull Requests are here:
https://github.com/pfsense/FreeBSD-ports/pull/1264
https://github.com/pfsense/FreeBSD-ports/pull/1265Unfortunately the new Suricata package requires PHP 8.1 or higher and is thus not compatible with the 2.6.0 CE branch.
Just installed them on 23.05, no issues. Thank you again
-
@bmeeks Question regarding the use of the Snort paid subscriber rules. This is an older image I just downloaded, but is there a way for Suricata to always use the current snapshot filename rather than having to enter the filename manually after Cisco/Talos updates it?
One thing I like about the Snort package is that you don't have to keep up with this. Thanks.
-
@DefenderLLC said in Is Suricata package updates blocked by an internal decision?:
@bmeeks Question regarding the use of the Snort paid subscriber rules. This is an older image I just downloaded, but is there a way for Suricata to always use the current snapshot filename rather than having to enter the filename manually after Cisco/Talos updates it?
One thing I like about the Snort package is that you don't have to keep up with this. Thanks.
No, how would Suricata know what the current Snort snapshot version is?
The Snort binary is locked to the rules version. You can't use a Snort rules snapshot file that has a different version than the Snort binary with Snort. So, Snort simply downloads the file that matches its internal binary version. That's how it always uses the most recent snapshot.
Suricata can't do that because it has no way to know what the current Snort snapshot version might be.
-
@bmeeks said in Is Suricata package updates blocked by an internal decision?:
@DefenderLLC said in Is Suricata package updates blocked by an internal decision?:
@bmeeks Question regarding the use of the Snort paid subscriber rules. This is an older image I just downloaded, but is there a way for Suricata to always use the current snapshot filename rather than having to enter the filename manually after Cisco/Talos updates it?
One thing I like about the Snort package is that you don't have to keep up with this. Thanks.
No, how would Suricata know what the current Snort snapshot version is?
The Snort binary is locked to the rules version. You can't use a Snort rules snapshot file that has a different version than the Snort binary with Snort. So, Snort simply downloads the file that matches its internal binary version. That's how it always uses the most recent snapshot.
Suricata can't do that because it has no way to know what the current Snort snapshot version might be.
Makes sense. Thanks for the quick response. I never made the connection of the snapshot version being tied to the binary version. I was thinking those were the daily/weekly updates. (facepalm).
I never really paid much attention to this when I briefly used Suricata before. I might just keep using Snort until they officially stop developing 2.9 like you mentioned yesterday. Thanks again.
-
@DefenderLLC said in Is Suricata package updates blocked by an internal decision?:
@bmeeks said in Is Suricata package updates blocked by an internal decision?:
@DefenderLLC said in Is Suricata package updates blocked by an internal decision?:
@bmeeks Question regarding the use of the Snort paid subscriber rules. This is an older image I just downloaded, but is there a way for Suricata to always use the current snapshot filename rather than having to enter the filename manually after Cisco/Talos updates it?
One thing I like about the Snort package is that you don't have to keep up with this. Thanks.
No, how would Suricata know what the current Snort snapshot version is?
The Snort binary is locked to the rules version. You can't use a Snort rules snapshot file that has a different version than the Snort binary with Snort. So, Snort simply downloads the file that matches its internal binary version. That's how it always uses the most recent snapshot.
Suricata can't do that because it has no way to know what the current Snort snapshot version might be.
Makes sense. Thanks for the quick response. I never made the connection of the snapshot version being tied to the binary version. I was thinking those were the daily/weekly updates. (facepalm).
I never really paid much attention to this when I briefly used Suricata before. I might just keep using Snort until they officially stop developing 2.9 like you mentioned yesterday. Thanks again.
It's pretty simple to keep the most current Snort rules with Suricata. Simply visit https://snort.org, log in with your account credentials, and check what the most recent 2.9.x snapshot file version is. It will only change when there is a major change to the Snort binary. For the 2.9.x branch, changes are down to maybe one per year (if that).
Here is a Sticky Post link I created sometime back describing the process: https://forum.netgate.com/topic/110325/using-snort-vrt-rules-with-suricata-and-keeping-them-updated.
But note that when using Snort rules with Suricata it is normal for several of them to cause syntax errors and fail to load. Several hundred of the Snort VRT rules are incompatible with Suricata. But Suricata will simply print an error when loading those rules and skip them.
-
@bmeeks Thank you, Mr. Meeks.
