Honeytokens

Los sistemas de decepción de intrusos siempre me han parecido muy interesantes de cara a garantizar la seguridad de una organización; si bien los más complejos, las honeynets, no suelen implantarse con frecuencia salvo en entornos grandes y/o especialmente concienciados en temas de seguridad (digamos que los beneficios obtenidos del sistema no suelen cubrir el coste asociado a la implantación y al mantenimiento del mismo), los sistemas sencillos, los honeypots, tienen, bajo mi punto de vista, una buena relación coste/beneficio.

Dentro de los honeypots, los sistemas más triviales son los honeytokens: elementos que simplemente por “tocarlos”, por acceder a ellos, generan una alarma que puede proporcionar información muy valiosa a la organización: intentos de intrusión, intentos de robo de información, etc. Este subconjunto es particularmente interesante, porque a cambio de una inversión mínima —existen honeytokens muy sencillos, y su mantenimiento una vez implantados es casi inexistente— obtenemos una información de alto valor.

En la red existen multitud de honeytokens ya prediseñados y listos para ser “dejados caer” en los sistemas corporativos con una mínima parametrización; una vez implantados, nos indicarán que algo anómalo sucede con una tasa de falsos positivos casi igual a cero, lo cual es obviamente muy interesante (uno de los problemas de los sistemas de detección de intrusos basados en red es la tasa de falsos positivos que pueden llegar a generar, y el coste asociado a procesar toda la información que producen día a día). Aparte de los honeytokens ya prediseñados y que todo el mundo conoce, no es difícil diseñar alguno “ad hoc” para nuestra organización: un registro JFK, un fichero que no debe ser accedido, un puerto que no debe ser usado… Uno de estos sistemas, que IMHO es muy interesante y nos permite detectar usuarios “curiosos” (generalmente internos) que tratan de acceder a información a la que no deberían puede ser el siguiente:

– Creemos un fichero “DESPIDOS.DOC” en un recurso compartido por Samba, por ejemplo.

– Gracias a la API inotify (en Linux), y al paquete inotify-tools, podemos hacer un monitor que detecte diferentes accesos al sistema:

inotifywait -m -e access DESPIDOS.DOC | while read FILE ACTION; do ACCION done

– Generalmente, un acceso de un usuario a un fichero utilizando una aplicación se traduce internamente por N accesos; podemos utilizar un buffer intermedio que “limpie” los accesos espúreos. El monitor se complica ligeramente, pero no deja de ser trivial (y lo lanzamos pasándole como parámetro la ruta del fichero a monitorizar):

#!/bin/sh

MARGEN=60
LASTU=0
LASTT=0

# Accion a realizar ante un acceso
function action(){
echo "ACCESO de $USER a $FILE en modo $ACTION"
}

# Al realizar un acceso para el usuario, en ocasiones se traduce internamente
# por N accesos. Ponemos un tampon para registrar el ultimo y no realizar
# ninguna accion si el siguiente es del mismo usuario dentro de un margen de
# tiempo definido ($MARGEN)

function buffer(){
if [ $USER -eq $LASTU ]; then
	DIFF=`expr $TIME \- $LASTT`
	if [ $DIFF -gt $MARGEN ]; then
		action
	fi
else action
fi
LASTU=$USER
LASTT=$TIME
}

if [ $# -ne 1 ]; then
	echo "Deteccion de acceso a ficheros"
	echo "USO: $0 fichero" 
	exit -1
fi

inotifywait -m -e access $1|while read FILE ACTION; do 
	USER=`ps -ef|grep $FILE|head -1|awk '{print $1}'`
	TIME=`date +%s`
	buffer 
done

– Si lo lanzamos en el arranque, invocándolo convenientemente, y sustituyendo en la función action() la orden echo por algo más elaborado (un evento, un mensaje a móvil, un correo electrónico…), conseguiremos detectar, como hemos dicho, a los usuarios que puedan ser más curiosos en la organización. No tenemos más que sentarnos a esperar nuestros eventos, SMS o lo que hayamos decidido enviar cuando se detecta un acceso :)

Ojo, el código anterior es fruto de veinte minutos de trabajo y por supuesto se puede mejorar por mil sitios, pero espero que sirva para hacernos una idea. Adicionalmente, yo provengo del mundo Unix y no conozco otros entornos con la profundidad necesaria para hacer algo parecido a esto, pero estoy seguro que en la mayor parte de sistemas (Windows, AS/400…) es posible —y no especialmente costoso— diseñar cosas parecidas que nos permitan detectar el interés de nuestros usuarios por acceder a información que no deberían ver…