ServerBuddies Support Blog

What is suEXEC?

The suEXEC feature — introduced in Apache 1.2 — provides Apache users the ability to run CGI and SSI programs under user IDs different from the user ID of the calling web-server. Normally, when a CGI or SSI program executes, it runs as the same user who is running the web server.

Presently, suEXEC does not allow ‘root’ to execute CGI/SSI programs.

Used properly, this feature can reduce considerably the security risks involved with allowing users to develop and run private CGI or SSI programs. However, if suEXEC is improperly configured, it can cause any number of problems and possibly create new holes in your computer’s security. If you aren’t familiar with managing setuid root programs and the security issues they present, we highly recommend that you not consider using suEXEC.

Permissions on Apache ServerRoot Directories

If you allow non-root users to modify any files that root either executes or writes on then you open your system to root compromises.

For example, someone could replace the httpd binary so that the next time you start it, it will execute some arbitrary code. If the logs directory is writeable (by a non-root user), someone could replace a log file with a symlink to some other system file, and then root might overwrite that file with arbitrary data. If the log files themselves are writeable (by a non-root user), then someone may be able to overwrite the log itself with bogus data.

If you choose to place ServerRoot in /usr/local/apache then it is suggested that you create that directory as root, with commands like these:

It is assumed that /, /usr, and /usr/local are only modifiable by root. When you install the httpd executable, you should ensure that it is similarly protected

Securing the Apache HTTP Server

The Apache HTTP Server is one of the most stable and secure services that ships with major Linux Server Distros.

Below is a few list of configuration options administrators should be careful using.

This directive is enabled by default, but may not be desirable. To prevent visitors from browsing files on the server, remove this directive.

This directive is enabled by default, be sure to use caution when creating symbolic links to the
document root of the Web server. For instance, it is a bad idea to provide a symbolic link to /.

The UserDir Directive

The UserDir directive is disabled by default because it can confirm the presence of a user account on the system. To enable user directory browsing on the server, use the following directives:

These directives activate user directory browsing for all user directories other than /root/. To add users to the list of disabled accounts, add a space delimited list of users on the UserDir disabled line.

Do Not Remove the IncludesNoExec Directive

Restrict Permissions for Executable Directories

Be certain to only assign write permissions to the root user for any directory containing scripts or CGIs. This can be accomplished by typing the following commands:

Webmin Proxied Through Apache

If you just want Webmin to be accessible via an URL subdirectory (like /webmin) on an Apache server without going to the trouble of configuring Apache to run the CGI scripts directly, there is a simpler method that can be used.

This is also useful if your system is only accessible on port 80, and you want access to both Webmin and a normal website. This is the recommended method of making Webmin run within an existing website hierarchy.

The steps to follow are:

Make sure mod_proxy is installed on your Apache webserver.

Add the following directives to the Apache configuration file:

Add the lines webprefix=/webmin and webprefixnoredir=1 to /etc/webmin/config.

In /etc/webmin/config, add the line referer=apachehost, where apachehost is the hostname eg; hostname after the http:// from the URL used to access Webmin via Apache.

If the referer line already has some hosts listed, add apachehost to it or you can disable referrer checking all together by just using referer=1

Edit /etc/webmin/miniserv.conf and disable ssl redirect ssl_redirect=0 and ssl=0

Re-start Apache and Webmin to apply the configuration.

All requests to /webmin on the Apache server will then be passed through to the Webmin server on localhost port 10000. All features should work fine, including themes, with the exception of IP access control (because as far as Webmin is concerned, all connections will be coming from localhost).

This method can also be used to make Webmin accessible via an Apache virtual host, like http://webmin.yourdomain.com/.

The steps to follow are :

Make sure mod_proxy is installed on your Apache webserver.

Add a virtual host to your Apache configuration file like:

In /etc/webmin/config, add the line referer=apachehost, where apachehost is the hostname from the URL used to access Webmin via Apache. If the referer line already has some hosts listed, add apachehost to it.

Re-start Apache to apply the configuration.

No changes need to be made to /etc/webmin/config, because no prefix is appended to the URL path.

Running Webmin Under Apache

Webmin includes a dedicated web server called miniserv.pl that is designed to run Webmin. It provides a number of additional security features, plus performance enhancements like configurable caching of Webmin libraries. Running Webmin under another web server is not recommended, but it is possible if necessary. There is no performance or security benefit to running Webmin under Apache (or any other web server).

To use Apache instead of miniserv.pl, follow these steps:

Create a new Apache virtual server with the document set to the directory where you installed Webmin, using a directive like DocumentRoot? /usr/local/webmin-1.330.

Configure Apache to treat all files with the .cgi extension as CGI programs, with the AddHandler? cgi-script .cgi directive.

Add index.cgi to the DirectoryIndex? directive.

Webmin CGI programs have their config directory passed to them in the WEBMIN_CONFIG, WEBMIN_VAR and MINISERV_CONFIG environment variables. For Apache to do this, you need to add the directives

Create a new section for the root directory, like

Add the directive Options ExecCGI? to the new section.

Password-protect the virtual server by putting directives like AuthName? Webmin AuthType? basic AuthUserFile? /etc/webmin/htusers require valid-user Inside the section. The file /etc/webmin/htusers must contains users who match up with those in /etc/webmin/webmin.acl.

Make all the Webmin programs owned by root and setuid with the commands

Add the -U flag to the perl line in all the Webmin scripts. This can be easily done with the following command run from the webmin-1.330 directory

This assumes that Perl is installed as /usr/bin/perl on your system.

Configure Webmin to use the ‘Default Webmin Theme’, as Apache cannot support Webmin’s theming system.

Make sure that the setuid scripts cannot be run by other users on your system, by setting the permissions on /usr/local/webmin-1.330 to 700 and changing its ownership to the user your webserver runs as. Otherwise any user would be able to execute any command as root by running some of the scripts.

You should now be able to start Apache and login to Webmin at whatever URL your Apache server is running on. Note that the Webmin Users and Webmin Configuration modules will not work, as they configure miniserv.pl and cannot deal with Apache.
Some versions of Perl refuse to run in setuid mode, and fail with an error like can’t do setuid. The solution is to install the special suidperl program and edit the Webmin CGI scripts to use it instead.

In Webmin versions 0.965 and above, it is possible to run Webmin under Apache in a subdirectory rather than at the top level of a virtual server. This means that Webmin could be accessed at a URL like http://www.yourdomain.com/webmin/ . The

steps to take to set this up are :

Create a new Alias that maps some URL path like /webmin to the directory where Webmin is installed, such as /usr/local/webmin-1.330.

In the directory section, configure Apache to treat all files with the .cgi extension as CGI programs, with the AddHandler? cgi-script .cgi directive.

Add the directives DirectoryIndex? index.cgi and Options ExecCGI? to the directory section.

Webmin CGI programs have their config directory passed to them in the WEBMIN_CONFIG, WEBMIN_VAR and MINISERV_CONFIG environment variables. For Apache to do this, you need to add the directives

Password-protect the virtual server by putting directives like AuthName? Webmin

Make all the Webmin programs owned by root and setuid with the commands

Add the -U flag to the perl line in all the Webmin scripts. This can be easily done with the following command run from the webmin-1.330 directory

Configure Webmin to use the ‘Default Webmin Theme’, as Apache cannot support Webmin’s theming system.

Make sure that the setuid scripts cannot be run by other users on your system, by setting the permissions on /usr/local/webmin-1.330 to 700 and changing its ownership to the user your webserver runs as. Otherwise any user would be able to execute any command as root by running some of the scripts.