El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
La versión 1.3 del Identity Services Engine (ISE) soporta un nuevo pxGrid llamado API. Este protocolo que soporta la autenticación, cifrado, y privilegios modernos y flexibles (grupos) permite la integración fácil con otras soluciones acerca de la seguridad. Este documento describe el uso de la aplicación del pxLog que se ha escrito como prueba de concepto. el pxLog puede recibir los mensajes de Syslog del Sistema de prevención de intrusiones (IPS) y enviar los mensajes del pxGrid al ISE para quarantine el atacante. Como consecuencia, el ISE utiliza el cambio RADIUS de la autorización (CoA) para cambiar el estatus de autorización del punto final que limita el acceso a la red. Todo el esto sucede transparente al usuario final.
Por este ejemplo, el Snort se ha utilizado como el IPS, pero cualquier otra solución podría ser utilizada. No tiene que realmente ser un IPS. Todo se requiere que es enviar el mensaje de Syslog al pxLog con la dirección IP del atacante. Esto crea una posibilidad de la integración de un gran número de soluciones.
Este documento también presenta cómo resolver problemas y probar las soluciones del pxGrid, con los problemas comunes y las limitaciones.
Descargo: La aplicación del pxLog no es soportada por Cisco. Este artículo se ha escrito como prueba de concepto. El propósito primario era utilizarlo durante betatesting de la implementación del pxGrid en el ISE.
Cisco recomienda que usted tiene experiencia con la configuración de Cisco ISE y el conocimiento básico de estos temas:
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
Aquí está el flujo de tráfico, como se ilustra en el diagrama de la red:
La solución es instalar un conjunto de las aplicaciones en una máquina de Linux:
La aplicación del pxLog utiliza estas bibliotecas:
Todas esas bibliotecas están en el directorio lib del proyecto tan allí no son ya ninguna necesidad de descargar más archivos del Java Archive (TARRO).
Para instalar la aplicación:
Este artículo no se centra en ningún IPS específico, que es porqué solamente se proporciona una explicación abreviada.
El Snort se configura como en línea con el soporte DAQ. El tráfico se reorienta con los iptables:
iptables -I FORWARD -j ACCEPT
iptables -I FORWARD -j NFQUEUE --queue-num 1
Entonces, después del examen, se inyecta y se remite según las reglas iptable predeterminadas.
Se han configurado algunas reglas de encargo del Snort (el archivo de /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)
El Snort envía un mensaje de Syslog cuando el Time to Live (TTL) del paquete es igual a 6 o el tamaño del payload está entre 666 y 686. El tráfico no es bloqueado por el Snort.
También los umbrales se deben configurar para aseegurarse las alertas no se accionan demasiado a menudo (/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
Entonces el servidor de Syslog señala a la máquina del pxLog (/etc/snort/snort.conf):
output alert_syslog: host=10.222.0.61:514, LOG_AUTH LOG_ALER
Para algunas versiones del Snort, hay bug relacionados con la configuración de syslog, y entonces las configuraciones predeterminadas podrían ser utilizadas que señalan al localhost y el Syslog-NG se podría configurar para remitir los mensajes específicos al host del pxLog.
Los EP se deben habilitar (inhabilitado por abandono) de la administración > de las configuraciones:
Esto permite que usted utilice las funciones de la cuarentena/del unquarantine.
Se encuentra la primera regla solamente cuando el punto final quarantined. El acceso entonces limitado es aplicado dinámicamente por el CoA RADIUS. El Switch también se debe agregar a los dispositivos de red con el secreto compartido correcto.
El estatus del pxGrid se puede verificar con el 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
Hay también debugs separados para el pxGrid (la administración > configuración > pxGrid del registro del registro > del debug). Los archivos del debug se salvan en el directorio del pxGrid. Los datos más importantes están en el pxgrid/pxgrid-jabberd.log y el pxgrid/pxgrid-controller.log.
La aplicación del pxLog se despliega automáticamente cuando Tomcat comienza.
el pxLog debe procesar los mensajes de Syslog y ejecutar las acciones basadas en él. Para agregar una nueva regla, selecta maneje las reglas:
Ahora el módulo del guardián busca esta expresión normal (regexp) en el mensaje de Syslog: “snort [”. Si está encontrado, busca todos los IP Addresses y selecciona el que está antes el más reciente. Esto hace juego la mayoría de las soluciones acerca de la seguridad. Refiera a la sección del Syslog para más información. Esa dirección IP (atacante) quarantined vía el pxGrid. También una regla más granular pudo ser utilizada (por ejemplo, puede ser que incluya el número de la firma).
La estación de Microsoft Windows 7 inicia una sesión atada con alambre del dot1x. Cisco Anyconnect NAM se ha utilizado como supplicant. Se configura el método Protocolo-protegido autenticación ampliable EAP (EAP-PEAP).
Se selecciona el perfil de total acceso de la autorización del dot1x ISE. El Switch descarga la lista de acceso para conceder el acceso total:
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
Esto muestra qué sucede si usted envía de un paquete de Microsoft Windows con TTL = 7:
c:\> ping 10.222.0.61 -i 7 -n 1
Que el valor decremented en el Snort en el encadenamiento de la expedición y una alarma se aumenta. Como consecuencia, un mensaje de Syslog hacia el pxLog se envía:
Sep 6 22:10:31 snort snort[6310]: [1:100124:0] ALERT {ICMP} 10.221.0.240 ->
10.222.0.61
El pxLog recibe el mensaje de Syslog, lo procesa, y lo pide para quarantine esa dirección IP. Esto puede ser confirmada si usted marca los registros:
El ISE señala que la dirección IP quarantined:
Como consecuencia, revisa la directiva de la autorización, elige la cuarentena, y envía el CoA RADIUS para poner al día el estatus de autorización en el Switch para ese punto final específico.
Ése es el CoA termina el mensaje que fuerza el supplicant para iniciar una nueva sesión y para conseguir el acceso limitado (Permit_ICMP):
El resultado se puede confirmar en el Switch (acceso limitado para el punto final):
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
En esta etapa, el administrador decide al unquarantine que punto final:
La misma operación se puede ejecutar directamente del ISE:
El ISE revisa las reglas y pone al día otra vez el estatus de autorización en el Switch (se concede el acceso a la red completo):
El informe confirma:
La aplicación del pxLog se ha escrito para demostrar las funciones del pxGrid API. Le permite a:
Más funciones se planean en el futuro.
Aquí está algún screenshots del ejemplo del pxLog:
El cliente (usuario) puede ser un miembro de un en un momento del grupo. Los dos grupos más de uso general son:
Según lo mencionado previamente, el regulador de ambas aplicaciones de cliente, del pxLog y del pxGrid (ISE), debe tener Certificados configurados para comunicar. La aplicación del pxLog mantiene ésos los archivos de KeyStore de las Javas:
Los archivos son protegidos por la contraseña (valor por defecto: cisco123). La ubicación del archivo y las contraseñas se pueden cambiar en WEB-INF/web.xml.
Aquí están los pasos para generar una nueva Java KeyStore:
pxgrid store # keytool -import -alias ca -keystore root.jks -file cert-ca.der
pxgrid store # keytool -import -alias mnt -keystore root.jks -file cert-mnt.der
pxgrid store # keytool -import -alias ca -keystore client.jks -file cert-ca.der
pxgrid store # keytool -genkey -alias clientcert -keyalg RSA -keystore client.jks -
keysize 2048
pxgrid store # keytool -certreq -alias clientcert -keystore client.jks -
file cert-client.csr
pxgrid store # keytool -import -alias clientcert -keystore client.jks -file cert-
client.der
pxgrid store # keytool -list -v -keystore client.jks
pxgrid store # keytool -list -v -keystore root.jks
Caution: Cuando el nodo ISE 1.3 se actualiza, hay una opción para guardar el certificado de identidad, pero se quita la firma de CA. Como consecuencia, el ISE actualizado utiliza un nuevo certificado pero nunca asocia el certificado de CA en el mensaje SSL/ServerHello. Esto acciona el error en el cliente que espera (según el RFC) ver un encadenamiento lleno.
El pxGrid API para varias funciones (como la descarga de la sesión) realiza la validación adicional. El cliente entra en contacto el ISE y recibe el nombre de host ISE, que es definido por el comando hostname en el CLI. Entonces, el cliente intenta realizar la resolución de DNS para ese nombre de host e intenta entrar en contacto y traer los datos de esa dirección IP. Si la resolución de DNS para el nombre de host ISE falla, el cliente no intenta conseguir ningunos datos.
Caution: Note que solamente el nombre de host está utilizado 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.
Cisco publica y soporta el pxGrid API. Hay un paquete nombrado como esto:
pxgrid-sdk-1.0.0-167
Dentro de hay:
Aquí está la lista de soluciones acerca de la seguridad que envíen los mensajes de Syslog con la dirección IP del atacante. Éstos se pueden integrar fácilmente con el pxLog mientras usted utilice la regla correcta del regexp en la configuración.
El Snort envía las alertas del 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 la más reciente (destino). Es simple construir un regexp granular para una firma específica y extraer la dirección IP del atacante. Aquí está un regexp del ejemplo para la firma 100124 y el Internet Control Message Protocol (ICMP) del mensaje:
snort[\.*:100124:.*ICMP.*
Cuando el ASA se configura para el examen HTTP (ejemplo), el mensaje de Syslog correspondiente parece esto:
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
Un regexp granular se podía utilizar otra vez para filtrar esos mensajes y extraer la dirección IP del atacante, el segundo antes la más reciente.
Aquí está 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
Tan otra vez, es simple extraer la dirección IP del atacante porque la misma lógica se aplica. También se proporciona el nombre de la directiva y la firma, así que la regla del pxLog puede ser granular.
Aquí está un mensaje de ejemplo enviado por la más viejas detección de intrusos y prevención (IDP) del enebro:
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.
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
Aquí están algunos iptables de Linux del ejemplo.
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
Usted puede enviar la Información de syslog para cualquier tipo de paquete con las funciones avanzadas proporcionadas por los módulos iptable como la conexión que sigue, los xtables, los rpfilters, coincidencia de patrones, y así sucesivamente.
Aquí está un mensaje de ejemplo para IPFW que bloquea los fragmentos:
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)
El ISE puede reconocer el tipo de sesiones en términos de dirección CoA.
El módulo EP es simple. Cuando ejecuta una cuarentena, envía siempre un CoA termina el paquete. Para las sesiones atadas con alambre/inalámbricas, no es un problema (todos los suplicantes del 802.1x pueden transparente iniciar una segunda sesión EAP). Pero cuando el ASA recibe el CoA termine, él cae a la sesión de VPN y presentan el usuario final con esto:
Hay dos Soluciones posibles para forzar el AnyConnect VPN para volver a conectar automáticamente (configurado en el perfil XML):
Incluso cuando se establece la nueva sesión, el ASA elige la nueva auditoría-sesión-identificación. Desde el punto de vista ISE, esto es una nueva sesión y no hay ocasión de encontrar la regla de la cuarentena. También para los VPN, no es posible utilizar la dirección MAC del punto final como la identidad, en comparación con el dot1x atado con alambre/inalámbrico.
La solución es forzar los EP para comportarse como el ISE y para enviar el tipo correcto de CoA basado en la sesión. Estas funciones serán introducidas en la versión 1.3.1 ISE.
Aquí está una lista de Partners y de soluciones del pxGrid:
Aquí están otros Partners y soluciones:
Refiera al catálogo de las soluciones del mercado para la lista completa de soluciones acerca de la seguridad.
Hay tres tipos de API disponibles en la versión 1.3 ISE.
Aquí está una comparación:
RESTO | Externo relajante | pxGrid | |
---|---|---|---|
Autenticación de cliente | nombre de usuario + contraseña (auth básico HTTP) |
nombre de usuario + contraseña (auth básico HTTP) |
certificado |
Separación del privilegio | no |
limitado (ERS Admin) |
sí (grupos) |
El acceder | MNT | MNT | MNT |
Transporte | tcp/443 (HTTPS) | tcp/9060 (HTTPS) | tcp/5222 (XMPP) |
Método HTTP | GET | GET/POST/PUT | GET/POST |
Habilitado por abandono | sí | no | no |
Número de operaciones | pocos | muchos | pocos |
El CoA termina | soportado | no | soportado |
El CoA Reauthenticate | soportado | no | soportado * |
Operaciones de usuario | no | sí | no |
Operaciones del punto final | no | sí | no |
Operaciones del grupo de la identidad del punto final | no | sí | no |
Cuarentena (IP, MAC) | no | no | sí |
UnQuarantine (IP, MAC) | no | no | sí |
PortBounce/apaga | no | no | sí |
Operaciones de Usuario invitado | no | sí | no |
Operaciones del portal del invitado | no | sí | no |
Operaciones del dispositivo de red | no | sí | no |
Operaciones del grupo de dispositivos de red | no | sí | no |
* Las aplicaciones de la cuarentena unificaron el soporte CoA de la versión 1.3.1 ISE.
el pxLog se puede descargar de Sourceforge.
El Software Development Kit (SDK) es ya incluido. Para la última documentación SDK y API para el pxGrid, entre en contacto su partner o al equipo de cuenta de Cisco.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
23-Dec-2014 |
Versión inicial |