Fail2ban won't start after update

Brand new install. Cannot be upstream.
Sounds like they f’d thing sup and released it without changing things. if that is the case.

This is fixed in Firewall module 15.0.11, and initial cause of this thread is due to Sysadmin. so feel free to upgrade firewall just hold off on Sysadmin. If you did upgrade Sysadmin, manually run the hook as I posted earlier.

It’s not installed:

yum list installed | grep fail2ban

You are correct. I missed that it was under available above.

If now using 0.11 , can someone show me, me as a non-distro user, what the apache-api filter is supposed to be doing?

(I have been doing fail2ban for quite a long time, so consider myself quite intimate with it)

logpath = /var/log/httpd/*access_log

failregex = ^<HOST> -.*".*/admin/api/.*".*403.*$

Thanks, not appropriate for me though. ( I don’t use apache so will bow out with a comment, *access.log is unneeded in 0.11 as the ‘state’ is now in an sqlite3 database, don’t waste cycles looking though yesterday’s news on restarting , a proper logrotate is all you need)

Appropos of nothing, looking at a couple of dozen FreePBI over the last six months, all deployed with my simple firewall and fail2ban 0.10 , but with all external devices registering and inviting over either TCP or TLS on a port other than 5000-5999 and only to a real URL , sysylog sees lots of stuff of course but all the freepbx and fail2ban logs filtered for bad actors are as busy as the Maytag repairman.

Maybe @billsimon 's recent post about ACL would be a better course to explore for VOIP

( I don’t like FreePBX chan_pjsip by default considering IP auth if the better considered restrictions are not met, chan_sip can simply do that by allowing only your ‘domain’)

The more likely exposure will be through other services though. I have previously posted about haproxy and it’s only accept SNI ability to mask any IP only based attacks that can but fail because only a TLS connection can possibly succeed yet not leak anything useful but can be certified by arbitrary certs that would be very obscure, but got little traction.

Any Takers ?

We are completely off topic at this point, but nevertheless…

I think if an intelligent, automatic ACL manager (like responsive firewall) were to be developed it should be done on parallel with the iptables option, perhaps given as an alternative choic efor Distro users or “the” access control option for non-Distro.

We are indeed completely off topic, but access to SIP service is one thing, access to UCP or provisioning can use another certificate provided to those services which should be in MHO not the same as your public facing WebSite

TLS allows us to provide and control the certificate provided and sharing that same cert with your public facing presence is maybe not the best idea.

iptables can filter your access quite well , but add TLS and you have ‘belt and braces’ for anything that passes/evades that simple filter, on a lower level, I almost never see connection attempts to TCP/5000-5999 apart from occasionally to 5080 (Freeswitch)

Keeping the off-topic theme going… I don’t really agree that the firewall needs to be fundamentally changed.

@dicko is correct that once SIP is moved off the 5000 range and using TCP or TLS, hacking attempts go down considerably. fail2ban mixed with xt_recent iptables rules do the trick perfectly, and I have this setup on my FusionPBX tenants with a 0% hack rate.

@billsimon is right as well, that FreePBX is supposed to manage Asterisk. But SNG7 is a distro and is supposed to roll everything in, including security. Hence, my position on this is that if you’re going distro, you’re entitled to security provided at the root level by the distro. If you want to roll your own OS, then YOU are responsible for the security of that system and FreePBX doesn’t have to do that for you, much like installing any application doesn’t setup security for you. Installing Apache or Asterisk doesn’t automatically create firewall rules… Why should FreePBX?

Opening up the firewall module to not require sysadmin is a possibility but is completely unnecessary for essential security. RFW is just a set of xt_recent rules that are loaded when the firewall is started. The only necessary dynamic component is whitelisting registered IP addresses which, if you roll your own OS anyway, you can easily script yourself as a cron job. And really, fail2ban is quite good by itself with the proper configuration. If you want a GUI to do the firewall for you, just use the distro.

Thank you but

Opening up the firewall module to not require sysadmin is a possibility but is completely unnecessary for essential security.

only pertains to the “the distro” and there are more and more people who can’t do that either essentially or opportunistically

Maybe when Zend dies (it has already) and ironcube is used in a more benign regime . . . .

We can’t overview the code, even you are guessing . as @sorvani has questioned. (And I realize you are not in the position to answer this.)

I can assure you that a basic fail2ban >=0.8 has been working for me for +lots of years, We always start the fail2ban-client AFTER ALL other rules are in place, that has never been a problem, the client behaves well.

But again reasonable use of iptables (SIP filters) just won’t pass anything because about two firewall rules will just stop 99.9+% of all that crap .

BTDT and obviously JM2CWAE

Fixed in Sysadmin v15.0.21.65 on EDGE

1 Like

@danardf - We were seeing this on 65 and 66… Was there a patch (re)released yesterday that didn’t increment the version numbers?

Current edge version of System Admin is 15.0.21.67

If it’s long gone, why hasn’t it been updated via yum or FreePBX on some of my servers?
Anything I can do to push it?

In resect to .8 being outdated, if I try to update here is what I get:
yum install fail2ban-fpbx
Loaded plugins: fastestmirror, versionlock
Loading mirror speeds from cached hostfile
Package fail2ban-fpbx-0.8.14-76.sng7.noarch already installed and latest version
(For reference Running: Derived from Red Hat Enterprise Linux 7.8 (Source) )

. . . fail2ban-fpbx-0.8.14-76.sng7.noarch . . .

You would have ask Sangoma that.

fail2ban closed that branch six years ago

There’s an open ticket for this that isn’t being dealt with. Vote for the issue to give it some traction:
https://issues.freepbx.org/browse/FREEPBX-22578

Done.

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