So fail2ban was discussed in the OSL tonight

From a coding standpoint this is simple. The problem is trust. Once anyone can sign, malicious actors can exploit vulnerabilities in the firewall to gain root to the machine.

1 Like

Not sure it makes sense.

You’re both right depending on point of view.

RFW itself has little to do with F2B, the F2B config files are in the RPM, the core F2B management code is in sysadmin, but they’ve put a fair amount of F2B control under the firewall module at this point.

It needs to change. Pretty much anything iptables/f2b should be in the firewall module, IMO.

I would bring the RPM back down to essentially duplicating the stock epel release, only being in the sangoma repo to prevent an incompatible upgrade, but otherwise tracking epel for any bug/security fixes after vetting.

Sysadmin/anaconda/rpms could be responsible for a minimal /etc/sysconfig/iptables.default, but not much else.

Let the firewall module generate the needed jails and other config for F2B, just as it does for iptables.

1 Like

Where?

Agreed and I think that is the sentiment of the entire community, with one modification:
I think jails should be controlled from the RPM to avoid possible compatibility issues. The problem here is that the RPM hasn’t been touched since early 2018

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.