HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials - Hardening the system without breaking ISPConfig

HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials (http://www.howtoforge.com/forums/index.php)

- Installation/Configuration (http://www.howtoforge.com/forums/forumdisplay.php?f=16)

- - Hardening the system without breaking ISPConfig (http://www.howtoforge.com/forums/showthread.php?t=4375)

Hardening the system without breaking ISPConfig

First of all, I'll list what I want to do and proceed with the issues I've encountered.

Needs:
- Prevent users from reading eachothers directories and subdirectories. <- Is this solvable without implementing ssh chroot?
- Diskquotas reportable by "quota"

Tests:
chmod 711 /var/www/web* <- will prevent people from listing the initial subdirectories however it will not prevent people to pry into subdirectories with lax chmod like 755 etc.
chmod 700 /var/www/web* <- will do some extra work but will prevent apache from displaying the sites.

Setting either of these chmod's will break ispconfig's ability to see disk statistics for the users. Even if the sudo option for du is activated in ispconfig's configuration-file.

Also if quota is activated on the system it doesnt seem to use diskquotas for the users? how so?

Quote:

Originally Posted by Norman

Setting either of these chmod's will break ispconfig's ability to see disk statistics for the users. Even if the sudo option for du is activated in ispconfig's configuration-file.

If you configured du to be executed with root priveliges via sudo, the statistics are correct. You can test if your configuration is correct by running:

su admispconfig
sudo du -h --max-depth=1 /home/www/web1

Quote:

Also if quota is activated on the system it doesnt seem to use diskquotas for the users? how so?

Have you enabled quotas for all partitions where userdata is stored?

Hardening ISPConfig

Hi Till and Falko,

We're very happy with ISPConfig, and would like to thank you guys for making it available to us! At this point, we are keen to "harden" our servers running ISPConfig and would like to do, as Norman suggests, a chmod 750 on /home/www/* to prevent other clients (and their users) from accessing any other client directory...

As Norman points out, however, this breaks access for Apache (running as user www-data on our Ubuntu system). We notice that any new web?? group automatically includes the admispconfig user - how could we also automatically include the user www-data? We've grepped the ISPConfig code looking for hints, but haven't found the right place... Any suggestions would be greatly appreciated.

Kind regards,

Dave

The admispconfig user is added to the group of the web in line 1101 in the file /root/ispconfig/scripts/config.lib.php

anyone tried using bastille for hardening?

Bastille hardening

Hi Tenaka,

Yesterday we installed Bastille on our Ubuntu server (via APT) in addition to the Bastille firewall provided by ISPConfig. We configured it for everything but the firewall - but as yet, we haven't applied stricter permissions (via the umask) on the user directories yet as doing so would block the webserver from serving up user web accounts... Fixing that requires a minor hack on ISPConfig to ensure that the Apache user (in our case www-data) is included in each customer group. We're working on that.
Cheers,

Dave

Right - applied a minor hack to ISPConfig (version 2.2.2) see below for diff - to add the Webserver user (in our case on Ubuntu Dapper Linux it's "www-data") to each web?? customer's default group, and also to create new users in our web directory (in our case /home/www) with permissions 750 rather than the default 755 (which allows users of any customer to look into any other customer's web directories and read email, database passwords, etc. - NOT GOOD).

To apply this fix retroactively, go into your web root directory and run the following (note - DON'T use the -R flag, as that will screw things up big time) - assuming you're using web? or web?? to designate your web customers:

Code:

chmod 750 web?? web?

Following this, restart apache - on Ubuntu Dapper, it's

Code:

/etc/init.d/apache2 restart

otherwise you might find that some sites fail to display (not sure why this happens, but a restart seems to fix it) with "permission denied" errors in the logs and "could not access .htaccess" or similar.

At this stage, I'm not aware of any problems with this solution - seems to work well - but it might have implications on quota management or other ISPConfig maintenance task - not sure.

Here's the diff for /root/ispconfig/scripts/lib/config.lib.php that makes it all happen.

Code:

Index: config.lib.php

===================================================================

--- config.lib.php      (revision 2844)

+++ config.lib.php      (working copy)

@@ -1087,14 +1087,33 @@

   $mod->system->add_user_to_group("web".$doc_id);

   //////////////////// admispconfig der Gruppe hinzuf�gen ENDE //////////////



+  // modified by dave@xxxxxx.com 20060919 to ensure that the web user can read into //

+  // all web client directories, but web clients can't read other web client's directories

+  // Adding Apache2 "www-data" user to each web group by default.

   $apache_user = $this->apache_user;

+  $mod->system->add_user_to_group("web".$doc_id,$apache_user);

+  // end dave@xxxxxx.com 20060919 modification //

+

+

+  $apache_user = $this->apache_user;

   if($update == 0 || $dir_new){

     exec("chown -R $apache_user:web$doc_id $web_path_realname &> /dev/null");

     exec("chown -R $apache_user:web$doc_id $web_path &> /dev/null");

     exec("chmod -R 775 $web_path");

     exec("chmod -R 775 $web_path_realname");

-    exec("chmod 755 $web_path");

-    exec("chmod 755 $web_path_realname");

+    // modified by dave@xxxxxx.com 20060919 to set up permissions: drwxr-x--- //

+    // to keep users from accessing the directories of other web?? customers.

+    // This does not lock out other users of the same web?? customer (who, by default,

+    // belong to the web?? group.

+    // users associated with the //

+    // exec("chmod 755 $web_path");

+    // exec("chmod 755 $web_path_realname");

+    exec("chmod 750 $web_path");

+    // note: not sure why we do this, as the "realname" appears to be a simple symbolic link to the

+    // "web_path" directory, and in Linux filesystems, links simply inherit the permissions of the

+    // thing they're linked to (at least on our system with ext3 filesystems)...

+    exec("chmod 750 $web_path_realname");

+    // end dave@xxxxxx.com 20060919 modification //

     exec("chmod 755 $web_path/user"); // user-Verzeichnis sollte nicht group-writable sein, weil Sendmail sonst warnings ausgeben k�nnte wg. der .forward-Datei

     exec("chmod 755 $web_path/log");

     exec("chmod 755 $web_path/ssl");

Hope that's helpful to someone. Falko, Till, is there any reason that ISPConfig isn't already configured like this? Perhaps my solution is too simplistic? I would've thought that the default 755 permissions would be very loose for a production virtual hosting environment, no?

Kind regards,

Dave

Quote:

Falko, Till, is there any reason that ISPConfig isn't already configured like this? Perhaps my solution is too simplistic? I would've thought that the default 755 permissions would be very loose for a production virtual hosting environment, no?

There was a reason in some older ISPConfig versions, at thi time the WebFTP was file based and not FTP based. But in the current versions I see no reasons why this wont work except of the problem with backwards compatibility.

thanks for this Dave.

One thing that might be of interest is that at least here /home/admispconfig is (was) world readable.

Quote:

One thing that might be of interest is that at least here /home/admispconfig is (was) world readable.

There is nothing hidden in this directory that you can not see if you download the ISPConfig sources from sourceforge or svn. There is just one file that contains the login information for the database and this can be only read by the admispconfig user.