Real Life Netwok Security

      No Comments on Real Life Netwok Security

Real Life Netwok Security : Atacados desde la zona “SEGURA”

CCNP Security: Escenarios reales

Hace un par de días se presento el siguiente escenario, un cliente llama diciendo que tiene perdidas constantes de conexión y en su revisión rápida pudo notar que los 2 Firewall se encontraban en modo activo, así que por deducción dije con un simple “no failover active” en el equipo standby se resolverá este problema, y como se lo imaginan no fue así.

RED-FW-ATTACK

 

Síntomas:

  • Tráfico intermitente.
  • Failover con errores.
  • Utilización de CPU alto.
  • Memoria al 80%.

 

Tareas realizadas:

Primero que todo se procede a revisar el estado failover de los equipos, encontrando que ambos están como activos, procedo con la ejecución del comando mencionado, para poder revisar la sincronización,  el resultado FAIL, debido a que el Failover presenta errores en sincronización por falta de memoria, se procede a dejar en línea solo 1 de estos. Ahora los Ping desde el ASA hacia Switch de Core, y Default Gateway, ambos con resultados de pérdidas. Se verifica los procesos que están siendo consumidos por el procesador encontrando que el proceso “Dispatch Unit” el cual es el proceso central de procesamiento de paquetes es el que ocupa el 99% de los recursos.

ciscoasa# show processes cpu-usage non-zero sorted

PC         Thread       5Sec     1Min     5Min   Process

0x0827e731   0xc85c5bf4     99.0%     99.3%     99.3%   Dispatch Unit

 

Se procede con apagar la interface inside, y volver a ejecutar el comando anterior, llegando a la conclusión de que el problema llega desde la LAN, ya que el Output mostrado por este es totalmente contrario al anterior indicando que el procesador ocupa un 5%, se vuelve a encender la interface. Con esto en mente realizo una captura de tráfico de la inside con destino outside con el comando “capture”, el cual muestra conexiones e intentos de la misma hacia la IP (118.69.169.124), por ende se procede con el bloqueo de la IP con una ACL en la interface inside, lo cual no presente ninguna mejora 🙁 . Se procede con la creación de una ACL en el Switch de CORE denegando la IP mencionada anteriormente y permitiendo todo lo demás en la VLAN que conecta el CORE con el ASA, los resultados son los esperados :D, el nivel de procesamiento en el ASA es reducido notoriamente, por ende queda identificar la causa del problema. Se realiza una captura en el Switch de CORE el cual nos muestra lo siguiente:

WS-ATTACK

 

WS-ATTACK-2

 

Por ende la tarea es buscar la MAC de origen (C4:64:13:54:13:B8), sin embargo al recorrer todos los Switch mostrados en la topología, cada uno indica que aprende la MAC por su interface que conecta a la MPLS, entonces nos preguntamos ¿Acaso el proveedor tendrá equipos contaminados?

Comandos ejecutados para verificación:

  • Show memory : verificar estado de memoria
  • Show cpu usage : verificar estado de cpu
  • Show processes cpu-usage non-zero sorted : verificar que proceso es ocupado de forma ordenada
  • Show run threat-detection : verificar la configuracion de theat-detection
  • Show service-policy global : verificar las inspecciones globales
  • Show interface | in errors : verificar errores de interfaces
  • Show interface : verificar interfaces
  • Show conn count : verificar la cantidad de conexiones existentes
  • Show conn | in SaAB : verificar si existen conexiones embrionicas
  • Show xlate count : verificar el numero de traducciones (NAT)
  • Show asp drop : verificar de forma rápida los paquetes o conexiones perdidos

Bueno estimados, espero este post haya sido de su interés y  les pueda ayudar si alguna vez se encuentran en una situación similar y puedan resolver el tema en un menor tiempo, ya que por mi lado, fueron hartas horas, cada día se aprende algo nuevo :D.

Saludos,