ISE versión 1.3 integración de pxGrid con la aplicación IPS pxLog

Introducción

Identity Services Engine (ISE) versión 1.3 admite una nueva API llamada pxGrid. Este protocolo moderno y flexible que admite autenticación, cifrado y privilegios (grupos) permite una fácil integración con otras soluciones de seguridad. Este documento describe el uso de la aplicación pxLog que se ha escrito como prueba de concepto. pxLog puede recibir mensajes syslog del Sistema de prevención de intrusiones (IPS) y enviar mensajes pxGrid al ISE para poner en cuarentena al atacante. Como resultado, ISE utiliza el cambio de autorización (CoA) de RADIUS para cambiar el estado de autorización del terminal que limita el acceso a la red. Todo esto sucede de forma transparente para el usuario final.

En este ejemplo, se ha utilizado Snort como IPS, pero se podría utilizar cualquier otra solución. En realidad no tiene que ser un IPS. Todo lo que se requiere es enviar el mensaje syslog a pxLog con la dirección IP del atacante. Esto crea la posibilidad de integrar un gran número de soluciones.

Este documento también presenta cómo resolver problemas y probar las soluciones pxGrid, con los problemas y limitaciones típicos.

Renuncia: Cisco no admite la aplicación pxLog. Este artículo ha sido escrito como una prueba de concepto. El objetivo principal era utilizarlo durante las pruebas de superación de la implementación de pxGrid en ISE.

Prerequisites

Requirements

Cisco recomienda tener experiencia en configuración de Cisco ISE y conocimientos básicos en estos temas:

• Implementaciones de ISE y configuración de autorización
• Configuración CLI de los switches Cisco Catalyst

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• Microsoft Windows 7
• Software de switch Catalyst de Cisco serie 3750X, versiones 15.0 y posteriores
• Software Cisco ISE, versiones 1.3 y posteriores
• Cisco AnyConnect Mobile Security con Network Access Manager (NAM), versión 3.1 y posteriores
• Snort versión 2.9.6 con adquisición de datos (DAQ)
• Aplicación pxLog Instalada en Tomcat 7 con MySQL Versión 5

Diagrama de red y flujo de tráfico

Este es el flujo de tráfico, como se ilustra en el diagrama de red:

1. Un usuario de Microsoft Windows 7 se conecta al switch y realiza la autenticación 802.1x.
   
   
2. El switch utiliza ISE como servidor de autenticación, autorización y contabilidad (AAA). La regla de autorización Dot1x Full Access coincide y se concede acceso completo a la red (DACL: PERMIT_ALL).
   
   
3. El usuario intenta conectarse con la red de confianza e infringe la regla Snort.
   
   
4. Como resultado, Snort envía una alerta a la aplicación pxLog (a través de syslog).
   
   
5. La aplicación pxLog realiza la verificación en su base de datos local. Se configura para capturar los mensajes de syslog enviados por Snort y extraer la dirección IP del atacante. A continuación, utiliza pxGrid para enviar una solicitud al ISE con el fin de poner en cuarentena la dirección IP del atacante (el ISE es un controlador pxGrid).
   
   
6. ISE vuelve a evaluar su política de autorización. Debido a que el terminal está en cuarentena, se cumple la condición Session:EPStatus EQUALS Quarantine y se coincide con un perfil de autorización diferente (Dot1x Quarantine). ISE envía una terminación de CoA al switch para finalizar la sesión. Esto activa la reautenticación y se aplica una nueva ACL descargable (DACL) (PERMIT_ICMP), que proporciona el acceso de red limitado al usuario final.
   
   
7. En esta etapa, el administrador puede decidir dejar de poner en cuarentena el punto final. Esto se puede lograr a través de la GUI de pxLog. De nuevo, se envía el mensaje de pxGrid hacia ISE.
   
   
8. ISE realiza una operación similar a la del paso 6. Esta vez, el terminal ya no se pone en cuarentena y se proporciona acceso completo.

pxLog

Arquitectura

La solución es instalar un conjunto de aplicaciones en una máquina Linux:

1. La aplicación pxLog escrita en Java e implementada en el servidor Tomcat. Dicha solicitud consta de:
   
   
   • Servlet que procesa las solicitudes web: se utiliza para acceder al panel administrativo a través del navegador web.
     
     
   • Módulo Enforcer: subproceso que se inicia junto con el servlet. Enforcer lee los mensajes de syslog del archivo (optimizado), procesa esos mensajes según las reglas configuradas y ejecuta acciones (como poner en cuarentena a través de pxGrid).
     
     
   
   
   
2. La base de datos MySQL que contiene la configuración para pxLog (reglas y registros).
   
   
3. El servidor syslog que recibe mensajes syslog de sistemas externos y los escribe en un archivo.

Instalación

La aplicación pxLog utiliza estas bibliotecas:

• jQuery (para compatibilidad con AJAX)
• JavaServer Pages Standard Tag Library (JSTL) (modelo de controlador de vista de modelo (MVC), los datos están separados de la lógica: el código de JavaServer Page (JSP) se utiliza sólo para procesar, no hay código HTML en las clases Java)
• Log4j como subsistema de registro
• conector MySQL
• displaytag para procesar/ordenar tablas
• API pxGrid de Cisco (actualmente versión alfa 147)

Todas estas bibliotecas ya están en el directorio lib del proyecto, por lo que no es necesario descargar más archivos Java ARchive (JAR).

Para instalar la aplicación:

1. Desempaquetar todo el directorio en el directorio Webapp de Tomcat.
   
   
2. Edite el archivo WEB-INF/web.xml. El único cambio necesario es la variable serverip, que debe apuntar a ISE. También se pueden generar los almacenes de claves de certificados Java (uno para la confianza y otro para la identidad) (en lugar del valor predeterminado). Esto es utilizado por la API pxGrid que utiliza la sesión de Secure Sockets Layer (SSL) con los certificados de cliente y de servidor. Ambos lados de la comunicación deben presentar el certificado y deben confiar el uno en el otro. Consulte la sección Requisitos del Protocolo pxGrid para obtener más información.
   
   
3. Asegúrese de que el nombre de host de ISE se resuelva correctamente en pxLog (consulte el registro en la entrada Domain Name Server (DNS) o/etc/hosts). Consulte la sección Requisitos del Protocolo pxGrid para obtener más información.
   
   
4. Configure la base de datos MySQL con el script mysql/init.sql. Las credenciales se pueden cambiar, pero deben reflejarse en el archivo WEB-INF/web.xml.

Snort

Este artículo no se centra en ningún IPS específico, por lo que solo se proporciona una breve explicación.

Snort se configura en línea con compatibilidad con DAQ. El tráfico se redirige con iptables:

iptables -I FORWARD -j ACCEPT
iptables -I FORWARD -j NFQUEUE --queue-num 1

Luego, después de la inspección, se inyecta y se reenvía según las reglas iptable predeterminadas.

Se han configurado algunas reglas de Snort personalizadas (el archivo /etc/snort/rules/test.rules se incluye en la configuración global).

alert icmp any any -> any any (itype:8; dsize:666<>686; sid:100122)
alert icmp any any -> any any (itype:8; ttl: 6; sid:100124)

Snort envía un mensaje de syslog cuando el tiempo de vida (TTL) del paquete es igual a 6 o el tamaño de la carga útil está entre 666 y 686. Snort no bloquea el tráfico.

También deben configurarse umbrales para asegurarse de que las alertas no se activan con demasiada frecuencia (/etc/snort/threshold.conf):

event_filter gen_id 1, sig_id 100122, type limit, track by_src, count 1, seconds 60
event_filter gen_id 1, sig_id 100124, type limit, track by_src, count 1, seconds 60

Luego, el servidor syslog apunta a la máquina pxLog (/etc/snort/snort.conf):

output alert_syslog: host=10.222.0.61:514, LOG_AUTH LOG_ALER

Para algunas versiones de Snort, hay errores relacionados con la configuración de syslog y, a continuación, se pueden utilizar los valores predeterminados que apuntan al host local y se puede configurar syslog-ng para reenviar mensajes específicos al host pxLog.

ISE

Configuración

Persona y certificado

1. Habilite el rol pxGrid, que está deshabilitado en ISE de forma predeterminada, en Administración > Implementación:
   
   

   

   
   
   
2. Verifique si los certificados se utilizan para pxGrid en Administration > Certificates > System Certificates:
   
   

   

Servicio de protección de terminales (EPS)

El EPS debe estar habilitado (deshabilitado de forma predeterminada) en Administration > Settings:

Esto le permite utilizar la funcionalidad de cuarentena/unquarantine.

Reglas de autorización

La primera regla se encuentra sólo cuando el punto final se pone en cuarentena. A continuación, el acceso limitado se aplica dinámicamente mediante RADIUS CoA. El switch también debe agregarse a los dispositivos de red con el secreto compartido correcto.

Troubleshoot

El estado de pxGrid se puede verificar con la CLI:

lise/admin# show application status ise

ISE PROCESS NAME                       STATE            PROCESS ID  
--------------------------------------------------------------------
Database Listener                      running          6717        
Database Server                        running          51 PROCESSES
Application Server                     running          9486        
Profiler Database                      running          7804        
AD Connector                           running          10058       
M&T Session Database                   running          7718        
M&T Log Collector                      running          9752        
M&T Log Processor                      running          9712        
Certificate Authority Service          running          9663        
pxGrid Infrastructure Service          running          14979       
pxGrid Publisher Subscriber Service    running          15281       
pxGrid Connection Manager              running          15248       
pxGrid Controller                      running          15089       
Identity Mapping Service               running          9962        

También hay depuraciones independientes para pxGrid (Administration > Logging > Debug Log Configuration > pxGrid). Los archivos de depuración se almacenan en el directorio pxGrid. Los datos más importantes se encuentran en pxgrid/pxgrid-jabberd.log y en pxgrid/pxgrid-controller.log.

Prueba

Paso 1. Registro para pxGrid

La aplicación pxLog se implementa automáticamente cuando se inicia Tomcat.

1. Para utilizar pxGrid, registre dos usuarios en ISE (uno con acceso a la sesión y otro con cuarentena). Esto se puede completar desde Operaciones de Pxgrid > Registrar usuarios:
   
   

   

   
   
   El registro se inicia automáticamente:
   
   

   

   
   
   
2. En esta etapa, es necesario aprobar a los usuarios registrados en ISE (la aprobación automática está deshabilitada de forma predeterminada):
   
   

   

   
   
   Después de la aprobación, pxLog notifica automáticamente al administrador (a través de una llamada AJAX):
   
   

   

   
   
   ISE muestra el estado de esos dos usuarios como En línea o Sin conexión (ya no pendiente).

Paso 2. Configuración de reglas pxLog

pxLog debe procesar los mensajes de syslog y ejecutar acciones basadas en él. Para agregar una nueva regla, seleccione Manage Rules:

Ahora el módulo de aplicación busca esta expresión regular (RegExp) en el mensaje de syslog: "snort[". Si se encuentra, busca en todas las direcciones IP y selecciona la anterior a la última. Esto se adapta a la mayoría de soluciones de seguridad. Consulte la sección Syslog para obtener más información. Esa dirección IP (atacante) se pone en cuarentena mediante pxGrid. También se podría utilizar una regla más granular (por ejemplo, podría incluir el número de firma).

Paso 3. Primera sesión Dot1x

La estación de Microsoft Windows 7 inicia una sesión dot1x con cable. Cisco Anyconnect NAM se ha utilizado como solicitante. Se configura el método EAP-PEAP protegido por protocolo de autenticación extensible (EAP-PEAP).

El perfil de autorización de acceso completo Dot1x de ISE está seleccionado. El switch descarga la lista de acceso para otorgar acceso completo:

3750#show authentication sessions interface g0/17   
            Interface:  GigabitEthernet0/17
          MAC Address:  0050.b611.ed31
           IP Address:  10.221.0.240
            User-Name:  cisco
               Status:  Authz Success
               Domain:  DATA
      Security Policy:  Should Secure
      Security Status:  Unsecure
       Oper host mode:  single-host
     Oper control dir:  both
        Authorized By:  Authentication Server
          Vlan Policy:  N/A
              ACS ACL:  xACSACLx-IP-PERMIT_ALL-53fc9dbe
      Session timeout:  N/A
         Idle timeout:  N/A
    Common Session ID:  0A01000C000037E6BAB267CF
      Acct Session ID:  0x00003A70
               Handle:  0xA100080E

Runnable methods list:
       Method   State
       dot1x    Authc Success

3750#show ip access-lists interface g0/17
     permit ip any any

Paso 4. El PC con Microsoft Windows envía el paquete que dispara la alarma

Esto muestra lo que sucede si envía desde un paquete de Microsoft Windows con TTL = 7:

c:\> ping 10.222.0.61 -i 7 -n 1

Ese valor disminuye en Snort en la cadena de reenvío y se activa una alarma. Como resultado, se envía un mensaje de syslog hacia pxLog:

Sep  6 22:10:31 snort snort[6310]: [1:100124:0] ALERT {ICMP} 10.221.0.240 ->
10.222.0.61

Paso 5. pxLog

El pxLog recibe el mensaje de syslog, lo procesa y solicita poner en cuarentena esa dirección IP. Esto puede confirmarse si comprueba los registros:

Paso 6. Cuarentena de ISE

ISE informa de que la dirección IP se ha puesto en cuarentena:

Como resultado, revisa la política de autorización, elige la cuarentena y envía RADIUS CoA para actualizar el estado de autorización en el switch para ese terminal específico.

Este es el mensaje de finalización de CoA que obliga al solicitante a iniciar una nueva sesión y obtener acceso limitado (Permit_ICMP):

El resultado se puede confirmar en el switch (acceso limitado para el terminal):

3750#show authentication sessions interface g0/17 
            Interface:  GigabitEthernet0/17
          MAC Address:  0050.b611.ed31
           IP Address:  10.221.0.240
            User-Name:  cisco
               Status:  Authz Success
               Domain:  DATA
      Security Policy:  Should Secure
      Security Status:  Unsecure
       Oper host mode:  single-host
     Oper control dir:  both
        Authorized By:  Authentication Server
          Vlan Policy:  N/A
              ACS ACL:  xACSACLx-IP-PERMIT_ICMP-53fc9dc5
      Session timeout:  N/A
         Idle timeout:  N/A
    Common Session ID:  0A01000C000037E7BAB7D68C
      Acct Session ID:  0x00003A71
               Handle:  0xE000080F

Runnable methods list:
       Method   State
       dot1x    Authc Success

3750#show ip access-lists interface g0/17         
     permit icmp any any

Paso 7. pxLog Unquarantine

En esta etapa, el administrador decide dejar de poner en cuarentena ese punto final:

La misma operación se puede ejecutar directamente desde ISE:

Paso 8. ISE sin cuarentena

ISE vuelve a revisar las reglas y actualiza el estado de autorización del switch (se concede acceso completo a la red):

El informe confirma:

Funcionalidad pxLog

La aplicación pxLog se ha escrito para demostrar la funcionalidad de la API pxGrid. Le permite lo siguiente:

• Registro de sesiones y usuarios de EPS en ISE
• Descargar información sobre todas las sesiones activas en ISE
• Descargar información sobre una sesión activa específica en ISE (por dirección IP)
• Descargar información sobre un usuario activo específico en ISE (por nombre de usuario)
• Mostrar la información sobre todos los perfiles (generador de perfiles)
• Mostrar la información sobre las etiquetas de grupos de seguridad (SGT) de TrustSec definidas en ISE
• Comprobar versión (capacidades de pxGrid)
• Cuarentena basada en la dirección IP o MAC
• Dejar de poner en cuarentena según la dirección IP o MAC

Se prevé ampliar la funcionalidad en el futuro.

Aquí hay algunas capturas de pantalla de ejemplo de pxLog:

Requisitos del protocolo pxGrid

Grupos

El cliente (usuario) puede ser miembro de un grupo a la vez. Los dos grupos más utilizados son:

• Sesión: se utiliza para examinar/descargar información sobre sesiones/perfiles/SGT.
• EPS: se utiliza para ejecutar la cuarentena

Certificados y Java KeyStore

Como se ha mencionado anteriormente, ambas aplicaciones cliente, pxLog y el controlador pxGrid (ISE), deben tener certificados configurados para comunicarse. La aplicación pxLog mantiene los archivos en los archivos KeyStore de Java:

• store/client.jks: incluye el cliente y los certificados de la autoridad certificadora (CA)
• store/root.jks: incluye la cadena ISE: identidad del nodo de supervisión y solución de problemas (MnT) y el certificado de CA.

Los archivos están protegidos por contraseña (valor predeterminado: cisco123). La ubicación y las contraseñas de los archivos se pueden cambiar en WEB-INF/web.xml.

Estos son los pasos para generar un nuevo Java KeyStore:

1. Para crear un almacén de claves raíz (de confianza), importe el certificado de CA (cert-ca.der debe tener el formato DER):
   
   

   pxgrid store # keytool -import -alias ca -keystore root.jks -file cert-ca.der

   
   
   
2. Cuando cree un nuevo almacén de claves, elija una contraseña, que se utilizará más adelante para acceder al almacén de claves.
   
   
3. Importe el certificado de identidad MnT en el almacén de claves raíz (cert-mnt.der es el certificado de identidad tomado de ISE y debe estar en formato DER):
   
   

   pxgrid store # keytool -import -alias mnt -keystore root.jks -file cert-mnt.der

   
   
   
4. Para crear el almacén de claves del cliente, importe el certificado de CA:
   
   

   pxgrid store # keytool -import -alias ca -keystore client.jks -file cert-ca.der

   
   
   
5. Cree una clave privada en el almacén de claves del cliente:
   
   

   pxgrid store # keytool -genkey -alias clientcert -keyalg RSA -keystore client.jks -
   keysize 2048

   
   
   
6. Generar una solicitud de firma de certificado (CSR) en el almacén de claves del cliente:
   
   

   pxgrid store # keytool -certreq -alias clientcert -keystore client.jks -
   file cert-client.csr

   
   
   
7. Firme el archivo cert-client.csr e importe el certificado de cliente firmado:
   
   

   pxgrid store # keytool -import -alias clientcert -keystore client.jks -file cert-
   client.der 

   
   
   
8. Verifique que ambos almacenes de claves contengan los certificados correctos:
   
   

   pxgrid store # keytool -list -v -keystore client.jks 
   pxgrid store # keytool -list -v -keystore root.jks 

   
   
   

   Precaución: cuando se actualiza el nodo ISE 1.3, existe la opción de conservar el certificado de identidad, pero se elimina la firma de CA. Como resultado, el ISE actualizado utiliza un nuevo certificado pero nunca adjunta el certificado de CA en el mensaje SSL/ServerHello. Esto activa la falla en el cliente que espera (según RFC) ver una cadena completa.

Hostname

La API pxGrid para varias funciones (como la descarga de sesión) realiza una validación adicional. El cliente se pone en contacto con ISE y recibe el nombre de host de ISE, que se define mediante el comando hostname en la CLI. Luego, el cliente intenta realizar la resolución DNS para ese nombre de host e intenta contactar y obtener datos de esa dirección IP. Si la resolución DNS del nombre de host de ISE falla, el cliente no intenta obtener ningún dato.

Precaución: Observe que sólo se utiliza el nombre de host para esta resolución, que es lise en este escenario, no el nombre de dominio completo (FQDN), que es lise.example.com en este escenario.

Nota para desarrolladores

Cisco publica y admite la API pxGrid. Hay un paquete llamado así:

pxgrid-sdk-1.0.0-167

Dentro hay:

• archivos JAR pxGrid con clases, que se pueden descodificar fácilmente en archivos Java para comprobar el código
• Almacenes de claves Java de ejemplo con certificados
• Scripts de ejemplo que utilizan clases Java de ejemplo que utilizan pxGrid

Syslog

Esta es la lista de soluciones de seguridad que envían mensajes de syslog con la dirección IP del atacante. Éstos se pueden integrar fácilmente con pxLog siempre y cuando se utilice la regla RegExp correcta en la configuración.

Snort

Snort envía alertas de syslog en este formato:

host[id] [sig_gen, sig_id, sig_sub] [action] [msg] [proto] [src] [dst]

Aquí tiene un ejemplo:

snort[6310]: [1:100124:0] ALERT {ICMP} 10.221.0.240 -> 10.222.0.61

La dirección IP del atacante es siempre la segunda antes de la última (destino). Es sencillo crear una RegExp granular para una firma específica y extraer la dirección IP del atacante. A continuación se muestra un ejemplo de RegExp para la firma 100124 y el mensaje Protocolo de mensajes de control de Internet (ICMP):

snort[\.*:100124:.*ICMP.*

Inspección del dispositivo de seguridad adaptable (ASA) de Cisco

Cuando ASA está configurado para la inspección HTTP (ejemplo), el mensaje syslog correspondiente es similar a lo siguiente:

Mar 12 2014 14:36:20: %ASA-5-415006: HTTP - matched Class 23: 
         MS13-025_class in policy-map MS_Mar_2013_policy, URI matched - 
         Dropping connection from inside:192.168.60.88/2135 to 
         outside:192.0.2.63/80

Una vez más, se podría utilizar un RegExp granular para filtrar esos mensajes y extraer la dirección IP del atacante, la segunda antes de la última.

Sistemas de prevención de intrusiones de última generación (NGIPS) Cisco Sourcefire

Este es un mensaje de ejemplo enviado por el sensor de Sourcefire:

Jan 28 19:46:19 IDS01 SFIMS: [CA IDS][Policy1][119:15:1] http_inspect: OVERSIZE 
REQUEST-URI DIRECTORY [Classification: Potentially Bad Traffic] [Priority: 2] 
{TCP} 10.12.253.47:55504 -> 10.15.224.60:80

De nuevo, es fácil extraer la dirección IP del atacante porque se aplica la misma lógica. También se proporciona el nombre de la política y la firma, por lo que la regla pxLog puede ser granular.

NetScreen de Juniper

A continuación se muestra un mensaje de ejemplo enviado por el antiguo equipo de Detección y prevención de intrusiones (IDP) de Juniper:

dayId="20061012" recordId="0" timeRecv="2006/10/12
21:52:21" timeGen="2006/10/12 21:52:21" domain="" devDomVer2="0"
device_ip="10.209.83.4" cat="Predefined" attack="TROJAN:SUBSEVEN:SCAN"
srcZn="NULL" srcIntf="NULL" srcAddr="192.168.170.20" srcPort="63396"
natSrcAddr="NULL" natSrcPort="0" dstZn="NULL" dstIntf="NULL"
dstAddr="192.168.170.10" dstPort="27374" natDstAddr="NULL" natDstPort="0"
protocol="TCP" ruleDomain="" ruleVer="5" policy="Policy2" rulebase="IDS"
ruleNo="4" action="NONE" severity="LOW" alert="no" elaspedTime="0" inbytes="0"
outbytes="0" totBytes="0" inPak="0" outPak="0" totPak="0" repCount="0"
packetData="no" varEnum="31" misc="<017>'interface=eth2" user="NULL"
app="NULL" uri="NULL"

La dirección IP del atacante se puede extraer de la misma manera.

Juniper JunOS

JunOS es similar:

Jul 16 10:09:39 JuniperJunOS: asp[8265]:  
ASP_IDS_TCP_SYN_ATTACK: asp 3: proto 6 (TCP),  
ge-0/0/1.0 10.60.0.123:2280 -> 192.168.1.12:80, TCP  
SYN flood attack

Linux iptables

Aquí hay algunos ejemplos de iptables de Linux.

Jun 15 23:37:33 netfilter kernel: Inbound IN=lo OUT=
MAC=00:13:d3:38:b6:e4:00:01:5c:22:9b:c2:08:00 src=10.0.0.1 DST=10.0.0.100 LEN=60
TOS=0x10 PREC=0x00 TTL=64 ID=47312 DF PROTO=TCP SPT=40945 DPT=3003 WINDOW=32767
RES=0x00 SYN URGP=0

Puede enviar información de syslog para cualquier tipo de paquete con la funcionalidad avanzada proporcionada por los módulos iptable como seguimiento de conexión, xtables, rpfilters, coincidencia de patrones, etc.

Firewall IPF de FreeBSD (IPFW)

Este es un mensaje de ejemplo para los fragmentos de bloqueo de IPFW:

Sep  7 15:03:14 delta ipfw: 11400 Deny UDP 10.61.216.50 10.81.199.2 in via fxp0 
(frag 52639:519@1480)

Preparación para VPN y gestión de CoA

ISE es capaz de reconocer el tipo de sesiones en términos de gestión de CoA.

• Para una omisión de autenticación 802.1x/MAC (MAB) por cable, ISE envía la reautenticación de CoA, que activa una segunda autenticación.
  
  
• Para un 802.1x/MAB inalámbrico, ISE envía la terminación CoA, que activa una segunda autenticación.
  
  
• Para una VPN ASA, ISE envía una CoA con una nueva DACL conectada (sin segunda autenticación).

El módulo EPS es sencillo. Cuando ejecuta una cuarentena, siempre envía un paquete de terminación de CoA. En el caso de las sesiones por cable/inalámbricas, no supone un problema (todos los suplicantes de 802.1x pueden iniciar de forma transparente una segunda sesión EAP). Pero cuando ASA recibe la terminación de CoA, descarta la sesión VPN y se presenta al usuario final esto:

Hay dos soluciones posibles para forzar que AnyConnect VPN se vuelva a conectar automáticamente (configuradas en el perfil XML):

• Autoconexión, que funciona sólo cuando se pierde la conexión con el gateway VPN, no para la terminación administrativa
  
  
• Siempre activo, lo que funciona y obliga a AnyConnect a restablecer automáticamente la sesión

Incluso cuando se establece la nueva sesión, ASA elige el nuevo audit-session-id. Desde el punto de vista de ISE, se trata de una nueva sesión y no hay posibilidad de encontrar la regla de cuarentena. Además, en el caso de las VPN, no es posible utilizar la dirección MAC del terminal como identidad, a diferencia de dot1x por cable o inalámbrico.

La solución consiste en obligar al EPS a comportarse como el ISE y enviar el tipo correcto de CoA según la sesión. Esta funcionalidad se introducirá en ISE versión 1.3.1.

Partners y soluciones de pxGrid

A continuación se muestra una lista de los partners y las soluciones de pxGrid:

• LogRhythm (Security Information and Event Management, SIEM)): admite la API de transferencia de estado representacional (REST)
• Splunk (SIEM): compatible con la API REST
• HP Arcsight (SIEM): compatible con la API REST
• Sentinel NetIQ (SIEM) - Planes para admitir pxGrid
• Lancope StealthWatch (SIEM): planes para admitir pxGrid
• Cisco Sourcefire: planes para admitir pxGrid 1HCY15
• Cisco Web Security Appliance (WSA): compatibilidad con pxGrid prevista para abril de 2014

Estos son otros partners y soluciones:

• Tenable (evaluación de vulnerabilidades)
• Emulex (captura y diagnóstico de paquetes)
• Bayshore Networks (prevención de la pérdida de datos (DLP) e Internet of Things (IoT))
• Identidad de ping (gestión de acceso e identidad (IAM)/inicio de sesión único (SSO))
• Qradar (SIEM)
• LogLogic (SIEM)
• Symantec (SIEM amd Mobile Device Management (MDM))

Consulte el Catálogo de soluciones de Marketplace para obtener la lista completa de soluciones de seguridad.

API de ISE: REST frente a EREST frente a pxGrid

Hay tres tipos de API disponibles en ISE versión 1.3.

Aquí tiene una comparación:

	DESCANSO	RESTful externo	pxGrid
Autenticación del cliente	nombre de usuario + contraseña (autenticación HTTP básica)	nombre de usuario + contraseña (autenticación HTTP básica)	certificado
Separación de privilegios	no	limitado (ERS Admin)	sí (grupos)
Acceso	MnT	MnT	MnT
Transporte	tcp/443 (HTTPS)	tcp/9060 (HTTPS)	tcp/5222 (XMPP)
Método HTTP	GET	GET/POST/PUT	GET/POST
Habilitado de forma predeterminada	sí	no	no
Número de operaciones	pocos	muchos	pocos
Terminación de CoA	admitido	no	admitido
CoA Reauthenticate	admitido	no	admitido*
Operaciones de usuario	no	sí	no
Operaciones de terminales	no	sí	no
Operaciones de grupo de Endpoint Identity	no	sí	no
Cuarentena (IP, MAC)	no	no	sí
Sin cuarentena (IP, MAC)	no	no	sí
PortBounce/Shutdown	no	no	sí
Operaciones de usuario invitado	no	sí	no
Operaciones del portal de invitados	no	sí	no
Operaciones de dispositivos de red	no	sí	no
Operaciones de grupo de dispositivos de red	no	sí	no

* La cuarentena utiliza la compatibilidad unificada de CoA de ISE versión 1.3.1.

Downloads

pxLog se puede descargar desde Sourceforge .

Ya se incluye el kit de desarrollo de software (SDK). Para obtener la documentación más reciente sobre SDK y API para pxGrid, póngase en contacto con su partner o con el equipo de cuentas de Cisco.

Información Relacionada

• API REST de Cisco ISE 1.2
• API RESTful externa de Cisco ISE 1.2
• Guía para administradores de Cisco ISE 1.3
• Soporte Técnico y Documentación - Cisco Systems