martes, 22 de julio de 2014

La monitorizacion de eventos en Seguridad Informatica, el eslabon perdido entre las leyes actuales.

Muchas son las leyes que hoy tratan de establecer principios del uso de los recursos informáticos, mas aun son los regulaciones que emergen alrededor del tema como el mejor estándar de cumplimiento. sin embargo nos preocupa mas cumplir con lo que nos piden las regulaciones que por conocer la "verdad" en nuestro entorno informático, Sí, la "verdad" llámele "verdad virtual" o "ciber-verdad" en fin como cualquier otro modismo informático de los que atraen comentarios en las conversaciones de colegas del área informática, pero que al final no dicen mucho, espero que le sea claro para el lector de este articulo, que acabo de referirme a la "Ciber-Verdad" como algo propio de la imaginación que caracteriza este blog, para que no se tomen la molestia de buscarlo en google, pudo ser la Verdad-light, o con vitaminas etc, lo importante es que en esencia me refiero a olvidarnos de las mentiras en las que aveces nos encontramos con una "carita feliz" :) al lado de nuestro escritorio, recordándonos que hemos cumplido la misión interna de la norma de turno en un periodo, tal como ISO##, PCI, ITIL, etc. Pero entonces cual es la verdad? Si tu plataforma informática no tiene una visualizacion completa, precisa y confiable para saber en tiempo "casi" real, que te informe rápida y oportunamente que es lo que esta pasando en tu red o equipos informáticos, estas en una posición similar a la del guarda del edificio, que sin custodiar las puertas traseras del mismo se gana una remuneración extra por no haber ocurrido un robo en el ultimo mes, o el policía que recibe una mención de honor por bajar las estadísticas delictivas en su zona, pero no sabe si los delincuentes estuvieron o no presentes en la zona, lo cierto es que la VERDAD o mejor Ciber-Verdad (me agrado el termino), es que en cualquier momento les puede pasar algo nefasto y quizás le cambien las estadísticas y con ellas su prestigio, para cuando ello ocurra, para ellos sera un suceso sin explicación alguna, es allí donde algunos altos mandos de "buen corazón" los despiden, pero no sin antes preguntarse, ¿pero entonces en que fallaron si eran tan "buenos"?,, sí, fallaron, fallaron porque no conocían la !VERDAD!, "La verdad de lo que pasaba en su red informática", si hubieran tenido un centro de monitorización implementado al alcance de sus responsabilidades, que le permitiera conocer al detalle todo lo que ocurre en cada una de las zonas criticas de su área y las de mayor preocupación ante posibles ataques informáticos, (para muchos la zona interna), estaríamos mas preocupados por lo que sucede en nuestra red que del auditor interno o externo, porque solo así tendríamos una gestión de seguridad cercana a la realidad, que seguramente se manifiesta en logros que no nos tomaran por sorpresa, porque en una "guerra cibernetica" como en la que estamos, llena de pequeños atacantes de alta peligrosidad, como en toda guerra, solo el que tenga el mayor poder puede vencer a su oponente, (The monitorization is power..RB) tampoco lo busquen en google. La monitorización es una herramienta que nos da poder y control, solo desde aquí se puede hablar de un verdadero punto de partida para mejorar y planear nuestro presupuesto presente y futuro, alrededor de cosas relevantes para toda la organización y por supuesto para el área informática, de este modo el cumplimiento a las normas sera algo fácil, de esta forma podríamos disfrutar de "VERDAD" todo tipo de medallas o menciones honoríficas, sin engallarnos a nosotros mismos :), de otro modo nos quedaremos solo agradeciendo a todo tipo de fuerza o poderes sobre naturales para que nos protejan de todo mal y peligro, y si te decides por esta ultima recuerda las palabras sabias "Ayúdate que yo te ayudare". esto es algo de lo que estoy convencido que las "Leyes de Murphy" SI tienen un SISTEMA DE MONITOREO para saber quien no se ayuda para visitarlo muy amenudo. RODRIGO BEDOYA.

martes, 28 de febrero de 2012

Una contribucion de la comunidad :) (Plugins OSSIM)

En esta ocasión quiero resaltar una valiosa contribución que ha tenido a bien realizar Fernando Mármol (fmarmol539 en gmail punto com).

Dicha contribución consiste en un par de scripts bellamente ejemplificados como colectores de información en bases de datos MySQL. Con estos scripts se escriben los datos de una tabla hacia un log de texto simple, el cual luego es posible procesar mediante un plugin típico, con fuente de log.

Aquí los scripts mencionados.


Script que recupera información de un servidor: base de datos en SQL

import pymssql
import pprint
db=pymssql.connect(host="10.1.84.80", user="logico", password="12345")
cursor=db.cursor()
sql1=("select   AlarmDate, AcctNum, AcctName, AlarmDescription, AlarmZones, AlarmPriority from traffic.dbo.Incoming where AlarmDate >= DATEADD(second, -15,GETDATE())and AlarmDate <= dateadd(dd,1,alarmdate) order by AlarmDate desc")
cursor.execute(sql1)
ret = cursor.fetchall()
data = ""
f=open('/var/log/alarmcenter.log', 'a')
for i in ret:
     data = data + "%s%s%s%s%s\n " % (i[0],i[1],i[2],i[3],i[4])
     f.write ("Fecha:%s Cuenta:%s Abonado:%s Zona:%s Prioridad:%s IpOrigen:10.1.84.80 BaseDatos:AlarmCenter\n" %(i[0],i[1],i[2],i[3],i[4]))
f.close()
 

Script que recupera información de un servidor: base de datos en MYSQL

import MySQLdb
import pprint
db=MySQLdb.connect(host="10.3.18.18",user="consulta",passwd="consulta",db="Consulta")
cursor=db.cursor()
sql1=("select UserName, login, FechaAcceso  from Accesos where FechaAcceso >= DATE_SUB(now(),  INTERVAL 5 MINUTE) order by 3")
cursor.execute(sql1)
ret = cursor.fetchall()
data = ""
f=open('/var/log/sigma.log', 'a')
for i in ret:
     data = data + "%s%s%s\n " % (i[0], i[1],i[2])
     f.write ("Usuario:%s Login:%s FechaAcceso:%s IpOrigen:10.3.18.18\n" %(i[0],i[1],i[2]))
f.close()

martes, 29 de noviembre de 2011

Security Zone 2011

!Sexy defense ! una alternativa en seguridad.

Una vez aparecen propuestas inclinadas hacia la personalización de la seguridad informática, (Security Customized), esta vez y aprovechando mi asistencia a uno de los mas importantes eventos realizados recientemente Securityzone 2011 he podido discutir algunos de los planteamientos de la "Sexy defense" directamente con el grupo de expositores, dentro de los cuales solo citare algunos nombres y sus conferencias:
- Ian Amit (Israel): Crimen|Guerra Cibernetica – conectando los puntos.
- Stefan Friedli (Suiza): Pruebas de Penetración: Como hacerlo Correcto!
- Michael J. Graven (USA): Cuando falla la prevención, los duros responden
- Georgia Weidman (USA) – Control Transparente BOTNET de teléfonos inteligentes por medio de SMS
- Vivek Ramachandran (India): Enterprise Wi-Fi Worms, Backdoors y Botnets para diversión y ganancias.
en fin pueden observar mas detalles en el cronograma de securityzone.co.
Lo importante del planteamiento de la "Sexy defense" es que encierra un modelo de protección personalizado para cada organización, eso incluye por supuesto, el uso de herramientas como OSSIM, o Alienvault Siem, aunque la verdad prefiero aun el primer nombre, por su traducción literal de sus siglas en ingles (Open Source Security Information Management), y es que precisamente soluciones de código abierto, integrables con múltiples plataformas, modulares etc, etc que ya conocemos de OSSIM, son un importante aporte para abordar la seguridad en este tipo de modelos de defensa sexy, que cada vez toma mas fuerza como una salida viable sustentada en la efectividad para los intereses de una organización.,

!En hora buena! ya se me estaban desgastando un poco los discursos acerca de este tema en mi región, gracias a algunos gerentes de TI, quienes aun buscan la gran bala de plata que le soluciona todos los problemas de seguridad y que les es ofrecida en un bonito estuche que se activa con solo oprimir un botón, me siento muy complacido de haberme orientado por OSSIM desde hace varios años no solo como un software o solución de seguridad, sino como una metodología de abordar la monitorización de seguridad informática, tal como se lo expuse al mismo Julio Casal en un pequeño restaurante al norte de mi ciudad natal, en fin seguramente seguirán sonando seudónimos para las soluciones de seguridad a medida, pero por ahora sigo pensando que una salida efectiva a la seguridad de las organizaciones, se debe plantear bajo la premisa, !for custom problems --- custom solutions! bueno una traducción no muy literar seria algo así como, para problemas específicos, soluciones a medida.

lunes, 24 de mayo de 2010

Campus Party Colombia 2010

En esta ocasión el equipo de OSSIM Colombia estará de nuevo en Campus Party 2010, y uno de nuestros miembros (el Sr. Kristian_Paul) estará dictando una interesantísima conferencia acerca del proyecto RepRap, concerniente a las aplicaciones de prototipado 3D con software y hardware libre.
De otra parte en esta edición de Campus Party habrá un espacio dedicado de forma exclusiva a la seguridad de la información y las redes, y tendremos conferencias de sumo interés como las que serán dictadas por la gente de la Comunidad DragonJar, además de (como siempre) lo último en innovación y entretenimiento.

Para ver más: Campus Party Colombia 2010

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!