El Servidor Apache HTTP tiene un buen historial de seguridad y comunidad de desarrolladores con una alta preocupación por los problemas de seguridad. Pero será inevitable que algunos problemas -- pequeños o grandes -- sean descubiertos en el software después de que éste ha sido publicado. Por esta razón, es crucial estar al tanto de las actualizaciones de software. Si ha obtenido su versión del Servidor HTTP directamente de Apache, le recomendamos encarecidamente que se suscriba a la Lista de Anuncios del Servidor Apache HTTP donde puede estar informado de nuevas versiones y actualizaciones de seguridad. Hay servicios similares disponibles desde la mayoría de distribuidores de terceros del Software Apache.

Desde luego, la mayor parte de las veces que el servidor web se ve comprometido, no es por problemas en el código del Servidor HTTP. Si no, más bien ocurre por problemas en código externo, scripts CGI, o el sistema operativo sobre el que se opera. Debe entonces estar al tanto de los problemas y actualizaciones de todo el software en su sistema.

Todos los servicios de red pueden ser objeto de ataques de denegación de servicio que intentan evitar que haya respuestas a clientes mediante la limitación o bloqueo de recursos en el servidor. No es posible prevenir tales ataques completamente, pero puede hacer ciertas cosas para mitigar los problemas que generan.

A menudo la herramienta más efectiva anti-DoS será un cortafuegos u otras configuraciones del sistema operativo. Por ejemplo, la mayoría de los cortafuegos pueden configurarse para restringir el número de conexiones simultáneas de una misma dirección IP o red, y de esta manera prevenir un rango de ataques sencillos. Pero desde luego esto no es de ayuda contra un Ataque Distribuido de Denegación de Servicio (DDoS).

Hay ciertas configuraciones del servidor Apache HTTP que pueden ayudar a mitigar problemas:

• La directiva RequestReadTimeout permite limitar el tiempo que un cliente tarda en enviar una petición.
• El valor de la directiva TimeOut debería reducirse en sitios que son objeto de ataques DoS. Configurar ésta a unos segundos podría ser apropiado. Como TimeOut se usa en realidad para distintas operaciones diferentes, configurar ésta a un valor muy bajo puede introducir problemas a largo plazo en scripts CGI que se ejecuten durante más de la cuenta.
• La directiva KeepAliveTimeout también puede reducirse en sitios que son objeto de ataques DoS. Algunos sitios incluso desactivan los keepalives completamente con KeepAlive, lo cual por supuesto genera otros inconvenientes en el rendimiento.
• Deberían comprobarse también los valores de las directivas de timeout facilitadas por otros módulos.
• Las directivas LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine, y LimitXMLRequestBody deberían configurarse cuidadosamente para limitar el consumo de recursos desencadenado por las entradas del cliente.
• En sistemas operativos que lo soporten, asegúrese de que usa la directiva AcceptFilter para descargar parte del procesamiento de la petición al sistema operativo. Está activa por defecto en Apache httpd, pero puede que sea necesaria configuración en su kernel.
• Ajuste la directiva MaxRequestWorkers para permitir al servidor gestionar el máximo número de conexiones simultáneas sin quedarse sin recursos. También vea la documentación de ajuste de rendimiento.
• Usar un mpm multihilo puede permitirle gestionar más conexiones simultáneas, mitigando así ataques DoS. Incluso el mpm event usa procesamiento asíncrono para evitar dedicar un hilo a cada conexión.

Generalmente, Apache se arranca con el usuario root, y éste cambia a un usuario definido con la directiva User para servir peticiones. Como es el caso con cualquier comando que ejecuta root, debe tener cuidado de que esté protegido de modificación por usuarios que no sean root. No solo los ficheros deben poder escribirse solo por root, pasa lo mismo con los directorios, y todos los directorios precedentes. Por ejemplo, si escoge colocar ServerRoot en /usr/local/apache entonces se sugiere que genere ese directorio como root, con comandos como estos:

Se asume que /, /usr, y /usr/local son solo modificables por root. Cuando instala el ejecutable httpd, debe asegurarse de que está protegido de manera similar:

Puede generar un subdirectorio htdocs que sea modificable por otros usuarios -- puesto que root nunca ejecuta ficheros en ese directorio y no debería estar generando ficheros ahí.

Si permite a usuarios no-root modificar cualquier fichero que root ejecute o escriba, entonces está permitiendo que root sea comprometido. Por ejemplo, alquien podría reemplazar el binario httpd de manera que la próxima vez que lo arrancara, ejecutaría un código arbitrario. Si el directorio de logs es modificable (por un usuario no-root), alguien podría reemplazar un fichero de log con un enlace simbólico a otro fichero de sistema, y entonces root podría sobreescribir ese fichero con datos arbitrarios. Si los ficheros de log son modificables (por un usuario no-root), entonces alguien podría sobreescribir el fichero de log con datos inservibles.

Los Server Side Includes (SSI) enfrentan a un administrador de servidores con varios riesgos de seguridad potenciales.

El primer riesgo es el incremento de carga en el servidor. Todos los ficheros activados para SSI son escrutados por Apache, tengan o no tengan directivas SSI incluidas dentro del fichero. Aunque esta carga es menor, en un entorno de servidor compartido puede ser significativa.

Los ficheros SSI también conllevan los mismos riesgos asociados con los scripts CGI en general. Usando el elemento exec cmd, los ficheros activados para SSI pueden ejecutar cualquier script CGI o programa bajo los permisos del usuario y grupo con los que se ejecuta Apache, tal y como está configurado en httpd.conf.

Hay formas de mejorar la seguridad de los ficheros SSI mientras se obtienen los beneficios que proveen.

Para aislar el daño que un fichero SSI caprichoso puede causar, un administrador de servidor puede habilitar suexec como se describe en la sección CGI en General.

Activar SSI para ficheros con extensiones .html o .htm puede ser peligroso. Esto puede darse especialmente en un entorno de servidor compartido y que tenga bastante carga. Los ficheros habilitados para SSI deberían tener una extensión diferente, como la típica .shtml. Esto ayuda a mantener la carga de servidor al mínimo y permite una gestión más sencilla del riesgo.

Otra solución es deshabilitar la capacidad de ejecutar scripts y programas desde páginas SSI. Para hacer esto sustituya Includes con IncludesNOEXEC en la directiva Options. Tenga en cuenta que los usuarios podrían todavía usar <--#include virtual="..." --> para ejecutar scripts CGI si estos scripts están en directorios designados por la directiva ScriptAlias.

Primero, siempre tiene que recordar que debe confiar en los desarrolladores de scripts/programas CGI o su habilidad para localizar agujeros potenciales de seguridad en CGI, sean deliberados o accidentales. Los scripts CGI pueden ejecutar comandos de manera arbitraria en su sistema con los permisos del usuario del servidor web y pueden por tanto ser extremadamente peligrosos si no se revisan cuidadosamente.

Todos los scripts CGI se ejecutarán con el mismo usuario, así que tienen potencial para el conflicto (accidental o deliberado) con otros scripts p. ej. Usuario A odia a Usuario B, así que escribe un script para borrar la base de datos CGI del usuario B. Un programa que puede usarse para permitir que scripts se ejecuten como distintos usuarios es suEXEC que está incluido con Apache desde la versión 1.2 y es llamado desde hooks especiales en el código del servidor Apache. Otra forma popular de hacer esto es con CGIWrap.

Permitir a usuarios ejecutar scripts CGI en cualquier directorio solo debería considerarse si:

• Confía en que los usuarios no escribirán scripts que deliberada o accidentalmente expondrán su sistema a un ataque.
• Considera que la seguridad de su sitio es tan débil en otras áreas, que tener un agujero potencial de seguridad sea irrelevante.
• No tiene usuarios, y nadie visita su servidor nunca.

Limitar CGI a directorios especiales le da al administrador control sobre lo que ocurre en esos directorios. Esto es indudablemente más seguro que CGI sin Alias de Script, pero solo si los usuarios con acceso de escritura a esos directorios son de fiar o el administrador comprueba cada programa/script por si tiene agujeros de seguridad potenciales.

La mayor parte de los sitios eligen esta opción en lugar del método CGI sin Alias de Script.

Opciones de script embebido que se ejecutan como parte del mismo servidor, tales como mod_php, mod_perl, mod_tcl, y mod_python, se ejecutan con la misma identidad que el servidor (vea la directiva User), y por tanto scripts que se ejecuten por estos motores pueden potencialmente acceder a cualquier cosa que el servidor pueda. Algunos motores de scripting pueden proveer restricciones, pero es mejor asumir que no lo hacen.

Cuando se configura contenido dinámico, como por ejemplo mod_php, mod_perl o mod_python, muchas consideraciones de seguridad escapan al ámbito del mismo httpd, y necesita consultar la documnetación de estos módulos. Por ejemplo, PHP le permite configurar un Modo Seguro, que generalmente está deshabilitado por defecto. Otro ejemplo es Suhosin, un addon PHP para más seguridad. Para más información sobre estos, consulte la documnetación de cada projecto.

A nivel de Apache, un módulo que se llama mod_security puede ser considerado como un firewall HTTP y, asumiento que lo configura correctamente, puede ayudarle a mejorar la seguridad de su contenido dinámico.

Para tener un sistema muy seguro, querrá impedir que los usuarios configuren ficheros .htaccess que pueden invalidar características de seguridad que usted haya configurado. Esta es una manera de hacerlo.

En el fichero de configuración del servidor, ponga

Esto previene el uso de ficheros .htaccess en todos los directorios aparte de aquellos habilitados específicamente.

Tenga en cuenta que este es el valor por defecto desde Apache HTTPD 2.3.9.

Un aspecto de Apache que ocasionalmente se malinterpreta es el acceso por defecto. Esto es, a menos que tome medidas para cambiarlo, el servidor puede encontrar su camino hacia un fichero a través reglas de mapeo de URL, que puede servir a los clientes.

Considere el siguiente ejemplo:

Esto permitiría clientes navegar por el sistema de ficheros al completo. Para corregir esto, añada el siguiente bloque a la configuración del servidor:

Esto prohibirá el acceso por defecto a ubicaciones del sistema de ficheros. Añada después bloques apropiados de Directory para aquellas áreas a las que quiera dar acceso. Por ejemplo,

Preste atención a las interacciones de las directivas Location y Directory; por ejemplo, incluso si <Directory "/"> deniega el acceso, una directiva <Location "/"> puede anularlo. (Aunque tenga en cuenta que Location representa paths virtuales relativos a partir del especificado en DocumentRoot)

También tenga cuidado jugando con la directiva UserDir; configurarla a algo como ./ tendría el mismo efecto, para root, como el primer ejemplo indicado previamente. Le recomendamos encarecidamente que incluya la siguiente línea en sus ficheros de configuración del servidor:

Para estar al día en lo que está a su servidor debe examinar los Ficheros de Log. Incluso aunque los ficheros de log solo reporten lo que ya ha pasado, le facilitarán entender qué ataques se han enviado a su servidor y comprobar si tiene configurado el nivel necesario de seguridad.

Un par de ejemplos:

El primer ejemplo le enseñará una lista de ataques intentando explotar la Vulnerabilidad de Revelado de Información de Apache Tomcat con Peticiones Malformadas Source.JSP, el segundo ejemplo listará los últimos 10 clientes a los que se les ha denegado el acceso, por ejemplo:

Como puede ver, los ficheros de log solo muestran lo que ya ha pasado, así que si el cliente ha podido acceder al fichero .htpasswd vería algo similar a:

en su Log de Acceso. Esto significa que usted probablemente deshabilitó lo siguiente en su fichero de configuración:

La fusión de secciones de configuración es complicada y a veces específica de ciertas directivas. Compruebe siempre sus cambios cuando genere dependencias en directivas que se fusionan.

Para módulos que no implementan la lógica de fusión, tales como mod_access_compat, el comportamiento en las secciones posteriores dependen de si estas tienen alguna directiva del módulo. La configuración se hereda hasta que se realiza algún cambio, y en ese punto la configuración se reemplaza no se fusiona.