RASTREO Y EXPLORACIÓN DE REDES Y SISTEMAS

En esta guía vamos a aprender técnicas y métodos de exploración de redes y sistemas. Veremos métodos para identificar estaciones de trabajo de una red, métodos de rastreo estándar como vainilla conect() y SYN medio abierto, métodos sigilosos de rastreo (indicador de TCP inverso, indicador ACK), métodos anónimos (rastreo de rebote FTP, rastreo de rebote en Proxy) y rastreo de puertos UDP. Pensaba incluir también una técnica silenciosa para enumerar servicios utilizando zombies, pero debido a la extensión y a las posibilidades que ofrece, se dejará para más adelante, ya que no daría tiempo a explicarla como se merece en este how-to.

SONDEO ICMP:

Supongamos que estamos dentro de una red. Como sabréis, en una red podemos encontra estaciones de trabajo, servidores de archivos, servidores de disco, servidores de impresión, servidores ftp, servidores web, servidores de correo... todos ellos conectados a un concentrador, conmutador o router (dependiendo de la red/subred) situado en el típico armario de conexiones. Un atacante, lo primero que haría sería hacerse con las ip's internas de la red con el fin de elaborar un mapa de conceptual de la red y los equipos que la componen. A continuación, procedería a evaluar estos sitemas con la finalidad de encontrar servicios que abordar.

Un sondeo ICMP revelaría en redes potencialmente débiles y poco protegidas, información sobre sus equipos. Existen varios tipos de mensajes ICMP, pero a nosotros nos interesan especialmente cuatro de ellos, que son los que resultan verdaderamente últimes para rastrear una red.

Echo request = También conocidos como paquetes ping. Mediante Nmap, podemos realizar barridos ping para identificar de una manera sencilla los equipos de la red.

Timestamp request = Son solicitudes de tiempo y se utilizan para obtener el tiempo que tarda nuestro equipo en obtener una respuesta del equipo victima.

Information request = Este mensaje se ideó en un principio para localizar sistemas autoconfigurables en el momento de arranque, consiguendo de esta manera descubrir direcciones de red.

Subnet address mask request = Estos mensajes revelan información sobre la mascara de subred utilizada por el equipo analizado. Esto servirá al atacante para realizar el mapa de la estructura de la red y sus subredes.

Barrido ICMP con Nmap:

Nmap, que a en mi humilde opinión, es una auténtica obra de arte de la programación (y los administradores de redes saben por qué lo digo), nos permite realizar barridos icmp con el fin de localizar maquinas internas. Un barrido ICMP consiste en enviar mensajes de tipo 8 "echo request" a todas las direcciones IP internas de la red. Esto se realizaría con el comando:

$ sudo nmap -sP 192.168.2.0/24 Starting Nmap 4.62 ( http://nmap.org ) at 2008-12-22 01:46 CET n hostname -- replacing with '*' Host (192.168.2.1) appears to be up. MAC Address: 00:XX:XX:XX:XX:XX Host 192.168.2.100 appears to be up. Host 192.168.2.103 appears to be up. Host 192.168.2.114 appears to be up. Host 192.168.2.116 appears to be up. Host 192.168.2.117 appears to be up. Host 192.168.2.124 appears to be up. Nmap done: 256 IP addresses (7 hosts up) scanned in 2.142 seconds

Con el argumento -sP, estamos indicando a Nmap que realice un barrido ping en la red. Un administrador competente, habrá filtrado el tráfico ICMP en los firewalls y en el router, por ello esta técnica quedaría obsoleta y habría que condimentarla con algo más. Podríamos añadir al comando el argumento "-PI", que enviará paquetes de sondeo TCP ACK y SYN al puerto 80 de cada equipo:

$ sudo nmap -sP -PI 192.168.2.0/24 Starting Nmap 4.62 ( http://nmap.org ) at 2008-12-22 01:46 CET n hostname -- replacing with '*' Host (192.168.2.1) appears to be up. MAC Address: 00:XX:XX:XX:XX:XX Host 192.168.2.100 appears to be up. Host 192.168.2.103 appears to be up. Host 192.168.2.107 appears to be up. Host 192.168.2.114 appears to be up. Host 192.168.2.116 appears to be up. Host 192.168.2.117 appears to be up. Host 192.168.2.124 appears to be up. Host 192.168.2.136 appears to be up. Host 192.168.2.141 appears to be up. Nmap done: 256 IP addresses (7 hosts up) scanned in 6.053 seconds

Como podéis apreciar, hemos obtenido más información con este comando que con el anterior.

SING:

SING, es una herramienta por línea de comandos que permite envíar sondeos ICMP configurables por el usuario. SING lleva tiempo ya intentando desbancar al comando PING, ya que implementa una serie de mejoras con respecto a este. SING puede descargarse desde sourceforge. Veamos algunas de las posibilidades que nos ofrece esta herramienta. Probemos en primer lugar a realizar un echo request. Con Nmap podíamos realizar esto en un bloque de red. Con SING, si tomamos como objetivo la dirección de difusión (acaba en 255), obtendremos información de todos los equipos de al red:

$ sing -echo 192.168.2.255

Vamos a usar ahora SING para enviar mensajes ICMP de solicitud de tiempo (timestamp request):

$ sing -tstamp 192.168.2.103

Ahora enviaremos mensajes ICMP de solicitud de información (information request):

$ sing -info 192.168.2.107

Por último veamos cono utilizar SING para enviar mensajes ICMP de solicitud de mascara de direcciones (subnet address mask request):

$ sing -mask 192.168.2.136

ICMPScan:

Otra herramienta es ICMPScan,que permite enviar mensajes ICMP de tipo 8, 13, 15 y 17 (que son los 4 que hemos visto antes). Este herramienta es realmente útil, quizá para este tipo de barridos es la mejor, ya que es capaz de poner la interfaz de red en modo promiscuo e indentificar así direcciones IP internas que responden a los sondeos enviados por el programa. Lo podéis descargar de http://bindshell.net/tools/icmpscan. Por si acaso, tenéis un mirror de descarga en esta misma web, al que podéis acceder desde el menú de la izquierda (usadlo en caso de que no funcione el oficial para evitar tráfico innecesario).

Para instalarlo necesitaréis tener instalado libcap y libdnet. Para instalarlo lo haremos del siguiente modo:

$ tar zxvf icmpscan.tgz $ cd icmpscan $ ./configure $ make $ sudo make install

Las funciones de ICMPScan son las siguiente:

Usage icmpscan [ -EPTSNMAIRcvbn ] [ -A address ] [ -f filename ] [ -i interface ] [ -r retries ] [ -t timeout ] target [...] Options -i, --interface Listen on the specified interface. If unspecified, icmpscan will examine the routing table and select the most appropriate interface for each target address. -c, --promisc Put in interface into promiscuous mode. As this option increases the load on the system in general, it should only be used if spoofing of source packets address is enabled with the "-A" option. -A, --address Specify the source IP address of generated packets. -t, --timeout Specify the timeout, in milli-seconds, before retrying. -r, --retries Specify the number of attempts to elicit a particular ICMP response. -f, --file Read target list from the specified file. -E, -P, --echo, --ping Check of ICMP Echo responses. -T, -S, --timestamp Check for ICMP Timestamp responses. -N, -M, --netmask Check for ICMP Netmask responses. -I, --info Check for ICMP Info responses. -R, --router Check for ICMP Router Solicitation responses. -v, --verbose Increase the output verbosity. -B, --debug

Un ejemplo de uso podría ser este:

icmpscan -c -t 500 -r 1 192.168.2.0/24

En este comando estamos especificando a ICMPScan que active el modo promiscuo (-c), que ajuste el tiempo de desconexión a 500 milisegundos (-t 500) y que reenvía como mucho una vez cada sondeo (-r 1).

Métodos de rastreo estándar:

Se trata de técnicas de rastreo sencillas y efectivas pero que llevan el inconveniente de producir mucho tráfico y ser muy agresivas, lo que levantará sospechas en el administrador de la red.

Rastreo Vainilla connect():

Os gusta la vainilla? a mi sí, pero eso no viene al caso. Bueno, ha llegado el momento de meternos con algo de teoría sobre el protocolo TCP/IP. Como ya sabréis, el protocolo TCP (Transfer Control Protcol) es un protocolo de control en el que por medio de banderas (flags) se controla la conexión realizada, indicando cuando se inicia, cuando se establece, cuando finaliza... En el protocolo TCP, para indicar que se va a establecer una conexión, se envía un paquete con flag SYN de sincronización de los sequence numbers (números de secuencia) a un puerto determinado, la maquina receptora, si tiene ese puerta abierto, enviará un paquete con flag SYN para sincronizar los números de secuencia y un paquete con flag ACK para afirmar que la conexión ha sido realizada, finalmente, el primer equipo (cliente) enviará un paquete con flag ACK para asegurar que la conexión se ha establecido también por parte del cliente. Véase el siguiente diagrama:

Sin embargo, si el cliente envía un paquete con flag SYN a un puerto que se encuentra cerrado o filtrado, el servidor responderá con un paquete con flag RST. Véase el siguiente diagrama:

Nmap nos permite realizar este tipo de rastreos con el argumento (-sT).

$ nmap -sT 192.168.167

Rastreo de flag SYN medio abierto:

Como ya hemos comentado, para sincronizar una conexión entre dos equipos utilizando el protocolo TCP/IP, el cliente manda al servidor un SYN, el servidor responde con un SYN/ACK en el caso de que el puerto esté abierto y con un RST si está cerrado. En el caso de que esté abierto y se envíe el SYN/ACK, el cliente concluye con un ACK. La técnica de rastreo de flag SYN medio abierto se distingue de la Vainilla connect() en que esta última, si el puerto está abierto, el cliente responde con un flag ACK. En SYN medio abierto, en caso de que se encuentre abierto el puerto, en lugar de responder con un ACK se reponde con un RST, lo que proboca que se reinicie bruscamente la conexión.

Por desgracia o por fortuna, estos dos métodos son fácilmente detectados por los IDS (Intrussions Detection System), así que no son aconsejables en caso de querer realizar un análisis sigiloso.

En la primera imagen podemos ver como se el servidor responde al SYN enviado por el cliente con un RST, indicando que el puerto está filtrado o cerrado. En la imagen 2, el cliente envía un RST como tercera parte de la comunicación TCP.

Para realizar estos rastreos podemos utilizar Nmap con el argumento -sS:

$ nmap -sS 192.168.2.156

En Nmap se puede ajustar la política de tiempos con el argumento "-T". Con el argumento "-T sneaky" se puede llegar a burlar la seguridad de los firewalls. Esto consiste en enviar muy rápidamente paquetes SYN a diferentes puertos, lo que provocará un desbordamiento de SYN (un tipo de DoS).

Una herramienta muy eficaz es Scanrand, producto de Paketto Keiretsu de Dan Kaminsky. En http://doxpara.com/read.php/code/paketto.html podéis encontrar información relevante sobre el proyecto así como utilidades interesantes. Las opciones del programa son las siguientes:

scanrand 1.10: Stateless TCP Scanner w/ Inverse SYN Cookies(HMAC-SHA1/32 in SEQ) Component of: Paketto Keiretsu 1.10; Dan Kaminsky (dan@doxpara.com) Example: scanrand -b10M 10.0.1.1-254:80,20-25,139 Def. Ports: Use [quick/squick/known/all] instead of explicitly naming ports Options: -S/-L: Only send requests / Only listen for responses -e/-E: Show negative responses / Only show negative responses -t [timeout]: Wait n full seconds for the last response (10s) -b[bandwidth]: Limit bandwidth consumption to n b/k/m/g bytes(0) (0 supresses timeouts or maximizes bw utilization) -N/-NN : Enable name resolution (Prefer Source/Dest) -v : Mark packets being sent, as well as received -vv : Output full packet traces to stderr Addressing: -d [device]: Send requests from this L2 hardware device -i [source]: Send requests from this L3 IP address -p [ port]: Send requests from this L4 TCP Port -s [ seed]: Use prespecified seed for scan verification -f [ file]: Read list of targets from file Experiments: -l [ttl-ttl]: Statelessly TCP Traceroute -D : Distco (Distance Discover) via forced RSTs -c : Try checking Inverse SYN Cookie on Traceroute Notes: Use Control-C to exit before scanrand times out. Be sure to use a longer timeout for slow scans! [n]: estimated network distance from target host. Be careful about available bandwidth -- use -b!

Veamos un ejemplo de uso (para ejecutarlo deberéis tener permisos root):

$ scanrand 192.168.2.1-254:20-25,80,443

Métodos de rastreo sigilosos:

Estos tipos de métodos, aprovechan la estructura de la propia pila TCP/IP para escanear sin ser detectados (en algunas ocasiones, ya que dependerá del IDS y sobretodo del SO). Bueno, vamos al grano. Como ya sabéis, cuando en los métodos anteriores enviábamos paquetes SYN a un host y este nos repondía con el conocido SYN/ACK, daba a conocer que el puerto en cuestión estaba abierto, pero cuando respondía con un RST, daba a entender que el puerto estaba cerrado o filtrado. Muchos IDS son capaces de detectar paquetes con el indicador SYN recibidos y lo que harán será avisar al administrador de sistema diciéndole: "Eh! que están evaluándonos!", a lo que el administrador del sistema responderá tomando mayores medidas de seguridad. Esto desde el punto de vista del atacante puede resultar bastante tedioso y si no queremos levantar sospechas, lo que tendremos que hacer es utilizar métodos sigilosos de rastreo.

Rastreo TCP con indicador inverso:

Este rastreo va a consistir en enviar sondeos con indicadores de tipo FIN, URG, PUSH y NULL. Existen tres tipos de sondeos:

Sondeo FIN = Consistirá en enviar paquetes con el indicador FIN.

Sondeo XMAS = Consistirá en enviar paquetes con los indicadores FIN, URG y PUSH.

Sondeo NULL = Consistirá en enviar paquetes con el indicador NULL.

Cuando enviemos uno de estos indicadores, si el puerto se encuentra abierto, no se obtendrá respuesta alguna. sin embargo, si el puerto se encuentra cerrado, recibiremos un paquete RST. Esto viene definido por el estander RCF 793, que como ya he dicho, indica que si no se percibe ninguna respuesta del puerto analizado, significa que el puerto está abierto o que el equipo se encuentra apagado. Lo que estamos haciendo es enviar paquetes "basura" que dificilmente van a ser detectados por los IDS.

Sin embargo he de deciros que Microsoft (para variar) no respeta este estándar, por lo que no se recbe respuesta alguna cuando se intenta conectar a un puerto cerrado. Por eso esta técnica sólo es eficaz con plataformas UNIX.

Para realizar uno de estos sondeos podemos utilizar Nmap con sus respectivos argumentos:

Sondeo FIN = se utilizará el argumento -sF.

Sondeo XMAS = se utilizará el argumento -sX.

Sondeo NULL = se utilizará el argumento -sN.

Rastreo con indicador ACK:

Otra técnica sigilosa es la de enviar paquetes con indicador ACK y luego analizar la información de los paquetes RST recibidos. Esta técnica explota vulnerabilidades de la pila TCP/IP de sistemas BSD. Existen dos modos de hacerlo:

Análisis del TTL = El TTL es el tiempo de vida de los paquetes recibidos (Time To Live). Para realizar este ataque, hay que enviar miles de paquetes con indicador ACK a diferentes puertos del equipo víctima. Después habrá que analizar los resultados. Nmap nos permite hacer esto con el argumento "sA". Con Hping2 también podemos construir nuestros paquetes y enviarlos aunque hacerlo de forma manual es bastante más tedioso. A la hora de analizar las respuestas habrá que fijarse en el TTL del paquete.

Análisis del campo WiNDOW = Para realizar este ataque se llevará a cabo un procedimiento similar al anterior, enviando muchos paquetes ACK y analizando el campo WINDOW del paquete respuesta. Por norma general, los puertos cerrados tienen un valor WINDOW de 0. Para realizarlo podemos utilizar Hping2 y Nmap con el argumento -sW.

Métodos de rastreo con suplantación de terceros:

En un principio tenía pensado añadir a esta guía información sobre el ratreo basado en el análisis del identificador ip de la cabecera del paquete. Sin embargo ese tema es tan amplio que se dejará para más adelante. Miraremos sin embargo dos técnicas realmente útiles y extremádamente anónimas: Rastreo de rebote FTP o FTP bounce, y rastreo de rebote en proxy.

Rastreo de rebote FTP (FTP bounce):

Muchos servidores web tienen su propio servidor FTP y en muchas redes podemos localizar ordenadores que hacen de servidores de archivos y utilizan el protocolo FTP para desarrollar dicha misión. Es posible que tengamos localizado un servidor FTP desactualizado que permita realizar este tipo de ataques. Existe une defecto en la forma en la que los servidores FTP gestionan las conexiones mediante el comando PORT, que envía datos a equipos y puertos especificados por el usuario. Os pongo algunos servidores que en su configuración estándar se ven afectados por esta vulnerabilidad:

Caldera Linux 1.2 (y versiones anteriores).

FreeBSD 2.1.7 (y versiones anteriores).

HP-UX 10.10 (y versiones anteriores).

IBM AIX 4.3 (y versiones anteriores).

SCO OpenServer 5.0.4 (y versiones anteriores).

Slackwaare 3.3 (y versiones anteriores).

Solaris 2.6/SunOS 5.6 (y versiones anteriores).

La siguiente imagen muestra la estructura del ataque:

Esto es lo que sucede cuando se lleva a cabo este ataque:

1.- El atacante conecta con el puerto del servidor FTP (por defecto el 21). Introduce el modo pasivo, el servidor por tanto es forzado a enviar datos utilizando DTP al puerto espezificado por el atacante en un objetivo. 2.- El atacante intenta conectar con un puerto específico TCP del servidor objetivo mediante el comando PORT. 3.- Se crea una conexión con el equipo objetivo especificado por el comando PORT anterior, mediante el comando LIST. Si se observa una repuesta 226, el puerto está abierto, si la repuesta es 425, el puerto está cerrado o filtrado.

Todo esto lo podemos hacer con Nmap mediante el siguiente comando:

$ nmap -P0 -b usuario:contraseña@servidor:puerto ipvictima

En realidad el argumento que realiza el escaneo FTP bounce es el "-b". El "-P0" sirve para especificar a Nmap que no queremos que realice un ping ya que no tendría sentido poner tanto empeño en camuflarnos si vamos a revelar nuestra verdadera IP.

Rastreo de rebote con proxy:

Todos sabemos que es un proxy y para qué lo podemos utilizar. En este caso vamos a realizar un escanéo utilizando un proxy para anonimizar nuestra IP. Existe una herramienta realmente buena llamada ppscan.c que permite realizar este tipo de escaneos. El uso es el siguiente:

$ ./ppscan Proxy Port Scanner v1.2 by Bronc Buster of LoU Usage: ./ppscan

Esta herramienta podéis descargarla de aquí mismo. Antes estaba disponible en http://phreak.org/, pero parece ser que lo han eliminado. Lo que descargaréis es el código fuente del programa.

Fuente: http://n3t-datagrams.net/guias/rastreo.html

Nagios 3 en Debian 5 (Monitor Redes Ahora Mas Potentes)

Esta es una instalacion por la via manual, aunque Ya Debian y sus derivados ya tiene un Repositorio incluido para esta instalacion Synaptic Packege Manager de Debian o sus derivados, como Ubuntu, y otros, aunque esta guia se pude correo en cualquier ditro teniendo en cuenta las rutas de los archivos simplemente.

AHORA que es NAGIOS ?:

Nagios es un sistema open source de monitorización de redes ampliamente utilizado, que vigila los equipos (hardware) y servicios (software) que se especifiquen, alertando cuando el comportamiento de los mismos no sea el deseado. Entre sus características principales figuran la monitorización de servicios de red (SMTP, POP3, HTTP, SNMP…), la monitorización de los recursos de sistemas hardware (carga del procesador, uso de los discos, memoria, estado de los puertos…), independencia de sistemas operativos, posibilidad de monitorización remota mediante túneles SSL cifrados ó SSH, y la posibilidad de programar plugins específicos para nuevos sistemas.

Partimos de una instalación limpia de debian etch con apache2. Lo primero que necesitamos es instalar nuestro entorno de compilación. Hay un paquete en debian con todo lo que necesitas para ello.

apt-get install build-essential

El segundo paso es instalar las librerías necesarias para, posteriormente, compilar nagios. Necesitamos las jpeg, png y gd2. Para las dos primeras no tuve ningún problema en instalar las que vienen con la distribución estable:

apt-get install libjpeg62 libjpeg62-dev libpng12-0 libpng12-dev

Para las gd2 sin embargo me lié un poco ¿necesito las que traen soporte para xpm o las que no?¿es indiferente, tal vez? Cómo no tenía ni idea y no encontré información referente a ello visité la página del proyecto y vi que allí no hacían distinción alguna… Reconozco que lo de los formatos gráficos no es lo mío (ni los de audio, ni los de video, ni…) así que tiré por la calle de enmedio y decidí bajarme los fuentes y compilarlos también:

cd /tmp
wget -c http://www.libgd.org/releases/gd-2.0.35.tar.gz
tar xzf gd-2.0.35.tar.gz
cd gd-2.0.35
./configure
make
make install

Lo siguiente es crear los grupos y usuarios necesarios para nagios:

useradd nagios
passwd nagios
groupadd nagios
groupadd nagcmd
usermod -G nagios nagios
usermod -G nagios josemaria
usermod -G nagcmd nagios
usermod -G nagcmd www-data

Con esto hemos creado un nuevo usuario (nagios), le asignamos una contraseña, creamos dos grupos (nagios y nagcmd). Añadimos nagios a ambos grupos, el usuario www-data (el que usa Apache) al grupo nagcmd y, por comodidad aunque no es indispensable, nuestro usuario común al grupo nagios para que la edición de ficheros de configuración nos resulte maś cómoda.

Ya lo tenemos todo listo. Ahora toca bajarse Nagios, compilarlo e instalarlo. Visita la página oficial para asegurarte de que usas las últimas versiones disponible. Por lo demás, la secuencia usando las versiones actuales es la siguiente:

cd /tmp
wget -c http://tinyurl.com/2jyzao/nagios-3.0a5.tar.gz
wget -c http://tinyurl.com/2mqzzk/nagios-plugins-1.4.9.tar.gz
tar xzf nagios-3.0a5.tar.gz
cd nagios-3.0a5
./configure --with-command-group=nagcmd
make all
make install
make install-init
make install-config
make install-commandmode
make install-webconf
cd ..
tar xzf nagios-plugins-1.4.9.tar.gz
cd nagios-plugins-1.4.9
./configure --with-nagios-user=nagios --with-nagios-group=nagios
make
make install

Creamos una contraseña para el acceso web del usuario nagiosadmin y reiniciamos apache:

htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
/etc/init.d/apache2 reload

Y por último arrancamos nagios y, si no presenta ningún error, creamos un enlace para que de ahora en adelante arranque de forma automática al iniciar la máquina:

/etc/init.d/nagios start
ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios

Y ya. Con esto nuestro nagios debe de estar totalmente funcional y accesible vía web a través de la URL “http://hostname/nagios”. La configuración por defecto monitoriza algunos servicios en la propia máquina dónde se instala y nos debe de bastar para saber que funciona correctamente. Para sacarle partido debemos de hacer algunas cosillas más que os enumero, aunque con menor detalle, a continuación.

Configurando Nagios 3x

El primer archivo que tenemos que tocar es /usr/local/nagios/etc/nagios.cfg. En el, entre otras cosas, se dicen los archivos de configuración que nagios tendrá en cuenta. En el apartado correspondiente a los objetos, que es lo único que vamos a tocar, localizamos la entrada correspondiente al fichero activo como ejemplo (linux.cfg). Comentamos la línea correspondiente a este fichero e introducimos una nueva con el archivo cfg que usaremos y que se llamará, por ejemplo, mired.cfg. Editamos el archivo nagios.cfg e introducimos los siguientes cambios (en negritas):

# Definitions for monitoring the local (Linux) host
# cfg_file=/usr/local/nagios/etc/objects/linux.cfg

# Definición de nuestra pequeña red local de ejemplo
cfg_file=/usr/local/nagios/etc/objects/mired.cfg

La red que vamos a definir como ejemplo constará de dos servidores windows, dos linux (uno de ellos el propio que alberga a Nagios), un router que nos da salida a Internet y un switch al que están conectados todos ellos. Vamos a crear el archivo mired.cfg en el directorio especificado y en el incluiremos la definición de estos objetos:

define host{
use linux-server
host_name nagios
alias Nagios Server
address 127.0.0.1
}

define host{
use generic-switch
host_name switch#1
alias Switch
address 192.168.0.2
parents nagios
}

define host{
use generic-switch
host_name router#1
alias Router ADSL
address 192.168.0.1
parents switch#1
}

define host{
use linux-server
host_name intranet
alias Servidor Linux
address 192.168.0.3
parents switch#1
}

define host{
use windows-server
host_name windows#1
alias Servidor principal del dominio
address 192.168.0.4
parents switch#1
}

define host{
use windows-server
host_name windows#2
alias Servidor secundario del dominio
address 192.168.0.5
parents switch#1
}

Como podeis ver las definiciones son bien sencillas. Esta simpleza deriva de que Nagios usa una estructura jerárquica en la que cada objeto hereda las características definidas previamente en las plantillas que está usando. La declaración de estas plantillas se hace en el archivo templates.cfg. Allí podemos ver, por ejemplo, el contenido del objeto linux-server que, a su vez, se deriva de otro denominado generic-host. Por el momento os digo esto sólo por culturilla porque no nos va a hacer falta. Nos basta con saber que tenemos disponibles las siguientes plantillas para empezar a trabajar con ellas:

• linux-server
• windows-server
• generic-printer
• generic-switch

Otra cosa interesante es la clausula parents mediante la que especificamos las conexiones entre los diferentes hosts. Como veis la única máquina a la que no le hemos asignado un padre es a la que tiene Nagios instalado. Pensad que esa máquina será el corazón de nuestra red de monitorización porque es desde ella desde donde se ejecutaran todos los comandos.

Aunque aquí no aparece ninguna, una máquina puede tener más de un host como padre (imaginaos una estructura de switches con conexiones redundantes entre ellos). Para ello basta con especificar los nombres de todos los padres que consideremos necesarios separados por comas.

A continuación y en el mismo fichero añadiremos las definiciones necesarias para crear grupos y organizar nuestros objetos y para monitorizar un primer servicio común a todos ellos: el PING

define hostgroup{
hostgroup_name linux-servers
alias Servidores Linux
members nagios, intranet
}

define hostgroup{
hostgroup_name windows-servers
alias Servidores Windows
members windows#1, windows#2
}

define hostgroup{
hostgroup_name switches
alias Electrónica de red
members switch#1, router#1
}

define service{
use generic-service
host_name nagios, intranet, switch#1, router#1, windows#1, windows#2
service_description PING
check_command check_ping!200.0,20%!600.0,60%
normal_check_interval 5
retry_check_interval 1
}

La definición de los grupos es autoexplicativa ¿verdad? Luego nos serviran para organizar las vistas adecuadamente. Y desde luego que esta clasificación no es obligatoria. Podeis crear grupos en función del entorno donde estén las máquinas (desarrollo, preproducción, producción), la localización geográfica, el color de la carcasa… a vuestro rollo, vamos.

Para los servicios quizás sea necesario contar algunas cosas más. Como podemos ver el servicio que hemos definido también deriva de un objeto denomimado generic-service y que también se encuentra en el archivo templates.cfg. Podemos echarle allí un vistazo a esa definición pero por el momento no conviene que os despisteis y lo más interesante es la linea etiquetada como check_command que es donde realmente invocamos al comando que se va a encargar de monitorizar el servicio con una curiosa estructura de argumentos separados mediante signos de exclamación. Para comprender lo que estamos haciendo realmente tenemos que echar mano del fichero commands.cfg. Alli buscamos la definición del comando check_ping:

# ‘check_ping’ command definition
define command{
command_name check_ping
command_line $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p 5
}

$USER1$ es una variable que apunta al directorio donde se encuentran los plugins (/usr/lib/nagios/plugins/) y $HOSTADDRESS$ es la IP del host que estamos monitorizando. Los argumentos que invocamos separados por signos de exclamación se sustituyen aquí por los $ARG1$ y $ARG2$. Es decir, cuando Nagios lanza esta comprobación para, por ejemplo, la máquina que aloja nuestra intranet está ejecutando lo siguiente:

/usr/lib/nagios/plugins/check_ping -H 192.168.0.3 -w 200.0,20% -c 600.0,60% -p 5

No creo que por el momento merezca la pena meterse en muchas interioridades pero básicamente lo que hacemos (y esto es común para casi todos los scripts que monitorizan servicios en Nagios) es pasar un umbral que consideraremos como warning y otro como critical (-w y -c respectivamente). Si te interesa saber más sobre lo que realmente estás haciendo basta con que ejecutes el comando con un -h.

Conocer como funcionan realmente los comandos de nagios es muy importante porque cuando empecemos a desarrollar nuestros propios scripts o queramos modificar los que vienen por defecto lo mejor es ejecutarlos directamente desde línea de comando y comprobar la salida que dan hasta que estemos satisfechos.

Y, si os parece, lo dejamos aquí por el momento. En la próxima entrega añadiremos algunos servicios más y adornaremos con iconos apropiados el mapa de nuestro sistema.

Ahora vamos a empezar por ponerlo bonito. Lo primero que necesitamos son logotipos. En el apartado correspondiente de Nagios Exchange tenemos varias colecciones para elegir. Yo uso habitualmente dos de ellas: Base Images para los ordenadores y Cook Images para la electrónica de red. Los descargamos, los descomprimimos y los copiamos en el directorio /usr/local/nagios/share/images/logos. Cada icono suele venir en cuatro formatos diferentes: gif, jpg, png y gd2.

Ahora tenemos que indicar en las definiciones de nuestros hosts los iconos que queremos usar para representarlos. Como ya os he dicho en otras ocasiones soy un poco torpe para los formatos así que suelo hacer caso a las recomendaciones que leí en algún momento (no recuerdo donde) y escojo el .gif como icono general y el .gd2 para el mapa de estado. No voy a poneros de nuevo la definición de todos los hosts con las líneas que hay que incluir para ello. La sintaxis es tan simple que, creo, basta con uno como ejemplo (lo añadido en negrita):

define host{
use linux-server
host_name nagios
alias Nagios Server
icon_image debian.gif
statusmap_image debian.gd2
address 127.0.0.1
}

Los iconos elegidos para el resto de los hosts han sido network_switch.gif, router.gif, linux40.gif, win40.gif y sus respectivos .gd2 para el mapa de estado. Reiniciamos el servicio y ahora ya se ve mejor ¿verdad?

Añadamos ahora algunos sevicios adicionales. Para ello vamos a volver a echarle un vistazo al fichero /usr/local/nagios/etc/objects/commands.cfg. En el apartado SAMPLE SERVICE CHECK COMMANDS tenemos los que vienen preconfigurados y listos para usar pero ojo con algunos de ellos: los que comienzan con check_local sólo sirven para monitorizar servicios en la propia máquina en la que está instalado nagios. Advertido esto, vamos a añadir los siguientes servicios:

• Número de usuarios, número de procesos y carga de cpu para la máquina que alberga a nagios.
• Servicios SSH y HTTP en ambas máquinas con Linux.
• Servicios SMTP y POP3 en la máquina que alberga la intranet y que, para este ejemplo, también hace las veces de servidor de correo.
• Servicio DHCP en el servidor secundario de dominio de windows.

Para ello añadimos lo siguiente al final de nuestro fichero mired.cfg y volvemos a reiniciar el servicio que ejecuta nagios:

define service{
use generic-service
host_name nagios
service_description Current Users
check_command check_local_users!20!50
}

define service{
use generic-service
host_name nagios
service_description Total Processes
check_command check_local_procs!250!400!RSZDT
}

define service{
use generic-service
host_name nagios
service_description Current Load
check_command check_local_load!5.0,4.0,3.0!10.0,6.0,4.0
}

define service{
use generic-service
host_name nagios, intranet
service_description SSH
check_command check_ssh
}

define service{
use generic-service
host_name nagios, intranet
service_description HTTP
check_command check_http
}

define service{
use generic-service
host_name intranet
service_description SMTP Response Check
check_command check_smtp!-t 5 -e “midominio.es”
}

define service{
use generic-service
host_name intranet
service_description POP3 Response Check
check_command check_pop!-t 5 -e “midominio.es”
}

define service{
use generic-service
host_name windows#2
service_description DHCP
check_command check_dhcp
}

La única personalización que requiere para adecuarlo a vuestra red es cambiar “midominio.es” en los servicios SMTP y POP3 por los que maneje vuestro servidor de correo.

Ahora la vista del grid de servicios de nuestra red queda bastante mejor (notad que he bajado a propósito el servicio POP3 de la máquina correspondiente para que no todo parezca tan idílico):

¿Sigue diciendo alguien por ahí que la configuración de nagios es complicada?

Y aquí lo dejamos por hoy. En la próxima entrega veremos como añadir nuevos servicios a los que vienen por defecto en el fichero commands.cfg

Fuente: http://blogs.clavedigital.com/ncastillo/2009/07/14/nagios-3-en-debian-5-monitor-redes-ahora-mas-potentes/