Tema 6 de teoría: Asegurar el sistema web (SWAP2016)

La seguridad en un sistema web resulta de vital importancia para evitar posibles accesos a las máquinas y a los datos por parte de hackers malintencionados. En un sistema bien asegurado podremos determinar qué ocurre en cada momento y quién ha hecho cada cosa y en qué momento. Un sistema bien configurado nos asegurará los siguientes puntos:

• La confidencialidad, en el sentido de que las comunicaciones deben ser secretas.
• La integridad, de forma que los mensajes enviados deben ser exactamente los recibidos.
• La disponibilidad de los servicios del sistema (no deben verse afectados por posibles ataques).

En este tema tratamos varios conceptos: defensa en profundidad, políticas de seguridad, asegurar el servidor, configuración del cortafuegos, y prácticas de seguridad recomendadas.

El concepto de defensa en profundidad hace referencia a la configuración de varias capas de defensa para defender el sistema a varios niveles. De esta forma se dificulta el acceso último del hacker malicioso a los servidores, haciendo que sea más probable detectar un ataque, y así evitar que las últimas defensas se vean comprometidas.

El proceso de asegurar el servidor implica establecer políticas de seguridad, que definen cómo interaccionarán los usuarios con los servidores del sistema web. Las políticas de seguridad definen procedimientos de identificación y acceso, que comprueban si un individuo es reconocido por los sistemas de seguridad. También los privilegios de uso, que definen qué acciones puede llevar a cabo cada tipo de usuario correctamente identificado.

Hemos comentado que se deben establecer y aplicar políticas a diferentes niveles y así establecer seguridad a nivel físico (que no lleguen hasta los servidores para robarlos), a nivel de red (evitar el acceso a través de comunicaciones por la red), a nivel de administrador (creando las cuentas de administrador adecuadamente), y a nivel de cuentas de servicios (o aplicaciones).

En el proceso de asegurar el servidor debemos eliminar diversos servicios innecesarios y otras fuentes de posibles vulnerabilidades. Concretamente debemos eliminar: características no necesarias, servicios, configuraciones e información de seguridad del servidor. Sólo dejaremos las aplicaciones, servicios y puertos imprescindibles.

Finalmente, una parte importante del proceso de asegurar el servidor es la configuración del cortafuegos. Este elemento de la red protege el sistema de accesos indebidos, haciendo de guardián del sistema, filtrando el tráfico de red (permitiendo cierto tráfico y denegando el resto). El software de cortafuegos por excelencia es iptables.

Un cortafuegos bien configurado evita el consumo excesivo de recursos, reduciendo el tráfico global que un servidor recibirá, oculta los servidores finales a otras redes, protege los servidores de múltiples ataques, oculta información de los servidores a otras redes, y avisa de posibles ataques justo en el momento en que se producen.

Por último, es importante tener un equipo de ingenieros con dedicación exclusiva a investigar temas de seguridad del sistema a todos los niveles para estar preparados ante posibles ataques. Estas personas deben conocer los temas relativos a la seguridad así como las vulnerabilidades a nivel de red, de cortafuegos, de sistema operativo y de las aplicaciones en el sistema web. Además, cuando se identifique una vulnerabilidad, los administradores de seguridad deben tomar las medidas de prevención necesarias para evitar que los posibles atacantes la puedan aprovechar.


En clase planteamos los siguientes ejercicios:

• Ejercicio T6.1: Aplicar con iptables una política de denegar todo el tráfico en una de las máquinas de prácticas. Comprobar el funcionamiento.
  

Aplicar con iptables una política de permitir todo el tráfico en una de las máquinas de prácticas. Comprobar el funcionamiento.

• Ejercicio T6.2: Comprobar qué puertos tienen abiertos nuestras máquinas, su estado, y qué programa o demonio lo ocupa.
  

• Ejercicio T6.3: Buscar información acerca de los tipos de ataques más comunes en servidores web, en qué consisten, y cómo se pueden evitar.
  

La entrega de los ejercicios de clase se realizará en una carpeta llamada "trabajos_de_clase" que cada cual mantendréis en vuestro repositorio de la asignatura en github.com


Recursos adicionales

Tutoriales sobre cómo configurar el cortafuegos en Linux con iptables:
  http://www.cyberciti.biz/tips/linux-iptables-examples.html
  http://www.linuxtotal.com.mx/?cont=info_seyre_002
  https://openwebinars.net/como-configurar-en-linux-firewall-basico-con-iptables/
  http://es.tldp.org/Manuales-LuCAS/doc-iptables-firewall/doc-iptables-firewall-html/

Sitios web especializados en seguridad:
  http://www.securitybydefault.com/
  http://www.pentester.es/
  http://www.elladodelmal.com/
  http://www.hackhispano.com/
  http://thehackerway.com/2014/05/21/21-blogs-sobre-seguridad-informatica-que-deberias-conocer/
  https://www.youtube.com/watch?v=w0SB6eAnx4Q&list=PL7C849047272B22E0

Tema 5 de teoría: Medir prestaciones (SWAP2016)

Tras configurar un sistema, del tipo que sea, debemos comprobar que dará las prestaciones esperadas. En este tema hemos explicado qué procesos y herramientas debemos usar para llevar a cabo la medición de prestaciones.

Como comentamos, no se trata de detectar posibles caídas o errores de programación, sino los problemas de rendimiento y degradación de prestaciones que puedan darse en el sistema cuando esté en producción. Buscamos los posibles cuellos de botella e ineficiencias antes de ponerlo en marcha de cara a los usuarios finales.

Para llevar a cabo estas tareas debemos tener en cuenta la dificultad que supone hacer pruebas en un entorno de producción, así como la imposibilidad de simular el comportamiento de los usuarios.

Habitualmente se utilizan tres métricas:

• Conexiones por segundo: número de conexiones de entrada que cierto dispositivo puede manejar por segundo (transacciones por segundo o sesiones por segundo).
• Número total de conexiones concurrentes: sesiones de usuario TCP que puede manejar el balanceador al mismo tiempo.
• Rendimiento (en bits por segundo): velocidad a la que un dispositivo maneja el tráfico; se mide en bits por segundo y es la combinación del "tamaño del paquete" y de los "paquetes por segundo".

Hemos estudiado que existe un límite del tráfico de red que produce una degradación en las prestaciones. Si se alcanza ese límite en un sistema, los tiempos de respuesta en las conexiones HTTP se degradan completamente, haciendo imposible la conexión. Es importante monitorizar el sistema para detectar este comportamiento, que se ve claramente en gráficas como las que siguen:

Cuando se alcanza el límite y el sistema deja de responder como se espera, las prestaciones caen (el sistema deja de dar su servicio).


Finalmente, para determinar cómo evolucionan las prestaciones del sistema se suelen utilizar herramientas que generan carga al sistema (tráfico de red). Se suelen usar benchmarks como SPECweb o WebStone para simular un número determinado de clientes.

Existen otras herramientas de simulación de carga que podemos usar en cualquier máquina, como por ejemplo:

• Apache Benchmark
• httperf
• OpenWebLoad
• The Grinder
• OpenSTA
• Jmeter
• siege
• Webstone (Mindcraft)

 
Todas ellas permiten comprobar el rendimiento de cualquier servidor web (Apache, MS Internet Information Services -IIS-, nginx, Cherokee, Tomcat, lighttpd, thttpd, etc) para comprobar el rendimiento del hardware, software o de alguna modificación en la configuración que hayamos hecho.

También tenemos la opción de encargar a una empresa externa especializada la aplicación de estas cargas y el análisis de los resultados. Como ejemplos, cabe destacar:

• Micro Focus Intl. - Segue Software (SilkPerformer)
• HP (LoadRunner)
• Micro Focus Intl. - Compuware (QALoad)
• Rational (SiteLoad)
• Radview (WebLoad)

Lo que hacen son diferentes tipos de pruebas a los servidores para comprobar su funcionamiento en diferentes condiciones:

• Humo (Smoke): pruebas preliminares para comprobar que el sistema está listo para los siguientes tests.
• Carga (Load): cargas lo más parecidas a la real ejecutadas en periodos cortos (1h), para determinar los tiempos de respuesta que tendrán los usuarios.
• Capacidad (Capacity): actividad creciente hasta detectar el punto de saturación.
• Estrés (Stress): para analizar el efecto de aplicar de forma continuada una carga por encima de la capacidad del sistema.
• Sobrecarga (Overload): aplicar fuertes picos de carga durante cortos periodos.
• Estabilidad (Stability): cargas lo más similares posibles a la real, aplicadas durante 1 día o 1 semana.

Es importante recoger todos los datos posibles durante la ejecución de estas pruebas para poder determinar lo que está ocurriendo en el sistema en cada momento y cómo reacciona éste en función de la carga introducida, ya sean medidas de la calidad del servicio del sistema (estadísticas que calcula la herramienta de generación de carga) o medidas del consumo de recursos del sistema (utilizando herramientas del sistema operativo).


En clase planteamos los siguientes ejercicios:

• Ejercicio 5.1: Buscar información sobre cómo calcular el número de conexiones por segundo.
• Ejercicio 5.2: Instalar wireshark y observar cómo fluye el tráfico de red en uno de los servidores web mientras se le hacen peticiones HTTP.
• Ejercicio 5.3: Buscar información sobre herramientas para monitorizar las prestaciones de un servidor.

La entrega de los ejercicios de clase se realizará en una carpeta llamada "trabajos_de_clase" que cada cual mantendréis en vuestro repositorio de la asignatura en github.com

Práctica 4: Comprobar el rendimiento de servidores web

En esta práctica vamos a usar varias herramientas para crear cargas HTTP sobre el sistema web. Hay sistemas en los que se usan herramientas como SPECweb o WebStone para simular un número determinado de clientes accediendo al sistema. En cualquier caso, las pruebas deben hacerse simulando accesos simultáneos de un gran número de usuarios, para lo cual, usaremos herramientas de generación del tráfico.

Existen herramientas para comprobar el rendimiento de servidores web basadas en interfaz de línea de comandos y también basadas en interfaz gráfica. Lo habitual es usar programas de línea de comandos que sobrecarguen lo mínimo posible las máquinas que estamos usando (tanto la que genera el tráfico como las del sistema servidor). Además, es importante usar siempre la misma máquina para generar el tráfico, y lo más importante, que esa máquina sea totalmente independiente de las que forman la granja web.

Entre las herramientas más utilizadas para generar tráfico HTTP destacan:

• Apache Benchmark
• Siege
• The Grinder
• OpenSTA
• JMeter
• httperf
• OpenWebLoad

Todas ellas nos permiten comprobar el rendimiento del servidor web, ya sea del hardware o software, o de alguna modificación/configuración que hayamos hecho.


En esta práctica proponemos usar las siguientes herramientas para comprobar el rendimiento de nuestra granja web recién configurada (aunque se pueden usar otras herramientas que encontremos):

• Apache Benchmark: http://httpd.apache.org/docs/2.2/programs/ab.html
• Siege: https://www.joedog.org/siege-home/

La idea de esta práctica es usar varias herramientas para comparar los resultados de rendimiento de tres configuraciones: (1) máquina sola, (2) granja con nginx, (3) granja con haproxy.

Se recomienda crear una cuarta máquina virtual o bien usar un terminal en nuestro ordenador anfitrión y desde ahí lanzar las herramientas para generar el tráfico. Es importante que la carga computacional y de red que supone la batería de peticiones no recaiga sobre ninguna de las máquinas que forman la granja web, tal y como se indica en el siguiente esquema:

Herramienta 1: Apache Benchmark

Apache Benchmark (ab) es una utilidad que se instala junto con el servidor Apache y permite comprobar el rendimiento de cualquier servidor web, por sencillo o complejo que sea. Con esta herramienta podemos analizar el rendimiento de servidores Apache, Internet Information Services (IIS), nginx, etc.

Para ejecutarla, entramos en un terminal en la máquina cliente y ejecutamos el comando:

ab -n 1000 -c 10 http://ipmaquina/test.html

Los parámetros indicados en la orden anterior le indican al benchmark que solicite la página con dirección http://ipmaquina/test.html 1000 veces (-n 1000 indica el número de peticiones) y hacer esas peticiones concurrentemente de 10 en 10 (-c 10 indica el nivel de concurrencia). Esos parámetros generan una carga muy baja; para hacer la práctica probablemente tengamos que usar valores mucho mayores en ambos casos.

ab no simula con total fidelidad el uso del sitio web que pueden hacer los usuarios habitualmente (en realidad, ninguna herramienta lo hará). Pide el mismo recurso (misma página) repetidamente. Sin embargo, va bien para testear cómo se comporta el servidor antes y después de modificar cierta configuración.

Con esta herramienta, de todas las medidas que nos ofrece, vamos a recoger: "Time taken for tests", "Failed requests", "Requests per second" y "Time per request".


Herramienta 2: Siege

Siege es una herramienta de generación de carga HTTP para benchmarking. Se trata de una utilidad de línea de comandos, similar en interfaz al Apache Benchmark, aunque las opciones de ejecución son ligeramente diferentes. Por ejemplo, permite realizar las baterías de tests contra varias URLs diferentes del mismo servidor, en lugar de usar la misma URL siempre.

Debemos usar la opción -b para ejecutar los tests sin pausas, con lo que comprobaremos el rendimiento general. Además, podemos indicar el tiempo exacto que queremos ejecutar Siege con la opción -t siguiendo el siguiente formato:
  -t60S (60 segundos)
  -t1H (1 hora)
  -t120M (120 minutos)

Como ejemplo, ejecutaremos la herramienta con el siguiente comando:

siege  -b -t60S -v http://ipmaquina

Lo que usará 15 usuarios concurrentes (el valor por defecto) y estará en ejecución durante 60 segundos.

Con esta herramienta, de todas las medidas que nos ofrece, vamos a recoger: "Availability", "Elapsed time", "Response time" y "Transaction rate".


Metodología: ¿Cómo realizar los tests con las herramientas?

Para realizar los tests debemos generar el tráfico ejecutando la herramienta correspondiente en la cuarta máquina (externa a la granja web), haciendo las baterías de ejecuciones a las siguientes configuraciones:

• una carga concreta a la IP de un servidor solo (puede ser la máquina final M1 o la M2)
• la misma carga a la IP del balanceador teniendo como software de balanceo el nginx
• la misma carga a la IP del balanceador teniendo como software de balanceo el haproxy
• Haremos un mínimo de 5 ejecuciones con ese nivel de carga y con cada configuración, y recogeremos los datos en una hoja de cálculo. Luego calculamos una tabla con medias y desviación estándar para cada uno de los tres casos, y representamos gráficamente estos valores de forma que podamos analizar y comparar adecuadamente los resultados obtenidos, ofreciendo unas conclusiones acerca de lo observado.

Nota 1: Las métricas obtenidas con las herramientas son muy diferentes entre sí, por lo que no debemos comparar lo obtenido con con las herramientas utilizadas. La idea es comparar los resultados de rendimiento entre las tres configuraciones (máquina sola, granja con nginx, granja con haproxy) con cada herramienta. Recordad que vamos a comparar configuraciones, y no herramientas.

Nota 2: Hemos propuesto dos posibles herramientas de las muchas que existen. Para subir la nota de la Práctica 4, buscad otra diferente y utilizadla siguiendo las indicaciones anteriores.

Tema 4 de teoría: Balanceo de carga (SWAP2016)

En este tema comenzamos viendo cómo hace años se usaban grandes mainframes como servidores de todo tipo. Sin embargo, eran máquinas muy caras, tanto para adquirirlas como para mantenerlas. Esto al desarrollo de la tecnología del balanceo de carga.

La idea es poner varias máquinas trabajando en paralelo en lugar de una sola máquina muy grande y cara. De esta forma, si una máquina del cluster (grupo o granja) se rompe, se puede sustituir fácilmente, lo que mejora la robustez, y además las tareas se pueden repartir entre grupos de servidores.

El funcionamiento se basa en el uso de un balanceador que reparte el tráfico web entre varios servidores finales.

Hay diversas opciones para configurar un balanceador, tanto en cuanto dispositivos hardware o software, realizando las siguientes tareas:
 - comprobar la disponibilidad de los servidores
 - protege de diversos ataques
 - derivar en función del tipo de tráfico

Existe software específico para configurar casi cualquier PC como balanceador, estableciendo diferentes algoritmos de reparto de carga. Como ejemplo de software para configurar el balanceo de carga, cabe destacar:
 - HAProxy
 - ngingx
 - Apache
 - Zen Load Balancer
 - Pirhana
 - Pound
 - Ultra Monkey
 - LVS
 - Local Director (cisco)
 - BIG-IP (F5)
 - NLB (Microsoft)

Entre los dispositivos tipo "caja negra", cabe nombrar aquellos que incluyen el hardware y software necesarios para el balanceo (una especie de PC con un software muy concreto y bien afinado), o bien procesadores específicos (ASIC, application specific integrated circuit) para realizar las tareas de modificación de paquetes. Destacan los fabricantes Cisco Systems, Foundry Networks, Nortel Networks, F5 Networks y Radware.

Todos estos balanceadores permiten el uso de varios algoritmos de balanceo de carga diferentes:
 - balanceo basado en turnos (round-robin)
 - balanceo basado en el menor número de conexiones
 - balanceo basado en ponderación
 - balanceo basado en prioridad
 - balanceo basado en tiempo de respuesta
 - combinación de los algoritmos de tiempo de respuesta y menor número de conexiones


Finalmente, existe una tecnología para realizar balanceo de carga global (GSLB, global server load balancing) de forma que se distribuya la carga entre varios centros de datos. La idea es minimizar los retrasos en las comunicaciones por las distancias entre el usuario y los servidores. Esto tiene la ventaja añadida de que si un centro falla, el tráfico se redirige a otro centro de datos (redundancia). Hay varias formas de implementar el GSLB:
 - Uso del sistema de DNS
 - Redirección HTTP
 - GSLB basado en DNS
 - GSLB usando protocolos de enrutamiento

A pesar de la alta disponibilidad que se obtiene usando GSLB, se trata de un sistema muy complejo de implementar. Un problema añadido es mantener el almacenamiento (BD, p.ej.) sincronizado entre los diversos centros de datos.


Como resumen, el balanceo de carga aporta diversos beneficios:

• Escalabilidad: El balanceador distribuye las peticiones de los usuarios entre varios servidores reales, haciendo que la capacidad global de proceso y servicio crezca respecto a un solo servidor.
• Disponibilidad: El balanceador monitoriza el estado de los servidores y las aplicaciones, de forma que si encuentra que uno de los servidores ha fallado, dejará de enviarle peticiones.
• Mantenimiento: El administrador puede apagar una máquina para actualizarla o repararla, y el resto del conjunto seguirá dando el servicio. Posteriormente, la máquina se puede añadir de nuevo cuando vuelva a estar operativa. Además, podemos tener grupos de máquinas configuradas para dar un tipo de servicio (FTP, HTTP, SMTP, etc).
• Seguridad: Puede ser una primera línea de defensa, rechazando varios tipos de ataques. Además, al hacer NAT, protege los servidores finales de accesos desde el exterior.
• Calidad de servicio: Nos referimos al tiempo de respuesta, a la disponibilidad o a la capacidad de ofrecer servicios en función del tipo de usuario.

En clase planteamos los siguientes ejercicios:

• Ejercicio T4.1: Buscar información sobre cuánto costaría en la actualidad un mainframe. Comparar precio y potencia entre esa máquina y una granja web de unas prestaciones similares.
• Ejercicio T4.2: Buscar información sobre precio y características de balanceadores hardware específicos. Compara las prestaciones que ofrecen unos y otros.
• Ejercicio T4.3: Buscar información sobre los métodos de balanceo que implementan los dispositivos recogidos en el ejercicio 4.2
• Ejercicio T4.4: Instala y configura en una máquina virtual el balanceador ZenLoadBalancer. Compara con la dificultad de la instalación y configuración usando nginx o haproxy (práctica 3).
• Ejercicio T4.5: Probar las diferentes maneras de redirección HTTP. ¿Cuál es adecuada y cuál no lo es para hacer balanceo de carga global? ¿Por qué?
• Ejercicio T4.6: Buscar información sobre los bloques de IP para los distintos países o continentes. Implementar en JavaScript o PHP la detección de la zona desde donde se conecta un usuario.
• Ejercicio T4.7: Buscar información sobre métodos y herramientas para implementar GSLB.

La entrega de los ejercicios de clase se realizará en una carpeta llamada "trabajos_de_clase" que cada cual mantendréis en vuestro repositorio de la asignatura en github.com