Monthly Archives: agosto 2016

El futuro de La Cloud

Leo  “Por ello un 41% de las compañías españolas ya utiliza la nube de alguna forma, según un estudio llevado a cabo por IDC. Esta cifra es muy superior al 15% de 2011 y aumentará hasta alcanzar el 52% en 2014, según sus previsiones

Había quien se las creía muy felices con este crecimiento “imparable”, pero claro sólo Jano, el Dios de pasado y del futuro es el que tiene “los datos” en el bolsillo…

No hay duda que la crisis ha vuelto a las empresas recelosas, defensivas, y “mirando hacia adentro” y más sobre su core business que no sobre procesos como los de TI. Que sí, que lo entienden y les gusta lo del “pago por uso”, pero lo miraremos más adelante.

Personalmente no creo que todo sea eso. Creo que falta confianza y una nueva cultura.

Sin duda que AWS, Microsoft y Google son los “chicos grandes” del patio. Pero tuvieron su parte visionaria y “su desierto del Sahara” para llegar a donde están. Vamos a decir que Microsoft supo darse cuenta del cambio del viento y hizo un viraje importante apostando por Azure.

Vuelvo a ver el informe IDC de este año y aunque más comedido, sigue haciendo “push” hacia “La Cloud”. 

Mi punto de vista.

El TI que hay ahora en Cloud, según mi visión, nace de 3 orígenes:

  • La TI de La Cloud. En este grupo pondríamos toda aquella infraestructura que “como va a dar servicio a La Cloud, ¿dónde la vamos a poner si no?”
  • La TI que nació en La Cloud. Generalmente son empresa muy nuevas, que han tenido un CIO visionario y ha pensado ¿Por qué no nacemos con la TI en Cloud?
  • Las grandes empresas, que ya tienen subcontratada la TI y la tienen de Cloud.

El resto pues está en ello. Mirando al de al lado, a ver que ha hecho, leyendo si ha pasado esto o aquello en tal CPD…

Voy a hacer un par de preguntas para demostrarlo. Cuantos CIOs conocen la calificación de los CPD según TIER y cuando conocen las 5 claves para considerar que un servicio Cloud?. Los que consiguen contestar correctamente las dos preguntas son aquellos que se han planteado alguna vez mover su TI a un CPD o a La Cloud!

He sido CIO de una aseguradora durante 10 años y los entiendo perfectamente (me gustó un artículo hace mucho tiempo ¿Porqué los CIOs no confían en las montañas rusas? ) y el problema es siempre el mismo.

Como decía el primer punto es la falta de confianza. ¡Pero es que no hay que poner todos los huevos en el mismo cesto! ¿ y como lo vamos a hacer?  Pues poco a poco y sin equivocarnos…..

Particularmente creo que hay varios “approaches” al tema. En primer lugar, haga un diseño de todo su TI, incluyendo el “on-premises” y el “off-premises”, con eso Vd tendrá la visión de su Cloud Híbrida. Así sin darse cuenta Vd. verá que dispone de un “pool” de recursos inside y otro offside.

Momento muy bueno para plantearse ¿Por qué no hacemos las copias aquí en local y un “copy job” en off-site?  ¡Un primer paso para disponer de una Cloud Híbrida!

el futuro de la cloudEsto nos podría conllevar a “Si tengo los datos allí, los puedo levantar en un DR con cierta facilidad, no?”

En un momento de “pico” de trabajo, Vd puede alquilar y aprovisionar infraestructura en remoto para, por ejemplo, tener desarrollo en la Cloud, o bien convertir todo en un DRaaS, enlazando la copia con la recuperación en una plataforma remota.

La última estrategia que he visto es quedando el hardware “local” con ciertos años, contratar los servicios generales en cloud, siendo los servicios locales que son los de respaldo (pero este caso es rara avis…. )


Por ello entiendo que el modelo que se debe plantear es un movimiento “smooth”, donde además el modelo permita ir paso adelante, paso atrás (Clouds Híbridas!)

Sé que varios de Vdes. están esperando por la cultura….  Verán, allá por 1987 yo era un técnico que mi función era, dentro de una gran industria química, forma y “vender” el uso de los PCs bajo es escepticismo de mis compañeros del IBM 4381 que creían que esos “ordenadores” eran simples juguetes. Lo mismo pasaba en los departamentos. ¡Había 1 ordenador y una impresora por departamento! Hasta que llegó, y llegó la cultura del PC y yo iba arriba y abajo instalando PCs ¡1 por mesa! quien lo hubiera  imaginado nunca!!!

Y esta es mi conclusión. Sí señores, la crisis ha ahogado mucho a la Cloud, pero no ha habido programas y estrategias de atraer los servicios de TI de una forma “gradual” hacia la Cloud. Cuando llegue la cultura de Cloud, recuerden mis palabras.

Take care,

Source: jmgriscom

La venganza de los Pokemon!

Hola!

Quien más quien menos estamos de vacaciones o algo parecido…

Y veo mucho cazador de Pokemon por las calles…….

Pero viene la venganza! ?

Felices vacaciones!

Source: jmgriscom

Continous, continous, continous

Continous integrations, Continous delivery, Continous deployment,  son conceptos que cada vez oímos más. Uno de ellos, continous delivery es de vital importancia para la gestión de cualquier cambio a aplicar en uno o un conjunto de servidores.

Los que hayan trabajado o colaborado con equipo de desarrollo de software seguramente el concepto continous integration o integración continua les sea familiar. La integración continua es una técnica utilizada por los equipos de desarrollo para detectar fallos en el código cuanto antes. Esta consiste en ejecutar de forma automática un conjunto de test cada vez que se sube un cambio al repositorio de código fuente. Estos test comprueban todas las funcionalidades de la aplicación para detectar si el nuevo cambio afecta a alguna de las funcionalidades de la aplicación. Este proceso protege de desplegar código erróneo a producción.

El concepto de continous delivery va un paso más allá. Continous delivery lleva la idea de integración continua a todos los actores y procesos  que participan en el flujo de despliegue de una aplicación o actualización de un sistema. El objetivo es desplegar todos los cambios, ya sea la instalación de nuevas funcionalidades, actualizar un bug o aplicar nuevas configuraciones a producción de forma segura y rápida.

La idea es establecer un conjunto de etapas o pipeline a través de las cuales pasa cada cambio antes de ser aplicado al entorno de producción. El objetivo de cada una de estas etapas es validar la calidad del cambio desde diferentes puntos de vista y prevenir los errores. No hay un pipeline único, sino que cada organización tienes su propio pipeline,  pero típicamente este puede estar formado por algunas es estas etapas:

  • Integración continua.
  • Ejecución de test funcionales.
  • Ejecución de test de seguridad.
  • Ejecución de test de rendimiento.
  • Despliegue a producción.
  • Operación.

El esquema siguiente muestra un pipeline para la gestión de cambios en los sistemas, donde lo deseado es que todas las etapas del pipeline sean automática, solo dejando el paso a producción con una acción manual, todo y que solo sea para activar el despliegue del cambio en el entorno de producción.

esquema continuos

Cada una de las etapas debe informar a los diferentes actores que intervienen en el proceso de continous delivery (desarrolladores, operadores, ingenieros de calidad, ingenieros de seguridad, gestores, …) del resultado de cada etapa. De esta forma, detectamos los problemas que pueda ocasionar un nuevo cambio antes que este se aplique sobre el entorno producción.

Para poder agilizar el proceso de aplicación de cambios y repetirlo tantas veces como sea necesarios, es básico automatizar los test ejecutados en cada una de estas etapas. Por otro lado, existen herramientas como Jenkins que permiten configurar y automatizar las etapas del pipeline.

Si os interesa, en https://continuousdelivery.com/ encontrareis recursos que profundizan en el tema.


Source: jmgriscom

Obtener datos e informes de storage en tiempo real de nuestra infraestructura de vSphere

Cada vez hay más soluciones de terceros o del propio VMware que nos sirven para monitorizar y analizar nuestra infraestructura. Las infraestructuras van madurando y se vuelven más confiables, hecho que hace que se virtualicen más cargas en ellas. Además, ya prácticamente todas las aplicaciones están soportadas dando niveles de rendimiento a la par o incluso mejores que en entornos físicos. Más consolidación de máquinas virtuales por host, más dispersión y máquinas virtuales más sensibles hacen que la necesidad de monitorizar de manera más exhaustiva sea una realidad

Como decía, hay herramientas de diversos tipos y funcionalidades que sacan, procesan y almacenan datos de rendimiento de nuestra infraestructura virtual para que podamos generar alertas o informes predictivos. Podríamos entrar a valorar muchas de ellas, pero antes creo que es casi obligado conocer las herramientas nativas en vSphere/vCenter. Conocerlas, además de otras ventajas que expondré seguidamente, nos ayudará a conocer “de base” las métricas más críticas que luego podremos explotar con otras soluciones.
 
Una de estas herramientas nativas es vscsiStats, nativa en ESXi. Con ella, obtendremos datos de caracterización del uso a nivel de Storage de nuestras máquinas virtuales. Qué ventajas supone? Como decimos, es nativa, por lo que ya la tienes incluida en tu hipervisor, es rápida en obtener datos en real-time, puesto que estamos consultando directamente el scheduler de ESXi, es relativamente sencilla de usar (veremos cómo a continuación) y fácilmente podemos exportar los datos que nos aporta. A diferencia de los datos de storage que nos aporta esxtop, otra herramienta nativa de monitorización para ESXi, que solo aplican para almacenamiento basado en iSCSI o Fibre Channel, vscsiStats nos da más variedad de información y sobretodo sin importarle en qué tipo de almacenamiento esté la VM, pues se sacan los datos a nivel de disco virtual.
 
Podremos sacar información de storage de cualquier VM, pero qué información? Básicamente lo que nos dará vscsiStats son datos de utilización y carácter de las operaciones de I/O de storage durante un periodo de muestreo en forma de histograma, por lo que será importante ejecutar las cargas que queremos monitorizar durante ese momento. Podemos sacar los siguientes histogramas:

  • seekDistance: localidad “espacial” de los I/Os
    • Dada una VM, podemos ver la secuencialidad de los bloques que consulta/escribe. Si un bloque está más cerca que los consultados/leídos inmediatamente antes, se accederá mucho más rápido. En cambio, si el patrón de uso de bloques es muy aleatorio, impactará en el rendimiento. Es interesante juntar patrones de uso común en las mismas LUNs para intentar optimizar el rendimiento.
  • ioLength: tamaño de IO
    • Como comentaba en anteriores posts, es importante alinear las configuraciones en todas las capas que intervienen en el uso de disco, pero a su vez puede resultar muy complejo. Sobretodo a alto nivel, pues puede resultar complicado sacar patrones de IO a nivel de sistema operativo de la VM o incluso la aplicación que use. Con vscsiStats, podremos sacar datos del tamaño de IO real que están utilizando nuestras VMs sin importar qué OS/aplicación estén ejecutando. Por ejemplo, si sabemos el tamaño medio de IO de nuestras VMs, podemos configurar el tamaño de stripe de nuestra cabina a ese valor para maximizar su rendimiento.
  • latency: análisis de latencias
    • Rápidamente podemos sacar analizar qué tiempos de respuesta están teniendo nuestras operaciones de I/O para sacar medias, ver a qué máximos estamos llegando y ver qué latencias son las más comunes.
  • interarrival
    • Nos sacará qué tiempo entre llegada de I/Os están teniendo nuestras VMs.
  • outstandingIOs
    • Al llegar una operación de I/O, se calculan cuantas otras para ese disco virtual están aún pendientes por llegar. Al verlo en histograma, se puede ver que concurrencia de I/Os se tiene para ese disco y ver si hay contención a nivel de profundidad de colas.

Vistas sus posibilidades, vayamos a ver como funciona:

  • Recoger IDs de las VMs y los discos: como hemos visto, vscsiStats se invoca para empezar a captar datos. Estos pueden ser referentes a todas las VMs y todos sus discos o de una VM o disco en concreto.

Si queremos recoger datos de todos los discos y VMs, podemos obviar este primer paso. En caso contrario, deberemos introducir el siguiente comando en la consola de nuestro ESXi (por SSH o DCUI):

# vscsiStats –l

El output serà un listado de las VMs y discos. Los datos que queremos obtener serán el “Virtual Machine worldID” que identificará nuestra VM y el “Virtual SCSI Disk handleID” que identifica el disco virtual. Con estos dos datos, seguimos adelante.

  • Empezamos la recolección de datos: debemos usar la opción “-s” para empezar a capturar datos de uso de nuestras VMs.

Si queremos capturar datos de todas las VMs y discos, tan solo hace falta que ejecutemos el siguiente comando:

# vscsiStats –s

En caso de que querramos monitorizar todos los discos de una VM en concreto, necesitaremos el parámetro “Virtual Machine worldID”:

#vscsiStats –s –w <worldID>

Si queremos concretar más y solo capturar datos de un solo disco virtual necesitaremos el “Virtual Machine worldID” y el “Virtual SCSI Disk handleID”

# vscsiStats –s –w <worldID> -i <handleID>

A partir de ejecutar el comando con la opción –s, empieza el periodo de muestreo que durará (si no indicamos lo contrario) 30 minutos. Si queremos alargárlo, tenemos que volver a ejecutar el comando –s con los parámetros que hayamos especificado anteriormente para “renovar” otros 30 minutos más.

  • Sacar histogramas: una vez hemos empezado a llenar los contadores, ya podemos obtener histogramas del uso. Como hemos visto previamente, hay varios disponibles así que previamente debemos saber cuál queremos sacar. Una vez está claro:
    1. seekDistance: # vscsiStats –p seekDistance
    2. ioLength: # vscsiStats –p ioLength
    3. latency: # vscsiStats –p latency
    4. interrarrival: # vscsiStats –p interarrival
    5. OIOs: #vscsiStats –p outstandingIOs

De esta manera podremos obtener los datos que precisamos en la pantalla de nuestra consola. En el siguiente post veremos como exportar datos con esta herramienta y ver como podemos sacar informes con los datos en excel.

.code {
font-family: “Courier New”, Courier, monospace;
}

Source: jmgriscom

¿Cual es el real “Estado del Arte” de los cryptolocker, ransomware y otros elementos dañinos?

En estos últimos días, oyendo casos de Ransomware, de su proliferación y lo que es más, su “no resolución” empieza a preocuparme.

No sé si conocéis la paradoja del cisne negro. Los ingleses en sus viajes, encontraron cisnes negros, pero claro, “Los cisnes son blancos….” Luego esto no es un cisne. Cuando llegaron a Inglaterra y los diseccionaron la respuesta era clara. Era un perfecto cisne, pero de color negro.

Esta paradoja se ha extendido en el mundo empresarial como “no des por sabido lo que sabes, puede que haya más sobre el tema que desconoces”. ¿Quien iba a pensar que unos aviones civiles se podían estrellar contra unas torres?

Recuerdo cuando empezó los auges de antivirus como el “I love you” y lo que está ocurriendo ahora me lo trae a la memoria, aquello fue un “Boom”, esto va en escalada.

Y así con aquella máxima informática que dice “Hay que saber del tema, y sino, el teléfono del que sabe” llamo a mi amigo Antonio Martínez Algora , Responsable Técnico de Stormshield para Iberia, curiosamente una empresa participada por Airbus. Aprovecho para “atracarle” con una entrevista para vosotros 🙂 J. Gracias Antonio, eres un amigo….

JMG. Antonio, que nos puedes decir de esta “escalada”?

AMA. Estamos asistiendo a un fenómeno preocupante: la confluencia de técnicas de ciberdelincuencia para conseguir un efecto más letal y evadir las medidas de protección.  Por primera vez, ransomware, como Locky o Cerber, son utilizados por una vulnerabilidad de Día Cero de Flash para infectar a sus víctimas.  Una razón adicional para actualizar su plugin de Flash con el último parche propuesto por Adobe.

Existen al menos dos kits de exploit, llamados Nucleus y Magnitude, que se encuentran disponibles “in the wild” y que aprovechan la vulnerabilidad de Día Cero descubierta recientemente en la aplicación multimedia.  Gracias a estos kits, los cibercriminales pueden explotar la vulnerabilidad de Flash para infectar a sus víctimas con Locky o Cerber, dos tipos de ransomware que cifran los documentos del ordenador de sus víctimas con potentes tecnologías de cifrado, y solicitan un pago o rescate para desencriptar y restaurar los documentos originales.

JMG. ¿Nos cuentas un poco sobre cada uno de ellos?

AMA. El primero de estos dos malware, Locky, ha hecho estragos el mes pasado en distintos países europeos y de todo el mundo, afectando a todo tipo de empresas y particulares.  Uno de los incidentes más renombrados ha sido el de un hospital en Los Ángeles, Estados Unidos, obligado a pagar 17.000USD de rescate para remover el malware en múltiples sistemas infectados y recuperar datos médicos como historiales, radiografías, análisis, etc.

En un primer momento, las técnicas utilizadas para la difusión de este ransomware han consistido en macros de Office incluidas dentro de un documento Word,  y también archivos JavaScript enviados como archivos adjuntos en campañas masivas de correos electrónicos o spam.  En ambos casos, se requiere de la participación del usuario, aprovechándose de su “ingenuidad” y menor concienciación de seguridad, para abrir estos documentos Word o JavaScript, a pesar de provenir de una fuente que podría no ser de confianza.

Si bien un usuario debidamente formado es poco propenso a abrir documentos sospechosos, el uso de la vulnerabilidad de Flash permite a los ciberdelincuentes infectar a cualquier tipo de usuario durante una simple visita a un sitio Web y por tanto sin requerir ningún tipo de intervención directa del usuario.  De esta forma, incluso los usuarios más recelosos y expertos, se convierten en víctimas impotentes de esta nueva forma de infección.

Desde la perspectiva de los piratas, esta combinación de técnicas de ataque permite optimizar la tasa de usuarios infectados de forma espectacular.  Los ciberdelincuentes buscan otros vectores para rentabilizar sus inversiones, ya que los usuarios se van mostrando cada vez más desconfiados hacia los ficheros adjuntos de fuentes desconocidas. Igualmente las herramientas de protección tradicionales están añadiendo capacidades para bloquear documentos que contengan macros o bien bloquear tipos de ficheros potencialmente peligrosos como programas ejecutables, JavaScript o scripts en general.   Gracias al uso de sitios Web legítimos infectados, o sitios web suplantados mediante redirección por los ciberdelincuentes, estos ataques son mucho más difíciles de detectar y de prevenir.

JMG. ¿Cuál es el perfil del Ciberdelincuente?

AMA. Si el kit de exploit Nuclear sirve para difundir Locky, Magnitude hace lo propio con otro ransomware, Cerber.  Este último malware, que también cifra  los datos de sus víctimas, tiene la particularidad de atacar múltiples sistemas operativos (Windows, Linux, MacOS X).  Con Cerber, asistimos a la llegada de una generación de ransomware proporcionados como un servicio.  Incluso sin conocimientos técnicos especiales, los ciberdelincuentes pueden comprar malware en línea y generar sus propias campañas de infección.

También se empieza a popularizar la infección de ransomware aprovechando una vulnerabilidad de Día Cero para acelerar su difusión. Estamos asistiendo a un cruce entre dos mercados de ciberdelincuencia: el negocio muy rentable del ransomware y el mercado para la venta de exploits de vulnerabilidades o “zero-day exploit”.

Hasta ahora el mercado de zero-day exploits  -que se venden por un precio que ronda desde unos pocos miles a decenas de miles de euros – era utilizado fundamentalmente para campañas de ataques persistentes avanzados (o APT por sus siglas en Inglés), para infiltrarse en una organización objetivo y robarle datos confidenciales y tomar control de sus sistemas a lo largo del tiempo.

antonio_stormshield

JMG. ¿Apuntar a las empresas más negligentes o con menor inversión en seguridad?

AMA. Si bien la vulnerabilidad de Flash afectaba a muchas versiones de la tecnología de Adobe, los exploits sólo atacaban a las versiones antiguas.  Esto plantea la pregunta de por qué los atacantes no están sacando el máximo provecho al exploit y auto-limitan el alcance de sus víctimas.

Matthieu Bonenfant, director de Producto de Stormshield, avanza una explicación bastante lógica para esta elección a priori sorprendente: “A menudo observamos dos tipos de empresas a la hora de abordar la instalación de parches de seguridad. Las que despliegan de forma regular las actualizaciones de sus aplicaciones; éstas empresas en realidad tendrían menor interés para los ciberdelincuentes, ya que tendrán más dificultad para atacarlas. Y por otra parte aquellas que muestran una carencia técnica desde hace varios años; estas empresas les permiten a los ciberdelincuentes perpetrar sus ataques durante mayor tiempo por debajo del radar sin saltar a la luz pública, especialmente con exploits de día cero”. En pocas palabras, los hackers podrían haber apuntado intencionadamente a las versiones más antiguas de Flash… por una mera cuestión de rentabilidad de sus acciones, para pasar desapercibidos el mayor tiempo posible.

Los últimos ataques de ransomware están tomando proporciones muy grandes. En primer lugar debido al número de usuarios afectados por la vulnerabilidad CVE-2016-1019, que afecta a todas las versiones de Flash anteriores al parche publicado el 7 de abril. Además, porque Nucleus y Magnitude, aunque no tienen la popularidad de un Anger, no son menos habituales en el “mercado negro”.  Hay que señalar que ha sido a través de un análisis del kit Magnitude como los investigadores de Proofpoint, ayudados por los de FireEye, han descubierto la vulnerabilidad CVE-2016-1019.

Esta escalada de la amenaza es parte de un aumento de la potencia de los ransomware.  Debido a este auge, las empresas están demandando herramientas específicas de protección contra APTs y zero-days como la solución de Stormshield Endpoint Security (SES). SES utiliza tecnologías avanzadas de protección, que tratan, no de reconocer cepas infecciosas, sino sus efectos, bloqueando los comportamientos nocivos, incluso de procesos legítimos, como escalado  de privilegios, ejecución de código, desbordamiento de la memoria, etc.

Las herramientas avanzadas de seguridad de Stormshield que anteriormente eran demandadas únicamente por empresas de sectores sensibles con altos requerimientos, están siendo solicitadas hoy en día por empresas de todos los sectores y de cualquier tamaño, incluyendo PYMEs… después de haber sido infectadas con ransomware y haber sufrido sus efectos, y para evitar seguir tropezando con distintas variantes del mismo problema en el futuro.

JMG. Pues nada Antonio, muchas gracias por tu valiosa información y nos gustaría volverte a ver por estos lares. Un abrazo

 

—– UPDATE 4.Agosto.2016 —-

Me informa Antonio Martinez que los que producen RaaS (Ransomware as a service) han tenido un enfrentamiento entre ellos. En este caso, los de PETYA han hackeado a otro Ransonmware rival, de nombre CHIMERA siendo sus claves plublicadas.

Tambien aquí podemos ver como detectar si tienes o no Chimera.

Saludos. JM


Source: jmgriscom