[OpenBSD]

[Volver al índice principal] [Sección 12.0 - Para usuarios avanzados] [Sección 14.0 - Uso de discos en OpenBSD]

Partes de este documento proceden de:

13.0 - Uso de IPSec (Protocolo de Seguridad de IP)

13.1 - ¿Qué es IPSec?

IPSec es un grupo de extensiones de la familia del protocolo IP. IPSec provee servicios criptográficos de seguridad. Estos servicios permiten la autenticación, integridad, control de acceso, y confidencialidad. IPSec provee servicios similares a SSL, pero a nivel de redes, de un modo que es completamente transparente para sus aplicaciones y mucho más robusto. Es transparente porque sus aplicaciones no necesitan tener ningún conocimiento de IPSec para poder usarlo. Puede usar cualquier protocolo IP sobre IPSec. Puede crear túneles cifrados (VPNs), o simple cifrado entre computadoras (ordenadores). Debido a que dispone de tantas opciones, IPSec es más bien complejo (¡mucho más que SSL!).

Antes de empezar a usar IPSec, le recomendamos encarecidamente que mire la «lectura recomendada» de la sección 6 de las preguntas frecuentes. En particular, si todavía no lo entiende, el documento Understanding IP Addressing es muy recomendable.

De un modo lógico, IPSec funciona en cualquiera de estos tres modos:

En cualquier escenario en el que haya una red, el concepto de enrutador está implícito, como en Huésped-a-Enrutador (y este enrutador controla y cifra el tráfico para una Red particular).

Como puede ver, IPSec se puede usar como túnel de tráfico para conexiones de «Redes Privadas Virtuales» (VPN, "Virtual Private Networks"). Sin embargo, su utilidad va más allá de las VPNs. Con un registro central de «Intercambio de Claves de Internet» (IKE, "Internet Key Exchange"), cada máquina en internet podría comunicarse con otra y usar cifrado y autenticación fuerte.

13.2 - Está bien pero, ¿para qué querría usar IPSec?

El protocolo de internet, IP, también conocido como IPv4, no provee por sí mismo de ninguna protección a sus transferencias de datos. Ni siquiera puede garantizar que el remitente sea quien dice ser. IPSec intenta remediarlo. Estos servicios vienen tratados como dos servicios distintos, pero IPSec ofrece soporte para ambos de un modo uniforme.

Confidencialidad

Asegúrese de que sea difícil para todos comprender qué datos se han comunicado, excepto para el receptor. No querrá que nadie vea sus contraseñas cuando ingrese en una máquina remota a través de Internet.

Integridad

Garantice que los datos no puedan ser cambiados en el camino. Si se encuentra en una línea que lleve datos sobre facturación, seguro que querrá estar seguro de que las cantidades y cifras de contabilidad son las correctas, y que no han podido ser alteradas durante el tránsito.

Autenticidad

Firme sus datos de modo que otros puedan verificar que es realmente Vd. quien los envió. Es agradable saber que los documentos no son falsos.

Protección a la réplica

Necesitamos modos para asegurarnos de que una transacción sólo se puede llevar a cabo una vez, a menos que autoricemos que la repitan. Nadie debería poder grabar una transacción, y luego replicarla al pie de la letra, con el propósito que pareciera como si se hubieran recibido múltiples transacciones del remitente original. Imagine que el atacante deba conocer cuál es el motivo del tráfico por medios distintos al de poder descifrarlo, y que el tráfico causara sucesos favorables para él, como depositar dinero en su cuenta. Tendríamos que asegurarnos que no pudiera replicar ese tráfico más tarde. AVISO: tal y como lo especifica la normativa, la protección a la réplica no se llevará a cabo cuando se use el sistema de claves manuales de IPSec (v.g., cuando se esté usando ipsecadm(8)).

13.3 - ¿Cuáles son los protocolos detrás de IPSec?

IPSec provee confidencialidad, integridad, autenticidad, y protección a la réplica a través de dos nuevos protocolos. Estos protocolos se llaman «Cabecera de Autenticación» (AH, "Authentication Header") y «Cargo de Seguridad Encapsulado» (ESP, "Encapsulated Security Payload").

AH provee auntenticación, integridad, y protección a la réplica (pero no confidencialidad). Su principal diferencia con ESP es que AH también asegura partes de la cabecera IP del paquete (como las direcciones de origen o destino).

ESP puede proveer autenticación, integridad, protección a la réplica, y confidencialidad de los datos (asegura todo lo que sigue a la cabecera en el paquete). La protección a la réplica requiere autenticación e integridad (éstas dos van siempre juntas). La confidencialidad (cifrado) se puede usar con o sin autenticación y/o integridad. Del mismo modo, puede usar la autenticación y/o la integridad con o sin la confidencialidad.

13.4 - Sobre el formato "wire"

La Cabecera de Autenticación (AH) viene de la cabecera básica IP y contiene resúmenes criptográficos ("hash") de los datos e información de identificación. Los resúmenes criptográficos también pueden cubrir las partes invariables de la misma cabecera de IP. Hay varios RFCs diferentes que ofrecen una elección de algoritmos para AH, sin embargo todos deben seguir las líneas especificadas en el RFC2402.

La cabecera del Cargo de Seguridad Encapsulado (ESP) permite reescribir el cargo en modo cifrado. La cabecera ESP no considera los campos de la cabecera IP que van delante, y por lo tanto no garantiza nada excepto el cargo. Los distintos tipos de ESP aplicables deben seguir conformar con el RFC2406. Una cabecera ESP también puede proveer autenticación para el cargo (pero no la cabecera exterior).

Una división ortogonal (en su mayor parte) de funcionalidad de IPSec, se aplica dependiendo de si el extremo que está llevando a cabo la encapsulación IPSec es la fuente original de los datos o una pasarela:

Los enlaces seguros de IPSec se definen en términos de «Asociaciones de Seguridad» (SAs). Cada SA viene definida por un único flujo unidireccional de datos, y por regla general (ignorando multicast) desde un único punto hasta otro, cubriendo el tráfico que se distingue por algún «selector único». Todo el flujo de tráfico sobre un único SA se trata del mismo modo. Algo del tráfico puede estar sujeto a varios SAs, cada uno de los cuales aplica algún tipo de transformación criptográfica. Un grupo de SAs se conoce como un «Haz» ("SA Bundle"). Los paquetes entrantes se pueden asignar a un SA particular por medio de los tres campos de definición:

SPI se puede considerar como un "cookie" manejado por el receptor del SA, cuando se negocian los parámetros de la conexión. El protocolo de seguridad debe ser AH o ESP. Debido a que la dirección IP del receptor es parte del trío, ésta es un valor único garantizado. Se pueden encontrar desde la cabecera IP exterior y la primera cabecera de seguridad (que contiene el SPI y el protocolo de seguridad).

Un ejemplo de un paquete AH en modo túnel es:

IPhdr AH IPhdr2 TCPhdr datos

Un ejemplo de un paquete AH en modo transporte es:

IPhdr AH TCPhdr datos

Debido a que una cabecera ESP no puede autenticar la cabecera IP exterior, es útil combinar una cabecera AH y una ESP para obtener lo siguiente:

IPhdr AH ESP TCPhdr datos

A esto se le llama «Adyacencia de Transporte». La versión del túnel sería algo así:

IPhdr AH ESP IPhdr2 TCPhdr datos

Sin embargo, no se menciona en el RFC. Como ocurre con la adyacencia de Transporte, esto autenticaría todo el paquete excepto unas cuantas cabeceras de la cabecera IP, y también cifraría la carga (en el ejemplo, en bastardilla). Cuando una cabecera AH y una ESP se aplican juntas directamente como en este caso, el orden de las cabeceras debería ser como el que se ha mostrado. En modo túnel es posible hacer encapsulación recursiva arbitraria para que no se especifique el orden.

13.5 - Configuración de IPSec

La forma en la que se configuran los sistemas IPSec y las pasarelas es, hasta un cierto punto, trabajo del diseñador; sin embargo, el RFC contiene algunas recomendaciones importantes sobre cómo se debería implementar para evitar al máximo la confusión.

Existen dos entidades administrativas que controlan lo que le ocurre a un paquete. Una es la «Base de Datos de Asociación de la Seguridad» (SAD, "Security Association Database", llamado TDB o tabla TDB en el código fuente de IPSec de OpenBSD), y el otro es la «Base de Datos de Política de la Seguridad» (SPD, "Security Policy Database").

Las dos se parecen en que, dado un número de selectores que describan algo de tráfico, entregarán una entrada que describa el proceso necesario. Sin embargo, SPD se elimina a dos pasos del proceso: SPD se usa para paquetes salientes, para decidir qué entradas SAD se deben usar, y qué entradas SAD describen el proceso y sus parámetros. Las entradas SPD especifican las entradas SAD existentes a usar (si es un «haz» puede haber más de una), pero si no hay una que se pueda usar, entonces se usa para crear otras nuevas. Los campos de SA que se crean se pueden tomar de la entrada SPD o del paquete que inició la creación.

Los paquetes salientes van desde la entrada SPD a la especificada de SA, para obtener parámetros de codificación. Los paquetes entrantes obtienen la SA correcta directamente, usando el trío SPI/DestIP/Protocolo, y de ahí van a la entrada SPD.

SPD también puede especificar qué tráfico debería circunvalar IPSec, y cuál se debería dejar caer, así que también debe ser consultado para tráfico no IPSec entrante. Las entradas SPD se deben ordenar de forma explícita, ya que varias podrían coincidir con un paquete particular, y el proceso debe ser reproducible.

Se puede pensar en SPD como algo parecido a un filtro de paquetes, en el que las acciones que se deciden son la activación de procesos SA. Los selectores pueden incluir direcciones de origen y destino, números de puertos si fueran relevantes, nombres de anfitriones, niveles de sensibilidad de seguridad, protocolos, etc...

Una entrada SAD incluye:

Una entrada SPD contiene:

Cada SA puede definir una cabecera ESP y una cabecera AH. Una sesión de IPSec debe tener una de las dos o ambas, pero no se puede definir sin ninguna de las dos (en caso contrario no habría cabeceras para especificar el SPI que deba buscar la SA). El RFC no dice qué sucedería si las cabeceras AH y ESP estuvieran en desacuerdo sobre el valor de SPI. Se puede pensar que esto implicaría múltiples SAs en un haz.

En OpenBSD, SPD se gestiona a través de la orden ipsecadm flow (sólo se cambiaría si estuviera usando el sistema de claves manual). Las entradas de SAD se pueden configurar manualmente con ipsecadm(8), sin embargo el IETF también ha definido mecanismos automáticos para la iniciación de sesiones y otras cosas como el intercambio de claves. OpenBSD implementa Photuris (RFC2522 y RFC2523) e intercambio automático de claves ISAKMP (RFC2407, RFC2408, y RFC2409) en los dæmons photurisd(8) e isakmpd(8).

13.6 - ¿Cómo configuro IPSec con el sistema de «claves manuales»?

El sistema de claves manuales es el más sencillo para empezar con IPSec. Con este método puede activar los sistemas criptográficos de cifrado entre redes y crear VPNs. Después de que haya leido esta sección, puede investigar cómo configurarlo de forma automática mediante el uso de /usr/share/ipsec/rc.vpn.

Para empezar debe activar las opciones IP AH e IP ESP en el núcleo del sistema de OpenBSD (si sólo está usando ESP, como con el guión rc.vpn, entonce no necesita activar AH; de hecho, puede haber problemas relacionados con la seguridad activando AH si no lo está usando).

Hay un sysctl para activar estos protocolos:

Puede editar /etc/sysctl.conf para activarlos durante el arranque. Para ello borre la marca de comentario # que verá delante de la línea net.inet.esp.enable y/o net.inet.ah.enable (dependiendo de cuál vaya a usar) y asegúrese de que estén configuradas con el valor 1.

También tendrá que generar sus claves manuales. Como la seguridad del VPN se basa en que estas claves no se puedan «adivinar», es muy importante escoger las claves usando una fuente aleatoria fuerte. Un método práctico de generarlas es usar el dispositivo random(4). Por ejemplo, para producir 160 bits de aleatoriedad, ponga:

El número de bits producidos es importante. Tipos de cifrado diferentes pueden requerir claves de tamaños también diferentes. 
Algoritmo	Tamaño
de cifrado	de la Clave
----------	-----------
DES		56 bits
3DES      	168 bits
BLF	        Variable (40-160, 160 bits recommended)
CAST    	Variable (40-128, 128 bits recommended)
SKIPJACK  	80 bits

Ahora tiene que configurar las SAs («Asociaciones de Seguridad»). Una SA es una combinación de sus direcciones IP, un SPI, y su protocolo de seguridad (AH y/o ESP). Las direcciones IP son la suya y la de su destino. El SPI («Índice del Parámetro de Seguridad») es un número que OpenBSD usa para clasificar distintas SAs.

En estos ejemplos sólo se usa ESP para cifrar su tráfico. ESP incluye la autenticación de los datos cifrados contenidos, pero no autentica la cabecera IP a su alrededor. Esta «autenticación limitada» es, sin embargo, suficiente para la mayoría de casos, especialmente para ESP en un entorno de túneles.

Llevémoslo a la práctica con dos enrutadores, 192.168.5.1 y 192.168.25.9.

En el anfitrión 192.168.5.1:

En el anfitrión 192.168.25.9:

Nótese que los SPI son distintos. Vea la sección Sobre el formato "wire" para una descripción completa sobre qué es el SPI y sobre dónde se está usando.

Ahora que ya tiene sus Asociaciones de Seguridad en su sitio, configure sus flujos.

En 192.168.5.1:

Aquí se crearán dos flujos, uno será la dirección de origen local, que cubrirá todos los paquetes que originen del anfitrión local hacia el destino, y el otro será el flujo de vuelta desde el destino hasta el anfitrión local.

En 192.168.25.9:

Si no necesita tanta carga en sus VPN Huésped-a-Huésped puede crear el SPI sin -forcetunnel, lo que le permitirá usar el modo de transporte (mientras que -forcetunnel asegura que todo en el paquete IP, incluida la cabecera IP, sea encapsulado por SPI). Si el origen o el destino es una red, tendrá que usar el modo de túnel. Crear una SA hacia o desde una red le asegurará automáticamente que se estén creando los SPI en modo túnel.

Éste es un método simple para empezar a usar IPSec.

Puede usar IPSec para pasar los espacios de direcciones IP privados por túneles en Internet. He aquí un buen ejemplo: Queremos pasar 192.168.99.0/24 (que se encuentra detrás de 208.1.1.1) por túneles a 208.1.2.0/24 y 208.1.5.0/24 (que están detrás de 208.2.2.2). Estos ejemplos se han generado usando el guión rc.vpn.

Como puede ver, cuando está usando el sistema de claves manuales con IPSec tiene que especificar con exactitud lo que quiere hacer. No lo adivinará por usted. Mire estos ejemplos:

En 208.1.1.1:

Primero configure las asociaciones de seguridad (SA):
(esto configura los SPI, métodos de cifrado, y claves)

A continuación configure un flujo desde 208.1.1.1 hasta 208.2.2.2 Configure un flujo desde 208.1.2.0/24 (que está detrás de 208.2.2.2) hasta 192.168.99.0/24 Configure un flujo desde 208.1.5.0/24 (que está detrás de 208.2.2.2) hasta 192.168.99.0/24 Configure un flujo desde 208.1.2.0/24 (que está detrás de 208.2.2.2) hasta el enrutador 208.1.1.1 Configure un flujo desde 208.1.5.0/24 (que está detrás de 208.2.2.2) hasta el enrutador 208.1.1.1 Finalmente, configure un flujo desde el enrutador 208.2.2.2 hasta el 192.168.99.0/24

En 208.2.2.2:

Al igual que antes, configuramos las SA...

Ahora, ésta es la parte al inverso... Configure un flujo desde el enrutador 208.2.2.2 hasta el 208.1.1.1 Configure un flujo desde la red 192.168.99.0/24 (que está detrás de 208.1.1.1) hasta 208.1.2.0/24 Configure un flujo desde la red 192.168.99.0/24 (que está detrás de 208.1.1.1) hasta 208.1.5.0/24 Configure un flujo desde 192.169.99.0/24 (que está detrás de 208.1.1.1) hasta el enrutador 208.2.2.2 Ya casi hemos terminado... Quedan dos flujos para obtener 208.1.2.0/24 y 208.1.5.0/24 desde el enrutador 208.2.2.2 hasta el enrutador 208.1.1.1

Si ha usado ipsecadm, y quiere librarse de cualquier trabajo que haya hecho y empezar desde cero, haga

Esto limpiará toda la información de IPSec (SPIs, flujos, entradas de enrutamiento) de su sistema.

13.7 - ¿Cómo configuro photurisd?

El uso de photuris no está tan extendido y por lo que concierne al estado del RFC, se considera experimental. Sin embargo, muchas personas lo han usado con OpenBSD.

Para configurar photurisd, primero edite /etc/photuris/secrets.conf en cada anfitrión con photurisd.

Cambie "This should be changed." por una clave de su elección en el fichero de configuración local, y otra clave de su elección en el fichero de configuración remota (use la misma configuración en su máquina remota pero cambie el lugar de "local" por el de "remote", y viceversa, para que se vea a sí misma como la clave local). Note que estas claves serán substituidas en una versión futura de photurisd que llevará a cabo su intercambio inicial de claves con claves públicas.

Asegúrese de que net.inet.ah.enable está configurado al valor 1.

Y ejecute startkey. Ahora ejecute tcpdump para verificar que sus paquetes estén siendo cifrados con AH (ejecute ping en otra ventana o sesión para generar tráfico).
También puede intentar usar tcpdump por la dirección del anfitrión si no obtiene nada.
Puede hacer que photurisd configure el origen y el destino del anfitrión o redes en /etc/photuris/photuris.startup

13.8 - ¿Cómo configuro isakmpd?

Si está pensando en VPNs u otras aplicaciones tradicionales de IPSec, probablemente vaya a usar ISAKMP. Algunas implementaciones comerciales de IPSec no proveen ningún tipo de sistema de claves manual, y en su lugar requieren que use algún tipo de ISAKMP.

13.8.1 - ¿Qué es isakmpd?

ISAKMP, también conocido como «Intercambio de Claves por Internet» (IKE, "Internet Key Exchange") es el mecanismo de intercambio para la VPN. ISAKMP aborda los problemas de seguridad usando los métodos mencionados en los RFC 2407, 2408 y 2409. ISAKMP gestiona el intercambio de claves criptográficas que normalmente tendría que gestionar usted con ipsecadm(8). Para ello hace uso de un proceso en dos fases para establecer parámetros de IPSec entre dos nodos de IPSec.

Fase 1 - Los dos extremos de conexiones ISAKMP establecen un canal seguro, autenticado, sobre el cual se comunican entre dos dæmos. Ésto establece una Asociación de Seguridad (SA) entre ambos anfitriones. Los métodos usados para establecer este canal son el Modo Principal y el Modo Agresivo. El Modo Principal envía la variada información sobre autenticación en una cierta secuencia, al tiempo que provee protección para la identidad. El Modo Agresivo no provee esta protección a la identidad porque toda la información sobre la autenticación se envía al mismo tiempo. El modo agresivo sólo se debería usar en casos en los que preocupe el ancho de banda de la red.

Fase 2 - Las Asociaciones de Seguridad se negocian en nombre de IPSec. La fase 2 establece túneles o SAs términos entre anfitriones IPSec. El Modo Rápido se usa en la fase 2 porque no es necesario repetir una autenticación total debido a que la fase 1 ya ha establecido las SA.

Resumiendo, la fase 1 se usa para obtener un canal seguro en el que llevar a cabo las configuraciones (más rápidas) de la fase 2. Puede haber múltiples configuraciones de la fase 2 en el mismo canal que la fase 1. La fase 2 se usa para configurar los túneles. En la fase 1, sus nodos de IPSec establecen una conexión en la que intercambian autenticación (bien sea un certificado X509 ó un secreto precompartido). Esto permite que cada extremo se asegure de que el otro extremo sea autenticado. La fase 2 es un intercambio de claves que determinan cómo se cifran los datos entre los dos.

13.8.2 - ¿Cómo empiezo con isakmpd?

OpenBSD viene con los binarios para ISAKMP y para todo IPSec por definición, pero no con los ficheros de muestra. Para obtenerlos necesita bajarse /usr/src/sbin/isakmpd/samples/VPN-east.conf y /usr/src/sbin/isakmpd/samples/policy del árbol de fuentes. Puede usar su CD (si tiene uno), cvsweb, o el cliente de CVS en la línea de órdenes (Cvsweb tiene VPN-east.conf y policy disponibles). Para este ejemplo, copie policy a /etc/isakmpd/isakmpd.policy, y VPN-east.conf a /etc/isakmpd/isakmpd.conf. Intentaremos mostrarle cómo configurar una VPN (túnel). Si desea usar isakmpd entre anfitriones únicos, hay otros ficheros de configuración en el directorio samples. Las páginas de manual contienen información detallada. No se olvide de isakmpd.conf(5) e isakmpd.policy(5).

Su primer paso es activar ESP. Al principio de la sección 13.6 se explica cómo hacerlo, tanto durante el arranque como con el sistema funcionando. Después debe editar /etc/isakmpd.policy. Este fichero indica a ISAKMP quién puede acceder a IPSec. En este ejemplo, el fichero policy indica que cualquiera que envíe datos usando ESP, y que se haya autenticado con la contraseña mekmitasdigoat (o cualquier otra contraseña que Vd. determine), puede comunicarse con isakmpd. Puede modificar este fichero para indicar a ISAKMP que sólo quiere permitir datos firmados con ciertos certificados digitales o usando una cierta transformación de cifrado. También puede permitir el acceso a IPSec a cualquiera. Esto sólo es recomendable para pruebas. Para ello, edite su fichero policy para que contenga sólo las siguientes líneas:

El mismo fichero policy contiene dos líneas que empiezan con el carácter $. Debe eliminar esas líneas antes de usarlo, son sólo para cvs.

Un fichero policy más útil para este ejemplo sería:

Implementando esto obtendrá solamente una VPN (túnel) básica que use ESP. En el anfitrión A, edite /etc/isakmpd/isakmpd.conf. La dirección IP de muestra 249.2.2.2, debe ser reemplazada con la dirección IP externa del anfitrión A. Haga algo parecido con isakmpd.conf en el anfitrión B. 249.3.3.3 representa la dirección IP externa para el anfitrión B.

Aquí es donde puede configurar las variables que afectarán al comportamiento principal de isakmpd. El uso de los predefinidos aquí es correcto. El valor Listen-on= especifica el IP en el que isakmpd debe estar a la escucha. Sólo es necesario el IP de Internet de su pasarela. Si tiene interfaces múltiples externas en su pasarela, podría especificar una lista de las interfaces en las que quiere que esté a la escucha, introduciéndolas, separadas por comas, en una lista.

A continuación, en el anfitrión A, edite isakmpd.conf otra vez:

Y en el anfitrión B:

Esta sección describe qué direcciones IP se deben aceptar para negociar la conexión de la fase 1. Su valor señala a la sección de más abajo (recuerde que la fase 1 sólo autentica la conexión remota para asegurar que sean quienes afirman ser). Puede dar una lista de múltiples direcciones con líneas adicionales en el formato IP_Address= <PEER-NAME>..

A continuación, en el anfitrión A:

Y en el anfitrión B:

Esto describe la fase 2 de la conexión. Ésta es la fase que determina qué protocolos usarán las dos partes para comunicarse.

El indicador Connections= se refiere a la sección de más abajo. Inicia los requisitos o los métodos aceptados para activar la fase 2. También le indica a ISAKMPD qué conexiones debe iniciar una vez haya comenzado. Puede tener secciones múltiples, como se ilustra abajo, si va a conectar con múltiples anfitriones.

Si no tiene la dirección IP del anfitrión remoto, puede especificar un Default= que señale a una sección que describa una entrada genérica que servirá de referencia para cualquier IP entrante que no esté en la lista del indicador Connections=.

En el anfitrión A:

En el anfitrión B: Éstas representan las secciones a las que se refiere en la sección anterior sobre la fase 1. Cada una de ellas describe los requisitos que debe cumplir la pasarela del extremo que intenta conectar, para proceder a la fase 2. Aquí hay muchas otras opciones, pero las que se mencionan son los requisitos mínimos.

En el anfitrión A:

En el anfitrión B:

Éstas representan las secciones a las que se refiere en la sección anterior sobre la fase 2. Son las configuraciones individuales que ISAKMPD debe usar para hablar entre las dos pasarelas de la conexión.

Ésta es la sección de IPSec-ID. Estas entradas deben existir en los ficheros isakmpd.conf del anfitrión A y del anfitrión B. Este ejemplo configurará 192.168.1.0/255.255.255.0 para el anfitrión A (que se conectó arriba a Net-A) y 192.168.20.0/255.255.255.0 para el anfitrión B (arriba Net-B).

Estas dos secciones están en el fichero de configuración de cada anfitrión. Son las secciones a las que se hace referencia en los identificadores Local-ID y Remote-ID. Describen las rutas que se deben configurar para permitir el paso del tráfico desde una red privada hasta otra. ID-type= puede ser IPV4_ADDR_SUBNET o IPV4_ADDR (RFC2708 menciona más valores posibles. En la actualidad sólo hay soporte en la implementación de OpenBSD para IPv4. El soporte para IPv6 puede estar en OpenBSD-current).

Ahora, en ambos anfitriones, el fichero de muestra debería ser:

Esta sección describe los requisitos para los métodos de cifrado de las conexiones de la fase 1. El nombre refleja el valor de la variable Configuration=. Como se puede ver aquí, estamos indicando nuestro Dominio de Interés, que es IPSec. La variable EXCHANGE_TYPE está configurada con el valor ID_PROT para la fase 1, que identifica los protocolos que cubrirá esta autenticación. Transforms= es la transformación criptográfica requerida (o asignada) para este intercambio. En este caso señala a la sección de abajo en el fichero de configuración, que indica que estamos recibiendo un paquete cifrado con 3DES y una suma de comprobación verificable con SHA. Hay muchas transformaciones criptográficas definidas en el fichero de muestra VPN-east.conf. Éstas se proveen porque 3DES y SHA no siempre tienen soporte en las diferentes plataformas. Para OpenBSD no hay razón para cambiar esta configuración básica. Si desea crear copias de esta sección y cambiar la variable Transforms=, puede hacerlo. El único requisito es que cambie la variable Configuration=.

Esta sección describe los requisitos para el cifrado de los datos que se envían a través de la VPN, y la referencia a ella está arriba en Configuration. Note que la diferencia entre esta sección y su equivalente en la fase 1 anterior es que EXCHANGE_TYPE es QUICK_MODE. Suites= señala a una sección Suite de IPSec que describe los distintos esquemas de cifrado disponibles entre los dos anfitriones. Se podría decir mucho más sobre ISAKMP e IPSec, pero usando las descripciones básicas que hemos mencionado debería ser capaz de crear una VPN simple pero sólida, que se cuidara de sí misma. Esto es el mínimo indispensable de isakmpd.conf para ambos anfitriones.

13.8.3 - Iniciar isakmpd

Puede usar

la primera vez que decida invocar este dæmon. El dæmon no funcionará en modo dæmon, sino como un proceso regular. Grabará todo en su terminal. Para parar isakmpd y limpiar las rutas, tiene que matar el proceso isakmpd en cada modo, y ejecutar ipsecadm flush.

13.9 - ¿Cómo uso isakmpd con certificados X.509?

Configurar isakmpd para el uso de certificados en lugar de claves precompartidas no es mucho más difícil en una gran red con muchas conexiones entrantes no fiables de lo que sería en una pequeña red. En realidad puede simplificar la configuración, y más importante, la gestión de claves.

Generación de cerfificados

Hay una buena descripción sobre cómo generar claves y certificados en el fichero README.PKI del directorio de fuentes de isakmpd. Debe tener una clave CA, el correspondiente certificado CA X.509, una clave privada para cada máquina en la red que use isakmpd, y un certificado X.509 para cada una de esas claves.

Los certificados X.509 necesitan tener una extensión de «Asunto Nombre Alternativo» (SubjectAltName), que describa al poseedor del certificado. Cómo configurar una extensión SubjectAltName usando certpatch para un certificado, también se describe en README.PKI para el caso de configuración de una dirección IP como la extensión SubjectAltName. Aquí, el uso de una dirección IP también es el comportamiento por definición de isakmpd.

Certpatch también tiene soporte para el uso de «Nombres de Dominio Totalmente Cualificados» (FQDN, "Fully Qualified Domain Name") o UFQDN (FQDN de Usuario). Un ejemplo de un FQDN sería www.openbsd.org, y un ejemplo de un UFQDN sería una dirección de correo electrónico, como por ejemplo Jorgen.Granstam@abc.se.

En este documento usaré FQDNs como SubjectAltNames. El uso de direcciones IP debería ser algo más fácil, ya que es el comportamiento por definición de isakmpd pero no es muy diferente, como veremos más adelante.

Para introducir un SubjectAltName FQDN en un certificado, haríamos algo como esto:

Aquí, ca.key es la clave privada de la «Autoridad de Certificación» (CA), por lo tanto esto sólo lo puede hacer quien tenga acceso a la clave privada del CA. home.mysite.se es el FQDN que se introduce en el certificado. Los nombres de los ficheros originalcert.crt y nuevocert.crt podrían tener el mismo nombre, en cuyo caso el fichero original sería anulado por el certificado modificado nuevo.

Ponga las claves y certificados en los directorios tal y como se describe al final de README.PKI. Si se van a usar las clave de una forma seria, la clave CA (ca.key) se debe guardar en algún sitio seguro.

Configuración de isakmpd

Ahora veamos el fichero de configuración /etc/isakmpd/isakmpd.conf. Originalmente se tomó del fichero de ejemplo en isakmpd.conf(5), pero se ha modificado mucho. También usaré un fichero mucho más corto que en el fichero de ejemplo en la página de manual. He eliminado de ese fichero la mayoría de las partes no necesarias para esta configuración. En parte para simplificar la comprensión de esta configuración. También he añadido algunos comentarios (algunos comentarios los he dejado como estaban en isakmpd.conf(5)), y he cambiado algunos nombres. Ninguno de los nombres de dominio aquí usados existen (que yo sepa).

En realidad, puesto que todo el que lea esto ya tendrá una configuración que funcione del caso de claves precompartidas (ver la sección anterior), no habrá muchas sorpresas en este fichero. No lo explicaré en detalle, mire isakmpd.conf(5) para descripciones de las partes que no comente.

Asumamos que nuestra configuración es parecida a ésta: 

one.mysite.se                                        one.worksite.se
 192.168.1.2--+    10.0.0.1====/======10.0.0.2     +--192.168.2.2 
              |  gw.mysite.se       gw.worksite.se |
              +--192.168.1.1         192.168.2.1---+
two.mysite.se |                                    | two.worksite.se
 192.168.1.3--+                                    +--192.168.2.3

O sea, dos redes que deben conectarse usando un túnel IPSec sobre una red de otro modo insegura. Ignore el hecho de que aquí esté usando direcciones IP reservadas para Internets privadas (RFC1918), debo usar algo. No explicaré cómo usar isakmpd en combinación con NAT ni nada parecido (ya que no lo he probado).

Ahora, veamos el fichero de configuración. Éste es el fichero para la pasarela de seguridad gw.mysite.se:

Hasta aquí la configuración para el sistema local. El sistema remoto se configura exactamente del mismo modo, sólo que al revés. Por lo tanto, la primera parte del fichero isakmpd.conf es diferente. Echemos un vistazo a esa primera parte del fichero isakmpd.conf para la pasarela de seguridad de gw.worksite.se:

No ha sido tan difícil, tal vez algo aburrido de leer. La siguiente parte es algo más interesante.

El fichero policy

El fichero policy puede ser algo confuso para alguien que no lo haya usado con anterioridad, especialmente si las cosas no funcionan como se espera. La página de manual de isakmpd.policy(5) no está tan mal. Tal vez sea poco clara en algunas partes, pero en general es buena.

El fichero policy más simple que es posible sería uno que contuviera una única línea:

Básicamente, esto significa que no hay limitaciones en policy sobre quién puede conectar. Por lo tanto, no es una configuración muy segura. La etiqueta authorizer es para indicar quién tiene la autorización para decidir la política a seguir. El autorizador especial "POLICY" tiene la autoridad total sobre policy. Cualquier otro authorizer debe primero ser autorizado por "POLICY" para poder tener cualquier autoridad.

También puede haber un grupo de condiciones sobre qué está autorizado. El siguiente policy vendría a decir que sólo alguien que use el protocolo ESP con algo de cifrado real, estaría autorizado (bueno, alguien que usara DES también estaría autorizado aquí, aunque DES casi está considerado como muy inseguro, se deja como ejercicio para el lector el cambiar este fichero policy para no permitir tampoco DES). Note que cualquiera que cifre con ESP todavía estaría autorizado.

También se puede «sublicenciar» la autoridad a alguien más (podría ser una o más entidades). El caso simple sería el caso de la clave precompartida. En ese caso, cualquiera que sepa que la contraseña precompartida, estará autorizado. Por lo tanto:

Esto autorizaría a cualquiera que supiera esta contraseña para conectar y cumplir con las condiciones (pero recuerde que la contraseña también se debe activar en la etiqueta Authentication de isakmpd.conf).

Hasta ahora, nada complicado. Ahora viene la parte interesante. Primero, puede haber muchos con licencias, aunque deben estar todos autorizados por "POLICY". Además, aquéllos que dispongan de licencias y estén autorizados, pueden «sublicenciar» a otros. Un licenciado puede ser simplemente una cadena si está más descrito en el fichero policy:

Y ahora, a por lo que todos estaban esperando. policy también se puede sublicenciar o delegar a una clave. En este caso suele ser un certificado X.509. El uso más simple de certificados sería usarlos como las contraseñas. Simplemente introduzca certificados de usuarios individuales en el fichero policy:

Esto, obviamente, es una idea estúpida si hay muchos usuarios. Los certificados que isakmpd lee de los directorios CA- y Certificate, y los certificados recibidos desde el otro extremo de la conexión se convierten en pseudocredenciales. Estos certificados convertidos en pseudocredenciales serían algo así:

Note que éstos no están autorizados por "POLICY" y por lo tanto no tendrán ningún efecto sin que estén de alguna manera autorizados. Además, esto muestra lo que le ocurre internamente a los certificados. La credencial anterior no se ve en el fichero policy. Sin embargo, se puede dar una sublicencia a tales credenciales. Recuerde el tema sobre sublicencias. Es posible dar licencias a todos los certificados que estén firmados por una cierta CA, poniendo el certificado de la CA como un licenciado de "POLICY":

El fichero policy que hemos visto es un simple ejemplo de fichero policy que delega en una CA. Cualquier usuario que tenga un certificado firmado por la CA de este certificado, y que además cumpla las otras condiciones configuradas en policy y en el fichero de configuración, estará autorizado.

Casi seguro... ¡no es seguro!

Desafortunadamente, esto no es suficiente para estar realmente seguro. Hay formas para atacar una pasarela de seguridad configurada de esta forma. Si no quiere leer los detalles, pase a la sección siguiente ahora. Para el resto, intentaremos entender porqué esto no es seguro. No es difícil.

Considere a qué información tiene acceso en este momento uno de los isakmpd. Del fichero de configuración, isakmpd sabe cuál es el IP-address desde el que se conectarán (en la sección Fase 1). De la información que obtiene durante la negociación de la fase 1, sabe el ID con el que el extremo que se conecta presenta a sí mismo y el certificado que obtiene desde ese extremo de la conexión prueba que que ese ID le pertenece.

Si la información del ID era el IP (si no ponemos una sección ID en fase 1, ésta es la situación por definición), todo va bien. La CA habrá ligado el IP al certificado, y el IP en la configuración será toda la información que necesitemos. Un impostor podría usar el mismo IP de otra máquina en algunos casos (si ambas máquinas estuvieran en la misma red local y la máquina que tuviera este IP estuviera fuera de servicio por cualquier motivo). Sin embargo, el impostor no podría tener un certificado y la correspondiente clave privada que probara que este IP pertenece al impostor.

Si esto ocurriera alguna vez, el impostor habría conseguido robar la clave privada del auténtico propietario del IP, o el impostor habría conseguido engañar la CA para que le diera un certificado que contuviera información falsa. En el primer caso significaría que la clave privada no se habría protegido lo suficientemente bien, y en el segundo la CA habría fallado al comprobar la identidad del impostor como debiera (o la información del ID del certificado) o la clave privada de la CA no habría estado bien protegida. Como todo esto son prerrequisitos para que la seguridad funcione, ninguna de estas situaciones debería suceder nunca.

En nuestro ejemplo la situación es diferente. Aquí tenemos un FQDN en el certificado en lugar de una dirección IP. Como todavía tenemos una dirección IP en la sección de fase 1, tenemos por tanto un posible problema de seguridad. Lo que ocurriría durante la negociación de fase 1 de ISAKMP sería que podríamos comprobar que el extremo de la conexión se hubiera llevado a cabo desde el IP supuesto (pero como hemos explicado anteriormente, en algunos casos se podría falsificar). Podríamos comprobar que ese ID que presenta nuestro extremo de la conexión realmente pertenece a éste. Pero lo que no podríamos comprobar ahora sería si ese ID es realmente el ID que suponemos, porque isakmpd nunca ha sabido qué ID debería ser.

Alguien podría decir que el sistema de DNS ata el IP al FQDN para el anfitrión. Es cierto, sin embargo el sistema de DNS actual no es seguro y se le puede, bajo ciertas circunstancias, engañar para que entregue información falsa (o podría ser víctima de una ataque de «denegación de servicio» (DoS, "Denial of Service") por parte de un atacante, y la máquina del atacante podría falsificar la respuesta del servidor de DNS). DNS seguro aparecerá en el futuro, pero todavía no está aquí (o por lo menos la mayoría de servidores de DNS todavía no son seguros); por lo tanto, hoy en día, el uso de DNS para comprobar si el FQDN en el certificado corresponde al IP supuesto, no es una garantía. De hecho, isakmpd no lo comprueba con DNS. Aun cuando DNS fuera seguro, la comprobación no serviría en el caso de usar un UFQDN.

Así pues, en caso de tener un FQDN como ID, sería posible que un atacante obtuviese su propia clave privada y que ésta estuviera firmada por la misma CA que usamos nosotros (pero con el FQDN del atacante). Y podría lanzar un ataque DoS sobre nuestra conexión para hacerla caer (de hecho, existen unos agujeros en el mismo protocolo ISAKMP, que probablemente se podrín usar para lanzar un ataque DoS remoto contra la conexión y hacerla caer, aunque no sé qué sensibles a estos ataques sería isakmpd). Entonces, el atacante podría configurar su propia máquina del mismo modo que la de nuestra conexión, conectarla a la red de nuestra conexión, e intentar conectarse mediante su ID, clave privada y certificado propios.

Nuestro isakmpd no habría sido informado sobre qué ID por nuestra conexión (debido a que el atacante está configurado de forma idéntica a nuestra conexión, aparte del certificado, ID y clave privada). Nuestro isakmpd podría comprobar que el certificado estuviera firmado por la misma CA (pero la mayoría de CAs firman muchos certificados, y un certificado no es tan difícil de conseguir), y que el ID presentado fuera el mismo que el ID en el certificado. Sin embargo, con la configuración presentada hasta ahora, no comprobaría que este ID fuera el supuesto. Por lo tanto, el atacante tendría permiso para conectar.

Prevenir el ataque

Ahora la cuestión es, ¿cómo podemos informar a isakmpd sobre qué ID debe esperar? Por suerte esto es fácil, y está documentado en la página de manual de isakmpd.policy(5). Debemos hacer la comprobación en policy, como esto:

Ahora sólo gw.worksite.se podría obtener una conexión IPSec. Se pueden añadir más permisos para otros IDs, añadiendo más comprobaciones remote_id alternativas, o sea, teniendo condiciones en policy como esta:

Con esta policy podrían conectar tanto gw.worksite.se, como gw.somesite.se, como gw.whatsite.se.

Algunos afirman que es desafortunado que tengan que haber certificados enteros introducidos en policy. Reformatear los certificados en el formato de policy requiere algo de esfuerzo, y hace que policy sea poco legible. Si alguien substituyera por error, un certificado de usuario con el correspondiente certificado de CA en alguna parte de un fichero policy complejo, podría provocar que usuarios no autorizados obtuvieran permiso para conectar en algunos casos y, aún peor, no sería fácilmente detectable leyendo el fichero policy (porque los certificados X.509 no están en un formato humano legible).

Ahora, para aquellos a quienes les gusta estar al borde del precipicio, existe una solución a este problema. Ahora se puede usar el certificado «Nombre Distinguido» (DN, "Distinguished Name") en lugar de un certificado en policy (por supuesto que el correspondiente certificado debe estar disponible desde los directorios cert o ca del disco, de modo que isakmpd lo pueda encontrar). Con este formato, el fichero policy anterior acabaría siendo algo así:

Mucho más legible, ¿o no? La información sobre lo que es el exacto DN para un certificado se puede encontrar mirando al certificado, usando la utilidad openssl:

Se pueden hacer configuraciones de policy más complicadas pero esto es suficiente para empezar, y todavía hay otro ejemplo en la siguiente sección.

Esto debería proveerle con la información necesaria sobre el certificado en ca.crt. Esto será bueno siempre que tengamos un fichero policy pequeño o, por lo menos, uno razonable. Sin embargo, todavía no es suficiente si tenemos un sitio enorme con muchos usuarios que deban tener permiso de conexión.

Configuraciones de multiusuario y/o autorización centralizada

Veamos ahora algunas características interesantes de isakmpd. Hasta ahora hemos asumido que el supuesto extremo remoto de la conexión era conocido y tenía una dirección IP estática. Esto no siempre es así. Muchas personas usan IPs asignados de forma dinámica, o usan muchas máquinas diferentes. En otros casos, como en el caso de los servidores, podríamos no estar seguros de quién quiere conectar.

Por lo tanto, una funcionalidad interesante de isakmpd es que puede usar en la sección de fase 1 una etiqueta predefinida en lugar de un IP, permitiendo de este modo negociaciones isakmpd desde cualquier IP. Esto se haría del siguiente modo:

Primero, hay que decir que esta configuración podría no ser segura frente a ataques de DoS. Como se ha dicho anteriormente, existen algunos agujeros en los protocolos ISAKMP/IKE. De todos modos, el uso de una sección de fase 1 predefinida también nos permite usar un tipo de «certificados de autorización».

Imagine que tuviéramos muchos usuarios autorizados, pero que no aceptáramos a cualquier usuario, como podría ocurrir en una compañía. Nos gustaría que los empleados tuvieran permiso para conectar, pero nadie más. Ahora imagine que la compañía tuviera miles de empleados, y que quisiéramos que todos ellos pudieran conectar desde cualquier máquina (no sólo desde dentro de la red de la compañía), pero que no todos tuvieran permiso para hacer cualquier cosa. Se podría escribir un fichero policy como éste:

Puede que esto no sea exactamente como debería ser. Por lo que sé, no está comprobado (de hecho, estas condiciones de filtros podrían no funcionar como espero). Además, un fichero policy como éste (cualquiera con un IP del extremo de la conexión predefinido) requeriría reescribir partes del fichero isakmpd.conf también. Esto conllevaría algunas implicaciones en la seguridad. Para este tipo de conexiones en las que cualquiera debe tener permiso para conectar, es probablemente deseable grabar el DN de cualquiera que conecte. Que yo sepa, isakmpd todavía no tiene soporte para esto. Además, también podría tener otras implicaciones en la seguridad. De cualquier modo la idea básica está clara.

Por si acaso alguien no ha visto las interesantes posibilidades que esto tiene: Si todas la máquinas que usan ISAMKP/IKE de este modo, tuvieran un grupo de condiciones estándar para todos los servicios que los usuarios quisieran usar de forma remota, la CA podría autorizar a los usuarios poniendo las extensiones SubjectAltName correctas en sus certificados. Además, la fecha de caducidad para estos certificados se podría configurar para que caducara a menudo, aunque los usuarios podrían obtener nuevos certificados cuando sus certificados actuales estuvieran a punto de caducar. Si los usuarios hicieran un mal uso de sus autorizaciones, bastaría con no volver a emitir los certificados para que no pudieran acceder después de la fecha de caducidad. No sería necesario cambiar los ficheros policy en todas las máquinas simplemente porque un empleado, por ejemplo, dejara el trabajo. El mismo esquema podría funcionar para propósitos distintos a ISAKMP/IPSec (¡incluida la autorización para sistemas fuera de la conexión!), aunque eso requeriría un software especial. En cualquier caso, cualquier organización que hiciera esto es probable que también quisiera ser su propia CA.

Las configuraciones de multiusuarios (usuarios móviles) como ésta, también son posibles con claves precompartidas, pero entonces se requiere que se use el modo AGGRESSIVE en lugar del modo ID_PROT, ya que en este caso necesitaremos poder escoger la frase de la contraseña correcta basada en el ID, debido a que en este caso no lo podemos saber por el ID (en modo AGGRESSIVE el ID se envía durante un estado más temprano de la negociación, pero se envía descifrado, por lo tanto el modo AGGRESSIVE es más rápido porque necesita menos intercambios de mensajes, pero también es un poco menos seguro debido a que el ID se envía en claro).

13.10 - ¿Qué clientes IKE son compatibles con isakmpd?

isakmpd es el dæmon de la gestión de claves de ISAKMP/Oakley que viene con OpenBSD. Sospechamos que interacciona, por lo menos en parte, con la mayoría de implementaciones ISAKMP, pero sólo los siguientes han sido comprobados. Note que algunos software isakmp que puede encontrar están basados en el dæmon iskamp de OpenBSD.

Los siguientes clientes para MS-Windows son compatibles según los informes recibidos:

Las siguientes pasarelas/enrutadores son compatibles según los informes recibidos:

13.11 - Solución de problemas de IPSec/VPN

Para solventar problemas, la primera herramienta que debe usar es tcpdump(8). Use tcpdump para buscar varias cosas.

Si está usando tcpdump en OpenBSD, dispone de una versión mejorada de tcpdump que puede mostrarle algo de información sobre paquetes ESP y AH. Si está usando tcpdump desde OpenBSD 2.5 o desde otro sistema operativo, es posible que tenga una versión anticuada que sólo le muestre el número del protocolo para AH o ESP (el protocolo IP de ESP es 50, y el de AH es 51).

13.12 - Documentación relacionada

IPSec está parcialmente documentado en la página de manual de vpn(8). Hay varios modelos de configuración en el directorio /usr/share/ipsec/ que le pueden ser de ayuda. Las páginas de manual de enc(4), ipsec(4), ipsecadm(8), photurisd(8), startkey(1), isakmpd(8), isakmpd.conf(5) y isakmpd.policy(5) tienen información más detallada y pueden ayudarle con la configuración y operación de IPSec.

Otros enlaces:

Y en los RFC:

[Volver al índice principal] [Sección 12.0 - Para usuarios avanzados] [Sección 14.0 - Uso de discos en OpenBSD]

[índice] www@openbsd.org
Originally [OpenBSD: faq13.html,v 1.37 2000/12/26 16:17:40 ericj Exp ]
$Translation: faq13.html,v 1.6 2000/12/26 21:12:09 horacio Exp $
$OpenBSD: faq13.html,v 1.6 2000/12/28 22:00:24 jufi Exp $