Playbooks para la gestión básica de infraestructura IT

Continuando con la automatización de configuraciones de nuestra infraestructura, en la Escuela Politécnica también hemos programado (y liberado) playbooks de Ansible relacionados con las tareas básicas que se realizan con los servidores de nuestros servicios IT.

Más información sobre estos playbooks en https://blogs.ua.es/labseps/?s=ansible&x=0&y=0

Y el software en https://github.com/EPSAlicante/ansibleEPS

¡Espero que os sea útil!


Monitorización de la infraestructura informática

Para asegurarnos que nuestros servicios de TI se están ofreciendo efectiva y eficientemente ( requerimientos de los usuarios, resolver fallos en el servicio, arreglar problemas y llevar a cabo operaciones rutinarias) debemos instalar y configurar herramientas que nos proporcionen información sobre el comportamiento de estos.

Nagios, Munin, OpenVas, cada uno en lo suyo, son aplicaciones libres que nos permiten obtener datos de disponibilidad, carga, seguridad,… que hace que sea, prácticamente, obligatoria su instalación, configuración y mantenimiento.

En la EPS hemos desarrollado una aplicación basada en Ansible que permite la automatización de las tareas relacionadas, entre otros, con Nagios, Munin y OpenVas.

Si no quieres, o puedes, calentarte la cabeza con la instalación de estos programas, pero quieres/necesitas usarlos, esta app es una magnífica opción (es obvio que no soy objetivo pero de verdad que lo digo porque lo pienso)

En el blog de mi unidad tenemos una entrada explicando la app y, también, sobre cómo conectarnos a la demo que hemos dejado libre para que se puede consultar cómo funciona.

El software que realiza toda la labor, lo hemos liberado: https://github.com/EPSAlicante/EPSMS

¡Espero que os sea útil!


Minimizando problemas con iSQL en WordPress

Alrededor del 15% de las vulnerabilidades de WordPress y sus plugins son del tipo iSQL (ver https://www.keycdn.com/blog/wordpress-security/) Además, iSQL en WordPress  adquiere mayor importancia debido a que, por defecto, la conexión entre WordPress y la base de datos que sustenta nuestro servicio se realiza, independientemente del tipo de usuario que se conecta (usuario del servicio), con la misma conexión (es decir, con el mismo usuario -de la base de datos-  y, por tanto, permisos en dicha base de datos).

imagen iSQL

Fuente: https://latesthackingnews.com/2017/10/31/types-of-sql-injection/

Una máxima de seguridad es otorgar los privilegios estrictamente necesarios para realizar la tarea solicitada, ni más, ni menos. Como podemos observar en esta entrada (https://ayudawp.com/como-wordpress-utiliza-mysql/) WordPress dispone de diversas tablas, cada una para almacenar un tipo de información, que le permiten realizar todas las tareas asociadas a su funcionalidad como CMS . Para mejorar la seguridad de nuestro sistema aplicando el principio de mínimo privilegio, debemos tener en cuenta que en un uso normal, el usuario de la base de datos no necesitará cambiar la estructura ni tipo de permisos de la propia base de datos, solo gestionar los datos almacenados, por lo que lo primero que podemos hacer es proporcionarle exclusivamente los permisos de gestión de datos:

GRANT SELECT , INSERT , UPDATE , DELETE ON  `[DATABASE]` . * TO  ‘[USER]’@'[HOST]’;

donde DATABASE es el nombre de la base de datos de nuestro WordPress en el motor de base de datos que usemos (MySQL, María,…), USER el usuario de conexión y HOST el equipo desde el que establecemos la conexión (usualmente, localhost)

Por otra parte, cuando actualicemos la versión de WordPress o algún plugin sí que debemos tener permisos para cambiar la estructura de la base de datos.  Además, solo los usuarios autenticados escribirán alguna vez en la base de datos: por ejemplo para publicar entradas o comentarios (si no permitimos que los NO autenticados publiquen comentarios, por supuesto) o cambiar la contraseña; por lo que para los NO autenticados, el usuario de conexión a la base de datos debería tener SOLO permisos de lectura.

Este razonamiento nos lleva a que, para garantizar el principio de mínimo privilegio (e, incluso, el de mínima exposición) debemos disponer de diferentes usuarios de la base de datos para utilizar en diferentes tipos de conexión con el objetivo de que cada usuario disponga de los permisos adecuados a las necesidades del momento.

¿Cómo podemos disponer de varias conexiones en WordPress?

Modificando los ficheros:

  1. wp-config.php para definir los usuarios de la base de datos y sus contraseñas de acceso (necesitamos definir tantas variables equivalentes a DB_USER y DB_PASSWORD como usuarios con distintos perfiles necesitemos)
  2. wp-includes/load.php, en concreto, la función  requiere_wp_db() para añadir un código PHP cuyo objetivo sea generar una conexión con el usuario de la base de datos apropiado en función de si está el usuario -del WordPress– identificado o no (lo estará siempre que exista la cookie cuyo nombre sigue este patrón ‘wordpress_logged_in*’) y, en el caso de estarlo, que sea el administrador del sitio (el contenido de la cookie indica el usuario). La conexión que, por defecto, tiene esta función es:

$wpdb = new wpdb( DB_USER, DB_PASSWORD, DB_NAME, DB_HOST );

En nuestro caso, tras las comprobaciones pertinentes, DB_USER y DB_PASSWORD deberían ser las definidas en el paso 1 para los “otros” usuarios.

Por último (o lo primero a realizar, da igual) debemos crear los usuarios con la contraseña y los permisos adecuados en la base de datos. Para el ejemplo, 3 para estas 3 situaciones y permisos:

  • Para usuarios NO autenticados, crearemos un usuario de la base de datos de solo lectura (es decir, permisos para SELECT)
  • Para usuarios autenticados que no sean el administrador, crearemos un usuario con  permisos de gestión de datos: SELECT, INSERT, DELETE y UPDATE
  • Para el usuario administrador: el que ya trae WordPress por defecto que permite todo.

Con estas tareas, en el caso de sufrir un ataque iSQL, podemos minimizar problemas o, directamente, no tenerlos si no están implicados usuarios autenticados.

¡Espero que os sea útil!

PD: ¡Cuidado con los cambios que hacéis en la base de datos y en los ficheros mencionados! No haced los cambios directamente en el entorno que tengáis en producción, por si acaso, y además, tened copias de seguridad.

PD2: Este es un ejemplo sencillo con 3 perfiles, pero podemos incluir todos los que consideremos. Por ejemplo, podríamos distinguir entre perfiles de usuario de WordPress (subscriptor, editor, etc ) definiendo para cada uno de ellos un usuario de la base de datos con los permisos por tabla estrictamente necesarios de tal forma que, por ejemplo, tabla a la que un perfil de usuario no tenga que acceder (wp_options para subscriptores), tendrá prohibido el acceso a ella.

PD3: Para más información sobre securizar WordPress:

 


Presentaciones de la segunda parte de la asignatura “Servidores Web”

Aquí dejo las presentaciones que he usado en las dos última sesiones de la asignatura de Servidores Web del Máster Universitario en Desarrollo de Aplicaciones y Servicios Web.

En estas sesiones hemos tratado:

  • Nginx:

  • Nodejs (características y usos principales):

  • Pruebas en servicios web:

  • Cloud: AWS y Azure

¡Espero que os sea útil!


Transparencias de la asignatura “Servidores Web”

Aquí dejo las presentaciones que he usado en las dos primeras sesiones de la asignatura de Servidores Web del Máster Universitario en Desarrollo de Aplicaciones y Servicios Web.

La primera sesión fue sobre el protocolo HTTP:

La segunda sobre Apache:

¡Espero que os sean útiles!


Ejemplo de uso Oauth para publicar una imagen en Twitter

Este fin de semana he estado entretenido programando un back-end de ejemplo para publicar imágenes (con su correspondiente texto) en Twitter, usando la librería de PHP https://twitteroauth.com/ La idea era implementar en el servidor (“server-side flow” de OAuth) las llamadas al API de Twitter para conseguir la autorización y publicación de una imagen con su texto (que se recibe en la llamada al primer PHP).

El código es muy sencillo, hace lo justo, sin comprobaciones que no tengan que ver con el objetivo y su única finalidad es docente (por ahora).

Está dividido en 2 partes. La primera (twitter.php) es la que recibe la petición de publicación, obtiene el REQUEST_TOKEN y solicita la autorización del usuario. La segunda será invocada por el API de Twitter y se encargará de obtener el auth_token necesario para publicar la imagen con el texto asociado (status).

El código, que se explica solo, lo he publicado en https://github.com/jagilma/imageToTwitter

Creo que, además, es un ejemplo útil para conocer básicamente el proceso en el lado del servidor de OAuth2.

¡Espero que os sea útil!


Infraestructura de monitorización basada en Grafana (más Influxdb y Telegraf). Primera parte

Como prueba de concepto comentaré los pasos que he seguido para disponer de un panel que muestre la analítica de un servidor web con Apache. Junto a Grafana, tendremos influxdb y Telegraf, los 3 elementos de nuestra infraestructura de medición y análisis que nos permitirá disponer de un potente framework  para realizar análisis en tiempo real de series históricas.

Leer más


Google authenticator como 2FA en Debian

El año pasado probé Google Authenticator como 2FA en una CentOS. Hoy he usado la información de esa entrada para configurar, ¡por fin!, un 2FA para el acceso por SSH a mi almacenamiento personal.

Como la distro es Debian, hay un pequeño cambio: el paquete que debemos tener instalado:

apt-get install libpam0g-dev

Debemos tener instalado tanto gcc como make para poder compilar la librería de google.

Un detalle más es que, al contrario de lo que comenté en mi anterior entrada, para configurar mi Android he preferido usar la secret key que obtenemos al ejecutar Google Authenticator para el usuario que queremos proteger.

¡Espero que os sea útil!


ownCloud y Raspberry PI

Tras un aviso de Dropbox para que reduzca los muchísimos GB que me sobran al haber “caducado la oferta” por pertenecer a la UA, he decidio crearme mi “ownCloud” con un disco duro de 1TB que tenía y una Raspberry PI.

Sobre como instalarlo hay muchas entradas en la red (I, II, III, IV,  …) así que poco más que añadir o comentar, salvo:

Leer más


Las cookies nos permiten ofrecer nuestros servicios. Al utilizar nuestros servicios, aceptas el uso que hacemos de las cookies. Más información.