Re: [suse-security] Location of the Apache document root (was: Apache Source Tree under 6.1)
I'd place the apache manual to /usr/doc/packages/appache/manual/ and set a symlink from /usr/local/httpd/htdocs/manual -> /usr/doc/packages/appache/manual to allow the example page to refer to the manual. Thus after installing one might decide to leave or to delete this link in order to have or to have not the apache manual on the server.
This is definitely a reasonable idea. I will change this in the next major release of SuSE Linux. However I prefer an Alias to a symlink.
By default, apache will not follow symlinks, at least not to outside the main document root. This is at least the default Red Hat 6.0 setup, and should be the default setup for any good distribution. The alias therefore seems a much better idea. Or does that have to be in the main document root too?
While we're on the security list, cgi-bin is non-empty. I remember that by some default on some distribution it contained a file with serious security problems?!?
The programs in our cgi-bin should all be harmless. However I will change the permissions in secure and paranoid settings to 000.
As was pointed out before, the program is testcgi. However, I now
backtracked the Bugtraq list, and the script I was referring to is
cachmgr.cgi.
-----from bugtraq:
cachemgr.cgi is the manager interface to Squid web proxy/cache server.
As all manager interface tools access to it SHOULD have restricted
access by default, not open for public access.
If you are not using the box as a Squid www proxy/cache server then
uninstall the package by executing "/etc/rc.d/init.d/squid stop ; rpm -e
squid".
If you are indeed using the Squid proxy server software, then make the
following actions to at least minimally secure access the manager
interface:
mkdir /home/httpd/protected-cgi-bin
mv /home/httpd/cgi-bin/cachemgr.cgi /home/httpd/protected-cgi-bin/
and add the following directives to /etc/httpd/conf/access.conf and
srm.conf
--- start access.conf segment ---
# Protected cgi-bin directory for programs that
# should not have public access
In article <199909202126.JAA14275@andromeda.elec.canterbury.ac.nz>,
Volker Kuhlmann
This is definitely a reasonable idea. I will change this in the next major release of SuSE Linux. However I prefer an Alias to a symlink.
By default, apache will not follow symlinks, at least not to outside the main document root. This is at least the default Red Hat 6.0 setup, and should be the default setup for any good distribution.
Well, if i'm not badly wrong with my files, SuSE 6.2 default configuration does allow to follow symlinks. /etc/httpd/httpd.conf: | # First, we configure the "default" to be a very restrictive set of | # permissions. | # | <Directory /> | Options FollowSymLinks | AllowOverride None | </Directory>
The alias therefore seems a much better idea. Or does that have to be in the main document root too?
Nope. You can set an alias to point to wherever you want. To quote /etc/httpd/httpd.conf again as example: | Alias /icons/ "/usr/local/httpd/icons/" | | [...] | | Alias /hilfe/ /usr/doc/susehilf/ | Alias /doc/ /usr/doc/ | Alias /cgi-bin-sdb/ /usr/local/httpd/cgi-bin/ | Alias /sdb/ /usr/doc/sdb/ (BTW, i'd remove the alias for /doc/. There is a lot of stuff in /usr/doc and only quite a few of it is suitable to be offered from the local http server.) To the alias versus symlink discussion: I think they are pros and contras for both of them. Symlinks are more flexible (no need to change the httpd-configuration to change them). But i think the main advantage is that they are more obvious: You can see in the directory that they are there. (I still remember how long i once tried to figure out why the links on my server were broken after an upgrade to a new SuSE version, when they added the "/doc/" aliases quoted above. I had a "doc" directory in my document root ...) I think this is also a security concern. I'd like to know how many people with a standard SuSE configuration actually *know* that they are offering their whole /usr/doc tree to their clients. The main disadvantage of setting a symlink that i can see is that you have to allow to follow symlinks in your configuration.
The programs in our cgi-bin should all be harmless. However I will change the permissions in secure and paranoid settings to 000.
I'd place no example scripts at all in the cgi-bin. I'd place them in
the apache documentation under /usr/doc/packages/apache so that anyone
willing to experiment with them may chose to copy them manually to the
cgi-bin.
In the ideal case, the cgi-bin should left empty in order to separate
locally installed scripts from those that comes with the distribution.
--
Rolf Krahl
participants (2)
-
rolf.krahl＠gmx.net -
Volker Kuhlmann