Suricata 2.0.3 Package Preview

bmeeks

@mais_um:

Oh c'mon people. We are crying where and you said hold off?? you are kidding right? Bill :P

Not kidding about the bug in IPv6 addresses when $EXTERNAL_NET is set to !$HOME_NET. If you set $EXTERNAL_NET to "any", then no problem except that causes a ton more alerts that are mostly false positives. This is because many rules are written to discriminate traffic based on $HOME_NET and $EXTERNAL_NET reflecting your true setup (where $HOME_NET represents only the networks your protecting, and $EXTERNAL_NET is everything else). If $EXTERNAL_NET is set to "any", then this rule paradigm is not true.

The Suricata and Snort packages have always used "$EXTERNAL_NET = !$HOME_NET" on pfSense as the defaults. So I have decided for now to not change those defaults and instead post a warning that IPv6 traffic will not always be correctly alerted on in Suricata until either I or the upstream Suricata guys can find out what's wrong in the binary.

Bill

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.

Cino

I can also confirm this bug.. Hopefully it can be found but at least there is a workaround for now…

bmeeks

@Cino:

I can also confirm this bug.. Hopefully it can be found but at least there is a workaround for now…

I've sent a message to the Suricata team about it, but received no response yet. Also tagged onto a similar (if not possibly the same) issue posted on the Suricata Bug Tracker Redmine site.

I've released the package for review by the pfSense guys, but will continue looking for the bug in the binary. It's a complicated source code package, and it's a little tough to reverse engineer something in the first place, and as I mentioned previously, IMHO there is not a lot of commenting in the code explaining the functions or logic flow. So finding this bug is a challenge…but I do love a challenge... ;)

Bill

Cino

Thanks Bill! Looking forward to the new release

Raul Ramos

Thanks

I will test PPPoE support in my WAN interface, and other things.

bmeeks

Update on IPv6 bug progress –

I have received an acknowledgement from the Suricata project guys on the IPv6 bug. At least one of them was able to reproduce the issue with IPv6 addresses within rule variables not generating alerts even on a match where they should. Hopefully a fix from them will be forthcoming soon. In the meantime, I'm continuing to look for the bug on my own.

As mentioned in a post above, I released the package for review and merge by the pfSense team. If the binary fix for Suricata comes through before they complete the GUI package code review, I will try to get it included with the initial 2.0.3 binary and GUI v2.0 release. If not, then as soon as the binary fix becomes available, I will post an update to the update (that is, a v2.0.1 of the GUI package versus what will be v2.0 of the GUI package).

The bug only impacts IPv6 alerts, and only when rules contain RULE VARS. But since a ton of the rules do contain the RULE VARS $EXTERNAL_NET and $HOME_NET, then a lot of IPv6 alerts don't happen. However, IPv4 works just fine. So if you have an IPv4-only installation, you will have no issue. Only IPv6 setups will have some potential "no alerts" on IPv6 traffic until the bug in the binary is found and fixed.

Bill

wcrowder

How 'bout just merge it, call it "beta" and let us play with it already… I know, i know... I need a life... LOL! ;D

zerodamage

We need this package update as soon as possible. Suricata just doesn't stay running for me right now.

Supermule

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.

wcrowder

Bump…

bmeeks

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/1120

Bill

AhnHEL

@bmeeks:

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.

bmeeks

@AhnHEL:

@bmeeks:

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

wcrowder

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

Supermule

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

@Supermule:

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.

Supermule

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