Glad to see such a respected member of the community is testing out beta software and working to improve the user experience. All feedback is valuable and helps us improve. This is the great thing about the open source community. Please test out your theory and let us know what happens. If things do not work as expected please feel free to file a bug report at http://issues.freepbx.org with steps to reproduce your results. As always the code is available on github if you would like to provide any patches. Patches are always welcome.
1 Like
Works exactly as expected. Server crashes. Server reboots. Bad guys get a 5-minute free pass through the disabled firewall. Glad you have a sense of humor about it… so far.
How did you make the server crash? Can you provide steps to reproduce this attack vector?
1 Like
After an insanely obvious suggestion by @SysAdminMan I’m now not letting you install the firewall module if the sysadmin RPM isn’t installed. facepalm. Sorry for being dumb. That and a couple of other things makes 13.0.10. Which I’m feeling REALLY good about.
Edit: Another fix in 13.0.11 was some bad chan_sip detection.
Hi Rob
Edit - Just saw you made the code change with the 1000 default. Many thanks!
Hi Rob
Actually, I’m still seeing an error about /proc/timer_list (failed to open stream).
(firewall | 13.0.11.1)
I think it just needs to check it exists before trying to open here?
public function getCurrentJiffie() {
$jf = file("/proc/timer_list", \FILE_IGNORE_NEW_LINES);
// Find the first entry that is 'jiffies: ' and return it
foreach ($jf as $l) {
Also, even when bypassing that warning I don’t see the firewall start after 5 minutes (even though the message in the GUI about being disabled for the first 5 minutes disappears). Please could you point me to how the firewall is getting started so I can check if this is specific to me or a general thing. The firewall rules do actually get applied if I enable/disable the firewall in the GUI, so it is working OK I think, just not getting started after the 5 minute period.
One last thought … it seems during those first 5 minutes any default firewall rules are left in place. There’s a chance, depending on what rules where in place before the FreePBX firewall was enabled, the user could still find themselves locked out.
If it’s decided to have this 5 minute “open” period it’s probably a good idea to actively ACCEPT and flush any rules.
Thanks - Matt
If you manually modify any code in the firewall it won’t start. Just FYI.
Ah, ok, thanks Andrew. I’ll wait to see if Rob pushes out a fix for the issue I’m having with timer_list and see if the firewall starts normally after that.
Thanks - Matt
is this firewall going to work with HA ?
FYI Rob,
Wouldn’t it be possible to create a check box or switch named “Add all registered IPs to Other zone”? This could eliminate the need to add a separate zone called register. This would effectively add a target rule in the fpbxknownreg chain that will go to the zone-other chain, which can run any extra or custom services to allow the registered IPs in. This eliminates the need for a whole lot of extra work, and at least is a place to start until smarter people than I have a better idea of what to do. (Unless said idea is already being worked on, then I’ll just stop talking. 
And if that is the case my feature request/bug report can be deleted - http://issues.freepbx.org/browse/FREEPBX-12388)
-Jon, Xpedeus
Hello. I just installed the latest FreePBX 13.0 on centos 7 per the wiki here: Sangoma Documentation and ran into the following when trying to install the module from the webui:
Exception: Hook file '/var/spool/asterisk/incron/firewall.firewall' was not picked up by Incron after 5 seconds. Is it not running?
if (!$deleted) { throw new \Exception("Hook file '$filename' was not picked up by Incron after 5 seconds. Is it not running?"); }
and the related callstack information:
/var/www/html/admin/modules/firewall/Firewall.class.php231
4.
FreePBX\modules\Firewall
runHook
/var/www/html/admin/modules/firewall/OOBE.class.php28
3.
FreePBX\modules\Firewall\OOBE
oobeRequest
/var/www/html/admin/modules/firewall/Firewall.class.php44
2.
FreePBX\modules\Firewall
oobeHook
/var/www/html/admin/libraries/BMO/OOBE.class.php145
1.
OOBE
runModulesOOBE
/var/www/html/admin/libraries/BMO/OOBE.class.php167
0.
OOBE
showOOBE
/var/www/html/admin/config.php446
This shows up when I now try to load the landing page. My systemctl status for incrond is as follows:
[root@pbx ~]# systemctl status incrond
● incrond.service - Inotify System Scheduler
Loaded: loaded (/usr/lib/systemd/system/incrond.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2016-06-16 22:25:01 PDT; 16min ago
Process: 908 ExecStart=/usr/sbin/incrond (code=exited, status=0/SUCCESS)
Main PID: 915 (incrond)
CGroup: /system.slice/incrond.service
└─915 /usr/sbin/incrond
Jun 16 22:25:01 pbx.box incrond[915]: loading table local
Jun 16 22:25:01 pbx.box incrond[915]: loading table sysadmin
Jun 16 22:25:01 pbx.box incrond[915]: loading user tables
Jun 16 22:25:01 pbx.box incrond[915]: loading table for user root
Jun 16 22:25:01 pbx.box incrond[915]: ready to process filesystem events
Jun 16 22:25:01 pbx.box systemd[1]: Started Inotify System Scheduler.
Jun 16 22:25:20 pbx.box incrond[915]: (system::sysadmin) CMD (/usr/bin/sysadmin_manager firewall.firewall)
Jun 16 22:25:42 pbx.box incrond[915]: (system::sysadmin) CMD (/usr/bin/sysadmin_manager firewall.firewall)
Jun 16 22:34:47 pbx.box incrond[915]: (system::sysadmin) CMD (/usr/bin/sysadmin_manager firewall.firewall)
Jun 16 22:40:54 pbx.box incrond[915]: (system::sysadmin) CMD (/usr/bin/sysadmin_manager firewall.firewall)
I had also been having issues with firewalld and extensions trying to register timing out, but resolved the timeout issues when stopping and disabling firewalld. Obviously, I’d rather not have the firewall be down but I was testing to make sure I installed everything else correctly and in the process found that my yate client running in the same subnet can only register with my Centos 7 FreePBX system when firewalld is stopped. I installed the module in hopes of fixing this but installing the module led to my now not being able to access the ui at all.
I had also installed sysadmin using yum install since the module admin was warning me regarding having sysadmin rpm installed prior to installing the firewall module and I’m not sure if this did irreversible damage to the system.
I tried to run “fwconsole uninstall firewall” and when following that with “fwconsole restart” and loading the webui, I’d get:
0
System Admin 13.0.47.3
Copyright 2016 by Schmoozecom, Inc., All rights reserved
By installing, copying, downloading, distributing, inspecting or using
the materials provided herewith, you agree to all of the terms of use as
outlined in our End User Agreement which can be found and reviewed at
www.schmoozecom.com/cmeula
I had tried yum removing sysadmin as well and I still get the same message from the documentroot of the webui.
At this point, I’d be more than OK with reverting back to a working version and wait for a version of the module that will run with CentOS 7 but can’t find info on this.
Thank you.
Sysadmin, which firewall requires, only works on the freepbx distro.
1 Like
There are other requirements, such as a compatible zend loader, which all stem from the need of a secure manner of being able to do stuff as root from the webui.
However, I’ll be making sure that Firewall works perfectly with the new C7 based distro, when it’s released.
in the meantime, is there any advice for a civilian like myself on how to revert to what I had before so that I can regain access to the webui…that is, outside of reinstalling freepbx? I may also opt for disabling firewalld and migrate the rules to the iptables service if that’s not ill-advised. Thanks!
upon doing a bit of reading, I’m just a bit confused. Accordingly to the firewall entry in the wiki here: http://wiki.freepbx.org/display/FPG/Firewall, “The Firewall module is a 100% Free Open Source Module, licenced under the AGPL v3. The code is hosted on git.freepbx.org with a mirror on GitHub for your convenience. Pull requests are welcome!”. And it requires
“'sysadmin-rpm’This
is a RPM package that allows secure privilege escalation in limited
circumstances. Firewall requires this to alter the system iptables
rules. This RPM is installed on most modern RPM-based distros.
Currently there is no method for privilege escalation without this
package. Support for non-rpm-based operating systems is on hold until
this issue is resolved.”
But I’ve been reading that sysadmin is a commercial module which depends on Zend guard loader and more so that any component that requires it is only commercially available.
I just wanted to get some clarity on this before I find out that I’m spending all this time on a firewall that I, as a non-commercial user, will never have access to. Thanks.
Firewall requires sysadmin because it needs incron to manage it’s tasks. This is the only way firewall can manage iptables without requiring root. It’s a double security situation. Sysadmin & Incron won’t perform tasks if the hooks have been tampered (GPG protects this) with as well.
If there was a way around this requirement we would be all for it but the only way around it is to put asterisk into the root wheel and that’s not something we want to do.
rm -rf /var/www/html/admin/modules/sysadmin
That will then remove all the Zended code that’s confusing your machine, and it will then appear as a broken module which can be removed through the UI.
@tm1000 nailed it. There have been some discussions in this thread, but no-one’s come up with code that solves the fundamental problem - how do we make this secure WITHOUT using Sysadmin and its associated infrastructure?
And yes, firewall is 100% open source, and if you read the source, all the places that sysadmin is required is documented and explained, in the hope that someone smarter than me can figure out a way to do it 8)
Edit 2 years later: It’s possible that someone is willing to spend some time on this! See Firewall Questions - #22 by xrobau
tm1000 and xrobau: thank you so much for that information and help. I have it up and running and reverted to iptables for now until the firewall situation is sorted. It’s peculiar that icrond per the systemctl bit above shows it being properly triggered, but the firewall issues an error message asking if icrond is on. Or maybe it’s not so peculiar at all. I don’t know.
Perhaps there’s a way to manually let whatever file is listening for confirmation that incrond has done something with firewall.firewall that incrond has done so?