lunes, 27 de abril de 2015

Charla sobre seguridad

Como parte del Tema 6, dedicado a la seguridad en el sistema, hemos contado con Juan Luis (@jlmacal) que nos ha dado una charla sumamente interesante en la que nos ha contado su experiencia de varios años como experto en seguridad.


Esta charla complementa los contenidos vistos en el tema de teoría, detallando tipos de ataques, vulnerabilidades, herramientas, ¡y otros detalles que ni sospechaba!

En la siguiente URL podéis revisar su PFC (un honeypot casero con Raspberrypi):
    http://www.raspberrypi-spanish.es/foro/viewtopic.php?t=7251
    https://www.youtube.com/watch?v=0ZByaYO0D-w
que está liberado en:
    https://github.com/jlmacal/ZetsuHoneypot


lunes, 20 de abril de 2015

Tema 6 de teoría: Asegurar el sistema web

Asegurar la granja web es una tarea muy importante para cualquier sitio web. Permite saber quién hizo cada cosa y en qué momento, y su objetivo principal es evitar (o al menos dificultar en lo posible) que un hacker malicioso realice cualquier acción que afecte al sistema, sobre todo a los datos de la empresa y la información de los usuarios.

Se trata de asegurar y mejorar la disponibilidad del sitio y también de asegurarse de que las operaciones que se lleven a cabo en el sitio sean seguras, todo basado en los siguientes conceptos:
  • Confidencialidad: las comunicaciones deben ser secretas.
  • Integridad: los mensajes enviados deben ser exactamente los recibidos.
  • Disponibilidad: la comunicación con cualquier aplicación o servicio de la granja web debe estar disponible en el momento en que sea requerida.
En este tema hemos tratado varias cuestiones:

(1) El concepto de defensa en profundidad (diferentes capas de defensa).
La idea es la protección del sistema a diferentes niveles, de forma que un hacker maliciosos deba superar cada una de las capas independientemente para acceder a los datos. Al incrementar el tiempo necesario para superar cada nivel hacemos que sea más probable detectar un ataque, y así evitar que las últimas defensas se vean comprometidas.


(2) Establecer políticas de seguridad, incluyendo claves seguras, para todas las cuentas.
Las políticas de seguridad definen cómo se les permite interaccionar a los usuarios con los servidores y el hardware de la red del sistema web. Todas las políticas definen:
  • Procedimientos de identificación y acceso: comprueban si un individuo es reconocido por los sistemas de seguridad.
  • Privilegios de uso: definen qué acciones puede llevar a cabo cada tipo de usuario correctamente identificado.
Se deben establecer y aplicar políticas a diferentes niveles:
  • Seguridad a nivel físico
  • Seguridad a nivel de red
  • Seguridad a nivel de administrador
  • Cuentas de servicios (o aplicaciones)

(3) Asegurar un servidor mediante la eliminación de servicios innecesarios y vulnerabilidades.
Para asegurar el servidor, debemos seguir un proceso en el que eliminaremos:
  • características no necesarias,
  • servicios,
  • configuraciones e
  • información de seguridad del servidor,
de forma que sólo se dejen las aplicaciones, servicios y puertos realmente necesarios.

Como parte de este proceso, deberemos configurar el cortafuegos adecuadamente.


(4) Usar un cortafuegos: comprender el funcionamiento de los cortafuegos y los beneficios de estos.
Un cortafuegos protege el sistema de accesos indebidos. Es el guardián de la puerta al sistema, permitiendo el tráfico autorizado y denegando el resto. Una máquina cortafuegos bien configurada aportará los siguientes beneficios:
  • 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 (evitamos escaneo de puertos).
  • Avisa de posibles ataques justo en el momento en que se producen.
El software de cortafuegos por excelencia es iptables. En los siguientes tutoriales se encontrará información detallada 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/

(5) Recursos en Internet sobre temas de seguridad
Finalmente, toda organización con un gran sistema web debe tener un equipo de ingenieros con dedicación exclusiva a desarrollar, investigar, responder y arreglar temas de seguridad del sistema a todos los niveles. Es muy importante estar al día en cuanto a temas de seguridad en todos los frentes. Es un trabajo continuo en el que revisar grupos de noticias, listas de correo, blogs y foros sobre estos temas.

El administrador responsable de la seguridad informática debe 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. Cuando se identifica una vulnerabilidad, los administradores de seguridad deben tomar medidas de prevención ya que los hackers estarán atentos para aprovecharla.

Un sitio especializado en seguridad que personalmente me gusta es:
http://www.securitybydefault.com/
En los últimos años han publicado análisis de diferentes tipos de ataques a varias webs, de forma muy didáctica y clara:
Mitigación de ataques DDoS basados en inundamiento
 http://www.securitybydefault.com/search/label/DDoS
Cómo CyberBunker atacó a Spamhaus y casi se llevó a medio Internet por delante
 http://bit.ly/14q7HmK
DDoS contra Movistar.es ¿Causada o preparada?
 http://www.securitybydefault.com/2011/06/ddos-contra-movistares-causada-o.html  
CloudFlare, una posible solución frente a ataques (D)DoS
 http://www.securitybydefault.com/2011/06/cloudflare-una-posible-solucion-frente.html
El caso de Anonymous contra la SGAE (ACENS)
 http://www.securitybydefault.com/2010/10/como-se-defendio-la-sgae-de-anonymous.html
Por supuesto, buscando en Internet encontraremos foros, blogs, etc con mucha más información:
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/
Además, en YouTube existen vídeo-tutoriales sobre temas de seguridad en servidores web. Como ejemplo, cabe destacar el siguiente canal:
https://www.youtube.com/watch?v=w0SB6eAnx4Q&list=PL7C849047272B22E0

En cuanto a los ejercicios que vamos planteando en los temas de teoría, en este tema hemos planteado 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.
Como ya indicamos, la entrega de los ejercicios de clase se realiza en el repositorio personal que cada cual mantenéis en github.com, en una carpeta que podéis llamar "ejercicios_de_clase".

Tema 5 de teoría: Medir prestaciones

En este tema hemos estudiado cómo medir las prestaciones de nuestro sistema web con el objetivo de comprobar si cumplen unos mínimos requisitos de rendimiento.

La idea de hacer los tests no es exclusivamente detectar las caídas o errores de programación, sino los problemas de rendimiento y degradación de recursos, así como detectar posibles cuellos de botella e ineficiencias.

Partimos de que los tests presentan ciertas limitaciones:
  • Dificultad para hacer pruebas en un entorno de producción.
  • No se puede simular el comportamiento de los usuarios.

Según el sitio web, usaremos diferentes métricas:
  • Conexiones por segundo: Hace referencia al número de conexiones de entrada que cierto dispositivo puede manejar por segundo. También se llama transacciones por segundo o sesiones por segundo. Es un factor determinante, ya que abrir y cerrar conexiones HTTP resulta muy costoso, ya que las aperturas y cierres de conexiones consumen muchos recursos.
  • Número total de conexiones concurrentes: Métrica para determinar cuántas sesiones de usuario TCP puede manejar el balanceador al mismo tiempo. Limitado por la memoria o el procesador del dispositivo.
  • Rendimiento (en bits por segundo): Hace referencia a la velocidad a la que el balanceador maneja y pasa el tráfico. Todos los dispositivos tienen una serie de factores que acaban limitando las prestaciones, basados en la estructura interna (hardware y software). Se mide en bits por segundo. Es combinación de las variables "tamaño del paquete" y "paquetes por segundo". El paquete típico tiene un tamaño máximo (MTU, Maximun Transmitable Unit) de 1.5KB. Si hay que enviar más datos, se trocean en paquetes de este tamaño máximo.

Hemos estudiado diferentes tipo de tráfico, con características particulares y métricas más importantes al analizarlos:


Existe un límite de tráfico de red suficientemente alto que produce una degradación grave en las prestaciones. En unos casos ese límite es más fácil de alcanzar que en otros. Llegado a ese límite los tiempos de respuesta en las conexiones HTTP se degradan completamente, haciendo imposible la conexión. Cuando se monitoriza el sistema, este comportamiento se ve claramente representado en gráficas de la evolución del sistema como la siguiente:


Finalmente, como vimos, necesitamos herramientas para crear cargas HTTP específicas y evaluar cómo se comportan diferentes configuraciones de nuestros sistemas. Se suelen usar benchmarks como SPECweb o WebStone para simular un número determinado de clientes.

En sistemas críticos, en lugar de usar (o desarrollar) una herramienta para generar la carga para los tests, se le puede encargar a una empresa externa especializada, como:
  • Micro Focus Intl. - Segue Software (SilkPerformer)
  • HP (LoadRunner)
  • Micro Focus Intl. - Compuware (QALoad)
  • Rational (SiteLoad)
  • Radview (WebLoad)

Se realizan 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. Se ejecutan 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.

Durante la ejecución de esas pruebas, se recogen mediciones que nos indiquen lo que está ocurriendo en el sistema en cada momento y cómo reacciona éste en función de la carga introducida:
  • Medidas de la calidad de servicio ofrecida por el sistema a los usuarios (estadísticas proporcionadas por la misma herramienta de simulación de carga)
  • Medidas relativas al consumo de recursos del sistema (utilizando las herramientas del sistema operativo)

Como herramientas de simulación de carga cabe destacar:
  • 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 que le hayamos hecho.


En cuanto a los ejercicios que vamos planteando en los temas de teoría, en este tema hemos planteado 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 características, disponibilidad para diversos SO, etc de herramientas para monitorizar las prestaciones de un servidor.
Como ya indicamos, la entrega de los ejercicios de clase se realiza en el repositorio personal que cada cual mantenéis en github.com, en una carpeta que podéis llamar "ejercicios_de_clase".

viernes, 10 de abril de 2015

Script PHP para la PRÁCTICA-4 (para que las peticiones sean muy costosas)

En la Práctica 4, para que a los servidores finales les cueste más trabajo servir los miles de peticiones que haremos con las herramientas de generación de tráfico, podemos usar una página HTML estática, o bien un script PHP que suponga más trabajo por petición.

Podemos crear uno que ejecute un bucle de varios millones de vueltas mientras hace varias operaciones aritméticas. Eso puede tardar dos o tres segundos por petición, lo que es mucho para un servidor cuando se le hagan muchos miles de peticiones al script.

Si con una página HTML estática pequeña el servidor solo no experimenta problemas por alta que sea la carga aplicada con las herramientas, se puede usar un script similar al siguiente:
<?php
$tiempo_inicio = microtime(true);
for ($i=0; $i<3000000; $i++){
 $a = $i * $i;
 $b = $a - $i;
 $c = $a / $b;
 $d = 1 / $c;
}
$tiempo_fin = microtime(true);
echo "Tiempo empleado: " . round($tiempo_fin - $tiempo_inicio, 4) ;
?>

Comenzamos la Práctica 4

Para medir el rendimiento de un servidor necesitaremos una herramienta que ejecutar en una o varias máquinas "clientes" para crear una carga HTTP específica. En algunos casos, las medidas se realizan con benchmarks como SPECweb o WebStone para simular un número determinado de clientes. Puesto que el número de usuarios de un servidor web puede ser del orden de los millones de usuarios, queda claro que simular un número pequeño de clientes no es realista. Sin embargo, en algunos entornos, no nos quedará más remedio que usar herramientas que generan el tráfico.

Existen diversas herramientas para comprobar el rendimiento de servidores web. Las hay basadas en interfaz de línea de comandos y de interfaz gráfica. Entre las más utilizadas destacan:
  • Apache Benchmark
  • httperf
  • openwebload
  • the grinder
  • OpenSTA
  • JMeter
Con ellas podemos comprobar el rendimiento de un servidor web, ya sea del hardware o software, o de alguna modificación que le hayamos hecho.

Lo habitual es usar programas de línea de comandos que sobrecarguen lo mínimo posible las máquinas que estamos usando. Es importante usar siempre la misma máquina "cliente" para hacer las ejecuciones que generan el tráfico (la cuarta máquina, a la derecha en la siguiente imagen, en la que se ejecutan los benchmarks). Además, esa máquina tiene que ser independiente de las que forman la granja web. Podemos crear una cuarta máquina virtual o bien usar un terminal en nuestro ordenador anfitrión.


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):

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


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; 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".

¿Cómo realizar los tests con "ab"?
Para realizar los tests con ab, debemos generar el tráfico en la cuarta máquina (externa a la granja web) y hacer baterías de ejecuciones a las siguientes configuraciones:
  1. una carga concreta a la IP de un servidor solo (puede ser la máquina final M1 o la M2)
  2. la misma carga a la IP del balanceador teniendo el nginx como software de balanceo
  3. la misma carga a la IP del balanceador teniendo el haproxy como software de balanceo
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.


httperf

httperf es otra herramienta para medir el rendimiento de sitios web. Originalmente se desarrolló en los laboratorios de investigación de Hewlett-Packard.

Para llevar a cabo un test, debemos ejecutarla en los clientes (recordemos que son máquinas independientes a las que forman la granja web). Si tenemos varios clientes, deberíamos hacer la ejecución en todos simultáneamente.

Como ejemplo de comando de ejecución:
httperf --server ipmaquina --port 80 --uri /prueba.html \
   --rate 150 --num-conn 27000 --num-call 1 --timeout 5
Por la forma en que genera el tráfico, siempre que usemos los mismos parámetros tardará el mismo tiempo en la ejecución (a diferenca del ab).

Con esta herramienta, de todas las medidas que nos ofrece, vamos a recoger: "Total connections", "replies", "Request rate" y "Errors total".

OpenWebLoad

Es otra herramienta de línea de comandos para medir el rendimiento de servidores web.

Si queremos simular diez clientes simultáneos, la ejecutaremos con:
openload ipmaquina 10
Hay dos parámetros (se parecen mucho a los de las herramientas anteriores): la URL de la página en el servidor a evaluar, y el número de clientes simultáneos que simularemos.

Con esta herramienta vamos a recoger las siguientes medidas: "Total TPS", "Avg. Response time" y "Max Response time"


Nota 1: Las métricas obtenidas con las tres 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.

Nota 2: Hemos propuesto tres herramientas de las muchas que existen. Si conocéis alguna otra diferente, o queréis usar otra diferente a las descritas aquí, hacedlo con total libertad.


miércoles, 8 de abril de 2015

Visita al Centro de Supercomputación de la UGR

Esta mañana (8 de abril) hemos realizado la visita al CSIRC, al Centro de Supercomputación de la UGR.

Hemos comenzado con una presentación por parte de Rafael y Santiago detallándonos los recursos informáticos del Centro a lo largo de los años, deteniéndose en los actuales.



A continuación hemos bajado a la sala donde están las máquinas. Hemos podido entrar en los pasillos fríos (por los que entra el aire frío para refrigerar las máquinas) y los calientes (a los que sale el aire muy caliente de las máquinas y de donde se recoge para sacarlo a las máquinas enfriadoras):








En la sala contigua están las máquinas enfriadoras, los sistemas antiincendios y las acometidas eléctricas:




Me gustaría agradecer al personal del CSIRC, especialmente a Rafael y a Santiago, su amabilidad a la hora de organizar la visita y durante la misma. Como siempre, han sido muy atentos con todos, contestando todas las dudas, explicándonos todos los detalles, y contándonos diversas curiosidades de las máquinas, de las configuraciones y del mismo CPD.