Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Block access to 3rd party applications unless authenticated #56

Open
Caffe1neAdd1ct opened this issue Sep 23, 2014 · 15 comments
Open

Block access to 3rd party applications unless authenticated #56

Caffe1neAdd1ct opened this issue Sep 23, 2014 · 15 comments
Milestone

Comments

@Caffe1neAdd1ct
Copy link
Contributor

Third party applications reside in /etc/zpanel/panel/etc/apps/ and are publicly available.

Tighter security could be implemented to stop anyone using these applications unless they have authenticated with the sentora panel first.

  1. Find a way to check sentora authentication before allowing each request inside this folder.
  2. Implement restriction
  3. Move roundcube to a virtual host of it's own as this app shouldn't be under such restrictions.
  4. Webalizer can be restricted further to make sure the logged in username matches the url requested
@Caffe1neAdd1ct Caffe1neAdd1ct added this to the Backlog milestone Sep 23, 2014
@TGates71
Copy link
Member

roundcube and phpmyadmin vhosts would be good, (keep mine at https://mysql.domain.com and https://webmail.domain.com) the rest should be locked down.

@TheNigelist
Copy link

Could we not just implement 3 sub-domains on install??

Ask for the FQDN, webmail domain, & mysql domain in the installer?

I know it's more for the NOOBS to get their heads around but aren't we trying to phase them out anyway?

We could give them a docs link to look at first and acknowledge, and if they show up at the forums we just point them towards the docs link again.

@Mehdi-Bl
Copy link
Contributor

I think /etc/app should run a different Vhost/ different context to improve permissions.

Let's say cp.zpanel.com:8080 a .htaccess could set a redirection so we don't get any major issues in menu's!

We can also beside different port add a suddomaine for access under port 80.

M B

@dolfje
Copy link

dolfje commented Sep 25, 2014

We can also use .htaccess with auto_prepend_file. So all calls to files in the apps directory are first checked against login information.

/etc/zpanel/panel/etc/apps/.htaccess:
php_value auto_prepend_file "/etc/zpanel/panel/etc/apps/security.php"

With something like this:

/etc/zpanel/panel/etc/apps/security.php:
<?php

// For all 3rd-party applications, a good zpanel login should be necesarry.
// Therefor this file is include by .htaccess prepend functionality.
// So now we will check if the user is successfully logged in.

session_start();
if(!isset($_SESSION['zpuid'])) {
  echo "No Authentication";
  exit();
}
session_write_close();

(Didn't test is, so just theoretical)

@Caffe1neAdd1ct
Copy link
Contributor Author

I've thought about prepend file but wanted to avoid it if possible.

However that said it's a quick and easy fix!

I also feel phpmyadmin should definitely be restricted as it is used too many times before to collect information out of zpanel instances once attackers gained mysql root pass from the config files.

I'm not sure about separate vhosts as this would require more setting up on the user's behalf and not practical if hosting zpanel internally on a local server. However to get a similar setup we could add an openbase_dir restriction for each app along with the suhosin blacklist.

Something like:

<location /apps/phpmyadmin>
 openbase_dir = "/apps/phpmyadmin"
 blacklist = "shell_exec etc"

This way the apps can't do any file operations outside of their directories...

@Mehdi-Bl
Copy link
Contributor

Thus my prior post over isolating completly the apps in a separate vhost where we could jail them and reduce permissions.
Php my admin will not be an issue if we don't have mysql root under /cnf. Later we will manage to fix that too.

Phpmysysinfo should be moved off core and offered as third party module and we should keep only the essential apps in /etc/app as: webmail/phpmyadmin.

M B

@allebb
Copy link
Contributor

allebb commented Oct 18, 2014

I like the idea @MBlagui and @Caffe1neAdd1ct! - Isolate and jail the PHP functions that are not required! - You guys ok to start working on this?

@allebb allebb closed this as completed Oct 18, 2014
@allebb allebb reopened this Oct 18, 2014
@allebb
Copy link
Contributor

allebb commented Oct 18, 2014

Sorry, clicked the wrong button! - Re-opening issue :)

@Mehdi-Bl
Copy link
Contributor

Yep ok for 1.1 and will be happy to team up with @Caffe1neAdd1ct over this.

Isolating the /app is key to improve security and we could also improve how webmail can accessed offer ing webmail.* for all domains and same for phpmyadmin. Sysinfo should be repackaged and set as an official module but no more in core.

M B

@allebb
Copy link
Contributor

allebb commented Oct 19, 2014

Personally I feel that all third-party app packages (that sit under
/etc/apps/) should be offered as third-party add-ons only.In my opinion we
should not be responsible for the bug fixes/potential issues that could
arise from these packages.... These should be installed by the users and
kept up to date by our new zppy upgrade functions of which I'm revisiting
in the next couple of weeks!

On 19 October 2014 20:02, MBlagui [email protected] wrote:

Yep ok for 1.1 and will be happy to team up with @Caffe1neAdd1ct
https://github.com/Caffe1neAdd1ct over this.

Isolating the /app is key to improve security and we could also improve
how webmail can accessed offer ing webmail.* for all domains and same for
phpmyadmin. Sysinfo should be repackaged and set as an official module but
no more in core.

M B


Reply to this email directly or view it on GitHub
#56 (comment).

@Mehdi-Bl
Copy link
Contributor

Webmail & phpmyadmin are very important for core. Unless we offer one click install. But removing them off sentora panel execution context & jailing them with suhosin would be contain any security breach/ flaw in these modules. Later adding a specific user under suEXEC will achieve this containment logic.
I've been thinking about moving /etc/sentora/panel/etc/app to /etc/sentora/panel/app and creating a vhost for each module.
Update indeed will be an issue but I think we can find solution for updating quickly those modules ( I see solutions).
We should be able in the future to update core modules one by one too.

It will leave only pchart as the remaining third party in the panel. Notice we already jailed it with .htacces banning execution.

Zsudo will follow too as discussed in the forum and I think we have a good solution for backward compatiblity and avoid any bypass.

@allebb
Copy link
Contributor

allebb commented Oct 19, 2014

Webmail and phpMyAdmin may seem important for core but realistically I
think that given they are third-party and just 'management' tools they
should be made into third-party modules and installed as and when required
by the users... maybe the installer at the end could ask say 'Would you
like to download and install the latest phpMyAdmin and RoundCube clients
now?' - There is a miriad of other web-based MySQL database managers and
webmail clients that we could also provide.

Can you link the Zsudo discussion for me please?

On 19 October 2014 20:19, MBlagui [email protected] wrote:

Webmail & phpmyadmin are very important for core. Unless we offer one
click install. But removing them off sentora panel execution context &
jailing them with suhosin would be contain any security breach/ flaw in
these modules. Later adding a specific user under suEXEC will achieve this
containment logic.
I've been thinking about moving /etc/sentora/panel/etc/app to
/etc/sentora/panel/app and creating a vhost for each module.
Update indeed will be an issue but I think we can find solution for
updating quickly those modules ( I see solutions).
We should be able in the future to update core modules one by one too.

It will leave only pchart as the remaining third party in the panel.
Notice we already jailed it with .htacces banning execution.

Zsudo will follow too as discussed in the forum and I think we have a good
solution for backward compatiblity and avoid any bypass.


Reply to this email directly or view it on GitHub
#56 (comment).

@Mehdi-Bl
Copy link
Contributor

tagged you in the forum check your PM inbox

@Caffe1neAdd1ct Caffe1neAdd1ct modified the milestones: 1.0.4, Backlog Sep 28, 2015
blondie101010 pushed a commit to blondie101010/sentora-ng that referenced this issue Jul 13, 2018
@Dukecitysolutions
Copy link
Contributor

Looking into this. Roundcube should be ok for now. Mysql needs this auth lockdown.

@TGates71
Copy link
Member

I access phpMyAdmin very frequently without being logged into my panel since I do a lot of web design. Logging into the panel to work with databases is not a suitable solution. Lock them down with snuffleupagus/suhosin and maybe a custom vhost entry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants