NUBE ABIERTA – OPENSTACK – ESPAÑOL

NUBE ABIERTA – OPENSTACK

Hoy iniciaremos una serie de artículos para explicar que es OpenStack, como está compuesto, como se puede utilizar para generar mayor valor y por qué desde hoy es una buena idea para las empresas en crecimiento adoptar esta tecnología que es robusta, probada y con un costo mucho menor que las mayormente comercializadas por las marcas líderes.

A

 

¿Qué es OpenStack?

Es un proyecto que involucra varias  tecnologías de código abierto que busca entregar de un sistema operativo cloud escalable. Que permite gestionar y controlar las capacidades de cómputo, almacenamiento, sistemas operativos y recursos de red de nuestra infraestructura.

 

 

¿Cuándo empezó?

B

 

 

 

 

Este proyecto tuvo sus Orígenes con la NASA y Rackspace quienes empezaron con NOTA y Swift.

 

 

 

Bases Fundamentales y Gobierno de OpenStack

  • Licencia Apache 2.0, para Desarrollo abierto.
  • Diseño abierto de procesos.
  • Código abierto disponible a todo el público mediante un repositorio de código
  • Comunidad abierta transparente en procesos y documentos.
  • Compromiso de adopción de estándares abiertos
  • Diseño modular para despliegues flexibles vía APIs .

Basada en una fundación que garantiza los principios y objetivos del proyecto, así como su gobernanza y su independencia

C

E

Componentes de OpenStack

Como hemos mencionado OpenStack es una colección de proyectos de software libre.

A continuación se mencionan los componentes iniciales y más importantes de OPenStack:

 

  • OpenStack Compute, con nombre Nova.
  • OpenStack Object Storage, con nombre Swift.
  • OpenStack Image Service, con nombre Glance.

G

  • Compute (Nova): es el controlador de la estructura básica del Cloud. Es el encargado de iniciar las instancias (máquinas virtuales) de los usuarios y grupos. También es el servicio encargado de la gestión de la red virtual para cada instancia o para las múltiples instancias que formen parte de un proyecto (tenant).

 

  • Object Storage (Swift): Se trata del módulo encargado de almacenar los archivos del sistema, asegurar su integridad y replicarlos por los diferentes discos que encontramos en la infraestructura, para que éstos siempre estén disponibles y accesibles de la forma más rápida posible.

 

  • Servicio de Imagen (Glance): Con Glance dispondremos de un servicio de gestión de imágenes, y no nos referimos a imágenes tipo fotografías, si no a imágenes que serán copias íntegras de las unidades de disco duro de las que dispongamos

 

Con el paso del tiempo se van agregando y a continuación te menciono los componentes que debes tener presente para cuando decidas implementar OpenStack

 

  • Dashboard (Horizon); Aquí tenemos el primer módulo que ve todo aquel que se inicia en OpenStack, el que se encarga de mostrarnos mediante una interfaz gráfica toda la gestión de OpenStack, desde donde podremos ver qué está pasando en nuestra nube y gestionar cualquier incidencia que surgiese

 

  • Telemetría (Ceilometer): Nos ofrece servicios de telemetría con los que podremos monitorizar el uso de cada usuario en nuestra infraestructura, así como facturar individualmente por dicho uso.

 

  • Block Storage (Cinder: Este módulo se centra en el almacenamiento de la forma más tradicional en que conocemos la palabra. Nos facilitará acceso al contenido alojado en las unidades de disco que se encuentren en nuestra cloud.

 

  • Orquestación (Heat): Heat nos permitirá almacenar los requerimientos de una aplicación que sirvamos desde nuestra nube, en un archivo que define los recursos necesarios para dicha aplicación. Lo que básicamente viene siendo que nos ayudará a establecer los requisitos de una infraestructura en función de las apps que alojemos en ésta.

 

  • Servicio de Identidad (Keystone): Este servicio controlará la identificación de los diferentes usuarios que se conecten a nuestra infraestructura, y el acceso a según qué servicios o aplicaciones de los mismos.

 

  • Networking (Neutron): Que cada módulo de OpenStack se comunique con otro y estén interrelacionados, es gracias a Neutron, que se encarga de que cada componente desplegado en OpenStack encuentre a sus “vecinos”.

 

  • Base de datos (Trove): Trove es una base de datos que funciona como un servicio de aprovisionamiento de motores de bases de datos relacionales y no relacionales.

 

 

A través de estos componentes, OpenStack proporciona una completa plataforma operativa para la administración y gestión de clouds.

 

Con esto OpenStack proporciona el poder desplegar de forma sencilla, escalable, elástica y de cualquier tamaño, tanto clouds públicos como clouds privados.

 

A continuación el historial de como van evolucionando los componentes:

l

 

Arquitectura conceptual

Desde una perspectiva global, OpenStack está diseñado para “entregar un sistema operativo para el despliegue de clouds masivamente escalables”. Para poder lograrlo, cada uno de los servicios que conforman OpenStack están diseñados para trabajar conjuntamente y poder proporcionar una Infraestructura como Servicio (IaaS, Infrastructure as a Service) completa. Esta integración se consigue a través de APIs (Application Programming Interfaces) que cada servicio ofrece, y que cada servicio puede consumir. Mientras que estas APIs permiten a cada uno de los servicios utilizar el resto, también permiten al desarrollador poder reemplazar cualquier servicio con otra implementación, siempre y cuando se respeten estas APIs. Dichas APIs también se encuentran disponibles para el usuario final del cloud.

 

Conceptualmente, se pueden representar las relaciones entre los servicios a través del siguiente diagrama:

H

G2

 

Agilidad en Actualizaciones de Open Stack.

  • OpenStack libera una versión cada 6 meses
  • se integran miles de commits, correcciones y parches
  • se coordinan cientos de desarrolladores
  • se añaden nuevos proyectos (servicios y funcionalidades)

 I

 

En los siguientes artículos definiremos cada uno de los componentes de OpenStack.

 

 

Fuentes:

https://wiki.openstack.org

https://en.wikipedia.org/

http://ken.pepple.info/

WEB APPLICATION FIREWALL

WEB APPLICATION FIREWALL

 

Si cuentas con aplicaciones WEB y crees que con tener un firewall con todos sus componentes de seguridad instalado ya estas seguro, lamento decirte que estas equivocado y que necesitas una protección especializada para aplicaciones WEB y esto es un WAF (Web Application Firewall)

w1

 

¿Qué es?:

Los WAF son un tipo de firewall que se utilizan para controlar el acceso a una aplicación o servicio web. A diferencia de un firewall tradicional, un IPS o IDS, la ventaja de un WAF es que opera sobre la capa de aplicación (capa 7 del modelo OSI), por lo que es posible considerar algunos tipos de protecciones más allá de las tradicionales con los dispositivos mencionados.

Básicamente nos permite evitar (entre otras) los siguientes ataques:

  • Cross-site scripting que consiste en la inclusión de código script malicioso en el cliente que consulta el servidor web.
  • SQL injection que consiste en introducir un código SQL que vulnere la Base de Datos de nuestro servidor.
  • Protege ataques dirigidos al servidor web que los IDS/IPS no pueden

 

 

¿Porqué Requerimos un WAF?

Los Firewalls tradicionales trabajan en la capa de red pero no ofrecen ninguna clase de protección contra los ataques especializados en explotar vulnerabilidades web.

 

¿ Cómo funciona?:

El WAF Niega por defecto todas las transacciones y solo acepta las que considera seguras. La definición de seguridad la recoge de una serie de reglas preestablecidas que se definen bien por auto-aprendizaje o bien por configuración manual.

  • Protege sus servidores web contra manipulaciones e intentos de ciberataques
  • Analizar las variables que llegan por GET o POST, detectando así un buffer overflow.
  • Puede analizar que los valores pasados por GET o POST no contengan valores usados por Cross Site Scripting o SQL Injection como “select from”, “unión”, “concat”, etc.
  • Soportan las siguientes características: caching, compresión, aceleración SSL, balanceo de carga y pooling de conexiones.
  • Es muy importante tener en cuenta que si nuestra aplicación utiliza caracteres “extraños”, tendremos que configurar el WAF para que no esté incluidos en su “lista negra” o bien rediseñar la aplicación web para evitar estos caracteres.

 

Diferencias entre IPS y WAF

El IPS(Intrusion Prevention System) Escanea los paquetes que viajan por la red. Actúa de forma similar al IDS (Intrusion Detection System), comparando los datos de los paquetes de la red con una BD de firmas o detectando anomalías en lo que se le ha definido como “trafico normal”. Se diferencia del IDS en que el IPS además de recoger logs y alertas, se puede programar para reaccionar ante lo que detecte. Por este motivo es más completo que el IDS.

Un IPS es capaz de proteger ante determinado tipo de ataques para aplicaciones web; sin embargo el WAF, al ser una herramienta especializada, permite un mayor control para web exclusivamente, llegando donde el IPS no llega, incluso para el tráfico HTTPS (en configuraciones especiales), para aplicaciones web “hechas en la casa” (para las que el IPS no tiene firmas específicas y lo pueda generar falsos positivos).

Mientras que IPS compara el tráfico con patrones y anomalías, WAF examina el comportamiento y la lógica que se está enviando y devolviendo.

 

A continuación un diagrama General de cómo debe lucir la configuración en tu empresa.

 

 

w2

 

 

A continuación se muestra que es lo que los WAF comprueban:

Normalización de URL (modelo de seguridad positiva): controlar el tamaño de los nombres y de los valores de los parámetros y de las cabeceras, de manera que no excedan lo permitido en la RFC de HTTP. Permitir los métodos HTTP estándar (GET y POST) y prohibir los extendidos (HEAD, OPTIONS, métodos WebDav, etc…). Eliminar los diferentes posibles Encodings o Decodings de los parámetros (mecanismos de evasión ante IPS o WAF). Deshacer los posibles intentos de Directory Traversal eliminando las repeticiones de “..\..\”, etc,…

Lista Negra (Modelo de Seguridad Negativa): Si la petición llega siendo “sana”, enfrentamos la petición contra una serie de expresiones regulares referidas a ataques conocidos contra aplicaciones comunes (OWALotus NotesSAPHorde, etc,… ) de manera que si en algún caso hacen “pattern matching” contra alguna expresión de la lista se denegará dicha petición. Esto puede generar gran cantidad de falsos positivos debido a que aplicaciones que puede que no sean vulnerables al ataque de la lista pero que coincidan con una expresión regular, provoquen una denegación de servicio. Asimismo, las listas negras no son un mecanismo óptimo para detener ataques del tipo SQL injectionXSS (Cross-Site Scripting), command injection. Un ejemplo muy claro de esta limitación sería por ejemplo un parámetro en una GET de la manera “index.php&action=drop“. En esta situación, una lista negra excesivamente estricta provocaría un bloqueo puesto que “drop” puede conllevar el borrado de una tabla de una base de datos, por lo que debería vetar el acceso.

Lista Ponderada (o Scoring List): Este mecanismo de análisis de tráfico funciona de manera similar a un antispam. Pertenece al modelo de seguridad negativa. Asigna pesos a aquellas porciones de la petición web de manera según tenga definidos en una tabla de scoring. Finalmente si la suma de los diferentes pesos asignados a una petición supera un determinado umbral, la bloquea. En el caso anterior, si suponemos que el umbral de bloqueo es 1, y asignamos 0.30 a la cadena “drop”, la dejaría pasar. Sin embargo, en una petición de la forma “index.php&action=’;drop * from data;–” al asignar 0,30 a “drop”, 0,50 a “*” y 0,30 a “from” y 0,20 a “-“, tendríamos 0,3 + 0,5 + 0,3 + 0,2 + 0,2 = 1,5 > 1 por tanto bloquearía el intento de SQL injection. De esta forma tenemos una forma mucho más “inteligente” de bloquear este tipo de ataques. El único WAF que conocemos que incorpore este sistema de análisis es rWeb de DenyAll.

Lista Blanca (modelo de seguridad positiva): Para determinado tipo de aplicaciones en las que el formato de los parámetros de entrada en las GET o POST no varíe muy a menudo, puede resultar interesante definir dicho formato a nivel de lista blanca, de manera que sólo aquellas peticiones que encajen ante dicha plantilla podrán acceder a la aplicación, denegándose todas las demás opciones.

 

 

 

 

 

Marco Antonio Morales Romero

Twitter: @MMoralesRomero

 

 

Referencias:

http://wiki.elhacker.net/seguridad/web/introduccion-a-los-web-application-firewalls-http://www.securitybydefault.com/2008/08/proteccin-de-aplicaciones-web-mediante_26.html