Análisis de una alerta SNMP de reinicio de firewall
Fecha: abril
del 2019 / febrero del 2021 (evento repetido con otro equipo diferente)
Escenario
Este escenario analiza una alerta
recibida (obviamente de noche) por el reload de un firewall
y en el cual justamente me encontraba
conectado por VPN para administrar otros equipos.
La pregunta del millón fue: vos
tocaste algo que el ASA se reinició ? el karma de la
profesión.
Este laboratorio analiza si
realmente se trató de un falso positivo y su causa, ya que el equipo
nunca se reinició ni dio alertas de
ningún tipo en el syslog.
Los nombres, las IP y otros datos se
cambiaron por confidencialidad.
1.- Alerta recibida:
From: zabbix@acme.com.ar
Date: mar., 19 de mar. de 2019 a la(s) 21:52
Subject: RECOVERY - ASA reloaded
To:
<administrador@acme.com.ar>
Trigger: ASA reloaded
Trigger status: OK
Trigger severity: Average
Item values:
1. sysUpTime (ASA:sysUpTime):
00:11:46 (esto es a las 22:00 Hs)
Original event ID: 28025529
2.- Verificación en el ASA:
ACME-FW# sh version
Cisco Adaptive Security Appliance
Software Version 8.4(7)30
Device Manager Version 7.5(2)153
Compiled on Mon 21-Dec-15 11:00 by
builders
System image file is
"disk0:/asa847-30-k8.bin"
Config file at boot was
"startup-config"
ACME-FW up 2 years 264 days
failover cluster up 2 years 264 days
Hardware: ASA5510, 1024 MB RAM, CPU Pentium 4 Celeron
1600 MHz
Internal ATA Compact Flash, 256MB
BIOS Flash M50FW016 @ 0xfff00000,
2048KB
---resumido---
This platform has an ASA 5510
Security Plus license.
Serial Number: JMX8537X1AS
Running Permanent Activation Key:
0xfa24c548 0xecda5e96 0xd020290c 0xae1484b8 0xcb1d3db4
Configuration register is 0x1
Configuration last modified by admin_fw
at 12:19:03.674 AR Wed Mar 20 2019
ACME-FW#
3.- Nueva verificación:
En la reunión técnica del día
posterior al supuesto reinicio del firewall se constata nuevamente el tiempo
de uptime del equipo, tanto por SNMP
como por CLI:
3.1.- Pruebas SNMP contra la OID sysuptime:
acmeadm@zabix:~$ snmpget -v2c -c acme_ro 192.168.1.254 .1.3.6.1.2.1.1.3.0
DISMAN-EVENT-MIB::sysUpTimeInstance
= Timeticks: (5416708) 15:02:47.08 (13:00 del día siguiente, 15 horas
desde las 21:42)
base 10: 5416708
base 16: 52A704
base 2 : 00000000010100101010011100000100
| |
32 23
3.2.- CLI en ASA:
ACME-FW# sh version | incl up
ACME-FW up 2 years 264 days (la verificación está
dentro de las 24 horas del falso positivo)
failover cluster up 2
years 265 days
ACME-FW#
4.- OID
.1.3.6.1.2.1.1.3.0 description:
iso(1) identified-organization(3)
dod(6) internet(1) mgmt(2) mib-2(1) system(1) sysUpTime(3)
sysUpTimeInstance(0)
Description: "sysUpTimeInstance"
Information: Automatically
extracted from IETF RFC 2982.
Fuente: http://www.oid-info.com/get/1.3.6.1.2.1.1.3.0
5.- Causa del falso
positivo:
sysUpTime is a 32-bit counter and will roll
over after 496 days.
But you can poll snmpEngineId
(.1.3.6.1.6.3.10.2.1.3) which returns the uptime in seconds and should not roll
over for 135 years
Fuente: www.cisco.com
6.- En resumen:
2 años y 264 días serían:
365+365+264=994 y 497+497=994, por lo tanto es la segunda vez que pasa…
También es discutible que dos años
sin reinicio son dos años sin actualizaciones :-/
7.- Pruebas SNMP en ASA 5545x:
Para verificar las diferencias de
versiones utilicé un ASA utilizado de honeypot y que lleva bastante tiempo UP
recopilando datos.
root@snmp:/home/snmptest/# snmpget -v2c -c public 10.0.0.5
.1.3.6.1.2.1.1.3.0
iso.3.6.1.2.1.1.3.0 = Timeticks: (4165033500) 482 days, 1:32:15.00
base 10: 4165033500
base 16: F8415E1C
base 2 : 11111000010000010101111000011100
(cuando todo esté en 1 comienza nuevamente por 0)
|
bit: 32
8.- Nueva verificación del 10 de abril:
root@snmp:/home/snmptest/# snmpget -v2c -c public 10.0.0.5
.1.3.6.1.2.1.1.3.0
iso.3.6.1.2.1.1.3.0 = Timeticks:
(4294092400) 497 days, 0:02:04.00
Podemos ver que el contador se va
llenando de 1:
9.- Nueva verificación del 11 de abril:
root@snmp:/home/snmptest/# snmpget -v2c -c public 10.0.0.5
.1.3.6.1.2.1.1.3.0
iso.3.6.1.2.1.1.3.0 = Timeticks:
(7881104) 21:53:31.04 (el día después el contador pasó por
0 y comenzó la cuenta)
10.- Pruebas con la OID “correcta”:
root@snmp:/home/snmptest/# snmpget -v2c -c public 10.0.0.5 .1.3.6.1.6.3.10.2.1.3 (recomendada por Cisco ver punto
4.)
iso.3.6.1.6.3.10.2.1.3 = No Such Instance currently exists at this OID (hasta el momento no pude realizarle un polling)
11.- Verificación en
la base de OID del ASA:
ASA-5545# sh snmp-server oid | incl 1.3.6.1.6.3.10.2.1.3
[956] 1.3.6.1.6.3.10.2.1.3. snmpEngineTime (la OID existe pero no la pude acceder, queda como tarea pendiente)
ASA-PM#
12.-
OID 1.3.6.1.6.3.10.2.1.3 description:
iso(1) identified-organization(3) dod(6) internet(1)
snmpV2(6) snmpModules(3) snmpFrameworkMIB(10)
snmpFrameworkMIBObjects(2)
snmpEngine(1) snmpEngineTime(3)
1.3.6.1.6.3.10.2.1.3
Description:
snmpEngineTime OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
UNITS
"seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of seconds since
the value of the snmpEngineBoots object last changed.
When incrementing this objects value would
cause it to exceed its maximum,snmpEngineBoots is
incremented as if are-initialization had
occurred, and thisobjects value consequently reverts to zero.
Information: Automatically extracted from RFC3411
Fuente: http://oid-info.com/get/1.3.6.1.6.3.10.2.1.3
(2019) Downtime is money
Rosario, Argentina