![[APACHE DOCUMENTATION]](../images/sub.gif)
Sugerencias e informaciones genéricas y específicas de Apache referentes a materias de seguridad durante la instalación de un servidor web.
Apache se inicia por defecto en modo usuario "root" y cambia a usuario definido mediante el comando User para desempeñar acciones. Como con cualquier comando ejecutado por el usuario "root", es conveniente el asegurarse de la protección contra modificación por otros que no sean el propio usuario root. No apenas los propios archivos, sino también los directorios donde están y todos los directorios por encima de estos deberán estar protegidos contra modificaciones por otros usuarios diferentes de root. Por ejemplo, si se elige colocar el ServerRoot en /usr/local/apache lo recomendable es que sea creado por root con comandos así:
mkdir /usr/local/apache
cd /usr/local/apache
mkdir bin conf logs
chown 0 . bin conf logs
chgrp 0 . bin conf logs
chmod 755 . bin conf logs
cp httpd /usr/local/apache/bin
chown 0 /usr/local/apache/bin/httpd
chgrp 0 /usr/local/apache/bin/httpd
chmod 511 /usr/local/apache/bin/httpd
Puede crearse un subdirectorio denominado htdocs que sea modificable por otros usuarios, ya que root nunca ejecutará, ni deberá intentar crear archivos allí.
Si se permite que usuarios diferentes de root puedan modificar cualquier archivo que el propio root ejecuta o escribir en ellos, entonces el sistema se expone a quedar desprotegido. Por ejemplo, alguien podría remplazar el httpd binario para que la próxima vez que se inicie ejecute un código arbitrario. Si el directorio donde se guardan los ficheros log o de eventos es modificable por otros distintos a root, alguien podría remplazar un fichero log por un enlace simbólico a cualquier otro archivo de sistema, y entonces root podría sobrescribir ese fichero con datos arbitrarios. Si otros usuarios fuera de root pueden modificar ficheros log, se posibilita entonces la sobrescritura del propio log con datos falsos.
El SSI puede configurarse de manera que los usuarios puedan ejecutar programas arbitrarios en el servidor. Apenas pensar en esa posibilidad ya causaría escalofríos en la columna vertebral de cualquier administrador de sistemas.
Una solución es el deshabilitar esa parte del SSI. Para hacerlo, hay que utilizar la opción del IncludesNOEXEC en la orden Options.
El permitir ejecutar scripts de CGI en cualquier directorio debería considerarse solo sí:
La limitación del uso de CGIs a directorios especiales da al administrador control sobre lo que hay en ellos. Esto es inevitablemente más seguro que los scripts CGI en directorios no declarados con Script, pero solo en caso de que se tenga plena confianza en los usuarios con acceso de escritura a los directorios o bien que el administrador quiera probar cada script de CGI/o programa para detectar agujeros potenciales de seguridad. La mayoría de los sitios eligen esta opción sobre el enfoque de los CGIs no declarados con Script Alias.
Hay que recordar siempre que se debe tener confianza plena en los que escriben scripts de CGI o programas o bien que el administrador posea la habilidad de darse cuenta de agujeros potenciales de seguridad en CGIs da igual que sea de manera accidental o premeditada.
Todos los scripts de CGI funcionarán de mano como si fueran el mismo usuario, así tienen potencial para entrar en conflicto de manera accidental o deliberada con otros scripts. Por ejemplo: el usuario A odia al usuario B así que desarrolla un script para echar abajo la base de datos CGI del usuario B. Un programa que puede ser usado para permitir que los scripts funcionen como ejecutados por usuarios diferentes es suEXEC que se incluye con Apache desde la versión 1.2 y se ejecuta desde llamadas especiales en el código de servidor de Apache. Otra forma popular de hacer esto es con CGIWrap.
Para funcionar con un manejo realmente estricto será necesario no permitir
que los usuarios configuren archivos .htaccess los cuales pueden
anular los sistemas de seguridad configurados. Aquí se expone una forma de
hacerlo.....
En el archivo de configuración del servidor hay que poner:
<Directory />
AllowOverride None
Options None
Allow from all
</Directory>
Esto detiene todas las anulaciones, inclusiones y accesos en todos los directorios fuera de los que se nombran.
Un aspecto de Apache que ocasionalmente se mal interpreta es la característica del acceso implícito. Esto es, a menos que se tomen medidas para cambiarlo, si el servidor puede hallar un archivo a través de las reglas normales de URL, ese archivo podrá ser distribuído al cliente.
Por ejemplo, consideremos el caso siguiente:
Esto permitiría a los clientes el recorrer completamente el sistema de archivos. Para evitarlo, hay que añadir las instrucciones siguientes a la configuración del servidor:
<Directory />
Order Deny,Allow
Deny from all
</Directory>
Esto prohibirá el acceso implícito al sistema de archivos. Simplemente hay que añadir bloques de tipo <Directory> para dar acceso solamente a las áreas que se deseen. Por ejemplo:
<Directory /usr/users/*/public_html>
Order Deny,Allow
Allow from all
</Directory>
<Directory /usr/local/httpd>
Order Deny,Allow
Allow from all
</Directory>
Hay que prestar una atención principal a las interacciones entre las órdenes <Location> y <Directory>; por ejemplo, incluso si <Directory /> deniega el acceso a la directiva <Location />, la orden podría revocarse.
Hay que ser también cauteloso a la hora de utilizar la orden UserDir ya que estableciendo algo como "./" tendría el mismo efecto, para root, que el primer ejemplo de arriba. Si se usa Apache 1.3 o superior, se recomienda incluir la línea siguiente en los archivos de configuración del servidor:
Rogamos que por favor remitan cualquier otra información sobre seguridad al grupo Apache, rellenando un informe sobre el problema encontrado. Si cree que ha encontrado un fallo de seguridad en el código fuente de Apache, por favor háganoslo saber.
