WAF (Web Application Firewall) es un elemento de protección frente a ataques que se encarga de analizar el tráfico web dirigido a los distintos portales que pueda disponer una organización. Este tipo de firewalls se diferencia del resto en que procesa el tráfico HTTP(s) a nivel de la capa 7 de la pila OSI y por lo tanto permite capacitarlo de reglas de detección directamente sobre las tecnologías con las que estén diseñados y desarrollados los sitios web. Además, podemos diferenciar este tipo de dispositivos de lo que denominamos un IPS por las características de identificación de patrones anómalos.

Normalmente pueden operar en 3 modos:

• Modo negativo, o basado en listas negras.
• Modo positivo, o basado en listas blancas.
• Modo mixto, empleando una combinación de los modos negativo y positivo.

Si se emplea el modo negativo exclusivamente, éste puede provocar una cantidad mayor de falsos positivos, además de sufrir un retardo mayor en el tiempo de procesamiento y en definitiva menor protección. En el lado positivo, tiene un menor tiempo de implementación.

[Read more…]

Hace unos días recibí una llamada de socorro de un familiar, de estas que te hacen temblar porque esperas que te diga que tiene un montón de virus en el ordenador, en el móvil o en el aire acondicionado. Sin embargo, resultó que se trataba de un caso típico de estafa o “phishing telefónico”, ataques que no deja de sorprenderme que sigan siendo efectivos.

En este caso, el ataque se inicia con la llamada por parte de un falso técnico de Microsoft. Ya había leído con anterioridad acerca de cómo actúan y qué hacen, pero me llamó la atención el grado de dispersión de este tipo de actividad, hasta el punto de llegar a personas cercanas. En 2012 ya había informes y reportes de especialistas de nuestro gremio que habían tenido la oportunidad de analizarlo, como el que se cita en este enlace de Viruslist. En éste, podemos repasar en detalle cada uno de los pasos que ejecutan los delincuentes.

1.- En primer lugar, el atacante realiza una llamada directa a la víctima, donde se identifica como un técnico de soporte de Microsoft. Que evidentemente, no lo es.

2.- A petición del atacante, la víctima accede a realizar una serie de comprobaciones falsas que le convencen de que su equipo está en peligro.

3.- Tras esto, el falso técnico convence a la víctima de que instale en su equipo una aplicación que le servirá para acceder de forma remota a su equipo y de esta manera solucionar su falso problema.

4.- Una vez instalado el malware, el atacante ya es capaz de acceder de forma remota e instalar cualquier tipo de malware, o incluso pedir dinero por los “trabajos” que han realizado.

5.- Por último, la víctima accede a pagar una cantidad de dinero (250$) mediante PayPal, VISA, u otros medios de pago.

En el caso de mi familiar, gracias a las advertencias que les suelo hacer (aunque muchas veces se olvidan), tuvo el nivel suficiente de desconfianza para sospechar, no caer en la trampa y colgar el teléfono. Me comentó que la llamada era de una persona que comenzó hablándole en inglés, y que al no entenderlo muy bien, apenas fue capaz de decir en castellano que tenían indicios de que estaba infectado su ordenador y por tanto corría un grave peligro.

He de reconocer que me sorprende que una persona confíe en un extraño que le llama por teléfono hasta el punto de de dejarle “meter mano” a su ordenador, y además, que pague una cantidad de dinero por los trabajos realizados. Pero esas cosas, por desgracia, siguen sucediendo.

Pero imaginemos que la persona que recibe la llamada, en lugar de estar en su casa, está sentado delante del PC de su empresa. La tecnología no ha llegado al punto de detectar este tipo de ataques, así que no hay firewall o IDS que detecte estas llamadas. En ese caso, si la persona no está lo suficientemente concienciada en materia de seguridad, es probable que facilite la instalación de troyanos y puertas traseras en los sistemas corporativos.

Sirva este breve post para alertar a los lectores de este tipo de ataques y que nunca es tarde para alertar a tus amigos y familiares, aunque parezca uno un poco paranoico. En mi caso, creo que esperaré el momento de recibir esta llamada para pasar a la acción.

Weblogic es una plataforma creada por Oracle en la que se integran varios productos de la misma familia, que tienen por objetivo ayudar a la gestión de procesos de las empresas que lo utilizan. Desde el punto de vista más técnico podemos decir que se trata de una plataforma basada en java EE y compuesta por servidores de aplicaciones, middlewares, servidores web, etc. que permiten gestionar la configuración de cada uno de ellos de una forma totalmente integrada. Para acceder a esta plataforma se requiere un usuario, el cual se crea durante la fase de instalación del producto. Este usuario permite configurar todos los componentes y complementos necesarios para cada caso.

Durante la instalación en modo desarrollo, es decir, previo a paso a producción, el asistente de configuración genera un archivo de identidad de arranque (boot.properties) necesario para la administración inicial del servidor. La cuestión es que este archivo contiene el nombre de usuario y la contraseña del usuario administrador, aunque de forma cifrada.

Una vez establecidos el usuario y la contraseña, se puede ver cómo quedan guardados:

En este fichero, a simple vista, se puede observar que se almacenan las credenciales de forma segura. A pesar de ello, debemos saber que si un usuario malintencionado o intruso accediera al sistema donde reside, podría obtener los credenciales en claro.

Los pasos que se tendrían que realizar desde el propio sistema son los siguientes:
1.- Acceder al directorio [FMW_HOME]/wlserver_XX.Y/server/bin/
2.- Ejecutar el script setWLSEnv.sh para configurar las variables del entorno.
3.- Descargar el script en python (jython) decrypt.py y ejecutarlos de la siguiente manera:

~$ java weblogic.WLST decrypt.py

Ejemplos:
Obtener el password:

~$ java weblogic.WLST decrypt.py /opt/oracle/Middleware/user_projects/
      domains/base_domain {AES}TV0pZXXXXXXXXXXXXXXXXXXXXXXXXXXXXXFjI6/zM\=

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

RESULT: micontrasenyacifrada

Obtener el usuario:

~$ java weblogic.WLST decrypt.py /opt/oracle/Middleware/user_projects/
     domains/base_domain {AES}MhcB2XXXXXXXXXXXXXXXXXXXXXXXXXXXXXFGHi5/jI\=
Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

RESULT: miusuariocifrado

En este caso, es importante eliminar el fichero una vez hayamos terminado de parametrizar el servidor en modo desarrollo. De esta forma nos evitaremos que caiga en manos de quien no debe.

decrypt.py

#============================================================================= 
# Jython Script for displaying de-crypted WebLogic boot.properties files 
# 
# To run, change to a WebLogic domain directory and execute: 
# 
# 
# Add parameter '-?' to the end of the command line to display more help 
#============================================================================= 

import os 
from java.io import FileInputStream 
from java.util import Properties 
from weblogic.management import EncryptionHelper 
from weblogic.security.service import SecurityManager 
from weblogic.security.subject import SubjectManager 

#============================================================================= 
# Main 
#============================================================================= 
def main(): 
#for arg in sys.argv: 
# if arg.count(arg.strip()): 
# printUsageAndExit() 
saltFilePath=os.path.join('security', 'SerializedSystemIni.dat') 
if not os.path.exists(saltFilePath): 
print "Error: The script must be run from a WebLogic domain direcotry or 
    a directory containing '%s'" % saltFilePath 
printUsageAndExit() 
try: 
open(saltFilePath, 'r').close() 
except IOError: 
print "Error: The file '%s' is not readable - check file permissions" % saltFilePath 
printUsageAndExit() 
processBootFiles(os.curdir, descryptPropsFile) 

#============================================================================= 
# Decrypt (Note, to encrypt just use: EncryptionHelper.encrypt(text)) 
#============================================================================= 
def decrypt(text): 
getKernelIdMethod = SecurityManager.getDeclaredMethod('getKernelIdentity', None) 
getKernelIdMethod.accessible=1 
return EncryptionHelper.decrypt(text, getKernelIdMethod.invoke(SecurityManager, None)) 

#============================================================================= 
# Process Boot Files 
#============================================================================= 
def processBootFiles(rootPath, processFunc): 
if not os.path.isdir(rootPath): 
return 
fileNames = os.listdir(rootPath) 
for fileName in fileNames: 
path = os.path.join(rootPath, fileName) 
if os.path.isfile(path): 
if fileName == 'boot.properties': 
processFunc(path) 
elif os.path.isdir(path): 
processBootFiles(path, processFunc) 
processFunc("./boot.properties") 

#============================================================================= 
# Decrypt Props File 
#============================================================================= 
def descryptPropsFile(filepath): 
print 
print '----- Decrypting %s -----' % filepath 
try: 
properties = Properties() 
file = FileInputStream(filepath) 
properties.load(file) 
file.close() 
for entry in properties.entrySet(): 
print '%s = %s' % (entry.key.strip(), java.lang.String(decrypt(entry.value.strip()))) 
except IOError: 
print "Error: Unable to read file '%s' - check file permissions" % filepath 
print 

#============================================================================= 
# Print Usage And Exit 
#============================================================================= 
def printUsageAndExit(): 
print 
print 'wlsdecrypt.py' 
print '-------------' 
print 
print "Jython Script for displaying de-crypted boot.properties files from a 
    WebLogic domain. Before running the script, change directory to the directory 
    that contains a WebLogic domain (or a directory containing 'security/
    SerializedSystemIni.dat' and one or more associated 'boot.properties' files). 
    Run this script via WLST or directly via the Java/Jython launch command (the 
    latter option requires both 'jython.jar' and 'weblogic.jar' to be added to 
    the classpath)." 
print 
print 'Example Usage:' 
print 
print '> /opt/weblogic/wlsadm/weblogic92/common/bin/wlst.sh ~/home/chordadm/
    wlsdecrypt.py (Unix)' 
print 
print '> C:\\bea\\weblogic92\\common\\bin wlst.cmd C: myscripts 
    wlsdecrypt.py (Windows)' 
print 
exit() 

# 
# Invoke main and end 
# 
main()

Me gustaría hablar del framework DionaeaFR de análisis de resultados del honeypot Dioanea del que probablemente hayáis oído hablar y hemos hablado en el pasado en este mismo blog (véase Plantas carnívoras vs. nuevos bichos (I) y Algunos scripts para Dionaea). Se trata de un framework en forma de interfaz web muy vistoso que ayuda a analizar e interpretar los datos de uno de los honeypots más populares, evidentemente, Dionaea.

Antes, vamos a volver a comentar algunos detalles de este honeypot antes de hablar de la interfaz. Puesto que existen multitud de tutoriales y documentación extensa de su funcionamiento, únicamente nombraré las características principales a grandes rasgos. Este honeypot está desarrollado principalmente en el lenguaje de programación python, lo cuál hace que sea muy flexible en el caso de que queramos desarrollar alguna extensión o modificar alguna característica en concreto. Dispone de un archivo de configuración mediante el cual definiremos qué servicios de red pretendemos “endulzar”. Entre los que permite configurar existen servicios como mysql, smb, ssh, ftp y web, servicios muy susceptibles de ser accedidos por atacantes que buscan vulnerabilidades y configuraciones por defecto para poder explotarlas.

Una de las características a destacar es que dispone de la posibilidad de almacenar el malware que un atacante intenta inyectar en alguno de los servicios expuestos, por lo que nos facilita el análisis de los ataques registrados, pudiendo comprobar el impacto que ocasionaría en un servicio en producción.

A lo que íbamos. Para facilitarnos la labor de análisis de resultados y poder obtener estadísticas de ataques registrados, Rubén Espadas (@rubenespadas), ha liberado el framework DionaeaFR. Al ejecutarlo obtenemos una clasificación de todos los registros que ha ido recogiendo el honeypot accesible desde una interfaz web que sirve el propio framework.

A continuación se muestran algunos pantallazos de DionaeaFR para que podáis ver el diseño que tiene.

Como pantalla principal, tenemos una especie de cuadro de mando en el que aparece una clasificación por origen y número de ataques por fecha capturados por el honeypot. Lo podéis ver a continuación:

Si vamos recorriendo las opciones de la interfaz, accedemos a la siguiente en la que podemos ver un resumen de los ataques, ordenados por fecha, a los cuáles podemos acceder para ver el detalle:

En cada uno de los registros podemos observar las características de la conexión que un posible atacante ha intentado realizar sobre el honeypot:

Otras pantallas que podemos ver son gráficas con detalles de conexiones por IP orígen, puerto destino, o evolución de ataques en los últimos 7 días:

Además, me gustaría destacar 2 pantallas adicionales a través de las cuáles podemos geolocalizar las IPs origen de los ataques que registra Dionaea:

En definitiva, un diseño muy acertado que proporciona vistosidad y facilidad en la interpretación de resultados de Dionaea. Las primeras conclusiones como curiosidad son que si publicara un servicio como MSSQL o un servicio SIP de voip, tendría una cantidad importante de ataques sobre ellos y la mayoría desde países como China. Con la ayuda, en este caso concreto, de este honeypot, se podría analizar qué medidas de protección tomar para evitar todos los intentos de ataques registrados.

Por último, resaltar que los datos mostrados en las capturas de pantalla están recogidos de un honeypot instalado tras una línea de Internet común de un particular sin ninguna configuración extraordinaria, por lo que podemos comprobar el número de intentos de ataques a los que estamos expuestos en el caso de publicar cualquier servicio a Internet.

Aunque he probado muchos de los proxys que permiten modificar peticiones web “en vivo” como pueden ser burp, webscarab, etc. recientemente descubrí uno bastante interesante, no sólo por los desarrolladores y el contexto en el que se presentó, sino también por las características que presenta y la arquitectura que lo integra. Se trata de Mallory Proxy, un proxy desarrollado por el grupo de expertos en seguridad informática Intrepidus que fue presentado en la Black Hat de 2010.

Mallory está desarrollado en python y se presenta con una parte de la aplicación que se ejecuta en modo servicio y otra como interfaz de configuración e interacción para el usuario.

Para el que quiera probar Mallory, la aplicación dispone de 2 opciones básicamente. La primera es seguir las instrucciones de instalación y descargar e instalar tanto los fuentes del proxy como las dependencias. La segunda es descargase una imagen de VMWare cuyo sistema operativo de base es Ubuntu y que viene tanto con el software como con las dependencias.

[Read more…]

Hace unos días se hizo público una vulnerabilidad sobre PHP-CGI. Esta vulnerabilidad puede ser aprovechada para conseguir código fuente de sitios web vulnerables, lo que significa que el código php de la web vulnerable queda expuesto para que sea analizado por un atacante que explote dicha vulnerabilidad. Hay que tener en cuenta que en muchos casos se encuentran usuarios, passwords, rutas de ficheros, ips privadas de servidores, etc dentro del código php, por lo que en estos casos, la criticidad de esta vulnerabilidad es mayor.

Dicha vulnerabilidad puede ser explotada de un forma muy sencilla, añadiendo los caracteres ?-s al final de la URL, que es lo mismo que ejecutar php-cgi con la opción -s.

[Read more…]

Una de las recomendaciones básicas de seguridad es el uso de cifrado para almacenar información sensible y confidencial. De esta forma se restringe el acceso a la misma a quienes conozcan la clave con la que se ha cifrado el medio de almacenamiento correspondiente. Se trata de una medida de prevención ante robo físico o pérdida del sistema de almacenamiento y protección del acceso lógico mientras no esté montada la partición cifrada. Aún así, existen técnicas para obtener la clave de cifrado del sistema operativo, siempre y cuando se tenga acceso físico al sistema objeto del ataque. Se trata de los ataques de arranque en frío (Cold boot attacks) y por otra parte ataques DMA, a través de puertos como el firewire, etc… .

Entre otras medidas de prevención frente a este tipo de ataques, existe una que fue presentada en las charlas de seguridad organizadas por USENIX en 2011: TRESOR. Se trata de un parche para el kernel de Linux compatible con arquitecturas x86 que implementa el algoritmo de cifrado AES basado en el manejo de claves de cifrado en registros del procesador. A diferencia de los sistemas de cifrado habituales, la mayoría de los cuales almacenan las claves en la memoria RAM del sistema, éste aprovecha los registros de debug como medio de almacenamiento seguro. En sistemas de 32 bits estos tienen 4 registros x 32 = 128 bits en total, lo suficiente para almacenar la clave secreta de AES-128. Pero en sistemas de 64 bits estos tienen 4 x 64 = 256 bits en total, suficiente para almacenar cualquiera de las longitudes de clave definidas para AES de 128, 192, y 256 bits. Los registros de depuración son un recurso privilegiado del anillo 0 de privilegios del sistema, lo que significa que ninguna aplicación que se ejecuta en el espacio de usuario, anillo 3, puede acceder a los registros de depuración directamente. Cualquier acceso se realiza a través de llamadas al sistema, es decir, a través de ptrace.

TRESOR parchea la llamada al sistema ptrace para devolver como resultado -EBUSY cada vez que un registro de breakpoint es solicitado, de esta forma se reserva su uso de cara al espacio de usuario. La clave almacenada en estos registros es guardada aplicando 2000 iteraciones del algoritmo SHA256 y consiste en una clave compuesta entre 8 y 53 caracteres que se solicita al usuario durante el proceso de arranque, directamente en el espacio del kernel. Sí que es cierto que durante el proceso de almacenado de la clave, se usa la memoria RAM, pero se trata de una transacción de muy poca duración, que además se realiza un borrado seguro de las partes de la clave que puedan haber quedado en la propia memoria, siempre antes que cualquier proceso de usuario se ejecute.

Ejemplo de uso:

> cryptsetup create tr /dev/sdb1 -c tresor
   Enter passphrase: ******
> mkfs.ext2 /dev/mapper/tr
> mount /dev/mapper/tr /media/tresor/

Tabla comparativa de velocidad de procesamiento de información según el método de cifrado:

Más información:

http://www1.informatik.uni-erlangen.de/tresor

Entre toda la información que recopilamos diariamente, podemos encontrar un interesante artículo publicado por la empresa de seguridad Panda Labs en una nota de prensa que trata sobre el mercado negro de la compra/venta de información robada.

He de decir que, siendo consciente de que existe un mercado bastante amplio de este tipo de información, no deja de sorprenderme la utilización de técnicas clásicas de venta que se emplean con tal de llegar a captar compradores. Los propios vendedores lanzan mensajes de tipo “busque, compare y si encuentra algo mejor, compre…”, e incluso permiten un breve tiempo de prueba para que el cliente pruebe el producto comprado, y si no le gusta puede devolverlo. Es increíble que en un mercado como este pueda llegar a haber tanta competencia, cuyo crecimiento queda evidenciado por la gráfica de la izquierda.

No es aventurado a la vista de los datos deducir que el malware es un negocio muy rentable, y me atrevo a decir que gran parte es gracias a las malas prácticas de muchos usuarios, que normalmente se traduce en un arrepentimiento inmediato y un desprecio hacia las nuevas tecnologías, debido a que muchos de ellos desconocen los riesgos y aún conociéndolos piensan que nunca van a ser víctimas. Para hacerse una idea de lo que podemos encontrar entre los productos ofertados, hay: tarjetas de crédito, falsas tiendas online, alquiler de spam, exploits de vulnerabilidades para conseguir el control de equipos, malware de todo tipo, etc… y por supuesto, información crítica de empresas muy valorada por la respectiva competencia.

Por otra parte, según el reporte, el FBI ha podido clasificar distintas especialidades dependiendo de la funcionalidad de cada persona involucrada en este tipo de mercados. Entre ellos podemos destacar los siguientes:

1. Programadores. Desarrollan los exploits y el malware que se utiliza para cometer los cibercrímenes.
2. Distribuidores. Recopilan y venden los datos robados, actuando como intermediarios.
3. Técnicos expertos. Mantienen la infraestructura de la “compañía” criminal, incluyendo servidores, tecnologías de cifrado, bases de datos, etc.
4. Hackers. Buscan aplicaciones exploits y vulnerabilidades en sistemas y redes.
5. Defraudadores. Crean técnicas de ingeniería social y despliegan diferentes ataques de phishing o spam, entre otros.
6. Proveedores de hosting. Ofrecen un entorno seguro para alojar contenido ilícito en servidores y páginas.
7. Vendedores. Controlan las cuentas y los nombres de las víctimas y las proveen a otros criminales mediante un pago.
8. Muleros. Realizan las transferencias bancarias entre cuentas de banco.
9. Blanqueadores. Se ocupan de blanquear los beneficios.
10. Líderes de la organización. Frecuentemente, personas sin conocimientos técnicos que crean el equipo y definen los objetivos.

Tal y como podemos comprobar, existe un gran nivel de especialización, así como infraestructuras totalmente organizadas y con roles perfectamente definidos que no tendrían nada que envidiar a muchas organizaciones; probablemente algunas serían susceptibles de ser certificadas en ISO 27001 e ISO 9001, aunque por supuesto, no creo que ninguna entidad de certificación se atreviese con la venta de servicios y productos ilícitos con los que sacar provecho a costa de la inseguridad de los sistemas y usuarios.

Tras conocer todos estos datos, se me ocurre una vez más sugerir el uso de buenas prácticas tales como desconfiar de sitos web desconocidos, no abrir correos sospechosos, mantener el antivirus actualizado… En general, mantener los sistemas informáticos protegidos, y como no, estar al día de noticias, parches, alertas de seguridad publicadas por fabricantes y empresas de seguridad como S2 Grupo en su blog https://www.securityartwork.es.

Para acabar, hay que indicar que aunque pongamos todas las medidas de seguridad a nuestro alcance, la seguridad total no existe, por lo que siempre existirá la posibilidad de que seamos víctimas de algún fraude tecnológico. En ese caso, es importante saber que puede denunciarlo a través de la Brigada de Investigación Tecnológica del cuerpo Nacional de Policía o a través del Grupo de Delitos Telemáticos de la Guardia Civil y por supuesto, puede realizar cualquier consulta al equipo de respuesta ante incidentes que la Generalitat Valenciana pone a disposición del ciudadano.

Seguimos con la serie sobre Honeynets, esta vez para hablar de las tipologías, que dependerán de los recursos de los que disponemos para implantar la honeynet. Según la tipología, aún siendo válidas todas ellas, estarán más o menos limitadas en el cumplimiento de los objetivos propuestos.

Tendremos en cuenta la clasificación que propusimos en el anterior post donde se diferenciaba por localización. El tipo de honeynet a implantar, bien sea conviviendo con nuestros sistemas en producción o en un entorno totalmente aislado de la organización, marcará las directrices a la hora de decidir que tecnologías utilizar.

Entorno de PRODUCCIÓN

Si nos decantamos por una honeynet integrada en nuestra red organizativa en producción, debemos conocer las tecnologías que forman parte de nuestros sistemas para no utilizar otra que pueda interferir en el modelo productivo. En este caso y como ejemplo, si tenemos una política de seguridad donde se exige que la implantación de nuevos sistemas debe hacerse mediante virtualización, sabemos que la instalación de los diferentes honeypots no podrá realizarse en sistemas físicos convencionales.

[Read more…]

Gran parte de los esfuerzos del área de seguridad a la hora de establecer medidas de protección se basan en el aprendizaje de las técnicas utilizadas por los atacantes. Con este propósito, uno de los pilares fundamentales del personal dedicado a la seguridad está enfocado a la recopilación de información para su posterior análisis, para poder aplicar y reforzar las medidas de seguridad en la organización en función de las conclusiones obtenidas.

Pero, ¿qué información se recopila en este proceso y de qué forma? Existen muchas fuentes de información conocidas como pueden ser los informes de nuevas vulnerabilidades de aplicaciones concretas, estudios de analistas independientes, nuevas técnicas de ataque, o incluso información obtenida del último ataque sufrido sobre un recurso corporativo. Igual que en las novelas de contraespionaje o en las películas de “James Bond”, no es difícil imaginar técnicas de obtención de información que estén basadas en la implantación de señuelos o trampas en forma de aplicaciones, cuyo propósito es registrar la actividad sospechosa de los potenciales atacantes, para que éstos actúen sin darse cuenta de que su comportamiento está siendo realmente estudiado. Así nos lo cuenta Clifford Stoll en su libro “The Cuckoo’s Egg: Tracking a Spy Through the Maze of Computer Espionage” (N.d.E. Un libro que nadie interesado en seguridad debería dejar de leer).

Este es el funcionamento básico de los denominados honeypots: aplicaciones que simulan, de una forma más o menos interactiva, servicios o aplicaciones que registran la actividad sospechosa que un atacante pueda realizar sobre ellos. Al conjunto de honeypots que presentan una arquitectura lógica de red simulando un conjunto de sistemas, servicios y aplicaciones relacionadas, se le denomina honeynet. Por supuesto, en este tipo de entornos simulados no existe información real sensible ni relativa a la organización, pero si información aparentemente interesante que motive al atacante y le haga “perder” tiempo, al mismo tiempo que proporciona información sobre técnicas y métodos de ataque.

En esta línea existe un proyecto dedicado a aunar esfuerzos y desarrollar pautas para la creación, gestión y divulgación de estos sistemas, denominado el HoneyNet Project. En su web es posible encontrar tanto papers con información técnica como referencias a los denominados chapters de cada país relacionados con el proyecto.

En cualquier caso, en este tipo de entornos es recomendable no olvidar que estamos tratando con sistemas que interactúan con potenciales intrusos, y que los clasificamos como honeypots porque tanto la información que se expone como los sistemas que puedan verse “comprometidos” no interfieren de forma negativa en el proceso de negocio de la organización. Como habrán supuesto, el interés de estos sistemas y entornos es doble.

Por una parte, el registro de la actividad del atacante que interactúa con el honeypot o la honeynet muestra nuevas técnicas o tendencias de ataques de los que podemos aprender, y por lo tanto, permite planificar e implantar las medidas de seguridad oportunas a corto, medio e incluso a largo plazo para paliar posibles futuros ataques sobre los sistemas productivos de la empresa. Al mismo tiempo, la existencia de sistemas intencionadamente vulnerables conviviendo con sistemas de producción convenientemente securizados (aunque como saben, nunca lo suficiente) proporciona una forma muy efectiva de dirigir la atención del atacante lejos de los sistemas de negocio. Es importante, no obstante, que el entorno vulnerable esté adecuadamente aislado, evitando que pueda servir de puente hacia otros sistemas internos, y por tanto convirtiendo una herramienta en un problema.

Una vez disponemos de toda la información, ¿cómo podemos recopilar, analizar y aprovechar todos los datos que se van generando? Para ello existen correladores de información que ofrecen una integración bastante sencilla con la mayoría de honeypots existentes, y que a su vez son lo suficientemente flexibles como para adaptarlos al sistema en el que deba implantarse. El resultado de este análisis puede plasmarse en una serie de informes de actividad periódicos que representen el histórico y evolución de la actividad registrada, algo que veremos más adelante en esta serie.

Existe un refrán que dice “Para aprender, perder…”. En la serie de posts que se publicarán más adelante veremos como es posible aprender mucho y perder poco.

(Entrada escrita en colaboración con Alberto Segovia, co-autor de la serie)