Protegiendo el servidor Apache

Apache es un servidor web de código abierto, que ocupa el primer lugar entre los servidores web más utilizados en todo el mundo.

Para nosotros, expertos técnicos, es muy probable que ya hayamos trabajado con él en algún momento de nuestra rutina profesional.

Lo que no es muy común sabermos es que Apache, al igual que toda la tecnología, puede presentar fallas de protección de datos, lo que nos lleva obligar a realizar ciertas configuraciones para reforzar la seguridad de nuestro servidor. Basado en las vulnerabilidades encontradas constantemente durante las pruebas realizadas por Cipher, señalaremos los puntos principales y cómo podemos solucionarlos.

ATTENCIÓN: Si realiza cualquier tipo de cambio en Apache, debe reiniciar el servicio para que los dichos cambios sean aplicados. Podemos hacerlo a través del comando service apache2 restart.

Banner Expuesto

El primer punto para tener en cuenta es este, porque es a través del banner que un atacante puede definir el tipo de servidor web, su versión y, basándose en esta información, elaborar un plan de ataque más resuelto. Este banner se puede ver en las páginas por defecto, en las cabeceras de respuesta y en las páginas de error.

Para ocultar el banner, cambiaremos el archivo de configuración de seguridad que se ubica en /etc/apache2/conf-available/security.conf Si el archivo no esté en ese mismo directorio, haga una búsqueda rápida para localizarlo, mediante el comando find/name security.conf -type f | grep -i apache 2>/dev/null o consulte el manual para conocer la ubicación exacta.

Con el archivo abierto, cambie la línea ServerTokens OS por ServerTokens Full, la línea ServerSignature On por ServerSignature Off y añada la línea SecServerSignature Server.

ETag

ETag se utiliza para hacer que el almacenamiento en caché sea más eficiente. Es un ID único generado para un recurso de la página web y no sea cambiado hasta que ese recurso correspondiente cambia. Esto ayuda a identificar si cierto contenido de la URL ha cambiado y, por lo tanto, a utilizar la caché si no ha ocurrido ningún cambio.

El servidor web Apache tiene una vulnerabilidad de divulgación de información relacionada con ETags (en la configuración por defecto). ETag en un archivo específico puede contener un valor de nodo-i. Esta información por sí sola es inofensiva, pero puede dar lugar a ciertos ataques cuando se combina con las NFS.

Utilice el mismo archivo para configurar el Ubanner (security.conf) y añada FileETag None al final del archivo.

Listado de Directorios

De los elementos informados hasta ahora, este es el que presenta los mayores riesgos, porque el Listado de Directorios es una característica que, estando activada, los servidores web listan el contenido de un directorio cuando no hay un archivo de índice presente, como index.php o index.html. En caso de que existan archivos confidenciales como: copias de seguridad, bases de datos, contraseñas y/o claves de acceso, serán entregados a un atacante.

Aquí, trabaje con el archivo /etc/apache2/apache2.conf, simplemente cambiando Options Indexes FollowSymLinks por Options FollowSymLinks.

Acesso ao git

Muchos sitios y/o aplicaciones web utilizan el git para versionar los códigos. Incluso después de bloquear el listado de directorios, es posible acceder directamente a archivos como http://site.com.br/.git/config o http://site.com.br/.git/HEAD, torna el proceso altamente vulnerable.

Abra el archivo /etc/apache2/conf-enabled/security.conf y añada el siguiente contenido:

<DirectoryMatch “/\.git”&gt

Exigir todos los denegados

</DirectoryMatch>

Git es sólo un ejemplo clásico (y crítico), pero esta regla debería aplicarse a todos los directorios que poseen datos confidenciales y que no se accede por usuario final.

Métodos HTTP

Abra el archivo /etc/apache2/sites-available/000-default.conf y comente la línea DAV On para desactivar los métodos PUT y DELETE. Este cambio desactiva el WebDAV (Web-based Distributed Authoring and Versioning) proporcionado por el módulo mod_dav, que es la extensión que permite crear, mover, copiar y excluir archivos.

Tenga en cuenta que este cambio no desactivó el método TRACE, que puede conducir a la divulgación de información como las cabeceras de autenticación del proxy. Para resolver este problema, abra el archivo /etc/apache2/conf-enabled/security.conf, y cambie TraceEnable On por TraceEnable Off.

XSS y Clickjacking

Los ataques XSS y Clickjacking son muy comunes y pueden presentar un cierto riesgo de seguridad. Esto se puede arreglar fácilmente accediendo a /etc/apache2/conf-enabled/security.conf y añadiendo las siguientes líneas:

Header set X-Frame-Options: “sameorigin”

Header set X-XSS-Protection “1; mode=block

A continuación, active el módulo ejecutando el siguiente comando en el terminal: a2enmod headers.

Desactivando el HTTP 1.0

Se sabe que en HTTP 1.0 hay una falla de seguridad relacionada con el secuestro de sesiones. Por lo tanto, debe ser desactivado para proteger los usuarios.

Abra el archivo /etc/apache2/apache2.conf y en la sección <Directory/var/www/>, añada las siguientes líneas:

RewriteEngine On

RewriteCond %{THE_REQUEST} !HTTP/1.1$

RewriteRule .* – [F]

Ahora sólo hay que habilitar el módulo con el comando a2enmod rewrite

IP Whitelisting (lista blanca)

Una buena práctica de seguridad es crear una lista de IPs válidos para acceder a una aplicación. Sabemos que esta regla no se puede generalizar, ya que ciertas aplicaciones deben ser realmente accesibles para todos, por lo que hay que utilizarlas sólo si es necesario.

Abra el archivo /etc/apache2/sites-available/000-default.conf, añada el siguiente contenido, dentro de la sección <VirtualHost *:80>.

<Location /<directory>>

Order deny,allow

Deny from all

Allow from <ip1>

Allow from <ip2>

Allow from <range>/24

</Location>

TLS (Transport Layer Security) v1.3.

El uso de criptografía en las requisiciones ha tornado imprescindible debido a la cantidad de datos confidenciales que circulan todo el tiempo. Los atacantes pueden, por ejemplo, interceptar las requisiciones a través de un ataque MITM (Man-In-The-Middle) y obtener acceso a las credenciales para acceder a una aplicación especifica. ¿Imagina qué puede pasar si es víctima de este tipo de ataque al acceder a su cuenta bancaria a través de la aplicación web? Los bancos utilizan el TLS por medida de seguridad, pero no todas las empresas siguen las buenas prácticas. Esté siempre atento.

Abra el archivo de acuerdo /etc/apache2/sites-available/default-ssl.conf (créelo si no existe) y añada el siguiente contenido:

<IfModule mod_ssl.c>

<VirtualHost _default_:443>

ServerAdmin webmaster@localhost

DocumentRoot /var/www/html

ErrorLog ${APACHE_LOG_DIR}/error.log

CustomLog ${APACHE_LOG_DIR}/access.log combined

# SSL Engine Switch:

# Enable/Disable SSL for this virtual host.

SSLEngine on

SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem

SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

# This enables optimized SSL connection renegotiation handling when SSL

# directives are used in per-directory context.

<FilesMatch “\.(cgi|shtml|phtml|php)$”>

SSLOptions +StdEnvVars

</FilesMatch>

</VirtualHost>

</IfModule>

Abra el archivo/etc/apache2/sites-available/000-default.conf y añada el siguiente contenido a la raíz del nodo <VirtualHost *.80>.

Redirect “/” “https://{{your_domain}}/”

A continuación, ejecute los siguientes comandos para activar los módulos de soporte SSL:

a2enmod ssl

a2enmod headers

a2ensite default-ssl

Con el TLS ya instalado, actualícelo a la última versión (la versión actual es la 1.3). Hágalo en /etc/apache2/mods-available/ssl.conf, cambiando la línea SSLProtocol all -SSLv3 (puede ser que ya esté configurada en otra versión) por SSLProtocol TLSv1.3.

Utilice el comando openssl s_client -connect {{su_dominio}}:443 -tls1_3 para confirmar si ha surtido efecto.

Conclusiones

Apache se puede configurar fácilmente, pero algunas de las configuraciones sugeridas pueden interferir en el correcto funcionamiento de las herramientas de escaneo y gestión de vulnerabilidades, por lo que todo cuidado es poco para evitar problemas adelante. Una aplicación web carga datos importantes y debemos protegerla siempre contra cualquier tipo de amenaza. Siguiendo estas buenas prácticas, la seguridad tendrá un mejoramiento. No tiene mucho sentido proteger el servidor y dejar vulnerable el código de la aplicación, ¿verdad? Aparte de eso, siempre es bueno utilizar un WAF (Web Application Firewall) como una camada extra de seguridad.

Espero que este post haya sido de gran ayuda para el uso del Apache.

Hasta la próxima.

Fonte: Lucas Davis – Consultor del Equipo Rojo – Cipher.