Suricata 2.0.3 Package Preview
-
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
-
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
There goes my Sunday off :P
That means I have to finish working on the disablesid guide, since it's the next milestone in the suricata series. Oh well, back to work.
-
After updating to Suricata 2.0.3 pkg v2.0.1 I got a lot of errors in the Widget and the Alert-tab.
Clearing the alert-logs and blocked-tab logs took care of it.Thanks for the quick "avink" bug-fix!
Edit: Found another bug, after updating and editing an interface, the Barnyard tab gives the following error:
Fatal error: Can't use function return value in write context in /usr/local/www/suricata/suricata_barnyard.php on line 99 -
More like vmWare-fied, if it was Cisco it would be $10,000.00 for a book, no support and 10 year old hardware… LOL... Yeah, at work we have to use a Cisco ASA for a simple 1 to 1 nat on a "air gaped" network... LMAO...
Have you actually read the license, or do you just like to gripe? Maybe they should remove the <gold>menu item for people that pay for "FULL SUPPORT", I don't care about it as long as I have this for home... I don't get the problem...
I can't wait to try the new "Supermule Firewall"!!!! I can picture the logo now! Big Smile. ;)
Ciscofying is a cool word :D</gold>
-
@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...
I'm not going to delete your post, I'm going to save it to use use as an example of the ingrates in the community.
It doesn't matter that we worked closely with Bill to make this happen, and that the release happened < 24 hours after he got the changes to us.
It doesn't matter that we've done 5 releases since early April, to fix a variety of issues, both security-related and otherwise.
It doesn't matter that I just gave a "heads-up" to the internal resource that will either just fix this, or fix it as soon as Bill gets his change to us.No, it doesn't matter what we do, you'll and others like you (e.g. Supermule) will find a reason to complain.
-
@jflsakfja:
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.
My advice is to not hold your breath waiting for this to occur.
-
@jflsakfja:
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".
We already have plans to do somewhat similar.
Your assertion that it takes care of #1 and #2 means you don't know what you're talking about. Consider if pfSense used a new kernel, (or made changes to drivers to enable ALTQ), now you're right back to square one.
Asserting suicide as a solution tells me you're either anti-social, or quite young, and have never lost a friend, family member or other loved one to suicide.
@jflsakfja:
"Yeap, no more waiting for devs to approve a newer suricata version"
I think you should ask Bill what the timelines looked like.
-
@gonzopancho: Can I watch???? :o
The work on this is VERY much appreciated, and I know you work long hours, and hearing this criticism takes a toll… In the long run, these packages will promote pfSense! There are always going to be "those in the crowd"..
We all get frustrated and impatient. jflsakfja contributes to the discussion and helps out a lot of users. Don't want to run him off... :))
@gonzopancho:
@jflsakfja:
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.
My advice is to not hold your breath waiting for this to occur.
-
@gonzopancho:
I'm not going to delete you, I'm just going to use you as an example of the ingrates in the community.
It doesn't matter that we worked closely with Bill to make this happen, and that the release happened < 24 hours after he got the changes to us.
It doesn't matter that we've done 5 releases since early April, to fix a variety of issues, both security-related and otherwise.It doesn't matter what we do, you'll and others like you will find a reason to complain.
The release did NOT happen <24 hours after he got the changes to you. At least have the decency to tell the truth. The package was given to you 11 days ago with the intent to merge it upstream. Bill said we found a few last minute bugs, wait till we can fix them. The package was again released for merge on the 30th, which to my books is not <24 hours.
It actually doesn't matter how many releases you do in a year. Even there is no release, or a thousand releases. As long as there are outstanding bugs that are ignored (not even a single dev has responded with even an anknowledgement that something is wrong), the community will always be somewhat annoyed with devs. That is if they ignore bugs but instead focus on money-milking them.
How about instead of focusing on how to add more subscribers by shoving the subscribe button in their faces, you lot instead focus on providing a product that people want to subscribe to for the features?
As far as the ungrateful comment, have a look at who has been supporting the snort/suricata community for the past year. In my book calling him ungrateful is ungrateful.
Can you please explain to the community how entire teams dedicated to the security patching of upstream projects can be rivaled? Or care to explain to the community why you don't push customizations upstream, if they are so important?
And I never suggested suicide. That was your own conclusion. Perhaps you should talk to a professional about it. Are you feeling stressed? Are you feeling that suicide is your only solution out of the tremendous peer pressure? Please seek professional help ASAP.
There is an old saying: Don't bite the hand that's feeding you. Stick to it.
