Año nuevo, vida nueva… Contraseña vieja.

by

Hace un par de meses leí que durante 2020 los ciberataques aumentaron un 70% con motivo de la pandemia, algunos de los titulares que más resonaron en Argentina fueron el ataque de Ransomware a Migraciones de Argentina, El “ataque” al Streaming del día de la lealtad peronista y el que más revuelo tuvo a nivel mundial el ataque al Tesoro de EEUU, según se cree por parte de otro país.
No obstante, estos fueron los ataques más relevantes, el phishing se incrementó casi in 80% y el robo de datos aumentó considerablemente.
(Para más información vean este informe de Interpol)

Ahora, en estas épocas del año nos ponemos objetivos para cumplir durante el nuevo año, me gustaría proponerte que en 2021 uno de tus objetivos sea “estar más segurx digitalmente”.  En las próximas líneas te voy a contar un poco que podés hacer para estar más seguro en el ciberespacio.

Actualizar tus contraseñas.

¿Hace cuanto que no cambias la contraseña del mail? ¿Y la contraseña de Facebook? ¿Cuánta gente sabe tu contraseña de Netflix? ¿Y la del Wifi?
Una buena idea para empezar este 2021 más seguros es cambiar la contraseña de nuestras cuentas. Algunos consejos:

  • Que tenga mayúsculas y minúsculas.
  • Que tenga números.
  • Que tenga caracteres especiales (¡, $, #, @, . , etc)
  • Que no sea fácil de adivinar (Evita cosas como clubes, bandas, direcciones, nombres de seres queridos, etc)

Un punto para empezar a cambiar las contraseñas y un ejercicio regular que podes hacer es entrar a haveibeenpwned que chequea tu mail contra filtraciones de datos reportadas abiertamente.

Activa el doble factor de autenticación

El doble factor de autenticación (2FA) es una medida de seguridad extra que se suele usar en entornos corporativos, pero que está disponible en una gran variedad de servicios.
Así como la contraseña es la respuesta a la pregunta a “Algo que sé” el doble factor de autenticación es la respuesta a una de dos preguntas “Algo que tengo” como puede ser un token o “Algo que soy” como podría ser un sensor de huellas dactilares o un scanner de retina.

Mi recomendación es activar un token de Google Authenticator que tiene una gran variedad de servicios disponibles.
Acá podes ver como instalarlo y configurarlo.

Usar un Password Manager

¿Tenés la contraseña anotada en la agenda? ¿En un archivo de Excel?
Te propongo una alternativa mucho más segura, usa un password manager.
Estos servicios son como una base de datos, completamente cifrada, para tus contraseñas y usuarios.
En cuanto a opciones 1Password es un servicio cloud en el que vas a tener todas tus contraseñas sincronizadas en el celu y la compu por 3 US$ al mes.

Mientras que Keepass es un servicio completamente gratuito https://keepass.info/ (la implementación para MacOS se llama MacPass)
todas las contraseñas se van a almacenar en un archivo .kdbx al que podemos darle una medida extra de seguridad poniéndolo en nuestro servicio de nube (Google Drive, One Drive, Dropbox, etc)
Acá te dejo un tutorial de como instalarlo.

Actualizar el Sistema Operativo y las Aplicaciones

Si tu PC lo permite, siempre es buena idea tener el sistema operativo con los parches al día y las aplicaciones lo más actualizadas posible.
Si hace rato que no actualizas tu PC te invito a que este año actives el Windows Update y bajes los últimos parches. Si no sabes cómo, buscar un técnico de PC para que lo haga por vos es dinero muy bien invertido, de paso optimizas la PC un poco.
En cuanto a las aplicaciones es un espectro muy amplio, pero ya el hecho de tener el navegador Web (Chrome, Firefox, Edge, Safari) al día es un punto importantísimo.

Tener el antivirus activado y actualizado

En cuanto al antivirus podemos hablar un rato largo cual es el mejor y cual tiene mejores prestaciones.
A mí me gusta Malwarebytes que por 3.33 US$ al mes tenés protección Premium para un dispositivo.
Ahora, en cuanto a antivirus gratuitos podemos usar Windows Defender que está incluido en la licencia de Windows 10 y trae varias funciones de seguridad avanzadas (Firewall Avanzado, Inspección de tráfico, etc), Avast es otra buena opción que es Gratuita.
Cualquier opción paga o gratuita lo importante es tenerlo activado y actualizado, así reconocen las nuevas amenazas.

Espero que este articulo te haya orientado con algunas ideas para estar mas segurx en 2021.
Felices fiestas!

Nacho

¿Cómo conectarse a la API de NSX?

by

El 31 de diciembre es el último día de soporte de Adobe Flash. Por lo que la mayoría de los browsers van a dejar de ser compatible son flash y algunos productos no van a funcionar correctamente.
La mayoría de los vendors sacaron parches y upgrade paths para sus productos a modo de no tener dependencias fuera de soporte.
Yendo al caso puntual de VMware, hay un post de William Lam que detalla todo a la perfección. Adicionalmente en la KB 78589 hay más detalles.

Yendo al caso de NSX-V: Es un producto que originalmente fue concebido en flash y fue pasando gradualmente a HTML5 (UI)
La recomendación oficial de VMware en relación a NSX-V es actualizar a 6.4.8, pero el problema es que perdemos algunas capacidades, por ejemplo, administrar de forma gráfica el servicio SSL VPN dentro de los NSX Edges y las definiciones de servicio.
(En este post hay más detalles sobre el cambio de versiones a NSX-V 6.4.8)

Lo bueno, es que vamos a poder seguir operando con normalidad mediante la API de NSX.

¿Cómo me conecto a la API de NSX?

Requisitos:
Tener instalado y configurado un cliente API REST.
Por ejemplo, este tutorial lo hicimos con RESTer


Procedimiento:
1. Descargar el certificado del NSX Manager:
Abrimos una pestaña nueva y navegamos hasta el NSX Manager
Aceptamos el certificado o generamos una excepción de seguridad (Firefox)


2. Agregamos la autorización para el cliente API

3. Configuramos las credenciales con las que nos vamos a autenticar al NSX Manager

4. Agregamos el header accept con el valor “application/json” para evitar el formato xml

5. Ejecutamos la request que queramos y nos aseguramos que la respuesta sea HTTP 200 (Ok)

La petición que le hicimos a la API era para saber el estado de SSLVPN en un Edge en particular.
GET /api/4.0/edges/{edgeId}/sslvpn/config
Para ver un listado de requests a la API de NSX podemos usar este link https://docs.vmware.com/en/VMware-NSX-Data-Center-for-vSphere/6.4/nsx_64_api.pdf
A partir de la página 460 tenemos documentación sobre SSL VPN.

6. Revisamos la respuesta.
Como la respuesta es en JSON podemos parsearla usando esta herramienta https://jsoneditoronline.org/

De este modo podemos conectarnos a la API de NSX para administrar SSL-VPN en nuestros edges.

¿Que tener en cuenta a la hora de implementar vSphere?

by

Hace algunos meses que estoy entrando día a día a VMTN (VMware Communities) y veo que muchas de las preguntas son del índole de ¿Puedo instalar ESXi en X hardware? o Instalé vCenter y no anda como espero.
Muchos de esos posteos son de usuarios que están probando vSphere por primera vez o de gente que no es nativa de la virtualización, no obstante, este post tiene como objetivo ayudar a todos los que están dando sus pasos en el mundo de la virtualización.

Diseño

La parte más importante de cualquier proyecto, en cualquier rubro, es el planeamiento.
Cuanto más tiempo pongamos planeando las cosas menos vamos a tener que poner arreglando problemas derivados de diseños fallidos.
Te dejo algunas preguntas que podes hacerte a la hora de empezar un proyecto de vSphere.

Análisis inicial

¿Para que quiero hacer esta implementación? Puede ser que quiera hacer un recambio de hardware por obsolescencia, puede ser que quiera desarrollar un proyecto de Hybrid Cloud o algo similar.
De este análisis inicial van a salir los requerimientos iniciales del proyecto, por ejemplo:
¿Cuántas VMs vamos a alocar en nuestros clusters?
¿Qué máquinas van a correr en mis clusters? No es lo mismo a nivel recursos correr un cluster de VDI que un cluster de Kubernetes o una base de datos Oracle.
¿Cuántos datos podemos ubicar en nuestro storage?
¿Puedo aceptar contención de recursos?
¿Cuánto voy a crecer por año?
¿Necesito un solo sitio? ¿Necesito más de un sitio?

Hardware

Un proyecto de virtualización depende del hardware que se use, algunas de las preguntas que podemos hacernos antes de adquirir el hardware son:
¿Qué tipo de servidores vamos a usar? (Blades/Rackeables/HCI) ¿Vamos a adquirir hardware nuevo? ¿Vamos a actualizar el hardware existente?
¿Cuántos CPU’s necesitamos? ¿Qué procesadores vamos a usar? ¿Cuántos cores voy a tener?
Estas primeras preguntas van a ser clave. Tené en cuenta que dentro de un mismo cluster lo ideal es tener hosts de la misma versión de ESXi y que los procesadores sean de la misma marca y familia (por EVC)
¿Cuánta memoria necesitamos?
¿Cuántas NICs necesito? ¿Cuántas HBA? Como mínimo siempre 2 para tener redundancia
¿Qué versión de vSphere voy a implementar?
¿Necesitamos algún tipo de hardware especial? (Placas de video, Hard Tokens, etc)
¿Tengo lugar en el datacenter? ¿Tengo suficiente capacidad en los racks? ¿Me alcanza la capacidad de computo? ¿Tengo puertos libres en los switches?
¿Dónde voy a instalar mi host? (Disco Local, SATADOM, SD, etc )
¿Voy a armar RAID para los discos locales? ¿Qué RAID?

Algo que me parece super importante aclarar, no podemos ir a instalar ningún servidor sin antes haber chequeado la matriz de compatibilidad (más ahora, ya que vSpher 7 no usa más los drivers VMKlinux como en versiones anteriores). Si nuestro proyecto usa vSAN podemos chequear la matriz de compatibilidad de vSAN o usar hardware vSAN ready.

Storage

¿Qué tipo de storage vamos a usar? (SAN/iSCSI/vSAN/NFS)
¿Vamos a adquirir hardware dedicado o tenemos que usar el hardware existente?
Cada tipo de storage tiene sus ventajas y sus limitaciones, por ejemplo, el storage SAN suele sumar complejidad a la administración (Zoning), mientras que iSCSI es más sencillo.
SAN tiene una red dedicada (con su propio protocolo) mientras que vSAN, iSCSI y NFS usan la red LAN. Por consiguiente, sumando tráfico a las NICs del servidor.
¿Necesito una solución metro?
¿Tengo suficientes puertos de SAN disponibles? (si es que los uso)

Networking

Algunas de las preguntas importantes a nivel redes
¿Voy a usar NSX?
¿Cuál es el troughput de mis equipos?
¿Cuántas VLANs administro?
¿Cómo está configurado MTU?
¿Tengo configurado CDP o LLDP?
¿Voy a usar algún mecanismo para prevenir loops (STP)?
¿Tengo suficientes puertos disponibles en los switches de red?

Estas respuestas nos van a decir como tenemos que configurar nuestros switches de vSphere.

vSphere

¿Qué servicios voy a necesitar? ¿Voy a tener solo ESXi? ¿Voy a tener vCenter? ¿vSAN? ¿vROPs?
¿Necesito más de un vCenter?
¿Necesito priorizar la disponibilidad?
¿Mis aplicaciones pueden tolerar un reinicio o no es aceptable?
¿Cuántos hosts caídos puedo tolerar?
¿Cómo van a bootear mis hosts? (Stateless vs Stateful)

Esta información te va a ayudar a determinar, entre otras cosas, cual es la licencia que necesitas.

Estas son algunas (porque siempre hay más) de las preguntas que tenemos que hacernos para empezar a diseñar una solución de vSphere que sea de calidad y resiliente a fallos.

A la hora de la implementación yo tengo este checklist para validar que todo esté listo para instalar y evitar perdidas de tiempo.

Una aclaración importante: Que algo no esté soportado en la matriz de comptabilidad significa que VMware no te va a aceptar los casos de soporte, no que no va a funcionar.
Por ejemplo, correr ESXi en modo nested no está soportado y se recomienda no correr VMs productivas, pero si lo usas para laboratorios está perfecto.

Espero te haya servido
Saludos

Nacho

¿Cómo configurar un proxy en Docker?

by
The what and why of Docker. A Beginner's guide to Docker — how to… | by Shanika Perera | Towards Data Science

Hace un par de semanas estuvimos trabajando con Docker.
El trabajo era bastante sencillo pero me volví loco buscando como configurar el proxy en Docker y lograr que funcione, ya que sin eso no podía salir a buscar la imagen al repositorio de imágenes.

Tenemos dos opciones, crear un drop-in o modificar los archivos de configuración. Ambas son igual de validas, personalmente me inclino por la primera.

Crear un drop-in

1. Ejecutamos el siguiente comando para crear el drop-in
sudo mkdir /etc/systemd/system/docker.service.d

2. Creamos un archivo que agregue la configuración de HTTP_PROXY y HTTPS_PROXY en /etc/systemd/system/docker.service.d/http-proxy.conf

[Service]
Environment="HTTP_PROXY=http://USUARIO:PASSWORD@IP_PROXY:PROXY_PORT/" Environment="HTTPS_PROXY=https://USUARIO:PASSWORD@IP_PROXY:PROXY_PORT/"
Environment="NO_PROXY= hostname.example.com,1.2.3.4"
Un ejemplo de esto sería: Environment="HTTP_PROXY=http://nachogon:PASSWORD@1.2.3.4:8080/"

3. Reiniciamos los servicios de systemd y docker

sudo systemctl daemon-reload && systemctl restart docker

Con estos pasos ya deberíamos tener configurado el proxy en Docker. Podemos validarlo haciendo un docker pull desde algún repositorio público.

Modificar el archivo de configuración:

Lo que tenemos que hacer es agregar las siguientes líneas al archivo /etc/sysconfig/Docker con los valores correctos.

export HTTP_PROXY="http://USUARIO:PASSWORD@IP_PROXY:PROXY_PORT”

export HTTPS_PROXY="https://USUARIO:PASSWORD@IP_PROXY:PROXY_PORT”

Una vez agreguemos esas líneas, reiniciamos docker:

sudo service docker restart

Con esto ya estaría configurado el proxy para poder pullear imágenes de internet.

Pasando de NSX-V a NSX-T

by

A fines de 2018 me tocó ser  parte de un proyecto que requería que aprenda y certifique toda la suite de NSX, en Enero de 2019 terminé de certificar el examen VMware Certified Advanced Professional – Network Virtualization 6 (Deploy) y pude trabajar con eso por algunos meses.
Entre abril de 2019 y mayo de 2020 estuve alejado de NSX por motivos laborales, durante ese año VMware decidió discontinuar la versión del producto que yo conozco (NSX-V) y darle foco a NSX-T, acompañando su visión Any App, Any Device, Any Cloud.
Para no quedarme atrás estuve investigando, y algo que me sirve a mi es hacer paralelismos con lo que entiendo.
En algunas líneas quiero compartir cuales son las diferencias entre NSX-V y NSX-T para que puedas “pasar tu conocimiento” haciendo algunas equivalencias y/o diferencias.

Arquitectura

Al igual que en NSX-V, NSX-T Cuenta con 3 planos (Management, Control, y Datos) pero en esta nueva versión hay algunas diferencias.

This image has an empty alt attribute; its file name is image-9.png

Management Plane

El Management Plane es el encargado de la administración de NSX. En NSX-V era un solo appliance (OVF) que después se registraba contra vCenter y hacia el deploy del control plane y preparaba los hosts, manteniendo un mapeo 1 a 1 entre el vCenter y el NSX Manager.
El deploy de NSX-T comienza del mismo modo (instalando un appliance) pero no requiere un vCenter para funcionar.
Adicionalmente ahora el NSX Manager está distribuido en un cluster de 3 virtual machines.
En la tabla a continuación podemos ver algunas diferencias entre ambos productos:

Sin embargo, el NSX Manager (Cluster) sigue siendo responsable de preparar hosts, crear nuevos logical switches, crear VMs de NSX Edge, al igual que proveer la API y la línea de comandos centralizada.

Control Plane:

La mayor diferencia entre NSX-V y NSX-T en relación al plano de control es el hecho de que ahora corre en las mismas  máquinas que el management Management Plane.
Adicionalmente al no existir el concepto de Distributed Logical Router, la máquina de control del DLR no es necesaria.

Plano de datos – Encapsulación y Switching:

La mayor diferencia entre NSX for vSphere y NSX Transformers a nivel encapsulación dejamos de usar el protocolo VXLAN y pasamos a usar el protocolo GENEVE.
Adicionalmente, NSX-V requeria MTU 1600 para funcionar y ahora requiere 1700.
A continuación dejo algunos detalles extra:

Respecto a los distributed switches, para NSX-T solo en entornos VMware se recomienda usar vSphere vDS, si vamos a usar KVM estamos limitados a usar N-VDS.

Plano de datos – L2 Bridging:

Una vez más, al no existir la VM del DLR, el Bridging se modifica y se crean los bridge nodes (dentro del kernel para los hipervisores).
Adicionalmente podemos crear bridge clusters para proveer redundancia.

Plano de datos – Routing:

Estas son algunas de las diferencias entre NSX-V y NSX-T a nivel routeo.

Esto me costó un poco entenderlo:
Tanto el Service Router como el Distributed Router existen dentro de los logical routers (T1 y T0)
Es decir, en un Logical Router T0 vamos a tener un componente del Distributed Router y un Componente del Service Router:
– El distributed router vive en el kernel de todos los hipervisores (al igual que el DLR)
– El service router vive en los edge nodes (debido a que hay servicios Norte-Sur que no son distribuidos, por ejemplo: NAT)

Adicionalmente, los Logical router Tier-0 corren sobre los recuirsos del Edge Cluster.

Plano de datos – NSX Edge

Ahora cada vez que creas un NSX Edge, vas a necesitar un NSX Edge cluster, como decíamos antes los Logical Router Tier-0 corren en los recursos del Edge Cluster, por más que tengas un solo NSX Edge, necesitas crear un Edge Cluster.
Otro cambio importante a nivel NSX Edge es que ahora podemos instalarlo sobre servidores bare metal y no solo como VMs. Esto es sumamente interesante si tenemos en cuenta el partnership de VMware con Nvidia, Project monterey y el avance de ESXi on ARM, ¿Te imaginas corriendo un NSX edge en un raspberry pi?, no es algo tan lejano.

Seguridad

Algunas de las mejoras a nivel seguridad.

Cabe aclarar que el identity firewall solo funciona con VMs windows que tengan active directory (Windows 10 y Windows 2019 están soportados)

Migración

De momento exiten dos modos de migración:
Migración en paralelo: en otras palabras significa tener NSX-V y NSX-T en paralelo, esta opción está buena si aprovechamos un recambio de hardware o un upgrade de versión.
La migración In place sirve para entornos que es dificil el recambio, esto es un estilo Lift and Shift.

2 Methods for VMware NSX Migration

VMware recomienda contactar a PSO para revisar los pasos previos a la migración.

Conclusión

Por más que NSX for vSphere es un producto super robusto, está limitado al SDDC de VMware vSphere.
NSX-T es un producto concebido para el Multi-Cloud, teniendo en cuenta productos Cloud Native como Kubernetes.
Como se prevee que para 2025 el 60% de las empresas van a tener sus Workloads en la nube, sería una buena idea empezar a considerar NSX-T para llegar al Multi-Cloud

Espero que te haya servido, por favor comentame que te pareció.

Saludos
N.