Of course it can be Sangoma. But it has to be done in something that can be installed on all systems, unlike SysAdmin.
Access control doesn’t have to be done in the kernel.
Care to explain? Both iptables and fail2ban require root.
I’m talking about using ACL functionality in Asterisk. It’s not a drop-in replacement to iptables but it fits better within the paradigm of FreePBX working with asterisk configuration as the asterisk user. Maybe a direction to consider for FreePBX 17.
Wanted to add to this thread. Same issue with the GUI indicating Fail2Ban not running, same error codes when attempting to start the service. Same Apache error - ‘filter.d/apache-api’ under /etc/fail2ban ERROR Unable to read the filter ERROR Errors in jail ‘apache-api’. Skipping…
Solution that worked for me on 4 FreePBX 15 was ashcortech in the last update.
I’m not trying to be disruptive, but can someone qualify exactly what version of Fail2ban is being deployed? and who wrote the systemd fail2ban.service that is apparently being used to start it?
Last mention of 0.8 is ‘quite a long time ago’
@yois Yes, all current for all modules & OS, all activated, and nothing I do changes the behavior, a few boxes are doing it and others are not.
Note: PBX is 100% Current for OS & Modules
Running: FreePBX 22.214.171.124
Reboot does nothing to resolve.
First here is a video showing how the GUI reacts: https://screenrec.com/share/3lwCtWNBG5
Error trying to start the server image: https://screenrec.com/share/nmZrcENs3b
Oput from status was provided above.
If there is an official Sangoma person that would like to remote in to see it for themselves I can work with you to connect to one of the PBX’s with this issue.
New system I setup last week. Nothing done yet but testing some export/import stuff in bulk import. Clean install of FreePBX 15 on Vultr, then registered to a PBXact license.
[jbusch@uc-90XXXXXX ~]$ sudo yum list fail2ban [sudo] password for jbusch: Loaded plugins: fastestmirror, versionlock Loading mirror speeds from cached hostfile Available Packages fail2ban.noarch 0.11.1-9.el7.2 sng-epel [jbusch@uc-90XXXXXX ~]$
Then let’s first make sure first that everyone is on that same page , Fail2ban 0.8 is long gone, 0.11 has it’s own included systemd service file that you can deploy, a cavetae is that it might not behave nicely with any particular ‘firewall’
The firewall adds to
@VoIPTek - Try running
Indeed, but the question remains “when” and “where” ?
FYI, since I know you don’t have it anywhere distro based:
[jbusch@uc-90XXXXXX system]$ sudo systemctl status fail2ban ● fail2ban.service - Fail2Ban Service Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; disabled; vendor preset: disabled) Active: active (running) since Sun 2021-07-11 19:58:33 CDT; 2 days ago Process: 2911 ExecStop=/usr/bin/fail2ban-client stop (code=exited, status=0/SUCCESS) Process: 2981 ExecStart=/usr/bin/fail2ban-client -x start (code=exited, status=0/SUCCESS) Process: 2979 ExecStartPre=/bin/mkdir -p /var/run/fail2ban (code=exited, status=0/SUCCESS) Main PID: 2985 (fail2ban-server) CGroup: /system.slice/fail2ban.service ├─2985 /usr/bin/python /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.... └─2987 /usr/libexec/gam_server Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. [jbusch@uc-90XXXXXX system]$ sudo cat /usr/lib/systemd/system/fail2ban.service [Unit] Description=Fail2Ban Service After=httpd.service [Service] Type=forking ExecStartPre=/bin/mkdir -p /var/run/fail2ban ExecStart=/usr/bin/fail2ban-client -x start ExecStop=/usr/bin/fail2ban-client stop ExecReload=/usr/bin/fail2ban-client reload PIDFile=/var/run/fail2ban/fail2ban.pid Restart=always [Install] WantedBy=default.target [jbusch@uc-90XXXXXX system]$
I suggest better to deploy pyinotify over gam, but that’s another story
iptables -L -n will show the priorities
if it changes dependent starting another iptables aware process there might be a problem
Unrelated to this thread, is the issue of the rules disappearing. I think @yois has/is working a patch for that.
[jbusch@uc-90XXXXXX ~]$ sudo iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination fail2ban-SIP all -- 0.0.0.0/0 0.0.0.0/0 fpbxfirewall all -- 0.0.0.0/0 0.0.0.0/0
[jbusch@pbx1 ~]$ sudo iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT udp -- 126.96.36.199 0.0.0.0/0 udp dpt:161 /* Skyetel SNMP */ fpbxfirewall all -- 0.0.0.0/0 0.0.0.0/0
Indeed, but as yet apparently problematic.