Análisis de una alerta SNMP de reinicio de firewall

Fecha: abril del 2019

 

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