• No se han encontrado resultados

Inventario de una red IP orientado en CMSI. Capítulo 6: Motor de inventario

N/A
N/A
Protected

Academic year: 2022

Share "Inventario de una red IP orientado en CMSI. Capítulo 6: Motor de inventario"

Copied!
9
0
0

Texto completo

(1)

Capítulo 6: Motor de inventario

(2)

Introducción

En este apartado vamos a explicar el modo de funcionamiento del motor de inventario. Este es el programa principal de proyecto. Es el encargado de clasificar los mensajes en la base de datos orientada en CMSI.

El programa está realizado en lenguaje C a igual que la mayoría de los sensores que desarrollamos anteriormente. El funcionamiento general del programa es conectarse a las bases de datos de alertas y de tráficos y clasificar los mensajes que se hayan detectados.

Modo de funcionamiento

Existe único binario denominado eneo_asset. Si ejecutamos la ayuda con el comando eneo_asset –h nos muestra una pequeña ayuda sobre el modo de uso.

./eneo_asset -h

Usage: eneo_asset [-h] [-d] [-f configFileName] [-c] [-a]

h: help d: debug

f: configFileName c: read traffic a: read alert

Vamos a explicar más detenidamente cada una de las opciones:

• -d: Para usar el programa en modo depuración. En caso de que no esté activada la información se guardará en los ficheros de logs del sistema.

• -c: Lee información procedente de la base de datos del colector de tráfico.

• -a: Lee información procedente de la base de datos del colector de alertas.

• -f: Para indicarle el fichero de configuración del programa. En el siguiente apartado se explica el fichero de configuración.

Configuración

Un ejemplo del fichero de configuración del programa eneo_asset puede ser el siguiente:

########DATABASE ASSET##########

AssetDatabaseNameDB=eneo_asset AssetHostDB=192.168.100.211 AssetUserDB=eneo

AssetPasswdDB=xxxx AssetPortDB=5432

########DATABASE ALERT#########

AlertDatabaseNameDB=eneo_alert AlertHostDB=192.168.100.211 AlertUserDB=eneo

AlertPasswdDB=xxxx AlertPortDB=5432

(3)

########DATABASE FLOW#########

TrafficDatabaseNameDB=eneo_flow TrafficHostDB=192.168.100.211 TrafficUserDB=eneo

TrafficPasswdDB=xxxx TrafficPortDB=5432

#Automatic Probes, detect probes and insert database AutomaticProbes=y

#Interval for delete old data Interval='1 year'

#Detail level for log file LogLevel=2

#Files timestamp

File_timestamp_alert=/etc/eneo_asset/timestamp_prelude.tmp File_timestamp_flow=/etc/eneo_asset/timestamp_netflow.tmp

#Enable probes

#Sensor=name (y|n) a b c d e

# a= [0=disabled, 1=enabled] Networks

# b= [0=disabled, 1=enabled] Operating System

# c= [0=disabled, 1=enabled] Service

# d= [0=disabled, 1=enabled] Property

# e= [0=disabled, 1=enabled] Hardware Sensor=arpwatch y 1 0 0 0 0

Sensor=pads n 0 0 1 0 0 Sensor=efifo_p0f y 0 1 0 0 0 Sensor=assetscan y 0 1 1 0 0 Sensor=mcheck y 0 0 0 1 0 Sensor=msupervise y 0 0 0 1 0 Sensor=wdping n 0 0 0 1 0 Sensor=linceupdate n 0 0 0 1 0 Sensor=watchdog y 0 0 0 1 0 Sensor=supervise n 0 0 0 1 0 Sensor=clamd n 0 0 0 1 0 Sensor=mflowalert y 0 0 0 1 0 Sensor=mresourcealert y 0 0 0 1 0 Sensor=minfo y 0 0 0 0 1

Vamos a ir describiendo cada uno de los parámetros dentro del fichero de configuración:

XXXXDatabaseNameDB: Nombre de la base de datos.

XXXXHostDB: IP o nombre del equipo donde reside la base de datos.

XXXXUserDB: Usuario por el cual se autentica dentro de la base de datos.

XXXXPassDB: Contraseña del usuario.

XXXXPortDB: Puerto de escucha del servidor de base de datos.

AutomaticProbes: [y]/n Indica que el servidor de inventario registrará sondas automáticamente sin necesidad de que esté previamente definida. Se puede poner 'n' para evitar que llegue información de sondas no deseadas.

Interval: Periodo de tiempo en el cual se guardará la información, está en formato temporal PostgreSQL. Ej. '1 year', etc...

(4)

LogLevel: Indica con un número la cantidad de información que quieres que se escriba en el fichero de logs. El máximo es 8 y el mínimo 0 en la cual no se escribe ninguna información.

File_timestamp_alert: Es un fichero temporal en la cual se escribe el último instante del cual se leyó la información de la base de datos de alerta. Con esto evita tener que leer de nuevo toda la base de datos. En el caso de que el fichero no exista o está vacío se leerá desde el dato más antiguo de la base de datos de alerta con el comando:

SELECT time FROM prelude_summary_daily ORDER BY time ASC LIMIT 1

Destacar que se lee los datos de la tabla prelude_summary_daily, y no de prelude_summary_yearly que es mucho más antigua, esto es debido a que la tabla diaria contiene información más detallada y necesaria para el inventario. Además, estamos hablando de tablas con una gran cantidad de información, no es muy aconsejable la primera vez que se ejecuta el demonio de inventario que tenga que leer y clasificar de golpe una gran cantidad de información, ya que puede saturar el servidor.

File_timestamp_traffic: A igual que antes es un fichero temporal que registra el ultimo instante de lectura de base de datos del coletor de tráfico. El comando que se ejecuta:

SELECT now()::TIMESTAMP - interval '1 day'

Sensor nombre_sensor (y|n) (1|0) (1|0) (1|0) (1|0) (1|0): Aquí es donde definimos los sensores o analizadores que se utiliza en el inventario. El objetivo de esto es hacer el sensor más eficiente según la naturaleza de los mensajes. El primer argumento es el nombre de la sonda, por ejemplo cualquiera que hayamos definido antes. El segundo argumento habilita el sensor para ser registrado en el inventario.

El resto de parámetros indica la naturaleza del sensor, en el siguiente orden:

o Red: El dato que llega al demonio de inventario tiene información de la red del sistema.

o Sistema Operativo: Los paquetes que se van clasificando tienen información sobre el sistema operativo.

o Servicio: Se aporta información sobre un servicio de red en un determinado equipo.

o Property: Se aporta información sobre algún evento especial en la red. Por ejemplo, un equipo no se ha reiniciado correctamente, detección de virus, etc.

o Hardware: Se aporta información sobre el hardware de los equipos de la red.

En caso de que no se sepa muy bien la información que aporta cada uno de los sensores, se puede activar todos los parámetros. Esto funcionará perfectamente el único inconveniente es que no será del todo eficiente. Ya que no tiene lógica por ejemplo que se intente clasificar mensajes procedentes de un

(5)

sensor que da información hardware en una familia del tipo Servicio. Por tanto que el sistema intente clasificarlo es una pérdida de eficiencia.

En el ejemplo de nuestro fichero de configuración podemos observar que la mayoría de los sensores están especializado en un naturaleza de información específica, excepto el sensor que desarrollamos antes el assetscan que da información del sistema operativo y de los servicios que están corriendo en un equipo determinado.

Código

En primer lugar vamos a presentar el fichero Makefile:

COMPILE = gcc -g -Wall CFLAGS = -lpq -lm -lpcre PROGRAM = eneo_asset MAIN = easset ASSET = eassetlib UTILS = utils DOSYSLOG = dosyslog ALERT = easset_alert DIRALERT = alert

TRAFFIC = easset_traffic DIRTRAFFIC = traffic

$(PROGRAM): $(MAIN).o $(ASSET).o $(ALERT).o $(TRAFFIC).o $(UTILS).o

$(DOSYSLOG).o

$(COMPILE) -o $(PROGRAM) $(MAIN).o $(ASSET).o $(ALERT).o

$(TRAFFIC).o $(UTILS).o $(DOSYSLOG).o $(CFLAGS) rm -rf *.o

$(MAIN).o: $(MAIN).c

$(COMPILE) -c $(MAIN).c

$(ASSET).o: $(ASSET).c

$(COMPILE) -c $(ASSET).c

$(UTILS).o: $(UTILS).c

$(COMPILE) -c $(UTILS).c

$(ALERT).o: $(DIRALERT)/$(ALERT).c

$(COMPILE) -c $(DIRALERT)/$(ALERT).c

$(TRAFFIC).o: $(DIRTRAFFIC)/$(TRAFFIC).c

$(COMPILE) -c $(DIRTRAFFIC)/$(TRAFFIC).c

$(DOSYSLOG).o: $(DOSYSLOG).c

$(COMPILE) -c $(DOSYSLOG).c clean:

rm -f *.o

rm -f $(PROGRAM)

rm -f *~

La carpeta marteasset está formada por los siguientes ficheros escritos en lenguaje C.

(6)

marteasset/

alert/

easset_alert.c easset_alert.h traffic/

easset_traffic.c easset_traffic.h definition.h dosyslog.h dosyslog.c easset.c easset.h eassetlib.c eassetlib.h makefile utils.c utils.h

Vamos a ir ahora explicando cada uno de los ficheros mencionados anteriormente:

Makefile: Fichero necesario para la compilación general del programa.

Definition.h: Es el fichero de cabecera global, contiene definiciones y estructuras necesarias en todo el programa.

Easset.*: Fichero que contiene la función principal del motor de inventario. Aquí se hace las llamadas a las funciones de clasificación tanto en el módulo de alertas como en el módulo de tráfico.

Eassetlib.*: Librería que contiene las funciones necesarias para la clasificación de los datos de inventario. Dichas funciones son:

o insert_host: Función necesaria para insertar un equipo detectado en la base de datos de inventario.

o insert_product: Función que inserta un producto en la base de datos conforme al estándar CMSI.

o insert_product_attr_value: Función que inserta el valor de un determinado producto en la tabla product_attr_value del estándar CMSI.

o insert_probe: Inserta una sonda en la tabla probes.

o ident_family: Devuelve el identificador de una familia, esta función es la más compleja ya que utiliza expresiones regulares de la librería pcre para saber a que familia pertenece cada mensaje. La función es capaz de determinar si un mensaje con la misma información ha sido insertado anteriormente, y en el caso de que se haya insertado, actualiza el tiempo de detección.

(7)

o ident_network: muy similar a la función anterior con la diferencia de que no utiliza expresiones regulares, sino que la única comprobación que se hace es si una cierta IP pertenece a una subred o no, utilizamos para ello el comando PostgreSQL. Ej. SELECT inet '192.168.100.27 <<

'192.168.100.0/24' devuelve true.

o createattributes: función básica que crea una lista de atributos a partir de un mensaje, esta lista de atributos es necesaria para insertarlo después en la tabla product_attr_value.

o family_unknown: función que devuelve el identificador de la familia especial 'unknown', esta familia se caracteriza por ser la familia por defecto.

Es decir, si no se es capaz de registrar ningún mensaje este pasará directamente a la familia unknown.

o is_famili_serv: función que devuelve si la familia tiene la propiedad de ser un servicio.

o family_name: función que devuelve el identificador de una familia a partir del nombre de esta.

o ident_attr_id: función que devuelve el identificador de un atributo a partir del nombre de este.

o update_family: función que actualiza los datos que ya existían en la base de datos de inventario. Útil para el caso de que se inserte una nueva expresión regular y se clasifique en una nueva familia.

o update_time: función que borra del inventario todos los datos de una antigüedad superior al periodo de tiempo que se le pasa en el fichero de configuración.

o exist_product: Función que se encarga de mirar si hay un producto del mismo equipo, sonda y familia que se haya insertado anteriormente y con los mismos atributos, si existe devuelve 0 y si no existe devuelve un numero distinto de 0.

o coincidence_attr: Función que se encarga de mirar si coincide los nuevos atributos con los antiguos, devuelve 0 si hay coincidencia, devuelve un número entero que indica el número de atributos que se diferencia.

o insert_new_family: Función que inserta una nueva familia en la base de datos.

o insert_expression: Función que inserta una expresión regular en la base de datos para una determinada familia.

alert/easset_alert.*: Este fichero contiene las siguientes funciones relacionada con la base de datos de alertas.

o inventory_alert: Función general que organiza la lectura y clasificación de la base de datos de alertas.

(8)

o probe_alert: Función que lee y clasifica los mensajes de cada sonda y sensor.

o read_last_time_alert: Función que devuelve el instante de tiempo más antiguo de la base de datos de alerta.

o read_first_time_alert: Función que devuelve el instante de tiempo de la última alerta insertada en la base de datos.

traffic/easset_traffic.*: Contiene las siguientes funciones.

o inventory_traffic: Función general que organiza la lectura y clasificación de la base de dato de tráfico.

o probe_traffic: Función que lee y clasifica los mensajes de cada sonda.

o read_last_time_traffic: Función que devuelve el instante de tiempo del flujo más antiguo de la base de datos de tráfico.

o read_first_time_traffic: Función que devuelve el instante de tiempo del último flujo insertado en la base de datos de tráfico.

dosyslog.*: Función que hace uso de la librería syslog. La utilizamos para insertar información en los ficheros de logs.

Utils.*: Fichero que contiene funciones útiles para el programa de inventario, estas funciones son:

o write_file_tmp: Escribe en un fichero temporal en el directorio /tmp la fecha de la última lectura de una base de datos (alertas, tráfico, etc).

o read_file_tmp: Lee del fichero temporal la última vez que se accedió a la base de datos.

o readconfig: Función que lee los parámetros del fichero de configuración /etc/eneo_asset/eneo_asset.conf presentado al principio de este capítulo .

o connectdb: Función que devuelve la conexión a una base de datos PostgreSQL.

o get_list_value: Función que devuelve en una lista, el resultado de una consulta SQL a una base de datos PostgreSQL.

Una vez que compilamos el código ejecutando make obtenemos un archivo binario eneo_asset. Este programa es el encargado, a partir del fichero de configuración, de clasificar todos los mensajes de las bases de datos indicadas.

La idea es que se llame a este programa a través de un cron que se ejecute cada cierto tiempo y vaya leyendo los mensajes nuevos que se inserten en las bases de datos de alertas y de tráfico.

(9)

Bibliografía

Las fuentes consultadas para el desarrollo de estás librerías son:

Las páginas de manual de Linux.

man XXXX.

Librerías de pcre.

http://www.pcre.org

Referencias

Documento similar

En nuestra opinión, las cuentas anuales de la Entidad Pública Empresarial Red.es correspondientes al ejercicio 2010 representan en todos los aspectos significativos la imagen fiel

En nuestra opinión, las cuentas anuales de la Entidad Pública Empresarial Red.es correspondientes al ejercicio 2012 representan en todos los aspectos

La Intervención General de la Administración del Estado, a través de la Oficina Nacional de Auditoría, en uso de las competencias que le atribuye el artículo 168

La Intervención General de la Administración del Estado, a través de la Oficina Nacional de Auditoría, en uso de las competencias que le atribuye el artículo

La campaña ha consistido en la revisión del etiquetado e instrucciones de uso de todos los ter- mómetros digitales comunicados, así como de la documentación técnica adicional de

Cedulario se inicia a mediados del siglo XVIL, por sus propias cédulas puede advertirse que no estaba totalmente conquistada la Nueva Gali- cia, ya que a fines del siglo xvn y en

Abstract: This paper reviews the dialogue and controversies between the paratexts of a corpus of collections of short novels –and romances– publi- shed from 1624 to 1637:

Esto viene a corroborar el hecho de que perviva aún hoy en el leonés occidental este diptongo, apesardel gran empuje sufrido porparte de /ue/ que empezó a desplazar a /uo/ a