Hardening — Asegurando Apache

Como comentamos en nuestro artículo anterior: Hardening — Asegurando NGINX, para poder realizar un buen hardening en un sistema debemos contemplar tres principios básicos:

  • Mínimo Punto de Exposición (MPE)
  • Mínimo Privilegio Posible (MPP)
  • Defensa en Profundidad (DP)

Ahora toca el turno de realizar algunas configuraciones que nos ayuden a garantizar estos principios básicos en nuestros servidores web Apache.

Deshabilitar headers del servidor

Las cabeceras HTTP pueden contener información muy útil para un atacante. Cuando se realiza una petición hacia un servidor web, éste en las distintas respuestas HTTP que ofrece, incluye la cabecera Server que generalmente contiene información sobre el software que ejecuta el servidor web.

Muchas instalaciones de Apache muestran el número de versión del servidor, el sistema operativo y un informe de módulos de Apache instalados; información que los usuarios maliciosos pueden usar para atacar tu servidor.

Hay dos directivas que necesitas cambiar en el archivo de configuración /etc/httpd/conf/httpd.conf

ServerSignature Off
ServerTokens Prod

El ServerSignature aparece en la parte inferior de las páginas generadas por Apache, por ejemplo al mostrar el error 404 (documento no encontrado).

La directiva ServerTokens sirve para determinar lo que pondrá Apache en la cabecera de la respuesta HTTP del servidor.

Deshabilitar los módulos que no se utilizan

El deshabilitar los módulos que no se vayan a utilizar, va a ofrecer dos ventajas principales. Por un lado, no solo se evitarán ataques sobre estos módulos (a mayor número de módulos, mayor número de posibilidades de ataque); y por otro, también consumirá menos recursos.

Otra ventaja más de desactivar los módulos, es que se verá reducida la necesidad de emplear más recursos para su administración y control.

Estos son algunos de los módulos que se instalan por defecto, pero que suelen ser innecesarios: mod_imap, mod_include, mod_info, mod_userdir, mod_status, mod_autoindex.

Apache cuenta con varios módulos. Si queremos ver cuáles módulos está corriendo nuestro servidor, podemos ejecutar el siguiente comando como root:

httpd -M

Aquí veremos un listado con todos los módulos que Apache carga. Analice la lista y confirme cuales utiliza su servidor, los que no, simplemente comente la línea en el archivo de configuración:

Debian/Ubuntu

Debian/Ubuntu vienen con dos scripts:

  • a2enmod es un script que habilita el módulo especificado dentro de la configuración de apache2. Lo hace creando enlaces simbólicos dentro de /etc/apache2/mods-enabled/.
  • a2dismod deshabilita un módulo eliminando esos enlaces simbólicos. No es un error habilitar un módulo que ya está habilitado, o desactivar uno que ya está deshabilitado.

Para deshabilitar se usa a2dismod {module-name}

Por ejemplo, para deshabilitar un módulo llamado foo o mime_magic, escriba:

a2dismod foo
a2dismod mime_magic

Si necesita volver a habilitar módulos deshabilitados, utilice el comando a2enmod de la siguiente manera:

Sintaxis: a2enmod {nombre-módulo}

Por ejemplo, para activar el módulo imagemap, introduzca:

a2enmod imagemap

Para listar los módulos disponibles:

a2enmod

RedHat/CentOS

En las distribuciones Linux basadas en Redhat, además de cargar los módulos en el archivo /etc/httpd/conf/httpd.conf, a veces es necesario modificar los archivos .conf almacenados en el directorio /etc/httpd/conf.d/.

Apache busca archivos con el sufijo .conf al iniciar.

Así que si el sistema no necesita usar mod_python, asegúrese de que no se carga el módulo en el archivo de configuración principal /etc/httpd/conf/httpd.conf, y que no se cargue en archivos dentro de /etc/httpd/conf.d/, por ejemplo renombrando ‘python.conf’ a ‘python.conf.disabled’; luego reiniciamos el servicio.

cd /etc/httpd/conf.d/
mv perl.conf perl.conf.disabled
apachectl configtest
apachectl restart

Para volver a habilitar módulos, basta renombrarlos con sus nombres originales y reiniciar Apache para recuperar la funcionalidad del módulo.

Permisos sobre los archivos de Apache

Durante la instalación se creará un usuario y grupo exclusivo para la ejecución de Apache. Este usuario y grupo se configura con las directivas User y Group. En cuanto a los permisos de ficheros, el owner (propietario) del binario de Apache debe ser root para poder abrir el puerto 80 y leer las claves privadas de los certificados; después cambia el usuario del proceso al propio de Apache. El resto de usuarios no debe tener permisos de escritura sobre este fichero ya que entonces podría sustituirlo por otro malicioso que se ejecutaría con los máximos privilegios. Por ello se sugieren los siguientes permisos en los binarios de Apache, aunque normalmente vengan así por defecto:

# chown -R root:root /usr/local/apache
# find /usr/lib/apache2/ -type d | xargs chmod 755
# find /usr/lib/apache2/ -type f | xargs chmod 644

Por otro lado, en muchas instalaciones por defecto otros usuarios tienen permisos de lectura sobre los archivos de configuración y de logs de Apache. Es recomendable eliminar estos permisos con los siguientes comandos:

# chmod -R go-r /etc/apache2
# chmod -R go-r /var/log/apache2

Usuario y grupos de ejecución

Un aspecto que debe tener en cuenta en la ejecución de servicios, pasa por controlar qué usuario lo ejecuta. La idea consiste en que un servicio sea ejecutado por un usuario dedicado a él, con los mínimos privilegios posibles, de modo que ante un fallo en la aplicación el impacto sea menor.

Algunas versiones de Apache, al igual que muchos otros programas, se ejecutan con el usuario nobody; esto compromete mucho su seguridad al compartir la misma cuenta de usuario, así que conviene usar:

User apache
Group apache

O en el caso de Debian/Ubuntu

User www-data
Group www-data

Denegar el acceso por defecto a los archivos publicados

Uno de los problemas más frecuentes en instalaciones de Apache, es que no se aplican las directivas adecuadas para controlar los archivos que se ubican en el directorio en el que se publican las páginas web. Este directorio está especificado mediante la directiva DocumentRoot. Si no se configura adecuadamente la directiva, es posible que existan errores de configuración que puedan posibilitar el acceso a otros directorios o subdirectorios.

<Directory />
Order Deny, Allow
Deny from all
Options None
AllowOverride None
</Directory>
<Directory /var/www/htdocs>
Order Allow,Deny
Allow from all
</Directory>

Las directivas Allow y Deny son utilizadas para permitir o denegar respectivamente el acceso a un directorio y Order especifica el orden en el que serán evaluadas.

La directiva <Directory> sirve para aplicar una serie de directivas sobre la carpeta especificada y a todas sus subcarpetas. Lo más común es que existan varias de estas directivas y que, como también se aplican a los subdirectorios, existan directivas contradictorias aplicadas a un directorio. En este caso, la directiva del <Directory> más específico es la que prevalece.

En el ejemplo anterior, existen directivas de acceso contradictorias en el directorio /var/www/htdocs, pero se imponen las que permiten el acceso por estar contenidas en un <Directory> más específico.

Evitar la resolución de enlaces simbólicos

En sistemas Unix/Linux, Apache puede recibir una petición a un archivo que es, a nivel de sistema operativo del servidor, un enlace simbólico y devolver el archivo apuntado por él aunque se encuentre fuera del DocumentRoot.

Esta funcionalidad puede posibilitar que un atacante que tenga permisos de escritura sobre el DocumentRoot, cree un enlace simbólico a archivos contenidos fuera del DocumentRoot para luego acceder a ellos a través del navegador.

Para deshabilitar esta posibilidad se debe aplicar la siguiente directiva:

Options -FollowSymLinks

Como alternativa, se puede habilitar esta funcionalidad pero sólo si el archivo destino pertenece al mismo usuario que el enlace simbólico:

Options -FollowSymLinks +SymLinksIfOwnerMatch

Deshabilitar el listado de archivos

Si se le envía a Apache una URL que solicita un directorio y no un archivo concreto, Apache permite mostrar los contenidos de este directorio. Esta funcionalidad puede ser aprovechada por un atacante para descubrir archivos que el administrador del sitio no tenía intención de publicar.

Esta característica de Apache es controlada por la directiva Options. Para desactivarla se debe aplicar la siguiente configuración:

Options -Indexes

Como su propio nombre indica, mediante esta directiva se controlan varias opciones de configuración. Puede aceptar varios valores, entre ellos All y None para activar o desactivar todas las opciones disponibles. De hecho, en la configuración del directorio raíz se recomienda desactivar todas por seguridad, lo que incluiría la opción Indexes:

<Directory />
Order Deny,Allow
Deny from all
Options None
AllowOverride None
</Directory>

Desactivar los includes del lado del servidor

Esto también se hace con las opciones de directiva dentro de la etiqueta <Directory>; tiene dos posibles valores none o include.

Options -Includes

Desactivar la ejecución de CGI

Si no necesitas la ejecución de CGI por algún motivo en concreto, desactívala. Esto se hace con las opciones de directiva dentro de la etiqueta directorio; tiene dos posibles valores none o ExecCGI.

Options -ExecCGI

Desactivar todas las opciones juntas

Si deseas desactivar el uso de todas las opciones simplemente usa: Options None. Si solamente deseas desactivar algunas en concreto, sepáralas con un espacio en las opciones de directiva:

Options -ExecCGI -FollowSymLinks -Indexes

Limitar el acceso a archivos por extensión

En algunas ocasiones, determinados ficheros deben existir dentro del DocumentRoot del servidor pero no se desea que estén disponibles, como los ficheros .htaccess y .htpasswd, cuya funcionalidad se explicará posteriormente. En estos casos, se pueden utilizar las directivas Files y FilesMatch para denegar su acceso.

<Directory /opt/vhost.com.uy>
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
<FilesMatch "xmlrpc.php|install.php|CHANGELOG.txt|INSTALL*.txt|LICENSE.txt|MAINTAINERS.txt|UPGRADE.txt)">
Order deny,allow
Deny from all
</FilesMatch>
</Directory>
<Directory "/opt/vhost.com.uy/sites/default/files/">
<Files ~ ".php">
Order deny,allow
Deny from all
</Files>
</Directory>
<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl|svn-base)$|^(code-style\.pl|Entries.*|Repository|Root|Tag|Template|all-wcprops|entries|format)$">
Order allow,deny
</FilesMatch>

Disminuir el valor máximo de tiempo de espera

Por defecto, el tiempo de espera es de 300 segundos. Puedes disminuirlo por seguridad (para mejorar la resistencia a ataques de denegación de servicio) así:

Timeout 45

Limitar el tamaño de peticiones

Apache tiene varias directivas que permiten limitar el tamaño de una petición, lo que puede ser muy útil para asegurarlo contra ataques por desbordamiento, por ejemplo.
Una buena forma de comenzar es con la directiva LimitRequestBody, que está fijada a ilimitado por defecto. Si permities uploads de archivos que no sean mayores a 1MB, podrías fijar este ajuste con lo siguiente:

LimitRequestBody 1048576

Y si no estás permitiendo uploads de archivos, puedes fijarlo a un tamaño más pequeño. Algunas otras directivas que puede ser importante mirar son: LimitRequestFields, LimitRequestFieldSize y LimitRequestLine.

Limitar el tamaño de un XML REQUEST BODY

Si tienes en ejecución mod_dav (por ej., para usarlo con subversion) puede que quieras limitar el tamaño máximo de un XML request body.

Su valor predeterminado es de 1 MB. Si estableces este valor a 0 eliminas la limitación de tamaño, lo que puede ser útil si el servidor va a manejar ficheros grandes; pero si no es el caso, puede ser conveniente establecer un límite. Por ej., para definir un tamaño máximo de 10 MB:

LimitXMLRequestBody 10485760

Restringir acceso por IP

Si tienes un recurso al que deba solamente tener acceso alguna red o IP en concreto, se puede configurar de la siguiente manera, por ej. para permitir solamente la red 192.168.10.0/16:

Order Deny,Allow
Deny from all
Allow from 192.168.10.0/16

En el caso de que sea una dirección IP específica:

Order Deny,Allow
Deny from all
Allow from 192.168.10.10

Limitar la concurrencia

Esto principalmente es para mejorar su rendimiento, aunque también puede venir bien para hacer frente a las denegaciones de servicio. El programa tiene bastantes opciones de configuración que pueden usarse para ajustar el manejo de peticiones concurrentes.

MaxClients es el N máximo de procesos hijos que serán creados para servir las peticiones. Otras directivas que pueden ser importantes ajustar, son: MaxSpareServers, MaxRequestsPerChild, y en Apache2, ThreadsPerChild, ServerLimit, y MaxSpareThreads.

N depende mucho de los recursos de cada servidor y de la aplicación que se tiene hosteada.

Prevenir ataques SYN Flood

Son más refinados que el anterior ya que tratan de colapsar el servidor a nivel de TCP/IP y no de aplicación. Esto se consigue colapsando una estructura de datos en la que se almacena información sobre las conexiones TCP llamada Transmission Control Block o TCB. Para ello, en el handshake de establecimiento de sesión TCP, el atacante envía el SYN inicial, el servidor responde con SYN-ACK pero el atacante no envía el ACK final.

En Linux se puede mitigar con el mecanismo de SYN cookies que sólo reserva espacio para la conexión cuando se recibe el mensaje de confirmación final. Se puede activar de la siguiente manera:

sysctl net.ipv4.tcp_syncookies=1

Deshabilitar métodos HTTP

Los métodos HTTP que se pueden utilizar en un servidor web Apache deben estar restringidos para que sólo se usen aquellos que sean estrictamente necesarios. GET, POST y HEAD deberían ser más que suficientes para una web “normal”. Si permites OPTIONS te van a poder examinar todos los métodos permitidos; si permites TRACE, te puedes encontrar con alguna situación como la de robar las cookies HTTPOnly.

Si permites el método PUT o DELETE te puedes encontrar algún punto de la web en los que por fallos de los permisos te acaben metiendo una webshell y que aparezcas en una búsqueda por Shodan en un ataque de hacking con buscadores o borrando ficheros.

Hay aplicaciones que pueden requerir otros métodos, por ejemplo owncloud requiere el método PROPFIND

<Location "/">
AllowMethods GET HEAD POST
</Location>

Loguear IP de origen si HTTPD está detrás de un RP

Una buena práctica en la puesta en producción de servidor web consiste en que los mismos puedan registrar la dirección IP origen del cliente que realiza una solicitud, de esta manera se hace más fácil el trabajo de análisis de logs durante un incidente; además se puede tener un monitoreo real de las IP que realzan la consulta al servidor web y se pueden implementar mecanismos de seguridad efectivos a nivel de host.

Para Apache HTTPD 2.4

En /etc/httpd/conf.modules.d/00-remoteip.conf

RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy 192.168.xx.xx/24

En /etc/httpd/conf/httpd.conf:

LogFormat "%a %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio

Para Apache HTTPD 2.2

En Apache 2.2 no se puede modificar el formato del log de errores. para modificar el log estándar se configura en /etc/httpd/conf/httpd.conf lo siguiente:

LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

Configuración SSL

La cipher suite siguiente, son los que usan Perfect Forward Secrecy, por lo tanto si el certificado en algún momento llegase a ser comprometido, no podría utilizarse para desencriptar conversaciones que hayan sido capturadas con anterioridad.

Estos deberían revisarse periódicamente, se configura en /etc/httpd/conf.d/ssl.conf de ejemplo.

#SSLCipherSuite  EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Header always set X-Content-Type-Options nosniff
# Requires Apache >= 2.4
SSLCompression off
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
# Requires Apache >= 2.4.11
SSLSessionTickets Off
# Requiere Apache 2.4.8
#Usar una clave Diffie-Hellman > 2048, se puede generar con el comando
## cd /etc/ssl/certs; openssl dhparam -out dhparams.pem 4096
SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparam.pem"

Te recomendamos leer el artículo Hardening — Mejorando configuraciones SSL/TLS donde hablamos más sobre las configuraciones SSL.

Otras protecciones

Habilitar X-XSS-Protection

  • 0: Filtro deshabilitado
  • 1: Filtro activado. Si se detecta un ataque de cross-site scripting, con el fin de detener el ataque, el navegador va a desinfectar la página.
  • 1; mode=block: Bloqueo de filtro habilitado. En vez de sanear la página, cuando se detecta un ataque XSS, el navegador va a evitar que se muestre la página.
Header always set X-Xss-Protection "1; mode=block"

Habilitar X-Frame-Options Header Not Set

Header always set X-Frame-Options "SAMEORIGIN"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

En este artículo hablamos sobre las configuraciones de respuestas HTTP.

Desde GuayoyoLabs, esperamos que estas configuraciones puedan ser muy útiles para ti y puedas mejorar la seguridad de tus servidores web Apache.

Artículo relacionados:

Hardening — Asegurando NGINX
Hardening — Mejorando configuraciones SSL/TLS
Asegurando las cabeceras de respuestas HTTP en servidores web IIS
Asegurando las cabeceras de respuestas HTTP en servidores web Apache y NGINX