So fail2ban was discussed in the OSL tonight

If so inclined, I could post to github a stub for hook support in minutes.

But your right, the only thread to claim any sort of security for the hook system is proper signing and zend(/ioncube).

We need something both sanctioned and with at least the same security as the distro.

I have the feeling if I tried cleaning and wrapping my stuff up into a sysadmin-oss module, Sangoma would start sending me letters.

What about intrusion detection sync?

Also, fail2ban will no longer start via fwconsole unless firewall module is installed and enabled in Admin > Module Admin. So they are linked in that way too as far as I can tell.

It is an open source module 100% because @xrobau did most of the work in his spare time and demanded it be open source.

Sometimes forgiveness over permission and publicly releasing stuff just works :upside_down_face:

3 Likes

Fun fact as long as you abide by the license etc they can write as many letters as they want. Realistically it is better for someone who has never seen the proprietary code to write an open source version. Then they can’t make any claims of copyrighted code. Some things will be the same because there are only so many ways to skin a cat…

Hmm. Good catch.
Actually, I’m realizing now that my “fail2ban bypass” feature should only be shown on non-activated systems so as not to cause a conflict with this service.

I think this is also coming from Sysadmin, not from the FW module.

Thanks @xrobau!

1 Like

I suspect this tip that you gave on a different thread could be useful - haven’t tried it yet, myself.

(As an aside, this was one of the most lively discussions I have seen in OSL and I regret that I had to leave at ten minutes before the hour when the Distro OS discussion was going strong)

1 Like

I’ve thought about, but have had other workarounds so far.

My un-researched assumption is the EUA probably has something to dissuade recreating a duplicate “sysadmin.”

It would be nice to drop in an oss version of “sysadmin” and have existing hook code just work. “Just working” sounds nice, but anything not on the distro needs to be aware of it.

If I were to move forward. I’d probably lean toward the runhook code explicitly checking for either “sysadmin” or “oss-hooks” or similar.

As I wrote pretty much all of that code, there is nothing that I can think of that would stop someone from doing it. In fact, the most important file is explicitly not zended, as you would have noticed.

The problem is that all the hooks are EXTREMELY TIGHTLY INTEGRATED with RHEL 7 based distros. That’s going to be the problem. Running hooks are easy. Look at the firewall (which is open source) hooks for example, and check /var/log/cron and /var/log/messages for more information.

1 Like

Hooks should be done with systemd as that is not rhel.

Not to mention that incron has been dead for 6 years.

And I would bet that nothing has been done about it. Just like fail2ban.

I was going to say it’s NOT dead, but it appears like it is. That’s annoying. I’ll see if I can get him to transfer the repo to me, and I’ll take it on.

Apart from a few tiny bugs, it’s a stable, fully functioning, service and it doesn’t NEED continuous updating and changes.

That does not change the fact that the project should switch to systemd paths with inotify.

Why packaged? Why can the module not just create config files. Why is this so hard?

Current versions have a nasty race condition, easy to trigger that will bring down the server. Would be nice to get it fixed. I use direvent for my own needs.

Agree in principle, but path units are far from a drop in replacement. To avoid an annoying amount of new systemd “services”, legacy hooks and modern hooks should be consolidated, and code added to sysadmin_manager to determine what file actually triggered the event.

All very doable, but unfortunately I don’t see Sangoma caring enough to do it, and community contributions are not possible since it’s closed source.

1 Like

Probably because that’s the best he could do with it locked up inside sysadmin.

I wanted this to be a drop in replacement for the current version in the distro. Nothing was changed except the underlying version of F2B and a couple if bug fixes in the jails (like PJSIP compatibility)

Your pre-edit was likely more accurate. Responding to that, yes that is a really stupid problem. Creating files should not be a hard thing.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.