Habitualmente, solemos monitorizar sucesos en routers (en este caso C1800) mediante traps snmp o agentes que procesan el log y tras evaluarlo, generan acciones. Cisco IOS Embedded Event Manager (EEM) nos da la posibilidad de definir acciones a eventos concretos generados en el sistema.
Por ejemplo, si usamos syslog para detectar accesos privilegiados a un router, tendríamos que tener un script que procese en tiempo real cada línea de log para buscar una cadena similar a “Privilege level set to 15 by“. Una vez detectada, un agente podría abrirnos una alerta en nuestro sistema de monitorización indicando del acceso privilegiado al router.
Una alternativa posible sería definirnos en EEM una entrada que recoja la información del susbsistema syslog y lance una acción al detectar un patrón concreto, en este caso el acceso privilegiado, por ejemplo enviar un trap SNMP o un correo electrónico de aviso.
Entraremos en detalle de EEM más adelante, no obstante, vamos a ver un ejemplo más práctico donde podríamos usar o no EEM. Por ejemplo, queremos disponer de un sistema automático para almacenar de forma periódica la configuración de nuestro router. Para abordar esta tarea, ahora mismo se me ocurren varias soluciones (quizás hay más que desconozco), por ejemplo:
- Disponer de un script externo que obtiene la configuracion del sistema y la almacena en un fichero de forma periódica. Esto es bastante fácil de hacer, ya sea haciendo nosotros mismos el script, por ejemplo con expect o las librerias de Cisco de Perl, o con aplicaciones ya creadas como Rancid.
- Usar el comando archive para guardar una copia de la configuración:
S2router(config)#archive S2router(config-archive)# path flash:COPIA.txt S2router(config-archive)# time-period 1 S2router(config-archive)# write-memory S2router(config-archive)# exit
Una vez configurado, comienza a guardar copias cada minuto:
S2router#show archive
There are currently 1 archive configurations saved.
The next archive file will be named flash:COPIA.txt-1
Archive # Name
0
1 flash:COPIA.txt-1
2 flash:COPIA.txt-2
3 flash:COPIA.txt-3
4 flash:COPIA.txt-4
S2router#dir
Directory of flash:/
1 -rw- 18716748 Dec 16 2008 08:40:28 +00:00 c1841-advsecurityk9-mz.12n
2 -rw- 2746 Dec 16 2008 08:55:52 +00:00 sdmconfig-18xx.cfg
3 -rw- 931840 Dec 16 2008 08:56:14 +00:00 es.tar
4 -rw- 1505280 Dec 16 2008 08:56:36 +00:00 common.tar
5 -rw- 1038 Dec 16 2008 08:56:54 +00:00 home.shtml
6 -rw- 112640 Dec 16 2008 08:57:12 +00:00 home.tar
7 -rw- 527849 Dec 16 2008 08:57:30 +00:00 128MB.sdf
8 -rw- 21169140 May 26 2010 18:20:18 +00:00 c1841-advsecurityk9-mz.12n
9 -rw- 5638 Dec 27 2013 15:58:54 +00:00 COPIA.txt-1
10 -rw- 5638 Dec 27 2013 15:59:52 +00:00 COPIA.txt-2
11 -rw- 5615 Dec 27 2013 16:00:36 +00:00 COPIA.txt-3
12 -rw- 5615 Dec 27 2013 16:00:52 +00:00 COPIA.txt-4
- Disponer de una tarea periódica configurada en el router para volcar la configuración a un sitio remoto por ejemplo por TFTP o guardarla en flash (que es lo que vamos a hacer). Tenemos que tener en cuenta que cuando ejecutamos algunos comandos, el sistema nos solicita confirmación del mismo, por lo que para automatizar tareas y evitar esto, tendremos que usar el comando file prompt quiet, ya sea en modo de configuración global, o en cada tarea activándolo y desactivándolo. Para tareas periódicas, IOS dispone de un scheduler (kron) donde podríamos configurar lo siguiente:
-
1. Creamos una policy-list de kron especificando las acciones a llevar a cabo:
S2router(config)# kron policy-list copia
S2router(config-kron-policy)# cli copy running-config flash:copia.txt
S2router(config-kron-policy)# exit
2. Creamos una entrada en kron indicando la frecuencia de ejecución, por ejemplo cada minuto:
S2router(config)# kron occurrence copia in 00:01 recurring
S2router(config-kron-occurrence)#policy-list copia
3. Verificamos que la tarea esta en ejecución y cuando finaliza, tenemos nuestra copia almacenada en flash:
S2router#show kron schedule
Kron Occurrence Schedule
copia inactive, will run again in 0 days 00:00:45
S2router#dir
Directory of flash:/
1 -rw- 18716748 Dec 16 2008 08:40:28 +00:00 c1841-advsecurityk9-mz.12n
2 -rw- 2746 Dec 16 2008 08:55:52 +00:00 sdmconfig-18xx.cfg
3 -rw- 931840 Dec 16 2008 08:56:14 +00:00 es.tar
4 -rw- 1505280 Dec 16 2008 08:56:36 +00:00 common.tar
5 -rw- 1038 Dec 16 2008 08:56:54 +00:00 home.shtml
6 -rw- 112640 Dec 16 2008 08:57:12 +00:00 home.tar
7 -rw- 527849 Dec 16 2008 08:57:30 +00:00 128MB.sdf
8 -rw- 5702 Dec 27 2013 10:21:18 +00:00 copia.txt
Las situaciones vistas, implican que de forma periódica vamos almacenando las copias de seguridad, no obstante, en muchas ocasiones la configuración no cambia tanto como para requerir de la misma copia de seguridad todos los días, y menos si la copia se almacena en local, por lo que lo ideal sería disponer al menos de una copia cuando un administrador entra al sistema (aunque no realice ningún cambio). Es aquí donde podemos usar Cisco IOS EEM.
Cisco IOS Embedded Event Manager (EEM) es un sistema de Cisco IOS que permite recolectar datos de distintos subsistemas y llevar a cabo acciones, de forma que mediante la automonitorización reduce la necesidad de hacer polling al dispositivo y por lo tanto, podría reducir el ancho de banda usado por un NMS.
Su arquitectura es sencilla y consta de tres componentes:
- Event detectors: recolectan información de los distintos subsistemas de IOS, como registros de syslog, comandos CLI, variables SNMP, registros Netflow, eventos de Routing, etc.
- EEM Server: el sistema central que recibe la información, la procesa, y lanza una o varias acciones.
- Policies: secuencias de comandos almacenados en memoria llamados applets o también scripts TCL definidos por el administrador.
Con EEM podemos generar copias periódicas por el vencimiento de timers o eventos de kron de forma similar a los vistos anteriormente, pero al darnos la potencia de poder detectar eventos y generar acciones concretas, podríamos hacer copias de seguridad únicamente cuando se detecte un acceso privilegiado al sistema. Vamos a verlo tanto con applets y acciones como con un script TCL.
Lo primero que debemos hacer es crear el applet:
S2router(config)# event manager applet ACCESOS
A continuación, seleccionamos el patrón que buscamos dentro del susbistema syslog:
S2router(config-applet)# event syslog pattern "Privilege level set to 15 by"
Finalmente, indicamos las acciones a llevar a cabo cuando se detecta el patrón anterior. Estas serán por ejemplo registrar el acceso en el log (aparecerá en consola si lo tenemos configurado así) y realizar una copia de seguridad en flash:
S2router(config-applet)# action 1.0 cli syslog priority debugging msg "ACCESO PRIVILEGIADO" S2router(config-applet)# action 2.0 cli command "enable" S2router(config-applet)# action 3.0 cli command "copy running-config flash:backup.txt" S2router(config-applet)# action 4.0 cli command "exit"
Una vez creado, lo vemos registrado correctamente:
S2router# show event manager policy registered
No. Class Type Event Type Trap Time Registered Name
1 applet system syslog Off Fri Dec 27 10:24:51 2013 ACCESOS
pattern {Privilege level set to 15 by}
action 1.0 syslog priority debugging msg "ACCESO PRIVILEGIADO"
action 2.0 cli command "enable"
action 3.0 cli command "copy running-config flash:backup.txt"
action 4.0 cli command "exit"
De forma que cuando accedemos por SSH, en la consola del sistema podríamos ver el mensaje anterior:
*Dec 27 10:27:31.643: %SYS-5-PRIV_AUTH_PASS: Privilege level set to 15 by jose ) *Dec 27 10:27:31.651: %HA_EM-7-LOG: ACCESOS: ACCESO PRIVILEGIADO
Y comprobar que disponemos de la copia correcta almacenada en flash:
S2router#dir
Directory of flash:/
1 -rw- 18716748 Dec 16 2008 08:40:28 +00:00 c1841-advsecurityk9-mz.12n
2 -rw- 2746 Dec 16 2008 08:55:52 +00:00 sdmconfig-18xx.cfg
3 -rw- 931840 Dec 16 2008 08:56:14 +00:00 es.tar
4 -rw- 1505280 Dec 16 2008 08:56:36 +00:00 common.tar
5 -rw- 1038 Dec 16 2008 08:56:54 +00:00 home.shtml
6 -rw- 112640 Dec 16 2008 08:57:12 +00:00 home.tar
7 -rw- 527849 Dec 16 2008 08:57:30 +00:00 128MB.sdf
8 -rw- 5644 Dec 27 2013 10:27:32 +00:00 backup.txt
9 -rw- 5702 Dec 27 2013 10:21:18 +00:00 copia.txt
Con esto, ya disponemos de una copia de seguridad previa a los posibles cambios del administrador (lo mejor sería copiarla también a un sitio remoto). Lógicamente, si volvemos a entrar los cambios se perderán, pero podríamos disponer de variables de entorno definidas (show event manager environment) y guardar las copias con distintos nombres en base a la fecha de acceso. También podríamos enviar un correo electrónico o generar un trap SNMP para notificar del acceso.
En unos días la segunda parte con más opciones en EEM.
