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:

 


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!


Metadatos de ficheros con ‘find’

find es una orden presente en GNU/Linux que podemos utilizar para obtener mucha información. Es útil, por ejemplo, para saber qué ficheros se han modificado en un periodo de tiempo, por ejemplo, en las últimas 24 horas:

find . -type f -mtime 0

o los ficheros que tienen permisos de escritura tanto para el propietario como para su grupo:

find . -perm -220

También nos puede ofrecer información sobre la fecha o tiempo de acceso, modificación, de creación, tamaño que ocupa el fichero en bloques de 1K, número de inodos, número de enlaces duros,…, de los ficheros que cumplan ciertos criterios de búsqueda:

find . -mtime 0 -perm -111 -type f \
   -printf "%Ax;%AT;%Tx;%TT;%Cx;%CT;%m;%U;%G;%s;%k;%i;%p\n"

Esta orden nos mostrará la fecha y el tiempo de acceso, fecha y tiempo de modificación, fecha y tiempo de creación, permisos, identificador de usuario y grupo, tamaño del fichero, número de bloques de 1K, número de inodos y nombre del fichero (con -type f nos aseguramos que sean ficheros) que ha sido modificado en las últimas 24horas (-mtime 0) y que tiene permisos de ejecución habilitados para propietario, grupo y cualquier otro usuario (-perm -111).

¡Espero que os sea útil!

Referencias

  1. man find

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!


Transparencias de clase sobre “Gestión de usuarios y LDAP”

Continúo con la publicación de viejas transparencias de clase; en este caso, la primera que publico de las clases de Administración de Sistemas Operativos en Red que impartí entre 1999 y 2012 y del que todavía hoy (literal) he tenido que preparar y realizar un examen.

Con esta presentación estudiábamos en clase los módulos PAM, cómo llegar a ser root y compartir privilegios (su y sudo) y cómo usar un directorio para centralizar la autenticación y autorización de los usuarios de un sistema con GNU/Linux.

La clase duraba 1 hora y media y no teníamos tiempo para más. Si no, podríamos haber incluido profundizado con otros temas, como por ejemplo: 2FA.

¡Espero que os sea útil!


Transparencias de clase sobre “Firewalls”

Continuando con las publicaciones de viejas transparencias de clase de Administración e Instalación de Redes de Computadores, en particular, de las que dedicaba a seguridad en red, hoy toca el turno de la presentación que hice sobre el diseño y configuración de cortafuegos. Para estas transparencias usé como principal fuente de información el libro “Building Internet Firewalls” de D. Bremt Chapman y Elizabeth D. Zwicky, editado por O’Reilly.

¡Espero que os sea útil!


Guión para cambiar un carácter (o varios) en el nombre de ficheros

Como podéis comprobar todos aquellos que tengáis instalado ownCloud, existe una serie de caracteres que os provocan el error : “Files contains invalid characters…” cuando sincronizáis con el cliente de escritorio.

Si optáis por la solución cómoda como es cambiar el nombre, quitando el carácter problemático por otro (‘_’ es una buena opción), en GNU/Linux, con esta orden ejecutada desde el directorio que sincronizáis, sobra:

find . -type f -name ‘*:*’ | while read fich; do echo “Moving $fich a ${fich//[:]/_}”; mv “$fich” “${fich//[:]/_}”; done

Con ella cambio el carácter ‘:’ por ‘_’. Si queréis generalizar la orden para más caracteres, solo tenéis que modificar la expresión “${fich//[:]/_}” en los 2 sitios donde aparece y también el patrón ‘*:*’.

¡Espero que os sea útil!

PD: la orden echo “Moving $fich a ${fich//[:]/_}” es solo informativa; puede no estar.

Actualización:

PD2: Lo que aparece en negrita es una actualización. Se me olvidó indicar el patrón que busca ficheros cuyo nombre contiene el carácter deseado.


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