Cisco Accelerated Security Path

2 de diciembre de 2011 Por

Recientemente he tenido que volver a repasar parte del funcionamiento del Adaptive Security Algorithm de Cisco. De manera breve, este algoritmo es el encargado de inspeccionar el tráfico y permitir o denegarlo basándose en las políticas existentes.

A grandes rasgos, cuando una conexión llega al sistema, es procesada mediante el Session Management Path, quien se encarga de comprobar la tabla de rutas y NAT y las listas de control de acceso, de forma que si la política definida permite el tráfico, se crea una nueva entrada en la tabla de estados mediante el Fast Path, que es el encargado de revisar las cabeceras 3 y 4, comprobar el checksum IP, números de secuencia TCP, etc. El resto de paquetes de la conexión ya establecida son enviados directamente al Fast Path. La conjunción del Session Management Path y del Fast Path es lo que se conoce como Accelerated Security Path (ASP).

El problema por el cual he tenido que volver a revisar este funcionamiento ha venido provocado por un sistema Cisco ASA que denegaba paquetes de conexiones permitidas por la política de control de acceso del propio firewall, por lo que los contadores de ASP podrí­an aportarme más información sobre lo que estaba sucediendo en el sistema.

ASA# show  asp drop 
Frame drop:  
    No route to host (no-route)                                                  2  
    Flow is denied by configured rule (acl-drop)                               101  
    NAT-T keepalive message (natt-keepalive)                                     4  
    First TCP packet not SYN (tcp-not-syn)                                      29  
    Bad TCP flags (bad-tcp-flags)                                                8  
    TCP failed 3 way handshake (tcp-3whs-failed)                                 3  
    TCP RST/FIN out of order (tcp-rstfin-ooo)                                    7  
    ICMP Error Inspect no existing conn (inspect-icmp-error-no-existing-conn)    9  
    FP L2 rule drop (l2_acl)                                                    30
Last clearing: 09:49:26 CEST Nov 24 2011 by enable_15

Como se puede ver, se están filtrando paquetes no solo por la propia polí­tica de control de acceso, sino también por problemas de enrutamiento o inconsistencias en el protocolo TCP (si queremos capturar este tráfico, podemos hacerlo mediante el comando capture CAPTURA type asp-drop OPCION). Para intentar mitigar alguna de estas inconsistencias en el protocolo TCP, podemos seguir los siguientes pasos:

1. Configuramos un tcp-map para inspeccionar y normalizar las conexiones TCP de forma que basándonos en ciertas características del protocolo podemos permitir o denegar las conexiones; dentro de estas opciones podemos encontrar entre otras:

  • Verificación el checksum a nivel TCP
  • Paquetes que exceden el tamaño máximo de segmento
  • Paquetes con ACK inválidos

    • Paquetes fuera de orden

  • Paquetes SYN con datos (o SYN-ACK)
  • Opciones activadas a nivel de cabecera TCP

2. Configuramos un class-map para identificar el tráfico que queremos inspeccionar.

3. Creamos un policy-map donde asociamos el class-map con el tcp-map creado mediante las opciones avanzadas.

4. Finalmente, creamos un service-policy para asociar el policy-map a la interfaz que queremos inspeccionar.

Como hemos visto, aunque lo habitual es que el tráfico se deniegue por la propia polí­tica, existen otras opciones que también pueden filtrar conexiones (antispoofing, inspección de tráfico, IPS,..) las cuales pueden estar configuradas por defecto en el sistema, por lo que es esencial disponer de un buen sistema de log que nos dé pistas de que esta sucediendo en el sistema, preferiblemente de forma automatizada buscando ciertos patrones en tiempo real, sin tener que llevar a cabo una revisión periódica por parte del administrador.

Es todo por hoy. La semana que viene introduciré el framework VERIS (Verizon Enterprise Risk and Incident Sharing), utilizado para algo tan necesario (y probablemente tan escaso) como es compartir información sobre incidentes de seguridad. Pasen un buen fin de semana y cojan o no puente (para aquellos que nos siguen desde fuera de España, el martes y el jueves que viene son festivos nacionales), les estaremos esperando.