sábado, 8 de mayo de 2010

Creacion de un plugin para OSSIM.

Creacion de un plugin para OSSIM.


En esta entrega revisaremos de forma rápida el método para agregar un nuevo plugin de detección a OSSIM. Básicamente, un plugin de OSSIM es un archivo en el cual se define una regla de selección con expresiones regulares en Python, para determinar el análisis de un log o registro que aún no exista para la plataforma. Siendo estrictos, cualquier registro de tipo estándar (syslog y similares) podría ser agregado como un nuevo evento a OSSIM, programando correctamente el plugin.

Antes que nada, debe explicarse un poco la estructura de identificación única de eventos en OSSIM con miras a la creación de un nuevo plugin. Cada plugin en OSSIM posee un identificador único llamado plugin_id (textualmente, es el nombre del campo en la base de datos) y a su vez los distintos eventos para cada plugin tienen su identificador llamado SID o plugin_sid (nombre del campo en la BD).
Así, y poniendo como ejemplo el plugin de SSH, podemos separar las características como:

Plugin ID (SSH) = 4003
Plugin SID para "SSH - Login Accepted" = 1 (y su plugin ID sera 4003)

Y así sucesivamente para todas las diferentes eventualidades que pudiera registrar SSH.
Entonces, a la hora de programar un plugin para OSSIM deben tenerse en cuenta dos archivos a editar; el primero será el plugin como tal (config. y expresión regular). El segundo será la información de la base de datos para la inserción del plugin en la plataforma OSSIM.
En cuanto a las expresiones regulares, tomaremos principalmente en cuenta los siguientes campos:

+ Repetición de una o más veces en un caracter
? Repetición única de un caracter o tipo
* Concuerda con cualquier caracter.
{x,y} Delimitador de repetición, mín. x, máx. y
\d Concuerda con dígitos numéricos
\s Concuerda con caracteres de espaciado.
\w Concuerda con caracteres de tipo word.
| Delimitador lógico de operación OR
. Concuerda con cualquier caracter por una vez.
\S Delimitador de negación de \s
$ Concuerda con caracter de final de línea
^ Concuerda con caracter de inicio de línea
() Delimitador de referencia a identificador.

NOTA: OSSIM posee algunos tipos predefinidos para las expresiones regulares, los cuales no usaremos en este corto tutorial.

Como ejemplo, revisaremos y programaremos un plugin para SSH.

Primero que todo, poseemos el siguiente registro que define un acceso fallido por SSH.

Nov 5 12:29:39 sshserver sshd[18186]: Failed password for admin from 172.16.15.18 port 24375 ssh2

Debemos programar una expresión que concuerde con el anterior registro. Una expresión regular para el anterior log sería

\S+\s+\d+\s+\d+:\d+:\d+\s+\S+\s+\S+\s+Failed\s+password\s+for\s+\S+\s+from\s+\d+\.\d+\.\d+\.\d+\s+port\d+\s+ssh2

Sin embargo, no es suficiente que la expresión simplemente concuerde, también debemos definir cual
es la información que se quiere obtener del evento presentado. Así, quizá nos interese saber la fecha y hora del evento, el equipo generador de la eventualidad y el nombre o dirección del servidor "atacado". Nuestra expresión regular no ha de cambiar, solamente se deberán agregar referenciadores con () en los campos que se desean rescatar.

(\S+\s+\d+\s+\d+:\d+:\d+)\s+(\S+)\s+\S+\s+Failed\s+password\s+for\s+(\S+)\s+from\s+(\d+\.\d+\.\d+\.\d+)\s+port(\d+)\s+ssh2

Estos referenciadores se leen de izquierda a derecha, por tanto la fecha sería el 1, el servidor el 2, el usuario el 3 y la IP de origen el 4.
En este momento debemos establecer el archivo .cfg para el plugin, que contiene la información de la expresión regular. En este caso se llamará SSH-proof.cfg El archivo deberá quedar de la siguiente forma:

;; ssh
;; plugin_id: 4003
;; type: detector
;; description: Ssh (Secure Shell) is a program for logging into a remote machine
;; and for executing commands on a remote machine.
;; URL: http://www.openssh.com
;;
;; $Id: ssh.cfg,v 1.12 2010/03/23 16:42:18 juanmals Exp $
#La parte de arriba es la información de autoría, en este caso textualmente copiada del plugin #SSH para OSSIM.

[DEFAULT]
plugin_id=4003 #ID asignado al plugin.

# default values for dst_ip and dst_port
# they can be overwritten in each rule
dst_ip=\_CFG(plugin-defaults,sensor)
dst_port=22

[config]
type=detector
enable=yes

source=log #Tipo de fuente, para SSH es log.
location=/var/log/auth.log

# create log file if it does not exists,
# otherwise stop processing this plugin
create_file=false

process=sshd
start=no
stop=no
startup=/etc/init.d/ssh start
shutdown=/etc/init.d/ssh stop


## rules

##
## Failed login attempts
##

[ssh - Failed password]
# Feb 8 10:09:06 golgotha sshd[24472]: Failed password for dgil from 192.168.6.69 port 33992 ssh2
event_type=event
regexp="
(\S+\s+\d+\s+\d+:\d+:\d+)\s+(\S+)\s+\S+\s+Failed\s+password\s+for\s+(\S+)\s+from\s+(\d+\.\d+\.\d+\.\d+)\s+port(\d+)\s+ssh2
"
plugin_sid=1
sensor={resolv($2)}
date={normalize_date($1)}
src_ip={$4}
dst_ip={resolv($2)}
username={$3}

Y este archivo deberá ser guardado en un directorio apropiado (en general /etc/ossim/agent/plugins) y ser referenciado en los statements de configuración en /etc/ossim/agent/config.cfg
De otra parte es necesario que los eventos capturados por el agente OSSIM con nuestro nuevo plugin sean reportados correctamente en la consola. Con este propósito debe programarse el fichero SQL para insertar el nuevo evento en la base de datos de OSSIM. Este tipo de ficheros se encuentran típicamente en /usr/share/ossim-mysql/contrib/plugins/. El fichero de nuestro flamante Uni-plugin de SSH se vería entonces de la siguiente forma:

-- SSHd
-- plugin_id: 4003

DELETE FROM plugin WHERE id = "4003";
DELETE FROM plugin_sid where plugin_id = "4003";


INSERT INTO plugin (id, type, name, description) VALUES (4003, 1, 'sshd', 'SSHd: Secure Shell daemon proof here!');

INSERT INTO plugin_sid (plugin_id, sid, category_id, class_id, name, priority, reliability) VALUES (4003, 1, NULL, NULL, 'SSHd: Failed password proof here!', 3, 2);

Una vez con estos dos archivos preparados, se inserta el SQL en la base de datos y se reinician los servicios de OSSIM (agente y servidor). Tendremos entonces un nuevo plugin en nuestra plataforma OSSIM.
Próximamente analizaremos el método para programar un plugin indirecto a través de OSSEC.

La importancia del RRD Round Robin Database.

Como parte de una serie de documentos que empezaremos a publicar y que tienen como finalidad explicar los diferentes modulos y herramientas asociadas con OSSIm, resaltamos esta vez la importancia que tienen las herramientas de RRDtools, para ello me he remitido a documentos externos de la web, publicados esta vez de brigomp.blogspot.com quien hace un importante aporte sobre la expicacion del tema:

Round Robin Databases


El año pasado por un requerimiento del trabajo me encontré on una herramienta que nunca había visto antes. Se trata de RRDTool. En su momento iba a postear sobre ello pero me imaginé que era algo bastante conocido ya que parece que mucha gente de sistemas está familiarizada con este tipo de herramientas. Hace unos días me encontré con un requisito que se ajustaba a este tipo de soluciones y la gente tampoco conocía el concepto por detrás de RRDTool, así que supongo que no está de más guardar el conocimiento por aquí.

RRDTool es una herramienta construida sobre el concepto de Round-Robin Database. Se trata de un tipo muy específico de base de datos, orientadas al almacenamiento de datos basados en series temporales, y que garantizan el espacio final ocupado por sus elementos.

RRDTool es muy sencillo de utilizar, y probablemente con un ejemplo se entienda mejor como funciona. Imaginaros un sistema de análisis bursátil. Cada día, una cotización puede variar de valor unas cuantas veces por segundo. Imaginémonos que varía 3 veces por segundo. Esto significa que en un día, asumiendo un intervalo de trading de ocho horas, se tienen 8*60*60*3 = 86400 valores por día. Si asumimos por ejemplo 100 valores a seguir, tendríamos 8640000 cotizaciones al día, lo que son casi 10 millones. En una semana (de 5 días), andaríamos cerca de los 40 millones de valores, y en un mes laboral rondaríamos los 200 millones.

Ahora bien, ¿a quién le interesa el valor que tenía la acción de Endesa en el segundo 20, del minuto 35, a las cuatro de la tarde del 21 de Enero del 2008? Respuesta simple: a nadie. Comúnmente la granularidad fina en los datos temporales es sólo interesante en una ventana corta de tiempo. Por ejemplo en un sistema de seguimiento de transacciones, interesa saber que ha fallado una transacción en las pocas horas, pero pasados los meses la información de exáctamente cuándo deja de perder importancia (sigue teniendo importancia el saber que hubo un fallo, pero ya no importa si en lugar de minutos nos quedamos con el día).

Lo que hace RRDTool es agrupar la información conforme a intervalos de tiempo que nosotros definimos. Por ejemplo, le podemos decir que queremos que guarde los datos con una granularidad de 1 segundo para la primera hora, con granularidad de 5 minutos, para las siguientes 23 horas, con granularidad de 30 minutos para 1 semana, 1 hora para los tres primeros meses, y 1 día para los últimos 9 meses del año. Al introducir datos en RRDTool, la herramienta se encarga de realizar las agruaciones y las medias conforme a los intervalos que hemos definido.

Seguramente, incluso los que no habíais oído hablar del concepto de Round-Robin Database ya os habríais encontrado con estos sistemas hace tiempo. En la página web de RRDTool tienen una amplia galería de ejemplos, pero si vais por ejemplo a Yahoo Finance (por poner un ejemplo) veréis como para mostrar las gráficas, la granularidad de los valores de una acción dependen del tipo de intervalo que escogéis: 1 minuto para el día, 5 minutos para 5 días, 1 día para el intervalor de 1 mes, etc. Se trata de economizar información.

En su web tienen bindings para lenguajes como Python y Ruby. Para los javeros, existe una implementación 100% Java de RRDTool: rrd4j que yo he probado y funciona bastante bien.

Pues nada más por hoy. ¡Espero que esto le sea útil a alquien!

miércoles, 16 de diciembre de 2009

NO caiga en el robo informatico

Cuidado con el Phishing (en nuestro país la pesca milagrosa informática)

Aunque ya es muy conocido saber que es el Phishing así como nos familiarizamos con las palabras "Pesca milagrosa" en nuestro país, no esta por demás recordar que el Phishing se trata de la modalidad de fraude que pretende engañar a las personas, por lo general mediante un mail falso motivando a que visiten paginas falsas que usurpan las verdaderas como bancos o entidades que requieran una autorización de ingreso y resulten tentativas para que un maleante pueda realizar algún tipo de fraude. Parecería insólito el comportamiento humano de creer en el contenido de un mensaje sin observar primero su procedencia, (Principio de los Bulos o mail con falsas alarmas si lo prefieres en este blog lo llamo "Chisme informatico")ademas este tipo de paginas falsas por lo general con formularios similares a los que utilizan las entidades reales, te piden cambiar o actualizar los datos muy personales y confidenciales de tu cuenta(s) bancarias, sin recurrir al método mas apropiado y aconsejado por estos dias, que es visitar el sitio real de la entidad bancaria escribiendola la direccion en la barra del navegador, es decir “NO se Navegue por las ramas cuando de bancos se trata,,vaya directo al banco”, entonces por que? Tocar este tema ya tan “trillado”, bueno en realidad a mi aun me llena de asombro que hayan personas en este país del “sagrado corazón” es decir somos creyentes por idiosincrasia, que se metan en pirámides que los harán súper ricos y aviones que no vuelan, ¡ ah! y hablo de los que están en ellas actualmente no los que ya despertaron hace algunos meses, también están los que apuestan al señor de las uñas largas al juego “Donde esta la bolita con sus cinco acompañantes que no dejan ver” jajaj y esta si que me causa gracia y desconcierto. Gracia de ver los maleantes creyendo que hayan personas que les van a caer en ese timo tan conocido y desconcierto al ver que si les caen , parece como si disfrutáramos mas de aquellas cosas que nos dicen que NO hagamos, pues bueno me cansaría de citar ejemplos que me hicieron pensar entonces, ¿por que no lanzar una advertencia mas sobre el tema? a los que todavía alimentan este tipo de estafadores informáticos mediante el Phishing, dándoles todos sus datos bancarios para que le vacíen sus ahorros remotamente y sin tocarle un dedo a la victima. No lo hagan mas por favor regálenlo al pastor o sacerdote de la iglesia, a los niños pobres, enfermos etc, o mejor dónelo a este tipo de Blogs para continuar publicando anuncios como este, si, humildemente se les reciben esos ahorros si no los necesitan.
No me hubiera sentido tan atraído o más bien comprometido a escribir este artículo, si no fuera testigo de los ya innumerables casos que se están presentando en especial en épocas de fin de año en esta región, de verdad es asombrosa la cantidad de mensajes que se han disparado en esta ocasión por esta fecha para tratar de tomar nuevas victimas, hasta he decidido enviar un mail masivo anunciando a las personas que mas pude de este peligro que se aumento desmedidamente en las ultimas semanas, claro que corro el riesgo de parecer que estuviera fomentando uno de esos molestos males del mundo el "Chisme informático" (BULO) y eso, por no hablar del mensaje tan grande que he puesto al fianl del mail que envie donde aclaro que “Por favor NO reenvíe este mensaje” y no me extrañaría que diera dos vueltas o mas al mundo y pronto se convirtiera en otra "Cadena de mail" Y no faltara quien le agregue las palabras típicas como “Si no lo reenvías te pasara algo terrible” porque aquí en este país también somos muy comunicativos; bueno claro que después de todo como dicen por alli cada que gana la selección…(((¡ por eso es que te quiero tanto carajo !)). Por ese talento creativo que nos sobra y muchas cosas mas, estoy seguro que si utilizáramos estas cualidades de comunicar rápidamente los peligros que nos acechan a los demás y creamos que somos capaces de cambiar para bien el mundo seguro estas amenazas no nos afectarían, ¡entonces! ¿ Por que no empezamos? Aquí esta mi aporte en el contenido de este articulo.
PD. Por favor NO recomiende este me articulo a nadie es un secreto, dígale que NO lo visite si es que se ve tentado, NO se lo envié a nadie por correo etc.


Rodrigo Bedoya
Consultor en Seguridad Informática.
www.soccolombia.com

viernes, 10 de julio de 2009

lunes, 22 de junio de 2009

Protegiéndonos de las soluciones de seguridad

"Acabo de recibir un mensaje de una gran consultora, de esas que hacen
estudios basándose en estadísticas tras recopilar la opinión de terceros
supuestamente expertos. Muy amables, solicitan corrija una errata en una
de las respuestas que rellené en su cuestionario. La pregunta pedía que,
según mi criterio, enumerara el top 10 de amenazas de seguridad a las
que se deberían enfrentar las empresas a corto y medio plazo. La
respuesta que suponen una errata es: las soluciones de seguridad.

Supongo que la mayoría estamos de acuerdo en que, en casos puntuales,
una solución de seguridad puede introducir nuevas amenazas, bien por
mal funcionamiento en sus funciones de protección, bien por nuevas
vulnerabilidades que se derivan del propio producto o servicio de
seguridad. No obstante, incluir esa remota y puntual posibilidad en un
top 10 de amenazas no es muy acertado. Así que entono el mea culpa por
una mala descripción de lo que quería decir (tampoco había mucho espacio
en el campo de texto libre del cuestionario), y les voy a enviar la
rectificación: marketing falso en soluciones de seguridad.

En su día me molestaba mucho leer el eslogan de "100% de protección
contra virus", una herencia de aquella molestia se puede encontrar aun
hoy día en el aviso que escribí hace 5 años en la web de VirusTotal: "No
existe solución en el mundo que pueda ofrecer un 100% de efectividad en
el reconocimiento de virus y malware en general. Si le ofrecen un
producto con el 100% de efectividad, está siendo víctima de publicidad
falsa.". Afortunadamente el marketing de los antivirus ha evolucionado
y ya nadie se atreve a decir nada parecido.

Sin embargo, en términos generales, el marketing en las soluciones de
seguridad sigue siendo poco honesto, tanto con el usuario final como con
el cliente corporativo. Un buen momento que tengo para afianzar esa
sensación es cuando presento los resultados de auditorías y test de
penetración a clientes corporativos. Es entonces cuando escucho frases
como: "pero el vendedor nos dijo que este sistema de prevención de
intrusiones evitaba cualquier tipo de inyección", "no puede ser, el
portátil tiene un sistema de cifrado y nos dijeron que era imposible
extraer ninguna información", etc.

Ya sabemos que cualquier solución de seguridad que nos ofrezcan, u
ofrezcamos, no es perfecta. Así que el vender las soluciones de
seguridad exagerando sus virtudes y omitiendo sus debilidades podría
entenderse como picaresca, parte del juego entre vendedor-comprador.
Pero los efectos en realidad son mucho más perniciosos que el del
anuncio del detergente que nos asegura que lava más blanco que ninguno,
porque puede llegar a crear una falsa sensación de seguridad en el
comprador y las consecuencias pueden ser desastrosas para la empresa.

No se trata simplemente de que el comprador haya adquirido una solución
que no es la mejor de su categoría, como ocurre en el caso del
detergente, sino que probablemente no le hayan explicado las
limitaciones de esa tecnología y de la que adolece cualquier otro
producto de la misma categoría. El resultado es que el comprador no
entenderá la necesidad de añadir capas adicionales de seguridad para
proteger sus activos, una verdad que en el mejor de los casos descubrirá
durante una auditoría o test de penetración, y en el peor de los
escenarios ya sería demasiado tarde.

Mi humilde consejo: cuando intenten venderle una tecnología o solución
de seguridad, desconfíe de cualquier presentación que no incluya
explícitamente una descripción de sus debilidades o limitaciones."

Bernardo Quintero

Fuente Original:
http://www.hispasec.com/unaaldia/3893/comentar

--
Crislato

sábado, 13 de junio de 2009

Saludos a Jenny Administradora!

Aprovecho este espacio para saludar a Jenny Bayona, quien ha tenido a bien interesarse por el proyecto SOC Colombia. En su blog

http://jennyadministradora.blogspot.com/2009/05/seguridad-informatica.html

comenta sobre "el reto al que se enfrentó el grupo de investigación I2T de la Universidad Icesi, en conjunto con la empresa TGR, y para lo cual desarrolló SOC Colombia, una herramienta basada en OSSIM".

Saludos a Jenny, agradeciendo su labor de difusión sobre OSSIM.

--
Crislato

Estudios académicos sobre la adaptación de OSSIM a entornos locales.

Hasta hace unos meses tuve la oportunidad de participar activamente en el proyecto "Adaptación y mejoras al motor de correlación y sistema de sensores remotos de OSSIM para un centro de operaciones de seguridad informática". Dicho proyecto tuvo diversas implicaciones y una nutrida producción documental, de la cual quiero compartir el artículo publicado en las memorias de EvencoCCC, un importante evento académico promovido en Colombia.
En dicho artículo, titulado "Implementación y mejora de la consola de seguridad informática OSSIM en el entorno colombiano" se expone de forma sencilla, breve y legible el esfuerzo conjunto del grupo de investigación i2T durante el proyecto. Textualmente, en el artículo se exponen "mejoras que incluyen la interconexión con dispositivos de
seguridad física, la creación automática de directivas de correlación para el motor de la herramienta y la mejora significativa de la confiabilidad de captura de información en redes con alto tráfico". Espero lo disfruten.

http://www.soccolombia.com/documentos/documento3.pdf

--
Crislato