content="text/html; charset=iso-8859-1"> Servidor HTTP Apache: Recomendaciones de Seguridad
[APACHE DOCUMENTATION]

Servidor HTTP Apache, versión 1.3

Información sobre Seguridad para la Configuración del Servidor


Sugerencias e informaciones genéricas y específicas de Apache referentes a materias de seguridad durante la instalación de un servidor web.


Permisos en los directorios ServerRoot

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
Se supone que /, /usr, y /usr/local solo pueden ser modificados por root. Al instalar el ejecutable httpd deberíamos asegurarnos que también está protegido:
    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.


Server Side Includes (SSI)

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.


CGIs no declarados con Script Alias

El permitir ejecutar scripts de CGI en cualquier directorio debería considerarse solo sí:

  1. Se tiene total confianza en que los usuarios no van a poner scripts que de manera accidental o deliberada pongan en riesgo de ataque al sistema.
  2. Se considera que la seguridad del sitio en general es tan débil en otras áreas que haga irrelevante el tener un agujero potencial más de cara a la seguridad.
  3. No tiene usuarios y nadie visita el servidor.


CGIs declarados con Script Alias

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.


CGIs en general

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.


Impedir que los usuarios alteren las características generales del sistema...

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>
Y después se configuran directorios específicos.

Esto detiene todas las anulaciones, inclusiones y accesos en todos los directorios fuera de los que se nombran.


Protección implícita de archivos del servidor

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:

  1. # cd /; ln -s / public_html
  2. Accediendo http://localhost/~root/

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:

UserDir disabled root

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.


Servidor HTTP Apache, versión 1.3

Index Home