###### Versión de pfSense:


Si hay algo indispensable en cualquier infraestructura, es un buen monitoreo de disponibilidad y seguridad; tener un correcto control de los dispositivos de red y servidores, permite realizar acciones proactivas y evitar casi todos los problemas que puedan surgir.

Dada la criticidad de los firewalls, una correcta definición de alertas sobre los mismos, nos puede permitir disminuir los downtimes y mejorar nuestra seguridad.

La mejor herramienta para hacerlo, por su trayectoria, por su comunidad, por su flexibilidad, por ser open-source, por ser gratutita y por ser altamente efectiva (si, me encanta), es sin lugar a dudas Nagios. Es un software que funciona con un servicio web que gestiona y facilita el monitoreo mediante una gran cantidad de plugins. Es posible realizar casi cualquier chequeo utilizando los plugins predeterminados, o cualquier otro plugin ya desarrollado o desarrollando uno propio. Todo es monitoreable: desde si la página web está mostrando un string específico o un 200/OK, hasta si un backup se ejecutó de manera correcta e íntegra.

En este post, se verán algunos conceptos y explicaciones para integrar ambas herramientas y poder adaptarlas a la necesidad de cada usuario y obtener un eficaz resultado.

Básicamente hay 3 tipos de chequeos que se pueden realizar desde Nagios:

  • Chequeos Remotos: Cualquier chequeo que se pueda realizar sin necesidad de acceder al equipo (por ejemplo chequear el estado de servicios/puertos de manera estandar como el web, https, smtp, o ftp).

  • Chequeos Locales: Cualquier chequeo realizable “desde adentro” de un equipo para obtener datos que no son publicables y que necesitan ciertos privilegios que “desde afuera” no sería posible. Para realizarlos, se instala en los equipos a chequear un agente, que los ejecuta y que brinda cierta seguridad y facilidad para consultarlos desde nuestro monitoreo. Por ejemplo, es posible chequear el espacio en disco, el uso de memoria, si un servicio en particular esta activo, si un archivo no se modifico, y muchos más. Existen varios agentes para chequeos locales, pero los más utilizados, confiable y faciles de implementar, son para Unix/Linux/BSD NRPE, y para Windows NSCLIENT++.

  • Chequeos SNMP: SNMP es un protocolo de consulta ampliamente aceptado y utilizado que poseen la mayoría de los dispositivos de red y sistemas operativos, que brinda de manera sencilla el acceso a muchísimas opciones de consulta de cada uno de los recursos de los dispositivos. Es una forma fácil de acceder a información de estados y funcionamiento sin necesidad de estar programando un script de consulta específico, sin embargo, se deben tener ciertos resguardos en cuanto a seguridad para asegurarnos que sólo nosros accedamos al dispositivo mediante este protocolo. Cada fabricante debe debería proveer una base de datos denominada MIB que asginan un ID númerico a cada tipo de consulta. Conociendo dicha base sabremos que nos es posible consultar mediante ese protocolo en cada equipo en particular.

¿ Que nos importa chequear en nuestro Firewall ?

En primer lugar, es siempre importante saber SI EL EQUIPO ESTA FUNCIONANDO. No ? Por lo tanto el chequeo más básico será de disponibilidad y la forma más sencilla de hacerlo es mediante el protocolo icmp (ping). Este será el único chequeo de tipo “remoto” que ejecutaremos en el equipo.

Otras ideas podrían ser:

  • UPTIME (Tiempo que estuvo activo. Si este tiempo vuelve a 0, significa que el equipo se reinició).
  • MEMORIA DISPONIBLE
  • ESPACIO EN DISCO
  • ESTADO DE LAS INTERFACES
  • ESTADO DE LAS VPNS
  • ESTADO DE LOS SERVICIOS
  • CANTIDAD DE USUARIOS CONECTADOS
  • DENEGACIONES EN LAS INTERFACES
  • TRÁFICO IN/OUT

No vamos a explicar en este artículo como implementar un sistema de monitoreo Nagios, y se asume que el usuario tiene ciertos conocimientos de dicha plataforma; si no los tenés, recomendamos leer la documentación disponible sobre la misma, que es mucha y muy buena.

Topología de Monitoreo ¿ Dónde ubicar nagios en la red ?:

La mejor opción sería ubicar Nagios en la misma red local, en una subnet específica y manejar los accesos desde ese equipo al resto o al firewall, mediante ACL específicas.

Si van a realizar un monitoreo desde algún punto remoto en Internet, sería muy recomendable realizarlo a través de una vpn ipsec; y en caso de que no sea posible, realizarlo vía intenet, pero restrigiendo mediante reglas de firewall el acceso por origen únicamente al nagios, para los servicios y puertos necesarios.

Vamos a utilizar los siguientes puertos que será necesario manejar en el firewall para que funcione, con origen Nagios y destino la IP del Firewall:

  • ICMP / PING – Para monitoreo remoto de disponibilidad.
  • 5666 / TCP – Para monitoreos NRPE
  • 161 / UDP – Para monitoreos SNMP

Configuración:

Definición de Template y Host:

En Nagios vamos a definir un template para este tipo de equipos que serán los firewalls pfSense de nuestra infra. Esto nos permitirá setearle parámetros de monitoreo específicos diferentes por ejemplo a servidores u otros equipos.

define host{
name                            pfsense-firewall
use                             generic-host
check_period                    24x7
check_interval                  5
retry_interval                  1
max_check_attempts              10
check_command                   check-host-alive
notification_interval           120
contact_groups                  admins
register                        0
}

El check_command, que define como se chequea el host para disponibilidad, en este caso será el por defecto check-host-alive, que realizar un chequeo ICMP

Y luego definiremos el Host que utilice dicho template.

define host{
use                 pfsense-firewall
host_name           pfsense.empresa.com.ar
alias               pfsense.empresa.com.ar
address             192.168.0.1
}

Con esta configuración ya Nagios agrega el host al dashboard y lo chequea para avisarnos de problemas de disponibilidad.

Chequeos Locales (vía NRPE):

Como dijimos, para este tipo de chequeos, es necesario instalar un agente en el equipo, y en este caso para el pfSense será NRPE. Por suerte pfSense nos facilita esta tarea mediante un paquete que se instala desde la GUI como cualquier otro, por lo tanto, en primer lugar, instalaremos el paquete “NRPE v2″, desde System -> Packages.

Una vez instalado, deberemos configurarlo, para esto vamos a Services -> NRPEv2:

En primer lugar se habilita el servicio con el primer tilde.

Se configura el puerto donde va a escuchar el servicio, si lo cambian, recuerden armar la correcta habiitación en el firewall.

La “Bind IP”, es la IP donde queremos que el servicio responda, por ejemplo si el firewall tiene más de una interface, tendremos que elegir la ip de alguna, si tenemos el Nagios en nuestra red local, seguramente la ip será una privada, en caso de que estemos monitoreando desde Internet, la IP será una pública. Si queremos que escuche en todas las interfaces, o si tenemos una ip pública que es dinámica, podemos ingresar 0.0.0.0, que se traduce en “todas”.

“Nagios Server” es la IP de nuestro Nagios, y es una medida de seguridad adicional a la regla de firewall, que únicamente permite que se hagan consultas desde esa IP.

Luego, se configurará los plugins que se ejecutarán internamente en el equipo, y la forma de consultarlos remotamente. Por default el paquete trae algunos, pero se pueden agregar cuantos necesitemos:

La interface anterior, lo que hace es ayudarnos en la configuración y básicamente escribirla en /usr/local/etc/nrpe.cfg

La primer columna, es el nombre que se utilizará para llamar al chequeo desde el Nagios mediante el chequeo de nrpe.

Luego figura un tilde para especificar si realiza el chequeo como root o no (sudo).

La tercer columna “command”, especifica que plugin va a ejecutar, el path de los plugins es /usr/local/libexec/nagios; si tienen alguna duda sobre como funciona algún plugin, pueden ir a ese path y ejecutar cada uno con el parametro –help. Por ejemplo:

/usr/local/libexec/nagios(9): ./check_users –help

check_users v (nagios-plugins 1.4.15)
Copyright (c) 1999 Ethan Galstad
Copyright (c) 2000-2007 Nagios Plugin Development Team
<[email protected]>

This plugin checks the number of users currently logged in on the local system and generates an error if the number exceeds the thresholds specified.

Usage:
check_users -w <users> -c <users>

Luego se configuran los umbrales de alerta para Warning y para Critical y un último campo para ejecuar parámetros adicionales si el plugin los necesita. Por ejemplo el check_disk necesita un -p para especificar el path a chequear.

Si se necesita ejecutar otro plugin adicional, se agrega con el simbolo “+”, y se especifica como ejectuarlo y como llamarlo.

Vamos a agregar un chequeo adicional a nuestra medida, para mostrar como hacerlo: el chequeo utilizará también el plugin “check_procs”, pero ejecutado de la siguiente forma:

check_procs -w 10 -c 20 –metric=CPU

Que nos alertará en caso de que cualquier proceso esté usando más de 10% del CPU (Warning) o más de 20% para critical:

**Lo que viene ahora es la configuración de los chequeos, pero del lado de Nagios.
**

En primer lugar, se define el comando para el chequeo local por medio de NRPE (que ya viene definido por default en la mayoría de las instalaciones). En nuestro caso, vamos a modificar la configuración por default para agregar el puerto a los parametros que le vamos a pasar:

define command{
command_name    check_nrpe
command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p $ARG1$ -c $ARG2$ -t 200
}

Lo que hicimos es definirle que cada vez que se lo llame se ejecuta pasando como parámetro la dirección del host en -H y el primer argumento al -p (puerto) y el segundo al -c (comando) y además un timeout generoso para evitar problemas de red que lo dejamos fijo en 200 segundos. Podríamos por ejemplo haberlo definido como -t $ARG3$ para que sea definido según el servicio que ejecutemos.

En la mayoría de las instalaciones, el -p también viene fijo en 5666 (-p 5666), pero dejarlo con ARG1, nos dará mayor flexibilidad en caso de que usemos diferentes puertos por equipo.

Ahora definimos los servicios para que chequee en el pfSense que vimos arriba:

define service{
use                 generic-service
host_name           pfsense.empresa.com.ar
service_description DISCO: ROOT
check_command       check_nrpe!5666!check_root
}

define service{
use                  generic-service
host_name            pfsense.empresa.com.ar
service_description  DISCO: VAR
check_command        check_nrpe!5666!check_var
}

define service{
use                  generic-service
host_name            pfsense.empresa.com.ar
service_description  CARGA
check_command    check_nrpe!5666!check_load
}

define service{
use                   generic-service
host_name             pfsense.empresa.com.ar
service_description   USUARIOS
check_command        check_nrpe!5666!check_users
}

define service{
use                    generic-service
host_name              pfsense.empresa.com.ar
service_description    PROCESOS ZOMBIES
check_command check_nrpe!5666!check_zombie_procs
}

define service{
use                 generic-service
host_name           pfsense.empresa.com.ar
service_description PROCESOS TOTALES
check_command check_nrpe!5666!check_total_procs
}

define service{
use                 generic-service
host_name           pfsense.empresa.com.ar
service_description PROCESOS CPU
check_command check_nrpe!5666!check_cpu_procs
}

Con la configuración anterior, Nagios ya es capaz de realizar los chequeos vía NRPE:

Chequeos SNMP:

Para realizar los chequeos SNMP, en primer lugar se debe habilitar el servicio en pfSense. Para esto vamos a ir System -> SNMP:

Se habilita el SNMP Daemon, se configura el puerto, y se setea un community string, que en este protocolo, es similiar a un password. Se recomienda cambiar el mismo. Luego se configura en que interface se bindea (tal cual hicimos con NRPE) y los modulos a utilizar:

Del lado de Nagios, el plugin para realizar chequeos SNMP, es check_snmp, se puede ver su utilización ejecutando un help del mismo:

check_snmp v2.0 (nagios-plugins 2.0)
Copyright (c) 1999-2014 Nagios Plugin Development Team
<[email protected]>

Check status of remote machines and obtain system information via SNMP

Usage:
check_snmp -H <ip_address> -o <OID> [-w warn_range] [-c crit_range]
[-C community] [-s string] [-r regex] [-R regexi] [-t timeout] [-e retries]
[-l label] [-u units] [-p port-number] [-d delimiter] [-D output-delimiter]
[-m miblist] [-P snmp version] [-L seclevel] [-U secname] [-a authproto]
[-A authpasswd] [-x privproto] [-X privpasswd]

Básicamente, utiliza la librería net-snmp, que contiene varias utilidades para consulta del protocolo snmp. Recomiendo primero hacer ciertas pruebas con dicha librería y con los comandos snmpget y snmpwalk para ponernos a tono con el protocolo; igualmente aca vamos a ver unos ejemplos.

Realmente me ha resultado dificil encontrar buena documentación sobre este tipos de chequeos en pfSense, pero al menos les voy a presentar algunos chequeos básicos e interesantes. Cualquier información adicional que encuentren, la pueden poner en un comentario y será agregada.

Voy a utilizar IF-MIB y SNMPv2-SMI para diferentes chequeos:

A. Utilizando IF-MIB:

En primer lugar vamos a identificar el ID númerico que asigna la MIB a las interfaces que tenemos en el equipo.

Podemos hacerlo por mac:

snmpwalk -v2c -c p4ssw0rdSNMP 192.168.0.1 IF-MIB::ifTable.ifEntry.ifPhysAddress

IF-MIB::ifPhysAddress.1 = STRING: 0:c:29:45:7:69
IF-MIB::ifPhysAddress.2 = STRING: 0:c:29:45:7:73
IF-MIB::ifPhysAddress.3 = STRING: 0:c:29:45:7:7d
IF-MIB::ifPhysAddress.4 = STRING:
IF-MIB::ifPhysAddress.5 = STRING:
IF-MIB::ifPhysAddress.6 = STRING:
IF-MIB::ifPhysAddress.7 = STRING:
IF-MIB::ifPhysAddress.8 = STRING:
IF-MIB::ifPhysAddress.9 = STRING:

O por descripción:

snmpwalk -v2c -c p4ssw0rdSNMP 192.168.0.1 IF-MIB::ifTable.ifEntry.ifDescr

IF-MIB::ifDescr.1 = STRING: em0
IF-MIB::ifDescr.2 = STRING: em1
IF-MIB::ifDescr.3 = STRING: em2
IF-MIB::ifDescr.4 = STRING: plip0
IF-MIB::ifDescr.5 = STRING: enc0
IF-MIB::ifDescr.6 = STRING: pfsync0
IF-MIB::ifDescr.7 = STRING: lo0
IF-MIB::ifDescr.8 = STRING: pflog0
IF-MIB::ifDescr.9 = STRING: ovpns1

En nuestro equipo, la em0 con su mac 0:c:29:45:7:69, es la interface a la que vamos a consultar ya que es nuestra wan. Pueden chequear dichos datos en Status –> Interfaces:

Ahora que sabemos el id numérico para las intefaces que queramos monitorear, vamos a probar algunos comandos para obtener data:

Tráfico in:

snmpwalk -v2c -c p4ssw0rdSNMP 192.168.0.1 IF-MIB::ifTable.ifEntry.ifInOctets.1

IF-MIB::ifInOctets.1 = Counter32: 110114086

Tráfico Out:

snmpwalk -v2c -c p4ssw0rdSNMP 192.168.0.1 IF-MIB::ifTable.ifEntry.ifOutOctets.1

IF-MIB::ifOutOctets.1 = Counter32: 84756753

Estado de la Interface:

snmpwalk -v2c -c p4ssw0rdSNMP 192.168.0.1 IF-MIB::ifTable.ifEntry.ifAdminStatus.1

IF-MIB::ifAdminStatus.1 = INTEGER: up(1)

B. Utilizando SNMPv2-SMI

Nuevamente identificamos las interfaces con esta tabla:

snmpwalk -v2c -c p4ssw0rdSNMP 192.168.0.1 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.1 = STRING: “all”
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.2 = STRING: “carp”
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.3 = STRING: “em0”
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.4 = STRING: “em1”
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.5 = STRING: “em2”
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.6 = STRING: “enc”
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.7 = STRING: “enc0”
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.8 = STRING: “lo”
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.9 = STRING: “lo0”
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.10 = STRING: “openvpn”
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.11 = STRING: “ovpns1”
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.12 = STRING: “pflog”
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.13 = STRING: “pflog0”
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.14 = STRING: “pfsync”
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.15 = STRING: “pfsync0”
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.16 = STRING: “plip0”
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.2.17 = STRING: “tun”

La que nos interesa a nosotros es la “em0” o sea el ID 3, y podemos consultar:

Paquetes bloqueados:

snmpwalk -v2c -c p4ssw0rdSNMP 192.168.0.1 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.12.3
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.12.3 = Counter64: 19202

Paquetes Aceptados:

snmpwalk -v2c -c p4ssw0rdSNMP 192.168.0.1 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.11.3
SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.12.3 = Counter64: 19208

Hay muchos otros datos estadísticos que podemos consultar, recomiendo hacer un snmpwalk más amplio para ver todos los disponibles:

snmpwalk -v2c -c p4ssw0rdSNMP 192.168.0.1

Ahora solo falta crear la configuración en Nagios para que levante dichos chequeos:

En primer lugar definimos el comando (generalmente creado en la instalación default), pero lo vamos a mejorar un poco:

define command{
  command_name    check_snmp
  command_line    $USER1$/check_snmp -H $HOSTADDRESS$ -C $ARG1$ -o $ARG2$ -w $ARG3$ -c $ARG4$
  }

Por lo tanto, el primer argumento será la community, el segundo el OID, el tercero el valor del warning y el último el valor del critical.

Creamos los servicios:

define service{
  use                   generic-service
  host_name             pfsense.empresa.com.ar
  service_description   TRAFICO IN - WAN
  check_command        check_snmp!p4ssw0rdSNMP!IF-MIB::ifTable.ifEntry.ifInOctets.1!150000000!140000000
  }

define service{
  use                   generic-service
  host_name             pfsense.empresa.com.ar
  service_description   TRAFICO OUT - WAN
  check_command        check_snmp!p4ssw0rdSNMP!IF-MIB::ifTable.ifEntry.ifOutOctets.1!150000000!140000000
  }

define service{
  use                  generic-service
  host_name            pfsense.empresa.com.ar
  service_description  INTERFACE STATUS - WAN
  check_command        check_snmp!p4ssw0rdSNMP!IF-MIB::ifTable.ifEntry.ifAdminStatus.1!1!1
  }

define service{
  use                  generic-service
  host_name            pfsense.empresa.com.ar
  service_description  PAQUETES BLOQUEADOS - WAN
  check_command    check_snmp!p4ssw0rdSNMP!SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.12.3!100000!90000
  }

define service{
  use                    generic-service
  host_name              pfsense.empresa.com.ar
  service_description    PAQUETES ACEPTADOS - WAN
  check_command    check_snmp!p4ssw0rdSNMP!SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.11.3!100000!90000
  }

Listo. Servicios Creados.

Gabriel Soltz