BORRADOR: Evaluación de Apache HTTP server como proxy/caché HTTPS en ambos extremos

1   Introducción

DXXXl CXXXn se pone en contacto telefónico conmigo la tarde del domingo 28 de abril de 2013, indicándome que las divisiones de banca del grupo SXXXr han sido amenazadas con ataques de denegación de servicio, que se realizarían a partir del 7 de mayo.

Con el fin de protegerse en lo posible, se está procediendo a configurar sistemas y a contratar servicios externos de paliación de ataques DDoS. Simultáneamente se planea desarrollar tecnología interna con este fin, con el propósito de disponer de varias vías de defensa alternativas, con diferentes costes y calidades.

En la conversación telefónica se me encarga la evaluación del servidor web Apache como plataforma proxy para la detección y prevención de ataques a servicios HTTPS. El plazo disponible es de una semana y el trabajo se tasa en XXX €.

2   Requisitos

El proyecto requiere cumplir estos requisitos:

1. El servicio debe atender peticiones HTTPS en la parte de cliente.
2. El servicio debe actuar de proxy de la forma más transparente posible (al usuario) hacia el sistema backend.
3. La conexión al sistema backend debe hacerse también por HTTPS.
4. El servicio debe escalar vertical (conexiones simultáneas en un mismo servidor) y horizontalmente (múltiples servidores proxy).
5. Un mismo proxy prestará servicios a muchos backends HTTPS distintos.
6. El servicio debe ser capaz de afrontar y notificar ataques DDoS básicos.
7. Idealmente, el servicio debe poder realizar también análisis de las peticiones para detectar y notificar (e idealmente, detener) ataques a nivel HTTP y a nivel de aplicación.
8. El proxy debe realizar también cacheo de objetos HTTP para reducir la carga en los servidores de backend, aunque para conseguir un nivel de “hits” importantes se requerirá modificar las aplicaciones de backend para añadir las cabeceras HTTP necesarias, etc.

DXXXl CXXXn sugiere utilizar el servidor web Apache porque se trata de un servidor capaz, con una gran reputación y presencia en el mercado, muy maduro y versátil. Además, el personal actual de PXXXn ya está familiarizado con él, así que soportar un producto basado en esta tecnología sería simple y tendría una curva de aprendizaje baja. Adicionalmente, el servidor web Apache dispone ya de módulos externos como “mod_security”, que se juzgan una buena base para este proyecto.

3   Evaluación preliminar

4   Evaluación

PXXXn realizará la instalación final usando Red Hat Linux, pero para las pruebas yo voy a utilizar una máquina virtual con Ubuntu 12.04 64 bits, con 2GB de RAM y 4 GB de disco duro: 3GB en “root”, 1GB de SWAP, bajo LVM. Sin cifrado de disco.

Instalamos OpenSSH y servidor DNS (ojo con su seguridad). Servidor completamente parcheado. Sin cortafuegos, ya que estamos en una máquina virtual.

Usuario: jcea/abc.

En la máquina virtual, mapeo de puertos: 11122->22, 11180->80, 11443->443.

Copio mi clave pública SSH para poder acceder desde mi portátil de forma simple.

La compilación de todo el software específico se realiza a través de scripts de configuración para tener configuraciones documentadas y reproducibles.

Dichos scripts y la configuración de los diferentes servicios se mantienen en un entorno de control de versiones.

Para intentar tener un entorno cercano a producción, genero certificados X.509 con claves RSA de 2048 bits. Usamos dos niveles, un CA y los certificados finales.

En el servidor Apache se configuran tres servidores virtuales: un servidor de monitorización, un servidor SSL externo, al que acceden los clientes, y un servidor SSL interno, haciendo de servidor “upstream” HTTPS.

Configuro Apache HTTP 2.4.4 para que se ejecute en el arranque. Pongo un “/server-status” y un “/server-info” en 11180. Sin control de acceso: http://www-status.XXX:11180/server-status .

Pongo “www-status.XXX” en mi “/etc/host”, mapeado a 127.0.0.1.

5   Detalles a verificar

• Revisar los permisos de las claves secretas SSL.

• Las claves secretas SSL no están protegidas con clave.

• Los errores en el proxy no deben filtrar información sobre los servidores “upstream” (sus nombres o sus IPs, por ejemplo).

• El proxy debe verificar los certificados X.509 de los servidores “upstream”.

• ¿Cómo vamos a canalizar las IPs de origen a través de los proxies?

• ¿Soporte SNI en el frontal? Problemático con clientes antiguos.

• Revisar con atención la configuración de las conexiones persistentes entre el proxy y los servidores “upstream”.

• ¿Las aplicaciones y los balanceadores intermedios funcionan si se canalizan peticiones de distintos usuarios a través de una única conexión persistente con el “upstream”?.

• ¿Activar la compresión entre el proxy y el “upstream”? ¿Entre el proxy y los clientes?

• Configurar correctamente la negociación de la calidad del cifrado SSL/TLS.

• Método “TRACE”.

• “mod_log_debug” puede configurarse para hacer log de los “timeouts” de los clientes.

• A la hora de realizar las pruebas de rendimiento, tengo que configurar mi portátil para que mantenga la CPU a 2.4Ghz y obtener así resultados estables y representativos.

  Por algún extraño motivo, obtengo más rendimiento con mi máquina cargada que con mi máquina en idle. Posiblemente un tema de “scheduling” entre mi kernel y la máquina virtual. Obtengo 65.6 peticiones por segundo, 34.8 si tengo la CPU a 800Mhz. Estas cifras sirven para poder compararse entre sí, no como valoración de rendimiento del entorno de producción.

• Configurar ProxyVia/ProxyReverseHost.

• Configurar ProxyPass con parámetros.

• Configurar ProxyErrorOverride.

• Configuro ProxyStatus, pero no sale nada. Insistir. ¿Tal vez no funciona para proxies inversos?.

• Evaluar “mod_proxy_express”.

• Evaluar “mod_proxy_html”.

• Evaluar “mod_proxy_balancer”. Activar el balancer-manager. Configuración en caliente.

• ¿Estamos delante o detrás del balanceador?. Importante para el “pool”, “stickiness”, “balanceador apache”.

• Configurar SSLProxy*.

• Evaluar SSLStapling*.

• Para evitar la sobrecarga de la negociación SSL/TLS, es imprescindible que los clientes reutilicen en lo posible las sesiones SSL/TLS. Configuro “SSL session cache”, pero no parece funcionar.

  El “lock” se guarda en un fichero borrado (pero accesible para los hijos del servidor Apache), pero no el caché SSL.

  Con “dbm” funciona, crea el fichero, pero no me parece usable en absoluto.

  apt_shm_create

  Si manipulo el código, veo que se crea el fichero, pero no guarda nada en él.

  Parcheando con “debug” a saco, veo que busca sesiones en la base de datos, pero también veo que no escribe nunca.

  Tras días investigando el asunto y escribiendo herramientas “ad hoc” para ello, identifico el problema: Si el cliente lo soporta, Apache utiliza “tickets” TLS, definidos en RFC 5077.

  Si la librería OpenSSL está compilada con soporte de “tickets” TLS, entonces Apache los utiliza incondicionalmente. No es configurable. Manipulo el código para desactivar el soporte de “tickets” TLS y entonces Apache sí emplea adecuadamente la base de datos de sesiones SSL.

  Todo esto es importante porque en la visualización del estado y las estadísticas Apache hay una sección sobre sesiones SSL, cuántas están activas y detalles de su reutilización. Cuando el cliente emplea “tickets” TLS, que he comprobado que es la norma, esa situación no se refleja en esas estadísticas, causando confusión y haciendo que la evaluación sea imposible. Lo que aparece es que el primer acceso de un cliente es un “miss”, pero los accesos subsiguientes, con “tickets” sencillamente no se ven en la estadística SSL/TLS. Entiendo que esto es un bug de Apache HTTP, tal vez porque la librería OpenSSL no exporta esa información. Verificarlo y notificarlo.

  Si desactivo el manejo de sesiones SSL en Apache, los clientes siguen pudiendo usar “tickets”. No es configurable en Apache.

  Me escribo un cliente que comprueba la recuperación de sesiones SSL y del uso de “tickets” TLS, y compruebo los puntos anteriores con detalle.

  Advertencia

  La idea de todo esto es poder monitorizar la efectividad del sistema de "tickets" TLS, porque un mecanismo de ataque evidente al servicio es obligarle a hacer negociaciones TLS redundantes o espúreas.

• Si tenemos varios proxies, todos ellos deberían usar la misma clave para proteger los “tickets” TLS, aunque por seguridad dicha clave debería cambiarse con frecuencia (horas).

• El uso de “tickets” TLS tiene implicaciones de seguridad importantes, como la desaparición de “forward secrecy” en caso de compromiso del servidor o de la clave de protección de los “tickets” TLS.

• Esto es aún más crítico cuando queremos que la clave de protección de “tickets” TLS esté compartida entre todos los proxies para reutilizar el máximo posible de sesiones TLS. Esto puede no ser un problema si solo tenemos un proxy por “cuenca” BGP.

• Falta verificación de certificados proxy.

• mod_security

  La protección DDoS no es muy capaz. Se limita a controlar el número de conexiones por IP, esté el servidor saturado o no. Para eso se puede hacer lo mismo a nivel de kernel, con “iptables -m connlimit”.

• Debido a la ocupación de memoria y a que el uso avanzado de módulos Apache que vamos a hacer es muy limitado, debemos usar pocos procesos con muchos hilos. Aún así, con la configuración de kernel “normal”, estamos hablando de 8 megabytes por conexión.

• Aunque Apache 2.4 tiene un modelo “Event”, que permitiría aliviar sobremanera este problema, no veo que haga nada en absoluto.

  Parcheando el código veo que sigue manteniendo un hilo por conexión, aunque estén “idle” o aunque estén sirviendo contenido ya generado. Invierto mucho tiempo investigando el asunto.

  Compruebo que cuando las conexiones no van cifradas, el modelo “event” sí funciona como se espera. Resulta que está documentado que no funciona (sin ningún tipo de “warning”) cuando se trabaja con conexiones SSL/TLS [5]. Esto hace que mis esperanzas de escalabilidad con Apache HTTP en nuestro entorno, 100% HTTPS, se frustren y descarta el producto. Vuelta al tablero de dibujo.

• Preguntados sobre el particular, aparentemente Apache HTTP 2.5, la versión de desarrollo no apta para producción, soluciona este problema. Pero no hay fecha de publicación de la versión estable 2.6.

• Tengo problemas también para configurar de forma separada los “timeouts” de los “keep-alive” en el proxy, en la parte “cliente” y en la parte “upstream” [6]. La documentación indica que se trata de un proceso delicado, pero incluso siguiendo el procedimiento indicado [7], no funciona. Parece ser un bug. Investigar.

6   Conclusión y recomendación final

Apache HTTP 2.4 consume un mínimo de 8 megabytes de memoria por conexión simultánea HTTPS al sistema. Solo este hecho excluye el uso de este producto para la aplicación demandada. Es cierto que la mayor parte de esa memoria no se va a utilizar y solo es preciso que esté disponible en el SWAP (para evitar el “overcommiting” de memoria), pero Apache HTTP no es un servidor proxy de alto rendimiento, sino un servidor web extremadamente versátil, con capacidad de actuar como proxy caché.

Adicionalmente, dotar de soporte HTTPS a un producto proxy/caché ya existente tiene un coste apreciable y requiere de unos conocimientos muy especializados del producto, sobre todo en productos asíncronos, que son precisamente los más escalables con el estado del arte actual.

De los productos alternativos analizados, solo nginx y Apache Traffic Server parecen merecer una evaluación más detallada.

Dado que el grupo SXXXr quiere contribuir a la fundación Apache y que la documentación del Apache Traffic Server parece ser muy completa y detallada, sugiero evaluar primero este producto.