Todas las entradas de Guillermo

Esta entrada podría haber sido publicada en el bloque de “Nuestro amigo el docker” https://seguridadzero.com/nuestro-amigo-el-docker , sin embargo, al ser una entrada especifica de seguridad he preferido ubicarla aquí.

Nota: Si alguien quiere conocer mas sobre vuestros “pantalones” (Dockers J) le aconsejo que visite le bloque de “Nuestro amigo el docker”.

Slaxx es una película que trataba de unos pantalones “asesinos”. Igual que en Slaxx, nuestros “pantalones” pueden “matar” la seguridad de nuestro sistemas si no se encuentran bien securizados.

Antes de empezar a hablar de la seguridad en Dockers (o contenedores) os daré unas pequeñas “pinceladas” de cómo se crean y lanzan estos contenedores para que no os perdáis al entrar en el apartado de seguridad. Esto esta muy detallado y explicado en el bloque comentado de dockers.

Un repaso rápido

La instalación de docker (community edition) en una maquina (virtual o física) Linux (Ubuntu) se compone de las siguientes instrucciones:

Para crear imágenes podremos descargarlas ya creadas (Docker Hub) o emplear un archivo “dockerfile” o “compose”

Dockerfile

Un “dockerfile” es un archivo de texto donde se establecen una serie de comandos (similares a un pseudo Linux) que hace que el cliente docker (el docker que corre en nuestra máquina) los ejecute cuando crea una imagen. Obviamente las imágenes se basan en otras imágenes (como ya se ha explicado) como puede ser una imagen de Ubuntu o Phyton (como en nuestro ejemplo). Estas imágenes “base” tienen las funcionalidades necesarias para luego “añadirle” otras en nuestra imagen “customizada”.

Un ejemplo para crear una imagen a través de un “dockerfile” muy simple con base una maquina Ubuntu 16.04 sería el siguiente archivo:

La explicación de este archivo es casi obvia, creamos una imagen de Ubuntu 16.04 al que le forzamos a actualizarse y a que se instale apache (“-y” significa que a todas las preguntas diga SI), que en la página web muestre un mensaje de bienvenida (siempre recogida en index.html) y que estará disponible (se expondrá) en el puerto 80.

Así, para construir nuestra imagen (obviamente la máquina de Ubuntu se obtiene de Docker Hub) ejecutamos el siguiente comando docker build -t ubuntutest .

Hay que tener claro que “-t” se refiere a “tag” (para poner el nombre a la imagen) y que el “.” final es necesario para decirle que lea el “Dockerfile” para crear la imagen en el propio directorio donde estamos.

Finalmente, con el comando docker run -d -p 80:80 ubuntutest /usr/sbin/apache2ctl -D FOREGROUND lanzamos el contenedor de la imagen creada forzando a que arranque el servidor apache (en background ya que un docker necesita ejecutar en primer plano el proceso principal “Ubuntu” y en background el resto) en el puerto 80. Cuando se encuentre en ejecución nos devuelve un UUID (identificador único universal) que se corresponde al contenedor ejecutándose.

COMPOSE

El archivo “docker-compose.yml” es un archivo que define como se ha de comportar un servicio (de varios contenedores Docker) en producción (es decir “corriendo”). Un ejemplo de archivo “compose.yml” es el siguiente:

El ejemplo anterior genera 5 réplicas de un container (servicio) asignándole 0,1 de CPU y 50 Mb de RAM a cada réplica. Lo más interesante es la respuesta en caso de fallo (condition: on-failure) que reinicia el contenedor que falle. Además, se mapea el puerto 4000 al 80 balanceando la carga en una red que se ha llamado “webnet” (podríamos haberla llamado de cualquier otra manera) esta red permite gestionar la carga entre los contenedores. El balanceo puede ser “leastconn”(el que tenga menos conexiones) o “roundrobin” (por defecto).

Para usar el archivo “docker-compose.yml” lo podemos hacer de 2 maneras:

• Como un archivo que crea unos contenedores como servicios: En este caso se ejecuta con las siguientes instrucciones:
  • docker-compose up — > Da instrucciones a Docker para crear el contendor, y ejecutarlo según docker-compose.yml (busca ese archivo por defecto).
  • docker-compose down — > Apaga todos los servicios que levantó con docker-compose up.
  • docker-compose ps — > Permite ver los contenedores funcionando.
  • docker-compose exec — > Permite ejecutar un comando a uno de los servicios levantados de Docker-compose.
• Como archivo para levantar un stack (Swarm). Un Swarm es una ”colmena” de hosts donde se ejecutan contenedores con una sola URL para todos (balanceo de carga).

La seguridad en Dockers

Hasta ahora no se ha hablado específicamente de la seguridad que nos brindan los contenedores y que se consigue (a parte de su aislamiento como cualquier otra maquina virtual) a través de las siguientes funcionalidades que residen en el kernel de Linux y que podemos aprovecharnos al lanzar contenedores:

• Namespaces — > Los namespaces permitirán espacios aislados para los procesos que contienen, lo que protege el sistema de acciones que suceden en el interior de la sandbox creada. Es decir que podremos permitir a un usuario ejecutarse en el “interior” del contenedor como “root” pero como un usuario sin privilegios especiales fuera de ese contenedor.
• Cgroups (Control Groups) — > Los control groups, permiten gestionar los recursos que se atribuyen a ciertos procesos, siendo posible de este modo asignar límites cuantitativos de CPU, memoria, acceso a disco, etc. Esto es muy útil para asegurar que el sistema no pueda ver comprometidos sus recursos. Es decir que asignamos unos recursos específicos dentro de un contenedor específico.
• Usuario con privilegios para lanzar el demonio Docker — > El Docker daemon debe ser lanzado por un usuario con privilegios “root” o un usuario dentro del grupo “docker” que no sea root.
• Capabilities — > Las capabilities son propias de un kernel Linux en el que permite ciertas acciones en su entorno, pero no fuera de él. Es decir permite ejecutarse las acciones específicas dentro del kernel del host anfitrión pero podemos limitar esas capacidades para que solo se ejecuten en un contenedor pero NO en el kernel del host anfitrión.

Usuario con privilegios para lanzar el demonio Docker

En los ejemplos vistos hasta ahora no se ha puesto de manifiesto que la ejecución de los comandos de docker necesitan permisos de root (o sudo). Lo ideal es crear un usuario específico para poder lanzar y crear nuestros contenedores. Para crear un usuario docker específico para la ejecución de sus comandos se puede realizar lo siguiente:

• Crear o usar un usuario con privilegios de “root”.
• Crear (si no existe ya) el grupo docker — > sudo groupadd docker
• Añadir el usuario anterior (estamos logados en el) al grupo docker — >   sudo usermod -aG docker $USER (La variable $USER es el usuario que estamos empleando en la consola).
• Reboot (Reiniciar el equipo).

Capabilities

Podemos ver las capacidades de nuestros usuarios con el comando pscap | head -10 con esa consulta en nuestro host vemos los siguiente:

Ahí vemos que el usuario “root” tiene diferentes capacidades como chown, syslog, etc… según sea el proceso que este ejecutándose (PID).

¿Cómo podemos “limitar” esas capacidades al lanzar un contenedor?

Podremos a través del comando de la imagen siguiente en el cual solo queremos que se ejecuten las capacidades “setuid” y “setgid” en el kernel del host anfitrión.

Como vemos con “–cap-drop=all” eliminamos todas las capacidades y las añadimos con “–cap-add=”.

Una forma útil de emplear esta restricción de capacidades es la de usar “atomic” (herramienta) para ejecutar imágenes que tengan en su creación (en el Dockerfile) unas etiquetes (Labels) que eliminen o añadan capacidades.

Cgroups

Los recursos (CPU, memoria, redes, disk i/o, etc.) empleados en los contenedores pueden dejar bloqueado un host sino se limitan adecuadamente. Como ya sabemos, la limitación de recursos es una medida de seguridad para que los contenedores no consuman todos los recursos de un host y puedan bloquear al resto de contenedores.

Existen varias maneras de limitar los recursos:

• En la propia ejecución del contenedor — > A partir de docker engine 1.13 se puede lanzar un contenedor con $docker run -it –cpus=».5″ ubuntu /bin/bash en el que se limita ese contenedor al consumo de 0,5 del recurso de la CPU (esto mismo se puede hacer con la memoria)
• En el archivo docker-compose.yml — > Como ya hemos visto, existen restricciones del tipo:

        limits:

          cpus: ‘0.50’

          memory: 50M

        reservations:

          cpus: ‘0.25’

          memory: 20M

Donde se limita un “techo” de 0,5 en CPU y de 50 MB en memoria con una reserva de (al menos) 0,25 y 20 MB respectivamente.

• A través de cgroups — > Un cgroup es una característica o servicio proporcionado por el kernel de Linux. Esta caracteristica permite crear un grupo de control (control group o cgroup) con unas limitaciones de recursos para luego aplicar ese cgroup al contenedor. Esta forma es un poco más laboriosa que las dos anteriores con lo que se aconseja emplear las dos anteriores.

Namespaces

Existen 6 tipos básicos de namespaces relacionados con distintos aspectos del sistema:

• NETWORK namespace — > Aislamiento de red. Así, cada namespace de red tendrá sus propios interfaces de red, direcciones de red, tablas de enrutamiento, puertos de red, etc.
• PID namespace — > Aísla el espacio de identificadores de proceso. Un contenedor tendrá su propia jerarquía de procesos y su proceso padre o init (PID 1).
• UTS namespace — > Aísla el dominio y hostname, permitiendo a un contenedor poseer su propio dominio de nombres.
• MOUNT namespace — > Aísla los puntos de montaje de los sistemas de ficheros que puede ver un grupo de procesos. Este namespace fue el punto de partida que nació con chroot.
• USER namespace — > Aísla identificadores de usuarios y grupos. Así dentro un contenedor es posible tener un usuario con ID 0 (root) que se corresponda con un ID de usuario cualquiera en el host.
• IPC namespace — > Aísla la intercomunicación entre procesos dentro del espacio.

La forma más efectiva de prevenir ataques de escalamiento de privilegios desde un contenedor es configurar las aplicaciones de su contenedor para que se ejecuten como usuarios sin privilegios, es decir aplicar un “USER namespace”. Así, para los contenedores cuyos procesos deben ejecutarse como usuario “root” dentro del contenedor se puede “mapear” a este usuario con un usuario con menos privilegios en el host anfitrión de Docker. Al usuario asignado se le asigna un rango de UID (0- 65536) que no tiene privilegios en la máquina host (tened en cuenta que un UID = 0 es el de “root”).

Para realizar lo anterior podemos crear un un archivo llamado “daemon.json” y que se emplea en el arranca del contenedor. En su arranque se remapea el usuario para docker de tal manera que dentro del contenedor se comporta como “root” pero fuera tendar un UID de menor privilegio.

En la siguiente imagen el usuario de dentro del contenedor NO puede modificar un archivo que necesita privilegios de root fuera del contenedor (incluso aunque acceda a él).

Y eso es todo, espero que os haya resultado interesante esta entrada de seguridad aplicada a contenedores.

geropa!!!!

En la anterior entrada (El mundo de los replicantes (Parte I)) vimos las características de Nessus Pro y ahora vamos a ver esta herramienta de una manera más práctica.

Entonces como puedo usar Nessus?

Aquí os mostrare como y para que uso yo Nessus. Eso no quiere decir que no existan otro tipo de capacidades o usos de esta increíble herramienta.

Paso 1. Elije: Wax dentro, Wax fuera (es una frase de la película Desde Paris con amor)

Si, debes de elegir si quieres hacer un escaneo desde el punto de vista de un atacante externo o desde el punto de vista de un “insider” (muy interesante). Además, lo ideal es hacer ambos si vas a “sufrir” un auditoria o pentest de seguridad por una empresa externa.

Aquí os mostrare como y para que uso yo Nessus. Eso no quiere decir que no existan otro tipo de capacidades o usos de esta increíble herramienta.

Paso 2. Crear tu propio escaneo o usar una plantilla

Cuando quiero crear un nuevo escaneo de vulnerabilidades, voy a My Scans >> New Scan >> Advanced Scan. Sin embargo, en ocasiones, prefiero usar una plantilla que me ofrece Tenable como la tan famosa “Log4Shell Vulnerability Ecosystem”.

En este ultimo caso (Log4Shell) es una plantilla con todos los plugins necesarios asociados para buscar esa vulnerabilidad. De hecho, no tienes que preocuparos por añadir los nuevos plugins relacionados con Log4j sino que se van incluyendo automáticamente a esta plantilla cuando actualizáis Nessus.

Por cierto, alguno os podéis preguntar que es eso de “Plugin”. Un plugin es una archivo con código escrito en lenguaje propietario de Nessus (NASL) donde se encuentra información para detectar la vulnerabilidad correspondiente, acciones de remedio y un algoritmo que detecta esa vulnerabilidad concreta.

Paso 3. Configura tu escaneo

El “Advanced Scan” debe ser configurado conforme a tus necesidades. Para ello disponemos de tres pestañas con varias opciones dentro de cada una de ellas.

• Pestaña “Settings”(mas info en https://docs.tenable.com/nessus/Content/TemplateSettings.htm)  en ellas se encuentran varias opciones para “ajustar” tu escaneo con la intención de hacerlo mas adecuado a tu entorno (tu red ICT). Las opciones aquí son infinitas, y no se pueden explicar todas, pero yo me detendría en dos de ellas principalmente (existen muchas opciones para ajustar tu escaneo al objetivo que buscas) como son dentro de “Assessments”:
  • Web Applications — > Opción muy interesante para comprobar vuestra aplicaciones web a través de Nessus. Ten en cuenta que esto añade parámetros de búsqueda para un servicio web a todos los plugins activos.
  • Malware — > Donde yo incluyo reglas Yara, pero que además se pueden incluir listas de específicos hashes o de IPs. Bueno y que es eso de las reglas Yara? Pues son reglas (vaya descubrimiento!!!) que ayudan a los motores de búsqueda a encontrar específicos patrones relacionados, en este caso, con vulnerabilidades. Las reglas Yara las podéis crear vosotros o utilizar las que muchos profesionales de ciberseguridad proporcionan gratuitamente (normalmente en github). Un par de ejemplos son las que crea Fireeye o Florian Roth (muy activo en este campo). En la imagen siguiente veis que yo he cargado una de Florian de Log4j donde dice en su descripción: “Detects IOCs found in Log4Shell incidents that indicate exploitation attempts of CVE-2021-44228”. Interesante, eh?

• Pestaña “Credentials”: Aquí deberíamos de considerar que los resultados que vayamos a obtener van a depender mucho de si hacemos el escaneo con credenciales o sin ellas. Si es posible, yo recomiendo hacerlos con credenciales, ya que los resultados son mas óptimos desde el punto de vista de “Blue Team”. Sin embargo, usando Nessus como herramienta de descubrimiento de vulnerabilidades como “Red Team” , obviamente, lo usaremos sin dichas credenciales. Existen tres tipos de credenciales:
  • SNMPv3 — > Para aquellos sistemas que usen esta versión de SNMP y que queramos escanear con las credenciales correspondientes.
  • SSH — > En general, usado para acceso a dispositivos Linux (al menos en el entorno de red que yo protejo). Esta opción nos permite varias posibilidades, como usar un usuario root (no es muy conveniente habilitar un login SSH como root, pero vosotros mismos….) o como usuario normal y, luego, elevando privilegios (si, ya sabéis, lo de “sudo”).
  • Windows — > Normalmente o basada autenticación a través de otros servicios (Kerberos o NTLM –no muy recomendado-) o a través de un password para un dominio especifico.

De nuevo remarcar que las credenciales deben de permitirnos ejercer acciones de super-usuario (tipo sudo o administrador) sino, le escaneo será limitado por los permisos de ese usuario.

• Pestaña “Compliance”: Usada por si debemos ajustar nuestro escaneos a “cumplimientos” con determinados estándares como pueden ser de Windows, Cisco y otros fabricantes (también las hay para servicios on cloud como AWS o Azure). Si esto os parece un poco confuso os pongo un ejemplo. Una compliance de Windows podría ser que la longitud mínima de un password sea de (por ejemplo) 8 caracteres. Todas estas compliances las podes “ajustar” a vuestras necesidades.
• Pestaña “Plugins”: Aquí es donde viene “la madre del cordero”. En “Advanced Scans” tenéis todas las familias de plugins activadas por defecto (unas 60 actualmente) y dentro de cada familia pueden existir mas de 18000 plugins. Una locura, verdad? Pues eso, tenedlo en cuenta que si todo vuestro entorno es Windows o Linux, lo ideal es deshabilitar aquellas familias o plugins que no necesitéis para que el escaneo no se eternice.

Paso 4. Lanza tu escaneo

Existen básicamente dos formas de manera puntual o periódica (repetitiva, muy interesante).

Con respecto a la manera periódica, deciros que un uso muy útil de Nessus es buscar IoCs (Indicadores de Compromiso) con reglas Yara de manera periódica hasta que tengáis todos vuestros equipos parcheados ante una vulnerabilidad incipiente (tened en cuenta que alguno productos tardan en sacar sus “parches” de seguridad semanas). Para hacer esto vais a Settings >> Basic >> Schedule.

Paso 5. Espera y crea tu informe

Finalmente, podemos ver los resultado directamente en Nessus (se quedan guardados clicando en el propio escaneo) y, además, crear un informe (Report) en múltiples formatos (csv, pdf o html) en el que podemos ver todos los detalles o solo los mas relevantes y (muy importante) ver las recomendaciones de como resolver nuestras vulnerabilidades.

Paso 6. Verifica las vulnerabilidades y a currar!!!!

El ultimo paso es verificar las vulnerabilidades descubiertas. Un ejemplo de “falso positivo” es que nos descubra una librería de Log4j vulnerable pero que no este realmente activa (por ejemplo sea un archivo de backup). Otro ejemplo son parches de un sistema operativo no aplicado (como Windows) pero que Microsoft (en este caso) ha visto que genera problemas de estabilidad si se aplican y, saca otro sin “avisar” que ese parche ya no es necesario para subsanar las vulnerabilidades, sino que el nuevo es suficiente (eso también puede pasar y ha pasado).

Cuando verifiques las vulnerabilidades, ya solo te queda currar y solventar todos tus posible «agujeros de seguridad”.

Espero que os haya gustado este paseo por el “Mundo de los replicantes”.

geropa!!!!

Quién no quedó impactado la primer vez que vio Blade Runner y la trama de los replicantes Nexus-6, yo soy no de ellos a los que esa película le marco su memoria.

Después del repaso cinematográfico de Nexus-6 voy a hablar de una herramienta homófona al modelo de replicantes tan famoso, Nessus.

Pues con nuestro “Nessus” también podemos decir eso de “Yo he visto cosas que vosotros no creeríais. Atacar naves en llamas más allá de Orion,. He visto rayos C brillar en la oscuridad cerca de la puerta de Tannhäuser. Todos esos momentos… se perderán como lagrimas en la lluvia…..”.

Pues sí, Nessus es una herramienta asombrosa que vosotros (sino lo habéis usado antes) “no creerías lo que veis”. Esta herramienta, sin embargo, esta algo subestimada, no se si por su bajo precio (alrededor de 3000 euros/año, lo cual en este mundo no es mucho) o por su simple interfaz o facilidad de ejecución.

En mi caso, he aprendido a apreciar esta herramienta y valorarla como lo que es, una gran ayuda para ver las vulnerabilidades que presenta un sistema. Aun así, con Nessus, me quedo corto si solo la considero como tal.

Nessus es uno de los productos estrella de Tenable, una reputada compañía de productos de seguridad. La verdad es que Tenable no solo ofrece unos grandes productos de ciberseguridad, sino que mantiene dichos productos con los mas actualizados datos de vulnerabilidades, exploits y tácticas y técnicas de ataque para poder ser prevenidos de nuestras vulnerabilidad y remediarlas. Yo, tengo que confesar, que una de las fuentes de alertas que uso sobre nuevas vulnerabilidades es, precisamente, Tenable.

Lo que hace que Nessus Professional -Pro- (Nessus Por o solo Nessus, a partir de ahora), sea una herramienta de la cual no puedo prescindir es por los siguiente (entre otras):

• Funciona como aplicación instalada en un equipo como puede ser un portátil, un servidores, etc.
• La puedo ejecutar como un servicio “on-premise”. Cosa importante sino quieres depender (o no puedes, por motivos de seguridad) de un servicio en la nube.
• Es muy flexible en cuanto a su licencia (lo comentare mas adelante).
• Puedes crear tu propios escaneos ajustados a los tipos de sistemas y dispositivos que manejes y, obviamente, a la lógica de tu negocio.
• No solo comprueba vulnerabilidades, sino también
• Su actualización de plugins es brutal.
• Su interfaz y su facilidad de uso es extremadamente sencilla pero, además, sus opciones de escaneo son increíbles, pudiendo (por ejemplo) integrar reglas especificas (lo comentare mas adelante).
• Prioriza las vulnerabilidades, haciendo que pongamos el foco en aquello mas urgente.
• Sus plantillas (Templates) son una gran ayuda para aquellas vulnerabilidades mas criticas y que mas impactan en los sistemas por el mundo.
• Sus informes son muy configurables y detallados.
• Podéis probarla gratuitamente.

Vaya, parece que quiero “venderos” esta herramienta. Pues no es así, también os diré alguna cosa “mejorable”:

• Por defecto mantiene la sencillez, lo cual es bueno, pero puede hacer que nuestros escaneos se “eternicen”. Daros cuenta que por defecto podría usar todos los plugins, mas de 150.000 actualmente!!!
• Sino tienes los plugins actualizados la herramienta funciona igual, pero los resultados serán sí o sí engañosos. Lo ideal es tener una licencia activa y actualizar SIEMPRE los plugins antes de empezar a hacer un escaneo. Una cosa interesante de la licencia, es que se puede cambiar de un dispositivo a otro muy fácilmente, posibilitando (con un sola licencia) ejecutar escaneos de manera interna o externa sin pagar dos licencias.
• Te detecta mucho, muchísimo, a veces se pasa. Es tan buena esta herramienta que quizás una de sus mayores debilidades es la cantidad de positivos que te puede mostrar y que debes de analizar por que son “falsos positivos” (ejemplo con archivos Log4j). De todas formas ten en cuenta que siempre es mejor un falso positivo que un falso negativo.
• La carencia de una actualización en un sistema puede mostramos decenas de vulnerabilidad diferentes para un mismo escaneo de Nessus, y con un simple parche desaparecerían todas las vulnerabilidades mostradas (esto, a veces, es algo confuso).
• Por lo anterior, demanda un análisis  o verificación de las vulnerabilidades encontradas antes de pasar la “patata caliente” a otro colega de tú equipo de IT.

Teniendo todo esto en cuenta, para mi Nessus Professional NO solo es un escáner de vulnerabilidades per se, sino una herramienta con la que vigilar y coordinar el “estado de salud” de mis sistemas (mi red ICT), lo cual hace que la use de una manera profusa y continua.

Ahora viene la pregunta de examen….. Nessus pro o Tenable.sc? (aquí solo considero productos 100% on premise).

Bueno, pues depende……. Nessus Pro es muy bueno y relativamente económico. Tenable.sc es muy bueno también (un poquito mejor, con mas funcionalidades) pero con dos pequeñas “pegas”. Tenable.sc se paga por numero de elementos escaneados en bloques de 512 elementos y, además, requiere (para sacar su máximo potencial) el uso de agentes.

Si vuestros equipos ya andan un poco “sobrecargados de agentes” (antivirus, agentes de logs, de gestión de elementos y software, etc) quizás no sea la mejor solución añadir otro agente “al lote”. Lo que si es cierto es que Tenable.sc es una solución mas completa y con mas funcionalidades que Nessus Pro , pero “basada” en Nessus Pro. Por otro lado, Tenable.io es una solución de gestión on-cloud (y la ultima y mas avanzada).

Lo ideal es empezar a “currar” con Nessus Pro y luego decidir que es lo que te conviene en tu entorno mirando temas como el coste, escalabilidad, el uso que le vais a dar a a la herramienta y las necesidades de esas “avanzadas” características.

Continua en la Parte II de los replicantes.

geropa!!!!

ἓν οἶδα ὅτι οὐδὲν οἶδα, hèn oîda hóti oudèn oîda, esta frase es confusa hasta en griego y la hemos oído todos sin entender muy bien que el principio del aprendizaje es reconocer tu propia ignorancia sobre algo.

En ciberseguridad yo tengo esa impresión todos los días (os doy mi palabra). Llevo en el mundo le tecnología (ó IT) casi 20 años, los últimos 6 orientado hacia la ciberseguridad en uno u otro cargo y cuando alguien que no pertenece a este mundillo me dice: “tu debes de haber aprendido mucho, sabrás un montón de cosas de hackers y de esas….”. La verdad es que me inunda un profundo sentimiento de “y yo como se lo explico ahora”, “que le puedo contar sino tengo ni idea de hackear” (por ejemplo).

Pues eso es lo que hay, sin paliativos, sin paños calientes “solo se que no se nada”. Realmente la ciberseguridad es tan increíblemente extensa que no se como explicar lo “poco” que si “podría” saber y la inmensidad que aun no se y que me queda por aprender.

Espera, un momento, como que no se nada?…Yo se de políticas de seguridad, de seguridad en redes, de seguridad en sistemas, de controles específicos de seguridad, gestiono herramientas como antivirus, de DLP (Data Loss Prevention), de encriptación, de monitorización de trafico, de gestión y monitorización de incidentes/eventos (que nunca es lo mismo, claro), de análisis de protocolos, de escaneo de vulnerabilidades, de borrados seguros, de análisis de riesgos y así muchas mas…

Muy bien, pero, eso que es mucho o poco?. Pues, la verdad, casi nada. Aunque tenga experiencia en el manejo y gestión (por ejemplo) de una herramienta SIEM nunca sabré tanto como un SOC/Security Analyst que esta exclusivamente utilizando la misma 8 o 10 horas al dia!!!.

Bueno, pues ya he asumido que se algo de muchas cosas, guay!. Y los que saben mas que yo (como el ejemplo del SOC analyst) que pasa con ello? Son superdotados o soy yo un “paquete” en ciberseguridad?. Pues ellos, sencillamente, cada día saben mas de menos para llegar a saber TODO de NADA. En eso consiste “especializarse” en el mundo de la ciberseguridad.

Volviendo al tema de cómo explico a alguien de fuera de este mundillo lo difícil y arriesgado que es decir aquello de “si, yo piloto sin problemas la ciberseguridad de mi empresa” (Hay que ser muy osado o ignorante para decir o creerse algo así), para poder hacer entender lo difícil que es esta profesión, en los momentos que me pregunta yo les pongo un ejemplo fácil de entender: “Oye, a que tu no irías a que te operara del corazón a un traumatólogo?, pues esto es lo mismo, pero mas exagerado, la ciberseguridad es vastísima y sino te especializas en algo, difícilmente te sentirás muy cómodo en una determinada área.

Ah!!!! entonces esto es como una especialidad de medicina, que cuando te especializas te vuelves un autentico erudito en esa materia….. Pues la verdad, es que tampoco (dudo también que esto suceda en la medicina, pero vamos a lo nuestro, a la ciberseguridad). En el ejemplo del SOC analyst, nuestro querido profesional de la ciberseguridad no esta haciendo todos los días un “sota-caballo-rey” en su trabajo diario. Por desgracia, debe saber (y mucho) de sus redes y de sus sistemas informáticos (o al menos de los que esta protegiendo), de cómo actúa el malware, de las tácticas y técnicas usadas en ataques, de eventos anómalos, técnicas de ocultación, etc. Es decir, que debe de tener un conocimiento solido de “casi de todo” en ciberseguridad también.

Bueno, entonces a donde llegamos con todo esto? A lo sencillo que es NO aburrirse en este mundo, de lo difícil y complicado que es mantenerse al día y que requiere estudiar, leer, compartir, formarte y sobre todo que te apasione este mundillo. Esta no es una profesión para gente acomodada, es para valientes, para gente con ganas de aprender, en definitiva para los que tengan claro que “saben que no saben nada” (todavía).

Como conclusión, difícilmente podrás especializarte en nada en la ciberseguridad sino tienes un conocimiento de todo aquello que rodea al “campo” que has elegido para ser un profesional avezado en ciberseguridad. Nota: Si quieres conocer un punto de vista personal de esta profesión y las diferentes opciones de especialización en ciberseguridad, visita: Una mirada al mundo de la ciberseguridad profesional

geropa!!!!

Para hablar de servicios de contenedores on-cloud se ha seleccionado AWS por ser la de mayor cuota de mercado entre todas ellas.

Anteriormente en esta misma web, hemos comentado que en AWS no se corresponden exactamente las definiciones de contenedor instancia e imagen. Sin meternos en profundidad en este tema podemos decir que existe la siguiente correspondencia:

• Imagen = Imagen (AWS)
• Contenedor = Tarea (AWS)
• Instancia = Servicio (AWS)
• Cluster/Swarm = Cluster (AWS)

Así pues, lo habitual es que en AWS para crear un servicio proporcionado por Dockers se sigan estos pasos (en ECS):

1. Creamos un cluster de recursos (EC2)
2. Creamos una Tarea (Task)
3. Creamos un servicio asociando Tasks (una o más task) a un cluster

Servicios que proporciona AWS con contenedores Dockers

Aunque en AWS existen múltiples servicios que utilizan (o pueden utilizar) contenedores en su despliegue (Como BeanStalk) lo cierto es que podemos desplegar contenedores de cuatro maneras posibles (estrictamente hablando):

1. Usando una AMI (MV EC2) y configurando todo lo necesario para poder generar contenedores dentro de dicha MV. Esta manera es la mas trabajos pero nos da un CONTROL TOTAL tanto d ellos servicios corriendo como de la MV subyacente.
2. Usando ECS (clásico). Este sistema usa MV EC2 “preconfiguradas” con el demonio docker (Docker CE) en el cluster que creemos y que nos ayuda a “orquestar” todos los contenedores gestionando también políticas de autoescalado no solo en los contenedores sino también en las propias MV’s. Esto tiene un coste técnico alto como el caso anterior y el control de todos los elementos es muy grande también.
3. Usando FARGATE. Es un poco “injusto” denominarlo como un servicio “separado” de ECS ya que es en el propio ECS donde se puede seleccionar una estructura “clásica” o de FARGATE. Este esquema es totalmente “serverless” solo necesito decirle la capacidad de lo que quiero y es AWS quien se encarga de aprovisionarme de las maquinas (o la computación) que requiero. Esta estructura es la mas simple de implementar pero perdemos algo de control sobre nuestra estructura (por ejemplo perdemos la capacidad de mapear nuestros puertos)

• Usando Kubernetes. Kubernetes es un software OpenSource que permite “orquestar” contenedores en cualquier plataforma donde esté instalado (on-prmise u on-cloud). Digamos que Kubernetes es una “suite” de herramientas con una interface bastante “amigable” de gestión, creación y control de nuestros servicios a través de contenedores docker. Su configuración no es trivial y es bastante mas compleja que los ejemplos anteriores, pero una vez está desplegada su gestión y adaptación a nuevos requerimientos es muy sencilla y a través de una GUI adaptada para ello. Su gran ventaja es que casi todas las plataformas on-cloud la implementan con lo que una vez nos habituemos a este entorno podremos manejarlo independientemente del proveedor del servicio (AWS, Azure, Google Cloud, etc…). Por último Kubernetes también nos ofrece la versión FARGATE.

Como ya os he comentado en los anteriores capítulos, un stack es un conjunto de servicios interrelacionados que comparten dependencias y que pueden ser dirigidos (orchestrated) y escalados juntos.

La verdad es que ya lo hemos estado realizando hasta ahora (recordar los comandos docker stack). Lo que ahora nos hace falta es interrelacionar diferentes servicios y con ellos acceder a recursos permanentes.

Así, modificamos nuestro archivo «docker-compose.yml» para añadir dos servicios más. En total tendremos los siguientes servicios:

• web — > Servicio web estática que nos muestra el nodo (hostname) que lo ejecuta y el numero de visitas a la web que lo obtiene de REDIS.
• visualizer — > Servicio de visualización que usará la información que Docker almacena en el nodo «manager», y lo mapea a un almacenamiento con el mismo nombre. Este servicio se le forzará para que solo se ejecute en el nodo «manager» que es el que dispone de dicha información.
• redis — > Este servicio es un almacén de estructura de datos (requiere que le establezcamos un sitio donde guardar esos datos dentro del contenedor a través de una relación del archivo host o nodo al contenedor) para ellos se mapea el directorio, sino hiciésemos esto, cada vez que se reinicie el nodo la información no sería permanente. Este servicio también se ejecuta solo en el nodo “manager”.

En las explicaciones anteriores han salido dos conceptos nuevos:

•  Ejecución de servicios (o contenedores) en un nodo restringido. Esto lo conseguimos con el comando constraints: [node.role == manager].
• Mapeo de almacenamiento (volumen). Esta es una característica que puede ser implementada de diferentes forma y de la que trataremos mas adelante en otras entradas, pero con saber que puedo «mapear» un espacio de almacenamiento local (host anfitrión) con uno interno del contenedor con el comando volumes: – «/home/user/data:/data« sobra. Obviamente tenemos que crear el archivo «./data» en el nodo manager antes de ejecutar “docker-compose.yml”.

El archivo nuevo de “docker-compose.yml” seria el siguiente:

version: «3»
services:
web:
# usamos una imagen desde un repositorio (como en este caso) o de la que ya dispongamos en el host local
image: maxtor71/test:part2
deploy:
replicas: 5
restart_policy:
condition: on-failure
resources:
limits:
cpus: «0.1»
memory: 50M
ports:
– «4000:80»
networks:
– webnet
visualizer:
image: dockersamples/visualizer:stable
ports:
– «8080:8080»
volumes:
– «/var/run/docker.sock:/var/run/docker.sock»
deploy:
placement:
constraints: [node.role == manager]
networks:
– webnet
redis:
image: redis
ports:
– «6379:6379»
volumes:
– «/home/user1/testdocker/data:/data»
deploy:
placement:
constraints: [node.role == manager]
command: redis-server –appendonly yes
networks:
– webnet
networks:
webnet:

Con el código anterior lanzamos 5 replicas de la web, 1 de redis y 1 de visualizer. En este caso hemos apagado un nodo y solo trabajamos con un nodo «manager» y otro «worker». Finalmente lanzamos nuestro stack como siempre docker stack deploy -c docker-compose.yml testmultiservices como podemos ver en la siguiente imagen.

Con docker service ls obtenemos la información de los servicios ejecutándose y los mapeo de puertos.

Comprobamos nuestros servicios con el servicio que nos proporciona visualizer en el puerto 8080.

Como vemos en visualizer tenemos dos nodos activos y otro apagado (en color rojo) y Swarm ha distribuido los contenedores entre los dos nodos restantes (manager y worker) pero manteniendo la restricción de que redis y visualizer deben de estar ejecutándose en el nodo «manager».

Para ver que nuestro servicio redis funciona vamos a comprobar si con varias visitas va aumentando el número de ellas que nos presenta en la web como se ve en la siguiente imagen.

Paramos todo (esto solo hace falta hacerlo en el nodo “manager”) y eliminamos la colmena en cada uno de los nodos. Esto se hace con:

• docker stack rm testmultiservices
• docker swarm leave –force

En el proximo capitulo hablaremos del gestor de volumenes y redes en dockers.

Después de tener ya nuestro nodos preparados lanzaremos 5 contenedores iguales con un archivo docker-compose.yml.

El archivo (usando la imagen que ya habíamos creado en nuestro host llamada «ubuntutest_web») es el siguiente:

version: «3»
services:
web:
# 5 contenedores web (Apache) respondiendo a la misma IP o diferentes
image: ubuntutest_web
deploy:
replicas: 5
resources:
limits:
cpus: «0.1»
memory: 100M
restart_policy:
condition: on-failure
ports:
– «8080:80»
networks:
– webnet
networks:
webnet:

Las imágenes del lanzamiento del docker-compose son las siguientes:

Como estamos en un modelo “roundrobin» (por defecto) se asignan las tareas por orden a los containers activos. Podríamos modificar el archivo “docker-compose.yml” y aumentar (por ejemplo) el número de instancias (contenedores) a «7» y relanzarlo de nuevo. En las siguientes imágenes vemos esta acción.

En la siguiente entrada crearemos un Stack con nuestra colmena (Swarm) donde lanzaremos 3 servicios diferentes y 5 contenedores en uno de ellos. Finalmente decir que para detener y eliminar un Swarm lo podemos hacer con docker stack rm NOMBRE_STACK, como vemos en la siguiente imagen.

Un apunte final. No podemos desplegar un Stack de varios contenedores (replicas) con una imagen que no este construida (build) previamente, nos dará error.

Nuestro obejetivo en esta entrada es construir una colmena o Swarm de Docker con el pbjetivo de lanzar varios contenedores de una misma imagen para que respondan a un servicio al mismo socket (Puerto+IP) balanceando la carga de las peticiones netre todo los contenedores creados.

Una cosa quiero acalararos antes de que perdais el tiempo al crear varios nodos si vais a trabajar en maquinas virtuales. Ciertos software de virtualizacion NO admiten virtualizacion anidad (nested virtualization). Uno de ellos es VirtualBox. O bien empleais distintas MVs como nodos o bien usais diferentes máquinas fisicas. Dicho esto ya podemos porseguir.

Ahora definiré ciertos conceptos para aclarar mas el tema de dockers con multi-servicios o balanceo de carga (LB):

• Services — > Varias copias de la misma instancia ejecutándose “en paralelo”.
• Swarm — > Colmena de máquinas (físicas o virtuales) que ejecutan dockers containers y que se gestionan como un cluster único (aunque las maquinas virtuales o físicas estén separadas).
• Stack — > Grupo de servicios interrelacionados que comparten dependencias que puede ser gestionado y auto escalado como uno solo. Por ejemplo, una web con un servicio de BBDD asociado.

Swarm nos permite generar clusters en una distintas máquinas físicas o virtuales. Una vez que dichas maquinas se unen al cluster swarm cada una de ellas se pasa a denominar NODO.

Así como existían estrategias para el balanceo de carga en un “Service”, también se puede producir una estrategia de para ejecutar los containers en los “nodos”. Existen las siguientes dos estrategias que se pueden marcar en el archivo “compose”:

• Emptiest node — > estrategia que completa con un container el nodo menos “completo” de instancias.
• Global — > Esta estrategia asegura el mismo número de máquinas en cada nodo.

Hay que tener en cuenta que solo los “swarm managers” pueden ejecutar los comandos que deseamos y solo ellos pueden asignar tareas a los “workers” o incluso dejar que se añadan a la colmena.

En la siguiente imagen vemos como cualquier IP de los nodos a los que solicitemos un servicio puede enviar dicha solicitud a un contenedor de otro nodo. Así pues, en el ejemplo, aunque accedamos a la IP 192.168.99.100 o la 101 o la 102 la carga se reparte entre todos los nodos porque es el «Swarm load balancer» el que «escucha» en esas IPs y reparte dicha carga. Esto garantiza que un servicio implementado en un puerto determinado dentro de su enjambre siempre tiene ese puerto reservado para ese servicio, no importa qué nodo está ejecutando realmente en ese contenedor.

Quiero subrayar que lo lógico por motivos de seguridad seria el exponer una sola IP al trafico de solicitud o (al menos) dividir la traducción DNS de direcciones a IPs por areas o regiones donde tengamos un nodo mas cerca de donde se produce la solicitud.

Creando nuestro Swarm (colmena)

Como ya es comentado al principio en VirtualBox tenemos el problema de la virtualización anidada. Las opciones para solucionar el problema son las siguientes:

1. Emplear un hypervisor que si nos permita anidar virtualizaciones (como VMware/VCenter).
2. Emplear una maquina física con un S.O Ubuntu (en este caso) en el que en VirtualBox estén creadas el resto de las máquinas.
3. Emplear maquinas físicas.
4. Emplear varias máquinas en VirtualBox con cualquier S.O anfitrión. Esta es la arquitectura elegida en el ejemplo que seguiremos.

En el caso de haber escogido una arquitectura como el segundo caso se podrían crear las maquinas usando docker-machine para realizar esta configuración podemos ver más información aquí.

Nosotros trabajaremos en el cuarto caso donde hemos “clonado” una máquina virtual desde una creada en Ubuntu 18. Es fácil deducir es que todas las maquinas deberán de tener instalado Docker Engine y una (o varias) podrían ser, además, “managers” del Swarm. En este caso tendremos 1 máquina virtual como manager (o leader) y 2 máquinas más como workers.

La estructura de nuestra prueba es la que se muestra en la siguiente imagen donde Ubuntu18(Worker) es el «worker» y Ubuntu18(Manager) es nuestro «leader» o «manager».

Cuando ejecutamos en una maquina el comando docker swarm init lo que hace es convertir esa máquina en manager o leader (además de poder ejecutar tareas como “worker”) y nos muestra las instrucciones para poder añadir más maquinas a nuestra “colmena” tanto de managers como workers. En la siguiente imagen vemos la ejecución de ese comando.

Como vemos en los mensajes que nos muestra nos indica que para añadir un nodo «worker» a nuestro enjambre/colmena (Swarm) debemos ejecutar en dicho nodo docker swarm join –token SWMTKN-1-2eelg9lrdpjyeg66yqy35ro4iscjowgwh2jmgifrtqygf7enfq-bkl7gmr7cx7hsebuqlxq39vd4 192.168.1.137:2377 donde la última IP es la de nuestro nodo «manager».

Es muy importante especificar el puerto 2377 (o ninguno si queremos) pero nunca el 2376 ya que ese es el que emplea el demonio de swarm. En la siguiente imagen vemos como unir un nodo como «worker».

Ahora con los comandos docker node ls obtenemos la información de las máquinas que están añadidas a la colmena, quien es el manager o leader y con docker info podemos discriminar el ID de la que es leader ya que (en este caso) son todas clonaciones y tienen el mismo nombre.

Si nos fijamos en el resultado de la imagen veremos «Managers: 1» (lo cual es correcto) y «Nodes: 2» que también es correcto ya que, como hemos dicho, un «manager» es un nodo y también ejecuta contenedores como lo haría un «worker».

En la siguiente entrada desplegaremos varios contenedores en nuestro Swarm.

En el entorno de las tecnologías un servicio es una aplicación que proporciona un recurso. Aquí vamos a aprender a escalar un servicio y balancear la carga entre los contenedores creados.

Para hacer esto, básicamente crearemos varios contenedores con el mismo servicio trabajando (podemos decir) en “paralelo” para que se puedan repartir la carga entre ellos. Para realizar esto tenemos dos alternativas:

1. Crear varios contenedores (cada uno de diferentes servicios) en un solo host anfitrión con el archivo docker-compose.yml.
2. Usar a nuestro “amigo” SWARM (Colmena o enjambre en inglés) para crear varios contenedores de uno o de diferentes servicios (balanceo de carga).

Swarm es ahora parte integral del engine y no tendremos que instalar elementos adicionales. Swarm es un protocolo de aglomeración nativo a Docker. Convierte un grupo de hosts anfitriones con docker engine en un solo host virtual de Docker. Ya que Swarm sirve a la API estándar de Docker, cualquier herramienta que se comunique con el «daemon» de Docker puede usar Swarm para «distribuirse» de forma transparente y proporcional entre varios hosts. En un clúster de Swarm existen dos tipos de nodo, Manager y Worker. Ls características de estos dos nodos son las siguientes:

• Los nodos Manager (puede haber mas de uno) son los encargados de gestionar el clúster. Entre todos los Manager se elige automáticamente un líder y éste es el encargado de mantener el estado del clúster.
• Los Manager son también los encargados de distribuir las tareas o tasks (unidades básicas de trabajo) entre todos los nodos Worker, los cuales reciben estas tareas y las ejecutan.

Los nodos Manager por defecto también actúan como nodos Worker aunque se puede cambiar su configuración para que sólo asuman tareas de Manager. La explicación mas en profundidad de Swarm la veremos en otra entrada, aquí nos centraremos en la alternativa «1», varios contenedores balancean la carga en un solo host anfitrión.

docker-compose-yml

Docker-compose (cuando se ejecuta en un solo host) sirve para «lanzar» un «stack», es decir un solo contenedor de cada servicio diferente (varios servicios diferentes a la vez), esto cambia con SWARM que permite varios contenedores de cada servicio y balanceo de carga.

Aunque ya hemos hablado anteriormente algo sobre docker-compose quería volver a incidir sobre sus grandes ventajas:

• docker-compose puede «lanzar» uno o varios contenedores de un mismo servicio (varios solo con SWARM). Bien a través de una imagen existente (o en el propio host o en un repositorio como Hocker Hub) o bien creándola a través de un archivo «Dockerfile» (como ya se ha visto en otras entradas).
• docker-compose puede «lanzar» un solo contenedor de cada servicio diferente a la vez en un mismo host (NO necesita SWARM).
• Cada servicio lanzado (imaginemos que con varios contenedores cada uno) balancea la carga por defecto (round-robin es el comportamiento de SWARM por defecto).
• Debemos lanzar nuestro docker-compose.yml en un nodo «manager» si queremos usar SWARM.

Instalación de docker-compose

En Ubuntu 18.04 la instalación de docker-compose es:

sudo apt update
sudo curl -L «https://github.com/docker/compose/releases/download/1.24.1/docker-compose-$(uname -s)-$(uname -m)» -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
###Para comprobarlo###
docker-compose –version

Ejemplo de una ejecución con docker-compose

El archivo “docker-compose.yml” es un archivo que define como se ha de comportar un servicio (de varios contenedores Docker) en producción (es decir “corriendo”). Un ejemplo que usaremos es el siguiente:

version: «3»
services:
web:
# hemos usado un «build» a traves de «Dockerfile»
build: .
ports:
– «8080:80»
networks:
– webnet
redis:
image: «redis:alpine»
networks:
webnet:

El ejemplo siguiente genera un contenedor (servicio web de apache como hemos creado antes con nuestro «Dockerfile» añadiéndole CMD [«apachectl», «-D», «FOREGROUND»]) y otro del servicio REDIS (Que comprueba el numero de visitas que tiene esa pagina web). El servicio REDIS solo lo vamos a lanzar acomo ejemplo y no nos va ha funcionar adecuadamenbte.

Lo más interesante es la respuesta en caso de fallo (condition: on-failure) que reinícia el contenedor que falle. Además, se mapea el puerto 8080 al 80 balanceando la carga en una red que se ha llamado “webnet” (podríamos haberla llamado de cualquier otra manera).

Este archivo puede ser configurado con muchos más parámetros como volúmenes de acceso (para hacer los datos permanentes), links, servidores proxy, etc.

Las instrucciones de docker-compose más empleadas son:

• docker-compose up — > Da instrucciones a Docker para crear el contenedor, y ejecutarlo según docker-compose.yml (busca ese archivo por defecto). La opción «-d» es «detached».
• docker-compose down — > Apaga todo los servicios que levantó con docker-compose up.
• docker-compose ps — > Permite ver los contenedores funcionando.
• docker-compose exec — > Permite ejecutar un comando a uno de los servicios levantados de Docker-compose.

A continuación vemos la ejecución de nuestro ejemplo.

Habitualmente los proveedores de servicios y plataformas cloud despliegan sus sistemas en una estructura con los siguientes elementos:

• Regiones — > Son las areas donde los proveedores han desplegado sus sistemas y los ponen a disposición de los clientes. Obviamente las regiones mas cercanas a un país son las que mas interesan a los clientes de esa region ya que su latencia (o lag) es menor que en otras regiones.
• Areas — > En cada region se establecen varias areas (raramente solo existe un area en una region, lo habitual es al menos 2) en las que los datos y sistemas puedan estar «redundados» existiendo la posibilidad de una alta disponibilidad y tolerancia a fallos.

Así pues, a la hora de seleccionar un proveedor de servicios debemos comprobar las regiones de las que disponen (ahora mismo AWS es el que mas dispone en Europa y América).

Sin embargo (y aquí viene la sorpresa) NO se prestan los mismos servicios en todas las regiones. Es decir, existen servicios que quizás no se pueda facilitar en la zona que te «interesa» (por ser la mas cercana a tus futuros usuarios). Por lo tanto hay que valorar el tener TODOS los servicios que te interesen o que te puedan interesar en una region especifica y que su latencia (o lag) no sea excesivo.

Para comprobar esto ultimo cada proveedor dispone de varias comprobaciones de el «lag» a cada una de sus regiones. Aquí os dejo un link en el que se puede comprobar esto para casi todos los proveedores de servicios cloud.

Mas adelante (en otra entrada) hablaremos mas de los conceptos de regiones y zonas asociados a la redundancia y la alta disponibilidad.

El concepto de Multicloud

Un concepto muy actual se basa en “no poner todos los huevos en la misma cesta”. Las grandes multinacionales prefieren dividir sus sistemas entre diferentes proveedores o contar con un equipo de HA (Alta redundancia -High Avaliability-) para disponer de un servicio de respaldo exactamente igual que el anterior encaso de que se caiga el primero.

Para ello el concepto de “multicloud” o emplear “múltiples nubes” es una arquitectura muy empleada hoy en día por grandes empresas.

Las ventajas obtenidas por esta arquitectura son menor latencia en la petición de los clientes, no depender de un solo cliente (piénsese en un ataque masivo contra los servidores de AWS , por ejemplo) y tener una alta redundancia de servicios entre otras.