Suricata 2.0.3 Package Preview
-
We need this package update as soon as possible. Suricata just doesn't stay running for me right now.
-
Is that REALLY the level that you are dragging everything down to??
Disgusted…
@gonzopancho:
You'll have to get Supermule to acknowledge that the bug isn't in pfSense, but is, rather, upstream. I don't want to have to hear his complaints.
-
Bump…
-
The IPv6 bug has been found :D :D :D
I have submitted the Pull Request to the Suricata Github site containing the fix. I will also soon be sending it to the pfSense team. Although it worked in all my testing, the pfSense team and I would still like to get confirmation of the fix from the Suricata developers. So give us another day or so.
Edit – updated URL to point to most recent request
If you are interested, here is the link to the Suricata Github pull request: https://github.com/inliniac/suricata/pull/1120Bill
-
The IPv6 bug has been found :D :D :D
I have submitted the Pull Request to the Suricata Github site containing the fix.
'
This line should have been written:
I have found The IPv6 bug :D :D :D
I have submitted the Pull Request to the Suricata Github site containing MY fix.
I love having a package maintainer who is an active contributor of the software he maintains. 8)
Great job as always Bill.
-
The IPv6 bug has been found :D :D :D
I have submitted the Pull Request to the Suricata Github site containing the fix.
'
This line should have been written:
I have found The IPv6 bug :D :D :D
I have submitted the Pull Request to the Suricata Github site containing MY fix.
I love having a package maintainer who is an active contributor of the software he maintains. 8)
Great job as always Bill.
Thanks… ;)
I spent many, many hours poring over the Suricata source code trying to find that bug. I first had to figure out how Suricata works internally, and after that start tracking down where and how some IPv6 address comparisons were failing. Finally found the problem last night and started working on a fix. My eyes are crossed and I tend to see everything as C source code now... ;D
Bill
-
Awesome work!!!
"If you are interested, here is the link to the Suricata Github pull request: https://github.com/inliniac/suricata/pull/1119"
Awesome description, I actually understood this… LOL. I really need to get out.
It's IPv6, though it's important and it should be adapted quicker, Much quicker. Many of us are still stuck at IPv4 and could really use the update. This update will accept more 'Modern' rules', allows updates without having to manually edit files, and adds many abilities many people are looking for. Looking at the rate that Suricata merges important updates, and the time it takes the pfSense team to push them our way. It would be nice to have the update merged, and when the Suricata team makes this available have this as another update.
Last Suricata merge was on Aug. 15th.
Updates, especially security related updates can not wait 30 days… :)
-
@AhnHEL: Others helped identify that there was indeed a bug, you know.
@wcrowder: Security fixes faster than 30 days? Are you F***ING CRAZY? We must get the gold button in the code before security fixes. Getting paid is more important than actually providing something to get paid for.
I'm not sure [sarcasm] tags are appropriate, given the recent(ish) Ciscofying of pfSense.
Queue mod deletion in 3…2...1...
-
Ciscofying is a cool word :D
@jflsakfja:
@AhnHEL: Others helped identify that there was indeed a bug, you know.
@wcrowder: Security fixes faster than 30 days? Are you F***ING CRAZY? We must get the gold button in the code before security fixes. Getting paid is more important than actually providing something to get paid for.
I'm not sure [sarcasm] tags are appropriate, given the recent(ish) Ciscofying of pfSense.
Queue mod deletion in 3…2...1...
-
Ciscofying is a cool word :D
It is also unfortunately the truth. I'm expecting the announcement that you have to pay a subscription if you want your packages updated any day now.
-
Thats what I have been yelling about for quite some time…
Apparently the karma button doesnt like that :D
But the comfort of that is I know it can be manually changed so no matter what, it will never become positive in my lifetime in here :D
Buts its freaking annoying that you have to deal with kiddoes like that and not grown ups.
Currently trying to find a sponsor to paid development of a fork of pfsense. Just like the one that happened to M0n0wall to PFsense.
-
A fork isn't needed if the devs (not only of this project, all open source projects) learn what the correct procedure to having a project of their own is: Stop trying to re-invent the wheel, stick with upstream, and slap on your customizations as a separate package, available upstream.
Imagine installing the latest freebsd version, and just installing the pfsense package, which transforms that freebsd into a full blown pfsense.
It already takes care of:
- keeping up to date with security fixes
- keeping up to date with outdated drivers
- actually implementing a proper syslog for pfsense (anyone that thinks the current way to log is the absolute best, please do humanity a favor, here's a gun, here's a bullet)
- keeping up to date with packages. Yeap, no more waiting for devs to approve a newer suricata version
Will the projects realize that sticking with upstream is the proper way to do it? Don't be silly, of course not. Pride, greed, power, all have something to do with the dev's denial to accept that what I say is in fact the truth.
Eventually pfsense will be forked. My only hope is that the fork follows the upstream example given above and not waste developers time running around in circles. Install a freebsd base, then install the firewall-webgui package which takes care of installing the necessary dependencies and providing a way for you to configure the system. If that happens, I'll be the first to say "so long and thanks for all the fish, so sad that it should come to this".
-
Funny you should mention this….
It was my roadmap sent as a suggestion to the people involved in forking it.
As I see it now, its a ptach on patch on a patch and thats why things are taking so long.
-
Only issue in that direction is the baselayer security in FBSD10. It would be like installing ISA/TMG on top of windows.
So many options and possibilities….
-
Funny you should mention this….
It was my roadmap sent as a suggestion to the people involved in forking it.
As I see it now, its a ptach on patch on a patch and thats why things are taking so long.
Nope, it's a patch to a patch, that was submitted as a patch to another patch, that's why it's taking so long. Basically the pfsense customizations have grown to such an extend, that they are no longer manageable, and the devs are changing things a character at a time in the hopes that they don't bring the house of cards down.
If freebsd isn't secure enough, suggest ways to improve the security upstream. Or go with openbsd. I would cut off my left one if those guys said it was for better security :o
-
@jflsakfja:
@AhnHEL: Others helped identify that there was indeed a bug, you know.
Yes, several folks were instrumental in reporting the bug and helping clarify its existence. I won't call out names to protect privacy, but I did recruit some private beta testers from the Forum to help me shakeout the new Suricata package because it contains so many changes and updates. At least one of those users has a full IPv6 setup and reported certain ET Scan rules were not alerting for IPv6 traffic. They would alert for IPv4, though. I tested in my VM setup and could reproduce. I then corresponded with my other private testers and some folks here on the Forum by PM (private messaging) to confirm and ask for any history or examples of similar IPv6 bugs.
Armed with all of that information, I then hunkered down and started sifting through all the 734 C-language source code modules in the Suricata binary. It took a while, but I finally found that IPv6 bug.
In @AhnHEL's defense, I think he was referring to my second paragraph above where I found the C source code bug. But @jflsakfja is also correct that if other community members had not noticed and reported it, the bug would still be there. So I consider the whole exercise as a great example of open-source community collaboration. None of us involved in the effort could necessarily have done it all individually.
Bill
edit to fix spelling
-
Yes, several folks were instrumental in reporting the bug and helping clarify its existence. I won't call out names to protect privacy, but I did recruit some private beta testers from the Forum to help me shakeout the new Suricata package because it contains so many changes and updates. At least one of those users has a full IPv6 setup and reported certain ET Scan rules were not alerting for IPv6 traffic. They would alert for IPv4, though. I tested in my VM setup and could reproduce. I then corresponded with my other private testers and some folks here on the Forum by PM (private messaging) to confirm and ask for any history or examples of similar IPv6 bugs.
Armed with all of that information, I then hunkered down and starting sifting through all the 734 C-language source code modules in the Suricata binary. It took a while, but I finally found that IPv6 bug.
**In @AhnHEL's defense, I think he was referring to my second paragraph above where I found the C source code bug. But @jflsakfja is also correct that if other community members had not noticed and reported it, the bug would still be there. So I consider the whole exercise as a great example of open-source community collaboration. None of us involved in the effort could necessarily have done it all individually.
Bill**
Yeap, I completely agree with that. That's what open source is all about. Use a software, identify a bug, and let the people that know how to fix it know about the bug, and provide as many details as possible in helping them figure out what's wrong. When everything is fixed, submit the fix upstream (if upstream hasn't already fixed it) and wait for it to trickle down.
Basically it all comes down to these groups of people involved in maintaining a piece of software: Developers, patchers, bug finders, users. If they all co-operate, the result is stellar.
-
Found a small bug in suricata.inc.
line 446: if (is_addrv6($gw) && !in_array($gw . "/128", $home_net))
Should be
if (is_ipaddrv6($gw) && !in_array($gw . "/128", $home_net))
-
New package has been merged into production. I don't have time at the moment to post release notes – have to be away for family fun most of today. Will post release notes later.
Bill
-
@avink:
Found a small bug in suricata.inc.
line 446: if (is_addrv6($gw) && !in_array($gw . "/128", $home_net))
Should be
if (is_ipaddrv6($gw) && !in_array($gw . "/128", $home_net))
Darn it! Will fix it later this evening.
Bill
