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 188.8.131.52
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 -- 184.108.40.206 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.
The fail2ban you’re showing is upstream and not available on FreePBX.
Currently, we’re using 0.8.14 which is old, and I’ve posted an update to 0.11.1 here attached to this ticket:
[FREEPBX-22543] Firewall service restart is not adding the fail2ban chains to iptables. - Sangoma Issue Tracker
The problem is that because of process forking, there is a small update in Sysadmin that needs to be made to detect that fail2ban is running, so that the dashboard and Intrusion Detection continue to work.
This is in firewall and closed: https://issues.freepbx.org/browse/FREEPBX-22562
This is for Sysadmin and is open (so vote for it): https://issues.freepbx.org/browse/FREEPBX-22578
Brand new install. Cannot be upstream.
Sounds like they f’d thing sup and released it without changing things. if that is the case.