FusionPBX Blocks Webmin

[KitchM]

Raspberry Pi with OS Lite. It does not matter if Webmin is installed first or FusionPBX is, once FusionPBX is involved the remote connectivity to Webmin is broken. The login is normally something like 192.168.1.10:10000. Port 10000 ceases to be available, but I don't know what Fusion does to create this situation. It did not happen that way a couple weeks ago.

Does anyone have any ideas about that?

 

[DigitalDaz]

It should always have worked like that. Where does webmin, have anything to do with FusionPBX

Look in your /etc/iptables/rules.v4, you will need to add a rule to allow it.

 

[KitchM]

FYI, sysadmins know that managing a server of any sort often is made easier by the use of a server management tool. Since FreeSWITCH is a server software, the use of it creates a server. I strongly recommend the use of a tool such as Webmin.

Sadly, there was a change in the install package with unnecessarily blocked the use of other remote control tools. That was unfortunate and totally unnecessary.

 

[DigitalDaz]

Dude, you talk absolute BS.

As someone who probably manages more than 100 servers and has done for 10 years plus, many of which include webmin, I can tell you, there is absolutely no reason to need webmin on a PBX.

Moreover, mr sysadmin, if you believe the install package has had a change made that blocks the use of other remote control tools, can you kindly point me to the piece of code that does that?

I can easily point you to the piece of code that has been in place for years now that will stop webmin functioning:

fusionpbx-install.sh/debian/resources/iptables.sh at master · fusionpbx/fusionpbx-install.sh

Contribute to fusionpbx/fusionpbx-install.sh development by creating an account on GitHub.

github.com

 

[glk70]

I have Webmin installed in all fusionpbx machines.
no prb at all
of course you have to change firewall rules
to start with you can enter this command

iptables -A INPUT -p tcp --dport 10000 -j Accept

To this command you can add CONNTRACK and other options, but as you are using a raspberry.... i 'd preferr the simplest command.

 

[markjcrane]

No effort whatsoever was put into blocking webmin. It maybe useful tool for some people however I think most server administrators don't need it.

 

[KitchM]

@DigitalDaz, your astounding narrow-mindedness has obvious kept you from seeing your extreme BS, and has exacerbated your meanness.

@glk70, you are quite right. There is also the simple opening of all to the LAN. But a good tip none-the-less. Thanks.

@markjcrane yes, perhaps it was unintentional. But so many of the default rules were unnecessary that starting over was preferred. My strong suggestion would be to not make rules but explain how to customize them for each user. This would help the user understand security methods a little better, and would make sure that the rules were correct for that user. Just an idea.

 

[ad5ou]

My strong suggestion would be to not make rules but explain how to customize them for each user. This would help the user understand security methods a little better, and would make sure that the rules were correct for that user. Just an idea.

Personally, I think if a user doesn't have a fair understanding of firewall rules and security needs of a VOIP server, they don't have much business attempting it. The default rules installed by Fusionpbx help keep the basic security needed in a VOIP server to avoid costly mistakes for first time users/testers/etc.

It is also fairly common expectation that a PBX server is generally a dedicated "appliance" and should not skip standard security steps on the off chance a user wants to run other network accessible services.

The quick install guide "assumes you are starting with a minimal install of Debian 9 with SSH enabled" Which would mean Webmin or other services are not expected (or needed). At the completion of the installation script the user is left with all of the required software of a functional PBX and configured to not leave your system fully exposed to the wild internet.

Any other configuration or additional apps would be considered a more advanced installation and a user should not expect everything to work without some extra effort to see the expected results.

 

[KitchM]

Interesting as your comment is, I believe that if a person is going to set up any sort of server, they should become familiar with security issues. (This is not difficult with the proper documentation.) One of these is Netfilter. There should never be so-called standard measures since each setup may be different.

One thing that should never be is to have any ports open that are not needed. This is one "standard" I would support. Therefore, there is little use for port 22 on a daily basis.

IMHO, I find that the Fusion security setup is lax, and that the quick install is assumptive.

 

[ad5ou]

Of course the quick install is assumptive. That is the very nature of such a tool. The whole point of install scripts is to install the baseline software and configurations to allow the "app" to function.

One assumption is the install is likely being installed on a headless server such as a virtual machine via SSH. The script also installs fail2ban to help guard against attacks to port 22.

Your comments are conflicting. Once statement you say the script shouldn't automatically make rules for ports not in use but the next thing says ports not needed should be closed.

If you have real concerns with assumptions made in the install script or anything else related to Fusionpbx, the code is open source so feel free to change things as you see fit. https://github.com/fusionpbx and optionally submit such changes as a pull request. https://docs.fusionpbx.com/en/latest/contributing.html

 

[KitchM]

The first assumptions are bad ones.

Also, there are no conflicting statements. Default inbound to DROP. Problem solved.

So there is one thing that should have been a proper assumption and obvious.

 

[ad5ou]

The first assumptions are bad ones.

Your opinion.
In reality every fusionpbx admin or advanced training class starts with installing a fresh copy of fusionpbx to a VPS instance via SSH. The vast majority of active fusionpbx community members use some form of virtualization on at least one instance of fusionpbx. Many users host "production machines" on bare metal, but also have test environments on a VM while many others use virtualized instances in production.

Also, there are no conflicting statements.

There are.

My strong suggestion would be to not make rules but explain how to customize them for each user

There should never be so-called standard measures since each setup may be different

conflicts with

One thing that should never be is to have any ports open that are not needed. This is one "standard" I would support

Default inbound to DROP.

Also default inbound to DROP would effectively break webmin which is what this whole thread is about.

 

[KitchM]

When people take things out of context, they can make anything appear any way they wish. This you have done.

To compound the error, you state a way you do things as if it means something. It doesn't; its just your opinion, in much the same way you state:

The vast majority of active fusionpbx community members use some form of virtualization on at least one instance of fusionpbx.

All a person can say to such statements is "So what?" There are 7.5 billion people on the planet, and that leaves a realtive few computer users. Of that there is an infinitesimal sub-fraction of people who attend your training classes.

 

[DigitalDaz]

We DO do default inbound to drop. @KitchM, the reason you get the answers you do is because of the completely false and slurring statements you make.

Those IP tables rules that will block webmin have been in there for as long as I can remember now. You implied there has been a recent change.

The statements you make are just not factually correct.

 

[KitchM]

@DigitalDaz I may have been wrong about a recent change. But that is beside the point of your bad attitude and slurs.

Every other statement I have made is indeed factually correct and can be proved as so.

BTW, I can carry on a good conversation with others, even if we do not agree. Not the same with you.

 

[DigitalDaz]

If you look at the start of the post, I answered you and I told you how to fix it. Job done, then in the third post you had to start having a go at the project:

Sadly, there was a change in the install package with unnecessarily blocked the use of other remote control tools. That was unfortunate and totally unnecessary.

I don't even have a problem with that when its true but it wasn't.

 

[ad5ou]

When people take things out of context, they can make anything appear any way they wish. This you have done.

To compound the error, you state a way you do things as if it means something. It doesn't; its just your opinion, in much the same way you state:


All a person can say to such statements is "So what?" There are 7.5 billion people on the planet, and that leaves a realtive few computer users. Of that there is an infinitesimal sub-fraction of people who attend your training classes.

Nothing was taken out of context. It was literally in the same context of the above thread.

None of my statements on how I or many others operate our systems are opinion. All are facts based on my experience in the telecom/IT industry, these forums, the IRC channel, and official training sessions. The “majority” I was speaking of relates to Fusionpbx users not the global population.

To be clear, while I have contributed small parts to the project, I am not one of the developers or have any direct relationship to the project. They are not “my classes” However, I have donated plenty of my time to help support the Fusionpbx community with factual information when possible and generally leave my opinions out of the conversations.

i mentioned the reasoning behind the security rules and assumptions the install script uses and you choose to argue your opinions and make false statements for no understandable reason.