Security problem with ftp server for provisioning allowing access to entire FreePBX server

Security and the FreePBX vsftpd provisioning server

I am upgrading to FreePBX from an older Elastix server where I had configured my Polycom phones to pull their provisioning from an ftp server on the Elastix box.

Because it is possible to see the ftp username and password from the Polycom phones, I had set up the login that the phones used so that the username would not be able to login and so that ftp user was chroot’ed to the directory with the provisioning info only (and thus could not snoop around the server).

In FreePBX, I enabled the ftp server in System Admin / Provisioning Protocols, and after I created a username and password, the /etc/vsftpd/vsftpd.conf file was created. However, when I use ftp to connect using my username and password, I am not chroot’ed, and I can roam around the entire file system using the ftp client.

That seems way too obvious to have been overlooked. Is that really the way the ftp server is configured on FreePBX?

Also, the vsftpd.conf that is created by FreePBX includes userlist_deny=no, which would seem to allow, rather than deny, the users in user_list (which includes, e.g. root, bin, and daemon), to log in using the ftp server. Is that what is intended? Wouldn’t we want to exclude the root user from logging in using ftp?

I can manually configure the ftp server to work the way I want (which I had done on the Elastix box), but I doubt that would match the way the Polycom portion of the Endpoint Manager is configured. However, if I set up that user to chroot into /tftpboot, it might work.

Am I missing something? Is there a better way to configure the ftp server?


Looking into this more, it looks like setting chroot_local_user=yes in /etc/vsftpd/vsftpd.conf does the chroot, and does not break the Endpoint Manager for at least Polycom provisioning.

Also, it looks like there is a /etc/vsftpd/ftpusers that is referenced in the PAM configuration at /etc/pam.d/vsftpd that prevents login from the users listed in ftpusers. In practice, I was not able to ftp into the box using the root login, which suggests that ftpusers is working.

The docs do mention some security risks with chroot_local_user, but I don’t think they apply, in that “virtual ftp users” are used, and they won’t have an ssh login.

Surely as you notice ftp is a nightmare and intrinsically insecure, move to https as soon as you can :wink:

Your polycoms will be absolutely fine with it.

Thanks, dicko.

I agree ftp isn’t great security, but it does allow me to set a username and password to access the config files, which http(s) does not appear to use for the Polycoms, and also allows me to have the phones upload their log files.

The Polycoms will upload their log files using an http PUT verb, but although the /tftpboot folder is exposed on http port 84 on the FreePBX box, it does not appear to accept the PUT, and I’m not sure how to configure it to. I am also concerned that, even if I did get the http PUT verb to work, that would provide an easy vector to modify the configuration files as well as the log files.

That is a highly inaccurate statement. Polycom’s support FTP, TFTP, HTTP and HTTPS for provisioning. So yes, using HTTPS will work just fine with Polycom’s.

Again, another incorrect statement. If the Polycom’s are set for TFTP, for example, as their provisioning method then they will upload their call logs/contacts via TFTP. It uses the same method as pulling the files. So if you use HTTPS, it will then use HTTPs to upload those files.

This is now a permissions/settings issues to allow the user to be able to upload files to the system. Something that you do in the configs and options of the method you are using. So as I used TFTP for the example, it would be the TFTP config you would update to allow writing to happening to the directory.

You really should read the Polycom manuals on provisioning because you are clearly unaware of how they do provisioning and handle their config files.

1 Like

Thanks, Tom, for your comments.

“which http(s) does not appear to use for the Polycoms” referred to using the username and password to restrict access to the FreePBX configuration files. In my testing, I did not see a way to get FreePBX to restrict access to the configuration files over http(s) the way it does for ftp. I believe that the Polycoms will send the username and password, but I don’t see where FreePBX is requiring them to access the configuration files.

“The Polycoms will upload their log files using an http PUT verb” refers only to http(s), as you are correct that they will upload their files using whatever method they are configured to use to pull their configuration. My point is that it is not clear what would be the best practices to configure FreePBX to accept the PUT, and still protect the configuration files from also being modified using a PUT.

This is all in the context of dicko’s suggestion of moving from ftp to https. I have been using Polycom provisioning with FTP with Elastix, where I had to do all of the FTP configuration manually, which actually works quite well.

Moving to FreePBX, I saw that FreePBX will set up the FTP server for me, but I found what I consider a serious security defect in that configuration, as it allows anyone with access to the FTP credentials access to the entire root filesystem.I certainly can set it up manually, as I have been doing with Elastix, but my question was about best practices for securing access while allowing pulling of configuration and pushing of log files. As noted above, I can manually enter the chroot_local_user, but I am concerned that FreePBX might remove it as part of its FTP server configuration process.

This is an option in System Admin Pro, Provisioning Protocols:

I’m prepared to be proven wrong, but I am pretty sure the Apache provisioning config done by System Admin, does not allow uploads via http(s).

I have little experience with Polycom, but I would not assume that all Polycom devices work identically without acknowledging that their current product line is significantly richer in features than the EOL legacy devices.

Correct and you were given an answer, HTTPS. If you want to do secure provisioning/config files for your phones you need to use HTTPS. Which then means you need to configure your HTTP server to deal with that properly. Like it was pointed out Sys Admin Pro lets you set all this and deal with it.

Thanks for the feedback, Tom and Lorne. The only piece still missing is the https upload issue, which I could probably live without.

Again, thanks everyone for your very helpful responses pointing me in the right direction.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.