Category Archives for "Seguridad"

Nueva Web en Orbal

web-orbal

Una web llena de recursos para vosotros

web-orbal

Siempre he dicho que una imagen vale más que cien palabras, y por eso creo que lo mejor es que se vea lo que estamos haciendo.

Estamos haciendo un punto de encuentro donde un Responsable Informático pueda encontrar la mayor cantidad de recursos sobre ello, videos, white papers, e-books

Y mientras vamos populando este apartado, podéis ver nuestro nuevo site, desde donde podréis ver lo que hacemos, nuestras novedades, etc.

captura-de-pantalla-2016-09-25-a-las-18-39-52

Os esperamos pronto por www.orbal.es

Take care,

JM

 


Source: jmgriscom

Organiza tus jobs de Veeam mediante políticas

organiza-tus-jobs-mediante-veeam

El hecho de que la virtualización es una tecnología ya bastante madura en cada vez más entornos supone muchos retos. Vamos añadiendo cargas (seguramente cada vez más críticas y sensibles) a los hipervisores, nuevas máquinas, ratios de consolidación más agresivos y demás realidades que parece que induzcan la idea de que mantener el control de nuestra infraestructura tenga que ser más una cuestión de “hacer malabares”. Estos fenómenos son los que o ya afrontamos o afrontaremos en algún momento y es por ello que por ahí van las tendencias de los fabricantes cada vez apostando más por la automatización y la monitorización.

Estas realidades aplican por supuesto también a las soluciones que dependen directamente de nuestra infraestructura vSphere, como por ejemplo Veeam Backup&Replication. Antes de nada, en el caso de Veeam, lo primordial es mantener una definición de los requerimientos de cada VM en cuanto a su nivel de disponibilidad, luego veremos cómo aplicarlos y sobretodo mantenerlos de manera ágil.

Al final, lo que queremos es una manera ordenada y dinámica de proteger nuestras VMs según las condiciones específicas de cada una de ellas.

Para definir estas políticas deberemos analizar qué requerimientos tienen nuestras VMs o nuestros perfiles de VMs: tenemos que declarar los parámetros en los que basaremos nuestras políticas de Backup/Replicación.

Paso 1 – definir parámetros y valores

Un ejemplo sencillo de estos parámetros podría ser el siguiente:

  • RPO

    • ¿Cada cuanto tiempo debemos ejecutar una copia de la VM? Lo podemos medir en minutos, horas, días …
  • Ventana
    • ¿Qué intervalo tenemos para ejecutar la copia? Pierde relevancia si usamos Storage Snapshots. Expresado en franja horaria.
  • Retención
    • ¿Qué histórico de copias debemos almacenar para esa VM? Lo especificaremos en valores “absolutos”. Es decir, si quiero mantener una semana de copias y mi RPO es de 24h, tendrá un valor de 7.
  • RTO
    • Tiempo en poner la máquina en producción a partir de la declaración del desastre. En sí no es un parámetro que apliquemos al job como el RPO, pero podemos agilizarlo usando Reverse Incremental o más aún con replicas.
  • Encriptación
    • ¿Debemos encriptar los datos de esa VM?
  • OS
    • Mantener VMs de OS/Datos/Apps parecidos nos ayudará a tener mejores ratios de deduplicación.
  • ¿Backup secundario?
    • Hay que almacenar una copia de la VM en algún otro lugar.

Paso 2 – agrupar

Con  este análisis como primer paso, tendremos una descripción en términos de protección de datos de nuestras VMs, “metadatos” para cada una. Ahora nos hará falta agruparlas según valores parecidos. Fácilmente, acabaremos (siga esto entendiéndose como ejemplo) con un grupo que será “Producción – Linux” con unos valores iguales para cada parámetro en todas las VMs. Con estos grupos, tendremos una posible propuesta de organización/distribución de nuestros Jobs de Backup/Replicación.

Paso 3 – “dinamizarlo”

Sin embargo, no olvidemos que el principal ánimo de este post es hacer el trabajo (sobretodo el de mantenimiento) más sencillo. De momento, tenemos una manera ordenada de proteger a nuestras VMs según los requisitos específicos de cada una, pero no hemos hablado de cómo hacer todo este proceso dinámico o semi-automatizado.

Cuando hablamos de Jobs dinámicos en Veeam Backup & Replication, nos referimos a Jobs que como origen tienen un objeto que no es/son una VM en sí. En la definición del job, como “Source”, podemos añadir una a una cada VM que cumpla los requisitos definidos por el Job. Si tu entorno es pequeño, y sobretodo, con pocas modificaciones, es algo planteable, pero si el entorno va evolucionando (que es lo más normal), habrá que empezar a plantear otras maneras, puesto que no vamos a ir añadiendo VMs a los Jobs, sería bastante ineficiente.

En el fondo, para tener un job dinámico bastaría con crear uno solo para toda tu infraestructura que, como “Source”, incluyera todo el vCenter. De esta manera, toda máquina nueva sería incluida directamente en la copia sin necesidad de dar “un paso más” añadiéndola. Sin embargo, catalogar todas las VMs bajo la misma definición no es lo que buscamos tampoco.

Es aquí donde toman relevancia objetos de vCenter que quizás no habías tenido en cuenta antes, como son las etiquetas (o “tags”) y las carpetas. En este whitepaper, Luca Dell’Oca nos sugiere que, una vez definidos los grupos de VMs que hemos visto en el paso 2, cada grupo se mapee a un tag de vCenter y luego, creando un Job para cada grupo, añadir cada etiqueta como “source” del job. Así pues, para nuestro grupo de ejemplo “Producción – Linux”, tendremos que crear su etiqueta en vCenter, etiquetar cada VM que pertenezca a este grupo con ella, y luego crear un Job de Veeam que como Source tenga dicho tag. Además de ser un genial White Paper (recomiendo descargarlo y leerlo detenidamente sobre todo por cómo se detallan los pasos), me parece un método perfecto para entornos heterogéneos, diversificados, (muy) grandes y con muchos usuarios y permisos en vCenter. Sin embargo, quizás vea más acorde a un entorno “standard” de los que tenemos hoy en día por nuestras tierras usar las carpetas de vCenter . La razón es sencilla: al crear una VM, ya sea mediante el wizard tradicional del cliente de vSphere o incluso mediante herramientas de terceros como Chef, nos dejará (de hecho nos “obligará”) especificar en qué carpeta la ubicamos.

Esto hace que no tengamos que dar ese “paso más” de luego ir y etiquetar la VM. Luca habla de maneras muy válidas mediante scripting por ejemplo de automatizar el proceso de etiquetar, pero quizás es demasiado complejo si ya nos sirven las carpetas.

La idea es que no queden máquinas virtuales fuera de copia. Si usamos carpetas, nos aseguramos que siempre nos pregunte en qué carpeta ponemos la VM, pero cabe la posibilidad de que la VM caiga en la carpeta “Discovered Virtual Machines” o en la matriz del Datacenter. Para mitigar este problema, podemos por ejemplo ejectuar un pequeño script que cada dia revise que no queden VMs en carpetas que no estén incluidas en ningún job.


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