Disclaimer:

Esta entrada ha tardado más de lo que tenía pensado porque en mi cabeza estuvo hablar también de lo que supone en cuanto a cambios Debian 9 respecto a la versión 8 (configuraciones, herramientas, paths, etc), pero tras varios servidores instalados en APACHEctl con Debian Stretch, creo que lo mejor es hacerlo en una aparte para poder explicarme mejor y dar un repaso a lo que más dolores de cabeza puede causar.

En el anterior post sobre mi participación en Hack&Beers Oviedo, ya os comenté que estaría de nuevo en Córdoba hablando de Servidores Web y cuestiones de seguridad. Pero a diferencia de 2015, año en el que impartí un taller de Hardening, esta vez tocaba subirse al escenario con: The ¿Perfect? Server, con una parte teórica y la «mítica Demo» (sí, esa del temido «efecto» que esta vez no sobrevoló el auditorio:).

 

Como dije en un vídeo que grabé con Oreixa frente al Mont Blanc desde el Aiguille du Midi a casi 3900 m, allí estaría «sí o sí». Desde la organización me facilitaron mucho las cosas en cuanto a la temática y pensando sobre qué podía hablar, les envié esta descripción

The ¿Perfect? Server

Aún recuerdo cuando seguía los míticos tutoriales de instalación de un servidor Web de Howtoforge publicados como «The Perfect Server». Falko, responsable del site y principal autor, ponía énfasis en una instalación básica en la que todo funcionaba, dejando a un lado cuestiones importantes como poder admitir un tráfico elevado, o cuestiones de seguridad.

A mi me parecían lo más lo más y me ayudaron mucho en su momento como punto de partida. Luego, con el tiempo, vas adaptando las instalaciones a las necesidades del proyecto y también aprendiendo sobre lo que no debes hacer, y los pasos que «sí o sí» tienes que dar.

Partiendo de la base de no creo que exista un «Servidor Perfecto», intentaré aportar mi punto de vista sobre cuestiones de instalación, configuraciones, optimización y seguridad fundamentales para un servidor dedicado.

Y basándome en ella, intenté aportar desde la experiencia de unas cuantas batallas, mi visión sobre lo que bajo mi punto de vista sería la instalación adecuada de un servidor web para quien esté empezando en este mundillo y necesite seguridad, estabilidad y/o rendimiento (que unas cosas llevan a las otras) así como para gente que llevaba más tiempo en el tema y pudieses aportarles algo de conocimiento adicional.

Di un repaso al «mundo Debian» explicando sus diferentes ramas, versiones de Software según Release, LTS, etc, dejando claro que para mi es la mejor elección a la hora de montar un servidor web.

Hablé de la elección de un sistema de ficheros y del particionado ideal, también del LVM, además del RAID y el cifrado de las particiones según el uso del server (aunque con lo que viene en el RGPD, cada vez es algo más) al igual que proteger GRUB en el arranque. Aquí os dejo un enlace a las guías de instalación oficiales, de recomendable lectura.

Y sobre las diferentes versiones de paquetes y las ramas de la distro, aquí tenéis el resumen que expuse en una de las diapositivas, enumerando las versiones del «stack» GLAMP / GLEMP, y los repos más comunes de Debian.

 

¿Qué pasa? que mucha gente cuando está haciendo un pentest, se lía un poco a veces con estas cuestiones y puedes llegar a pensar que has encontrado una vulnerabilidad si ves en la salida de tu Nmap un Nginx versión 1.6 (Debian 8) y vas a la página oficial y ves que la última versión de la rama 1.6x  fue la 1.6.3 de Abril de 2015 (es sólo un ejemplo), cuando realmente esa versión 1.6 es la de Debian y está actualizada y no es vulnerable.

También hablamos de Apache Vs Nginx y expuse varias comparativas (aquí una en la que se analiza uno frente al otro con contenido estático y dinámico) que venían a decir que sirviendo contenido estático, Nginx le superaba por goleada a Apache, pero que en un nivel de «performance» similar (PHP-FPM, PHP 7x + Zend OPcache, Pagespeed) la cosa cambia ya según desarrollos u otros temas relacionados.Por cierto, aquí una comparativa extensa de funciones y otros aspectos.

No dejé a un lado las importantes diferencias del MPM elegido para la puesta en producción de Apache. Centrando el foco en MPM Event y explicando las diferencias y relación con Worker,  funcionamiento asíncrono y las mejoras en las conexiones Keep Alive y alguna de sus directivas más comunes:

### Apache MPM Prefork, multiproceso, procesos “hijo” y sin hebras

StartServers: Número de procesos hijo creados en el arranque .
MinSpareServers: Número mínimo de procesos hijo a la espera de peticiones.
MaxSpareServers: Número máximo de procesos hijo a la espera de peticiones.
MaxRequestWorkers: Número máximo de conexiones simultáneas (se aumenta con ServerLimit).
MaxConnectionsPerChild: Número máximo de peticiones que sirve un proceso hijo de Apache

### Apache MPM Worker, multiproceso, procesos “hijo” y hebras o hilos

MinSpareThreads: Número mínimo de hebras en espera para atender peticiones.
MaxSpareThreads: Número máximo de hebras en espera.
ThreadLimit: Límite estricto del número de hebras del servidor.
ThreadsPerChild: Número de hebras creadas por cada proceso hijo.
MaxRequestWorkers: Límite estricto de peticiones simultáneas que serán servidas.
Ojo con la directiva “ListenBacklog” y los DoS  cuando MaxRequestWorkers llegue al límite.

Hice mención a las diferencias y mejoras en velocidad de MariaDB frente a MySQL (la rama 10x de MariaDB, es «un 10» también en rendimiento).

Mencioné las mejoras de PHP 7 frente a PHP 5x en rendimiento y memoria: comparativa 1, infografía, comparativa 3 junto a HHVM Aka: «el PHP de Facebook». También es importante tener claro qué implica la migración de la 5 a la 7 y os recomiendo esta entrada en la que enumeran 10 cuestiones a conocer sobre PHP 7.

Sobre seguridad en PHP, hardening / pentest, etc. Os recomiendo ver repasar los enlaces y contenidos de esta entrada.  No faltó un repaso al OWASP Top 10 2017 y cómo había evolucionado respecto al de 2013 (donde vemos cuestiones comunes y otras nuevas relacionadas con problemas de configuración y una protección proactiva frente a diferentes tipos de ataques).

Sobre los ataques DoS / DDoS

Volví a insistir en aquello de «por qué lo llaman DoS cuando son problemas causados por configuraciones ineficaces» y hablando de DDoS, recomendé el uso de UFONet, una gran herramienta creada por el amigo Epsylon que aprovecha vulnerabilidades «Open Redirect» con múltiples opciones y como dice su autor «no es para usarse con fines educativos;).

La herramienta «ab» incluida en «apache utils» (aptitude install apache2-utils) es de gran utilidad para realizar pruebas de estrés o simular ataques DoS desde uno o varios servidores. Aquí os dejo unos consejos interesantes para mejorar el rendimiento. También puede ser interesante usar Apache Benchmark y las gráficas de GNUPlot. Básicamente el uso sería:

ab -c 300 -n 1000 http://webdeejemplo.com/index.php/

Donde c 300 sería el nivel de concurrencia y n 1000 el número de peticiones (os recomiendo ver todas las opciones disponibles). Si estáis haciendo un test con Apache Benchmark y veis este mensaje de error al intentar subir los valores de concurrencia o peticiones:

socket: "Too many Open Files"

Con aumentar los límites con el comando ulimit (página del manual) ya lo tendréis resuelto:

ulimit -n 5000 (por ejemplo)

En el servidor atacado, podéis ver el número de peticiones que llegan desde las IPs de origen por ejemplo con este comando:

netstat -plan|grep :80 | awk {'print $5'}|cut -d: -f 1|sort|uniq -c|sort -n

Otra herramienta DoS que siempre tengo siempre a mano es GoldenEye, intuitiva, efectiva y fácil de usar.

Volviendo a UFONet, aquí os dejo un ejemplo de uso, sería ya el concepto de un ataque distribuido y con un impacto mucho mayor llegado el caso o dependiendo de los «zombies», así que ojo y a documentarse bien (teniendo en cuenta que según la legislación de vuestro país de origen, aprovecharse o explotar esas vulnerabilidades «Open Redirect», si hablamos de España, lugar donde el hacking / conocimiento está cada vez más criminalizado, puede meterte en apuros, así que más ojo si cabe).

Mi intervención que fue de en torno a una hora, acabó con una demo realizando ataques DoS desde varios servidores hacia un subdominio que monté en un VPS y estuvimos viendo cómo se comportaba, analizando peticiones, origen de los ataques, (principalmente con Mod Status) así como aplicando medidas paliativas con Mod Evasive y otras configuraciones.Aquí tenéis un ejemplo de lo que os comento y que podéis ver en la siguiente imagen:

Para ver en tiempo real las IPs y peticiones que se están realizando al servidor, en vuestro navegador:

http://IP-Servidor/server-status?refresh=2 donde el refresh=2 es el número de segundos para refrescar los datos.

No faltó una mención a Cloudflare con algún ejemplo, también a herramientas como «Cloudflail» y algún ejemplo de lo visto en cuanto a ·»fingerprinting» y configuraciones muy permisivas buceando con DNSdumpster (recurso que gustó mucho). Para acabar con el tema de las pruebas de estrés, un recurso web que puede ser interesante es Load Impact, donde tenéis diferentes planes de precio en modo «suscripción» o también está opción de pagar por tests puntuales según concurrencia y duración del mismo..

Un evento para no olvidar…

Sobre el QurtubaCON, no me cansaré de repetirlo, increíble esfuerzo por parte de la organización (con «súper Paco» a la cabeza) y no daré nombres porque siempre te dejas a alguno en el tintero. Un equipazo que está encima de cada detalle para que te sientas como en tu casa, y una CON de las que te deja huella en lo técnico y humano. Disfruté y aprendí mucho viendo al resto de ponentes, además de con la ciudad una vez más y su gente. De veras, eso de «somos una familia», en Qurtuba, además de algún otro evento en los que he estado, no es una frase hecha.

Muchas gracias a las personas de la organización, resto de participantes y a los asistentes al evento (guardo con cariño los detalles de algunos de vosotros y no me olvido de vuestras palabras, recuerdo incluido hacia el Podcast, que verá la luz de nuevo) ¿Lo próximo? Servers y Debian 9.