jueves, 26 de marzo de 2015

OSSIM 23. Conectar un OSSIM sensor externo a nuestro servidor por VPN

Estimados amigos de Inseguros.

Después de iniciarnos en el mundo del SIEM con OSSIM (1234567 , 89 101112 1314.,15, 16 ,17 18, 19,20,21 22 )

Vamos a configurar una sencilla operación. Instalar un sensor OSSIM en un VPS externo a nuestra red, y conectarlo con nuestro actual despliegue de OSSIM de manera segura por VPN.

De esta manera podemos usar los plugins de los sistemas que tengamos en esa ubicación, y enviar los eventos al servidor central.

Tenemos que descargar una imagen ISO, que nos sirve tanto para instalar el servidor como el sensor. Si tu VPS no trabaja con virtualización, tu me contarás como vas a instalar la ISO :-). Una vez solventado este concepto, procedemos con las pantallas de instalación.


Una vez configurados los datos de red, hemos terminado !!

Ahora viene el proceso. El resumen es que en el servidor Ossim tenemos que acceder por ssh puerto 22 al sensor. En mi caso estaba en un vps, detrás de un firewall, por lo que he tenido que natear en el sensor el puerto 22. El servidor se conecta al sensor, configura el cliente vpn copiando la configuración en /etc/openvpn/ip.conf. El problema es que cuando Ossim copia los datos al cliente, en ese fichero .conf indica la dirección ip de OSSIM server, la interna, por lo que el cliente vpn del sensor intenta conectar a una ip privada... Yo he tenido que cambiar el fichero citado y poner la dirección ip publica de mi server OSSIM, y hacer un nat en el firewall hacia el puerto TCP 33800.

Vamos a ello !!!
En el servidor principal Ossim, en la consola de administración ejecutamos:

Esta es la red virtual del servidor vpn. el equpo será .1
Ahora seguimos desde el servidor OSSIM y configuramos el VPN client.

Esta ip es la local del sensor OSSIM
Ahora nos conectamos con el sensor Ossim que acabamos de instalar, y seleccionamos:


Esta IP es la del extremo virtual de la vpn del servidor OSSIM. Coincide con la red vpn que hemos configurado unos pasos atrás. Hacemos lo mismo con framework IP. Ahora aplicamos los cambios.


Por último, desde el gui de Ossim añadimos un sensor nuevo, bajo la rama despliegue, e indicamos los datos de ip, que será la interface de túnel del equipo sensor.


El resumen es:

SEDE PRINCIPAL:
ip publica--->fw/nat 33800-->ossim server.
SEDE REMOTA:
ip publica-->fw/nat 22 ->> ossim sensor.

EN OSSIM SERVER: configurar la opcion vpn server y cliente. ( por defecto 10.67.68)
EN OSSIM SENSOR: configurar las direcciones de server y framework con la ip del tunel. (por defecto 10.67.68.1)
Editar el fichero /etc/openvpn/ip.conf con la dirección ip pública del servidor OSSIM.
/etc/init.d/openvpn restart.
EN OSSIM SERVER GUI: añadir el sensor con la ip del túnel, del extremo del sensor. ( por defecto 10.67.68.12)

Como siempre espero que os sirva de ayuda, y gracias por leerme !!!





miércoles, 25 de marzo de 2015

Haz tu plan de seguridad casero a coste cero.

Estimados amigos de Inseguros.

Los amigos de Eset España me han permitido escribir un post sobre como empezar a realizar un plan de seguridad en nuestra empresa a coste cero. Será una serie de artículos destinados a los que se inician en el mundo de la seguridad. Espero que os guste !!!



http://blogs.protegerse.com/laboratorio/2015/03/25/guia-para-realizar-un-plan-de-seguridad-basico-a-precio-cero/


viernes, 20 de marzo de 2015

OpenDLP. Data Loss Prevention open source. Monitoriza las fugas de información.

Estimados amigos de Inseguros.

En el capítulo de hoy vamos a hablar de un concepto habitual en el mundo de la seguridad DLP Data Loss Prevention o prevención de fugas de información.

Si la información es el activo que queremos proteger en nuestras organizaciones, detectar fugas de información por procesos "normales" o "habituales" debería ser lo más básico.

Si nos protegemos de una Sql Inyection que nos pueda dumpear una base de datos.
Si nos protegemos de un XSS que nos puede dumpear la cookie de administrador de nuestro portal.
Si nos protegemos de RFI que nos puedan comprometer la consola de un servidor web.

Nos deberíamos proteger de estas mismas fugas de información por parte de los empleados? Por supuesto que si. Imagina los frentes. Dropbox, correo, pendrives, artículos en páginas fake, etc etc.


Por lo general ser suelen emplear herramientas comerciales. Por ejemplo, tengo bastante experiencia en DLP en sistemas Fortinet en los que mediante expresiones regulares inspeccionamos todo el tráfico de salida en busca de patrones de fuga de información. PERO imagina una alerta por cada XLS, DOC o similar que sale por nuestro smtp...



En este episodio vamos a hablar del proyecto OPENDLP creado por el señor Andrew Garvin.


La instalación podemos realizarla desde las fuentes o usar un fichero OVA para virtualbox. Yo me decido por usar este, y en otro momento lo pasaré a un VMWare o Hyper-v de producción. Para hacer las pruebas me vale.

La lista de dispositivos que escanea el agente OpenDLP son: floppy, thumb drive, flash card reader, HDD, flash drive, CD-ROM and RAM disk.

Una de las gestiones que tenemos que hacer al importar la máquina es deshabilitar el usb 2.0 y activar la tarjeta de red.

Una vez instalada la máquina lo primero que debemos hacer es borrar el fichero /etc/udev/rules.d/70-persistent-net.rules para que Ubuntu no compruebe la mac de la máquina clonada, que como ha cambiado, no detecta la interface por defecto. Seguro que el user/pass opendlp/opendlp ya se te había ocurrido cierto? :-)

Ahora accedemos por scp a la carpeta /var/www/OpenDLP/bin/ y copiamos en ella el fichero sc.exe de cualquier Windows XP que tengamos por casa.

El siguiente paso es importar el fichero de certificado que se extrae en la carpeta de instalación de la máquina virtual en Firefox, en mi caso. Simple.


Podemos acceder desde el navegador de tal manera: https://ip/OpenDLP/index.html
user:dlpuser.pass:OpenDLP

Este es el aspecto inicial.


Vamos a trastear un poco con las opciones del gui. Vamos a crear un perfil para nuestros equipos Windows en este caso. Hay que tener en cuenta la antigüedad del proyecto. En el profile cambia la ruta de instalación del agente, para que no use "program files" sino una directorio concreto. De esta manera nos ahorramos el problema de las versiones x86/64


Tras el nombre e indicar el tipo Windows based agent debemos configurar las expresiones regulares que queremos monitorizar. Vamos a activar las que trae por defecto, al menos, para detectar una fuga de información de una tarjeta VISA o MASTERCARD.

Mastercard:(\\D|^)5[1-5][0-9]{2}(\\ |\\-|)[0-9]{4}(\\ |\\-|)[0-9]{4}(\\ |\\-|)[0-9]{4}(\\D|$)
Visa:(\\D|^)4[0-9]{3}(\\ |\\-|)[0-9]{4}(\\ |\\-|)[0-9]{4}(\\ |\\-|)[0-9]{4}(\\D|$)

El usuario que debemos proporcionar al agente para subir los resultados al servidor es: ddt/OpenDLPagent

Ahora realizamos un scan para instalar el agente en las ip´s que le indiquemos.


Podemos usar la recolección de datos mediante tráfico SMB sin instalar agente. Es más si intentas instalar el agente en sistemas > xp tendrás problemas con el ntlmv2 ya que winexe no lo soporta, y los sistemas operativos "modernos" suelen tener por GPO que no hagan RESPONSE a ntlm <2.


Como es normal, una regular expression tan genérica como la de las tarjetas de crédito arroja muchos falsos positivos.

En otro capítulo seguiremos trabajando con OpenDLP contra sistemas linux y con otras expresiones regulares que nos proporcionen más información.

Espero que os guste, gracias por leerme !!!




lunes, 16 de marzo de 2015

Honeypot nuevo cada noche + sistema de control aislado de la red para analizar la información. HoneyDrive+Vmware+Powercli

Estimados amigos de inseguros.

Después de tantos artículos sobre el asunto de Honeypots, creo que podemos darle forma con un proyecto concreto basado en un despliegue sobre VMware, muy asequible como vps en cualquier operador, y un conjunto de máquinas y configuraciones dedicadas específicamente a mantener un Honeypot.

Uno de los retos con el Honeypot es mantener su integridad. Si creamos una estrategia para generar automaticamente una máquina virtual con el honeypot cada noche, nos aseguramos que en caso de compromiso, al menos, el atacante deberá realizar las mismas acciones cada día de explotación para tener acceso. No vamos a tener un Honeypot comprometido realizando el mal a sus anchas, y nosotros recolectando logs... Legalmente creo que seríamos los responsables de las acciones del criminal.


La idea general es tener en un host VMware, una máquina virtual firewall gratuita como pueda ser pfsense, o un cfs sobre iptables, un mikrotik virtual o similar. Esto nos permite dar visibilidad hacia la parte "interna" de nuestro sistema, las máquinas virtuales con los Honeypots y sobre todo, un sistema aislado y seguro para conectarnos hacia nuestro "Command & Control" y no tener que abrir una puerta conectando nuestros sistemas hacia un Honeypot, un sistema que a priori se despliega para que te "ciber-zurran" :-).

Basando nuestro Honeypot en la distro. Honeydrive versión actual .
El proceso de instalación sobre ESXi lo puedes leer aquí.

Aparte de cambiar el teclado a tu gusto, debes realizar el cambio de clave honeydrive por una que NO TENGA NADA QUE VER CON SISTEMAS que tengamos en producción. No uses ni la misma combinación, totalmente distinta. sudo passwd es más que suficiente.

Aparte de la máquina virtual instalada como Honeydrive, vamos a crear un disco duro secundario con VMware de 20 gb, que usaremos para montar/desmontar la información de los sistemas en el Honeypot y luego pasárselo a una máquina de confianza para recolectar la información.

Importante este punto. Para crear el disco duro que pueda ser accesible por distintas máquinas tenemos que hacer una configuración un tanto distinta de como estamos acostumbrados.

Para empezar, debemos acceder al ESXi por ssh y desde el directorio del volumen donde reside nuestra máquina, crear un disco eagerzerothick con este comando:

vmkfstools -d eagerzeroedthick -c 20G -a lsilogic intercambio.vmdk
desde la ruta: /vmfs/volumes/

Una vez creado el disco, lo agregamos a la máquina virtual como siempre.

Ahora cambiamos la configuración del adaptador SCSI para que sea Virtual, y así poder acceder desde varias máquinas virtuales en el mismo host.



Podemos montar el disco, según si has particionado ya algo, con los pasos en este enlace. Recuerda que crear la partición solo lo realizarás la primera vez, en las operaciones diarias solo realizaremos la parte de montaje/desmontaje entre las distintas máquinas virtuales.

No olvides modificar tu /etc/fstab en ambas máquinas para que se monte el disco al inicio.

Un dato importante, no podrás tener las dos máquinas instaladas corriendo debido al disco, la VM activa bloquea el disco.

Esto implicaría coordinar con el proceso de restauración del Honeypot mediante Powercli, el encendido de la máquina control y posterior envio de información. Esta tarea la realizaremos con el script modificado al final del artículo en Powershell, asociado a una tarea programada.

Ya tenemos el Honeypot y un disco duro para logs, vamos a montar algún servicio honey y a cambiar la configuración para que escriba en el disco.

Antes de nada, me gusta iniciar tcpdump al arrancar la máquina virtual, filtrando solo los puertos que ofrecemos como Honeypot. De esta manera, podemos tener un pcap diario de la actividad contra al servicio Honey. Si enfocamos la captura a solo unos puertos puede que perdamos el sentido del Honeypot si lo que queremos es encontrar patrones de actividad basados en el acceso a distintos puertos, por ejemplo, si estamos detectando un bot que explota algún port knocking por defecto. Para el caso de obtener estadísticas, ip reputation, y algunos comando o la descarga de malware, me basta con hacer el tcpdump normal.

Podría valer este: =tcpdump -i eth0  -n dst port 22 or 24 -w /media/disk1/pcap.pcap

Empezamos con el famoso Kippo, que ya vimos alguna configuración por aquí.

Lo que voy a hacer es copiar todos los logs que genera, incluido la bbdd Kippo para verlo luego en Kippo-Graph, con un cron programado 10 minutos antes de apagar la máquina.

Qué cosas voy a copiar en ese disco duro? que datos voy a necesitar para visualizar en mis sistemas?
Para el ejemplo de Kippo y Kippo-graph podemos copiar:

#! /bin/bash
clave=cacadevaca
vacio=`ls -l /honeydrive/kippo/dl | grep -v total | wc -l`
now=$(date +"%m_%d_%y")
if [ ! -d /media/disk1/log-kippo/$now ]
then
mkdir /media/disk1/log-kippo/$now
fi
cp /honeydrive/kippo/log/kippo.log* /media/disk1/log-kippo/$now
if [ $vacio != 0 ]
then
cp /honeydrive/kippo/dl/* /media/disk1/log-kippo/$now
fi
if [ -f /media/disk1/pcap.pcap ]
then
cp /media/disk1/pcap.pcap /media/disk1/log-kippo/$now/pcap.pcap
fi
rm -f /media/disk1/pcap.pcap
rm -f /honeydrive/kippo/dl/*
cat /dev/null > /honeydrive/kippo/log/kippo.log
mysql -u root --password=$clave kippo -e "select * from auth" -B > /media/disk1/log-kippo/$now/auth.csv
mysql -u root --password=$clave kippo -e "select * from clients" -B > /media/disk1/log-kippo/$now/clients.csv
mysql -u root --password=$clave kippo -e "select * from downloads" -B > /media/disk1/log-kippo/$now/downloads.csv
mysql -u root --password=$clave kippo -e "select * from input" -B > /media/disk1/log-kippo/$now/input.csv
mysql -u root --password=$clave kippo -e "select * from sensors" -B > /media/disk1/log-kippo/$now/sensors.csv
mysql -u root --password=$clave kippo -e "select * from sessions" -B > /media/disk1/log-kippo/$now/sessions.csv
mysql -u root --password=$clave kippo -e "select * from ttylog" -B > /media/disk1/log-kippo/$now/tty.csv


Ten en cuenta en cambiar el path donde has montado tu disco duro de intercambio.

Preparamos un cron para que a las 23:45 realice la copia, ya que vamos a programar que a las 24:00 la máquina Honeypot se apague, se borre, se regenere desde una plantilla y se inicie.

Ahora es el turno de montar un sistema de control. Una máquina aislada del Honeypot, en la que solo se permita el acceso por ssh desde lo que denominaría la sede. En esta máquina vamos a montar el disco duro en el que se guarda toda la información del Honeypot, para poder extraer la información. De esta manera, el honeypot NUNCA tendrá una conexión hacia ningún sistema de producción, el intercambio lo haremos montando el disco duro de datos en otra máquina que si tiene acceso al sistema de producción. Esta máquina debe estar muy capada.

Cualquier máquina linux que montes es buena. El asunto ahora es agregarle en Vmware un segundo disco, que será el mismo segundo disco que hemos montado en la máquina Honeypot, osea, el de intercambio...

Comprobamos que accedemos al disco duro de intercambio.

Ahora es el turno de coordinar el tiempo entre que el Honeypot está apagado, arrancamos la máquina de control, realizamos el volcado de información hacia nuestra sede, apagamos la máquina de control e iniciamos el Honeypot de nuevo. Aquí deberías tener un script al inicio para volcar la información. Omito de momento esta parte ya que mi destino, de momento, será la propia máquina Honeypot control.

Recuerda este artículo para automatizar la tarea.

El final del script es este:

Connect-VIServer -Server ip-server-esxi -User usuario -Password contraseña
Stop-VM -VM "nombre de la clonada" -Kill -Confirm:$false
Remove-VM "nombre de la clonada" -DeletePermanently -Confirm:$false
Clone-MasterVM -MasterName "nombre de la original"  -CloneName "nombre de la clonada" -DatastoreName "nombre del datastore" -Register -PowerON

Vamos a realizar una modificación. Trás apagar la máquina virtual Honeypot, vamos a añadir:

Connect-VIServer -Server ip-server-esxi -User usuario -Password contraseña
*conexión al vmware
Stop-VM -VM "nombre de la clonada" -Kill -Confirm:$false
*parar el honeypot
Start-Sleep -s 60
*espera 1 minuto a que se apague.
Remove-VM "nombre de la clonada" -DeletePermanently -Confirm:$false
*borra la máquina honeypot
Start-VM -VM control-honeypot
*arranco la máquina de control
Start-Sleep -s 300
*espero 5 minutos para que arranque y ejecute un script de inicio volcando información.
Stop-VM -VM "control-honeypot" -Kill -Confirm:$false
*apago la máquina de control.
Clone-MasterVM -MasterName "nombre de la original"  -CloneName "nombre de la clonada" -DatastoreName "nombre del datastore" -Register -PowerON
*clono el honeypot plantilla a una máquina nueva y la inicio.

De momento el esquema es:

EQUIPO VMWARE ESXi.
-Máquina firewall para natear la IP pública con las máquinas virtuales y el propio Vsphere client.
 - Ip pública al firewall.
 - Nateos al puerto ssh y vsphere client al host Vmware. Ip privada el host.
 - Nateos al puerto del Honyepot configurado.
 - Nateo a vlan distinta para la máquina de control. Todos puertos cerrados salvo ssh filtrado a sede.
-Máquina Honeypot Honeydrive.
-Máquina Debian para recibir la información.
*Disco duro compartido entre la máquina Honeypot y Control.
*script modificado del artículo anterior con este.

Tenemos un Honeypot con kippo que se regenera todas las noches y guarda la información en un disco duro compartido con otra máquina virtual, que será la que usemos para trabajar la información. Digamos que es la parte de infraestructura.

En el próximo capítulo de la serie completaremos el script Powershell con las típicas mejoras que habrás podido observar, y realizaremos algún trabajo con la clasificación de los logs que nos ha generado Kippo. Tambien pasaremos por snort y similares el fichero pcap de captura.

Espero que os guste el artículo, gracias por leerme !!!

















IP REPUTATION Collective Intelligence Framework. Parte 2.

Estimados amigos de Inseguros !!!

Vamos a seguir madurando el concepto de IP REPUTATION que comenzamos en el pasado artículo.


En esta ocasión, vamos a preparar el framework de trabajo para obtener la información de seguridad de eventos no solo para nuestro sistema OSSIM como vimos, sino para otras fuentes públicas.

Vamos a usar el proyecto CIF Collective Intelligence Framework elaborado por REN-ISAC que me recomendó el profesor Jose Luis Chica. Gracias !!!

El proyecto implementa el formato IODEF  Incident Object Description Exchange Format . Volvemos a las épocas de los RFC´s :-)


Se puede observar que en la descripción del proyecto no aparece esta información, ya que la definición del formato IODEF se contempla como formato de transporte, y no de almacenamiento de larga duración, por lo que CIF implementa una definición de IODEF adaptada a un almacenamiento en formato JSON no en XML con en origen indica el RFC. El resultado es una tabla con una sola columna de texto. Se crean índices con la extracción de los metadatos, y al parecer, la velocidad es superior que en un planteamiento clásico de estructura SQL normalizada, con mil millones de tablas y campos.

Una imagen vale más que mil palabras. 


A diferencia de un SIEM, con CIF podemos no solo recolectar información, sino que podemos generar el output que necesitamos para incorporar en nuestros sistemas de prevención. Podemos generar la alerta para que nuestro Snort o Bro PAREN el ataque. Podemos cargar la información en IPTABLES, etc. Con OSSIM por ejemplo tendrías que hacer lo que comentamos en el anterior post, crearte un script que ejecute una inserción de la ip del evento en tu sistema. 
La lista de Outputs que genera CIF es: Bind Zone config, BRO, CSV, HTML,  IPTABLES, JSON, PCAPFILTER , SNORT, TABLE

La comodidad de usar una API nos permite usar la parte del proyecto que nos interese, consultando o exportando información de una manera controlada.

Podemos crear una estructura federada para compartir información entre varios CIF. El objetivo primordial de un proyecto como este, desarrollado para dar cobertura a los CERT´s, es el de compartir la información de amenazas.



  
El otro punto es que se integra con numerosas fuentes de información públicas o FEEDS. Como puedan ser:*algunas no funcionan bien, o bien ya no existen publicamente*

http://honeytarg.cert.br/honeypots/
http://exposure.iseclab.org/
http://arakis.pl/en/index.html
http://www.spamcop.net/
http://honeytarg.cert.br/spampots/
http://zeltser.com/combating-malicious-software/malicious-ip-blocklists.html
http://contagiodump.blogspot.com/2010/11/links-and-resources-for-malware-samples.html
http://urlquery.net/index.php
http://www3.malekal.com/malwares/
http://jsunpack.jeek.org/dec/go?list=1
http://vxvault.siri-urz.net/ViriList.php
http://minotauranalysis.com/malwarelist.aspx -- overlaps malc0de and cleanmx
http://rss.uribl.com/nic/NAUNET_REG_RIPN.xml
http://www.malwareblacklist.com/showMDL.php
http://abusix.org/service/spamfeeds
http://atlas.arbor.net/summary/fastflux?out=xml
http://dshield.org/diary.html?storyid=12373
https://reputation.alienvault.com/reputation.data
http://security-research.dyndns.org/pub/malware-feeds/ponmocup-botnet-domains.txt
http://security-research.dyndns.org/pub/malware-feeds/ponmocup-botnet-ips.txt
http://security-research.dyndns.org/pub/malware-feeds/ponmocup-malware-domains.txt
http://security-research.dyndns.org/pub/malware-feeds/ponmocup-malware-ips.txt
http://malwareint.com
http://www.senderbase.org/home/detail_virus_source
http://callbackdomains.wordpress.com
http://labs.snort.org/iplists/
http://www.enisa.europa.eu/activities/cert/support/proactive-detection/proactive-detection-report
http://rules.emergingthreats.net/open/suricata/rules/compromised-ips.txt
http://rules.emergingthreats.net/open/suricata/rules/botcc.rules
http://rules.emergingthreats.net/open/suricata/rules/rbn-ips.txt
https://www.projecthoneypot.org/list_of_ips.php
http://rules.emergingthreats.net/open/suricata/rules/tor.rules
http://rules.emergingthreats.net/open/suricata/rules/compromised.rules
http://www.malwaredomainlist.com/hostslist/ip.txt
http://rules.emergingthreats.net/open/suricata/rules/rbn.rules
http://www.mtc.sri.com/live_data/attackers/
http://intel.martincyber.com/ip/
https://reputation.alienvault.com/reputation.generic
https://www.openbl.org/lists/base.txt
http://www.blocklist.de/lists/ssh.txt
https://palevotracker.abuse.ch/
http://www.malwaregroup.com/ipaddresses
http://www.ciarmy.com/list/ci-badguys.txt
http://www.malware.com.br/cgi/submit?action=list
http://www.autoshun.org/files/shunlist.html
abusechweb http://dnsbl.abuse.ch/webabusetracker.php
arbor http://atlas-public.ec2.arbor.net/public/ssh_attackers
autoshun http://www.autoshun.org/files/shunlist.csv
badguys http://www.t-arend.de/linux/badguys.txt
blacklisted http://www.infiltrated.net/blacklisted
brawg http://www.brawg.com/hosts.deny
cleanmxv http://support.clean-mx.de/clean-mx/xmlviruses?response=alive&format=csv&fields=url,ip,domain&domain=
cleanmxp http://support.clean-mx.de/clean-mx/xmlphishing?response=alive&format=csv&fields=url,ip,domain&domain=
danger http://danger.rulez.sk/projects/bruteforceblocker/blist.php
denyhost http://stats.denyhosts.net/stats.html
dshield http://www.dshield.org/ipsascii.html?limit=5000
dynastop http://dynastop.tanaya.net/DynaStop.BleedingThreats.conf
emergingthreats http://www.emergingthreats.net/rules/bleeding-compromised.rules
evilssh http://vmx.yourcmc.ru/BAD_HOSTS.IP4
geopsy http://www.geopsy.org/blacklist.html
haleys http://charles.the-haleys.org/ssh_dico_attack_hdeny_format.php/hostsdeny.txt
kidsclinic http://www.kids-clinic.jp/uni/ipaddress/new_log
kolatzek http://robert.kolatzek.org/possible_botnet_ips.txt
malekal http://www3.malekal.com/exploit.txt
maldom http://mirror1.malwaredomains.com/files/domains.txt
mdl http://www.malwaredomainlist.com/mdl.php?colsearch=All&quantity=All&search=
prometheus http://downloads.prometheus-group.com/delayed/rules/modsec/domain-blacklist.txt
skygeo http://sky.geocities.jp/ro_hp_add/ro_hp_add_hosts.txt
sshbl http://www.sshbl.org/list.txt
stopforumspam http://www.stopforumspam.com/downloads/bannedips.csv
surriel rsync://psbl-mirror.surriel.com/psbl/psbl.txt

Imagina parsear todas estas fuentes a mano :-)

Existe otro proyecto parecido. AbuseHelper pero no he podido investigar mucho, y por lo que veo, está poco actualizado
La instalación realizada sobre Debian Wheezy requiere de las siguientes dependencias y paquetes:

sudo aptitude -y install rng-tools postgresql apache2 apache2-threaded-dev gcc g++ make libexpat1-dev libapache2-mod-perl2 libclass-dbi-perl libdigest-sha-perl libnet-cidr-perl libossp-uuid-perl libxml-libxml-perl libxml2-dev libmodule-install-perl libapache2-request-perl libdbd-pg-perl bind9 libregexp-common-perl libxml-rss-perl libapache2-mod-gnutls libapreq2-dev rsync libunicode-string-perl libconfig-simple-perl libmime-lite-perl libfile-type-perl libtext-csv-perl libio-socket-inet6-perl libapr1-dbg libhtml-table-perl libdate-manip-perl libtry-tiny-perl libclass-accessor-perl pkg-config libnet-ssleay-perl vim libjson-xs-perl libextutils-parsexs-perl libdatetime-format-dateparse-perl libnet-patricia-perl libdatetime-perl libtext-table-perl libcpan-meta-perl libmodule-build-perl

Si usas otra distribución puedes consultar la dependencias:
El siguiente paso es instalar zeromq, paquete necesario para la gestión de colas de mensajes entre componentes y algunos componentes más que requieren instalación por fuente.

$ wget http://download.zeromq.org/zeromq-2.2.0.tar.gz
$ tar -zxvf zeromq-2.2.0.tar.gz
$ cd zeromq-2.2.0
$ ./configure && make && sudo make install
$ sudo ldconfig

sudo PERL_MM_USE_DEFAULT=1 perl -MCPAN -e 'install Test::SharedFork,Test::TCP,Net::Abuse::Utils,Regexp::Common::net::CIDR,LWP::Protocol::https,Google::ProtocolBuffers,Iodef::Pb::Simple,Compress::Snappy,Snort::Rule,Time::HiRes,Net::Abuse::Utils::Spamhaus,Net::SSLeay,Net::DNS::Match,Log::Dispatch,Sys::MemInfo,LWPx::ParanoidAgent,ZeroMQ,Net::Whois::IP,Net::DNS,Email::Address'
 
$ wget http://search.cpan.org/CPAN/authors/id/J/JS/JSTOWE/Linux-Cpuinfo-1.7.tar.gz
$ tar -zxvf Linux-Cpuinfo-1.7.tar.gz
$ cd Linux-Cpuinfo-1.7
$ perl Makefile.PL && make && sudo make install
 
Ahora nos auto-baneamos de Internet durante un tiempo :-)

iface eth0 inet
        dns-nameservers 127.0.0.1
sudo vim /etc/resolv.confnameserver 127.0.0.1

Añadimos el usuario CIF:

sudo adduser --disabled-password --gecos '' cif

Configuramos algunos parámetros en Apache.

sudo a2ensite default-sslsudo a2enmod ssl perl apreq

sudo vi /etc/apache2/sites-available/default-ssl
<IfModule mod_ssl.c>

<VirtualHost _default_:443>
+      PerlRequire /opt/cif/bin/http_api.pl
+      Include /etc/apache2/cif.conf
....
 
sudo vi /etc/apache2/cif.conf
 
<Location /api>
    SetHandler perl-script
    PerlResponseHandler CIF::Router::HTTP
    PerlSetVar CIFRouterConfig "/home/cif/.cif"
</Location>
 
Por último configuramos rng-tools para generar numeros random.

echo 'HRNGDEVICE=/dev/urandom' | sudo tee -a /etc/default/rng-tools

Configuramos BIND y Postgres con las instrucciones que nos proporciona la documentación oficial.Si tienes problemas al reiniciar Bind puedes comprobar el fallo ejecutando: named-checkconf

Ahora instalamos el framework CIF.

Paramos Apache
$ tar -xzvf cif-v1-1.X.X.tar.gz
$ cd cif-v1-1.X.X
$ ./configure && make testdeps
$ sudo make install
$ sudo make initdb 

El proceso de configuración es muy sencillo y está bien documentado aquí.

Este proceso tarda bastante, quizás horas.


Una vez terminado el proceso de instalación, configurada la rotación de logs y creados los cron para ejecutar las actualizaciones, es turno de probar la herramienta.

Para poder consultar la información tenemos varios métodos, un cliente instalado, un plugin para los navegadores Firefox y Chrome y la API.

Vamos a instalar el complemento en Chrome tal como lo índica el manual. Descargamos el plugin. Y configuramos:



Configuramos la dirección del servidor, la API key de cliente y probamos conexión.



Con esto ya podemos consultar nuestro servidor CIF desde Chrome. Vamos a hacer una prueba. Podemos hacer click sobre el icono de CIF en la parte superior derecha, o directamente sobre un dominio, correo, IP o similar, seleccionarlo y botón derecho.




Ya tenemos instalado CIF server para recolectar inteligencia de distintas fuentes de información mas  o menos públicas. Podemos consultar manualmente esta información con el Plugin para Chrome. 

En los próximos episodios seguiremos trabajando con la idea de integrar en un única base de datos, nuestras IP´s, cotejando la información con estas fuentes, y creando una base de datos sólida.

Espero que os guste, gracias por leerme.
Related Posts Plugin for WordPress, Blogger...