Hace unos días presentamos en el blog de ElevenPaths nuestro proyecto de dockerizar WordPress in Paranoid Mode (WPM) y de esa forma, hacer más sencillo poder probarlo de una forma rápida y segura. En este artículo vamos a ver un poco más en profundidad cómo hemos realizado la tarea de pasar a Docker nuestro querido WPM ya que pensamos puede ser útil para aquellos que queráis descubrir y practicar con las maravillas que ofrece esta tecnología basada en contenedores.
Escribir el libro sobre Docker llamado “Docker: SecDevOps” de 0xWord junto a dos grandes como son mi gran amigo Rafael Troncoso (@tuxotron, ¡gracias maestro!) y Elías Grande (@3grander) también ayuda un poco a entender cómo funcionan los contenedores Docker.
WordPress in Paranoid Mode
Antes de empezar a hablar del proyecto de crear Docker WordPress in Paranoid Mode, hay que recordar que lo que en él se incluyen son las publicaciones, ajustes, e integraciones de tecnologías de seguridad de las que estuvieron hablando Chema Alonso y Pablo González, y que acabaron formando parte del libro de Máxima Seguridad en WordPress de Daniel Martín Maldonado. En la siguiente lista tienes todos los recursos sobre este tema enlazados, y esta conferencia recoge casi todos los detalles en WPM.
Figura 3: Configurar Wordpress like a hacker
[Libro] Máxima Seguridad en WordPress
[Libro] Hardening GNU/Linux
[Paper] WordPress in Paranoid Mode (Parte 1)
[Paper] WordPress in Paranoid Mode (Parte 2)
[Vídeo] Proteger WordPress con Latch
[Vídeo] Proteger WordPress con Latch Cloud TOTP
[Vídeo] MyWordPress in Paranoid Mode (conferencia Chema Alonso)
[Vídeo] MyWordPress in Paranoid Mode (ElevenPaths Talks de Pablo González)
[Vídeo] Ejemplo de uso de Latch en WordPress
[Vídeo] Hardening WordPress like a hacker
[Vídeo] WordPress Demo XSS en WP-UserAgent
[BlogPost] My WordPress in Paranoid Mode
[BlogPost] Máxima Seguridad en WordPress
[BlogPost] Hackear un WordPress con Network Packet Manipulation
[BlogPost] Fortificar comunicación entre WordPress y MySQL
[BlogPost] WordPress Latch Enforcement
[BlogPost] WordPress aún más seguro con Latch Lock After Request
[BlogPost] Fortificar WordPress frente a ataques de fuerza bruta
[BlogPost] Ataques (al corazón) de tu WordPress
[BlogPost] Cómo robarle las contraseñas a los administradores de WordPress
[BlogPost] Agrupar el control de varios WordPress con un solo Latch
[BlogPost] WordPress: Time-Based XSPA (Cross-Site Port Attack)
[BlogPost] Cómo debería ser un WordPress un poco más seguro
[BlogPost] WPHardening: Automatizar fortificación de WordPress
[BlogPost] Protege los borradores de los artículos de tu WordPress
[BlogPost] Registro de cuentas en WordPress públicos
[BlogPost] Riesgos en la ejecución de tareas de Cron
[BlogPost] WordPres: XSS en plugin WP-UserAgent
[BlogPost] Listar los plugins de WordPress en un pentest
[BlogPost] WordPress: SQL Injection en Scarcity Builder Plugin
[BlogPost] Docker WordPress in Paranoid Mode
Y ahora, vamos a centrarnos en el proceso de dockerización de WPM para que pueda ser implantado fácilmente en los entornos que sean necesarios.
Dockers: Essentials
Un contenedor es básicamente un paquete de software donde se incluye una aplicación y todo lo que necesita para funcionar como por ejemplo librerías, componentes, entornos runtime, herramientas, etcétera. La gran ventaja frente a las máquinas virtuales es que los contenedores comparten la base del sistema operativo en el cual se ejecutan (host), ya sea GNU/Linux o Microsoft Windows. De esta forma se consigue una gran optimización tanto en la ejecución como en el tamaño de los contenedores gracias a que, como se ha comentado antes, sólo tienen lo necesario para ejecutar la aplicación, el resto lo obtendrán del sistema operativo host.
En dicho host - en nuestro caso era una máquina virtual con Ubuntu 16.04 Desktop 64bits (esto es importante) - es donde se ejecutará el motor Docker (Docker Engine) el cual es el encargado de gestionar los contenedores. Este motor consta de un cliente, desde el cual se introducen los comandos y un demonio el cual se ejecutará en el servidor host y es el encargado de gestionar los contenedores.
Básicamente la idea es crear dos contenedores, uno para ejecutar MySQL y otro para WordPress. Ambos tendrán a su vez una ubicación en el sistema de ficheros del host para poder asegurar la consistencia de la información. Es decir, necesitaremos un espacio en el disco duro (volumen Docker) para que los datos almacenados tanto en la base de datos MySQL como los cambios que se realicen en el WordPress se mantengan cuando reiniciemos el host.
Necesitaremos dos ficheros Dockerfile, uno para el contenedor MySQL y otro para el Wordpress donde se definen los parámetros básicos necesarios para montarlo, como por ejemplo la imagen base o los comandos que necesitemos ejecutar (como las dependencias necesarias para instalar el script de WPM o copiar el plugin de Latch). El siguiente gráfico muestra el proceso de creación (A) y de ejecución (B) de los contenedores y los volúmenes:
La fase (A) es donde se definen los contenedores y la fase (B) corresponde a la ejecución del docker-compose y es donde se crean los contenedores y los volúmenes. Tal y como ya hemos mencionado antes, cada contenedor tiene su propio fichero Dockerfile. Estos ficheros deben de tener este mismo nombre, por lo tanto, cada contenedor tendrá su propia carpeta sobre la cual se creará tanto el fichero Dockerfile correspondiente así como su volumen para los datos.
En el caso del contenedor MySQL, será necesario instalar las dependencias necesarias para ejecutar WPM así como copiar dentro del mismo contenedor el script de instalación WPM. Vamos a verlo en detalle, este es el contenido del fichero Dockerfile de MySQL (carpeta /db):
La línea número 1 define la imagen que vamos a recuperar del repositorio de Docker utilizando el comando FROM y la etiqueta mysql:5.7 (la cual se descargará desde el Docker Hub) que servirá como base para configurar el contenedor y ejecutar MySQL. La línea número 3, comando RUN (este comando permite ejecutar instrucciones directas del sistema operativo), se encargará de instalar (usando el típico apt-get) en el contenedor todas las dependencias necesarias para poder ejecutar el script que instala WPM, como por ejemplo ruby, gcc, etcétera.
En la línea 6, el comando ADD añade o copia el directorio /WPM_Latch el cual contiene WPM al completo dentro de una carpeta y que se ubicará en el directorio raíz del contenedor, también con el nombre WPM_Latch. En la línea 7 activamos los permisos necesarios para poder ejecutar el script en la carpeta donde se encuentra WPM y finalmente en la línea 8 establecemos como directorio de trabajo (el que aparecerá por defecto cuando accedamos al contenedor) /WP_Latch.
El fichero Dockerfile del contenedor que ejecutará WordPress es un poco más sencillo. Sólo necesitamos definir la imagen sobre la cual lo vamos a ejecutar, en este caso wordpress:latest (la última versión que exista en el repositorio) y copiar Latch. Para copiar el plugin de Latch, usamos de nuevo el comando ADD.
La carpeta Latch con el plugin ya está preparada dentro de los datos que hemos descargado desde GitHub así que simplemente se copiarán a la ruta que aparece, dentro de la carpeta plugins de WordPress. Esto instalará Latch pero no lo activará, esta acción tendremos que realizarla manualmente durante el proceso de configuración, como ya explicamos en el post de "·Cómo fortificar tu Base de datos de WordPress con Latch".
Continúa en la Parte 2
Autor: Fran Ramírez, (@cyberhadesblog) miembro del equipo de Crazy Ideas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" y del blog Cyberhades.
 |
| Figura 1: Docker de My WordPress In Paranoid Mode (WPM): "The making of" (Parte 1 de 2) |
Escribir el libro sobre Docker llamado “Docker: SecDevOps” de 0xWord junto a dos grandes como son mi gran amigo Rafael Troncoso (@tuxotron, ¡gracias maestro!) y Elías Grande (@3grander) también ayuda un poco a entender cómo funcionan los contenedores Docker.
 |
| Figura 2: Libro de Docker SecDevOps |
WordPress in Paranoid Mode
Antes de empezar a hablar del proyecto de crear Docker WordPress in Paranoid Mode, hay que recordar que lo que en él se incluyen son las publicaciones, ajustes, e integraciones de tecnologías de seguridad de las que estuvieron hablando Chema Alonso y Pablo González, y que acabaron formando parte del libro de Máxima Seguridad en WordPress de Daniel Martín Maldonado. En la siguiente lista tienes todos los recursos sobre este tema enlazados, y esta conferencia recoge casi todos los detalles en WPM.
Figura 3: Configurar Wordpress like a hacker
[Libro] Hardening GNU/Linux
[Paper] WordPress in Paranoid Mode (Parte 1)
[Paper] WordPress in Paranoid Mode (Parte 2)
[Vídeo] Proteger WordPress con Latch
[Vídeo] Proteger WordPress con Latch Cloud TOTP
[Vídeo] MyWordPress in Paranoid Mode (conferencia Chema Alonso)
[Vídeo] MyWordPress in Paranoid Mode (ElevenPaths Talks de Pablo González)
[Vídeo] Ejemplo de uso de Latch en WordPress
[Vídeo] Hardening WordPress like a hacker
[Vídeo] WordPress Demo XSS en WP-UserAgent
[BlogPost] My WordPress in Paranoid Mode
[BlogPost] Máxima Seguridad en WordPress
[BlogPost] Hackear un WordPress con Network Packet Manipulation
[BlogPost] Fortificar comunicación entre WordPress y MySQL
[BlogPost] WordPress Latch Enforcement
[BlogPost] WordPress aún más seguro con Latch Lock After Request
[BlogPost] Fortificar WordPress frente a ataques de fuerza bruta
[BlogPost] Ataques (al corazón) de tu WordPress
[BlogPost] Cómo robarle las contraseñas a los administradores de WordPress
[BlogPost] Agrupar el control de varios WordPress con un solo Latch
[BlogPost] WordPress: Time-Based XSPA (Cross-Site Port Attack)
[BlogPost] Cómo debería ser un WordPress un poco más seguro
[BlogPost] WPHardening: Automatizar fortificación de WordPress
[BlogPost] Protege los borradores de los artículos de tu WordPress
[BlogPost] Registro de cuentas en WordPress públicos
[BlogPost] Riesgos en la ejecución de tareas de Cron
[BlogPost] WordPres: XSS en plugin WP-UserAgent
[BlogPost] Listar los plugins de WordPress en un pentest
[BlogPost] WordPress: SQL Injection en Scarcity Builder Plugin
[BlogPost] Docker WordPress in Paranoid Mode
Y ahora, vamos a centrarnos en el proceso de dockerización de WPM para que pueda ser implantado fácilmente en los entornos que sean necesarios.
Dockers: Essentials
Un contenedor es básicamente un paquete de software donde se incluye una aplicación y todo lo que necesita para funcionar como por ejemplo librerías, componentes, entornos runtime, herramientas, etcétera. La gran ventaja frente a las máquinas virtuales es que los contenedores comparten la base del sistema operativo en el cual se ejecutan (host), ya sea GNU/Linux o Microsoft Windows. De esta forma se consigue una gran optimización tanto en la ejecución como en el tamaño de los contenedores gracias a que, como se ha comentado antes, sólo tienen lo necesario para ejecutar la aplicación, el resto lo obtendrán del sistema operativo host.
 |
| Figura 4: Comparación entre VMs y Contenedores Docker |
En dicho host - en nuestro caso era una máquina virtual con Ubuntu 16.04 Desktop 64bits (esto es importante) - es donde se ejecutará el motor Docker (Docker Engine) el cual es el encargado de gestionar los contenedores. Este motor consta de un cliente, desde el cual se introducen los comandos y un demonio el cual se ejecutará en el servidor host y es el encargado de gestionar los contenedores.
Básicamente la idea es crear dos contenedores, uno para ejecutar MySQL y otro para WordPress. Ambos tendrán a su vez una ubicación en el sistema de ficheros del host para poder asegurar la consistencia de la información. Es decir, necesitaremos un espacio en el disco duro (volumen Docker) para que los datos almacenados tanto en la base de datos MySQL como los cambios que se realicen en el WordPress se mantengan cuando reiniciemos el host.
 |
| Figura 5: Explicación técnica del funcionamiento de un volumen en Docker. |
Necesitaremos dos ficheros Dockerfile, uno para el contenedor MySQL y otro para el Wordpress donde se definen los parámetros básicos necesarios para montarlo, como por ejemplo la imagen base o los comandos que necesitemos ejecutar (como las dependencias necesarias para instalar el script de WPM o copiar el plugin de Latch). El siguiente gráfico muestra el proceso de creación (A) y de ejecución (B) de los contenedores y los volúmenes:
 |
| Figura 6: Esquema de creación y ejecución de WPM Docker |
La fase (A) es donde se definen los contenedores y la fase (B) corresponde a la ejecución del docker-compose y es donde se crean los contenedores y los volúmenes. Tal y como ya hemos mencionado antes, cada contenedor tiene su propio fichero Dockerfile. Estos ficheros deben de tener este mismo nombre, por lo tanto, cada contenedor tendrá su propia carpeta sobre la cual se creará tanto el fichero Dockerfile correspondiente así como su volumen para los datos.
En el caso del contenedor MySQL, será necesario instalar las dependencias necesarias para ejecutar WPM así como copiar dentro del mismo contenedor el script de instalación WPM. Vamos a verlo en detalle, este es el contenido del fichero Dockerfile de MySQL (carpeta /db):
 |
| Figura 7: Contenido del fichero Dockerfile para el contendor de MySQL |
La línea número 1 define la imagen que vamos a recuperar del repositorio de Docker utilizando el comando FROM y la etiqueta mysql:5.7 (la cual se descargará desde el Docker Hub) que servirá como base para configurar el contenedor y ejecutar MySQL. La línea número 3, comando RUN (este comando permite ejecutar instrucciones directas del sistema operativo), se encargará de instalar (usando el típico apt-get) en el contenedor todas las dependencias necesarias para poder ejecutar el script que instala WPM, como por ejemplo ruby, gcc, etcétera.
En la línea 6, el comando ADD añade o copia el directorio /WPM_Latch el cual contiene WPM al completo dentro de una carpeta y que se ubicará en el directorio raíz del contenedor, también con el nombre WPM_Latch. En la línea 7 activamos los permisos necesarios para poder ejecutar el script en la carpeta donde se encuentra WPM y finalmente en la línea 8 establecemos como directorio de trabajo (el que aparecerá por defecto cuando accedamos al contenedor) /WP_Latch.
 |
| Figura 8: Contenido del fichero Dockerfile para el contendor de WordPress |
El fichero Dockerfile del contenedor que ejecutará WordPress es un poco más sencillo. Sólo necesitamos definir la imagen sobre la cual lo vamos a ejecutar, en este caso wordpress:latest (la última versión que exista en el repositorio) y copiar Latch. Para copiar el plugin de Latch, usamos de nuevo el comando ADD.
La carpeta Latch con el plugin ya está preparada dentro de los datos que hemos descargado desde GitHub así que simplemente se copiarán a la ruta que aparece, dentro de la carpeta plugins de WordPress. Esto instalará Latch pero no lo activará, esta acción tendremos que realizarla manualmente durante el proceso de configuración, como ya explicamos en el post de "·Cómo fortificar tu Base de datos de WordPress con Latch".
Continúa en la Parte 2
Autor: Fran Ramírez, (@cyberhadesblog) miembro del equipo de Crazy Ideas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" y del blog Cyberhades.
No hay comentarios:
Publicar un comentario