So as of late yesterday, System Admin ver. 15.0.21.71 was promoted to stable which should resolve the fail2ban starting issue. Upgrading sysadmin can be done in the conventional way using the GUI or you can run:
fwconsole ma upgrade downloadinstall sysadmin --tag 15.0.21.71
would return, apparently the systemd fail2ban.service is disabled in the distro so something is otherwise doing fail2ban-client -x start or systemctl start fail2ban (both of which would fail if it is actually already running) , as to your previous iptables status, then iptables -L -n before and after might be helpful
of course yourfirewall.service should not be messing with fail2ban in any way (tested working on f2b >= 0.8 with its distributed systemd service installed for “lot’s of years”)
ERROR Found no accessible config files for ‘filter.d/zulu’ under /etc/fail2ban
ERROR Unable to read the filter
ERROR Errors in jail ‘zulu’. Skipping…
This is why I originally uninstalled Zulu. I just tried reinstalling it and running the command again. Same result.
Usage: /bin/fail2ban-client [OPTIONS]
Fail2Ban v0.8.14 reads log file that contains password failure report
and bans the corresponding IP addresses using firewall rules.
Options:
-c configuration directory
-s socket path
-p pidfile path
-d dump configuration. For debugging
-i interactive mode
-v increase verbosity
-q decrease verbosity
-x force execution of the server (remove socket file)
-h, --help display this help message
-V, --version print the version
Command:
BASIC
start starts the server and the jails
reload reloads the configuration
reload reloads the jail
That seems to have done it on this server. Intrusion detection rules were of course wiped out but syncing it with the trusted networks and registered extensions works now.
Will go check the other servers that were having this issue and report back. Thanks.
In case this fixes anyone else’s issue my sysadmin module was updated via the GUI to the edge track (forgot that was set to edge mode) to version 15.0.21.72 . I commented out the lines about the zuu jail in /etc/fail2ban/jail.local. Then ran fail2ban-client -x start and now it appears to be working. Will see if CPU usage goes up again.
It will always be higher if you restart it later in the day as your logs grow, well written logrotate mitigates a little in the early morning by resetting the log files being watched to 0 length , but while fail2ban remains at 0.8 you are hamstrung until Sangoma takes this problem seriously and decouples “intrusion detection” from it’s commercial “firewall” or at least makes them play well together. IMHO F2B >=0.10 would be a good place for them to start (as far is I can experiment, badly written “jails” are no longer fatal, just ignored)
fwconsole ma downloadinstall sysadmin --tag 15.0.21.66 -f
```did it for me. Stepping back from 15.0.21.71. However same error before in ..71.
I'm not using Zulu.
see CLI, where sysadmin_fail2ban is updated.
No repos specified, using: [standard,extended,commercial] from last GUI settings
Starting module download from https://mirror.freepbx.org/modules/packages/sysadmin/5.6/sysadmin-15.0.21.66.tgz.gpg ...
Processing
Downloading...
852497/852497 [============================] 100%
Finished downloading
Extracting...Done
Module https://mirror.freepbx.org/modules/packages/sysadmin/5.6/sysadmin-15.0.21.66.tgz.gpg successfully downloaded
Updating tables sysadmin_options, sysadmin_update_log, sysadmin_fail2ban...Done
Sangoma PnP Server activated
Generating CSS...Done
Module sysadmin version 15.0.21.66 successfully installed
Updating Hooks...Done
Chowning directories...Done
[root@freepbx fail2ban]# systemctl start fail2ban.service
[root@freepbx fail2ban]#
I will not upgrade to ..72 again until green light from Lorne
I’ve got another with a similar problem but this time it’s got a problem with apache-api jail. Is that safe to comment out?
fail2ban-client -x start
ERROR Found no accessible config files for ‘filter.d/apache-api’ under /etc/fail2ban
ERROR Unable to read the filter
ERROR Errors in jail ‘apache-api’. Skipping…
Unfortunately as yet everything posted in this thread (and other similar ones) are closed source as to resolution , so you will have to add your problems behind the dozens of other unresolved dependencies that await attention by Sangoma.
( crocodiles have alarm clocks, a quick ameliorative I can suggest is to stop listening to UDP/5060 before it bites you, and sngrep will show all the exposure you already have, because your firewall is apparently broken and every ‘bot’ and their ‘controller’ knows it)
Best choice a properly configured and certified TLS on 5061 (easy), next a TCP connection on anything outside 5000-5999 (BTDT, they are not stupid) , lastly and for UDP if you insist , at your chosen random port between 49152 and 65535.
Everyone will tell you that security by obfuscation is dumb, I disagree, add an iptables ‘port scanner’ to DROP such attemp’s and wait for an intrusion . . .
Again TLS is the way to go, your STIR/ SHAKEN headers can’t be fragmented (as ultimately they will over UDP as the concept gets traction) . . .
For what it’s worth I took the apache-api.conf from another server and uploaded it to the one where I had that problem and it seemed to fix the issue. The file is only a couple lines long if you want to try it
API filter access forbiden 403
[Definition]
failregex = ^ -."./admin/api/.*".403.$
ignoreregex =
The comment seems to trigger bold characters in the forums, but that first line is commented out. Also, permissions set to root (group and owner) and octal 0644