Configuración de IPsec en el router

Para que el protocolo funcione correctamente, debemos completar todos los parámetros necesarios en la configuración de nuestro router. Se recomienda completarlos en el siguiente orden, tanto por facilidad como para no cometer errores:

  1. Configuración de la Lista de Control de Acceso de IPSec
  2. Configuración de los Templates (parámetros de seguridad)
  3. Creación de la SPD

A continuación se describen los pasos para configurar el protocolo IPsec en el router, tanto en la versión CIT como en la versión Linux.

CIT

Para tener la característica de IPsec en el router se requiere una licencia del tipo 9 15. Esta lincencia nos da todas las funcionalidades de IPsec y permite su monitorización.

Linux

En linux, el programa que gobierna IPsec se llama setkey. Su sintaxis varía en función de los parámetros introducidos, pero se puede resumir de la siguiente forma:

     >setkey [-vrk] file ...                                                   
     >setkey [-nvrk] -c                                                        
     >setkey [-nvrk] -f filename                                               
     >setkey [-Palpvrk] -D                                                     
     >setkey [-Pv] -F                                                          
     >setkey [-H] -x                                                           
     >setkey [-V] [-h]

Los parámetros son los siguientes:

  • -D: Muestra la base de datos de asociaciones (SAD) activas.
  • -a: Con la opción -D no se muestran asociaciones 'muertas'. Indicando el flag -a aparecen las entradas muertas
  • -p: Muestra también los puertos
  • -F: Borra la base de datos de listas de acceso (SPD) activas.
  • -P: La acción afecta también a la base de datos de listas de acceso (SPD).Sirve para las opciones -D y -F.
  • -r: Usa las semánticas descritas en los RFCs de IPsec. Es el modo default
  • -k: Usa las semánticas descritas en el kernel.
  • -n: No hace nada, símplemente comprueba que la entrada de datos es válida.
  • -V: Muestra la versión de setkey.
  • -v: 'Be verbose'. El programa muestra todos los mensajes intercambiados por el socket PF_KEY, incluyendo los mensajes del kernel a otros procesos.
  • -l: Hace un bucle eterno mostrando los cámbios efectuados con la opción -D.
  • -x: Hace un bucle eterno mostrando los datos transmitidos por el socket PF_KEY. -xx muestra estos datos, pero incluyendo el tiempo sin formato.
  • -H: Muestra datos hexadecimales en el modo -x.
  • -h: Muestra una pequeña ayuda.
  • -?: Muestra una pequeña ayuda.
  • -c: Lee por entrada estándar las opciones de configuración
  • -f filename: Lee del fichero filename las opciones de configuración.

Esta opción -f filename es la usaremos para configurar los parámetros de configuración. Estos parámetros estarán guardados en el fichero /etc/setkey.conf

Comandos básicos

Habilitar/Deshabilitar IPsec

Para poder usar la funcionalidad de IPsec hay que habilitarla en el router. Si queremos desactivar su uso, guardando la configuracion para un posterior uso de ella. Para estas dos acciones usamos estos comandos:

CIT

Habilitar

  Config>protocol ip                                                              
                                                                              
  -- Internet protocol user configuration --                                      
  IP config>ipsec                                                                 
                                                                              
  -- IPSec user configuration --                                                  
  IPSec config>enable                                                             
  IPSec config>

Deshabilitar

  Config>protocol ip                                                              
                                                                              
  -- Internet protocol user configuration --                                      
  IP config>ipsec                                                                 
                                                                              
  -- IPSec user configuration -- 
  IPSec config>disable                                                            
  IPSec config>

Linux

Habilitar

 >setkey -f /etc/setkey.conf

Este mandato lo que hace es leer las opciones de configuración del archiv /etc/setkey.conf y aplicarlas. Esta acción se puede interpretar como “habilitar IPsec”, ya que IPsec está habilitado en Linux si el kernel está configurado para tal propósito e ipsec-tools está instalado.

Deshabilitar

 >setkey -FP

Si quisiéramos incluir esta acción en un fichero, añadiríamos las opciones flush y spdflush en nuestro archivo de configuración, tal que:

 >vi /etc/setkey.conf
 flush;
 spdflush;

Estas acciones lo que hacen es borrar la SAD y la SPD respectivamente

Se recomienda incluir flush y spdflush al principio del fichero de configuración /etc/setkey.conf para empezar con una configuración nueva, justo antes de las otras acciones que se van a realizar

Comandos para configurar las listas de control de acceso

Existe una serie de listas de control de acceso que actúan como bloques de selectores asociados a una acción (permitir o denegar). Cada lista está identificada por un único identificador.El bloque de selectores esta compuesto por una dirección IP origen (o rango de direcciones), una dirección IP destino (o rango de direcciones IP destino), un protocolo (o rango de protocolos), puertos origen y destino (o rango de puertos), y el identificador de la conexión entre interfaces por los que viajaría el paquete. No es necesario especificarlos todos, tan sólo el que se desee. La acción representa el procesamiento asignado a los paquetes coincidentes con el bloque de selectores asociado: PERMIT o DENY.

Es importante darse cuenta que la SPD especifica los elementos para los paquetes de salida exclusivamente a través de las interfaces del router. Pongamos por caso que la Máquina A se quiere comunicar con la Máquina B. Para poder hacer esta comunicación se tienen que dar los siguientes datos:

  • Máquina A : Dirección IP
  • Máquina B : Dirección IP
  • Acción :Permit (procesar IPsec)

Cualquier paquete que viaje de Máquina A a Máquina B será encapsulado de una forma determinada (de la manera que defina el template asociado). Huelga decir que a cualquier paquete que venga de Máquina B a Máquina A se le exigiría que estuviera igualmente encapsulado, creando así un túnel seguro entre ambos extremos.

Huelga decir que que es importante considerar que la direcciones IP de origen y destino vienen acompañadas por una máscara de red. Esto nos da la posibilidad de que todo el tráfico de una subred sea encriptado por IPsec (por ejemplo, poniendo IP 192.168.3.0 y máscara 255.255.255.0) o que sólo sea un host de esa subred el que mande tráfico encriptado (por ejemplo, poniendo IP 192.168.3.2 y máscara 255.255.255.255). Podemos ver la multitud de situaciones en los gráficos siguientes:

Conexión cifrada entre dos máquinas desde distintas redes

Existe una conexión cifrada entre las máquinas 192.168.1.2 y 192.168.3.4. Entre las demás máquinas no existe conexión cifrada. Para establecer una conexión cifrada lo que hacemos es crear un túnel entre los dos routers de las redes 192.168.1.0 y 192.168.3.0 sobre una red no segura; definimos unas listas de acceso entre en los dos routers de la manera siguiente:

  • Router Derecho : Una entrada con dirección de origen 192.168.1.2 y con máscara 255.255.255.255. La dirección de destino es 192.168.3.4 y con máscara 255.255.255.255. La acción es permit.
  • Router Izquierdo : Una entrada con dirección de origen 192.168.3.4 y con máscara 255.255.255.255. La dirección de destino es 192.168.1.2 y con máscara 255.255.255.255. La acción es permit.

Huelga decir que para los equipos que no se cumplan las condiciones de dirección AND máscara, la acción será deny, es decir, no se cifrará el tráfico por IPsec y la comunicación no se hará a través del tunel seguro. Por lo tanto, todos los demás equipos de las dos redes no cumplen las condiciones anteriores y su tráfico no será cifrado.

También hay que darse cuenta que si la máquina 192.168.1.2 se quiere comunicar comunicar con 192.168.3.2, esta será una conexión no cifrada, ya que no respeta las reglas de la lista de acceso del túnel.

Este ejemplo ilustra el caso de que dos usuarios máquinas intercambian información entre ellas mediante una conexión segura a nivel de IP.

Comunicación cifrada entre una máquina de una red y todas las máquinas de otra red

Existe una conexión cifrada entre las máquinas 192.168.3.4 y todas las máquinas de la red 192.168.1.0. Entre las demás máquinas no existe conexión cifrada. Para establecer una conexión cifrada lo que hacemos es crear un túnel entre los dos routers de las redes 192.168.1.0 y 192.168.3.0 sobre una red no segura; definimos unas listas de acceso entre en los dos routers de la manera siguiente:

  • Router Derecho : Una entrada con dirección de origen 192.168.1.0 y con máscara 255.255.255.0. La dirección de destino es 192.168.3.4 y con máscara 255.255.255.255. La acción es permit.
  • Router Izquierdo : Una entrada con dirección de origen 192.168.3.4 y con máscara 255.255.255.255. La dirección de destino es 192.168.1.0 y con máscara 255.255.255.0. La acción es permit.

Huelga decir que para los equipos que no se cumplan las condiciones de dirección AND máscara, la acción será deny, es decir, no se cifrará el tráfico por IPsec y la comunicación no se hará a través del tunel seguro. Por lo tanto, todos los demás equipos de las dos redes no cumplen las condiciones anteriores y su tráfico no será cifrado.En este caso, todas las máquinas de la red 192.168.1.0 están incluidas en la comunicación cifrada. De la otra red (192.168.3.0) sólo establece comunicación cifrada con 192.168.3.4.

También hay que darse cuenta que si la máquina 192.168.1.2 se quiere comunicar comunicar con 192.168.3.2, esta será una conexión no cifrada, ya que no respeta las reglas de la lista de acceso del túnel.

Este ejemplo ilustra el caso de que un usuario desde su equipo de casa quiere comunicarse con la red de la oficina, que está en otro lugar del mundo (otra red). Para ello, previamente ha configurado su router de casa y el router de la oficina para que se cree un túnel entre ellos. En otras palabras, el usuario, desde su casa ha entrado en la VPN de la empresa.

Comunicación cifrada entre todos los equipos de dos redes

Existe una conexión cifrada entre las máquinas todas las máquinas de la red 192.168.3.0 y todas las máquinas de la red 192.168.1.0. Para establecer una conexión cifrada lo que hacemos es crear un túnel entre los dos routers de las redes 192.168.1.0 y 192.168.3.0 sobre una red no segura; definimos unas listas de acceso entre en los dos routers de la manera siguiente:

  • Router Derecho : Una entrada con dirección de origen 192.168.1.0 y con máscara 255.255.255.0. La dirección de destino es 192.168.3.0 y con máscara 255.255.255.0. La acción es permit.
  • Router Izquierdo : Una entrada con dirección de origen 192.168.3.0 y con máscara 255.255.255.0. La dirección de destino es 192.168.1.0 y con máscara 255.255.255.0. La acción es permit.

En este caso, todas las máquinas de las dos redes cumplen las condiciones, y por tanto, entre las dos redes siempre habrá comunicación segura.

Este ejemplo ilustra el caso de una gran empresa que tiene sus departamentos geográficamente alejados. Lo que hace es unir las redes de sus dos departamentos mediante un túnel sobre una red no segura por el cual se transmita información cifrada.

Listas de acceso IPsec

CIT

Para acceder al menu de listas de acceso hacemos lo siguiente:

 Config> feature access-lists

Aqui podemos hacer todo lo relacionado con las listas de acceso. IPsec utiliza las listas de acceso extendidas, por tanto deberemos usar las listas comprendidas entre 100 y 1999. Para acceder a una lista determinada hacemos lo siguiente:

  Access Lists config>access-list 101
  Extended Access List 101>

Una vez aquí tenemos que definir una serie de entradas para la lista, que definen las propiedades que debe tener un paquete para que se considere que perteneciente a esa entrada y por consiguiente a esa lista. Después, esa lista de control de acceso genérica se asigna a un protocolo, en este caso, IPsec. Para cada una de estas entradas, los parametros se configuran con el comando entry <numero> , de esta manera:

  Extended Access List 101>entry 1 ?
    default           Sets default values to an existing or a new entry
    permit            Configures type of entry or access control as permit
    deny              Configures type of entry or access control as deny
    source            Source menu: subnet or port
    destination       Destination menu: subnet or port
    protocol          Protocol
    protocol-range    Protocol range
    connection        IP connection identifier (rule)
    description       Sets a description for the current entry
    ds-field          DSCP in IP packets
    label             Label for classification
    precedence        Precedence in IP packets
    tcp-specific      Tcp specific filtering
    tos-octet         TOS octet value in IP packets
    no                Negate a command or set its defaults

Los modificadores que nos interesan son:

  • permit: Tipo de acción (procesado IPSec en caso de asignar la lista a este protocolo).
  Extended Access List 101>entry 1 permit
  • deny: No llevar a cabo ningún procesado
  Extended Access List 101>entry 1 deny
  • source address: Dirección IP de origen del selector de la lista
  Extended Access List 101>entry 1 source address 192.168.1.2 255.255.255.255
  • destination address: Dirección IP de destino del selector de la lista
  Extended Access List 101>entry 1 destination address 192.168.3.2 255.255.255.255
  • description: Una descripción de la entrada de la lista (limitado a 64 caracteres y sin espacios)
  Extended Access List 101>entry 1 description tunel_para_la_prueba_1
  • no: Borra la entrada
  Extended Access List 101>entry 1 no

Linux

Para configurar las listas de acceso, lo ideal es configurar los parámetros en un fichero (se usa por defecto /etc/setkey.conf) y después llamar a setkey.

  >setkey -f /etc/setkey.conf

Agregar elemento

   spdadd [-46n] src_range dst_range upperspec policy ;
   

Esta es la sintaxis de este parámetro.Los modificadores -6 ,-4 y -n son opcionales e indican el formato en el que deben estar las direcciones.-4 requiere IPv4, -6 requiere IPv6 y -n evita la resolución FQDN y obliga a que las direcciones vayan en formato numérico. Huelga decir que setkey autodetecta el formato de las direcciones numéricas.

  • src_range y dst_range:Identifica las máquinas o conjunto de máquinas sobre las cuales se aplicará la comunicación segura. Pueden ser direcciones IPv4/IPv6 o rangos IPv4/IPv6 y pueden ir acompañadas por una especificación de puerto TCP/UDP. Esto es, si al router le llega un paquete desde una direccion comprendida en el conjunto src_range y que va dirigido a dst_range, el paquete será tratado según la política definida en policy. La especificación de src_range y dst_range puede tomar diferentes formas:
    • address : Una única direccion. Por ejemplo: 192.168.2.2. Todos los paquetes que vengan o vayan (según si está definido en sec_range o dst_range a 192.168.2.2 serán tratados según la política especificada en policy.
    • address/prefixlen:Identifica un conjunto de direcciones de una red, definida por la direccion de red y el numero de unos en la máscara de red. Un ejemplo: La red 192.168.2.0 con máscara 255.255.255.0 será expresada para definir la política como 192.168.2.0/24 . Esto es así porque la máscara de red 255.255.255.0 tiene 24 unos.Todos los paquetes que vengan o vayan (según si está definido en sec_range o dst_range a las máquinas de la red 192.168.2.0 serán tratados según la política especificada en policy.
    • address[port]: Identifica una dirección y un puerto. El puerto debe ir obligatoriamente entre corchetes y ser un valor numérico.Un ejemplo: las comunicaciones con la máquina 192.168.2.2 por el puerto 80 serán especificadas como 192.168.2.2[80].Todos los paquetes que vengan o vayan (según si está definido en sec_range o dst_range a la máquina 192.168.2.2 por el puerto 80 serán tratados según la política especificada en policy.
    • address/prefixlen[port]:Identifica un conjunto de direcciones de una red, definida por la direccion de red y el numero de unos en la máscara de red y un puerto. El puerto debe ir obligatoriamente entre corchetes y ser un valor numérico.Un ejemplo: La red 192.168.2.0 con máscara 255.255.255.0 cuyas cominicaciones se efectuan por el puerto 80 será expresada para definir la política como 192.168.2.0/24[80] . Esto es así porque la máscara de red 255.255.255.0 tiene 24 unos.Todos los paquetes que vengan o vayan (según si está definido en sec_range o dst_range a las máquinas de la red 192.168.2.0 al puerto 80 serán tratados según la política especificada en policy.
  • upperspec:Identifica la capa superior que se va a usar. Se pueden usar las nomenclaturas definidas en /etc/protocols/ como upperspec o nomenclaturas tales como ip4, icmp6 o any. Usando any la capa superior será identificada como “any protocol” (cualquier protocolo). También se puede usar un número de protocolo. También se puede especificar un tipo y/o código de ICMPv6 cuando definimos ICMPv6 como upperspec. Esta especificación debe ser puesta después de icmp6. Un tipo es separado de un código por una coma. Un código debe venir siempre especificado. Cuando un zero es especificado, el kernel lo trata como un wildcard. Por ejemplo, la siguiente política a aplicar para paquetes entrantes ICMPv6 del tipo Neighbour Solicitation (código 135) es que no se requiere IPsec para este tipo de mensajes. Sería: spdadd ::/0 ::/0 icmp6 135 -P in none .

El kernel no puede hacer distinción entre un wildcard y una mensaje ICMPv6 del tipo 0

La definición de uppersec no funciona por el momento con forwarding, dado que requiere un reensamblaje extra en el nodo que hace el forwarding (no implementado por el momento). Hay muchos protocolos definidos en /etc/protocols pero a excepción de TCP, UDP e ICMP, los demás pueden no ser adecuados para IPsec.

  • policy: Identifica la política que se tiene que aplicar a los paquetes que cumplen las reglas anteriores. Esta tiene 3 formatos:
    -P direction [priority specification] discart;
    -P direction [priority specification] none;
    -P direction [priority specification ipsec protocol/mode/src-dst/level;
    • direction : Indica la dirección del paquete. Puede ser in(entrada), out(salida) o fwd(forwarding).
    • priority specification : La inclusión de la prioridad es opcional (en la sintaxis va entre corchetes, los cuales indican un parámetro opcional). La prioridad se usa para posicionar la politica actual que se está definiendo en la tabla SPD. Se trata de un entero con signo, donde un número más grande indicará una prioridad más alta y se añadira la política cerca del principio de la lista y un número más pequeño indicará una prioridad más baja y se añadirá la política cerca del final de la lista. Las póliticas con igual prioridad se añadirán al final de cada grupo con idénticas prioridades. La prioridad se puede especificar en varios formatos:
      • {priority,prio} offset: El offset es un entero entre el rango [-2147483647,214783648].
      • {priority,prio} base {+,-] offset : Se define una prioridad a sobre una base.La base puede ser low (-1073741824), def (0), o high (1073741824).El offset es un entero sin signo y puede tener de valor máximo hasta 1073741824 para offsets positivos,y hasta 1073741823 offsets negativos.

El sistema de prioridades está disponible si se ha compilado setkey contra unos kernel-headers que soporta políticas de prioridades (Linux >= 2.2.6). Si se especifica una prioridad y el kernel no soporta políticas de prioridad se recibirá un mensaje warning indicando que no se soportan prioridades la primera vez que se utilice una prioridad.

  • Acción: Se especifica una accion para los paquetes que cumplan las condiciones anteriormente especificadas en src_range,dst_range y upperspec. Puede ser discard,none o ipsec. La acción discard descarta el paquete. La accion none hace que no se realicen operaciones de IPsec sobre el paquete. La acción ipsec hace que se realicen operaciones IPsec sobre el paquete. Por supuesto, las más interesantes son ipsec como default y none para poner reglas especiales, tal como que no aplique reglas IPsec a paquetes ICMP.
  • protocol/mode/src-dst/level: Esta parte define que regla se aplica para procesar el paquete. Está formado por diferentes parámetros:
    • protocol:Define que protocolo usar para el paquete. Puede tomar los valores ah (AH, Authentication header), esp (ESP, Encapsulating Security Payload) o ipcomp (IPComp, IP Payload Compression Protocol). Se puede encontrar más información en esta sección: Protocolo IPsec (Descripción).
    • mode: Define en que modo actua IPsec. Puede tomar los valores de tunnel (Modo Túnel) o transport (Modo Transporte).Si usamos el modo túnel (lo más común entre routers), las direcciones de principio y final de tunel deben ir especificadas en src y dst, con un guión entre ellas. Si el modo es transporte, estas direcciones pueden estar omitidas.
    • src y dst: Son las direcciones de principio (src) y final (dst) de túnel.Pueden están en formato IPv4 o IPv6.
    • level: Será una de estas opciones :default, use, require, or unique. Si el SA no está disponible en algún nivel, el kernel va a pedir al demonio de key exchange (intercambio de llaves) para que establezca el SA apropiado.
      • default: El kernel consulta el valor por defecto del protocolo que se está usando, por ejemplo, para esp, la variable esp_trans_deflev de sysctl, cuando el kernel procesa el paquete.
      • use:El kernel usa el SA asociado si hay uno disponible.Sino el kernel hace la operación normal.
      • requiere:Es necesario un SA cada vez que un paquete se ajusta a la política que se está definiendo.
      • unique:Es necesario un SA cada vez que un paquete se ajusta a la política que se está definiendo (como requiere), pero además permite definir un único SA. Si la política es una política manual, se permite definir el identificador (entre 1 y 32767) definido en el comando add (descrito más abajo, en la seccion de Configuración de la SAD), en la parte extensions, y está asociado al modificador -u.Para definirlo se el identificador se ponen dos puntos (:) después de unique y el identificador, tal como 'unique:identificador'. Si se usa el modo automatico, racoon se encargará de hacer el SA efectivo.

Cuando se quiere usar un conjunto de SAa (varias cabeceras, por ejemplo ESP sobre AH sobre IP), se pueden usar varias reglas dentro de un mismo spdadd. Por ejemplo, si queremos que haya una cabecera IP seguida de de una cabecera AH seguida de una cabecera ESP seguida de una cabecera de un protocolo superior, la regla se tiene que definir de la siguiente manera:

  esp/transport//require ah/transport//require;

El orden de las distintas partes de las reglas es extremadamente importante

Borrar elemento

  spddelete [-46n] src_range dst_range upperspec -P direction ;

Sirve para borrar un elemento de la SPD. Los modificadores -6 ,-4 y -n son opcionales e indican el formato en el que deben estar las direcciones.-4 requiere IPv4, -6 requiere IPv6 y -n evita la resolución FQDN y obliga a que las direcciones vayan en formato numérico. Huelga decir que setkey autodetecta el formato de las direcciones numéricas.

  • src_range y dst_range:Identifica las máquinas o conjunto de máquinas sobre las cuales se aplicará la comunicación segura. Pueden ser direcciones IPv4/IPv6 o rangos IPv4/IPv6 y pueden ir acompañadas por una especificación de puerto TCP/UDP. Esto es, si al router le llega un paquete desde una direccion comprendida en el conjunto src_range y que va dirigido a dst_range, el paquete será tratado según la política definida en policy. La especificación de src_range y dst_range puede tomar diferentes formas:
    • address : Una única direccion. Por ejemplo: 192.168.2.2. Todos los paquetes que vengan o vayan (según si está definido en sec_range o dst_range a 192.168.2.2 serán tratados según la política especificada en policy.
    • address/prefixlen:Identifica un conjunto de direcciones de una red, definida por la direccion de red y el numero de unos en la máscara de red. Un ejemplo: La red 192.168.2.0 con máscara 255.255.255.0 será expresada para definir la política como 192.168.2.0/24 . Esto es así porque la máscara de red 255.255.255.0 tiene 24 unos.Todos los paquetes que vengan o vayan (según si está definido en sec_range o dst_range a las máquinas de la red 192.168.2.0 serán tratados según la política especificada en policy.
    • address[port]: Identifica una dirección y un puerto. El puerto debe ir obligatoriamente entre corchetes y ser un valor numérico.Un ejemplo: las comunicaciones con la máquina 192.168.2.2 por el puerto 80 serán especificadas como 192.168.2.2[80].Todos los paquetes que vengan o vayan (según si está definido en sec_range o dst_range a la máquina 192.168.2.2 por el puerto 80 serán tratados según la política especificada en policy.
    • address/prefixlen[port]:Identifica un conjunto de direcciones de una red, definida por la direccion de red y el numero de unos en la máscara de red y un puerto. El puerto debe ir obligatoriamente entre corchetes y ser un valor numérico.Un ejemplo: La red 192.168.2.0 con máscara 255.255.255.0 cuyas cominicaciones se efectuan por el puerto 80 será expresada para definir la política como 192.168.2.0/24[80] . Esto es así porque la máscara de red 255.255.255.0 tiene 24 unos.Todos los paquetes que vengan o vayan (según si está definido en sec_range o dst_range a las máquinas de la red 192.168.2.0 al puerto 80 serán tratados según la política especificada en policy.
  • upperspec:Identifica la capa superior que se va a usar. Se pueden usar las nomenclaturas definidas en /etc/protocols/ como upperspec o nomenclaturas tales como ip4, icmp6 o any. Usando any la capa superior será identificada como “any protocol” (cualquier protocolo). También se puede usar un número de protocolo. También se puede especificar un tipo y/o código de ICMPv6 cuando definimos ICMPv6 como upperspec. Esta especificación debe ser puesta después de icmp6. Un tipo es separado de un código por una coma. Un código debe venir siempre especificado. Cuando un zero es especificado, el kernel lo trata como un wildcard. Por ejemplo, la siguiente política a aplicar para paquetes entrantes ICMPv6 del tipo Neighbour Solicitation (código 135) es que no se requiere IPsec para este tipo de mensajes. Sería: spdadd ::/0 ::/0 icmp6 135 -P in none .
  • direction : Indica la dirección del paquete. Puede ser in(entrada), out(salida) o fwd(forwarding).

Comandos para configurar los Templates (parámetros de seguridad)

Los templates son plantillas que se utilizan para definir los parámetros de seguridad del túnel creado. Es importante definir los mismos parámetros de seguridad (mismo protocolo de cifrado,SPI…) en los dos extremos del túnel para que el túnel funcione.

Escenario típico IPsec

Se puede observar en la imagen anterior que se forma un túnel IPsec sobre una red no segura. La información que se transmite sobre esa red no segura por el túnel está cifrada, por lo tanto, si alguien captura esa información por el camino de (desde un extremo del túnel hasta el otro extremo), sería incapaz de descifrar su contenido a menos que sepa la clave con la que está cifrada esa información. Podemos decir, por tanto, que la transmisión de la información es segura de un extremo a otro del túnel.

Los routers que usan el protocolo IPsec y que construyen el túnel tienen dos bases de datos cada uno en su interior (SPD y SAD). La SPD contiene las listas de acceso, que establecen en que casos se van a usar IPsec. La SAD contiene las asociaciones de seguridad que se usan para crear los túneles, es decir, todos los parámetros de seguridad que usan para configurar los túneles entre dos routers. Entre estos parámetros podemos encontrar los siguientes:

  • Dirección de origen : Dirección de origen del paquete.
  • Dirección de destino: Dirección de destino del paquete.
  • Protocolo :Que protocolo se va a utilizar en la comunicación. Si queremos autenticidad en los datos utilizaremos la cabecera AH y si queremos seguridad en los datos utilizaremos la cabecera ESP.
  • SPI: Es el número identificativo de la asociación. Este número, junto con las direcciones de inicio y fin del túnel son los únicos datos en claro disponibles del paquete. Este número servirá al router para identificar la asociación que corresponde al paquete. Una vez identificada la asociación, será descifrado mediante el algoritmo de cifrado correspondiente y el paquete original será entregado al destino correspondiente si no se ha degradado en el camino. Por tanto, el SPI es un parámetro muy importante para el correcto funcionamiento del protocolo IPsec.
  • Algoritmo y llave: Para la correcta transformación del paquete debe usarse un algoritmo y una llave apropiada. Si usáramos un algoritmo distinto o una llave distinta para descifrar que cifrar, el paquete original saldría erróneo.

Todos los parámetros anteriores constituyen una entrada en la base de datos SAD. Cuando un paquete se identifica con una de las entradas de la base de datos de las listas de acceso (SPD), se lee la SA (entrada de la base de datos SAD) asociada a esa entrada de la SPD. Es entonces cuando el paquete se transforma según la SA.

IPsec está diseñado de tal manera que los paquetes que llegan y los paquetes que salen a un punto del túnel pueden tener diferentes políticas. Analicemos el siguiente escenario planteado: Existe un túnel entre los routers 13.4.5.1 y 10.1.2.1.

  • Los paquetes que salen de 13.4.5.1 y van a 10.1.2.1 usan la política asociada al SPI 310. Los paquetes que van a 13.4.5.1 y salen de 10.1.2.1 usan la política asociada al SPI 415.
  • Los paquetes que salen de 10.1.2.1 y van a 13.4.5.1 usan la política asociada al SPI 415. Los paquetes que van a 10.1.2.1 y salen de 13.4.5.1 usan la política asociada al SPI 310.

Como se puede ver, las políticas son completamente inversas. Si para los paquetes out en el router 13.4.5.1 usamos la política asociada al SPI 310, para los paquetes en el otro extremo (router 10.1.2.1) del tipo in tendrán que usar la misma política, es decir, la asociada al SPI 310. Se aplica lo mismo para el otro caso: si para los paquetes in en el router 13.4.5.1 usamos la política asociada al SPI 415, para los paquetes en el otro extremo (router 10.1.2.1) del tipo out tendrán que usar la misma política, es decir, la asociada al SPI 415.

Esta configuración tiene la ventaja de que es muy segura. Se usan dos claves distintas: una para los paquetes de entrada y otra para los paquetes de salida. Esto le da a la comunicación una seguridad adicional, ya que si un intruso consiguiera averiguar una de las claves, sólo sabría lo que se transmite en un sólo sentido (in o out) y no sabría cual es la respuesta a la petición si puede descifrar el paquete de la petición, o no sabría a que petición se está respondiendo si ha descrifrado la respuesta. El inconveniente a esto es que es muy fácil equivocarse al escribir las reglas, ya que hay que tener mucho cuidado al invertir la regla creada en uno de los extremos para el otro extremo.

Una configuración estática típica es aquella en la que se usa el mismo SPI para la comunicación bidireccional. Un escenario podría ser el siguiente:

 Escenario normal IPsec

Analicemos el siguiente escenario planteado: Existe un túnel entre los routers 13.4.5.1 y 10.1.2.1.

  • Los paquetes que salen de 13.4.5.1 y van a 10.1.2.1 usan la política asociada al SPI 315. Los paquetes que van a 13.4.5.1 y salen de 10.1.2.1 usan la política asociada al SPI 315.
  • Los paquetes que salen de 10.1.2.1 y van a 13.4.5.1 usan la política asociada al SPI 315. Los paquetes que van a 10.1.2.1 y salen de 13.4.5.1 usan la política asociada al SPI 315.

Como se puede ver, las políticas son completamente inversas, pero usan el mismo SPI. La ventaja de esta configuración es que es muy fácil de escribir y no hay mucho peligro de confusión al escribirla. La desventaja es que no es tan segura como la anterior, ya que si un intruso consigue descifrar la clave, sabrá en que consiste la solicitud y la respuesta enviada, ya que no se utilizan diferentes claves para cada uno de los sentidos.

Comandos para la creación de la SAD

CIT

TODO

Linux

Para configurar las listas de acceso, lo ideal es configurar los parámetros en un fichero (se usa por defecto /etc/setkey.conf) y después llamar a setkey.

  >setkey -f /etc/setkey.conf 

Añadir una SA add [-46n] src dst protocol spi [extensions] algorithm ;

Esta es la sintaxis de este parámetro.Los modificadores -6 ,-4 y -n son opcionales e indican el formato en el que deben estar las direcciones.-4 requiere IPv4, -6 requiere IPv6 y -n evita la resolución FQDN y obliga a que las direcciones vayan en formato numérico. Huelga decir que setkey autodetecta el formato de las direcciones numéricas.

  • src y dst: Son las direcciones de origen y destino del tunel. Representan los endpoints del túnel.
  • protocol: Define el protocolo que se utiliza. Pueden ser los siguientes:
    • esp : ESP (Encapsulation Security Payload) basado en el RFC 2406. Es el que se utiliza habitualmente.
    • esp-old:ESP (Encapsulation Security Payload) basado en el RFC 1827. Es la implementación antigua de ESP, útil para tratar con routers viejos que no implementan el protocolo actual.
    • ah: AH (Authentication Header) basado en el RFC 2402. Es el que se utiliza habitualmente.
    • ah-old:AH (Authentication Header) basado en el RFC 1826. Es la implementación antigua de AH, útil para tratar con routers viejos que no implementan el protocolo actual.
    • ipcomp:IPComp (IP Payload Compression Protocol) basado en el RFC 2393.
    • tcp: TCP-MD5 basado en el RFC 2385.

El software original CIT es compatible con las nuevas implementaciones de ESP y AH, por lo tanto siempre usaremos las opciones esp y ah. Se puede encontrar más información sobre los protocolos ESP y AH en la sección Protocolo IPsec.

  • spi: Security Parameter Index (SPI) para el SAD y el SPD. Debe ser un número decimal o hexadecimal, que en tal caso irá precedido por '0x'.

Los valores entre 0 y 255 están reservados para uso futuro por IANA y no pueden ser usados.

  • extensions: Sirven para definir parámetros adicionales sobre la configuración. Tienen especial importancia -m y -u, aunque ninguno es obligatio. Estos parámetros son los siguientes:
    • -m mode: Sirve para definir el modo del protocolo. Se puede usar en mode los valores de tunnel (modo túnel), transport (modo transporte) o any(cualquiera). El valor por defecto es any. El valor que que nos interesa sobre todo es tunnel, ya que en este tipo de aplicaciones crearemos casi siempre un túnel.
    • -r size: Especifica el tamaño de la ventana en bytes para prevenir ataques de replay. El valor size tiene que ser un número en decimal en una palabra de 32 bits. Si size es 0 o se omite, no se hacen comprobaciones de ataques de replay.
    • -u id: Especifica el identificador de la política para hacer la la relación entre este SA y la entrada del SPD. Para más información véase la sección policy en el apartado “Configurar la SPD” de esta misma guía.
    • -f pad_option: Define el contenido del ESP padding. El valor pad_option puede ser zero-pad (todos los paddings son 0), random-pad, (contenido aleatorio del padding) o seq-pad (Una serie de números secuenciales empezando por el 1.
    • -f nocyclic-seq: No se aceptan números cíclicos en las secuencias.
    • -lh time: Define la duración “hard life time” de la SA medido en segundos (valor time).
    • -ls time: Define la duración “soft life time” de la SA medido en segundos (valor time).
    • -bh bytes: Define la duración “hard life time” de la SA medido en bytes transportados (valor bytes ).
    • -bs bytes: Define la duración “soft life time” de la SA medido en bytes transportados (valor bytes ).
  • algorithm: Es un conjunto de parámetros que sirven para definir los algoritmos que se van a usar para el cifrado/descifrado del paquete, junto con sus claves. El formato es el siguiente:
    • -E ealgo key: Especifica un cifrado para ESP. El algoritmo ealgo debe ser uno de la tabla de más abajo y la llave irá en key, debiendo esta estar denotada entre dobles comillas (en caso de ser una cadena) o precedida por '0x'.
    • -E ealgo key -A aalgo key: Especifica un cifrado para ESP, junto con el payload authentication. El algoritmo de cifrado ealgo debe ser uno de los de la tabla de más abajo y la llave irá en el primer key. El algoritmo para el payload authentication tiene que ser uno de la tabla de más abajo y la llave irá en el segundo key.
    • -A aalgo key: Especifica con que algoritmo se debe hacer la comprobación de autenticidad para AH. El algoritmo aalgo debe ser uno de los de la tabla de más abajo y la llave irá en key.

A continuación se especifican los algoritmos de cifrado para ESP, a incluir en el campo ealgo:

         algorithm       keylen (bits)
         des-cbc         64              esp-old: rfc1829, esp: rfc2405
         3des-cbc        192             rfc2451
         null            0 to 2048       rfc2410
         blowfish-cbc    40 to 448       rfc2451
         cast128-cbc     40 to 128       rfc2451
         des-deriv       64              ipsec-ciph-des-derived-01
         3des-deriv      192             no document
         rijndael-cbc    128/192/256     rfc3602
         twofish-cbc     0 to 256        draft-ietf-ipsec-ciph-aes-cbc-01
         aes-ctr         160/224/288     draft-ietf-ipsec-ciph-aes-ctr-03

A continuación se especifican los algoritmos de hash para AH, a incluir en el campo aalgo. Estos algoritmos se deben usar también para calcular el hash del payload authentication de ESP. Son los siguientes:

         algorithm       keylen (bits)
         hmac-md5        128             ah: rfc2403
                         128             ah-old: rfc2085
         hmac-sha1       160             ah: rfc2404
                         160             ah-old: 128bit ICV (no document)
         keyed-md5       128             ah: 96bit ICV (no document)
                         128             ah-old: rfc1828
         keyed-sha1      160             ah: 96bit ICV (no document)
                         160             ah-old: 128bit ICV (no document)
         null            0 to 2048       for debugging
         hmac-sha256     256             ah: 96bit ICV
                                         (draft-ietf-ipsec-ciph-sha-256-00)
                         256             ah-old: 128bit ICV (no document)
         hmac-sha384     384             ah: 96bit ICV (no document)
                         384             ah-old: 128bit ICV (no document)
         hmac-sha512     512             ah: 96bit ICV (no document)
                         512             ah-old: 128bit ICV (no document)
         hmac-ripemd160  160             ah: 96bit ICV (RFC2857)
                                         ah-old: 128bit ICV (no document)
         aes-xcbc-mac    128             ah: 96bit ICV (RFC3566)
                         128             ah-old: 128bit ICV (no document)
         tcp-md5         8 to 640        tcp: rfc2385

Modelo de configuración

  #!/sbin/setkey -f
  
  # Flush the SAD and SPD
  flush;
  dump;
  
  # Extremos de los  tuneles
  add 192.168.2.1 192.168.2.2                    
  esp 0x118                                                             
  -m tunnel                                                             
  -E 3des-cbc 0x68353373343565663436616776343634366E326A3871706F        
  -A hmac-sha1 0x623734686437343867687A6D36376B366D366431;        
           
  add 138.100.200.1 138.100.200.2
  esp 0x119                                            
  -m tunnel                                            
  -E 3des-cbc 0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
  -A hmac-sha1 0xBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB; 
                                                  
  # add <dir_origen_tunel> <dir_destino_tunel>                                                          
  # esp es el tipo de cabecera (de momento siempre igual) y luego va acompanado por 0xnnn (5 caracteres)
  # -m tunnel no varia                                                          
  # -E toma los siguientes valores 3des-cbc(50),des-cbc(18),blowfish-cbc(12-122) y luego la clave en hex
  # -A toma los siguientes valores hmac-sha1(42),hmac-md5(34) y luego la clave en hex
  # al final punto y coma (en la linea anterior)
 
proyectos/teldatsi/teldatsi/protocolos_de_comunicaciones/configuracion_ipsec_manual.txt · Última modificación: 2012/10/08 17:58 (editor externo)
 
Recent changes RSS feed Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki