Avisando con Syslog…

Saber si algo anómalo ocurre en nuestra de red resulta de vital importancia para llevar a cabo una correcta administración de nuestra infraestructura. Estas anomalías pueden venir dadas por una gran cantidad de causas pero por citar algunas podríamos hablar de fallo  de una fuente de alimentación para equipos con redundancia eléctrica, reseteo imprevisto de un dispositivo, intentos de accesos fallidos, etc. etc. etc.

Para tener conocimiento de ello, los equipos de red pueden tener disponible el protocolo Syslog para que, en caso de producirse algún suceso digno de ser notificado, envíen un mensaje de registro a una estación central donde los procese una aplicación y podamos visualizarlo. Existen una gran variedad de herramientas bajo los acrónimos SIEM, SIM y SEM. Alguna de ellas pueden ser Kiwi Syslog Server o algunas con una gran variedad de otras funcionalidades entre las que se encuentran las del registro de estos mensajes como puede ser Cisco Prime Lan Management Solution (LMS).

Pues bien, entre una de mis tareas en mi actual cliente estaba la de configurar esta herramienta para que enviase por correo electrónico las alarmas que el conjunto de administradores creímos más relevantes. Para ello en primer lugar configuramos los equipos para habilitar este protocolo mediante los siguientes comandos

Router(config)#logging on 

Habilitamos syslog a nivel global del equipo

Router(config)#logging 192.168.10.53

Indicamos la IP del host donde se enviarán los mensajes.

Router(config)#logging trap x

Indicamos el nivel a un valor determinado entre 0 y 7. La tabla que figura a continuación establece los niveles configurables. Hay que tener en cuenta según el número que indicamos llevará implícito también los números superiores. Esto es, si elegimos el número 5, recibiremos también los mensajes del nivel 6  y 7.

0 Emergencia: el sistema está inutilizable
1 Alerta: se debe actuar inmediatamente
2 Crítico: condiciones críticas
3 Error: condiciones de error
4 Peligro: condiciones de peligro
5 Aviso: normal, pero condiciones notables
6 Información: mensajes informativos
7 Depuración: mensajes de bajo nivel

Por último: 

Router(config)#service timestamps log datetime

El mensaje llevará consigo una marca horaria.

Una vez configurada la aplicación Cisco Prime LMS con un servidor de correo, cuenta de usuario, dirección de envío, etc. estaría listo para recibir correos con el siguiente contenido:

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 10 23:17:53 switch-0001.dominiopruebas.net 2013 Feb 10

23:17:52 GMT +01:00 %SYS-2-PS_FAIL: Power supply 2 failed 

En este caso el mensaje nos dice que la fuente de alimentación (PS, Power Supply) número 2 del switch con nombre switch-001, ha fallado. El mensaje ha sucedido a las 23:17:52 y la aplicación ha mandado el correo a las 23:17:53, un segundo más tarde.  Cabe destacar que se trataba de un switch Cisco 6509-E que poseen dos fuentes de alimentación redundantes, vamos que no estamos hablando de un 2960…

Suponiendo  que a la mañana siguiente nos damos cuenta de ello y la cambiamos por otra nueva, recibiremos el siguiente:

Syslog message generated from device switch-0001: Feb 11 08:15:22 switch-0001.dominiopruebas.net 2013 Feb 11 08:15:21 GMT +01:00 %SYS-2-PS_OK: Power supply 2 okay

Como os habréis podido imaginar los datos horarios son falsos, en realidad lo que hice fue apagarla para ver si lo que había configurado iba bien.

Pero como mi mente es algo inquieta, pensé en lugar de simular una un fallo de hardware fuese víctima de un ataque, por ejemplo de un CAM overflow. Hay más información aqui.

Así que preparé mi Backtrack, configuré el switch  igual que otro cualquiera, lo conecté a la red y venga.

Eché mano de la aplicación macof. Macof lo que hace básicamente es generar tramas con direcciones MAC de origen aleatorias de tal manera que por cada trama que entre en el switch la incluirá en la tabla CAM. Al ser todas distintas la tabla CAM se irá llenando, hasta que al final se sature, porque obviamente la memoria tiene un límite. ¿Y qué pasa cuando eso ocurre? Pues que el switch podría comportarse como un hub. Aparte de ello, también lancé un ataque con THC Hydra similar a lque explico en mis entradas Mejorando acceso por SSH (Parte I) y Mejorando acceso por SSH (Parte II)

Vamos que entre el llenado de la memoria más la carga en la CPU… iba bien servido. Así que lo dejé. Pues bien al cabo de un par de minutos empecé a recibir los siguientes correos:

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001:: Feb 11 16:46:51 switch-0001.dominiopruebas.net 20: Feb 11 15:46:51: %PLATFORM-1-CRASHED: System previously crashed with the following message:

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 21: Feb 11 15:46:51: %PLATFORM-1-CRASHED: Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 12.2(50)SE5, RELEASE SOFTWARE (fc1)

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 22: Feb 11 15:46:51: %PLATFORM-1-CRASHED: Technical Support: http://www.cisco.com/techsupport

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 23: Feb 11 15:46:51: %PLATFORM-1-CRASHED: Copyright (c) 1986-2010 by Cisco Systems, Inc.

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 24: Feb 11 15:46:51: %PLATFORM-1-CRASHED: Compiled Tue 28-Sep-10 13:44 by prod_rel_team 

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 25: Feb 11 15:46:51: %PLATFORM-1-CRASHED:  

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 26: Feb 11 15:46:51: %PLATFORM-1-CRASHED: Debug Exception (Could be NULL pointer dereference) Exception (0x2000)!

Mensaje generado automáticamente por la aplicación Cisco LMS

Syslog message generated from device switch-0001: Feb 11 16:46:51 switch-0001.dominiopruebas.net 28: Feb 11 15:46:51: %PLATFORM-1-CRASHED: SRR0 = 0x010469F0  SRR1 = 0x00029230  SRR2 = 0x006548A4  SRR3 = 0x00021000

Resultan claras las palabras %PLATFORM-1-CRASHED: Luego el equipo se reinició y como el ataque continuaba pues vuelta a empezar, y a los dos minutos ¡catapum!, otra vez reinicio y así hasta parar.

Como vemos resultan muy útiles estos protocolos. La verdad que la herramienta de Cisco que pongo como ejemplo es una maravilla, como maravilla es lo que cuesta su licencia. La verdad que para la red que administramos es muy necesaria y el gasto se justifica, no tanto en otros entornos más pequeños. En cualquier caso lo que pretendo hacer ver es los mecanismos de los que podemos disponer para estar avisados en el caso de que algo raro suceda.

Espero haya sido interesante.

Un saludo, seguiremos informando

Deja un comentario