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…

Comments

  1. Solo un pequeño matiz: Decepcion de intrusos??

  2. El término “decepción” es una traducción algo “dudosa” del término anglosajón “deception”, que significa realmente “engaño”. Por tanto, estaríamos hablando de “sistemas de engaño de intrusos”.

    No obstante, a pesar de lo extraño de la traducción, es habitual encontrar “decepción de intrusos” en bibliografía relacionada, y es así como suele denominarse a los Honey*.

    Sirva esto como aclaración.

  3. Francisco Benet says

    El post me ha gustado mucho, pero me pregunto yo : ¿el hecho de descubrir usuarios curiosos que deberia decirnos? Creo que, si existe una politica de privacidad de datos o de clasificación de la informació o similares en la organización que este bien implantada, el curioso lo que le pasa es que tiene demasiado tiempo libre. Es decir ¿han violado la seguridad? ¿han infringido alguna politica?

    Me gusta conocer los habitos de los usuarios, para poder predecir el comportamiento y asegurar la información, pero no acabo de ver la relación.

  4. Brillante, sencillo y efectivo, como todo lo que he visto hasta ahora que hacéis. La sensación de impunidad es caldo de cultivo de incidentes y la mejor disuasión es la sensación de vigilancia constante.

    Me ha recordado a algo que escribí hace tiempo que tiene que ver con la teoría de la vigilancia. El Panopticon (“verlo-todo”) se diseñó como un edificio o máquina de la vigilancia circular. Su diseño se aseguraba que ningún preso podría ver jamás al “inspector@@@ quién ejercía la vigilancia desde una ubicación central privilegiada dentro del edifico. El preso nunca podría nunca saber cuando estaba siendo vigilado: la propia incertidumbre mental sería un instrumento crucial del método de vigilancia.

    Podéis leer toda la entrada en http://seguridad-de-la-informacion.blogspot.com/2005/04/el-panopticon-teora-de-la-vigilancia.html.

    Además, esta filosofía que habéis diseñado podría ser utilizada para lograr implantar lo que apuntan Edgard y Dani en el blog Eddasec de “Autogestión de la seguridad basada en el comportamiento del usuario” y que publicaron en la revista SIC que podéis consultar aquí-> http://www.docstoc.com/docs/document-preview.aspx?doc_id=4107506

  5. Antonio Villalon says

    Hola Javier
    Muy interesantes ambos artículos. Gracias por la info! :)
    Saludos
    Toni

  6. Antonio Villalon says

    Hola Francisco
    Independientemente de políticas implantadas, clasificación de la información, etc., siempre es interesante saber los hábitos y curiosidades del personal (al menos para mí); sin ser a priori una violación de la política de seguridad (o sí, depende de la política), la curiosidad mata al gato, y si tengo a alguien demasiado curioso en mi organización me interesa, al menos saberlo. Esto no significa que estemos ante un robo de información o similar, que sería un tema mucho más espinoso: simplemente que tengo a alguien curioso, con tiempo, o similar, y para evaluar si se trata de un riesgo a mitigar debo, cuanto menos, saber la probabilidad de que ocurra…

    Saludos
    Toni

  7. Francisco Benet says

    Aclarando un poco mi comentario: me parece interesante conocer los hábitos de los usuarios, ya que podemos predecir posibles usuarios descontentos, avanzados o ávidos de información. Pero al final nos podemos encontrar realmente (y creo que es lo que pasa) que las políticas son papel mojado ya que no se dispone de tiempo ni recursos para implantar controles rigurosos de acceso a la información.

    No obstante, me ha gustado mucho el post.