jueves, 29 de marzo de 2018

Análisis de una campaña de phishing



Los campañas de phishing vía correo electrónico siguen siendo la opción más usada por los criminales a la hora de robar credenciales de acceso a cuentas bancarias, PayPal y similares.



El phishing es un tipo de ataque informático dedicado a robar credenciales de acceso a sitios sensibles como pueden ser cuentas bancarias, cuentas de PayPal, redes sociales, paneles de administración de páginas web... A diferencia de otros tipos de ataque, el phishing no se aprovecha de un error de código o de configuración sino que se aprovecha del factor humano.

El esquema de este tipo de ataques es siempre el mismo: los criminales realizan un envío masivo de mails hacia potenciales víctimas. Estos mails explican a la víctima que su cuenta ha sido hackeada o que debe verificar sus datos personales o similar e incluyen un enlace a la supuesta web del servicio/empresa. Usan los logotipos y tipo de redactado de la empresa legítima para dar veracidad a lo que cuentan. La página web a la que que apuntan tiene un diseño clonado de la web real, pero es una web falsa gestionada por el atacante. En estas webs falsas, siempre hay un formulario de login que al ser rellenado por la víctima, guarda las credenciales introducidas en una base de datos controlada por el atacante y luego redirecciona la petición a la página real, para que la víctima no sospeche nada.


Caso real



Ayer, pude analizar de primera mano uno de estos mails de phishing. Mi novia recibió un e-mail, aparentemente enviado por PayPal, que anunciaba que la dirección hac.ker2018@gmail.com había sido añadida a su cuenta de PayPal y que si no había sido ella quien la había añadido, se logeara en PayPal y la eliminase:


Para el que se lo esté preguntado... el botón de hotmail está en holandés.

Para empezar, que el mensaje provenga de service07@raquelalves.com en vez de una dirección @paypal.com ya les desmonta toda credibilidad. Hacer mail spoofing no es demasiado complicado, pero algunos criminales siguen yendo a por lo fácil, supongo.

Por otro lado, para quien no esté al tanto, si dejamos el ratón encima de un enlace de un correo electrónico podemos ver la dirección hacia donde lleva dicho enlace. Evidentemente, el destino del enlace no era paypal.com, así que decidí copiar el destino al que se dirigía la palabra "log in" y abrirlo en una nueva sesión, para ver qué pasaba. Es importante, en caso de querer investigar, el cerrar sesión del correo electrónico, o abrir el enlace desde una ventana de incógnito para así evitar el posible robo de sesiones de cuentas de correo mediante Cross Site Scripting.

Volviendo al enlace, este llevaba a una web proxy, probablemente un host hackeado:

http://hethongmay.com/red.html

En este red.html encontramos el siguiente código:

<html> <head> <title></title> </head> <body> <meta http-equiv="refresh" content="0; url=https://nysa.net/service.inc/" /> <h2 style="text-align: center;"><img src="https://www.bladen.co.nz/brand/processing-6.gif" /></h2> </body> </html>
En este código fuente vemos dos cosas:
  • https://www.bladen.co.nz: un tercer host usado por los atacantes para alojar imágenes.

  • https://nysa.net: la dirección final hacia donde se nos redirige, con un formulario de login que imita la web de PayPal, usado por los atacantes para robar credenciales de víctimas.

Como decía, el código anterior realiza una redirección a https://nysa.net/service.inc/, la cual imita la pantalla de login de PayPal. Lo que me ha sorprendido de esta página es que el dominio usado tenga un certificado SSL válido:



Supongo que los atacantes hackearon una página web con un certificado SSL activo para que las víctimas vieran "Secure" en la barra de direcciones del navegador y confiasen plenamente en la web.

Si analizamos el certificado, vemos que está expedido por "Let's Encrypt Authority X3" y que es plenamente válido en el momento de escribir este artículo:



Alguno se habrá dado cuenta de que las capturas de pantalla están tomadas desde un Mac usando Chrome. ¿Qué ocurre si intentamos acceder a la web final mediante Firefox desde Windows?



Firefox bloquea la URL final, que ya está incluida en una blacklist de webs maliciosas. Curioso que Firefox bloquee la URL antes que Chrome.

NOTA: al momento de escribir este artículo, Chrome para Mac no bloqueaba la URL. Unas horas más tarde, he vuelto a probar a acceder y ya la bloquea.

Llegados a este punto sólo me quedaba ser un buen samaritano y reportar los distintos dominios usados en este ataque a las compañías registradoras de los dominios.

Un WHOIS al primer dominio (raquelalves.com) me devuelve:



Un mail al registrador del dominio y otro al hospedador de la web explicándoles la situación y en pocas horas las webs dejarán de estar operativas.


Conclusión



Aunque el ataque gozaba de cierta sofisticación - uso de un servidor proxy intermedio que permite al atacante cambiar la dirección hacia donde redirige el mail por si la página final es eliminada y uso de HTTPS con certificado SSL - otros aspectos como la dirección remitente del correo o las direcciones URL no enmascaradas no dejaban lugar a dudas de que estábamos ante una campaña de phishing.
0

martes, 27 de marzo de 2018

Jackpotting: de Terminator 2 a la vida real



La reciente detención del jefe técnico del grupo Carbanak, dedicado a la sustracción de dinero en efectivo de cajeros automáticos, ha puesto en la luz pública este tipo de ataques informáticos.



¿Quién no ha visto Terminator 2, con esa mítica escena en la que un joven John Connor hackea un cajero y sustrae dinero en efectivo? como siempre, la realidad supera la ficción y este tipo de ataques llevan años produciéndose. Se los denomina "jackpotting" (en inglés jackpot es el premio en efectivo que se obtiene de una máquina tragaperras).

El jackpotting se ha puesto recientemete en el punto de mira de los medios de comunicación a raíz de la detención, nada más y nada menos que en Alicante, del ucraniano Denis K., líder técnico de un grupo de criminales dedicado a robar bancos. Y es que si antes se robaban bancos a punta de pistola, ahora se roban a clic de ratón.

El grupo, que se valía de varios programas de creación propia (Carbanak, Cobalt, Anunak...) para penetrar en los sistemas informáticos de bancos de todo el mundo y llevar a cabo extracciones programadas de dinero en cajeros, logró robar más de 1.000 millones de dólares.

Todo esto ha sido posible porque, según Kaspersky, "el 95% de todos los cajeros automáticos que hay en el mundo aún usan Windows XP", entre otros problemas de seguridad.

Para realizar los golpes, se valían del siguiente modus operandi:



Denis K. creó varios sistemas de spear phising para acceder a las redes internas de los bancos, además del sistema de acceso remoto a ordenadores Cobalt Strike. Según S21sec, los ataques a entidades bancarias funcionan de la siguiente manera:
  • Los delincuentes obtienen acceso a la red interna de la entidad financiera a través de mails de spear phishing que incluyen archivos adjuntos maliciosos.

  • Una vez consiguen entrar en la red y utilizando técnicas de escalado de privilegios que explotan vulnerabilidades del controlador de dominio y posterior movimiento lateral, los cibercriminales comprometen sistemas críticos con acceso a la infraestructura de los cajeros.

  • Los atacantes crean una red de sistemas infectados que se controla desde un panel de Command & Control operado por la banda y que es indetectable para la entidad financiera.

  • El operador se conecta a los cajeros mediante una conexión vía escritorio remoto y los infecta inyectando el malware. Una vez se ha conseguido esto, todo el ecosistema está preparado para lanzar el ataque.

  • El malware utiliza la capa XFS para tomar, de manera ilegítima, el control completo del dispensador del cajero y de este modo llevar a cabo la sustracción.

  • El ataque está en todo momento controlado por el operador de la banda, que se encarga remotamente de lanzar órdenes de retirada de efectivo e indica a las mulas el momento en el que pueden recoger ese dinero. Se genera un registro de todas estas actividades y se recopilan para asegurarse de que las mulas no operan de forma individual.

  • Por último, una vez se perpetra el ataque, el operador elimina toda prueba de forma remota evitando así que se pueda recuperar ninguna evidencia del mismo.

Una vez controlados los sistemas de administración de los cajeros, el grupo mandaba a mulas a cajeros concretos en horas concretas - mula es la forma de llamar a una persona que espera para recoger los billetes - a recoger los billetes escupidos. Luego, estas mulas cambiaban el efectivo por bitcoin y lo enviaban a las carteras de los cerebros de la operación.

La actividad era lucrativa; el detenido poseía dos coches de alta gama, un chalé, un piso valorado en un millón de euros y joyas por valor de 500.000 euros y llegó a disponer de 15.000 bitcoins. Y fue precisamente por su wallet de bitcoin por donde la policía pudo seguirle el rastro y acabar deteniéndole.

El ministro del Interior de España, Juan Ignacio Zoido, acompañado de los responsables policiales de la Comisaría General de Policía Judicial, la unidad de ciberdelincuencia, Europol y el FBI, ha dado cuenta de esta operación.

Y ahora yo me pregunto: si se puede rastrear a alguien a través de su wallet de bitcoin hasta dar con él físicamente, ¿tan difícil es rastrear a un tal M. Rajoy?


Fuentes:

https://www.kaspersky.es/blog/el-mayor-atraco-del-siglo-los-hackers-roban-mil-millones-de-dolares... https://www.elperiodico.com/es/sociedad/20180326/detenido-en-alicante-el-ciberatracador-que-robo...
0

lunes, 12 de marzo de 2018

Instalar SSD en un portátil y clonar antiguo HDD



O cómo copiar toda la información de nuestro disco duro actual a un nuevo disco SSD,
manteniendo dual boot Windows/Linux en un mismo disco.



Image and video hosting by TinyPic

En el trabajo uso un ordenador cuyo disco es de estado sólido (SSD) y en casa tengo un portátil con un disco duro magnético de toda la vida. Viendo lo rápido que se inicia el ordenador del trabajo, llevaba ya un tiempo queriendo cambiar el disco duro magnético de mi ordenador personal por un SSD. Recientemente, me he hecho con un disco de estado sólido y he decidido instalarlo como disco principal en mi portátil. He aquí mis andanzas con el proceso.

Vamos por partes:

Antecedentes
Adquirir un disco SSD
Conectar el disco
Configurar BIOS
Clonar HDD a SSD
Arrancar desde el SSD
Valoración




Antecedentes



En mi ordenador personal tengo configurado un boot dual Windows 10/Ubuntu 17.10 con GRUB2 como gestor de arranque. En cuanto a disco, tengo instalado en el portátil un HDD Western Digital de 1 TB y me he hecho con un SAMSUNG SSD de 256 GB.

Mi intención es copiar toda la información de mi disco antiguo al SSD y usar este último como disco principal. Con este cambio, pretendo acelerar la velocidad de inicio de los sistemas operativos y de los programas que tengo instalados, básicamente.



Adquirir un disco SSD



Lo primero que debemos hacer si queremos comprar un disco SSD es buscar uno que se adapte a nuestras necesidades. Para ello, deberemos tener en cuenta varias cosas:

¿Tendrá un solo sistema operativo instalado?
¿Cuánto espacio tenemos ocupado en el disco actual?
¿Tenemos un disco secundario (o un disco extraíble) donde almacenar más información?

Mientras nos hacemos estas preguntas, debemos tener en cuenta que, como viene ocurriendo desde siempre, cuanta más capacidad de almacenamiento tenga el disco, más caro será.

Según Microsoft, el espacio en disco recomendado para Windows 10 es un mínimo de 20 GB. Obviamente, si queremos instalar Windows y luego queremos usar Office y algunas aplicaciones básicas más, necesitaremos bastantes más que esos 20 GB que especifica Microsoft.

Por otro lado, la instalación promedio de una distribución GNU/Linux es de 5 GB (excepto OpenSUSE, que pide un mínimo de 12 GB para la administración de snapshots).

Image and video hosting by TinyPic Teniendo en cuenta todo lo mencionado, el tamaño mínimo que recomiendo a la hora de comprar un SSD es de 128 GB en el caso de querer tener instalado solamente Windows.

Si tenemos instalados varios sistemas operativos en nuestro disco actual, recomiendo mínimo un SSD de 256 GB.

A la hora de comprar el disco tenemos muchas opciones: tiendas físicas, tiendas online, comprar en el extranjero... yo, por comodidad, rapidez y atención post-venta, recomiendo comprarlo en Amazon.



Conectar el disco



Una vez tengamos un disco SSD en nuestras manos, deberemos conectarlo a una ranura libre de nuestra placa base. En mi caso, mi portátil es bastante grande e incluye dos ranuras SATA y una ranura mSATA. Incluso, si quisiera, podría desmontar el lector/grabador de DVD y conectar allí un cuarto disco. De momento, con dos discos me es suficiente :)



Configurar BIOS



Tras conectar el SSD a la ranura SATA libre de mi placa, la BIOS pasó a reconocerlo como disco secundario, GRUB lo reconoció como (hd1), Linux lo reconoció como unidad /dev/sdb y Windows como unidad D:/

Quería que el SSD fuera el disco principal del equipo, así que configuré la BIOS para ubicar el SSD por encima del HDD en la secuencia de arranque. Hecho esto, guardé cambios y salí de la BIOS.

Image and video hosting by TinyPic

Al iniciar el equipo, me encontré con un mensaje en pantalla que decía algo parecido a "No Operation System found!". Era de esperar, puesto que el SSD no tenía ningún sistema operativo instalado aún y estaba configurado como dispositivo primario de arranque. Si nos encontramos con este mensaje, simplemente presionando Enter el ordenador pasará a arrancar desde el siguiente dispositivo de la lista de arranque de la BIOS. En mi caso, pasó a arrancar desde el HDD e inicié sesión en Windows.



Clonar HDD a SSD



Con el disco colocado y el orden de arranque ajustado en la BIOS, el siguiente paso - para mi - era clonar el disco antiguo al nuevo para mantener programas instalados, fotos, documentos, etc. Como comentaba, en mi ordenador personal tengo boot dual Windows 10/Ubuntu 17.10 con GRUB2 como bootloader, así que estaba preparado para todo al hacer el clonado: perder GRUB, perder uno de los sistemas operativos, errores de consistencia en los datos, etc. pero si no surgiera ningún problema, ¿qué diversión habría? :)

A la hora de clonar el disco debemos decidir cómo vamos a hacerlo: desde Windows, desde Linux, con una aplicación, con otra... En mi caso hice una búsqueda rápida en Google y encontré varios programas dedicados al clonado de discos para Windows. Me produjeron todos la misma sensación que, años atrás, me producían los programas que encontraba en softonic.com para mejorar el rendimiento del PC. Todos tenían una pinta chunga y eran poco más que malware xD

Al final decidí probar uno llamado AOMEI Backupper, el cual ofrecía una versión gratuita para particulares. Lo instalé y probé la opción de clonado de discos:

Image and video hosting by TinyPic

Durante el proceso, me di cuenta de que mi disco de origen tenía una partición de boot MBR y el disco de destino (el SSD) estaba formateado en GPT. Como sabréis, BIOS usa MBR y EFI usa el particionado GPT. A la hora de clonar discos, origen y destino deben tener el mismo sistema de particiones de arranque.

Miré si el programa en cuestión me permitía cambiar el tipo de partición de arranque, pero no vi la opción. Intenté darle formato MBR al disco SSD desde el administrador de discos de Windows - según Microsoft es posible - pero la opción "Convertir disco a MBR" me aparecía en gris y no era ejecutable... Windows siempre tan servicial :)

Después de otra búsqueda rápida en Google, me topé con "EaseUS Partition Master Edición Gratuita Para Usuarios Domésticos". Fue instalarlo, clic derecho y cambiar GPT a MBR. De nuevo clic derecho y clonar disco. Parecía muy fácil... y lo fue :)

Image and video hosting by TinyPic

Durante el proceso, el ordenador se reinició y se mantuvo en una pantalla tipo consola copiando particiones. El proceso de clonado duró cerca de una hora.



Arrancar desde el SSD



Al acabar el clonado, el ordenador se reinició y se quedó clavado con una "_" en pantalla parpadeando; claramente, GRUB había perdido la capacidad de arranque. Decidí entonces conectar un USB con un Ubuntu Live y arrancar desde USB. Desde este sistema, cambié las particiones de GRUB de ambos sistemas de /dev/sda a /dev/sdb para que arrancaran desde el SSD, re-instalé GRUB en /dev/sdb y reinicié el equipo. Ahora sí, GRUB apareció en pantalla y pude iniciar Ubuntu (por probar uno de los S.O.) sin problema.

Me encontré entonces con un problema nuevo: Ubuntu me arrancaba desde /dev/sda. Y es que por mucho que en GRUB definiera el arranque del sistema en hd1 o /dev/sdb, Ubuntu me arrancaba una y otra vez desde el disco antiguo en /dev/sda (fácil de comprobar lanzando un simple df desde terminal). Imagino que es un bug de GRUB. Después de comprobar que Windows arrancaba bien, decidí formatear mi HDD y dejarlo vacío. Y después de reiniciar el equipo, esta vez sí, Ubuntu arrancó desde el SSD:

Image and video hosting by TinyPic
Ubuntu arrancado en la partición /dev/sdb5. O lo que es lo mismo, en el nuevo disco.



Valoración



Mi opinión respecto al proceso de clonado de un HDD a un SSD después de esta primera vez es que se trata de un proceso muy sencillo y rápido. Y hay algo muy interesante que no he comentado aún: lo mejor de estos programas de clonado es que detectan el espacio real usado. Es decir, si el disco de destino es de menor tamaño que el disco de origen pero el disco de origen tiene menos espacio usado, te permiten clonar el disco sin problema. Traducido, cloné un disco HDD de 1 TB que tenía alrededor de 220 GB usados a un disco SSD de 256 GB.

En cuanto a la velocidad de un SSD respecto a un HDD, se nota bastante. Ahora, desde que presiono el botón de encendido hasta que llego a la pantalla de login de Windows, pasan 10 segundos exactos (GRUB de por medio). Una vez hecho el login hacia Windows, me encuentro con que ya no debo esperar a que se acaben de cargar los iconos del escritorio ni esperar a que el cursor de Windows deje de "pensar" para poder empezar a usar el ordenador. Con un SSD es hacer login y ya poder iniciar cualquier aplicación al acto. Y eso desde mi portátil de 2012. En ordenadores más nuevos - como el de mi trabajo - la llegada al escritorio se produce en unos escasos 5 segundos.

Por último, comentar un aspecto negativo de los SSD: su ciclo de vida. Y es que la fiabilidad de este tipo de discos está asegurada durante dos años. A partir del segundo año, puede que empecemos a experimentar problemas de lectura y/o escritura al disco. Además, hay que tener en cuenta que en caso de problemas, recuperar la información contenida en un disco SSD que haya fallado es prácticamente imposible. Por ese motivo, recomiendo solo tener los sistemas operativos presentes en el SSD y los datos sensibles en discos magnéticos, de los cuales es más factible recuperar datos en caso de problemas.
3

jueves, 1 de marzo de 2018

Resumen de SUSE Expert Days Barcelona 2018



Repaso a las novedades de OpenSUSE, SUSE Linux Enterprise y otros productos presentadas
por SUSE en el evento Expert Days 2018, celebrado el pasado mes de febrero en Barcelona.




Después de recibir un e-mail por parte de SUSE invitándome a asistir a una jornada presencial llamada "SUSE Expert Days 2018" no pude sino pedirle a mi jefe que me dejara asistir al evento. No puso objeción, y unos días más tarde cogí un bus hacia el World Trade Center de Barcelona, con las pilas cargadas y preparado para aprender alguna que otra cosa durante el día.

La jornada empezó con la entrega de los pases a los asistentes, diferenciando entre partners y clientes finales. Junto con las acreditaciones, se nos dió un bolígrafo, una carpeta y un blog de notas con sus respectivos lagartos de SUSE.


Nos dieron regalos y nos invitaron a desayuno y almuerzo. ¿Qué más se puede pedir?


Las charlas: novedades



La primera charla del día empezó con una proyección en pantalla de la frase:

"Linux is free as long as your time is worth nothing" - Jay Ashford

La verdad es que no tengo ni idea de quién es ese tal Jay Ashford ni estoy deacuerdo con esa frase, pero sirvió para conectar con la idea que nos querían transmitir de que SUSE Linux es gratuito; lo que venden es el soporte técnico con tickets de asistencia y parches para el sistema. Y es verdad, si entramos a la web de SUSE, podemos descargar SUSE Linux Enterprise gratuitamente. El acceso a repositorios para actualizar el sistema ya es otra cosa.

En cuanto al soporte de SUSE Linux Enterprise o SLE, comentaron que el siguiente Service Pack (SP4) para SLE 12 estaba planeado para 2019 y el SP5 saldría en 2020, siendo este el último Service Pack disponible para SLE 12.

También comentaron que este año veríamos la llegada de SLE 15 y de OpenSUSE 15. Ambos sistemas igualarán su número de versión y, según comentaron, cualquier paquete que funcione en OpenSUSE 15 lo hará también en SLE 15. Se acabó el buscarse la vida para instalar determinadas aplicaciones en SLE.

Hablaron del soporte que tendrá el futuro SLE 15 para replicación DRBD, un sistema de réplica de datos parecido a RAID 1 pero más eficiente de cara a la recuperación de datos almacenados en un cluster en caso de problemas. Además de esto, avanzaron que SUSEFirewall2 daría paso a Firewalld, el firewall que equipan de serie otras distribuciones de Linux como Fedora.


Actualizaciones



Se podrá actualizar desde SLE 11 o SLE 12 a SLE 15 directamente. Imagino que mediante un zypper migration. (NOTA: ¿dónde quedaron SLE 13 y 14?). También comentaron que se distribuiría una sola ISO del sistema y sería durante la instalación donde elegiríamos si queremos un SLE for SAP, si queremos crear un servidor LAMP, etc.

Hablando de actualizaciones, nombraron un tipo de repositorio que desconocía por completo: SUSE Package Hub, un repositorio con paquetes open-source para SLE 12, no incluidos en los repositorios oficiales de SLE. Próximamente le dedicaré una entrada entera a este repositorio y sus posibilidades.

Sin dejar de lado las actualizaciones, debo mencionar el Live Patching de SLE, mediante el cual se puede parchear un componente del kernel aplicándole updates de seguridad y manteniendo en memoria dos instancias de dicho componente: una con la vieja función y otra con la nueva, de modo que si encontrásemos problemas con dicho componente, podríamos hacer un rollback al momento y hacer pasar el flujo de peticiones a través de la instancia no parcheada. Como no, este Live Patching se licencia a parte de una licencia estándar de SLE.


Microsoft loves (Linux) Open Source



Una de las cosas que más me llamaron la atención es que Microsoft fuese uno de los patrocinadores principales del evento. Según parece, el 40% de las máquinas virtuales que corren en Azure son Linux y el 60% de las soluciones ofrecidas en Azure Marketplace lo hacen sobre Linux. Parece que Microsoft no ha tenido más remedio que adaptarse a la situación y hacerse amiguetes de SUSE, Red Hat y compañía para poder ofrecer soporte de primer nivel sobre esos sistemas operativos.

Como curiosidad, una de las charlas del evento, que trató de cómo optimizar los recursos de una máquina virtual en Azure, empezó con esta imagen:


¿Os imagináis a Microsoft empezando así una charla 10 años atrás? cómo cambian los tiempos...


Sistemas monolíticos vs Contenedores



Otra de las cosas que más me llamaron la atención fue la forma de llamar "sistemas monolíticos" a las máquinas virtuales estándar en entorno VMWare. Todas las hojas de ruta de los productos de SUSE, desde el SUSE Linux Enterprise al SUSE Manager pasando por CaaS no hablaban de otra cosa que no fuera contenedores. Supongo que ya es hora de pensar solo en microservicios y contenedores e ir abandonando realmente la creación de máquinas virtuales dedicadas para cada servicio, pero yo aún no lo veo claro.

El distinto personal de SUSE puso especial émfasis en el cloud; desde el cloud privado con CaaS o OpenStack al cloud público en proveedores externos como Azure o AWS. Para ello, se valieron de un nuevo tipo de sistema operativo ya anunciado en 2017 llamado MicroOS. MicroOS - también llamado POD durante la conferencia - es una versión minimalista de SLE destinada única y exclusivamente a ejecutar contenedores.


SUSE Manager



Se desplazó desde Alemania uno de los ingenieros de SUSE encargados de la programación de SUSE Manager, un gestor de sistemas SLE capaz de actualizarlos en masa, ver paquetes instalados en cada sistema, crear copias de seguridad, etc. todo desde una consola centralizada.

Algunas de las funciones que mencionaron fueron:

- Capacidad de manejar contenedores.
- Capacidad de administrar sistemas SLE, Red Hat, Debian y Ubuntu.
- Conexión directa con nuestra cuenta de AWS y aplicación de parches a máquinas alojadas allí.
- SALT
- Capacidad de crear máquinas virtuales en ESX.
- Descarga parches una sola vez y despliegue posterior sin necesidad de una descarga por máquina.

A todo esto, añadieron que se podía pedir acceso al programa SUSE Manager Beta y disfrutar de versiones Beta gratuitas de SUSE Manager a cambio de reportar problemas y actuar como conejillo de indias de las nuevas caraterísticas.


Otros



Se habló de muchas otras cosas durante la jornada: sistemas de storage, CephFS, scripts HEAT para OpenStack, DeepSea... la verdad, no estoy metido en esos temas y no merece la pena que yo hable de ellos, pero sí quiero resaltar que entre el público había mucha gente interesada en el storage. Se formularon preguntas de alto nivel técnico y un invitado especial venido de EEUU se dedicó a responderlas.

Si hacías preguntas, te llevabas a casa una camiseta de SUSE, así que en un momento dado hice una pregunta sobre hardware y me llevé mi camiseta a casa.

Al final de la jornada, nos agasajaron de nuevo con más regalos:


Un transformador de corriente a USB y un transformador de mechero de coche a USB.

Fue un evento interesante con varios conceptos nuevos para mi. Me alegro de haber asistido y espero volver a hacerlo en el evento de 2019 :)

Para los interesados en profundizar más, comentar que las presentaciones mostradas durante el día están disponibles online en este enlace.
0