Guía de hardening para JBoss EAP 7.0

Hardening para servidores JBoss EAP 7.0

Hoy les quiero compartir una guía de hardening de servidores web JBoss EAP 7.0. Debido a lo reciente que es la versión, la documentación existente es muy poca y algunas cosas de plano no están documentadas aún (Y ni mencionar que la documentación de Redhat no es libre). Entonces para ahorrarles el trabajo y que no acaben como yo…

Tabs tabs tabs!

Aquí podrán encontrar una guía concreta con las configuraciones que aplicar para hardenizar una aplicación web que se ejecute sobre JBoss EAP 7.0.

Página de bienvenida y páginas de errores personalizadas

El servidor web por defecto incluye páginas default de bienvenida y para cada tipo de error HTTP que pueda generar la aplicación (404, 500, etc). Se recomienda:

Ocultar o reemplazar la página de bienvenida para evitar revelar la versión de software. Para deshabilitar la página de bienvenida se puede establecer el valor de Root Web Context al valor “/” en el archivo jboss-web.xml:

<?xml version="1.0" encoding="UTF-8"?>
<jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_5_1.xsd">
<context-root>/</context-root>
</jboss-web>

Otra manera de deshabilitar la página de bienvenida sin tener que mover el valor de la ruta de nuestra aplicación es eliminando las siguientes líneas del archivo de configuración standalone.xml:

<location name="/" handler="welcome-content"/>
<handlers>
  <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
</handlers>

Personalizar las páginas de error para ocultar las trazas de pila o de depuración que genera la aplicación. Esto tiene el objetivo de ocultar detalles internos de la aplicación a visitantes o posibles atacantes. Para configurar la aplicación debemos modificar el archivo de configuración web.xml y agregar la siguiente configuración:

<error-page>
  <error-code>500</error-code>
  <location>/error.jsp</location>
</error-page>
<error-page>
  <error-code>404</error-code>
  <location>/error404.jsp</location>
</error-page>

1.2 Cabeceras de información

El servidor web por defecto incluye cabeceras de información que incluyen detalles como el tipo de servidor, tecnologías que utilizan y versiones de software.

1.2.1 X-Powered-by

Se recomienda eliminar o personalizar el valor de la cabecera X-Powered-By para evitar revelar información sobre la versión del producto. Esto se puede realizar desde el archivo de configuración web.xml utilizando las siguientes directivas como filtros:

<subsystem xmlns="urn:jboss:domain:undertow:3.1">
…
<filters>
  <response-header name="server-header" header-name="Server" header-value="My Own Server"/>
  <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="My Own Server"/>
</filters>
</subsystem>

1.3 Configuración SSL / TLS

Aplicaciones que manejen información sensible o financiera deben operar a través de canales de comunicación seguros. Se recomienda habilitar TLS como canal de comunicación seguro y configurar el servidor para solo permitir protocolos y métodos de cifrado seguros.

1.3.1 Protocolos y cifrados inseguros

Se recomienda eliminar protocolos inseguros como SSLv2 y SSLv3 y únicamente habilitar métodos de cifrado (ciphers) que se consideren seguros. Esto se puede realizar desde el archivo de configuración del listener HTTPS a través de los valores “enabled-protocols” y “enabled-cipher-suites” como se demuestra a continuación:

<https-listener name="https" secure="true" enabled-protocols="TLSv1.1,TLSv1.2" enabled-cipher-suites="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256" security-realm="SSLRealm" socket-binding="https"/>

En la configuración anterior únicamente habilitamos cifrados que no tienen problemas de seguridad conocidos y se consideran robustos pero se recomienda hacer pruebas de compatibilidad en base a los requerimientos del proyecto.

Ilustración 1 Resultado de ssl-enum-ciphers de Nmap después de aplicar la configuración

Adicionalmente se puede evaluar la configuración de un servidor SSL/TLS con la herramienta SSLTest de Qualys disponible gratuitamente en la siguiente dirección: https://www.ssllabs.com/ssltest/

1.3.1 HSTS

Esta cabecera obliga al navegador a conectarse únicamente al sitio a través del protocolo HTTPS. Es importante incluir un tiempo de vida corto mientras se prueba esta cabecera y asegurarse que toda la aplicación y recursos sean transmitidos sobre HTTPS.

Strict-Transport-Security: max-age=86400; includeSubDomains

En la aplicación se puede establecer este valor a través de la siguiente función:

response.addHeader("Strict-Transport-Security", "max-age=86400; includeSubDomains");

Más información sobre esta cabecera puede ser encontrada en la siguiente dirección:

https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet

1.3.2 HPKP

Esta cabecera de seguridad previene el uso de certificados falsos o apócrifos y mitiga los ataques de tipo Man In the Middle. Esta cabecera debe ser implementada únicamente en organizaciones con cierta madurez en el proceso de manejo de certificados porque una mala administración puede llevar a bloquear a usuarios del sitio. La cabecera tiene el siguiente formato:

Public-Key-Pins: pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; report-uri="http://example.com/pkp-report"; max-age=10000; includeSubDomains

En la aplicación se puede establecer este valor a través de la siguiente función:

response.addHeader("Public-Key-Pins ", ‘sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; report-uri="http://example.com/pkp-report"; max-age=10000; includeSubDomains’);

HPKP: https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#hpkp

1.4 Cabeceras de seguridad

Existen cabeceras de seguridad que vienen implementadas en todos los navegadores web modernos que pueden ser utilizadas para incrementar el nivel de seguridad de la aplicación.

Para más información sobre estas cabeceras visite la siguiente página:

https://www.owasp.org/images/6/6a/Headers_seguros.pdf

1.4.1 X-XSS-PROTECTION

Esta cabecera protege contra ataques de tipo Cross Site Scripting en peticiones e incluso pueden bloquearse a nivel navegador web. Para implementarlo en páginas JSP solo se requiere agregar el siguiente código:

response.addHeader("X-XSS-Protection", "1; mode=block;");

Además esta cabecera puede ser configurada para que automáticamente envíe cualquier incidente de este tipo si establecemos la directiva ‘report’:

response.addHeader("X-XSS-Protection", "1; mode=block; report=<URL>");

Más información en https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#xxxsp

1.4.2X-FRAME-OPTIONS

Esta cabecera protege contra ataques de tipo Clickjacking. Para evitar que la aplicación web sea cargada dentro de frames, solo se requiere agregar el siguiente código Java al proyecto:

response.addHeader("X-Frame-Options", "DENY");

Si la aplicación funciona a través de frames, se puede configurar la política para solo permitir dominios específicos.

Más información en https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#xfo

1.4.3Cookies

Existen dos tipos de cabeceras de seguridad relacionadas con cookies.

Secure

Esta cabecera evita la transmisión de cookies por canales no seguros como HTTP. Este valor se adjunta con la cabecera de cookies y puede ser automáticamente configurado desde la configuración de la aplicación en el archivo web.xml:

<session-config>
  <cookie-config>
    <secure>true</secure>
  </cookie-config>
</session-config>

Más información en https://www.owasp.org/index.php/SecureFlag

HTTPOnly

Esta cabecera restringe el acceso a las cookies desde scripts de lado cliente. Esto mitiga ataques de robo de sesión a través de vulnerabilidades Cross Site Scripting. Este valor igual simplemente se adjunta a las cabeceras de cookies y se puede configurar automáticamente desde la configuración del servidor web (web.xml).

<session-config>
  <cookie-config>
    <http-only>true</http-only>
  </cookie-config>
</session-config>

Más información en https://www.owasp.org/index.php/HttpOnly

1.4.4Cabeceras de seguridad adicionales

Existen otras cabeceras de seguridad que pueden ser implementadas como controles adicionales después de una rigurosa inspección del contenido a servir. Errores en configuración podrían afectar la accesibilidad del sitio.

Content-Security-Policy: https://www.owasp.org/index.php/Content_Security_Policy
X-Content-Type-Options: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

Estas cabeceras se pueden implementar a nivel aplicación de la misma manera que las cabeceras de seguridad mencionadas anteriormente.

¿Nos faltó algo?

No dudes en contactarnos si crees que deberíamos agregar algo más a esta guía.