Sigue El lado del mal en Telegram
Sigue El lado del Mal en Google+
Chema Alonso en Linkedin
Dreamlab
Root Secure
IT Forensic
e-Hack MX 
AREA 51 
AIYON Panamá 
ARPAHE SOLUTIONS 
Docker de My WordPress In Paranoid Mode (WPM): "The making of" (Parte 2 de 2)
En esta parte continuamos el trabajo que sigue a lo que hemos visto en la primera parte de este artículo sobre cómo hemos dockerizado WodPresss in Paranoid Mode. Una vez ya tenemos preparados los ficheros Dockerfile es el momento de preparar el fichero Docker Compose, el cual es el encargado de montar todo el sistema.
Vamos a echar antes un vistazo al código de este fichero llamado docker-compose.yml. Aquí es donde se produce toda la magia de Docker. Este fichero compose se ha realizado utilizando la versión 2.0. Se pueden observar dos etiquetas principales llamadas services y volumes. En la primera, services, se definen los contenedores con sus aplicaciones o servicios, así como las variables necesarias para su configuración.
La etiqueta volumes indica el nombre del volumen principal donde se crearán los espacios de almacenamiento de cada contenedor. En services se han definido dos, uno llamado db (para MySQL) y otro wordpress (para WordPress).
El servicio que crea el contenedor db de MySQL en la línea 5 le asignamos un nombre para poder tenerlo identificado en todo momento y evitar utilizar nombre aleatorios definidos por Docker. Lo mismo ocurre con el contenedor para Wordpress, en la línea 20 se le asigna el nombre wpm.
Cuando lo tengamos todo en ejecución, si utilizamos el comando:
Las imágenes resultantes de la creación de los contenedores tendrán los nombres mysqllatch (para MySQL) y wplatch (para WordPress). Estos nombres se asignan en las líneas 6 y 24 del fichero docker-compose. Centrándonos en el contenedor db de MySQL, además de asignar un nombre de la imagen que se generará a partir de estos, también se define la ubicación de los mismos, en este caso en la carpeta ./db (línea 7, comando build). El siguiente paso, línea 8 y 9, será asignar el volumen. Para ello se indica primero el volumen principal y luego la ruta de la aplicación.
El comando de la línea 10 simplemente nos asegura que el contenedor se ejecutará cada vez que lo haga el host. Finalmente, tenemos la parte de asignación de variables de entorno. En este caso se definen las variables correspondientes a los parámetros necesarios para la creación de la base de datos y añadimos también dos para asignar los valores de las key de la aplicación WPM que previamente hemos creado desde nuestra cuenta de Latch.
La parte del contenedor que hemos llamado wordpress es parecida a la asignación de valores para db pero con algunos cambios. Por ejemplo, en las líneas 29 y 30 se definen los puertos desde los cuales la aplicación será accesible. En la parte de asignación de variables esta vez se crean aquellas que WordPress necesitará para conectar con la base de datos MySQL creada en el contenedor db.
También hay que destacar la línea 22 donde se utiliza el comando depends_on el cual asigna las dependencias de los contenedores, en este caso db, el contenedor que tiene la base de datos MySQL de Wordpress.
Para que todo funcionara correctamente intentando la menor intervención del usuario, hemos tenido que modificar el script bash de instalación de WPM. En principio, necesitaba dos parámetros para su ejecución, uno era la key de la aplicación WPM y el otro el secret key de WPM. Para que el script tome estos parámetros directamente del docker-compose, en concreto del que pertenece a la creación del contenedor llamado db (MySQL), tendremos que asignarlas internamente utilizando las variables de entorno creadas en el fichero compose.
En concreto serán las variables LATCHAPPID y LATCHSECRET las que luego usaremos dentro del script (por ejemplo, sustituir todas las llamadas que usaban los parámetros de entrada referenciados como $1 o $2) asignándolas a otras variables internas como se puede observar en estar parte del código del mismo:
Finalmente, sólo nos queda ejecutar el comando docker-compose para levantar los contenedores y probar la aplicación siguiendo los pasos del readme. La primera vez tardará un poco ya que tiene que descargar todas las imágenes necesarias para crearlos. En el siguiente video podéis comprobar todos los pasos de ejecución, configuración y los resultados finales:
Figura 14: Docker de WordPress in Paranoid Mode
Si queremos volver a ejecutar y crear desde cero los contenedores en el mismo host, será necesario primero eliminar los contenedores, imágenes y los volúmenes creados. Para realizar esta limpieza utilizaremos el comando prune para cada elemento. En este enlace podéis encontrar un fantástico tutorial sobre cómo borrar los recursos creados en Docker.
Más recursos sobre WordPress in Paranoid Mode
Si quieres saber más sobre WPM, echa un vistazo a esta charla de Chema Alonso donde explica cómo fortificar un Wordpress usando WPM y de paso entender un poco mejor su funcionamiento:
Figura 15: Presentación de WordPress in Paranoid Mode
Y para saber en detalle cómo funciona WPM y la teoría en la cual se basa, siempre podéis consultar el paper oficial de este proyecto:
Sin duda seguiremos utilizando Docker para ir incluyendo nuevas PoC (aparte de WPM) para que sea más sencillo probarlas y jugar con ellas. Puedes descargarte de nuestro repositorio de GitHub el docker de WordPress in Paranoid Mode.
El 19 de septiembre, Pablo González realizará un Code Talk For Developers sobre WPM en el cual también explicará algunos detalles más de cómo ha sido la integración de Docker con el script de WPM. No os lo perdáis.
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 9: Docker de My WordPress In Paranoid Mode (WPM): "The making of" (Parte 2 de 2) |
Vamos a echar antes un vistazo al código de este fichero llamado docker-compose.yml. Aquí es donde se produce toda la magia de Docker. Este fichero compose se ha realizado utilizando la versión 2.0. Se pueden observar dos etiquetas principales llamadas services y volumes. En la primera, services, se definen los contenedores con sus aplicaciones o servicios, así como las variables necesarias para su configuración.
 |
| Figura 10: Contenido del fichero Docker-Compose del proyecto WPM. |
La etiqueta volumes indica el nombre del volumen principal donde se crearán los espacios de almacenamiento de cada contenedor. En services se han definido dos, uno llamado db (para MySQL) y otro wordpress (para WordPress).
El servicio que crea el contenedor db de MySQL en la línea 5 le asignamos un nombre para poder tenerlo identificado en todo momento y evitar utilizar nombre aleatorios definidos por Docker. Lo mismo ocurre con el contenedor para Wordpress, en la línea 20 se le asigna el nombre wpm.
Cuando lo tengamos todo en ejecución, si utilizamos el comando:
docker container lsEste comando nos mostrará la siguiente salida, en la cual tendremos identificado en todo momento el contenedor que corresponde a cada servicio (marcado en rojo en la imagen inferior):
 |
| Figura 11: Listado de contenedores en ejecución y sus nombres |
Las imágenes resultantes de la creación de los contenedores tendrán los nombres mysqllatch (para MySQL) y wplatch (para WordPress). Estos nombres se asignan en las líneas 6 y 24 del fichero docker-compose. Centrándonos en el contenedor db de MySQL, además de asignar un nombre de la imagen que se generará a partir de estos, también se define la ubicación de los mismos, en este caso en la carpeta ./db (línea 7, comando build). El siguiente paso, línea 8 y 9, será asignar el volumen. Para ello se indica primero el volumen principal y luego la ruta de la aplicación.
El comando de la línea 10 simplemente nos asegura que el contenedor se ejecutará cada vez que lo haga el host. Finalmente, tenemos la parte de asignación de variables de entorno. En este caso se definen las variables correspondientes a los parámetros necesarios para la creación de la base de datos y añadimos también dos para asignar los valores de las key de la aplicación WPM que previamente hemos creado desde nuestra cuenta de Latch.
 |
| Figura 12: Estructura en árbol de todas las carpetas y ficheros que componen WPM para Docker |
La parte del contenedor que hemos llamado wordpress es parecida a la asignación de valores para db pero con algunos cambios. Por ejemplo, en las líneas 29 y 30 se definen los puertos desde los cuales la aplicación será accesible. En la parte de asignación de variables esta vez se crean aquellas que WordPress necesitará para conectar con la base de datos MySQL creada en el contenedor db.
También hay que destacar la línea 22 donde se utiliza el comando depends_on el cual asigna las dependencias de los contenedores, en este caso db, el contenedor que tiene la base de datos MySQL de Wordpress.
Para que todo funcionara correctamente intentando la menor intervención del usuario, hemos tenido que modificar el script bash de instalación de WPM. En principio, necesitaba dos parámetros para su ejecución, uno era la key de la aplicación WPM y el otro el secret key de WPM. Para que el script tome estos parámetros directamente del docker-compose, en concreto del que pertenece a la creación del contenedor llamado db (MySQL), tendremos que asignarlas internamente utilizando las variables de entorno creadas en el fichero compose.
En concreto serán las variables LATCHAPPID y LATCHSECRET las que luego usaremos dentro del script (por ejemplo, sustituir todas las llamadas que usaban los parámetros de entrada referenciados como $1 o $2) asignándolas a otras variables internas como se puede observar en estar parte del código del mismo:
 |
| Figura 13: Asignación de variables internas a las variables de entorno definidas en el fichero docker-compose del script install.sh de WPM |
Finalmente, sólo nos queda ejecutar el comando docker-compose para levantar los contenedores y probar la aplicación siguiendo los pasos del readme. La primera vez tardará un poco ya que tiene que descargar todas las imágenes necesarias para crearlos. En el siguiente video podéis comprobar todos los pasos de ejecución, configuración y los resultados finales:
Figura 14: Docker de WordPress in Paranoid Mode
Si queremos volver a ejecutar y crear desde cero los contenedores en el mismo host, será necesario primero eliminar los contenedores, imágenes y los volúmenes creados. Para realizar esta limpieza utilizaremos el comando prune para cada elemento. En este enlace podéis encontrar un fantástico tutorial sobre cómo borrar los recursos creados en Docker.
Más recursos sobre WordPress in Paranoid Mode
Si quieres saber más sobre WPM, echa un vistazo a esta charla de Chema Alonso donde explica cómo fortificar un Wordpress usando WPM y de paso entender un poco mejor su funcionamiento:
Figura 15: Presentación de WordPress in Paranoid Mode
Y para saber en detalle cómo funciona WPM y la teoría en la cual se basa, siempre podéis consultar el paper oficial de este proyecto:
Figura 16: Wordpress in Paranoid Mode I
Figura 17: Wordpress in Paranoid Mode II from ElevenPaths
Sin duda seguiremos utilizando Docker para ir incluyendo nuevas PoC (aparte de WPM) para que sea más sencillo probarlas y jugar con ellas. Puedes descargarte de nuestro repositorio de GitHub el docker de WordPress in Paranoid Mode.
 |
| Figura 18: Docker de WordPress in Paranoid Mode |
El 19 de septiembre, Pablo González realizará un Code Talk For Developers sobre WPM en el cual también explicará algunos detalles más de cómo ha sido la integración de Docker con el script de WPM. No os lo perdáis.
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.
