Ike-scan

Introducción a ike-scan 

ike-scan es una herramienta de línea de comandos para el descubrimiento, identificación y prueba de sistemas IPsec VPN. Construye y envía IKE Fase 1-paquetes a los hosts especificados, y muestra las respuestas que se reciben. 

ike-scan le permite: 
Enviar paquetes IKE para cualquier número de hosts de destino, utilizando un ancho de banda de salida configurable o tasa de paquetes. Esto es útil para la detección de VPN, cuando puede que tenga que escanear grandes espacios de direcciones. 
Construir el paquete IKE saliente de una manera flexible. Esto incluye paquetes IKE que no cumplan con los requisitos RFC. 
Decodificar y mostrar los paquetes devueltos. 
Grieta agresivos modo claves pre-compartidas. Puede utilizar ike-scan para obtener los datos de hash PSK, y luego usar psk-crack para obtener la clave. 


IPsec Protocolo Diagrama de jerarquía

IPsec es un grupo de protocolos en lugar de un único protocolo. 



Como muestra el diagrama de arriba, hay tres principales protocolos utilizados por IPsec: IKE, AH y ESP. IKE proporciona autenticación y el intercambio de claves, y AH y ESP se utilizan para enviar los datos a través de la conexión VPN. Algunas implementaciones antiguas utilizan IPSec “manual” conexiones que no requieren el uso de IKE. Sin embargo, éstos se han quedado obsoletas y todos los sistemas modernos de IPsec utilizará IKE. De estos tres protocolos, IKE es de lejos el más complejo. En este documento sólo se preocupan por el protocolo IKE, por lo que no cubriremos AH o ESP adelante. 

La utilización de IKE para autenticar e intercambiar material clave para una conexión ESP o AH es un proceso de dos fases. Fase-1 autentica a los compañeros y establece un canal seguro (llamado IKE SA) para la Fase-2, que negocia el modo IPsec y establece un canal seguro para el tráfico AH o ESP denominado SA IPsec. 

Fase-1 puede funcionar en uno de dos modos: o bien el modo principal o modo dinámico, mientras que la Fase-2 sólo tiene un modo único llamado Modo Rápido. Al probar IPsec VPN sistemas que se ocupará principalmente de IKE Fase-1, Fase-2 sólo se puede acceder tras la autenticación exitosa. Para el resto de este documento, sólo se va a considerar IKE Fase-1. 

Modo principal es el estándar de la fase-1 modo, y todas las implementaciones de IKE deben apoyarlo. Modo principal ofrece protección de identidad por no pasar las identidades hasta que el canal está codificado, y también evita algunos ataques de denegación de servicio mediante la realización de una prueba de verificación liveness antes de emprender el costoso Diffie-Hellman exponenciación. 

Modo Agresivo es una opción Fase-1 de modo, que no todas las implementaciones de apoyo. Es un intercambio sencillo, requiriendo menos paquetes, pero es menos flexible que el modo principal y también tiene una serie de debilidades de seguridad. El uso principal de modo agresivo en la práctica es permitir el uso de la Pre-Shared Key autenticación para soluciones de acceso remoto. Debido a la forma en que se calcula el material de claves, no es posible utilizar el modo principal con la autenticación PSK, a menos que la dirección IP del iniciador se conoce de antemano (el cual no es normalmente el caso en una situación de acceso remoto). 

Los siguientes RFC IPsec se refieren a: 
RFC 2409 Internet Key Exchange (IKE) 
RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP) 
RFC 2407 El Dominio de Internet IP de Interpretación de Seguridad ISAKMP 
RFC 2406 IP encapsulante de Seguridad de carga útil (ESP) 
RFC 2402 cabecera de autenticación IP 

Vamos a hacer referencia a ellas en este documento, especialmente para los dos primeros que describen el protocolo IKE, y la estructura del paquete ISAKMP. 

IPsec VPN descubrimiento 

IPsec servidores VPN generalmente no será detectado por un análisis de puertos. Esto se debe a que no se escucha ningún puerto TCP, por lo que un puerto TCP scan no los encontrará. Lo que es más, no suelen enviar mensajes ICMP inalcanzables, por lo que un escaneo de puertos UDP no recogerá IKE en el puerto 500 (el puerto estándar para este tipo de conexiones) y un exploración IP en bruto no recogerá ESP o AH con protocolos IP 50 y 51. Además, las RFC IPsec especificar que los paquetes de formato incorrecto debe ser ignorado, así que enviar basura aleatoria al puerto UDP 500 o protocolos IP 50 y 51 normalmente no provoca una respuesta tampoco. 

La manera eficaz de detectar los sistemas IPsec VPN es el envío de un paquete IKE con el formato correcto para cada uno de los sistemas que desea comprobar y visualizar cualquier respuesta IKE que se reciben. Este método es capaz de detectar las VPN IPSec IKE que utilizan para el intercambio de claves y no restringir las direcciones IP de origen que van a responder. En la práctica, casi todas las modernas implementaciones de IPsec utiliza IKE, la alternativa es el intercambio de claves manual, lo cual es muy raro hoy en día. El programa ike-scan nos permite enviar un paquete IKE a los sistemas de destino especificados y mostrar las respuestas. 

Usando ike-scan con la configuración predeterminada 

Para empezar, nos encontramos ike-scan con la meta de hosts usando los ajustes por defecto. Con estos ajustes, ike-scan le enviará un paquete IKE de modo principal para cada objetivo. Este paquete consta de una cabecera de ISAKMP seguido de una asociación de seguridad (SA) de carga útil. La carga útil SA contiene una única propuesta, que a su vez contiene ocho transformaciones. 

El siguiente diagrama muestra la estructura del paquete de modo principal IKE que se envía por ike-scan con la configuración predeterminada. 



La estructura de las diversas cargas útiles: Cabecera ISAKMP, SA, Propuesta y Transformación se definen en RFC 2408 . 

Cada transformación contiene un número de atributos. Los atributos de cada uno de los ocho transformaciones de la propuesta por defecto son: 



Estos ocho transformaciones representan las combinaciones de atributos siguientes: 
Algoritmo de cifrado: DES o Triple DES 
Hash algoritmo: MD5 o SHA1 
Método de autenticación: Pre-Shared Key 
Diffie-Hellman grupo: 1 ó 2 
SA por vida: 28.800 segundos 

La lista a continuación muestra un ejemplo de la salida ike-scan para esta ejecución descubrimiento inicial. En este ejemplo, se especifica los hosts de destino como la red 10.0.0.0/24, lo que resulta en nosotros escanear un total de 256 sistemas de 10.0.0.0 a 10.0.0.255 inclusive. El M-(multilínea) opción hace que cada carga que se muestra en una línea separada, lo que hace que la salida más fácil de leer. 
$ Ike-scan-M 10.0.0.0/24 A partir ike-scan 1,7 con 256 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.5 Mensaje de Notificación 14 (NO LA PROPUESTA elegido) 10.0.0.6 Handshake Modo Principal regresó SA = (= Enc 3DES Hash MD5 = Grupo = 2: modp1024 Auth = PSK LifeType = Segundos LifeDuration = 28800) VID Handshake = 4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentación) 10.0.0.1 Modo Principal regresó SA = (Enc = 3DES Hash SHA1 = Auth = PSK = Grupo 2: modp1024 LifeType = LifeDuration segundos (4) = 0x00007080) Poner fin a ike-scan 1.7: 256 hosts escaneados en 19,22 segundos (13,32 hosts / seg). 17 apretón de manos regresaron, el 32 regresó notificar 

Podemos ver que algunos sistemas han respondido con un apretón de manos de modo principal, lo que significa que están dispuestos a realizar las negociaciones IKE con nosotros, y al menos uno de nuestros ocho transformaciones es aceptable. También podemos ver que algunos otros sistemas han respondido con un mensaje de notificación, lo que significa que o bien el sistema no está dispuesto a negociar con nosotros (por ejemplo, debido a que sólo acepta solicitudes de determinadas direcciones IP de origen), o que ninguna de nuestras transformaciones son aceptables. Debido a que sólo están interesados ​​en el descubrimiento de sistemas VPN en esta etapa, no se preocupa de si los sistemas responden con un apretón de manos o un mensaje de notificación – de cualquier manera, se han revelado. 

Para aquellos sistemas que responden con un apretón de manos, podemos ver los detalles de la transformación que fue aceptado en la carga SA, por ejemplo Enc = 3DES Hash MD5 = Grupo = 2: modp1024 Auth = PSK LifeType = Segundos LifeDuration = 28800 que significa Triple- DES para el cifrado, MD5 como algoritmo de hash HMAC, Diffie-Hellman grupo 2 (que es un grupo de 1024-bit MODP), Pre-Shared Key (PSK), y una vida útil de segundos SA 28800. Algunos sistemas también incluyen un ID de proveedor (VID) de carga útil en su respuesta – vamos a estar viendo esto más adelante cuando hablemos de las huellas digitales. Para los sistemas que responden con un mensaje de notificación se obtiene el número de mensaje y, cuando el número es conocido, el nombre correspondiente a ese número, por ejemplo: mensaje de notificación 14 (NO-PROPUESTA-elegido).

Intentar diferentes transformaciones 

No todos los sistemas VPN responder con un mensaje de notificación cuando ninguna de las transformadas son aceptables. Algunos simplemente ignorar paquetes IKE con atributos no válidos en su lugar. Tenemos que encontrar una transformación aceptable con el fin de obtener este tipo de sistemas para responder. 

Cada transformada se compone de un número variable de atributos, pero en la práctica sólo hay cuatro que hay que considerar en esta fase: el algoritmo de cifrado (y longitud de la clave de cifrado de longitud variable), el algoritmo de hash, el método de autenticación y el Diffie- Hellman grupo. El tiempo de vida en segundos SA con seguridad se puede dejar en el valor predeterminado de 28800, ya que casi siempre es aceptable, y no hay necesidad de agregar cualquier otro atributo. El valor para cada uno de los cuatro atributos es un número sin signo de 16-bit, y por lo tanto tiene 65536 valores posibles. Si todos los valores son posibles, entonces no habría un total de 65536 ^ 4 (unos 18 millones de billones de dólares) combinaciones diferentes, por lo que sería imposible de tratar a todos ellos. Sin embargo, en la práctica cada atributo usa sólo unas pocas de las posibles valores, y algunos de estos valores son mucho más comunes que otros, por lo que es posible detectar la mayoría de los sistemas con un número razonable de transformaciones. En las tablas siguientes se enumeran los valores de los atributos de transformación que se definen en las diversas IPsec RFC y borradores IETF. 

Valores Algoritmo de cifrado 



Valores Hash Algorithm 



Valores Método de autenticación 



Diffie-Hellman Group Valores 



En cuanto a los valores comunes de las tablas de atributos de transformación, podemos ver que hay cinco algoritmos de cifrado (AES cuenta como tres, ya que cuenta con tres diferentes longitudes de clave), dos algoritmos de hash, cuatro métodos de autenticación, y tres grupos Diffie-Hellman. Esto da un total de 120 combinaciones de estos valores comunes, lo cual es lo suficientemente bajo como para que podamos probar cada uno. 

ike-scan permite que el método de autenticación por defecto en el conjunto de transformación que cambiarse con la opción – auth. Por otra parte, una transformación personalizada se puede especificar con la opción – trans, y es posible usar esta opción varias veces para agregar un número arbitrario de las transformaciones para la carga útil SA. Debido a que es posible especificar un número arbitrario de transformaciones con la opción – trans, podríamos estar tentados a especificar todos los ciento veinte combinaciones. Sin embargo, eso no va a funcionar, porque muchas implementaciones IPsec poner un límite en el número de transformaciones que tratan. El número máximo varía de un fabricante a otro, un ejemplo es el Checkpoint que acepta un máximo de veinte transformaciones. Por lo tanto, debemos realizar varios ciclos, y cada uno con un número razonable de transformaciones. 

La primera cosa a intentar es utilizar el estándar de transformar set, pero cambiar el método de autenticación de clave previamente compartida para una de las opciones comunes. Puede utilizar la opción – auth para hacer esto, por ejemplo ike-scan – auth = 3 10.0.0.0/24 utilizará el estándar de transformación establecido con el conjunto de métodos de autenticación para RSA Firma en lugar de la llave Pre-Compartida por defecto para cada transformación. Este método es sorprendentemente eficaz en descubrir servidores VPN que no responden a la norma de transformación establecido. 

Los métodos alternativos de autenticación recomendados para tratar son: 
– Auth = 3: Firma RSA 
– Auth = 64221: Modo híbrido, de uso común en los sistemas Checkpoint. 
– Auth = 65001: XAUTH, de uso común en muchos sistemas de acceso remoto. 

Un método alternativo y más completo es el de crear un script para generar todas las combinaciones de transformación y, a continuación, utilizar xargs para funcionar ike-scan tantas veces como sea necesario, con un número máximo especificado de transformaciones. Aquí es una secuencia de comandos shell ejemplo que podría ser utilizado para generar una lista de opciones de transformación que contienen todas las combinaciones posibles de los comúnmente utilizados atributos de transformación:

#! / Bin / sh
#
# Algoritmos de cifrado: DES, Triple-DES, AES/128, AES/192 y AES/256
ENCLIST = “1 5 7/128 7/192 7/256”
# Algoritmos hash: MD5 y SHA1
Lista ordenada = “1 2”
# Los métodos de autenticación: Pre-Shared Key, firmas RSA, Modo Híbrido y XAUTH
AUTHLIST = “1 3 64221 65001”
# Diffie-Hellman grupos: 1, 2 y 5
Lista_grupos = “1 2 5”
#
para ENC en $ ENCLIST; hacer
para HASH en $ lista ordenada; hacer
para AUTH en $ AUTHLIST; hacer
para el GRUPO en $ lista_grupos; hacer
echo “- trans = $ ENC, $ HASH, $ AUTH, $ GRUPO”
hecho
hecho
hecho
hecho


Si este script se llama generate-transforms.sh, podríamos usarlo para ejecutar ike-scan con hasta ocho transformaciones en cada carrera de la siguiente manera:

generate-transforms.sh | xargs – max-lines = 8 ike-scan 10.0.0.0/24

Esto resultará en 15 de exploración ike-carreras, cada uno contra 256 objetivos. 


Otras opciones útiles para VPN Discovery 

Usted puede encontrar las siguientes opciones de escaneo ike-útil al realizar VPN servidor de descubrimiento, sobre todo si se trata de una larga lista de direcciones IP de destino: 

– Retry – especifica el número máximo de veces para tratar un host que no responde. El valor predeterminado es tres, pero normalmente se puede reducir a menos que haya una pérdida de paquetes entre usted y el objetivo. Reducir Esto acelera el proceso de escaneado. 
– Ancho de banda – especifica el ancho de banda de salida. Puede aumentar este para acelerar la exploración si tiene suficiente ancho de banda, o disminuirlo para hacer la exploración más cauteloso. El ancho de banda de salida predeterminado es 56000 bits por segundo. 
– Random – aleatoriza el orden en que los objetivos son escaneados. Esto puede hacer que la exploración de un poco menos obvio, especialmente si va a escanear rangos muy grandes. 

IPsec VPN Fingerprinting 

Una vez que han descubierto los servidores VPN, el siguiente paso es averiguar tanta información sobre ellos como podamos. Utilizando las técnicas de toma de huellas digitales que se detallan en esta sección, a menudo podemos determinar el fabricante y el modelo del servidor VPN, y en ocasiones también podemos determinar el número de versión del software. Esta información puede ser valiosa para un atacante, ya que podrían usarlo para buscar vulnerabilidades conocidas asociadas con esa marca de VPN, o descargar el software VPN cliente y tratar de adivinar la contraseña y nombre de usuario. El servidor VPN es también a menudo el servidor de seguridad, en cuyo caso la toma de huellas dactilares a identificar la marca cortafuegos también. 

A menudo, sólo una técnica de toma de huellas dactilares es suficiente para identificar a una implementación de servidor VPN. Sin embargo, cuando no se puede obtener un resultado definitivo con cualquier técnica, la combinación de métodos por lo general nos dará la información suficiente para determinar la aplicación, o por lo menos hacer una conjetura. 

Conseguir un apretón de manos IKE 

El primer paso es tratar de conseguir un apretón de manos IKE de cada uno de los sistemas que queremos huella digital, y anotar los atributos de transformación aceptables. Si ya tienes un apretón de manos de la etapa de descubrimiento, entonces sólo podemos anotar los atributos de transformación de la carga SA. Sin embargo, si todo lo que tenemos es un mensaje de notificación, entonces debemos tratar de conseguir un apretón de manos antes de que podamos proceder con la toma de huellas dactilares. 

El proceso de tratar de obtener un apretón de manos consiste en tratar todas las combinaciones de atributos transformar hasta encontrar uno que sea aceptable. Este es el mismo proceso que se utilizó en la fase de descubrimiento para tratar de detectar sistemas VPN que no respondieron a la norma transformar conjunto, la única diferencia es que se trata de un número mucho más pequeño de los sistemas en esta etapa y por lo tanto puede intentar más atributos. 

Una vez que hemos obtenido un apretón de manos IKE, usaremos la transformada aceptable en futuros análisis. Por ejemplo, si la carga SA fue devuelto SA = (= Enc KeyLength AES = 256 = hash SHA1 = Grupo 5: modp1536 Auth = PSK LifeType = Segundos LifeDuration = 28800), podríamos especificar – trans = 7/256, 2, 1,5. Tenga en cuenta que para la variable-KeyLength sistemas de cifrado como AES, se especifica el KeyLength como “/ bits” después de que el algoritmo de cifrado. 

UDP Backoff Fingerprinting 

IKE utiliza el transporte UDP, que es poco fiable. Por lo tanto, debe implementar su estrategia de retransmisión propio para hacer frente a la pérdida de paquetes. Debido a que IPsec RFC no especifica los detalles precisos de la estrategia de retroceso, cada vendedor IPsec generalmente inventa su propio esquema. Podemos usar estas estrategias backoff diferentes para la huella digital del servidor VPN. 

Para obtener los detalles del patrón de retroceso, enviamos un paquete IKE con una transformación aceptable, pero no respondió a ninguna de las respuestas del servidor VPN. El servidor se asume que el paquete se perdió, y se volverá a tratar en función de su estrategia de reducción de potencia. Al registrar el momento en que cada uno de los paquetes del servidor es recibida, y calculando la diferencia entre los tiempos, se puede determinar la estrategia de retardo de envío y por lo tanto la huella dactilar del servidor. 

Un paquete normal de cambio de modo principal entre el cliente VPN y el servidor tiene el siguiente aspecto:



Si usamos ike-scan en el modo de toma de huellas dactilares backoff, no responderá a los paquetes desde el servidor, lo que hará que el servidor de retransmitir. En este caso, el intercambio de paquetes se verá así: 



ike-scan permite obtener el patrón de retroceso de un servidor VPN, y también a tratar de coincidir con el patrón recibido en contra de una base de datos de patrones conocidos. Para realizar la toma de huellas dactilares backoff tenemos que especificar la opción – showbackoff, lo que provocará ike-scan para registrar las horas de todos los paquetes de respuesta, y esperar hasta sesenta segundos después de que el último paquete para asegurarse de que ha visto todo ellos antes de mostrar los detalles de los tiempos y intentando hacer coincidir el patrón. Porque tenemos que esperar hasta que todos los paquetes que han sido enviados, y luego esperar un minuto más para asegurarse de que no están llegando más, el proceso de toma de huellas dactilares backoff tarda entre uno y dos minutos. 

A continuación se presentan cuatro ejemplos de toma de huellas dactilares backoff en acción. Los significados de las columnas en los patrones de backoff son: 

IP Address – La dirección IP del servidor VPN que este patrón se relaciona. 
No. – El número del paquete de respuesta de este host con el paquete de respuesta primero ser 1. 
Tiempo Pets – El tiempo en que este paquete se ha recibido respuesta. Este tiempo se muestra como el número de segundos y microsegundos desde la medianoche el 1 de enero de 1970 (la Época utilizado por los sistemas Unix). 
Tiempo Delta – La diferencia entre el tiempo cuando este paquete de respuesta se ha recibido y el tiempo en que el paquete de respuesta anterior fue recibido en segundos. Esto es siempre cero para el paquete de respuesta primero.

$ Ike-scan-M – trans = 5,2,1,2 – showbackoff 10.0.0.1
A partir ike-scan 1,7 con un hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.1 Handshake Modo principal devuelto
SA = (= Enc 3DES hash SHA1 = Auth = PSK = Grupo 2: modp1024 LifeType = LifeDuration segundos (4) = 0x00007080)

IKE Backoff Patrones:

No. IP Address Pets tiempo Tiempo Delta
10.0.0.1 1 1121251508,773117 0,000000
10.0.0.1 2 1121251510,772474 1,999357
10.0.0.1 3 1121251512,775259 2,002785
10.0.0.1 4 1121251514,777952 2,002693
10.0.0.1 5 1121251516,780746 2,002794
10.0.0.1 6 1121251518,783504 2,002758
10.0.0.1 7 1121251520,786298 2,002794
10.0.0.1 8 1121251524,791781 4,005483
10.0.0.1 9 1121251528,797329 4,005548
10.0.0.1 10 1121251532,802822 4,005493
10.0.0.1 11 1121251536,808370 4,005548
10.0.0.1 12 1121251540,813874 4,005504
10.0.0.1 Aplicación conjetura: Firewall-1 4.1/NG/NGX
________________________________________________________________________
$ Ike-scan-M – trans = 5,1,1,2 – showbackoff 10.0.0.2
A partir ike-scan 1,7 con un hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.2 Handshake Modo principal devuelto
SA = (= Enc 3DES Hash MD5 = Grupo = 2: modp1024 Auth = PSK LifeType = Segundos LifeDuration = 28800)
VID = 4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentación)

IKE Backoff Patrones:

No. IP Address Pets tiempo Tiempo Delta
10.0.0.2 1 1121252105,954742 0,000000
10.0.0.2 2 1121252113,946698 7,991956
10.0.0.2 3 1121252121,944037 7,997339
10.0.0.2 4 1121252129,945608 8,001571
10.0.0.2 Aplicación conjetura: Cisco VPN Concentrator
________________________________________________________________________
$ Ike-scan-M – trans = 5,2,1,2 – showbackoff 10.0.0.3
A partir ike-scan 1,7 con un hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.3 Handshake Modo principal devuelto
SA = (= Enc 3DES hash SHA1 = Auth = PSK = Grupo 2: modp1024 LifeType = LifeDuration segundos (4) = 0x00007080)

IKE Backoff Patrones:

No. IP Address Pets tiempo Tiempo Delta
10.0.0.3 1 1121252226.796701 0.000000
10.0.0.3 2 1121252242.606684 15.809983
10.0.0.3 3 1121252258.419674 15.812990
10.0.0.3 4 1121252274.559528 16.139854
10.0.0.3 Implementation guess: Nortel Contivity
________________________________________________________________________
$ ike-scan -M –trans=5,2,3,2 –showbackoff 10.0.0.4
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.4 Main Mode Handshake returned
SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=RSA_Sig LifeType=Seconds LifeDuration(4)=0x00007080)
VID=1e2b516905991c7d7c96fcbfb587e46100000004 (Windows-2003-or-XP-SP2)
VID=4048b7d56ebce88525e7de7f00d6c2d3 (IKE Fragmentation)
VID=90cb80913ebb696e086381b5ec427b1f (draft-ietf-ipsec-nat-t-ike-02\n)

IKE Backoff Patterns:

IP Address No. Recv time Delta Time
10.0.0.4 1 1121252667.865074 0.000000
10.0.0.4 2 1121252668.971457 1.106383
10.0.0.4 3 1121252670.973030 2.001573
10.0.0.4 4 1121252674.972099 3.999069
10.0.0.4 5 1121252682.966370 7.994271
10.0.0.4 6 1121252698.968920 16.002550
10.0.0.4 7 1121252730.975145 32.006225
10.0.0.4 Implementation guess: Windows 2000, 2003 or XP
_____________________________________________________________________________

Podemos ver que cada uno de los cuatro servidores respondió con un patrón diferente, y en cada caso hemos sido capaces de determinar la marca de servidor VPN. Usted también puede haber notado que algunos de los servidores han respondido con cargas adicionales de “VID” – son cargas de ID de proveedor, y a estar buscando en ellos en la siguiente sección.

Los tiempos que observamos pueden ser una fracción de un segundo diferente de los valores utilizados por el servidor en el algoritmo de retroceso debido a las diferencias de la latencia, retrasos en el servidor y otros temas de programación. Sin embargo, si nos ronda los retrasos observados al segundo más cercano, podemos ver que los cuatro patrones son:

Checkpoint Firewall-1 – 0, 2, 2, 2, 2, 2, 2, 4, 4, 4, 4, 4 
Cisco VPN Concentrator – 0, 8, 8, 8 
Nortel Contivity – 0, 16, 16, 16 
Microsoft Windows – 0, 1, 2, 4, 8, 16, 32 

Puedes ver otros ejemplos de patrones de backoff en el archivo de patrones de backoff ike, que se incluye en la distribución de ike-scan. 

Vendor ID Fingerprinting 

El protocolo IKE define una carga Vendor ID opcional (VID), que puede ser incluido en un paquete de IKE Phase-1 y puede contener datos arbitrarios. Esta carga es utilizada por vendedores para intercambiar información sobre extensiones propietarias o reconocer sus propias implementaciones. Los datos de la carga útil están a menudo el hash MD5 de una cadena de texto.

Podemos utilizar cualquier cargas Vendor ID que son enviados por el servidor VPN para ayudar a identificarlo. IKE-scan muestra automáticamente cualquier cargas de ID de proveedor que recibe y tratará de compensarlas contra una base de datos de patrones conocidos de ID de proveedor. También permite cargas Vendor ID que se añade a los paquetes salientes con la opción de proveedor.

No todos los servidores VPN envían ID de proveedor y los que a veces sólo enviarlos si reciben primero un ID de proveedor específico, o solamente en modo agresivo IKE (que va cubriendo más adelante en este artículo). Si un servidor VPN no envía un ID de proveedor, y crees que sabes lo que es el servidor, entonces vale la pena olfateando el tráfico saliente de la aplicación de cliente VPN asociada con tcpdump o etéreo de observación de una ID de proveedor enviada por ese cliente. Envío que Vendor ID al servidor a menudo hará responder con su propio proveedor. 

El siguiente ejemplo muestra las cargas de ID de proveedor devueltas por un servidor Microsoft Windows 2003 IPsec. El primer vídeo es el más interesante: este es el hash MD5 de la cadena MS NT5 ISAKMPOAKLEY con el número cuatro que se incorpora como un valor de 32 bits en formato big-endian. Todas las implementaciones de Microsoft IPsec envían el mismo hash, pero las versiones de windows distintas agregar números diferentes al final del hash, que permite reducir la versión del software. Los valores que ike-scan conoce son:

00000002 – Windows 2000 Server 
00000003 – Windows XP SP1 
00000004 – Windows 2003 Server and Windows XP SP2 
00000005 – Windows Vista and Windows 2008 server 

$ ike-scan –trans=5,2,3,2 –multiline 10.0.0.4
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.4 Main Mode Handshake returned
SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=RSA_Sig LifeType=Seconds LifeDuration(4)=0x00007080)
VID=1e2b516905991c7d7c96fcbfb587e46100000004 (Windows-2003-or-XP-SP2)
VID=4048b7d56ebce88525e7de7f00d6c2d3 (IKE Fragmentation)
VID=90cb80913ebb696e086381b5ec427b1f (draft-ietf-ipsec-nat-t-ike-02\n)


Este es un ejemplo de Checkpoint Firewall-1. La versión en este ejemplo sólo devolverá una carga útil de identificación del vendedor, si se envía una carga útil VID que contiene f4ed19e0c114eb516faaac0ee37daf2807b4381f, que es de los primeros veinte bytes del VID que envían todos los productos de Checkpoint. Vemos que el servidor devuelve un ID de proveedor que no sólo lo identifica como Checkpoint Firewall-1 (porque el vídeo comienza con los mismos veinte bytes), pero también identifica la versión de exact software en los bytes restantes de veinte. En este caso, el objetivo es correr Checkpoint Firewall-1 NG AI R54. Ver http://www.nta-monitor.com/news/checkpoint2004/index.htmpara más detalles sobre la estructura de este ID de proveedor.

$ ike-scan –trans=5,2,1,2 –vendor=f4ed19e0c114eb516faaac0ee37daf2807b4381f –multiline 10.0.0.1
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.1 Main Mode Handshake returned
SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138c000000000000000018a00000 (Firewall-1 NG AI R54)


Finalmente, este ejemplo muestra la carga de ID de proveedor devuelta por un Nortel Contivity (ahora conocido como Nortel VPN router). Este sistema sólo devolverá una carga útil VID si se envía en el paquete de solicitud. Sin embargo, a diferencia de Checkpoint, Nortel no le importa qué ID de proveedor se da, por lo que enviar un solo byte con valor cero. El ID de proveedor que se devuelve consta de cuatro bytes, que son la cadena de texto BNES, seguido por el número nueve como un valor de 32 bits en formato big-endian. BNES significa Bahía redes empresa interruptor, que era el nombre del producto antes de Bay Networks fueron adquiridas por Nortel, y el número al final probablemente representa la versión del software. 

$ ike-scan –trans=5,2,1,2 –vendor=00 –multiline 10.0.0.3
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.3 Main Mode Handshake returned
SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
VID=424e455300000009 (Nortel Contivity)


IKE Aggressive Mode 

Todos los ejemplos hasta ahora han utilizado el modo principal de IKE, que debe ser apoyado por todos los servidores VPN. Algunos servidores VPN, servidores de acceso remoto especialmente, también admiten el modo agresivo. Si un servidor soporta el modo agresivo, entonces podemos utilizar eso para obtener información adicional. Modo agresivo se utiliza normalmente para acceso remoto con la autenticación de clave previamente compartida. 

El siguiente diagrama muestra la estructura del primer paquete de modo agresivo de IKE. Usted puede ver que es más complejo que el paquete de modo principal mostrado anteriormente, ya que contiene tres cargas adicionales:

Key Exchange – El valor público de Diffie-Hellman
Nonce – Reproducir datos aleatorios para probar la vitalidad y prevenir
Identification – La identidad de los pares 



Dado que el primer paquete de modo agresivo contiene el valor público de Diffie-Hellman, sólo un único grupo Diffie-Hellman puede especificarse en la propuesta. Por lo tanto la propuesta de exploración de ike estándar es diferente cuando se utiliza el modo agresivo – sólo contiene cuatro transformaciones en lugar de los ocho se transforma en un paquete normal modo principal ya que utiliza sólo 2 de grupo Diffie-Hellman. 

Son las cuatro transformaciones en la propuesta de modo agresivo estándar de ike-scan:

 

Estas cuatro transformaciones representan las siguientes combinaciones de atributo:

Algoritmo de cifrado: DES or Triple DES 
Algoritmo hash: MD5 or SHA1 
Método de autenticación: Pre-Shared Key 
Grupo Diffie-Hellman: 2 
Vida SA: 28800 seconds 

A veces puede ser difícil conseguir un servidor VPN para el apretón de manos con modo agresivo IKE, porque muchos servidores no responden si no se suministra una identificación válida en la carga útil de identificación. Este identificador suele ser un nombre de usuario o correo electrónico. De hecho, sólo responder a ID válido presenta una vulnerabilidad de enumeración username porque permite distinguir entre los nombres de usuario válidos y no válidos.

El siguiente ejemplo muestra una respuesta de modo agresivo de un concentrador de VPN de Cisco. Para este sistema, tenemos que especificar un nombre de usuario válido en la carga de la identidad (aunque para las versiones más recientes del software de Cisco concentrador no es el caso). Podemos ver que la respuesta contiene varias cargas útiles interesantes: 

ID – El servidor utiliza su dirección IP en la carga de identidad. Si el servidor está detrás de un dispositivo NAT, entonces esto revelará su dirección real. 
Hash – Se trata de un valor hash basado en MD5 HMAC. Podemos utilizar esto para montar una línea contraseñas ataque. 
VIDs – Un total de cinco cargas de ID de proveedor se devuelven, que identifique el sistema como un concentrador de VPN de Cisco.

$ ike-scan –aggressive –multiline –id=finance_group 10.0.0.2
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.2 Aggressive Mode Handshake returned
SA=(Enc=3DES Hash=MD5 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
KeyExchange(128 bytes)
Nonce(20 bytes)
ID(Type=ID_IPV4_ADDR, Value=10.0.0.2)
Hash(16 bytes)
VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity)
VID=09002689dfd6b712 (XAUTH)
VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection)
VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation)
VID=1f07f70eaa6514d3b0fa96542a500306 (Cisco VPN Concentrator)


En el ejemplo siguiente se muestra una respuesta de modo agresivo de un firewall Cisco PIX. No tenemos que suministrar una identificación válida con este sistema. Este sistema utiliza su nombre de host para el identificador y el nombre elegido nos da una idea de la marca y el modelo del sistema. Si observamos con cuidado, también podemos ver que el concentrador de VPN pone sus cargas en un orden diferente al PIX: el concentrador de VPN envía SA, Key Exchange, Nonce, ID, Hash, VID x 5; Considerando que el PIX envía SA, VID x 4, Key Exchange, ID, Nonce, Hash. Esta diferencia indica que aunque los dos sistemas son del mismo fabricante, se basan en diferentes implementaciones de IPsec subyacentes. Nos estará mirando este tipo de respuestas diferentes en la siguiente sección. 

$ ike-scan –trans=7/256,2,1,2 –aggressive –multiline 192.168.91.2
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
192.168.91.2 Aggressive Mode Handshake returned
SA=(Enc=AES KeyLength=256 Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800)
VID=09002689dfd6b712 (XAUTH)
VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection)
VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity)
VID=11f27f551d0760dfc9ca6f5670fe5291
KeyExchange(128 bytes)
ID(Type=ID_FQDN, Value=pix520-internet.company.com)
Nonce(20 bytes)
Hash(20 bytes)


Se puede especificar una transformación personalizada establece de modo agresivo en la misma forma que el modo agresivo. Pero hay dos diferencias importantes para transforma de modo agresivo, que se relacionan con el hecho de que el primer paquete contiene la carga útil de intercambio de claves. 

La primera diferencia es que todos los transforma de modo agresivo deben utilizar el mismo grupo Diffie-Hellman. Se trata de una limitación de modo agresivo; RFC 2409 Estados: debido a los requisitos de construcción del mensaje no se puede negociar el grupo en el que se realiza el intercambio Diffie-Hellman. IKE-scan permitirá especificar diferentes grupos Diffie-Hellman, que pueden ser útiles si desea determinar cómo el servidor responde a cargas no compatibles con. Pero para el uso normal, asegúrese de que transforma todos tiene el mismo grupo Diffie-Hellman cuando use el modo agresivo. 

La segunda diferencia es que usted tendrá que especificar el grupo Diffie-Hellman para la carga útil de intercambio de claves para grupos que no sean el grupo predeterminado 2. Esto se logra con la opción–dhgroup. IKE-scan permite utilizar cualquier grupo Diffie-Hellman para la carga útil de intercambio de claves, pero para uso normal siempre especificar Diffie-Hellman en grupo con la opción–dhgroup para el modo agresivo y asegurar que el número de grupo es el mismo que el especificado en las transformaciones.

Diferencias en el comportamiento 

Ya hemos analizado las diferencias en el comportamiento de diferentes implementaciones de IPsec con backoff estrategias, Vendor ID y el orden de cargas en el paquete de IKE. Esta sección describe algunos otros ejemplos de diferencias que pueden utilizarse para implementaciones de IPsec de huellas dactilares.

Algunas de las diferencias son cosas que no están totalmente definidas, otros se deben a que las RFC se puede interpretar de varias maneras diferentes, y uno o dos sólo no tienen ningún sentido en absoluto. 

El IKE_Implementation_Analysis sección contiene ejemplos de implementaciones de IKE varios, e incluye detalles de cómo responder a los paquetes IKE diferentes. Esto puede ser un recurso muy útil si usted está tratando de huella digital de un sistema que no tiene un patrón único backoff o proveedor de identidad. 

Cifrado de clave de longitud fija para cifrados con claves de longitud 

La longitud de la clave de atributo transformada se utiliza para algoritmos de cifrado con claves de longitud variable, por ejemplo AES. No está destinado a ser utilizado por los algoritmos de cifrado con claves de longitud fija como DES y Triple DES, y RFC 2409 dice: _Es [longitud de clave] atributo NO DEBE ser utilizado cuando el algoritmo de cifrado especificado utiliza un KEY_ longitud fija. Encontramos que diferentes implementaciones manejar esta situación de manera diferente: algunos rechazan la transformación, algunos aceptan la transformación, pero ignoran el atributo de longitud de la clave, y algunos aceptan la transformación y devolver el atributo KeyLength válido. 

Los ejemplos siguientes muestran la respuesta de tres sistemas diferentes para un atributo de longitud de la clave que especifica el valor absurdo de veintisiete con el triple de cifrado DES, que utiliza una clave de longitud fija. En cuanto a las respuestas, se observa el siguiente comportamiento:

Checkpoint Firewall-1 – Aceptar la transformación y devuelve la longitud de la clave misma en su respuesta, 
Concentrador Cisco VPN – No responde en absoluto, 
Nortel Contivity – Responde con una Propuesta No Elegido notificar mensaje, 
Windows 2003 – Acepta la transformada pero no devuelve un atributo de longitud de la clave.

$ Ike-scan – trans = 5/27, 2,1,2-M 10.0.0.1
A partir ike-scan 1,7 con un hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.1 Handshake Modo principal devuelto
SA = (= Enc 3DES hash SHA1 = Auth = PSK = Grupo 2: modp1024 KeyLength = 27 = LifeType LifeDuration segundos (4) = 0x00007080)
____________________________________________________________
$ Ike-scan – trans = 5/27, 1,1,2-M 10.0.0.2
A partir ike-scan 1,7 con un hosts (http://www.nta-monitor.com/ike-scan/)
____________________________________________________________
$ Ike-scan – trans = 5/27, 2,1,2-M 10.0.0.3
A partir ike-scan 1,7 con un hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.3 Notify mensaje 14 (NO LA PROPUESTA elegido)
____________________________________________________________
$ Ike-scan – trans = 5/27, 2,3,2-M 10.0.0.4
A partir ike-scan 1,7 con un hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.4 Handshake Modo principal devuelto
SA = (= Enc 3DES hash SHA1 = Grupo = 2: modp1024 Auth = rsa_sig LifeType = LifeDuration segundos (4) = 0x00007080)
VID = 1e2b516905991c7d7c96fcbfb587e46100000004 (Windows-2003-o-XP-SP2)
VID = 4048b7d56ebce88525e7de7f00d6c2d3 (IKE Fragmentación)
VID = 90cb80913ebb696e086381b5ec427b1f (draft-ietf-ipsec-nat-t-ike-02 \ n)


Codificación de longitud variable atributo para valores pequeños 

Hay dos tipos de atributo transform: atributos básicos que tienen un valor de 16-bits, y los atributos de variable cuyo valor puede ser de cualquier tamaño. Un ejemplo de un atributo variable es el tiempo de vida en segundos. 

Ike-scan enviará siempre el tiempo de vida en segundos como un atributo variable, pero el servidor devuelve a veces esto como un atributo básico si el valor se ajusta en 16 bits. Esto es permitido por RFC 2409 , que dice: Los atributos de longitud variable PUEDE ser codificado como atributos básicos si su valor puede ajustarse en dos octetos. 

Si un atributo básico se devuelve luego ike-scan mostrará el valor como un número decimal, por ejemplo LifeDuration = 28800. Si un atributo variable se devuelve, entonces ike-scan muestra el número de bytes seguidos por el valor como un número hexadecimal, por ejemplo LifeDuration (4) = 0x00007080. 

Uso de la duración predeterminada de segundo 28800, que se ajustará en 16 bits, nos encontramos con que el Concentrador Cisco VPN y Cisco PIX devolver un atributo básico para la vida, pero Checkpoint Firewall-1, Nortel Contivity y Windows 2003 devolver un atributo de longitud variable. 

El [ atributo transform pedido ] sección se detalla cómo se puede utilizar la avanzada transformar especificación para especificar un atributo, ya sea de longitud fija o variable, y para dar un atributo de longitud variable de cualquier longitud valor. 

Número máximo de transformaciones inspeccionados 

El número de transformaciones que pueden estar contenidos en una propuesta SA sólo está limitado por el tamaño máximo del datagrama IP de 64 kilobytes, que permite a aproximadamente 1800 transformaciones. Sin embargo, la mayoría de las implementaciones de IPsec sólo procesará un número limitado de transformaciones. El límite depende de la implementación, pero es generalmente mucho menor que el límite teórico. 

Esta limitación del número de transformaciones soportadas está permitido por la RFC 2409 , que establece lo siguiente: No hay límite en el número de ofertas que el iniciador puede enviar al respondedor implementaciones conformes pero puede optar por limitar el número de ofertas se inspeccionará por razones de rendimiento . 

Podemos determinar el número máximo de transformaciones que una aplicación dada se inspeccionan mediante el envío de un número de transformadas inaceptables seguido de una transformada aceptable, y variando el número de transformaciones inaceptables para encontrar el punto en el que el servidor VPN ya no acepta la propuesta. Debido a que a menudo tendrá que generar cientos de transformaciones, lo más fácil es usar un script de Perl simple para generar las opciones ike-scan. Por ejemplo, si sabemos que el servidor VPN acepta una transformación con atributos Enc = 3DES, Hash = SHA1, Auth = PSK, Grupo = 2, y no aceptará una transformación con atributos Enc = IDEA, Hash = Tiger, Auth = RSA_enc, Grupo = 5, se podría enviar una propuesta con 99 transformaciones no válidas seguida de una transformación válida para el servidor VPN en 10.0.0.1 con: print ike-scan `perl-e ‘” – trans = 2,3,4, 5 “x 99. “- Trans 5,2,1,2”; ‘`10.0.0.1. Si el servidor VPN responde con un apretón de manos, entonces sabemos que es compatible con al menos 100 transformaciones. 

Por ejemplo, con Checkpoint Firewall-1, nos encontramos con que sólo se inspeccionará un máximo de veinte transformaciones. El siguiente ejemplo muestra la respuesta de una primera Firewall-1 sistemas con veinte transformaciones (inaceptable diecinueve seguido por una aceptable) y luego con veintiuno.

Print $ ike-scan-M `perl-e ‘” – trans = 2,3,4,5 “x 19. “- Trans 5,2,1,2”; ‘`10.0.0.1
A partir ike-scan 1,7 con un hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.1 Handshake Modo principal devuelto
SA = (= Enc 3DES hash SHA1 = Auth = PSK = Grupo 2: modp1024 LifeType = LifeDuration segundos (4) = 0x00007080)

Print $ ike-scan-M `perl-e ‘” – trans = 2,3,4,5 “x 20. “- Trans 5,2,1,2”; ‘`10.0.0.1
A partir ike-scan 1,7 con un hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.1 Notify mensaje 14 (NO LA PROPUESTA elegido)

ISAKMP Responder formato de la galleta 

La respuesta del servidor contiene una cookie de respuesta. Este es un número de 64 bits, que debe ser único y no predecible. 

La mayoría de servidores VPN crear cookies respondedoras que parecen ser aleatorios para el cliente. Sin embargo, las cookies algunas implementaciones ‘respondedoras muestran una estructura reconocible. 

Por ejemplo, el Checkpoint Firewall-1 siempre utilizará una cookie con valor cero cuando se envía un mensaje de notificación:

$ Ike-scan-M 172.16.2.2
A partir ike-scan 1.8.4 con un hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2 Notify mensaje 14 (NO LA PROPUESTA elegido)
HDR = (CKY-R = 0000000000000000, msgid = d44ad35f)


Con Cisco PIX, los primero 32-bits de la cookie de respuesta son constantes para un determinado sistema de PIX: 

$ Ike-scan-M 10.0.38.226
A partir ike-scan 1.8.4 con un hosts (http://www.nta-monitor.com/tools/ike-scan/)
217.205.38.226 Handshake Modo principal devuelto
HDR = (CKY-R = ff553a4d65572e8a)
SA = (= Enc 3DES hash SHA1 = Grupo = 1: modp768 Auth = PSK LifeType = Segundos LifeDuration = 28800)

$ Ike-scan-M 10.0.38.226
A partir ike-scan 1.8.4 con un hosts (http://www.nta-monitor.com/tools/ike-scan/)
217.205.38.226 Handshake Modo principal devuelto
HDR = (CKY-R = ff553a4d957eb6cb)
SA = (= Enc 3DES hash SHA1 = Grupo = 1: modp768 Auth = PSK LifeType = Segundos LifeDuration = 28800)


Transformar orden de los atributos 

Los atributos dentro de una transformada puede estar en cualquier orden. De forma predeterminada, ike-scan enviará los atributos en el orden: 
1. Algoritmo de cifrado 
2. Hash Algorithm 
3. Método de autentificación 
4. Diffie-Hellman Group 
5. Longitud de la clave (si se especifica) 
6. LifeType (segundos o KB) 
7. LifeDuration 

Sin embargo, es posible enviar cualquier combinación de atributos en cualquier orden mediante el uso de la forma avanzada de la opción – trans como sigue:

– Trans = (attr1 = val1, val2 = attr2, …)

Los paréntesis son especiales para algunas conchas (por ejemplo bash), así que puede que tenga que incluir el valor de la opción en citas como la siguiente: – trans = “(attr1 = val1, val2 attr2 =)” 

Puede especificar tantos atributos como desee en esta forma, incluyendo sin atributos en absoluto. 

Cada atributo puede ser codificado como un atributo básico, que tiene un valor de 16 bits dando un rango de 0 a 65.535; o como un atributo de la variable, que tiene un valor de longitud variable. Para especificar un atributo básico, dar el valor como un valor decimal; para especificar un atributo variable, dar el valor en hexadecimal con un líder x 0. La longitud del valor de un atributo de longitud variable depende de la longitud del valor hexadecimal especificada después de 0 x, tan 0xff, 0x00ff, 0x0000ff y 0x000000ff todos especificar el valor 255 pero codifican como bytes de uno, dos, tres y cuatro respectivamente.

La tabla siguiente muestra los atributos que se definen en el RFC 2409 . 



Estos son algunos ejemplos utilizando CheckPoint NGX como el servidor VPN. Primero enviamos una sola transformación con atributos Enc = 3DES, Hash = SHA1, Auth = RSA, DHgroup = 2. Entonces enviamos los mismos atributos, pero en sentido inverso: DHgroup = 2, Auth = RSA, Hash = SHA1, Enc = 3DES. Ambos ordenamientos son aceptados por el servidor VPN (mayoría de las implementaciones no se preocupan por el orden de atributo), y este sistema devuelve los atributos en el mismo orden que especificaron.

$ ike-scan -r 1 –trans=”(1=5,2=2,3=3,4=2)” -M 172.16.2.2
172.16.2.2 Main Mode Handshake returned
HDR=(CKY-R=3cf85f6cc2c81a2e)
SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024)
VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d454c90cf0000000018000000 (Firewall-1 NGX)

$ ike-scan -r 1 –trans=”(4=2,3=3,2=2,1=5)” -M 172.16.2.2
172.16.2.2 Main Mode Handshake returned
HDR=(CKY-R=2c6daa3aafdf0b12)
SA=(Group=2:modp1024 Auth=RSA_Sig Hash=SHA1 Enc=3DES)
VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d454c90ee0000000018000000 (Firewall-1 NGX)


Este es otro ejemplo usando el algoritmo de cifrado AES, que tiene una longitud de clave variable. Para cifras de longitud de clave variable, el keylength se especifica como un atributo separado. En este ejemplo, especificamos una keylength de 256 bits.

$ ike-scan –trans=”(1=7,14=256,2=2,3=3,4=2)” -M 172.16.2.2
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2 Main Mode Handshake returned
HDR=(CKY-R=1796d77085c73fd7)
SA=(Enc=AES KeyLength=256 Hash=SHA1 Auth=RSA_Sig Group=2:modp1024)
VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d45e59b160000000018000000 (Firewall-1 NGX)

Aquí hay un ejemplo final, que se suma a toda una vida de 123 segundos y una vida de 456 KB. Las especificaciones de la vida cada uno consisten de un par de atributos: uno para especificar lifetype (segundos o KB) y otro para especificar la duración de la vida. Especificamos las duraciones como atributos de longitud variable de cuatro bytes, con los valores representados en hexadecimal (123 = 0x7b y 456 = 0x1c8).

$ ike-scan –trans=”(1=7,14=256,2=2,3=3,4=2,11=1,12=0x0000007b,11=2,12=0x000001c8)” -M 172.16.2.2
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
172.16.2.2 Main Mode Handshake returned
HDR=(CKY-R=a5cf73ed86ee10af)
SA=(Enc=AES KeyLength=256 Hash=SHA1 Auth=RSA_Sig Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x0000007b LifeType=Kilobytes LifeDuration(4)=0x000001c8)
VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d45e59c380000000018000000 (Firewall-1 NGX)

Respuesta a malformados o no compatible con paquetes de IKE 

Diferentes implementaciones varían en su respuesta a malformados o no compatible con paquetes de IKE. IKE-scan puede generar una gran cantidad de diferentes paquetes malformados y no conformes, y algunos de ellos podemos utilizar para el sistema de destino de la huella digital.

Usted debe tener mucho cuidado al enviar paquetes con formato incorrecto, ya que es posible se estrellara el servidor de destino, provocando una denegación de servicio. Todos los métodos que se muestra a continuación se han encontrado para ser seguro en los productos que he probado, pero no puede haber ninguna garantía. 

La sección de análisis de la implantación de IKE, muestra cómo responden estos paquetes malformados y no compatibles con sistemas que he probado y es un recurso útil cuando se trata de dispositivos de la huella digital.

Tenga en cuenta que algunos firewalls y sistemas IDS pueden ver algunos de estos paquetes malformados como firmas de ataques y bloquearlos. La funcionalidad de SmartDefense en CheckPoint Firewall-1/VPN-1 es un ejemplo de un sistema que puede hacerlo.

En general, un sistema de destino responderá en una de las siguientes maneras a un paquete con formato incorrecto o que no cumplen:

Ignorar el paquete y no responde de ninguna forma
Responde normalmente, ignorando o no verificar la parte de error 
Responder con un mensaje de notificación. 

Algunos ejemplos de paquetes de IKE malformados o no conformes son:

No transforma aceptable – una carga de SA, donde ninguna de las transformaciones tienen atributos aceptables. 
Versión de IKE mal – el número de versión en el encabezado ISAKMP no es válido. La versión principal, versión secundaria o ambos pueden ser no válidos.
DOI no válido – el dominio de la interpretación en el encabezado de SA no es válida.
Situación no válido – la situación en el encabezado de SA no es válida. 
Cookie de iniciador válido – la cookie de iniciador es cero.
Banderas no válidos – el campo de banderas en el encabezado ISAKMP no es válido
Protocolo no válido – el identificador de protocolo en la carga de la propuesta no es válido. 
SPI no válido – el tamaño del SPI en la carga de la propuesta no es válido. 
No cero campos reservados – reservados (deben ser cero o MBZ) campos en el paquete de IKE son distinto de cero.

La tabla siguiente muestra las opciones de exploración de ike que pueden utilizarse para crear estos paquetes de IKE, y lo que dicen los documentos RFC acerca de cómo debe manejar una implementación. 



Admite valores de atributo 

Implementaciones diferentes tienen diferentes valores aceptables para los atributos de transformación, y esto puede usarse para ayudar a la toma de huellas dactilares en algunas situaciones. Por ejemplo, un sistema puede apoyar algoritmos de encriptación DES y Triple-DES, mientras que otro puede apoyar sólo Triple-DES. Atributo toma de huellas dactilares de apoyo se complica por el hecho de que la mayoría de las implementaciones permite al usuario configurar los atributos de transformación aceptable, por lo que el hecho de que una aplicación determinada no soporta encriptación DES puede significar que la aplicación no puede soportarlo, o que el usuario ha desactivado esa cifra.

Un ejemplo donde atributos soportados pueden ayudar en el proceso de huellas dactilares es cuando una aplicación compatible con un valor de atributo recientes, como el cifrado AES, el algoritmo de hash SHA-512 o el grupo Diffie-Hellman 5. Si ya sabes el tipo de sistema que se trata, la presencia de un algoritmo reciente puede indicar el número de versión mínimo. Sin embargo, porque el usuario puede deshabilitar los valores de atributo, no puede determinar cualquier cosa, desde la ausencia de apoyo de algoritmo reciente.

Por ejemplo, si un sistema ha sido tomar sus huellas dactilares como Cisco PIX y se observa para apoyar AES, entonces debe ser versión 6.3 o posterior porque soporte AES fue añadida en la versión 6.3.

Otro ejemplo puede apoyo donde atributo es donde una aplicación compatible con un algoritmo inusual como el cifrado Twofish. Algunos algoritmos son suficientemente raros que pueden reducir las posibles implementaciones a sólo uno o dos posibilidades.

Transformar el atributo (enumeración)

A veces es necesario determinar la lista de atributos de transformación que aceptará el servidor VPN IPsec para IKE Phase-1. Por ejemplo, puede que necesite determinar si el servidor VPN admite cualquier cifrado cifrado débil que está prohibido por la política de seguridad de la información. 

Atributos 

Los siguientes cuatro atributos de transformación son obligatorios y por lo tanto deben estar presentes en todo se transforma:

Algoritmo de cifrado 
Algoritmo hash
Método de autenticación
Grupo Diffie-Hellman 

A veces se requieren los siguientes dos atributos: 

Longitud de la clave (sólo para cifras de longitud variable) 
Vida de SA en segundos (codificado como dos atributos: tipo de vida y la duración de la vida)

ke-scan descubre huellas dactilares de los hots IPsecIKE (servidores VPN)
ike-scan hace dos cosas: 

1) Descubrimiento: Determinar qué hosts ejecutan IKE. Esto se hace mediante la visualización de los anfitriones que respondan a las solicitudes IKE enviados por ike-scan. 
2) Huellas: Determinar qué implementación de IKE está utilizando. Hay varias maneras de hacer esto: 

(a) las huellas dactilares Backoff – el registro de los tiempos de los paquetes de respuesta IKE desde el host de destino y comparar el patrón observado retransmisión backoff contra patrones conocidos 
(b) Identificación del proveedor de huellas digitales – que coincida con el vendedor específico del proveedor IDs contra patrones conocidos Vendor ID, y (c) los códigos de mensaje de notificación de propiedad. 

El retardo de envío de retransmisión concepto de huellas dactilares se discute en más detalle en el documento de toma de huellas dactilares UDP backoff que deben ser incluidos en el kit ike-scan como udp-backoff-fingerprinting-paper.txt. 

El programa envía IKE Fase 1, las solicitudes de los hosts especificados y muestra las respuestas que se reciben. Maneja y vuelva a intentar la retransmisión de backoff para hacer frente a la pérdida de paquetes. También limita la cantidad de ancho de banda utilizado por los paquetes IKE salientes. 

IKE es la clave de protocolo de Internet de Exchange que es el intercambio de claves y el mecanismo de autenticación utilizado por IPsec. Casi todos los modernos sistemas VPN IPsec lo implementan, y la gran mayoría de IKE IPsec VPNs dan uso para el intercambio de claves. 

Fase-1 tiene dos modos: el modo principal y modo agresivo. ike-scan soporta tanto el modo principal y agresivo, y utiliza el modo principal por defecto. RFC 2409 (IKE) sección 5 se especifica que el modo principal debe ser implementado, por lo tanto, todas las implementaciones de IKE se puede esperar que soportan el modo principal

Sintaxis

ike-scan [options] [hots]

Opciones

– Help o-h Muestra este mensaje de uso y termina. 

– File = <Fn> o-f <Fn> Leer los nombres de host o direcciones a partir del archivo especificado en lugar de desde la línea de comandos. Un nombre o la dirección IP por línea. Utilice “-” para la entrada estándar. 

– Sport = <p> o s-<p> Configure el puerto de origen UDP a <p>, por defecto = 500, 0 = aleatorio. Algunas implementaciones de IKE requieren que el cliente use el puerto de origen UDP 500 y no quiere hablar con otros puertos. Tenga en cuenta que los privilegios de superusuario son normalmente requeridos para utilizar distintos de cero puertos de origen por debajo de 1024. También sólo un proceso en un sistema puede enlazar con un puerto de origen dado en un momento dado. 

– <p> Dport = o-d <p> Configure el puerto UDP destino a <p>, por defecto = 500. UDP puerto 500 es el número de puerto asignado para ISAKMP y este es el puerto utilizado por la mayoría, si no todas las implementaciones de IKE. 

– Retry = <n> o-r <n> Establecer el número total de intentos por host a <n>, por defecto = 3. 

– Timeout = <n> o-t <n> Ajuste inicial por tiempo de espera de host para <n> ms, por defecto = 500. Este tiempo de espera es para el primer paquete enviado a cada host. tiempos de espera subsiguientes se multiplican por el factor de retardo de envío que se establece con – backoff. 

– Interval = <n> o-i <n> Establecer intervalo mínimo de paquetes a <n> ms, por defecto = 75. Esto controla el uso del ancho de banda saliente mediante la limitación de la velocidad a la que los paquetes pueden ser enviados. El intervalo entre paquetes no será inferior a este número. Los paquetes salientes tienen un tamaño total de 364 bytes (20 bytes IP hdr + 8 bytes UDP HDR + 336 bytes de datos) cuando el conjunto de transformación por omisión se utiliza, o 112 bytes si una transformación personalizada especificado. Por lo tanto, por el impago conjunto de transformación: 50 = 58240bps, 36400bps 80 = y transformación personalizada: 15 = 59733bps, 30 = 35840bps. 

– Backoff = <b> o-b <b> Establecer factor de backoff tiempo de espera a <b>, por defecto = 1,50. El tiempo de espera por el huésped se multiplica por este factor después de cada tiempo muerto. Así, si el número de retrys es 3, la inicial por host de tiempo de espera es de 500 ms y el factor de retroceso es 1,5, entonces el tiempo de espera primero será de 500 ms, 750 ms la segunda y la tercera 1125ms. 

– Verbose o v- Muestra mensajes detallados del progreso. Utilice más de una vez para mayor efecto: 1 – Muestra cuando cada paso se ha completado y cuando los paquetes con galletas no válidos sean recibidos. 2 – Mostrar cada paquete enviado y recibido y cuando los anfitriones se eliminan de la lista. 3 – Muestra el host, el ID de proveedor y las listas de backoff antes de iniciarse la búsqueda. 

– Quiet o q- No decodificar el paquete devuelto. Esto imprime menos información de protocolo para que las líneas de producción son más cortos. 

– Multilínea o-M Dividir la carga de decodificación a través de varias líneas. Con esta opción, la decodificación para cada carga se imprime en una línea separada a partir de un TAB. Esta opción hace que la salida más fácil de leer, especialmente cuando hay muchas cargas útiles. 

– De por vida = <S> o-l <S> Establecer vida IKE segundo <S>, por defecto = 28800. RFC 2407 especifica 28,800 por defecto, pero algunas aplicaciones pueden requerir diferentes valores. Si se especifica 0, no toda la vida va a ser especificado. Puede utilizar esta opción más de una vez en combinación con las opciones – trans para producir múltiples cargas de Transformación con vidas diferentes. Cada opción – trans utilizará el valor de la duración especificada anteriormente. 

– LifeSize = <S> o-z <S> Establecer IKE a tamaño natural Kilobytes <S>, por defecto = 0. Si se especifica 0, no se especifica tamaño natural. Puede utilizar esta opción más de una vez en combinación con las opciones – trans para producir múltiples cargas de Transformación con lifesizes diferentes. Cada opción – trans utilizará el valor especificado anteriormente tamaño natural. 

– Auth = <n> o-m <n> Establecer auth. método para <n>, por defecto = 1 (pre-shared key). RFC valores definidos son de 1 a 5. Consulte RFC 2409 Apéndice A. Checkpoint modo híbrido es 64221. GSS (Windows “Kerberos”) es 65001. XAUTH utiliza 65001 a 65010. 

– Versión o V- Muestra la versión del programa y salir. 

– Vendor = <v> o e-<v> Establecer cadena Vendor ID para <v> valor hexadecimal. Puede utilizar esta opción más de una vez para enviar múltiples cargas útiles de identificación de los proveedores. 

– Trans = <t> o un <t> Use transformación personalizada <t> en lugar de un conjunto predeterminado. <t> se especifica como enc [/ len], hash, auth, grupo. Cuando enc es el algoritmo de cifrado, len es la longitud de la clave de cifrado de longitud variable, el hash es el algoritmo de hash, y el grupo es el grupo de DH. Consulte RFC 2409 Apéndice A para obtener más información de la que los valores de uso. Por ejemplo, – trans = 5,2,1,2 especifica Enc = 3DES-CBC, Hash = SHA1, Auth = shared key, DH Grupo 2 = y – trans = 7/256, 1,1,5 especifica Enc = AES-256, Hash MD5 =, Auth = shared key, DH Grupo = 5 Puede utilizar esta opción más de una vez para enviar un número arbitrario de transformaciones personalizadas. 

– Showbackoff [= <n>] o-o [<n>] Visualice la tabla de huellas dactilares backoff. Visualice la tabla de backoff para la implementación de IKE huella en los hosts remotos. El argumento opcional especifica el tiempo de espera en segundos después de recibir el último paquete por defecto, = 60. Si utiliza la forma corta de la opción (-o), el valor debe seguir inmediatamente la letra de opción sin espacios, por ejemplo-o25-o no 25. 

– Fuzz = <n> o-u <n> Establecer fuzz coincidencia de patrones a <n> ms, por defecto = 100. Esto establece la diferencia máxima aceptable entre los tiempos de backoff observados y los tiempos de referencia en el archivo de retardo de envío de patrones. Los valores más grandes permiten una mayor varianza, sino también aumentar el riesgo de falsas identificaciones positivas. Las especificaciones de pelusa por la entrada de patrones en el archivo de patrones anulará el ajuste de este valor. 

– Patrones = <f> o-p <f> Usar archivo de patrones de IKE <f>, por defecto = / usr / local / share / ike-scan / ike-backoff patrones. Especifica el nombre del archivo que contiene los patrones de backoff IKE. Este archivo se utiliza solamente cuando – showbackoff se especifica. 

– Vidpatterns = <f> o-I <f> Utilizar ID de proveedor patrones archivo <f>, por defecto = / usr / local / share / ike-scan / ike-vendor-ID. Especifica el nombre del archivo que contiene los patrones de proveedor de identidad. Estos patrones se utilizan para la huella dactilar Vendor ID. 

– Agresivo o-A Utilice el Modo Agresivo IKE (El valor predeterminado es el modo principal) si especifica – agresivo, entonces usted también puede especificar – dhgroup, – Identificación y – tipo_ID. Si utiliza transformaciones personalizadas con el modo agresivo con la opción – trans, tenga en cuenta que todas las transformaciones deben tener el mismo grupo de DH y esta debe coincidir con el grupo especificado con – dhgroup o si el defecto – dhgroup no se utiliza. 

– <id> Id = o-n <id> Use <id> como el valor de identificación. Esta opción sólo se aplica al modo agresivo. <id> se puede especificar como una cadena, por ejemplo – id = prueba o como un valor hexadecimal con el prefijo “0x”, por ejemplo – id = 0xdeadbeef. 

– Tipo_ID = n o in- Utilice <n> identificación del tipo. Por defecto 3 (ID_USER_FQDN). Esta opción sólo se aplica al modo agresivo. Consulte RFC 2407 4.6.2 para información sobre los tipos de identificación. 

– Dhgroup = n o gn- Utilice Diffie Hellman Group <n>. Default 2. Esta opción sólo es aplicable a modo agresivo donde se utiliza para determinar el tamaño de la carga útil de intercambio de claves. Los valores aceptables son 1,2,5,14,15,16,17,18 (MODP solamente). 

– Gssid = <n> o G-<n> Utilice GSS ID <n> donde <n> es una cadena hexadecimal. Esto utiliza transformar tipo de atributo 16384 como se especifica en draft-ietf-ipsec-isakmp-gss-auth-07.txt, aunque Windows-2000 se ha observado que usar 32001 también. En Windows 2000, tendrá que usar – auth = 65001 para especificar Kerberos (GSS) de autenticación. 

– Random-R o Aleatorizar la lista de hosts. Esta opción aleatoriza el orden de los anfitriones en la lista de hosts, de modo que las sondas IKE se envían a los anfitriones en un orden aleatorio. Se utiliza el algoritmo de barajar Knuth. 

– Tcp [= n] o-T [n] Utilice el transporte TCP en lugar de UDP. Esto le permite probar un host que ejecuta IKE sobre TCP. Normalmente, usted no tendrá esta opción porque la gran mayoría de los sistemas IPsec IKE sólo admiten a través de UDP. La <n> valor opcional que especifica el tipo de IKE sobre TCP. Actualmente hay dos valores posibles: 1 = IKE RAW a través de TCP utilizado por Checkpoint (por defecto) 2 = encapsulado IKE sobre TCP usado por Cisco. Si utiliza la forma corta de la opción (-T), el valor debe seguir inmediatamente la letra de opción sin espacios, por ejemplo-no-T2 T 2. Sólo se puede especificar un host de destino solo si se utiliza esta opción. 

– TCPtimeout = n o n-O Establecer tiempo de espera de conexión TCP en n segundos (por defecto = 10). Esto sólo es aplicable a TCP modo de transporte. 

– Pskcrack [= f] o P [f] Grieta agresivos modo claves pre-compartidas. Esta opción genera el modo agresivo clave pre-compartida (PSK) Parámetros para el craqueo fuera de línea utilizando el “psk-crack”, programa que se suministra con ike-scan. Si lo desea, puede especificar un nombre de archivo, “f”, para escribir los parámetros a PSK. Si no se especifica un nombre de archivo, los parámetros PSK se escriben en la salida estándar. Si utiliza la forma corta de la opción (-P), el valor debe seguir inmediatamente la letra de opción sin espacios, por ejemplo-no-P pfile archivos. Sólo se puede especificar un host de destino solo si se utiliza esta opción. Esta opción sólo se aplica al modo agresivo IKE. 

– Nodns o-N No utilizar DNS para resolver nombres. Si utiliza esta opción, todos los hosts se debe especificar como direcciones IP


Ejemplos

ike-scan -T 192.168.0.55

Etiquetado con:

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*