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:

 


App simple para esteganografía y marcas de agua en fotos e imágenes

La esteganografía es la aplicación de técnicas que nos permiten ocultar mensajes u objetos dentro de otros, llamados portadores, con el objetivo de que no se perciba su existencia. Uno de los usos que podemos darle es como “marca de agua” oculta pero que identifica al propietario de una imagen (aunque no ofrece garantías totales debido a los potenciales ataques que pueden realizarse).

Esto es lo que hace esta pequeña aplicación: por un lado marcar nuestras imágenes y, por otro, poder comprobar las marcas que hayamos introducido. Estas marcas son de texto y podremos ocultarlas, además, cifradas con AES, SHA-512 o HMAC-SHA512. Permite, además, insertar texto o una imagen como marca de agua  clásica, es decir, visible.

El proceso de marca de una imagen (ver figura 1) consiste en:

  1. Configurar el texto, contraseña y método de cifrado para la parte estego y el texto o imagen para la marcar de agua (junto con tamaño, dónde insertarlo, etc)
  2. Cargar la imagen a marcar
  3. Por último, marcar/firmar la imagen.
  4. Si queremos disponer de una copia de la imagen marcada (no cambia la original) debemos descargarla a nuestro disco. Si no lo hacemos, la perderemos con simplemente recargar la página.
  5. Por último, podemos guardar la relación texto, contraseña, método y nombre de la imagen para tener un historial de acciones que podamos consultar (para quien tenga tan mala memoria como yo 😉 ). ¡Y cuidado! Estas acciones se guardan en el almacenamiento interno del navegador (en concreto, Indexed DB), por lo que tendremos una copia en cada ordenador, sistema operativo y navegador que utilicemos para firmar imágenes.

Figura 1.- Proceso de firma de una imagen

El proceso de comprobación de firma (ver figura 2) se corresponde con la opción Decode del menú superior y es:

  1. Configurar el texto, contraseña y método de cifrado
  2. Cargar la imagen a marcar
  3. Chequear si el texto, con el cifrado introducido, está presente en la imagen.

Figura 2.- Proceso de comprobación de marca de una imagen

Para el proceso de esteganografía he usado esta librería que oculta la marca proporcionada en el canal alfa de la imagen dada. Este algoritmo aumenta (demasiado para mi gusto) el tamaño del fichero resultante, no funciona con imágenes con fondos transparentes y si se modifica la imagen (recortes, etc) se “pierde” la marca. Sería una buena idea sustituirlo por otro mejor (¿voluntarios/as? Yo dudo mucho que lo haga).

Por último, para seguir probando cosas con Angular (este era mi objetivo cuando empecé con esta app), añadí botones para publicar en redes sociales, aquellas que proporcionan un API rest para poder escribir, es decir, Twitter, Facebook, Pinterest y Flickr. Instagram no debido a que no permite (o permitía, no sé si ahora lo hacen) escribir.

La he probado tanto para GNU/Linux como Windows 10 con Firefox 45 y Chrome 52. También la he probado en mi móvil (Nexus 5), tomando una foto y, salvo publicar en RRSS (por tamaño de la foto) sí que ha funcionado el marcar/comprobar con estego y descargar la foto marcada.

¡Espero que os sea útil!

PD: Como es muy mejorable, he dejado los fuentes en https://github.com/jagilma

Guardar

Guardar


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!


Creando cuadro de mandos con Grafana. Segunda parte

Con las instalaciones y configuraciones vistas en la entrada anterior, tenemos la infraestructura1 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. Lo que nos falta es crear el cuadro de mando que necesitemos para monitorizar y analizar nuestro servicio. En la URL http://IP_de_Grafana:3000 tendremos la aplicación web que, fácilmente, nos lo permitirá. El proceso de configurar Grafana con Influxdb es muy sencillo y está muy bien documentado en el sitio web de Grafana.

Leer más


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


Clase decoradora para calcular el tiempo de ejecución de funciones

Una de las características de Python es el uso de funciones y clases decoradoras muy útiles cuando estamos evaluando rendimiento y lo que necesitamos es un cronómetro que nos mida cuánto tarda en ejecutarse una función (cualquiera de las que tenemos). Vamos a ver cómo calcular el tiempo de ejecución de funciones:

class getTime:
    def __init__(self, function):
        self.function = function
    def __call__(self, *args, **kwargs):
        start = time.time()
        result = self.function(*args,**kwargs)
        global t_time
        t_time=[self.function.__name__, time.time()-start]
        return result

Esta clase decoradora se puede utilizar de la siguiente forma en todas las funciones para las que queremos medir tiempo:

@getTime
def sendData(data):

¡Espero que os sea útil!


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