sábado, 21 de mayo de 2016

Vmware vShield endpoint vs NSX

VMWare vShield inicialmente nació como un firewall para los hipervisores de VMWare, con el tiempo se le ha dotado de numerosas capacidades y modalidades como App, Edge, Zones, Manager...y en concreto una de ellas que se ha explotado por las compañías que desarrollan software antimalware : EndPoint.

vShield EndPoint evita la necesidad de desplegar agentes antivirus en las VMs que se ejecutan sobre el host desplegando una app o vm que accede por medio de las APIs a las capas del hipervisor para analizar el tráfico. Esta solución es altamente interesante ya que simplifica la gestión de las plataformas de antivirus y nos evita el consumo de recursos innecesario en las VMs y los posibles problemas que un antivirus pueda ocasionar.

Además de que todo esto pinta bien, VMWare lo borda cuando libera el acceso a los partners y además no requiere licencia adicional de uso.  Con estos parámetros las compañías que desarrollan software antimalware lanzan sus productos incidiendo en esta solución (trend Micro, kaspersky...) ofreciendo funcionalidades adicionales como patching de sistemas operativos en VM, ... , la panacea de un administrador de sistemas... no?

Pues hasta ahora sí, pero parece que todo cambia cuando se mira de cerca... Si buscáis vShield en VMWare aparecen muchos documentos pero en el porfolio principal en el apartado de networking y seguridad sólo aparece NSX... y vshield?. vShield sigue integrado en las ediciones de vSphere pero si seguimos indagando vemos que vShield desaparecerá este año para ser sustituido por NSX.

El problema de NSX es que aún  no sabemos si es apto para todas las organizaciones, ni siquiera podemos obtener un precio y muchos partners no tienen acceso a descargar el software para probarlo, sólo algunos elegidos.

Entonces... qué pasa con estas soluciones antimalware basadas en vShield EndPoint?. Pues ya está pasando varias cosas...
  • La primera es que se han adaptado para trabajar bajo NSX ,perfecto es el futuro, pero todas las organizaciones con independencia de su tamaño podrán ir a NSX?
  • La segunda es que el despliegue de VMs sin antivirus ya es un problema con vSphere 6 pues requiere la instalación de un agente adicional en la VM.Si ya estamos en un entorno de este tipo no veo mayor problema pero si ya tenemos un despliegue de antivirus en VMs qué ganamos con esta solución?
  • La tercera es que podemos apreciar que hay partners que con la excusa de la ciberseguridad se atreven a vender soluciones de este tipo sin explicar y,  lo peor, muchas veces sin conocer los puntos que hemos abordado previamente, asesorando a clientes finales de las bondades de una solución (que las tiene y muchas) pero con un futuro incierto a corto plazo y sobre todo que puede cargar de costes altos y no necesarios a las empresas finales.





sábado, 14 de mayo de 2016

Industria 4.0 : De qué estamos hablando?

Impacto mediático

No hay duda, Industria 4.0 es el término de moda, como lo fue Big Data no hace tanto. por cierto, ¿Alguien se acuerda del brutal impacto que tuvo en la prensa diaria este término?, y ahora?.

La feria de Hannover ha sido el último catalizador mediático popular, llegando al punto álgido con la presencia del presidente de los EEUU, Barack Obama, y la canciller alemana Angela Merkel. Una buena función comercial.


Al igual que pasó con Big Data, la historia se repite, no hacemos más que oír hablar de Industria 4.0 a todos y , como siempre, no todos tienen claro de qué están hablando, es más muchos ni se acercan a la esencia, complejidad e implicaciones reales que este término conlleva, sin embargo deben vender sus productos y servicios bajo esta marca, pues es cool.

¿Qué es Industria 4.0?

Una definición de tantas podemos encontrarla en la propia Wikipedia, en ella obtenemos algunas claves y hechos necesarios para entender el término promocionado por el gobierno alemán, pero lo que de verdad define el objetivo es el cambio de paradigma industrial, la cuarta revolución Industrial.


Recordemos que la primera revolución industrial surge con el empleo de la mecanización de los trabajos industriales gracias a los avances en las máquinas de vapor, la segunda revolución llega con el cambio de los procesos hacia una producción en masa utilizando sistemas de montaje en línea y utilizando electricidad, la tercera es en la que estamos, surge con la aplicación de sistemas computerizados en procesos industriales.

El paradigma de la cuarta revolución industrial es conseguir la fábrica inteligente (Smart Factory), un concepto pretencioso aunque asequible a futuro. Es altamente probable que hayan elegido un término de marketing (Smart) cuando realmente debería haberse decantado por otro más asequible:  Auto, es decir, conseguir la autogestión y control de la fábrica en los procesos de fabricación, control y calidad llegando hasta la relación con los clientes y proveedores.

Cuales son los objetivos que persigue?

No hace falta decirlo pero el factor beneficios siempre es la clave tanto para las empresas que venden tecnología como para las que la compran para producir de modo más eficiente, es un hecho que los procesos asistidos por ordenador han logrado reducir costes de forma significativa incidiendo principalmente directamente en varios frentes:
  • Reducción de la mano de obra necesaria para desarrollar la fabricación
  • Producción intensiva, masiva y uniforme
  • Automatización de los controles de calidad sistemáticos
Si bien todo esto ya existe y está desplegado en muchos procesos industriales, también es cierto que las empresas son algo más que sus procesos productivos, son las relaciones con sus clientes, proveedores, estados, los flujos de comunicación interna ..., algo que está bajo el paraguas de las tecnologías de la información. Estas relaciones son altamente dinámicas y extremadamente críticas para el funcionamiento de la empresa (qué supone para un organización estar sin correo, internet , servicio en general durante un breve periodo de tiempo?). Este dinamismo mutuo entre las organizaciones y las tecnologías de IT ha hecho crecer y desarrollar sobremanera la cantidad de tecnologías disponibles y expandirlas como algo propio del núcleo de la empresa (redes, bbdd, dispositivos,...)

Desde la irrupción de las tecnologías de la información a escala masiva se ha creado una bicefalia entre lo que hoy se llama IT (Information Technology) y OT (Operations Technology). Dos mundos históricamente separados... pero realmente separados como todos hemos sufrido alguna vez. Sin embargo la capacidad de adaptación existente en IT así como las tecnologías manejadas son algo nuevo para el personal de  OT, los perfiles de OT no están preparados para afrontar avalancha de requerimientos que les imponen (bastante tienen con mantener y afinar el proceso no?), por otra parte el personal de IT ya conoce y utiliza desde hace tiempo las herramientas necesarias para afrontar estos requisitos aunque hay que bajar a planta para sentir las características propias de este entorno, que las tiene y muchas.

Y aquí es donde está la verdadera clave de Industria 4.0, señores, hay que "unir" estos dos perfiles y permitir que los datos fluyan entre ambos mundos y además de modo bidireccional y no, no estamos hablando de MES, estamos hablando de integración de los procesos productivos dentro del ecosistema informático de la empresa, la empresa es todo: redes, sistemas, gestión, producción, calidad.Merece la pena leer el artículo "IT vs OT: Bridging the divide" de 2013 donde explica claramente de qué estamos hablando.

Una vez dispongamos de esta integración podremos pensar en Smart y automatizar aún más los procesos volviéndolos proactivos, reflexivos y abiertos al exterior, incidiendo de nuevo en los tres factores expuestos inicialmente, nada más que eso.

Y para alcanzar este paradigma ... qué se necesita?

Pues lo primero y más difícil no son las tecnologías...no, es disponer del apoyo directo de la dirección en la definición y consecución del objetivo, sin este apoyo no será posible afrontar los cambios necesarios, que los hay, ni delegar responsabilidades entre los mundos de IT y OT.

La creación de un equipo multidisciplinar es el segundo punto, IT y OT han de converger sí, pero ya converger en IT es algo complicado, verdad? (¿alguien sabe de todo: sistemas, redes, BBDD, ...?), una vez definido el equipo de IT , OT ha de hacer lo mismo, podremos empezar a hablar aunque falta el tercer factor, el funcional. Sólo las áreas productivas y de calidad saben lo que es realmente importante en el proceso y deben formar parte del equipo.

Pero hablar de qué?,.. pues de integración de ambos sistemas, nada más y nada menos y aquí entran las tecnologías de IT, las tecnologías de proceso de OT y la experiencia de producción y calidad en determinar la importancia de la información que debe fluir.

Hace no muchos años (meses?), la gente de IT se veía denostada por la gente de OT, incluso en grandes eventos de Allen Bradley y Siemens esta separación se repetía cada segundo, "¿qué hace una persona de IT aquí?, esto no es para ellos, nosotros somos la parte seria que maneja el núcleo de la empresa", cual no es mi sorpresa, cuando tras muchos años navegando entre ambos mundos, parece industria 4.0 y se cambia el sentido de tal modo que ahora somos la posibilidad de salvación, "...hablamos de integración IT-OT es fundamental, pero es difícil encontrar personas que tengan la posibilidad de hablar en los dos mundos...hay que crearlas". No, señores, no hay que crearlas, hay que formar a personal de IT en las características propias de los procesos y de OT, que las hay, pero no son tan diferentes de las que estamos lidiando desde hace muchos años. Personalmente no deja de asombrarme oír hablar de grandes avances en productos, comunicaciones y seguridad de PLCs por gente que no tiene nada claro lo que está diciendo (IP pública/Privada por ejemplo) y que ya hemos sobrepasado hace mucho tiempo en IT, cuando existen equipos con Windows 95 e incluso OS2 críticos en más de una organización, cuando la conciencia de seguridad (security, no safety) les acaba de explotar en la cara...pero esto es otra historia.

 Si ya disponemos de este equipo y conocemos el entorno fabril hay que componer el puzle objetivo y esto empieza, por la definición de las tecnologías que debemos usar en los siguiente ámbitos:

  • Redes de comunicaciones
  • Sistemas
  • Aplicaciones y BBDD

y ... Oh! sorpresa, debemos empezar por piedra angular de todas ellas, las redes de comunicaciones.


lunes, 9 de mayo de 2016

Despliegue de un sistema de mensajería instantánea sobre Windows (III): Zabbix

OpenFire y Zabbix

Zabbix se puede configurar como un cliente XMPP por lo que las alertas se pueden automatizar para que se envíen directamente al servidor OpenFire y ser recibidas por un grupo de usuarios.

Este era uno de nuestros objetivos principales a la hora de realizar el despliegue de este sistema, ser conscientes de las alarmas provenientes de nuestros sistemas de monitorización.



Nota: Se han detectado problemas con la versión 4.0.2, sin embargo la versión 3.6.4 funciona perfectamente para este propósito.

Configuración del servidor

Antes de nada, Zabbix debe estar preparado para gestionar mensajería XMPP, esto se realiza en tiempo de configuración del servidor y antes debemos instalar las librerías necesarias de Jabber:

sudo apt-get install libiksemel3 libiksemel-dev libiksemel-utils

Y en el momento de configuración y build de la distribución debemos indicar la inclusión de Jabber:

./configure --enable-server --enable-agent --enable-proxy --with-mysql --with-net-snmp --with-jabber --with-openipmi --with-libcurl


Zabbix: Configuración de Media type 

Media Type o definición de medios de comunicación con los usuarios que Zabbix empleará:


Antes de la arroba el nombre de usuario de jabber y tras la arroba el nombre del servidor Jabber que hemos instalado.

Zabbix: Configuración de grupos

Las alertas se podrían enviar identificando a cada usuario individualmente, sin embargo la presencia de los grupos facilita en gran medida la gestión de alarmas y sobre todo la discriminación de usuarios por tipo de alarma.

Podemos generar cuantos grupos queramos y asociar a los usuarios a ellos, es a cada grupo al que le atribuimos las alarmas que le llegarán, por lo tanto podemos tener diferentes ámbitos de alarmas para diferentes grupos (por localización, por severidad, por tipo de dispositivo....).

Configuramos un grupo en el que incluiremos los usuarios que deben recibir las alertas vía Jabber.



Zabbix: Configuración de usuarios

Debemos añadir la dirección de IM a los usuarios de Zabbix, esta es la dirección que nos ha asociado el servidor openFire.


Zabbix: Configuración de triggers

Por último sólo resta configurar los triggers para que se envíen por medio de jabber, esto lo hacemos por medio de las actions :


En la pestaña conditions podemos establecer condiciones de envío de los eventos, en este caso por severidad del trigger:


Finalmente indicamos el grupo y tipo de envío (Jabber)



Con estas opciones comenzaremos a recibir las alertas de zabbix en nuestro cliente spark como una difusión.

Enlaces artículos anteriores:

Despliegue de open Fire
Spark

miércoles, 4 de mayo de 2016

Despliegue de un sistema de mensajería instantánea sobre Windows (II) : Spark

Cliente Jabber : Spark

Spark es el cliente de mensajería instantánea (XMPP) de ignite Realtime (http://www.igniterealtime.org/downloads/index.jsp), se trata del complemento perfecto para openFire.

Al igual que para OpenFire existen versiones para Windows, Linux y Mac.

Es un cliente sencillo pero altamente configurable, permite establecer diálogos entre integrantes del mismo dominio de mensajería así como incorporarse a salas (Rooms) definidas.

Obviamente debemos centrarnos mucho en los permisos de acceso que adjudiquemos para no dejar cabida a brechas de seguridad.

Incorpora funciones interesantes como posibilidad de configurar proxy, SSO y una opción interesante que es el login automático, con esta última opción no tendremos la necesidad de loggearnos con cada inicio del PC.

Pantalla de Login

Pantalla principal

ChatRoom


Gestión de avatares

El avatar es la imagen que aparecerá en nuestro usuario.




Para que un usuario pueda modificar su avatar (imagenes) se debe configurar previamente en la consola de openFire la propiedad ldap.override.avatar a true



Con esto permitiremos que el usuario pueda cambiar su imagen

En la siguiente entrega nos centraremos en la integración de OpenFire con Zabbix utilizando Spark como cliente de IM

Acceso a la entrega anterior : Despliegue de OpenFire


lunes, 2 de mayo de 2016

Despliegue de un sistema de mensajería instantánea sobre Windows (I)

Descripción

Nuestro objetivo es el despliegue de un sistema de mensajería instantánea open source en entorno Windows.

En concreto pretendemos con este post desplegar openFire de Ignite Realtime en nuestra red, openFire es un sistema de sistema de mensajería instantánea open source compilado para varios sistemas operativos, entre ellos Windows.


¿Para qué necesitamos un sistema de mensajería instántanea dentro de nuestra red?

La respuesta obvia es para facilitar la comunicación entre los integrantes de un grupo, en el caso de los departamentos de IT puede ser una herramienta extremadamente útil en casos de deslocalización física , casos en que el correo es demasiado lento para ser tratado con celeridad.

Otra ventaja de un sistema de este tipo es la recepción de alarmas de monitorización de sistemas. El gran problema de estos sistemas es saber qué algo está sucediendo y que las personas adecuadas han recibido las alarmas, derivando la salida de las alarmas de monitorización a este sistema nos aseguramos que la comunicación llega en tiempo.

En la última parte del artículo veremos como integrar Zabbix con el servidor openFire.

OpenFire/Spark

OpenFire es el servidor de mensajería instantánea y chat open source (Apache License) desarrollado por Ignite Realtime, este servidor implementa el protocolo estándar XMPP (Extensible Messaging and Presence Protocol, basado en XML)  , también conocido como Jabber.

Es un servidor sencillo pero adecuado para un entorno empresarial, sobre todo por la inclusión de seguridad y soporte de LDAP.

Spark, por su parte es el cliente de Jabber desarrollado por la misma compañía y se integra perfectamente con OpenFire.

Ademñas de Spark existen multitud de clientes de Jabber, desde un interface web que instalaremos en el propio servidor hasta clientes para Android.

Instalación del servidor: OpenFire

Utilizamos OpenFire de ignite realtime en la última versión disponible en la fecha : v4.0.2 que podremos bajar de la propia web de ignite: https://www.igniterealtime.org


Una vez descargado el instalador (aproximadamente 56 MB) procedemos a lanzarlo


Una vez finalizado vemos la ventana de control de openFire desde donde podemos arrancar y parar el servicio así como el acceso a la consola de administración.



Al ser una primera instalación debemos configurar unas cuantas cosas más :
Idioma


Dominio de mensajería, puertos y encriptación :


Configuración de la base de datos:
Optamos por una configuración sencilla con una bbdd embedida en el software.


Este punto es interesante, si disponemos de Active Directory u otros servidores LDAP podremos configurarlo en este punto:



En nuestro caso optamos por vincularlo a Active Directory:



Introducimos los datos requeridos y realizamos el test Settings, durante unos segundos largos la pantalla queda difuminada realizando el test de conexiones, una vez terminado el test con éxito continuamos.



En este punto podremos tener problemas en dos frentes:
  • Con el Domain Controller elegido
    • En el caso de sistemas en que exista más de un DC, debemos seleccionar el que ostente los roles de Global Catalog y Operation Master.
    • En las pruebas realizadas hemos tenido problemas en el paso final de añadir usuarios administradores.
  • Con las notaciones de los DN pero básicamente es:
    • Base DN: origen de la raíz de búsqueda de los objetos del Active Directorio
    • OU="UnidadOrganizativaUsuarios",DC="dominio",DC="com"
    • Administrator DN:
      • Ubicación completa hasta el usuario que será administrador del sistema de mensajería
    • Ha de tener permisos de búsqueda en el directorio.
      • CN="userLogin",OU="UnidadOrgn",...,OU="UnidadOrg1",OU="UnidadOrganizativaUsuarios",DC="dominio",DC="com"

En los Domain Controllers del Active Directory se puede encontrar la herramienta ADSI edit (dentro de Administrative tools), desde ella podemos navegar por la jerarquía del directorio y nos irá mostrando el Distinguished Name de cada objeto, los parámetros Host y administrator a los que nos referimos.

En el siguiente paso definiremos el nombre mostrado a los usuarios de Active Directorio en el sistema de mensajería así como los filtros que queramos establecer sobre los mismos.

En primera instancia nos interesa dejarlo así para probar el sistema, siempre podremos volver posteriormente a la configuración para añadir filtros.



El último paso relativo al Active Directory es establecer la proyección de los campos de Active Directory para que los recopile el sistema de mensajería.

Dejamos todo por defecto.



Para finalizar la configuración debemos establecer el/los usuarios de Active Directory que serán administradores del sistema de mensajería, para ello introducimos los nombres de usuarios del Active Directory y pulsamos Continue para finalizar el setUp.






Lanzamos la consola de administración desde un navegador y nos loggeamos con el usuario administrador definido en el punto anterior:




Existen diversos errores comunes que pueden ocasionar fallos en el arranque de la consola :

  • Permisos en el directorio de instalación de OpenFire:
    • Verificar la consola si hay errores de creación de ficheros de Log
    • Aunque no es muy ético, salimos del paso dando permisos de Update/Read a Everyone.
  • Error en la página jsp relativa a la BBDD
    • Reinicia el server...
    • Al entrar en la consola volverá a pedir parámetros de configuración pero esta vez funcionará.
  • Puertos Abiertos
    • Habilitar siempre el Firewall del server y permitir el paso de los siguientes puertos
    • 5222-5223, 5229, 5262-5263, 5269, 5275-5276, 7070-7071, 7443, 7777, 9090-9091

Instalación del servicio Windows

Para ejecutar OpenFire como servicio debe instalarse previamente, para ellos debemos abrir un command prompt como administrator (Run as Administrator) y lanzar la siguiente instrucción:




Para evitar problemas de inicio de sesión puede ser necesario modificar el servicio y autenticarlo con las credenciales de usuario con que abrimos la consola de OpenFire.

Instalar SparkWeb

SparkWeb es un servicio web que hace las veces de cliente simple de Jabber, en este caso instalamos el complemento en el mismo server que aloja OpenFire.

En nuestro caso es un Windows 2008R2 y utilizaremos IIS como webServer.

Secuencia de pasos:
  • Agregar Rol Web Server al servidor Windows 2008R2, en caso de no estar ya añadido
  • Descargar sparkWeb de la web de IgniteRealtime (http://www.igniterealtime.org/projects/index.jsp)
  • Descomprimir la carpeta y moverla dentro de c:\inetpub
  • Agregar un nuevo sitio web y establecer como página default SparkWeb.html
  • Bindings: verifica que los puertos utilizados estén libres.
  • Start webSite.
Ahora sólo falta acceder al nuevo sitio mediante un navegador web:





En siguientes entregas veremos el cliente Spark y la integración con Zabbix.