Regarding the Fail2ban conversation in OSL tonight.
There are two versions native to SNG7
What is so special about 0.8?
1 Like
So I was not there, but Iâve dealt with this extensively in my own dev environment.
The bundled 0.8.14 version with SNG7 had customized jail configs meant for FreePBX. 0.11.1 in the el7 repo dies not. The FreePBX.sng7 package has a requirement for the 0.8.14 version and will not allow an upgrade (for good reason).
I repackaged the customized jails with 0.11.1 and posted it up on JIRA, and is now sitting in Sangomaâs lap to do something with it.
FPBX does not recognize newer versions of fail2ban at all. Shows not running in the GUI when it is.
0.8.14 of fail2ban is really old and doesnât use a database, so it really loads up a system when the log files get big. When you reboot and the log files are really big it could be at 100% CPU for several minutes while fail2ban scans the log files.
I have a JIRA open for this too and the fix is simple, but itâs in Sysadmin so we just need to wait.
Any reason besides needing to make a deadline? Were there issues with the CentOS 7 epel version at the time? That would be a good reason, but IIRC, CentOS7 was already 2-3 years old when SNG7 was born.
Admittedly, they had to bridge the CentOS6 to CentOS7 transition, and I can see the value of having the FBPX version locked as a known entity.
But SNG7 should have used the current epel version itâs baseline, even if locked down inside Sangomaâs repo. Seems the conditional logic to support either version would be pretty simple if you have it locked to two versions.
At the time Iâm sure it seemed OK, something to go back and fix later, âwe need to get it out the door.â Four or five years later it seems foolish.
Iâve been guilty of the same thing, but that doesnât make it right, and usually comes back to bite you in the âŚ
I doubt anything other than itâs what CentOS6 used, and everything was already coded for.
The good reason is that the jails are configured in the RPM. The el7 package will remove the jails.
Yes, using 0.8 because all the Sangoma staff that write the original RPM are gone is unacceptable. Whatâs even more infuriating is that I have an updated RPM that works and the project maintainers donât seem to care.
(Naive question) Wouldnât it be more reasonable to have this done by the firewall module?
Because Fail2Ban is controlled by Intrusion Detection which is a Sysadmin thing, not a Firewall thing (which is dumb and should be reviewed, as previously discussed in these forums)
Also, attempting to modify the jails from within the modules has proven to be bug riddled, as the current âfail2ban not starting debacleâ has shown us these past few months WITH ALMOST CONPLETE SILENCE FROM SANGOMA.
I have posted this before , but there is an apparently âlittle known factâ that in fail2banâs jail.conf is an option
# Specify chain where jumps would need to be added in ban-actions expecting parameter chain
chain = <known/chain>
I believe that if that was set to a known chain (that any firewall would create in the right place), much of this hoo-hah could be resolved (IWFM) and your firewall no longer need to fight with fail2ban or vice versa, all rules could remain âwell orderedâ and the âfirewallâ could leave that chain in place if it wanted to when stopped. leaving F2B working.
Undoubtedly.
But the firewall module is an odd fellow. Itâs the only OSS system level component. Probably because they thought folks would want to see it to trust it.
My sense is that the community should not be touching the firewall module, specifically because of how it is tightly coupled with sysadmin. Troubleshooting and debugging is many times harder when you are working against a black box. I say this as a fellow contributor and one who appreciates your efforts, but the arrangement really holds us back from working on this part of the code.
Always thought that was the correct approach, and have said so multiple times here.
Have also said FreePBX 16 is the right time to do it. But the âget it out the doorâ mentality will probably win out.
2 Likes
So far none of the problems Iâm hearing have anything to do with the firewall module. For the purpose of reiteration - Fail2Ban is not controlled, enabled, disabled, mutilated, or otherwise modified by the firewall module. The only changes made were actually to PREVENT the firewall module from breaking fail2ban.
This entire thread is pointing at Sysadmin, not Firewall.
Pardon my confusion. . .
Youâre saying they are not related (correct, technically, even though both are in the core business of modifying iptables) and yet someone wants to put them together on the same screen and call them all âFirewallâ. So it is confusing.
Responsive firewall is not based on Fail2ban - it uses xt_recent and counts packets.
See here for the code that makes RFW work:
Source of Iptables.class.php - firewall - FreePBX GIT
The screen I showed is not only responsive firewall.
It is RFW, âservicesâ (standard layer 4 firewall stuff, ordinary iptables) and fail2ban.
I thought it was a firewall update that caused the fail2ban breakage.
If not then what was the breaking change that caused fail2ban not to start? (still)
The fail2ban side is a transplant from Sysadmin when they moved intrusion detection over here. The nuts and bolts of the code still reside in Sysadmin, just the GUI window was moved over.
Starting somewheres around version .66, Sysadmin added 2 jails to Fail2Ban - one for Apache, and one for Zulu. The code to create the jail config files is not reliable and many times the files are not generated. Pinging @danardf
Thanks for the clarification. This makes sense to me now.
I think the better option would be to divorce F2B from sysadmin completely, moving all F2B code to the firewall module. Anything iptables should be in one spot. The firewall would be much less than it is now without the community.
Other than the F2B stuff, the only thing firewall interacts with sysdamin is reading the port assignments (and needing it for hook support).
RPM and version checks and such can be left with sysadmin for the distro.
If we ever get non-distro hook support, non-distro users might really move it forward.