Estimados amigos de Inseguros.
En el post de hoy vamos a empezar una serie de artículo relacionados con la creación de una base de datos de Reputación IP. La idea es tener una bbdd de direcciones ip´s que han atacado de alguna manera a alguno de nuestros sistemas o honeypots.
De esta manera si tenemos actividad maliciosa en un vps externo o una sede remota, podremos obtener esa información y banear no solo en el VPS, sino en todos nuestros sistemas.
Para realizar esta práctica voy a trabajar con la base de datos instalada en OSSIM ya que la mayoría de mis eventos los centralizo en el SIEM, si los tengo disponibles para analizar, los tengo disponibles para almacenar.
Uno de los primeros pasos que debes hacer es el de la servilleta. Documentar las ideas que te vayan surgiendo en el proyecto y medio documentarlas. Yo suelo hacer esto, llegando a ser autentico fan de los folios A3 llenos de cajitas y flechas con los datos y procesos. Eso si, solo los entiendo yo xD.
El primer paso que vamos a hacer es conectarnos con nuestra bbdd de OSSIM para crear la estructura de la bbdd de IP REPUTATION. Los datos de configuración los tenemos en /etc/ossim/ossim_setup.conf.
Puedes usar cualquier base de datos que tengas o quieras crear, pero dado el gran número de registros que se van a insertar, tantos como Events Per Second tengas en tu SIEM, prefiero hacerlo en local en esa máquina para evitarme conectarme a otro Mysql externo. Para gusto los colores.
Para obtener información de actividad maliciosa en la red vamos a usar distintas fuentes de información.
Una de las fuentes que vamos a usar para nuestra IP REPUTATION es la base de datos
OTX de AlienVault. Si tenemos ya ese conocimiento de confianza de parte de una gran empresa, por qué no usarlo? Indicaremos en todo momento en nuestra bbdd que esas ip´s provienen de
OTX y no de nuestros sistemas internos.
En este capítulo de Inseguros vimos como registrarnos en el servicio para usarlo desde la web o desde OSSIM.
La bbdd es un fichero ubicado en /etc/ossim/server/reputation.data con el siguiente formato:
112.125.32.145#4#2#Scanning Host#CN#Beijing#39.9289016724,116.388298035#11
112.64.214.174#4#2#Scanning Host#CN#Shanghai#31.0456008911,121.39969635#11
113.108.197.251#4#2#Scanning Host#CN#Guangzhou#23.1166992188,113.25#11
113.193.6.214#4#2#Scanning Host#IN#Mumbai#18.9750003815,72.8257980347#11
Podemos investigar el log para saber cuando se está descargando la información y si existe alguna incidencia.
alienvault:/etc/ossim/server# tail -F /var/log/ossim/reputation.log
2015-03-11 09:15:03 Message-update: Reputation updated
2015-03-11 09:30:01 Message-feedback: Running reputation feedback
2015-03-11 09:30:01 Message-feedback: Getting data from database
2015-03-11 09:30:02 Message-feedback: Sending information (reputation step)
2015-03-11 09:30:03 Message-feedback: Information sent (reputation step)
2015-03-11 09:30:03 Message-feedback: Sending information (all feedback step)
2015-03-11 09:30:03 Message-feedback: Information sent (all feedback step)
2015-03-11 10:15:01 Message-update: Running reputation updater
2015-03-11 10:15:02 Message-update: Updating database from server
2015-03-11 10:15:02 Message-update: Reputation updated
Otra fuente que vamos a usar es spamhaus. Mediante el sencillo comando
host ip.zen.spamjaus.org podemos consultar si está incluido o no. Lo implementaremos en un script por cada ip que introduzcamos en la bbdd, añadiendo este dato a una "columna" de la ip del tipo "INCLUIDO SPAMHAUS". Lo veremos en otro capítulo.
Tenemos que tener en cuenta que vamos a crear una base de datos de conocimiento. Las acciones posteriores que configuramos en nuestros sistemas de seguridad las tenemos que definir según nuestro criterio. Por ejemplo, puede que no bloqueemos una dirección IP que ha intentado hacer un Connect a un puerto de un Honeypot... sería como un port scan o similar y no daríamos a basto en bloquear las ip´s. Pero sin embargo, si esa misma IP está reportada en
OTX o SPAMHAUS quizás si podríamos configurarlo como una amenaza real y realizar acciones defensivas.
Podemos usar este conocimiento para otros sistemas como la detección/prevención de intrusos. Podemos consultar esta lista con Mod_Security o Snort para añadir mas profundidad a los bloqueos, no solo la IP sino el patrón de ataque.
EL TIPICO DATO-INFORMACION-CONOCIMIENTO-INTELIGENCIA.
El
dato serían los logs de firewalls, ids, waf, av, siem, etc. Por ejemplo: ssh connect a un honeypot.
La
información sería la clasificación y métrica de los eventos que han producido el dato. Por ejemplo: clasificación como riesgo bajo.
El
conocimiento sería peligrosidad de esa información. Por ejemplo, si tengo varios eventos de ese tipo, pero desde una ip en un país que no es "a priori" atacante, o que es España y lo considero un posible escanneo dirigido.
La
inteligencia sería ACTUAR con ese conocimiento. Por ejemplo, baneando esa ip y registran un log que a su vez me genere datos con información, para llegar al conocimiento que esa ip lleva 6 meses intentando conectarse.
La cuestión sobre todo esto es definir donde se va a realizar la gestión del conocimiento. Para eso está el SIEM y por eso se toma como fuente base de recolección. Aunque obtendremos información de otros servicios de seguridad, como pueda ser Fail2Ban, que por cualquier motivo no hemos integrado en el SIEM. Suele ser por pereza para escribir las regular expressions para los logs :-)
Vamos a empezar con lo más fácil. Cargar nuestros eventos del SIEM Ossim en una tabla de nuestra base de datos IP REPUTATION. Para ello utilizaremos una acción para cada evento, que ejecutará un script de inserción.
Si tienes dudas en como crear políticas puedes consultar
este artículo.
No te voy a dar la tabla de destino xD ni el script que hace el insert into, solo difundo mis ideas xD.
En algún momento del proyecto vamos a necesitar de un lenguaje de programación algo más "versátil" que bash script. Por ejemplo, para ejecutar procedimientos almacenados en Mysql que requieren de un "output". Usaremos PHP ejecutado desde scripts bash para ir realizando nuestras "lógicas de negocio".
Un ejemplo de tablas que puedes crear son:
LOCATION: cargar la ip, pais, codigo pais, ciudad, latitud y longitud y timestamp. Con esta tabla desnormalizada podemos cargar todo lo relativo a geolocalización.
DATA: los datos que extraemos del script de inserción que ejecutamos con OSSIM. De momento solo vamos a introducir estos datos, en otros capítulos podemos agregar otras fuentes.
SENSOR: identificar que sensor ha generado el evento, como pueda Snort, Modsec, Ossec, etc.
CATEGORIAS: una manera de clasificar los eventos: portscan, exploit, malware, spam, bad traffic, tor traffic.
WHITELIST: una tabla para cargar aquellas ip´s que no queremos incluir NUNCA, como puedan ser algunas ip´s que usemos para test de intrusión internos.
OTX: Cargar la información de la base de datos de OTX en nuestro sistema nos ayudará en varios sentidos. El primero, que todos los datos de LOCATION nos los brinda, es decir, que cualquier evento que venga a nuestros sistemas, cuya ip exista en
OTX, nos ahorramos pasarle el script para geolocalizarlo.
Una de las cosas que debes valorar es que si tienes muchas inserciones por segundo, mucha actividad maliciosa a registrar, puede que necesites un almacenamiento para Mysql del tipo MyIsam y no Innodb que suele ser más lento para la escritura. El problema de este almacenamiento es que MyIsam no trabaja con FK, por lo que toda la lógica de integridad referencial la tendrás que mantener con tu código php.
Por poner un ejemplo, gestionar que una ip está incluida ya o no en la IP REPUTATION. O si por lo contrario vas a usar como pk el binomio IP-Tipo de ataque. Si una IP se elimina de la base de datos al pasar una semana, su registro asociado en LOCATION debería desaparecer solo no? para qué guardar información de IP´s que no están en tu registro...
Vas a tener un hitcount para saber si una ip maliciosa es "novata" o lleva ya algunos intentos? Puede que para sistemas en producción que paramos los ataques y baneamos, no va a aumentar el hitcount, pero si en un Honeypot...
Creo que con estos datos ya puedes empezar a pensar en montarte tu sistema de reputación ip propio.
Estoy preparando otra serie de artículos sobre el despliegue automático de honeypots de manera seria, con sus medidas de seguridad. En algún punto conectaré las dos series de artículos.
La idea del proyecto global que estoy montando es:
Tener un OVF con todas las máquinas y configuraciones necesarias para instalar un sistema completo Honeypot seguro en un VPS, y con esa información alimentar la base de datos de reputación IP.
Espero que os guste la serie. Gracias por leerme.