test

Guía de administración del sistema: servicios IP

Parte IV Seguridad IP

Esta sección se centra en la seguridad de red. La arquitectura de seguridad IP (IPsec) protege la red en el nivel del paquete. El intercambio de claves de Internet (IKE) administra las claves para IPsec. El filtro IP de Oracle Solaris proporciona un cortafuegos.

Capítulo 19 Arquitectura de seguridad IP (descripción general)

La arquitectura de seguridad IP (IPsec) ofrece protección criptográfica para los datagramas IP en paquetes de redes IPv4 e IPv6.

Este capítulo contiene la información siguiente:

Para implementar IPsec en la red, consulte el Capítulo 20Configuración de IPsec (tareas). Para obtener información de referencia, consulte el Capítulo 21Arquitectura de seguridad IP (referencia).

Novedades de IPsec

Solaris 10 4/09: a partir de esta versión, la utilidad de gestión de servicios (SMF) administra IPsec como conjunto de servicios.

Por defecto, hay dos servicios de IPsec habilitados en el inicio del sistema:

Por defecto, los servicios de gestión de claves se deshabilitan en el inicio del sistema:

Para activar directivas IPsec en SMF, siga estos pasos:

  1. Agregue entradas de directivas IPsec al archivo ipsecinit.conf.

  2. Configure la Internet Key Exchange (IKE) o configure manualmente las claves.

  3. Actualice el servicio de directivas IPsec.

  4. Habilite el servicio de administración de teclas.

Para obtener más información sobre SMF, consulte el Capítulo 18, Managing Services (Overview) de System Administration Guide: Basic Administration. Consulte también las páginas de comando man smf(5) y svcadm(1M).

A partir de esta versión, los comandos ipsecconf e ipseckey presentan la opción -c para comprobar la sintaxis de sus respectivos archivos de configuración. Asimismo, el perfil de derechos Network IPsec Management se proporciona para administrar IPsec e IKE.

Solaris 10 7/07&: a partir de esta versión, IPsec implementa por completo los túneles en modo túnel y se modifican las utilidades que admiten túneles.

Solaris 10 1/06: a partir de esta versión, IKE es totalmente compatible con NAT-Traversal, como se describe en RFC 3947 y RFC 3948. Las operaciones IKE usan la biblioteca PKCS #11 de la estructura criptográfica, lo cual mejora el rendimiento.

La estructura criptográfica proporciona un almacén de claves softtoken para las aplicaciones que utilizan la metarranura. Cuando IKE utilice la metarranura, podrá guardar las claves en el disco, en una placa conectada o en el almacén de claves softtoken.

Introducción a IPsec

IPsec protege los paquetes IP autenticándolos, cifrándolos o llevando a cabo ambas acciones. IPsec se lleva a cabo dentro del módulo IP, debajo de la capa de aplicación. Por tanto, una aplicación de Internet puede aprovechar IPsec aunque no esté configurada para el uso de IPsec. Cuando se utiliza correctamente, la directiva IPsec es una herramienta eficaz para proteger el tráfico de la red.

La protección IPsec implica cinco componentes principales:

IPsec aplica los mecanismos de seguridad a los datagramas IP que se transfieren a la dirección de destino IP. El receptor utiliza la información de SADB para comprobar que los paquetes que llegan sean legítimos y descifrarlos. Las aplicaciones pueden invocar IPsec para aplicar mecanismos de seguridad a los datagramas IP por socket también.

Los sockets tienen un comportamiento distinto según el puerto:

RFC IPsec

Internet Engineering Task Force (IETF) ha publicado una serie de solicitudes de comentarios (RFC) que describen la arquitectura de seguridad para la capa IP. Todas las RFC tienen copyright de la Sociedad de Internet. Encontrará un vínculo a las RFC en la página http://www.ietf.org/. La siguiente lista de RFC incluye referencias de seguridad IP generales:

Terminología de IPsec

Las RFC IPsec definen una serie de términos útiles para determinar cuándo debe implementar IPsec en los sistemas. La tabla siguiente enumera los términos de IPsec, proporciona sus acrónimos habituales y aporta una definición. Para ver una lista de la terminología que se utiliza en la negociación de claves, consulte la Tabla 22–1.

Tabla 19–1 Términos, acrónimos y usos de IPsec

Término de IPsec 

Acrónimo 

Definición 

Asociación de seguridad 

SA 

Conexión exclusiva entre dos nodos de una red. La conexión se define mediante tres elementos: un protocolo de seguridad, un índice de parámetros de seguridad y un destino IP. El destino IP puede ser una dirección IP o un socket. 

Base de datos de asociaciones de seguridad 

SADB 

Base de datos que contiene todas las asociaciones de seguridad activas. 

Índice de parámetros de seguridad 

SPI 

El valor de índice para una asociación de seguridad. Un SPI es un valor de 32 bits que distingue entre las SA que tienen el mismo destino IP y protocolo de seguridad. 

base de datos de directivas de seguridad

SPD 

Base de datos que determina si los paquetes salientes y entrantes tienen el nivel de protección especificado. 

Intercambio de claves 

 

El proceso de generación de claves para los algoritmos criptográficos asimétricos. Los dos métodos principales son los protocolos RSA y el protocolo Diffie-Hellman. 

Protocolo Diffie-Hellman 

DH 

Protocolo de intercambio de claves que implica la generación y la autenticación de claves. A menudo se denomina intercambio de claves autenticadas.

Protocolo RSA 

RSA 

Protocolo de intercambio de claves que implica la generación y la distribución de claves. El protocolo recibe el nombre de sus tres creadores, Rivest, Shamir y Adleman. 

Protocolo de administración de claves y asociaciones de seguridad de Internet 

ISAKMP 

Estructura habitual para establecer el formato de los atributos SA, así como para negociar, modificar y eliminar SA. ISAKMP es el estándar IETF para administrar SA IPsec. 

Flujo de paquetes IPsec

La Figura 19–1 muestra cómo se comporta un paquete de direcciones IP, como parte de un datagrama IP, cuando se invoca IPsec en un paquete saliente. El diagrama de flujo muestra dónde se pueden aplicar en el paquete las entidades encabezado de autenticación (AH) y Carga de seguridad encapsuladora (ESP). En las secciones siguientes se describe cómo aplicar estas entidades, así como el modo de seleccionar los algoritmos.

La Figura 19–2 muestra el proceso entrante de IPsec.

Figura 19–1 IPsec aplicado al proceso de paquetes salientes

El diagrama de flujo muestra que el paquete saliente primero se protege mediante ESP y luego con AH. A continuación, el paquete atraviesa un túnel o una interfaz física.

Figura 19–2 IPsec aplicado al proceso de paquetes entrantes

El diagrama de flujo muestra que IPsec primero procesa el encabezado AH y luego el encabezado ESP en los paquetes entrantes. Los paquetes que no están suficientemente protegidos se dejan.

Asociaciones de seguridad IPsec

Una asociación de seguridad (SA) IPsec especifica las propiedades de seguridad que se reconocen mediante hosts comunicados. Una única SA protege los datos en una dirección. La protección es para un solo host o para una dirección de grupo (multidifusión). Dado que la mayoría de la comunicación es de igual a igual o de cliente-servidor, debe haber dos SA para proteger el tráfico en ambas direcciones.

Los tres elementos siguientes identifican una SA IPsec de modo exclusivo:

El SPI, un valor arbitrario de 32 bits, se transmite con un paquete AH o ESP. Las páginas del comando man ipsecah(7P) y ipsecesp(7P) explican la protección que ofrecen AH y ESP. Se utiliza un valor de suma de comprobación de integridad para autenticar un paquete. Si la autenticación falla, se deja el paquete.

Las asociaciones de seguridad se almacenan en una base de datos de asociaciones de seguridad (SADB). Un motor de administración basado en sockets, la interfaz PF_KEY, permite a las aplicaciones privilegiadas administrar la base de datos. Por ejemplo, la aplicación IKE y el comando ipseckeys usan la interfaz de socket PF_KEY.

Administración de claves en IPsec

Las asociaciones de seguridad (SA) requieren materiales para la autenticación y para el cifrado. La administración de este material de claves se denomina administración de claves. El protocolo de intercambio de claves de Internet (IKE) gestiona automáticamente la administración de claves. También puede administrar las claves manualmente con el comando ipseckey.

Las SA de los paquetes IPv4 e IPv6 pueden utilizar cualquier método para administrar las claves. A menos que tenga una razón de peso para utilizar la administración de claves manual, se recomienda la administración automática. Por ejemplo, para interoperar con sistemas que no sean Solaris es posible que precise la administración de claves manual.

En la versión actual, SMF proporciona el siguiente servicio de administración de claves para IPsec:

En las versiones anteriores a Solaris 10 4/09 los comandos en.iked e ipseckey administran material de claves.

Mecanismos de protección de IPsec

IPsec proporciona dos protocolos de seguridad para proteger los datos:

Un AH protege los datos con un algoritmo de autenticación. Una ESP protege los datos con un algoritmo de cifrado. De modo opcional, una ESP protege los datos con un algoritmo de autenticación. Cada implementación de un algoritmo se denomina mecanismo.

Encabezado de autenticación

El encabezado de autenticación proporciona autenticación de datos, una integridad sólida y protección de repetición para los datagramas IP. AH protege la mayor parte del datagrama IP. Como muestra la ilustración siguiente, AH se inserta entre el encabezado IP y el encabezado de transporte.

El diagrama muestra el encabezado AH entre el encabezado IP y el encabezado TCP.

El encabezado de transporte puede ser TCP, UDP, SCTP o ICMP. Si se utiliza un túnel, el encabezado de transporte puede ser otro encabezado de IP.

Carga de seguridad encapsuladora

El módulo Encapsulating Security Payload (ESP) ofrece confidencialidad para los elementos que encapsula ESP. ESP también proporciona los servicios que proporciona AH. Sin embargo, ESP sólo proporciona sus protecciones de la parte del datagrama que encapsula ESP. ESP proporciona servicios de autenticación opcional para asegurar la integridad de los paquetes protegidos. Debido a que ESP utiliza tecnología de habilitación de cifrado, un sistema que proporcione ESP puede estar sujeto a leyes de control de importación y exportación.

ESP encapsula sus datos, de modo que ESP sólo protege los datos que siguen a su inicio en el datagrama, como se muestra en la ilustración siguiente.

El diagrama muestra el encabezado ESP entre el encabezado IP y el encabezado TCP. El encabezado TCP se cifra mediante el encabezado ESP.

En un paquete TCP, ESP encapsula únicamente el encabezado TCP y sus datos. Si el paquete se encuentra en un datagrama de IP en IP, ESP protege el datagrama IP interior. La directiva por socket permite la autoencapsulación, de modo que ESP puede encapsular las opciones de IP cuando lo necesita.

Si está activada la autoencapsulación, se realiza una copia del encabezado IP para construir un datagrama de IP en IP. Por ejemplo, cuando la autoencapsulación no está activada en un socket TCP, el datagrama se envía con el siguiente formato:


[ IP(a -> b) options + TCP + data ]

Cuando la autoencapsulación está activa en ese socket TCP, el datagrama se envía con el siguiente formato:


[ IP(a -> b) + ESP [ IP(a -> b) options + TCP + data ] ]

Para más información, consulte Modos de transporte y túnel en IPsec.

Consideraciones de seguridad para el uso de AH y ESP

La tabla siguiente compara las protecciones que proporcionan AH y ESP.

Tabla 19–2 Protecciones que proporcionan AH y ESP en IPsec

Protocolo 

Protección de paquetes 

Protección 

Contra ataques 

AH 

Protege el paquete del encabezado IP al encabezado de transporte. 

Proporciona integridad sólida, autenticación de datos: 

  • Garantiza que el receptor recibe exactamente lo que ha enviado el remitente.

  • Es susceptible a los ataques de repetición cuando AH no activa la protección contra repeticiones.

Repetición, cortar y pegar 

ESP. 

Protege el paquete que sigue a ESP en el datagrama. 

Con la opción de cifrado, cifra el datagrama IP. Garantiza la confidencialidad. 

Intercepción de comunicaciones 

Con la opción de autenticación, proporciona la misma protección que AH. 

Repetición, cortar y pegar 

Con ambas opciones, proporciona integridad sólida, autenticación de datos y confidencialidad. 

Repetición, cortar y pegar e intercepción de comunicaciones. 

Algoritmos de autenticación y cifrado en IPsec

Los protocolos de seguridad IPsec utilizan dos tipos de algoritmos: de autenticación y de cifrado. El módulo AH utiliza algoritmos de autenticación. El módulo ESP puede utilizar tanto algoritmos de cifrado como de autenticación. Puede obtener una lista de los algoritmos de su sistema y sus propiedades con el comando ipsecalgs. Para mas información, consulte la página del comando man ipsecalgs(1M) También puede utilizar las funciones que se describen en la página del comando man getipsecalgbyname(3NSL) para recuperar las propiedades de los algoritmos.

IPsec en un sistema Solaris utiliza la estructura criptográfica de Solaris para acceder a los algoritmos. La estructura proporciona un depósito central para los algoritmos, además de otros servicios. La estructura permite a IPsec aprovechar los aceleradores de hardware criptográficos de alto rendimiento. La estructura también proporciona funciones de control de recursos. Por ejemplo, la estructura permite limitar la cantidad de tiempo de CPU que se dedica a las operaciones criptográficas en el núcleo.

Para obtener más información, consulte las siguientes direcciones:

Algoritmos de autenticación en IPsec

Los algoritmos de autenticación producen un valor de suma de comprobación de integridad o síntesis que se basa en los datos y una clave. El módulo AH utiliza algoritmos de autenticación. El módulo ESP también puede utilizar algoritmos de autenticación.

Algoritmos de cifrado en IPsec

Los algoritmos de cifrado cifran los datos con una clave. El módulo ESP de IPsec utiliza algoritmos de cifrado. Los algoritmos operan en los datos en unidades del tamaño de un bloque.

Diferentes versiones del sistema operativo Solaris 10 proporcionan algoritmos de cifrado predeterminados distintos.

Precaución – Precaución –

A partir de la versión Solaris 10 7/07, no añada Solaris Encryption Kit al sistema. El kit reduce el nivel de revisión para cifrado del sistema. El kit es incompatible con el cifrado del sistema.

Directivas de protección IPsec

Las directivas de protección IPsec pueden utilizar cualquiera de los mecanismos de seguridad. Las directivas IPsec se pueden aplicar en los niveles siguientes:

IPsec aplica la directiva en todo el sistema a los datagramas entrantes y salientes. Los datagramas salientes se envían con o sin protección. Si se aplica protección, los algoritmos son específicos o no específicos. Puede aplicar algunas reglas adicionales a los datagramas salientes, dados los datos adicionales que conoce el sistema. Los datagramas entrantes pueden aceptarse o dejarse. La decisión de dejar o aceptar un datagrama entrante se basa en varios criterios, que en ocasiones se pueden superponer o entrar en conflicto. Los conflictos se resuelven determinando qué regla que analiza primero. El tráfico se acepta automáticamente, excepto cuando una entrada de directiva indica que el tráfico debe omitir las demás directivas.

La directiva que normalmente protege un datagrama se puede omitir. Puede especificar una excepción en la directiva del sistema, o solicitar una omisión en la directiva por socket. Para el tráfico de un sistema, se aplican las directivas, pero no se aplican los mecanismos de seguridad reales. En lugar de ello, la directiva saliente de un paquete dentro del sistema se convierte en un paquete entrante al que se han aplicado esos mecanismos.

El archivo ipsecinit.conf y el comando ipsecconf permiten configurar directivas IPsec. Para ver detalles y ejemplos, consulte la página del comando man ipsecconf(1M).

Modos de transporte y túnel en IPsec

Los estándares IPsec definen dos modos distintos de funcionamiento de IPsec, el modo transporte y el modo túnel. Dichos modos no afectan a la codificación de paquetes. Los paquetes están protegidos por AH, ESP, o ambos en cada modo. Los modos aplican la directiva de un modo distinto cuando el paquete interior es un paquete IP, como en el caso siguiente:

En modo transporte, pueden utilizarse el encabezado exterior, el encabezado siguiente y los puertos que admita el siguiente encabezado para determinar la directiva IPsec. En efecto, IPsec puede aplicar diferentes directivas de modo de transporte entre dos direcciones IP hasta la granularidad de un único puerto. Por ejemplo, si el siguiente encabezado es TCP, que admite puertos, la directiva IPsec se puede configurar para un puerto TCP de la dirección IP exterior. De modo similar, si el siguiente encabezado es un encabezado IP, se pueden utilizar el encabezado exterior y el encabezado IP interior para determinar la directiva IPsec.

El modo túnel sólo funciona para los datagramas de IP en IP. El uso de túneles en modo túnel puede ser útil cuando los usuarios se conecten desde casa a un equipo central. En modo túnel, la directiva IPsec se aplica en el contenido del datagrama IP interior. Se pueden aplicar diferentes directivas IPsec para distintas direcciones IP interiores. Es decir, el encabezado IP interior, su encabezado siguiente y los puertos que admite el siguiente encabezado pueden aplicar una directiva. A diferencia del modo transporte, en el modo túnel el encabezado IP exterior no dicta la directiva de su datagrama IP interior.

Por tanto, en modo túnel, la directiva IPsec se puede especificar para las subredes de una LAN detrás de un enrutador y para puertos de dichas subredes. La directiva IPsec también se puede especificar para una dirección IP concreta, es decir, hosts de esas subredes. Los puertos de dichos hosts también pueden tener una directiva IPsec específica. Sin embargo, si se ejecuta un protocolo de enrutamiento dinámico por un túnel, no utilice la selección de subredes o la sección de direcciones, porque la vista de la topología de red en la red equivalente podría cambiar. Los cambios invalidarían la directiva IPsec estática. Para ver algunos ejemplos de procedimientos de túnel que incluyen la configuración de rutas estáticas, consulte Protección de una VPN con IPsec.

En SO Solaris, el modo túnel puede aplicarse sólo en una interfaz de red de túneles IP. El comando ipsecconf proporciona una palabra clave tunnel para seleccionar una interfaz de red de túneles IP. Cuando la palabra clave tunnel está presente en una regla, todos los selectores específicos de dicha regla se aplican al paquete interior.

En modo transporte, ESP, AH, o ambos, pueden proteger el datagrama.

La figura siguiente muestra un encabezado IP con un paquete TCP sin proteger.

Figura 19–3 Paquete IP sin proteger con información TCP

El diagrama muestra el encabezado IP seguido del encabezado TCP. El encabezado TCP no está protegido.

En modo transporte, ESP protege los datos tal como se muestra en la figura siguiente. El área sombreada muestra la parte cifrada del paquete.

Figura 19–4 Paquete IP protegido con información TCP

El diagrama muestra el encabezado ESP entre el encabezado IP y el encabezado TCP. El encabezado TCP se cifra mediante el encabezado ESP.

En modo transporte, AH protege los datos como se muestra en la figura siguiente.

Figura 19–5 Paquete protegido por encabezado de autenticación

El diagrama muestra el encabezado AH entre el encabezado IP y el encabezado TCP.

AH cifra los datos antes de que aparezcan en el datagrama. En consecuencia, la protección que proporciona AH, incluso en el modo transporte, cifra parte del encabezado IP.

En modo túnel, todo el datagrama está dentro de la protección de un encabezado IPsec. El datagrama de la Figura 19–3 está protegido en modo túnel por otro encabezado IPsec exterior, en este caso ESP, tal como se muestra en la figura siguiente.

Figura 19–6 Paquete IPsec protegido en modo túnel

El diagrama muestra el encabezado ESP después del encabezado IP y antes de un encabezado y un encabezado TCP. Los dos últimos encabezados están protegidos mediante cifrado.

El comando ipsecconf incluye palabras clave para configurar túneles en modo túnel o en modo transporte.

Redes privadas virtuales e IPsec

Un túnel configurado es una interfaz de punto a punto. El túnel permite la encapsulación de un paquete IP dentro de otro paquete IP. Un túnel configurado correctamente requiere tanto un origen como un destino. Para obtener más información, consulte la página de comando man tun(7M) y Configuración de túneles para compatibilidad con IPv6.

Un túnel crea una interfaz física aparente para IP. La integridad del vínculo físico depende de los protocolos de seguridad subyacentes. Si configura las asociaciones de seguridad (SA) de un modo seguro, puede confiar en el túnel. Los paquetes que salen del túnel deben haberse originado en su equivalente especificado en el destino del túnel. Si existe esa confianza, puede utilizar el reenvío de IP por interfaz para crear una red privada virtual (VPN).

Puede utilizar IPsec para construir una VPN. IPsec protege la conexión. Por ejemplo, una organización que utiliza tecnología VPN para conectar oficinas con redes separadas puede implementar IPsec para proteger el tráfico entre las dos oficinas.

La figura siguiente ilustra cómo las dos oficinas utilizan Internet para formar su VPN con IPsec implementado en sus sistemas de red.

Figura 19–7 Red privada virtual

El diagrama muestra que las oficinas 1 y 2 utilizan la interfaz hme0 para comunicarse entre sí. Cada oficina utiliza hme1 para la comunicación interna.

Para ver un ejemplo detallado del procedimiento de configuración, consulte Cómo proteger una VPN con un túnel IPsec en modo túnel mediante IPv4.

Para ver un ejemplo similar con direcciones IPv6, consulte Cómo proteger una VPN con un túnel IPsec en modo túnel mediante IPv6.

Paso a través de IPsec y NAT

IKE puede negociar las SA IPsec a través de un cuadro NAT Esta función permite a los sistemas conectarse de forma segura desde una red remota, incluso cuando los sistemas están detrás de un dispositivo NAT. Por ejemplo, los empleados que trabajan desde casa, o que se registran desde un sitio de conferencia pueden proteger su tráfico con IPsec.

NAT significa traducción de direcciones de red. Un cuadro NAT se utiliza para traducir una dirección interna privada en una dirección de Internet exclusiva. Las NAT son muy comunes en los puntos de acceso públicos a Internet, como los hoteles. Para obtener más información, consulte Uso de la función NAT del filtro IP de Oracle Solaris.

La posibilidad de utilizar IKE cuando un cuadro NAT se encuentra entre sistemas que se comunican, se denomina NAT traversal, o NAT-T. En la versión the Solaris 10, tiene las limitaciones siguientes:

En losa siguientes documentos RFC se describen las funciones de NAT y los límites de NAT-T. Puede obtener copias de los RFC en http://www.rfc-editor.org.

Para utilizar IPsec en una NAT, consulte Configuración de IKE para sistemas portátiles (mapa de tareas).

IPsec y SCTP

El SO Solaris admite el protocolo SCTP (Streams Control Transmission Protocol). Se admite el uso del protocolo SCTP y el número de puerto SCTP para especificar la directiva IPsec, pero no es fiable. Las extensiones IPsec para SCTP tal como se especifican en la RFC 3554 todavía no están implementadas. Estas limitaciones pueden generar complicaciones a la hora de crear la directiva IPsec para SCTP.

SCTP puede utilizar varias direcciones de origen y destino en el contexto de una sola asociación SCTP. Cuando la directiva IPsec se aplica a una única dirección de origen o una única dirección de destino, la comunicación puede fallar cuando SCTP cambie la dirección de origen o de destino de dicha asociación. La directiva IPsec sólo reconoce la dirección original. Para obtener información sobre SCTP, consulte las RFC y el Protocolo SCTP.

IPsec y Zonas de Solaris

IPsec se configura desde la zona global para las zonas IP compartidas. El archivo de configuración de la directiva IPsec, ipsecinit.conf, se encuentra únicamente en la zona global. El archivo puede tener entradas que se apliquen a zonas no globales, así como entradas que se apliquen a la zona global.

Para zonas de IP exclusiva, IPsec está configurado en la zona no global.

Para obtener información sobre cómo utilizar IPsec con zonas, consulte Protección del tráfico con IPsec. Para obtener información sobre zonas, consulte el Capítulo 16, Introducción a Solaris Zones de Guía de administración de sistemas: administración de recursos y contenedores de Oracle Solaris y zonas de Oracle Solaris.

IPsec y dominios lógicos

IPsec funciona con dominios lógicos. El dominio lógico debe ejecutar una versión del SO Solaris que incluya IPsec, como, por ejemplo, Solaris 10.

Para crear dominios lógicos, debe utilizar Oracle VM Server para SPARC, anteriormente denominado Logical Domains. Para obtener más información sobre cómo configurar dominios lógicos, consulte Logical Domains 1.2 Administration Guide o Oracle VM Server for SPARC 2.0 Administration Guide.

Archivos y utilidades IPsec

La Tabla 19–3 describe los archivos, comandos e identificadores de servicios que se utilizan para configurar y administrar IPsec. Para mayor información, la tabla incluye comandos y archivos de administración de claves.

A partir de Solaris 10 4/09, SMF administra IPsec. Para obtener más información sobre identificadores de servicios, consulte el Capítulo 18, Managing Services (Overview) de System Administration Guide: Basic Administration.

Tabla 19–3 Lista de archivos y utilidades IPsec seleccionados

Utilidad IPsec, archivo o servicio  

Descripción 

Página de comando man 

svc:/network/ipsec/ipsecalgs

En la versión actual, el servicio SMF que administra los algoritmos IPsec.  

smf(5), ipsecalgs(1M)

svc:/network/ipsec/manual-key

En la versión actual, el servicio SMF que gestiona asociaciones de seguridad manuales (SA).  

smf(5), ipseckey(1M)

svc:/network/ipsec/policy

En la versión actual, el servicio SMF que gestiona la directiva IPsec.

smf(5), ipsecconf(1M)

svc: /network/ipsec/ike

En la versión actual, el servicio SMF para la gestión automática de IPsec SA.  

smf(5), in.iked(1M)

Archivo /etc/inet/ipsecinit.conf

archivo de directiva IPsec En las versiones anteriores a Solaris 10 4/09, si el archivo existe, IPsec se activará en el momento del inicio.

En la versión actual, el servicio SMF policy utiliza este archivo para configurar la directiva de IPsec durante el inicio del sistema.

ipsecconf(1M)

Comando ipsecconf

Comando de directiva IPsec. Es útil para visualizar y modificar la directiva IPsec actual, así como para realizar pruebas. En las versiones anteriores a Solaris 10 4/09 las secuencias de comandos de inicio utilizan ipsecconf para leer el archivo /etc/inet/ipsecinit.conf y activar IPsec.

En la versión actual, ipsecconf lo utiliza el servicio SMF policy para configurar la directiva IPsec en el inicio del sistema.

ipsecconf(1M)

Interfaz de socket PF_KEY

Interfaz para la base de datos de asociaciones de seguridad (SADB). Controla la administración de claves manual y automática.

pf_key(7P)

Comando ipseckey

Comando de material de claves de asociaciones de seguridad (SA) de IPsec. ipseckey es un componente frontal de línea de comandos para la interfaz PF_KEY. ipseckey puede crear, destruir o modificar SA.

ipseckey(1M)

Archivo /etc/inet/secret/ipseckeys

Claves para SA de IPsec. En las versiones anteriores a Solaris 10 4/09 si existe el archivo ipsecinit.conf, el archivo ipseckeys se lee automáticamente en el momento del inicio.

En la versión actual, el servicio SMF manual-key utiliza ipseckeys para configurar manualmente las asociaciones de seguridad (SA) durante el inicio del sistema.

 

Comando ipsecalgs

Comando de algoritmos IPsec. Es útil para visualizar y modificar la lista de algoritmos IPsec y sus propiedades.

En la versión actual, se utiliza por parte del servicio SMF ipsecalgs para sincronizar algoritmos IPsec conocidos con el núcleo en el inicio del sistema.

ipsecalgs(1M)

Archivo /etc/inet/ipsecalgs

Contiene los protocolos IPsec configurados y las definiciones de algoritmos. Este archivo lo administra el comando ipsecalgs y nunca se debe editar manualmente.

 

Archivo /etc/inet/ike/config

archivo de configuración y directiva de IKE Por defecto, este archivo no existe. En las versiones anteriores a Solaris 10 4/09, si el archivo existe, el daemon IKE (in.iked) proporciona gestión automática de claves. La administración se basa en reglas y parámetros globales del archivo /etc/inet/ike/config. Consulte Archivos y utilidades IKE.

En la versión actual, si el archivo existe, el servicio svc:/network/ipsec/ike inicia el daemon IKE, in.iked, para proporcionar gestión automática de claves.

ike.config(4)

Cambios en IPsec para la versión Solaris 10

Para ver una lista completa de las nuevas funciones de Solaris y una descripción de las versiones de Solaris, consulte Novedades de Oracle Solaris 10 9/10. A partir de la versión Solaris 9, IPsec incluye las siguientes funciones:

Capítulo 20 Configuración de IPsec (tareas)

Este capítulo incluye los procedimientos para implementar IPsec en la red. Los procedimientos se describen en los siguientes mapas de tareas:

Para obtener información general sobre IPsec, consulte el Capítulo 19Arquitectura de seguridad IP (descripción general). Para obtener información de referencia sobre IPsec, consulte el Capítulo 21Arquitectura de seguridad IP (referencia).

Protección del tráfico con IPsec (mapa de tareas)

El siguiente mapa de tareas hace referencia a los procedimientos que configuran IPsec entre uno o más sistemas. Las páginas del comando man ipsecconf(1M), ipseckey(1M) y ifconfig(1M) también describen procedimientos útiles en sus secciones de ejemplos correspondientes.

Tarea 

Descripción 

Para obtener instrucciones 

Proteger el tráfico entre dos sistemas. 

Protege los paquetes de un sistema a otro. 

Cómo proteger el tráfico entre dos sistemas con IPsec

Proteger un servidor web con la directiva IPsec. 

Requiere el uso de IPsec por parte del tráfico que no sea de red. Los clientes web se identifican mediante puertos específicos, que omiten las comprobaciones de IPsec. 

Cómo utilizar IPsec para proteger un servidor web del tráfico que no procede de Internet

Visualizar las directivas de IPsec. 

Muestra las directivas de IPsec que se están aplicando, en el orden en que se aplican. 

Cómo visualizar las directivas de IPsec

Generar números aleatorios. 

Genera números aleatorios para el material de claves para las asociaciones de seguridad creadas manualmente. 

Cómo generar números aleatorios en un sistema Solaris

How to Generate a Symmetric Key by Using the pktool Command de System Administration Guide: Security Services

Crear o reemplazar asociaciones de seguridad manualmente. 

Proporciona los datos básicos para las asociaciones de seguridad: 

  • Nombre de algoritmo IPsec y material de claves

  • Clave para el índice de parámetros de seguridad

  • Direcciones IP de origen y destino

Cómo crear manualmente asociaciones de seguridad IPsec

Comprobar que IPsec esté protegiendo los paquetes. 

Examina el resultado del comando snoop para los encabezados específicos que indica cómo se protegen los datagramas IP.

Cómo verificar que los paquetes estén protegidos con IPsec

(Opcional) Crear un rol de seguridad de red. 

Crea un rol que puede configurar una red segura, pero que puede desempeñar menos funciones que un superusuario. 

Cómo configurar una función para la seguridad de la red

Administrar IPsec y materiales clave como un conjunto de servicios SMF. 

Describe cómo y cuándo utilizar los comandos que habilitan, inhabilitan, actualizan y reinician los servicios. También describe los comandos que cambian los valores de propiedad de los servicios. 

Cómo administrar servicios de IPsec e IKE

Configurar una red privada virtual protegida (VPN). 

Configura IPsec entre dos sistemas separados por Internet. 

Protección de una VPN con IPsec (mapa de tareas)

Protección del tráfico con IPsec

En esta sección se describen los procedimientos que permiten proteger un servidor web y el tráfico entre dos sistemas. Para proteger una VPN, consulte Protección de una VPN con IPsec (mapa de tareas) . Existen procedimientos adicionales que proporcionan los materiales de claves y las asociaciones de seguridad, y además verifican que IPsec esté funcionando de acuerdo con la configuración establecida.

La información siguiente se aplica a todas las tareas de configuración de IPsec:

ProcedureCómo proteger el tráfico entre dos sistemas con IPsec

Este procedimiento presupone la siguiente configuración:

Antes de empezar

Debe estar en la zona global para configurar la directiva IPsec para el sistema o para una zona de IP compartida. Para una zona de IP exclusiva, configure la directiva IPsec en la zona no global.

  1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

    Nota –

    El registro remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para iniciar una sesión remota de forma segura. Esto se ilustra en el Ejemplo 20–1.

  2. En cada sistema, agregue entradas de host.

    En la versión actual, agregue las entradas de host al archivo /etc/inet/hosts.

    En un sistema que se ejecute en una versión anterior a Solaris 10 7/07, agregue entradas IPv4 e IPv6 en el archivo /etc/inet/ipnodes. Las entradas de un sistema deben ser contiguas en el archivo. Para obtener información sobre los archivos de configuración del sistema, consulte Archivos de configuración TCP/IP y el Capítulo 11IPv6 en profundidad (referencia).

    Si está conectando sistemas sólo con direcciones IPv4, debe modificar el archivo /etc/inet/hosts. En este ejemplo, los sistemas que se conectan ejecutan una versión anterior de Solaris y utilizan direcciones IPv6.

    1. En un sistema denominado enigma, escriba lo siguiente en el archivo hosts o ipnodes:


      # Secure communication with partym
192.168.13.213 partym
2001::eeee:3333:3333 partym

    2. En un sistema denominado partym, escriba lo siguiente en el archivo hosts o ipnodes:


      # Secure communication with enigma
192.168.116.16 enigma
2001::aaaa:6666:6666 enigma

    El uso de los servicios de asignación de nombres simbólicos no es seguro.

  3. En cada sistema, cree el archivo de directiva IPsec.

    El nombre de archivo es /etc/inet/ipsecinit.conf. Para ver un ejemplo, consulte el archivo /etc/inet/ipsecinit.sample.

  4. Agregue una entrada de directiva IPsec al archivo ipsecinit.conf.

    1. En el sistema enigma, agregue la directiva siguiente:


      {laddr enigma raddr partym} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    2. En el sistema partym, agregue una directiva idéntica:


      {laddr partym raddr enigma} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

      Para ver la sintaxis de las entradas de la directiva IPsec, consulte la página del comando man ipsecconf(1M).

  5. En cada sistema, agregue un par de SA IPsec entre los dos sistemas.

    Puede configurar el intercambio de claves de Internet (IKE) para crear las SA automáticamente. También puede agregar las SA de forma manual.

    Nota –

    Debe utilizar IKE a menos que tenga una razón de peso para generar y mantener las claves manualmente. La administración de claves IKE es más segura que la administración manual.

  6. Habilite la directiva IPsec.

  7. Compruebe la sintaxis del archivo de directiva IPsec. 


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

    Subsane los posibles errores, compruebe la sintaxis del archivo y continúe.

  8. Actualice la directiva IPsec. 


    # svcadm refresh svc:/network/ipsec/policy:default

    La directiva IPsec está habilitada de forma predeterminada, por lo que puede actualizarla. Si ha inhabilitado la directiva IPsec, habilítela. 


    # svcadm enable svc:/network/ipsec/policy:default

  9. Active las claves para IPsec.

    • Si ha configurado IKE en el Paso 5, realice una de las acciones siguientes:

      • Si el servicio ike no está habilitado, habilítelo. 


        # svcadm enable svc:/network/ipsec/ike:default

      • Si el servicio ike está habilitado, reinícielo. 


        # svcadm restart svc:/network/ipsec/ike:default

    • Si ha configurado manualmente las claves en el Paso 5, realice una de las acciones siguientes:

      • Si el servicio manual-key no está habilitado, habilítelo. 


        # svcadm enable svc:/network/ipsec/manual-key:default

      • Si el servicio manual-key está habilitado, actualícelo. 


        # svcadm refresh svc:/network/ipsec/manual-key:default

  10. Compruebe que los paquetes se estén protegiendo.

    Para ver el procedimiento, consulte Cómo verificar que los paquetes estén protegidos con IPsec.

Ejemplo 20–1 Adición de directivas IPsec al utilizar una conexión ssh

En este ejemplo, el administrador configura como superusuario las claves y la directiva IPsec en dos sistemas mediante el comando ssh para llegar al segundo sistema. Para obtener más información, consulte la página de comando man ssh(1).

La próxima ocasión que los dos sistemas se comunican, incluida la conexión ssh, la comunicación queda protegida por IPsec.

Ejemplo 20–2 Cómo proteger el tráfico con IPsec sin reiniciar

El siguiente ejemplo es útil cuando se está ejecutando una versión anterior a Solaris 10 4/09. Es decir, en su versión, IPsec no se gestiona como un servicio. El ejemplo describe cómo implementar IPsec en un entorno de prueba. En un entorno de producción, es más seguro reiniciar que ejecutar el comando ipsecconf. Consulte las consideraciones de seguridad al final de este ejemplo.

En lugar de reiniciar en el Paso 6, elija una de estas opciones:

Consideraciones de seguridad: Lea la advertencia que aparece al ejecutar el comando ipsecconf. Un socket que ya está bloqueado, es decir, un socket que ya está en uso, constituye una puerta trasera no segura al sistema. Si desea más información al respecto, consulte Consideraciones de seguridad para ipsecinit.conf e ipsecconf.

ProcedureCómo utilizar IPsec para proteger un servidor web del tráfico que no procede de Internet

Un servidor web seguro permite a los clientes web comunicarse con el servicio web. En un servidor web seguro, el tráfico que no sea de la red debe someterse a comprobaciones de seguridad. El siguiente procedimiento incluye las omisiones del tráfico de red. Además, este servidor web puede realizar solicitudes de clientes DNS no seguras. El resto del tráfico requiere ESP con los algoritmos AES y SHA-1.

Antes de empezar

Debe encontrarse en la zona global para poder configurar la directiva IPsec. Para una zona de IP exclusiva, configure la directiva IPsec en la zona no global. Ha completado Cómo proteger el tráfico entre dos sistemas con IPsec para que se apliquen las condiciones siguientes:

  1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

    Nota –

    El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para iniciar una sesión remota de forma segura.

  2. Determine qué servicios deben omitir las comprobaciones de directiva de seguridad.

    En el caso de un servidor web, estos servicios incluyen los puertos TCP 80 (HTTP) y 443 (HTTP seguro). Si el servidor web proporciona consultas de nombres DNS, el servidor también podría incluir el puerto 53 tanto para TCP como para UDP.

  3. Cree una directiva IPsec para el servidor web y habilítela.

    • A partir de la versión Solaris 10 4/09, siga del Paso 4 al Paso 7.

    • Si está ejecutando una versión anterior a Solaris 10 4/09 , siga del Paso 8 al Paso 11.

    El Paso 12 es opcional en todas las versiones de Solaris.

  4. Agregue la directiva de servidor web al archivo de directiva IPsec.

    Agregue las líneas siguientes al archivo /etc/inet/ipsecinit.conf: 


    # Web traffic that web server should bypass.
{lport  80 ulp tcp dir both} bypass {}
{lport 443 ulp tcp dir both} bypass {}

# Outbound DNS lookups should also be bypassed.
{rport 53 dir both} bypass {}

# Require all other traffic to use ESP with AES and SHA-1.
# Use a unique SA for outbound traffic from the port
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    Esta configuración sólo permite que el tráfico seguro acceda al sistema, con las excepciones de omisión que se describen en el Paso 4.

  5. Compruebe la sintaxis del archivo de directiva IPsec. 


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. Actualice la directiva IPsec. 


    # svcadm refresh svc:/network/ipsec/policy:default

  7. Actualice las claves para IPsec.

    La configuración se ha completado. Si lo desea, puede llevar a cabo el Paso 12.

  8. Cree un archivo en el directorio /etc/inet para la directiva del servidor web.

    Nota –

    Los siguientes pasos configuran un servidor web que está ejecutando una versión anterior a Solaris 10 4/09.

    Asigne al archivo un nombre que indique su finalidad, por ejemplo IPsecWebInitFile. Escriba las siguientes líneas en el archivo:


    # Web traffic that web server should bypass.
{lport  80 ulp tcp dir both} bypass {}
{lport 443 ulp tcp dir both} bypass {}

# Outbound DNS lookups should also be bypassed.
{rport 53 dir both} bypass {}

# Require all other traffic to use ESP with AES and SHA-1.
# Use a unique SA for outbound traffic from the port
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    Esta configuración sólo permite que el tráfico seguro acceda al sistema, con las excepciones de omisión que se describen en el Paso 4.

  9. Copie el contenido del archivo que haya creado en el Paso 8 en el archivo /etc/inet/ipsecinit.conf.

  10. Proteja el archivo IPsecWebInitFile con permisos de sólo lectura.


    # chmod 400 IPsecWebInitFile

  11. Proteja el servidor web sin reiniciar.

    Elija una de las siguientes opciones:

    • Si está utilizando IKE para la administración de claves, detenga el daemon in.iked y reinícielo.


      # pkill in.iked
# /usr/lib/inet/in.iked

    • Si está administrando las claves manualmente, utilice los comandos ipseckey e ipsecconf.

      Utilice IPsecWebInitFile como argumento para el comando ipsecconf. Si utiliza el archivo ipsecinit.conf como argumento, el comando ipsecconf genera errores cuando las directivas del archivo ya están implementadas en el sistema.


      # ipseckey -c -f /etc/inet/secret/ipseckeys 
# ipsecconf -a /etc/inet/IPsecWebInitFile
    Precaución – Precaución –

    Lea la advertencia cuando ejecute el comando ipsecconf. Un socket que ya está bloqueado, es decir, un socket que ya está en uso, constituye una puerta trasera no segura al sistema. Si desea más información al respecto, consulte Consideraciones de seguridad para ipsecinit.conf e ipsecconf. La misma advertencia aparece al reiniciar el daemon in.iked.

    También puede reiniciar. Al reiniciar se asegura de que la directiva IPsec esté aplicada en todas las conexiones TCP. Al reiniciar, las conexiones TCP utilizan la directiva del archivo de directiva IPsec.

  12. (Opcional) Active un sistema remoto para comunicarse con el servidor web para tráfico que no sea de red.

    Escriba la siguiente directiva en el archivo ipsecinit.conf de un sistema remoto:


    # Communicate with web server about nonweb stuff
#
{laddr webserver} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    Un sistema remoto puede comunicarse de forma segura con el servidor web para tráfico que no sea de web sólo cuando las directivas IPsec del sistema coinciden.

ProcedureCómo visualizar las directivas de IPsec

Puede ver las directivas configuradas en el sistema ejecutando el comando ipsecconf sin argumentos.

Antes de empezar

Debe ejecutar el comando ipsecconf en la zona global. Para una zona de IP exclusiva, ejecute el comando ipsecconf en la zona no global.

  1. Asuma un rol que incluya el perfil de administración IPsec de la red o conviértase en superusuario.

    Si está ejecutando una versión anterior a Solaris 10 4/09, el perfil de Network IPsec Management no está disponible. Utilice el perfil de la seguridad de la red.

    Para crear un rol que incluya un perfil de seguridad de red y asignarlo a un usuario, consulte Cómo configurar una función para la seguridad de la red.

  2. Visualizar las directivas de IPsec.

    1. Visualice las entradas de la directiva IPsec global en el orden en que se agregaron las entradas.


      $ ipsecconf

      El comando muestra cada entrada con un índice, seguida de un número.

    2. Visualice las entradas de la directiva IPsec en el orden en que se produzca una coincidencia.


      $ ipsecconf -l

    3. Visualice las entradas de la directiva IPsec, incluidas las entradas por túnel, en el orden en que se produzca una coincidencia.


      $ ipsecconf -L

ProcedureCómo generar números aleatorios en un sistema Solaris

Si está especificando claves manualmente, el material de claves debe ser aleatorio. El formato del material de claves de un sistema Solaris es hexadecimal. Otros sistemas operativos pueden requerir material de claves ASCII. Para generar material de claves para un sistema Solaris que se comunica con otro sistema operativo que requiera ASCII, consulte el Ejemplo 23–1.

Si su sitio cuenta con un generador de números aleatorios, utilícelo. De lo contrario, puede utilizar el comando od con el dispositivo Solaris /dev/random como entrada. Para más información, consulte la página del comando man od(1).

En la versión Solaris 10 4/09, también puede utilizar el comando pktool. La sintaxis de este comando es más sencilla que la del comando od. Para obtener más detalles, consulte How to Generate a Symmetric Key by Using the pktool Command de System Administration Guide: Security Services.

  1. Genere números aleatorios en formato hexadecimal.


    % od -x|-X -A n file | head -n
    -x

    Muestra el vaciado octal en formato hexadecimal. El formato hexadecimal resulta útil para el material de claves. Dicho formato se imprime en bloques de 4 caracteres.

    -X

    Muestra el vaciado octal en formato hexadecimal. Dicho formato se imprime en bloques de 8 caracteres.

    -A n

    Elimina la base de desfase de entrada de la pantalla.

    archivo

    Actúa como origen para los números aleatorios.

    head -n

    Limita el resultado de la pantalla a las primeras n líneas.

  2. Combine el resultado para crear una clave con la longitud adecuada.

    Elimine los espacios entre los números de una línea para crear una clave de 32 caracteres. Una clave de 32 caracteres tiene 128 bits. En el caso de un índice de parámetros de seguridad (SPI), debe utilizar una clave de 8 caracteres. La clave debe utilizar el prefijo 0x.

Ejemplo 20–3 Generación de material de claves para IPsec

El ejemplo siguiente muestra dos líneas de claves en grupos de ocho caracteres hexadecimales cada uno.


% od -X -A n /dev/random | head -2
         d54d1536 4a3e0352 0faf93bd 24fd6cad
         8ecc2670 f3447465 20db0b0c c83f5a4b

Al combinar los cuatro números de la primera línea, puede crear una clave de 32 caracteres. Un número de 8 caracteres precedido de 0x proporciona un valor de SPI adecuado, por ejemplo, 0xf3447465.

El ejemplo siguiente muestra dos líneas de claves en grupos de cuatro caracteres hexadecimales cada uno.


% od -x -A n /dev/random | head -2
         34ce 56b2 8b1b 3677 9231 42e9 80b0 c673
         2f74 2817 8026 df68 12f4 905a db3d ef27

Al combinar los ocho números en la primera línea, puede crear una clave de 32 caracteres.

ProcedureCómo crear manualmente asociaciones de seguridad IPsec

El procedimiento siguiente proporciona el material de claves para el procedimiento, Cómo proteger el tráfico entre dos sistemas con IPsec. Está generando teclas para dos sistemas, partym y enigma. Se generan las claves en un sistema, y después se utilizan las teclas del primer sistema en ambos sistemas.

Antes de empezar

Debe estar en la zona global para administrar material de claves para una zona IP compartida.

  1. Genere el material de claves para la SA.

    Necesita tres números aleatorios hexadecimales para el tráfico saliente y tres para el tráfico entrante.

    Por tanto, un sistema necesita generar los siguientes números:

    • Dos números aleatorios hexadecimales como valor para la palabra clave spi. Un número es para el tráfico saliente. Otro es para el tráfico entrante. Cada número puede tener hasta ocho caracteres de longitud.

    • Dos números aleatorios hexadecimales para el algoritmo SHA-1 para la autenticación. Para una clave de 160 bits, cada numero debe tener 40 caracteres de longitud. Un número es para dst enigma. Un número es para dst partym.

    • Dos números aleatorios hexadecimales para el algoritmo DES para el cifrado de ESP. Para una clave de 256 bits, cada numero debe tener 64 caracteres de longitud. Un número es para dst enigma. Un número es para dst partym.

    Si dispone de un generador de números aleatorios en su sitio, utilícelo. También puede utilizar el comando od. Consulte Cómo generar números aleatorios en un sistema Solaris para ver el procedimiento.

  2. En la consola del sistema de uno de los sistemas, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

    Nota –

    El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para iniciar una sesión remota de forma segura.

  3. Cree las SA.

    • A partir de la versión Solaris 10 4/09, siga del Paso 8 al Paso 10.

    • Si está ejecutando una versión anterior a Solaris 10 4/09, siga del Paso 4 al Paso 9.

  4. Active el modo de comando ipseckey.


    # ipseckey

>

    El símbolo del sistema > indica que se encuentra en modo de comando ipseckey.

  5. Si está sustituyendo las SA existentes, vacíelas.


    > flush
>

    Para evitar que un intruso interrumpa las SA, debe sustituir el material de claves.

    Nota –

    Es necesario coordinar la sustitución de claves en los sistemas que se comunican. Al sustituir las SA en un sistema, también deben sustituirse las del sistema remoto.

  6. Para crear SA, escriba el comando siguiente.


    > add protocol spi random-hex-string \
src addr dst addr2 \
protocol-prefix_alg protocol-algorithm  \
protocol-prefixkey random-hex-string-of-algorithm-specified-length

    Esta sintaxis también se utiliza para sustituir las SA que acaba de vaciar.

    protocolo

    Especifica esp o ah.

    cadena_hex_aleatoria

    Especifica un número aleatorio de hasta ocho caracteres en formato hexadecimal. Preceda los caracteres con 0x. Si especifica más números de los que acepta el índice de parámetros de seguridad (SPI), el sistema omitirá los números adicionales. Si especifica menos números de los que acepta el SPI, el sistema rellena la entrada.

    dir

    Especifica la dirección IP de un sistema.

    dir2

    Especifica la dirección IP del sistema equivalente a dir.

    prefijo_protocolo

    Especifica un prefijo encr o auth. El prefijo encr se utiliza con el protocolo esp. El prefijo auth se utiliza con el protocolo ah, y para autenticar el protocolo esp.

    algoritmo_protocolo

    Especifica un algoritmo para ESP o AH. Cada algoritmo requiere una clave de una longitud específica.

    Los algoritmos de autenticación incluyen MD5 y SHA-1. A partir de la versión Solaris 10 4/09, SHA256 y SHA512 son compatibles. Los algoritmos de cifrado incluyen DES, 3DES, AES y Blowfish.

    cadena_hex_aleatoria_de_longitud_algoritmo_especificada

    Especifica un número hexadecimal aleatorio de la longitud que requiere el algoritmo. Por ejemplo, el algoritmo MD5 requiere una cadena de 32 caracteres para su clave de 128 bits. El algoritmo 3DES requiere una cadena de 48 caracteres para su clave de 192 bits.

    1. Por ejemplo, en el sistema enigma, proteja los paquetes salientes.

      Utilice los números aleatorios que haya generado en el paso Paso 1.

      Para Solaris 10 1/06:


      > add esp spi 0x8bcd1407 \
src 192.168.116.16 dst 192.168.13.213 \
encr_alg aes \
auth_alg sha1 \
encrkey c0c65b888c2ee301c84245c3da63127e92b2676105d5330e85327c1442f37d49 \
authkey 6fab07fec4f2895445500ed992ab48835b9286ff
>
      Nota –

      El sistema equivalente debe utilizar el mismo material de claves y el mismo SPI.

    2. Continúe en modo de comando ipseckey en el sistema enigma y proteja los paquetes entrantes.

      Escriba los siguientes comandos para proteger los paquetes:


      > add esp spi 0x122a43e4 \
src 192.168.13.213 dst 192.168.116.16 \
encr_alg aes \
auth_alg sha1 \
encrkey a2ea934cd62ca7fa14907cb2ad189b68e4d18c976c14f22b30829e4b1ea4d2ae \
authkey c80984bc4733cc0b7c228b9b74b988d2b7467745
>
      Nota –

      Las claves y el SPI pueden ser diferentes para cada SA. Debe asignar claves y SPI distintos para cada SA.

  7. Para salir del modo de comando ipseckey, pulse Control-D o escriba quit.

  8. Agregue, el material de claves al archivo /etc/inet/secret/.

    En las versiones anteriores a Solaris 10 4/09 este paso garantiza que el material de claves está disponible para IPsec al reiniciar.

    Las líneas del archivo /etc/inet/secret/ipseckeys son idénticas al lenguaje de la línea de comandos ipseckey.

    1. Por ejemplo, el archivo /etc/inet/secret/ipseckeys del sistema enigma tendría un aspecto similar al siguiente:


      # ipseckeys - This file takes the file format documented in 
#   ipseckey(1m).
#   Note that naming services might not be available when this file
#   loads, just like ipsecinit.conf.
#
# for outbound packets on enigma
add esp spi 0x8bcd1407 \
   src 192.168.116.16 dst 192.168.13.213  \
   encr_alg aes \
   auth_alg sha1  \
   encrkey  c0c65b888c2ee301c84245c3da63127e92b2676105d5330e85327c1442f37d49 \
   authkey  6fab07fec4f2895445500ed992ab48835b9286ff
#
# for inbound packets
add esp spi 0x122a43e4 \
   src 192.168.13.213 dst 192.168.116.16 \
   encr_alg aes \
   auth_alg sha1  \
   encrkey a2ea934cd62ca7fa14907cb2ad189b68e4d18c976c14f22b30829e4b1ea4d2ae \
   authkey c80984bc4733cc0b7c228b9b74b988d2b7467745

    2. Proteja el archivo con permisos de sólo lectura.


      # chmod 400 /etc/inet/secret/ipseckeys

  9. Repita el procedimiento en el sistema partym.

    Utilice el mismo material de claves que utilizó en enigma.

    El material de claves de los dos sistemas debe ser idéntico. Tal como se muestra en el ejemplo siguiente, sólo los comentarios de ipseckeys son distintos. Los comentarios difieren porque dst enigma entra en el sistema enigma y sale del sistema partym.


    # partym ipseckeys file
#
# for inbound packets
add esp spi 0x8bcd1407 \
   src 192.168.116.16 dst 192.168.13.213  \
   encr_alg aes \
   auth_alg sha1  \
   encrkey  c0c65b888c2ee301c84245c3da63127e92b2676105d5330e85327c1442f37d49 \
   authkey  6fab07fec4f2895445500ed992ab48835b9286ff
#
# for outbound packets
add esp spi 0x122a43e4 \
   src 192.168.13.213 dst 192.168.116.16 \
   encr_alg aes \
   auth_alg sha1  \
   encrkey a2ea934cd62ca7fa14907cb2ad189b68e4d18c976c14f22b30829e4b1ea4d2ae \
   authkey c80984bc4733cc0b7c228b9b74b988d2b7467745

  10. Habilite el servicio manual-key.


    # svcadm enable svc:/network/ipsec/manual-key

    Para sustituir las claves de la versión actual, consulte el Ejemplo 20–4.

Ejemplo 20–4 Sustitución de SA de IPsec

En este ejemplo, el administrador está configurando un sistema que ejecuta la versión Solaris 10 actual. El administrador genera nuevas claves, cambia la información sobre claves en el archivo ipseckeys y reinicia el servicio.

ProcedureCómo verificar que los paquetes estén protegidos con IPsec

Para verificar que los paquetes estén protegidos, pruebe la conexión con el comando snoop. Los prefijos siguientes pueden aparecer en el resultado de snoop:

Antes de empezar

Debe ser superusuario o asumir un rol equivalente para crear el resultado snoop. Para poder probar la conexión, es preciso tener acceso a ambos sistemas.

  1. Conviértase en superusuario en un sistema, por ejemplo partym.


    % su -
Password: Type root password
#

  2. En el sistema partym, prepárese para buscar paquetes desde un sistema remoto.

    En una ventana de terminal en partym, busque los paquetes desde el sistema enigma.


    # snoop -v enigma
Using device /dev/hme (promiscuous mode)

  3. Envíe un paquete desde el sistema remoto.

    En otra ventana de terminal, inicie sesión remotamente en el sistema enigma. Facilite su contraseña. A continuación, conviértase en superusuario y envíe un paquete del sistema enigma al sistema partym. El paquete debe capturarse mediante el comando snoop -v enigma.


    % ssh enigma
Password: Type your password
% su -
Password: Type root password
# ping partym

  4. Examine el resultado de snoop.

    En el sistema partym, debería ver el resultado que incluye la información de AH y ESP tras la información de encabezado IP inicial. Aparecerá información de AH y ESP que muestra que se están protegiendo los paquetes:


    IP:   Time to live = 64 seconds/hops
IP:   Protocol = 51 (AH)
IP:   Header checksum = 4e0e
IP:   Source address = 192.168.116.16, enigma
IP:   Destination address = 192.168.13.213, partym
IP:   No options
IP:
AH:  ----- Authentication Header -----
AH:
AH:  Next header = 50 (ESP)
AH:  AH length = 4 (24 bytes)
AH:  <Reserved field = 0x0>
AH:  SPI = 0xb3a8d714
AH:  Replay = 52
AH:  ICV = c653901433ef5a7d77c76eaa
AH:
ESP:  ----- Encapsulating Security Payload -----
ESP:
ESP:  SPI = 0xd4f40a61
ESP:  Replay = 52
ESP:     ....ENCRYPTED DATA....

ETHER:  ----- Ether Header -----
...

ProcedureCómo configurar una función para la seguridad de la red

Si está utilizando RBAC (Role-Based Access Control) para administrar los sistemas, siga este procedimiento para proporcionar una función de administración de red o de seguridad de red.

  1. Busque los perfiles de derechos de red en la base de datos prof_attr local.

    En la versión actual, aparece una salida similar a la siguiente: 


    % cd /etc/security
% grep Network prof_attr
Network IPsec Management:::Manage IPsec and IKE...
Network Link Security:::Manage network link security...
Network Management:::Manage the host and network configuration...
Network Security:::Manage network and host security...
Network Wifi Management:::Manage wifi network configuration...
Network Wifi Security:::Manage wifi network security...

    Si está ejecutando una versión anterior a Solaris 10 4/09, la salida presenta un aspecto parecido al siguiente: 


    % cd /etc/security
% grep Network prof_attr
Network Management:::Manage the host and network configuration  
Network Security:::Manage network and host security  
System Administrator::: Network Management 

    El perfil de administración de red es un perfil complementario del perfil de administrador de sistemas. Si ha incluido el perfil de derechos de administrador de sistemas en un rol, dicho rol podrá ejecutar los comandos del perfil de administración de red.

  2. Determine qué comandos hay disponibles en el perfil de derechos de administración de red.


    % grep "Network Management" /etc/security/exec_attr
Network Management:solaris:cmd:::/usr/sbin/ifconfig:privs=sys_net_config
…
Network Management:suser:cmd:::/usr/sbin/snoop:uid=0

    Los comandos de directiva solaris se ejecutan con privilegio ( privs=sys_net_config). Los comandos de directiva suser se ejecutan como superusuario (uid=0).

  3. Decida el ámbito de las funciones de seguridad de la red en su sitio.

    Utilice las definiciones de los perfiles de derechos en el Paso 1 para guiar la decisión.

    • Para crear una función que administre toda la seguridad de la red, utilice el perfil de derechos de la seguridad de la red.

    • En la versión actual, para crear una función que administre sólo IPsec e IKE, utilice el perfil de derechos de gestión de red IPsec.

  4. Cree un rol de seguridad de red que incluya el perfil de derechos de gestión de la red.

    Una función con el perfil de derechos de gestión de red IPsec o de seguridad de la red, además del perfil de gestión de la red, puede ejecutar los comandos ifconfig, snoop, ipsecconf e ipseckey, entre otros, con privilegios adecuados.

    Para crear el rol, asignarlo a un usuario y registrar los cambios con el servicio de nombres, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

Ejemplo 20–5 División de responsabilidades de seguridad de la red entre las funciones

En este ejemplo, el administrador divide las responsabilidades de seguridad de la red entre dos funciones. Una función administra wifi y seguridad de los vínculos; otra administra IPsec e IKE. Cada función está asignada a tres personas, una por turno.

El administrador crea las funciones como se indica a continuación:

ProcedureCómo administrar servicios de IPsec e IKE

Los siguientes pasos ofrecen los usos más probables de los servicios SMF para IPsec, IKE y la gestión manual de claves. Por defecto, los servicios policy e ipsecalgs están habilitados. También por defecto, los servicios ike y manual-key están inhabilitados.

  1. Para administrar la directiva IPsec, lleve a cabo una de las siguientes acciones:

    • Después de agregar nuevas directivas al archivo ipsecinit.conf, actualice el servicio policy. 


      # svcadm refresh svc:/network/ipsec/policy

    • Tras cambiar el valor de una propiedad de servicio, consulte el valor de la propiedad y, a continuación, actualice y reinicie el servicio policy. 


      # svccfg -s policy setprop config/config_file=/etc/inet/MyIpsecinit.conf
# svcprop -p config/config_file policy
/etc/inet/MyIpsecinit.conf
# svcadm refresh svc:/network/ipsec/policy
# svcadm restart svc:/network/ipsec/policy

  2. Para administrar claves automáticamente, realice una de las siguientes acciones:

    • Después de agregar entradas al archivo /etc/inet/ike/config, habilite el servicio ike. 


      # svcadm enable svc:/network/ipsec/ike

    • Después de cambiar las entradas en el archivo /etc/inet/ike/config, actualice el servicio ike. 


      # svcadm refresh svc:/network/ipsec/ike

    • Tras cambiar el valor de una propiedad de servicio, consulte el valor de la propiedad y, a continuación, actualice el servicio y reinícielo. 


      # svccfg -s ike setprop config/admin_privilege=modkeys
# svcprop -p config/admin_privilege ike
modkeys
# svcadm refresh svc:/network/ipsec/ike
# svcadm restart svc:/network/ipsec/ike

    • Para detener el servicio ike, inhabilítelo. 


      # svcadm disable svc:/network/ipsec/ike

  3. Para administrar claves manualmente, lleve a cabo una de las siguientes acciones:

    • Después de agregar entradas al archivo /etc/inet/secret/ipseckeys, habilite el servicio manual-key. 


      # svcadm enable svc:/network/ipsec/manual-key

    • Después de cambiar el archivo ipseckeys, actualice el servicio. 


      # svcadm refresh manual-key

    • Tras cambiar el valor de una propiedad de servicio, consulte el valor de la propiedad; a continuación, actualice y reinicie el servicio. 


      # svccfg -s manual-key setprop config/config_file=/etc/inet/secret/MyIpseckeyfile
# svcprop -p config/config_file manual-key
/etc/inet/secret/MyIpseckeyfile
# svcadm refresh svc:/network/ipsec/manual-key
# svcadm restart svc:/network/ipsec/manual-key

    • Para impedir la gestión manual de claves, inhabilite el servicio manual-key. 


      # svcadm disable svc:/network/ipsec/manual-key

  4. Si modifica la tabla de algoritmos y los protocolos IPsec, actualice el servicio ipsecalgs. 


    # svcadm refresh svc:/network/ipsec/ipsecalgs
Errores más frecuentes

Utilice el comando svcs servicio para buscar el estado de un servicio. Si el servicio está en el modo maintenance, siga las sugerencias de depuración en la salida del comando svcs -x servicio.

Protección de una VPN con IPsec

Los túneles de IPsec pueden proteger una VPN. En la versión Solaris 10 7/07, un túnel puede estar en modo de túnel o de transporte. El modo de túnel es interoperable con la implementación de IPsec por parte de otros proveedores. El modo de transporte es interoperable con las versiones anteriores de SO Solaris. Para ver una descripción de los modos de túnel, consulte Modos de transporte y túnel en IPsec.

Los túneles en modo túnel ofrecen un control más preciso del tráfico. En modo túnel, para ver una dirección IP interna, puede especificar la protección concreta que desee, hasta alcanzar un único puerto.

Ejemplos de protección de una VPN con IPsec mediante el uso de túneles en modo túnel

Figura 20–1 Diagrama de túnel de IPsec

El diagrama muestra una VPN que conecta dos LAN. Cada LAN tiene cuatro subredes.

Los ejemplos siguientes presuponen que el túnel se ha configurado para todas las subredes de la LAN:


## Tunnel configuration ##
# Tunnel name is ip.tun0
# Intranet point for the source is 10.1.2.1
# Intranet point for the destination is 10.2.3.1
# Tunnel source is 192.168.1.10
# Tunnel destination is 192.168.2.10
Ejemplo 20–6 Creación de un túnel que puedan utilizar todas las subredes

En este ejemplo, se puede crear un túnel de todo el tráfico de las redes LAN locales de la red LAN central de la Figura 20–1 del enrutador 1 al 2 y, a continuación, transferirlo a todas las redes LAN locales de la red LAN internacional. El tráfico se cifra con AES.


## IPsec policy ##
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
Ejemplo 20–7 Creación de un túnel que sólo conecta dos subredes

En este ejemplo, sólo se crea un túnel y se cifra el tráfico entre la subred 10.1.2.0/24 de la LAN central y la subred 10.2.3.0/24 de la LAN internacional. En caso de no haber otras directivas IPsec para Central, si la LAN central intenta enrutar el tráfico para otras LAN por este túnel, el tráfico se transferirá al enrutador 1.


## IPsec policy ##
{tunnel ip.tun0 negotiate tunnel laddr 10.1.2.0/24 raddr 10.2.3.0/24} 
 ipsec {encr_algs aes encr_auth_algs md5 sha1 shared}
Ejemplo 20–8 Creación de un túnel sólo para el tráfico de correo electrónico entre dos subredes

En este ejemplo, se crea un túnel sólo para el tráfico de correo electrónico. El tráfico se transfiere de la subred 10.1.2.0/24 de la LAN central al servidor de correo electrónico de la subred 10.2.3.0/24 de la LAN internacional. El correo electrónico se cifra con Blowfish. Las directivas se aplican a los puertos de correo electrónico remoto y local. La directiva rport protege el correo electrónico que Central envía al puerto de correo electrónico remoto de Internacional. La directiva lport protege el correo electrónico que Central recibe de Internacional en el puerto local 25.


## IPsec policy for email from Central to Overseas ##
{tunnel ip.tun0 negotiate tunnel ulp tcp rport 25 
 laddr 10.1.2.0/24 raddr 10.2.3.0/24} 
 ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}
 

## IPsec policy for email from Overseas to Central ##
{tunnel ip.tun0 negotiate tunnel ulp tcp lport 25 
 laddr 10.1.2.0/24 raddr 10.2.3.0/24} 
 ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}
Ejemplo 20–9 Creación de un túnel para el tráfico FTP para todas las subredes

En este ejemplo, la directiva IPsec protege los puertos FTP de la Figura 20–1 con DES para todas las subredes de la red LAN central a todas las subredes de la red LAN internacional. Esta configuración funciona para el modo activo de FTP.


## IPsec policy for outbound FTP from Central to Overseas ##
{tunnel ip.tun0 negotiate tunnel ulp tcp rport 21} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
{tunnel ip.tun0 negotiate tunnel ulp tcp lport 20} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
 

## IPsec policy for inbound FTP from Central to Overseas ##
{tunnel ip.tun0 negotiate tunnel ulp tcp lport 21} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
{tunnel ip.tun0 negotiate tunnel ulp tcp rport 20} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

Protección de una VPN con IPsec (mapa de tareas)

El mapa de tareas siguiente indica procedimientos que configuran IPsec para la protección del tráfico por Internet. Estos procedimientos configuran una red privada virtual (VPN) entre dos sistemas separados por Internet. Un uso común de esta tecnología es proteger el tráfico entre los trabajadores remotos y su oficina corporativa.

Tarea 

Descripción 

Para obtener instrucciones 

Proteger el tráfico de túnel en modo túnel por IPv4. 

Protege el tráfico en modo transporte entre dos sistemas Solaris 10, dos sistemas Oracle Solaris y un sistema Oracle Solaris Express. El sistema Solaris 10 debe ejecutar como mínimo la versión Solaris 10 7/07.  

Asimismo, protege el tráfico en modo túnel entre un sistema Solaris 10 o un sistema Oracle Solaris Express y un sistema que se ejecuta en otra plataforma. El sistema Solaris 10 debe ejecutar como mínimo la versión Solaris 10 7/07.  

Cómo proteger una VPN con un túnel IPsec en modo túnel mediante IPv4

Proteger el tráfico de túnel en modo túnel por IPv6. 

Protege el tráfico en modo túnel entre dos sistemas Oracle Solaris que utilizan el protocolo IPv6. 

Cómo proteger una VPN con un túnel IPsec en modo túnel mediante IPv6

Proteger el tráfico de túnel en modo de transporte por IPv4. 

Protege el tráfico en modo transporte entre dos sistemas Solaris 10, dos sistemas Solaris o entre un sistema Solaris 10 y un sistema Oracle Solaris. El sistema Solaris 10 debe ejecutar como mínimo la versión Solaris 10 7/07. 

Además, protege el tráfico en modo transporte entre un sistema que ejecuta una versión anterior de SO Solaris y Solaris 10 o un sistema Oracle Solaris. El sistema Solaris 10 debe ejecutar como mínimo la versión Solaris 10 7/07. 

Cómo proteger una VPN con un túnel IPsec en modo transporte mediante IPv4

Protege el tráfico utilizando una sintaxis más antigua y no admitida. Este método resulta útil cuando se está comunicando con un sistema que ejecuta una versión anterior de SO Solaris. Este método simplifica la comparación de los archivos de configuración de los dos sistemas. 

Ejemplo 20–11

Ejemplo 20–16

Proteger el tráfico de túnel en modo transporte por IPv6. 

Protege el tráfico en modo transporte entre dos sistemas Oracle Solaris que utilizan el protocolo IPv6. 

Cómo proteger una VPN con un túnel IPsec en modo transporte mediante IPv6

Evitar la falsificación de la IP.  

Crea un servicio SMF para evitar que el sistema reenvíe paquetes a través de una VPN sin descifrarlos.  

Cómo evitar la falsificación de la IP

Descripción de la topología de red para la protección de una VPN por parte de las tareas de IPsec

Los procedimientos que se describen a continuación presuponen la siguiente configuración. Para ver una representación de la red, consulte la Figura 20–2.

Figura 20–2 VPN de ejemplo entre oficinas separadas por Internet

El diagrama muestra los detalles de una VPN entre las oficinas de Europa y California.

Como muestra la ilustración anterior, los procedimientos para la red IPv4 utilizan los siguientes parámetros de configuración.

Parámetro 

Europa 

California 

Nombre del sistema 

 

enigma
 

partym

Interfaz de la intranet del sistema 

 

hme1
 

hme1

La dirección de intranet del sistema, también dirección -punto en el Paso 7 


10.16.16.6
 

10.1.3.3

Interfaz de Internet del sistema 

 

hme0
 

hme0

Dirección de Internet del sistema, también dirección tsrc en el Paso 7 


192.168.116.16
 

192.168.13.213

Nombre del enrutador de Internet 

 

router-E
 

router-C

Dirección del enrutador de Internet 

 

192.168.116.4
 

192.168.13.5

Nombre de túnel 

 

ip.tun0
 

ip.tun0

Las siguientes direcciones IPv6 se utilizan en los procedimientos. Los nombres de túnel son los mismos.

Parámetro 

Europa 

California 

Dirección de intranet del sistema 

 

6000:6666::aaaa:1116
 

6000:3333::eeee:1113

Dirección de Internet del sistema 

 

2001::aaaa:6666:6666
 

2001::eeee:3333:3333

Dirección del enrutador de Internet 

 

2001::aaaa:0:4
 

2001::eeee:0:1

ProcedureCómo proteger una VPN con un túnel IPsec en modo túnel mediante IPv4

En modo túnel, el paquete IP interior determina la directiva IPsec que protege su contenido.

Este procedimiento amplía el procedimiento de Cómo proteger el tráfico entre dos sistemas con IPsec. El procedimiento de configuración se describe en Descripción de la topología de red para la protección de una VPN por parte de las tareas de IPsec.

Nota –

Lleve a cabo los pasos de este procedimiento en ambos sistemas.

Además de conectar dos sistemas, está conectando dos intranets que se conectan a estos dos sistemas. Los sistemas de este procedimiento actúan como portales.

Antes de empezar

Debe estar en la zona global para configurar la directiva IPsec para el sistema o para una zona de IP compartida. Para una zona de IP exclusiva, configure la directiva IPsec en la zona no global.

  1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

    Nota –

    El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

  2. Controle el flujo de paquetes antes de configurar IPsec.

    1. Asegúrese de que el reenvío de IP y el enrutamiento dinámico de IP estén desactivados.


      # routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
IPv4 forwarding     disabled           disabled
   IPv4 routing     default (enabled)   enabled
…

      Si el reenvío de IP y el enrutamiento dinámico de IP están habilitados, puede inhabilitarlos escribiendo:


      # routeadm -d ipv4-routing -d ipv4-forwarding
# routeadm -u

      La desactivación del reenvío de IP impide que los paquetes se envíen de una red a otra a través de este sistema. Para ver una descripción del comando routeadm, consulte la página del comando man routeadm(1M).

    2. Active los hosts múltiples de destino estricto de IP. 


      # ndd -set /dev/ip ip_strict_dst_multihoming 1

      La activación de los hosts múltiples de destino estricto de IP garantiza que los paquetes de una de las direcciones de destino del sistema llegan a la dirección de destino correcta.

      Cuando está activa la función de hosts múltiples de destino estricto, los paquetes que alcanzan una determinada interfaz deben dirigirse a una de las direcciones IP locales de dicha interfaz. Todos los demás paquetes, incluidos los que se dirigen a otras direcciones locales del sistema, se eliminan.

      Precaución – Precaución –

      El valor de host múltiple vuelve al predeterminado cuando se inicia el sistema. Para hacer que el valor cambiado sea persistente, consulte Cómo evitar la falsificación de la IP .

    3. Desactive la mayoría de los servicios de red, y posiblemente todos.

      Nota –

      Si su sistema se instaló con el perfil SMF "limitado", puede omitir este paso. Los servicios de red se desactivan, a excepción de Solaris Secure Shell.

      La desactivación de los servicios de red evita que los paquetes IP dañen el sistema. Por ejemplo, podrían aprovecharse un daemon SNMP, una conexión telnet o una conexión rlogin.

      Elija una de las siguientes opciones:

      • Si ejecuta Solaris 10 11/06 o una versión posterior, ejecute el perfil SMF "limitado".


        # netservices limited

      • De lo contrario, desactive los servicios de red de forma individual.


        # svcadm disable network/ftp:default
# svcadm disable network/finger:default
# svcadm disable network/login:rlogin
# svcadm disable network/nfs/server:default
# svcadm disable network/rpc/rstat:default
# svcadm disable network/smtp:sendmail
# svcadm disable network/telnet:default

    4. Compruebe que la mayoría de los servicios de red estén inhabilitados.

      Compruebe que los montajes de realimentación y el servicio ssh se estén ejecutando.


      # svcs | grep network
online         Aug_02   svc:/network/loopback:default
…
online         Aug_09   svc:/network/ssh:default

  3. Agregue un par de SA entre los dos sistemas.

    Elija una de las siguientes opciones:

  4. Agregue la directiva IPsec.

    Edite el archivo /etc/inet/ipsecinit.conf para agregar la directiva IPsec para la VPN. Para reforzar la directiva, consulte el Ejemplo 20–12. Para ver ejemplos adicionales, consulte Ejemplos de protección de una VPN con IPsec mediante el uso de túneles en modo túnel.

    En esta directiva, la protección IPsec no se necesita entre sistemas de la LAN local y la dirección IP del servidor de seguridad, de modo que se agrega una instrucción bypass.

    1. En el sistema enigma, escriba la entrada siguiente en el archivo ipsecinit.conf:


      # LAN traffic to and from this host can bypass IPsec.
{laddr 10.16.16.6 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    2. En el sistema partym, escriba la entrada siguiente en el archivo ipsecinit.conf:


      # LAN traffic to and from this host can bypass IPsec.
{laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

  5. (Opcional) Compruebe la sintaxis del archivo de directiva IPsec. 


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. Para configurar el túnel y protegerlo con IPsec, siga los pasos descritos en función de la versión de Solaris:

    • A partir de la versión Solaris 10 4/09, siga los pasos del Paso 7 al Paso 13 y, a continuación, ejecute el protocolo de enrutamiento en Paso 22.

    • Si está ejecutando una versión anterior a Solaris 10 4/09, siga las indicaciones del Paso 14 al Paso 22.

  7. Configure el túnel, ip.tun0, en el archivo /etc/hostname.ip.tun0.

    La sintaxis del archivo es la siguiente:


    system1-point system2-point tsrc system1-taddr tdst system2-taddr router up

    1. En el sistema enigma, agregue la entrada siguiente al archivo hostname.ip.tun0:


      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up

    2. En el sistema partym, agregue la entrada siguiente al archivo hostname.ip.tun0:


      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

  8. Proteja el túnel con la directiva IPsec que ha creado.


    # svcadm refresh svc:/network/ipsec/policy:default

  9. Para leer el contenido del archivo de configuración de túnel en el núcleo, reinicie los servicios de red. 


    # svcadm restart svc:/network/initial:default

  10. Active el reenvío de IP para la interfaz hme1.

    1. En el sistema enigma, agregue la entrada del enrutador al archivo /etc/hostname.hme1.


      192.168.116.16 router

    2. En el sistema partym, agregue la entrada del enrutador al archivo /etc/hostname.hme1.


      192.168.13.213 router

    El reenvío de IP significa que los paquetes que llegan desde cualquier parte se pueden reenviar. El reenvío de IP también significa que los paquetes que abandonan esta interfaz podrían haberse originado en cualquier otra parte. Para reenviar un paquete correctamente, tanto la interfaz receptora como la de transmisión deben tener activa la opción de reenvío de IP.

    Dado que la interfaz hme1 está dentro de la intranet, el reenvío de IP debe estar activo para hme1. Dado que ip.tun0 conecta los dos sistemas a través de Internet, el reenvío de IP debe estar activo para ip.tun0.

    La interfaz hme0 tiene su propio reenvío de IP desactivado para evitar que un adversario externo inserte paquetes en la intranet protegida. El término externo hace referencia a Internet.

  11. Asegúrese de que los protocolos de enrutamiento no publiquen la ruta predeterminada en la intranet.

    1. En el sistema enigma, agregue el indicador private al archivo /etc/hostname.hme0.


      10.16.16.6 private

    2. En el sistema partym, agregue el indicador private al archivo /etc/hostname.hme0.


      10.1.3.3 private

    Aunque hme0 tenga el reenvío de IP desactivado, la implementación de un protocolo de enrutamiento podría seguir publicando la interfaz. Por ejemplo, el protocolo in.routed podría seguir anunciando que hme0 está disponible para reenviar paquetes a sus equivalentes dentro de la intranet. Al configurar el indicador private de la interfaz, se evita la publicación de estos datos.

  12. Agregue manualmente una ruta predeterminada a través de la interfaz hme0.

    La ruta predeterminada debe ser un enrutador con acceso directo a Internet.

    1. En el sistema enigma, agregue la ruta siguiente:


      # route add default 192.168.116.4

    2. En el sistema partym, agregue la ruta siguiente:


      # route add default 192.168.13.5

      Aunque la interfaz hme0 no forme parte de la intranet, hme0 necesita alcanzar su sistema equivalente a través de Internet. Para encontrar su equivalente, hme0 necesita información sobre el enrutamiento de Internet. El sistema VPN aparece como host, en lugar de aparecer como enrutador, para el resto de Internet. Por tanto, puede utilizar un enrutador predeterminado o ejecutar el protocolo de descubrimiento de enrutador para encontrar un sistema equivalente. Para más información, consulte las páginas del comando man route(1M) e in.routed(1M).

  13. Para completar el procedimiento, vaya al Paso 22 para ejecutar un protocolo de enrutamiento.

  14. Configure el túnel, ip.tun0.

    Nota –

    Los siguientes pasos configuran un túnel en un sistema que ejecuta una versión anterior a Solaris 10 4/09.

    Utilice los comandos ifconfig para crear la interfaz de punto a punto:


    # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 system1-point system2-point \
tsrc system1-taddr tdst system2-taddr

    1. En el sistema enigma, escriba los comandos siguientes:


      # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.16.16.6 10.1.3.3 \
tsrc 192.168.116.16 tdst 192.168.13.213

    2. En el sistema partym, escriba los comandos siguientes:


      # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.1.3.3 10.16.16.6  \
tsrc 192.168.13.213 tdst 192.168.116.16

  15. Proteja el túnel con la directiva IPsec que ha creado.


    # ipsecconf

  16. Muestre el enrutador para el túnel.


    # ifconfig ip.tun0 router up

  17. Active el reenvío de IP para la interfaz hme1.


    # ifconfig hme1 router

    El reenvío de IP significa que los paquetes que llegan desde cualquier parte se pueden reenviar. El reenvío de IP también significa que los paquetes que abandonan esta interfaz podrían haberse originado en cualquier otra parte. Para reenviar un paquete correctamente, tanto la interfaz receptora como la de transmisión deben tener activa la opción de reenvío de IP.

    Puesto que la interfaz hme1 está dentro de la intranet, el reenvío de IP debe estar activo para hme1. Dado que ip.tun0 conecta los dos sistemas a través de Internet, el reenvío de IP debe estar activo para ip.tun0.

    La interfaz hme0 tiene su propio reenvío de IP desactivado para evitar que un adversario externo inserte paquetes en la intranet protegida. El término externo hace referencia a Internet.

  18. Asegúrese de que los protocolos de enrutamiento no publiquen la ruta predeterminada en la intranet.


    # ifconfig hme0 private

    Aunque hme0 tenga el reenvío de IP desactivado, la implementación de un protocolo de enrutamiento podría seguir publicando la interfaz. Por ejemplo, el protocolo in.routed podría seguir publicando que hme0 está disponible para reenviar paquetes a sus equivalentes dentro de la intranet. Al configurar el indicador private de la interfaz, se evita la publicación de estos datos.

  19. Agregue manualmente una ruta predeterminada a través de hme0.

    La ruta predeterminada debe ser un enrutador con acceso directo a Internet.

    1. En el sistema enigma, agregue la ruta siguiente:


      # route add default 192.168.116.4

    2. En el sistema partym, agregue la ruta siguiente:


      # route add default 192.168.13.5

      Aunque la interfaz hme0 no forme parte de la intranet, hme0 necesita alcanzar su sistema equivalente a través de Internet. Para encontrar su equivalente, hme0 necesita información sobre el enrutamiento de Internet. El sistema VPN aparece como host, en lugar de aparecer como enrutador, para el resto de Internet. Por tanto, puede utilizar un enrutador predeterminado o ejecutar el protocolo de descubrimiento de enrutador para encontrar un sistema equivalente. Para más información, consulte las páginas del comando man route(1M) e in.routed(1M).

  20. Asegúrese de que la VPN se inicie tras un reinicio mediante la adición de una entrada al archivo /etc/hostname.ip.tun0 .


    system1-point system2-point tsrc system1-taddr tdst system2-taddr router up

    1. En el sistema enigma, agregue la entrada siguiente al archivo hostname.ip.tun0:


      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up

    2. En el sistema partym, agregue la entrada siguiente al archivo hostname.ip.tun0:


      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

  21. Configure los archivos de interfaz para transferir los parámetros correctos al daemon de enrutamiento.

    1. En el sistema enigma, modifique los archivos /etc/hostname. interfaz.


      # cat /etc/hostname.hme0
## enigma
10.16.16.6 private
      		 

      # cat /etc/hostname.hme1
## enigma
192.168.116.16 router

    2. En el sistema partym, modifique los archivos /etc/hostname. interfaz.


      # cat /etc/hostname.hme0
## partym
10.1.3.3 private
      		 

      # cat /etc/hostname.hme1
## partym
192.168.13.213 router

  22. Ejecute un protocolo de enrutamiento. 


    # routeadm -e ipv4-routing
# routeadm -u

    Podría ser que antes de ejecutar el protocolo de enrutamiento fuese necesario configurarlo. Para obtener más información, consulte Protocolos de enrutamiento en Oracle Solaris. Para conocer el procedimiento, consulte Configuración de un enrutador IPv4.

Ejemplo 20–10 Creación de túneles temporales durante la prueba

En este ejemplo, el administrador prueba la creación del túnel en un sistema Solaris 10 4/09. Más tarde, el administrador utilizará el procedimiento Cómo proteger una VPN con un túnel IPsec en modo túnel mediante IPv4 para que los túneles sean permanentes. Durante la prueba, el administrador realiza las siguientes series de pasos en los sistemas system1 y system2:

Ejemplo 20–11 Creación de un túnel en una versión anterior de un sistema Solaris mediante la línea de comandos

En la versión Solaris 10 7/07, la sintaxis del comando ifconfig se ha simplificado. En este ejemplo, el administrador prueba la creación del túnel en un sistema que está ejecutando una versión de Solaris anterior a Solaris 10 7/07. Mediante la sintaxis original del comando ifconfig, el administrador puede utilizar comandos idénticos en los dos sistemas comunicantes. Más tarde, el administrador utilizará Cómo proteger una VPN con un túnel IPsec en modo túnel mediante IPv4 para hacer que los túneles sean permanentes.

Durante la prueba, el administrador realiza los pasos siguientes en los sistemas system1 y system2:

Ejemplo 20–12 Requisito de directiva IPsec en todos los sistemas de una LAN

En este ejemplo, el administrador comenta la directiva bypass que se ha configurado en el Paso 4, con lo cual se refuerza la seguridad. Con esta configuración de directiva, cada sistema de la LAN debe activar IPsec para comunicarse con el enrutador.


# LAN traffic must implement IPsec.
# {laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate tunnel} ipsec {encr_algs aes encr_auth_algs sha1}
Ejemplo 20–13 Uso de IPsec para proteger el tráfico Telnet de un modo distinto del tráfico SMTP

En este ejemplo, la primera regla protege al tráfico telnet del puerto 23 con Blowfish y SHA–1. La segunda regla protege al tráfico SMTP del puerto 25 con AES y MD5.


{laddr 10.1.3.3 ulp tcp dport 23 dir both} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa unique}
{laddr 10.1.3.3 ulp tcp dport 25 dir both} 
 ipsec {encr_algs aes encr_auth_algs md5 sa unique}
Ejemplo 20–14 Uso de un túnel IPsec en modo túnel para proteger una subred de un modo distinto del resto del tráfico de red

La siguiente configuración de túnel protege todo el tráfico de la subred 10.1.3.0/24 a través del túnel:


{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

Las siguientes configuraciones de túnel protegen el tráfico de la subred 10.1.3.0/24 a distintas subredes a través del túnel. Las subredes que empiezan por 10.2.x.x atraviesan el túnel.


{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.1.0/24} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}
 

{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.2.0/24} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}
 

{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.3.0/24} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

ProcedureCómo proteger una VPN con un túnel IPsec en modo túnel mediante IPv6

Para configurar una VPN en una red IPv6, debe seguir los mismos pasos que para configurar una red IPv4. No obstante, la sintaxis de los comandos es ligeramente distinta. Para ver una descripción completa de los motivos para ejecutar comandos específicos, consulte los pasos correspondientes en Cómo proteger una VPN con un túnel IPsec en modo túnel mediante IPv4.

Nota –

Lleve a cabo los pasos de este procedimiento en ambos sistemas.

Este procedimiento utiliza los siguientes parámetros.

Parámetro 

Europa 

California 

Nombre del sistema 

 

enigma
 

partym

Interfaz de la intranet del sistema 

 

hme1
 

hme1

Interfaz de Internet del sistema 

 

hme0
 

hme0

Dirección de intranet del sistema 

 

6000:6666::aaaa:1116
 

6000:3333::eeee:1113

Dirección de Internet del sistema 

 

2001::aaaa:6666:6666
 

2001::eeee:3333:3333

Nombre del enrutador de Internet 

 

router-E
 

router-C

Dirección del enrutador de Internet 

 

2001::aaaa:0:4
 

2001::eeee:0:1

Nombre de túnel 

 

ip6.tun0
 

ip6.tun0

  1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

    Nota –

    El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

  2. Controle el flujo de paquetes antes de configurar IPsec.

    Para ver los efectos de estos comandos, consulte el Paso 2 de Cómo proteger una VPN con un túnel IPsec en modo túnel mediante IPv4.

    1. Asegúrese de que el reenvío de IP y el enrutamiento dinámico de IP estén desactivados.


      # routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
…
IPv6 forwarding     disabled          disabled
   IPv6 routing     disabled          disabled

      Si el reenvío de IP y el enrutamiento dinámico de IP están habilitados, puede inhabilitarlos escribiendo:


      # routeadm -d ipv6-forwarding -d ipv6-routing
# routeadm -u

    2. Active los hosts múltiples de destino estricto de IP. 


      # ndd -set /dev/ip ip6_strict_dst_multihoming 1
      Precaución – Precaución –

      El valor de ip6_strict_dst_multihoming vuelve al predeterminado cuando se inicia el sistema. Para hacer que el valor cambiado sea persistente, consulte Cómo evitar la falsificación de la IP .

    3. Desactive la mayoría de los servicios de red, y posiblemente todos.

      Nota –

      Si su sistema se instaló con el perfil SMF "limitado", puede omitir este paso. Los servicios de red se desactivan, a excepción de Solaris Secure Shell.

      La desactivación de los servicios de red evita que los paquetes IP dañen el sistema. Por ejemplo, podrían aprovecharse un daemon SNMP, una conexión telnet o una conexión rlogin.

      Elija una de las siguientes opciones:

      • Si ejecuta Solaris 10 11/06 o una versión posterior, ejecute el perfil SMF "limitado".


        # netservices limited

      • De lo contrario, desactive los servicios de red de forma individual.


        # svcadm disable network/ftp:default
# svcadm disable network/finger:default
# svcadm disable network/login:rlogin
# svcadm disable network/nfs/server:default
# svcadm disable network/rpc/rstat:default
# svcadm disable network/smtp:sendmail
# svcadm disable network/telnet:default 

    4. Compruebe que la mayoría de los servicios de red estén inhabilitados.

      Compruebe que los montajes de realimentación y el servicio ssh se estén ejecutando.


      # svcs | grep network
online         Aug_02   svc:/network/loopback:default
...
online         Aug_09   svc:/network/ssh:default

  3. Agregue un par de SA entre los dos sistemas.

    Elija una de las siguientes opciones:

  4. Agregue una directiva IPsec para la VPN.

    Edite el archivo /etc/inet/ipsecinit.conf para agregar la directiva IPsec para la VPN.

    1. En el sistema enigma, escriba la entrada siguiente en el archivo ipsecinit.conf:


      # IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic to and from this host can bypass IPsec.
{laddr 6000:6666::aaaa:1116 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip6.tun0 negotiate tunnel} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    2. En el sistema partym, escriba la entrada siguiente en el archivo ipsecinit.conf:


      # IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic to and from this host can bypass IPsec.
{laddr 6000:3333::eeee:1113 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip6.tun0 negotiate tunnel} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

  5. (Opcional) Compruebe la sintaxis del archivo de directiva IPsec.


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. Para configurar el túnel y protegerlo con IPsec, siga los pasos en función de la versión de Solaris:

    • A partir de la versión Solaris 10 4/09, siga los pasos del Paso 7 al Paso 13 y, a continuación, ejecute el protocolo de enrutamiento en Paso 22.

    • Si está ejecutando una versión anterior a Solaris 10 4/09, siga las indicaciones del Paso 14 al Paso 22.

  7. Configure el túnel, ip6.tun0, en el archivo /etc/hostname.ip6.tun0.

    1. En el sistema enigma, agregue la entrada siguiente al archivo hostname.ip6.tun0:


      6000:6666::aaaa:1116 6000:3333::eeee:1113 tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333 router up

    2. En el sistema partym, agregue la entrada siguiente al archivo hostname.ip6.tun0:


      6000:3333::eeee:1113  6000:6666::aaaa:1116 tsrc 2001::eeee:3333:3333 tdst 2001::aaaa:6666:6666 router up

  8. Proteja el túnel con la directiva IPsec que ha creado.


    # svcadm refresh svc:/network/ipsec/policy:default

  9. Para leer el contenido del archivo de configuración de túnel en el núcleo, reinicie los servicios de red. 


    # svcadm restart svc:/network/initial:default

  10. Active el reenvío de IP para la interfaz hme1.

    1. En el sistema enigma, agregue la entrada del enrutador al archivo /etc/hostname6.hme1.


      2001::aaaa:6666:6666 inet6 router

    2. En el sistema partym, agregue la entrada del enrutador al archivo /etc/hostname6.hme1.


      2001::eeee:3333:3333 inet6 router

  11. Asegúrese de que los protocolos de enrutamiento no publiquen la ruta predeterminada en la intranet.

    1. En el sistema enigma, agregue el indicador private al archivo /etc/hostname6.hme0.


      6000:6666::aaaa:1116 inet6 private

    2. En el sistema partym, agregue el indicador private al archivo /etc/hostname6.hme0.


      6000:3333::eeee:1113 inet6 private

  12. Agregue manualmente una ruta predeterminada a través de hme0.

    1. En el sistema enigma, agregue la ruta siguiente:


      # route add -inet6 default 2001::aaaa:0:4

    2. En el sistema partym, agregue la ruta siguiente:


      # route add -inet6 default 2001::eeee:0:1

  13. Para completar el procedimiento, vaya al Paso 22 para ejecutar un protocolo de enrutamiento.

  14. Configure un túnel seguro, ip6.tun0.

    Nota –

    Los siguientes pasos configuran un túnel en un sistema que esté ejecutando una versión anterior a Solaris 10 4/09.

    1. En el sistema enigma, escriba los comandos siguientes:


      # ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6 6000:6666::aaaa:1116 6000:3333::eeee:1113 \
tsrc 2001::aaaa:6666:6666   tdst 2001::eeee:3333:3333

    2. En el sistema partym, escriba los comandos siguientes:


      # ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6 6000:3333::eeee:1113 6000:6666::aaaa:1116 \
tsrc 2001::eeee:3333:3333   tdst 2001::aaaa:6666:6666

  15. Proteja el túnel con la directiva IPsec que ha creado.


    # ipsecconf

  16. Muestre el enrutador para el túnel.


    # ifconfig ip6.tun0 router up

  17. En cada sistema, active el reenvío de IP para la interfaz hme1. 


    # ifconfig hme1 router

  18. Asegúrese de que los protocolos de enrutamiento no publiquen la ruta predeterminada en la intranet.


    # ifconfig hme0 private

  19. Agregue manualmente una ruta predeterminada a través de hme0.

    La ruta predeterminada debe ser un enrutador con acceso directo a Internet.

    1. En el sistema enigma, agregue la ruta siguiente:


      # route add -inet6 default 2001::aaaa:0:4

    2. En el sistema partym, agregue la ruta siguiente:


      # route add -inet6 default 2001::eeee:0:1

  20. Asegúrese de que la VPN se inicie tras un reinicio, mediante la adición de una entrada al archivo /etc/hostname6.ip6.tun0.

    La entrada replica los parámetros que se hayan transferido al comando ifconfig en el Paso 14.

    1. En el sistema enigma, agregue la entrada siguiente al archivo hostname6.ip6.tun0:


      6000:6666::aaaa:1116 6000:3333::eeee:1113 \
tsrc 2001::aaaa:6666:6666  tdst 2001::eeee:3333:3333 router up

    2. En el sistema partym, agregue la entrada siguiente al archivo hostname6.ip6.tun0:


      6000:3333::eeee:1113 6000:6666::aaaa:1116 \
tsrc 2001::eeee:3333:3333   tdst 2001::aaaa:6666:6666  router up

  21. En cada sistema, configure los archivos de interfaz para transferir los parámetros correctos al daemon de enrutamiento.

    1. En el sistema enigma, modifique los archivos /etc/hostname. interfaz.


      # cat /etc/hostname6.hme0
## enigma
6000:6666::aaaa:1116 inet6 private
      		 

      #  cat /etc/hostname6.hme1
## enigma
2001::aaaa:6666:6666 inet6 router

    2. En el sistema partym, modifique los archivos /etc/hostname. interfaz.


      # cat /etc/hostname6.hme0
## partym
6000:3333::eeee:1113 inet6 private
      		 

      # cat /etc/hostname6.hme1
## partym
2001::eeee:3333:3333 inet6 router

  22. Ejecute un protocolo de enrutamiento. 


    # routeadm -e ipv6-routing
# routeadm -u

    Podría ser que antes de ejecutar el protocolo de enrutamiento fuese necesario configurarlo. Para obtener más información, consulte Protocolos de enrutamiento en Oracle Solaris. Para obtener un procedimiento, consulte Configuración de un enrutador IPv6.

ProcedureCómo proteger una VPN con un túnel IPsec en modo transporte mediante IPv4

En modo transporte, el encabezado exterior determina la directiva IPsec que protege el paquete IP interior.

Este procedimiento amplía el procedimiento de Cómo proteger el tráfico entre dos sistemas con IPsec. Además de conectar dos sistemas, está conectando dos intranets que se conectan a estos dos sistemas. Los sistemas de este procedimiento actúan como portales.

En este procedimiento se utiliza la configuración descrita en Descripción de la topología de red para la protección de una VPN por parte de las tareas de IPsec. Para ver una descripción completa de los motivos para ejecutar comandos específicos, consulte los pasos correspondientes en Cómo proteger una VPN con un túnel IPsec en modo túnel mediante IPv4.

Nota –

Lleve a cabo los pasos de este procedimiento en ambos sistemas.

  1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

    Nota –

    El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

  2. Controle el flujo de paquetes antes de configurar IPsec.

    1. Asegúrese de que el reenvío de IP y el enrutamiento dinámico de IP estén desactivados.


      # routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
IPv4 forwarding     disabled           disabled
   IPv4 routing     default (enabled)   enabled
…

      Si el reenvío de IP y el enrutamiento dinámico de IP están habilitados, puede inhabilitarlos escribiendo:


      # routeadm -d ipv4-routing -d ipv4-forwarding
# routeadm -u

    2. Active los hosts múltiples de destino estricto de IP. 


      # ndd -set /dev/ip ip_strict_dst_multihoming 1
      Precaución – Precaución –

      El valor de ip_strict_dst_multihoming vuelve al predeterminado cuando se inicia el sistema. Para hacer que el valor cambiado sea persistente, consulte Cómo evitar la falsificación de la IP .

    3. Desactive la mayoría de los servicios de red, y posiblemente todos.

      Nota –

      Si su sistema se instaló con el perfil SMF "limitado", puede omitir este paso. Los servicios de red se desactivan, a excepción de Solaris Secure Shell.

      La desactivación de los servicios de red evita que los paquetes IP dañen el sistema. Por ejemplo, podrían aprovecharse un daemon SNMP, una conexión telnet o una conexión rlogin.

      Elija una de las siguientes opciones:

      • Si ejecuta Solaris 10 11/06 o una versión posterior, ejecute el perfil SMF "limitado".


        # netservices limited

      • De lo contrario, desactive los servicios de red de forma individual.


        # svcadm disable network/ftp:default
# svcadm disable network/finger:default
# svcadm disable network/login:rlogin
# svcadm disable network/nfs/server:default
# svcadm disable network/rpc/rstat:default
# svcadm disable network/smtp:sendmail
# svcadm disable network/telnet:default 

    4. Compruebe que la mayoría de los servicios de red estén inhabilitados.

      Compruebe que los montajes de realimentación y el servicio ssh se estén ejecutando.


      # svcs | grep network
online         Aug_02   svc:/network/loopback:default
…
online         Aug_09   svc:/network/ssh:default

  3. Agregue un par de SA entre los dos sistemas.

    Elija una de las siguientes opciones:

  4. Agregue la directiva IPsec.

    Edite el archivo /etc/inet/ipsecinit.conf para agregar la directiva IPsec para la VPN. Para reforzar la directiva, consulte el Ejemplo 20–15.

    1. Por ejemplo, en el sistema enigma, escriba la entrada siguiente en el archivo ipsecinit.conf:


      # LAN traffic to and from this host can bypass IPsec.
{laddr 10.16.16.6 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    2. En el sistema partym, escriba la entrada siguiente en el archivo ipsecinit.conf:


      # LAN traffic to and from this host can bypass IPsec.
{laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

  5. (Opcional) Compruebe la sintaxis del archivo de directiva IPsec.


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. Para configurar el túnel y protegerlo con IPsec, siga los pasos en función de la versión de Solaris:

    • A partir de la versión Solaris 10 4/09, siga los pasos del Paso 7 al Paso 13 y, a continuación, ejecute el protocolo de enrutamiento en Paso 22.

    • Si está ejecutando una versión anterior a Solaris 10 4/09, siga las indicaciones del Paso 14 al Paso 22.

  7. Configure el túnel, ip.tun0, en el archivo /etc/hostname.ip.tun0.

    1. En el sistema enigma, agregue la entrada siguiente al archivo hostname.ip.tun0:


      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up

    2. En el sistema partym, agregue la entrada siguiente al archivo hostname.ip.tun0:


      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

  8. Proteja el túnel con la directiva IPsec que ha creado.


    # svcadm refresh svc:/network/ipsec/policy:default

  9. Para leer el contenido del archivo hostname.ip.tun0 en el núcleo, reinicie los servicios de red. 


    # svcadm restart svc:/network/initial:default

  10. Active el reenvío de IP para la interfaz hme1.

    1. En el sistema enigma, agregue la entrada del enrutador al archivo /etc/hostname.hme1. 


      192.168.116.16 router

    2. En el sistema partym, agregue la entrada del enrutador al archivo /etc/hostname.hme1. 


      192.168.13.213 router

  11. Asegúrese de que los protocolos de enrutamiento no publiquen la ruta predeterminada en la intranet.

    1. En el sistema enigma, agregue el indicador private al archivo /etc/hostname.hme1. 


      10.16.16.6 private

    2. En el sistema partym, agregue el indicador private al archivo /etc/hostname.hme1. 


      10.1.3.3 private

  12. Agregue manualmente una ruta predeterminada a través de hme0.

    1. En el sistema enigma, agregue la ruta siguiente:


      # route add default 192.168.116.4

    2. En el sistema partym, agregue la ruta siguiente:


      # route add default 192.168.13.5

  13. Para completar el procedimiento, vaya al Paso 22 para ejecutar un protocolo de enrutamiento.

  14. Configure el túnel, ip.tun0.

    Nota –

    Los siguientes pasos configuran un túnel en un sistema que ejecuta una versión anterior a Solaris 10 4/09.

    Utilice los comandos ifconfig para crear la interfaz de punto a punto:


    # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 system1-point system2-point \
tsrc system1-taddr tdst system2-taddr

    1. En el sistema enigma, escriba los comandos siguientes:


      # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.16.16.6 10.1.3.3 \
tsrc 192.168.116.16 tdst 192.168.13.213

    2. En el sistema partym, escriba los comandos siguientes:


      # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.1.3.3 10.16.16.6  \
tsrc 192.168.13.213 tdst 192.168.116.16

  15. Proteja el túnel con la directiva IPsec que ha creado.


    # ipsecconf

  16. Muestre el enrutador para el túnel.


    # ifconfig ip.tun0 router up

  17. Active el reenvío de IP para la interfaz hme1. 


    # ifconfig hme1 router

  18. Asegúrese de que los protocolos de enrutamiento no publiquen la ruta predeterminada en la intranet.


    # ifconfig hme0 private

  19. Agregue manualmente una ruta predeterminada a través de hme0.

    La ruta predeterminada debe ser un enrutador con acceso directo a Internet.


    # route add default router-on-hme0-subnet

    1. En el sistema enigma, agregue la ruta siguiente:


      # route add default 192.168.116.4

    2. En el sistema partym, agregue la ruta siguiente:


      # route add default 192.168.13.5

  20. Asegúrese de que la VPN se inicie tras un reinicio mediante la adición de una entrada al archivo /etc/hostname.ip.tun0 .


    system1-point system2-point tsrc system1-taddr \
tdst system2-taddr encr_algs aes encr_auth_algs sha1 router up

    1. En el sistema enigma, agregue la entrada siguiente al archivo hostname.ip.tun0:


      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 \
tdst 192.168.13.213 router up

    2. En el sistema partym, agregue la entrada siguiente al archivo hostname.ip.tun0:


      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 \
tdst 192.168.116.16 router up

  21. Configure los archivos de interfaz para transferir los parámetros correctos al daemon de enrutamiento.

    1. En el sistema enigma, modifique los archivos /etc/hostname. interfaz.


      # cat /etc/hostname.hme0
## enigma
10.16.16.6 private
      		 

      # cat /etc/hostname.hme1
## enigma
192.168.116.16 router

    2. En el sistema partym, modifique los archivos /etc/hostname. interfaz.


      # cat /etc/hostname.hme0
## partym
10.1.3.3 private
      		 

      # cat /etc/hostname.hme1
## partym
192.168.13.213 router

  22. Ejecute un protocolo de enrutamiento. 


    # routeadm -e ipv4-routing
# routeadm -u
Ejemplo 20–15 Requisito de directiva IPsec en todos los sistemas en modo transporte

En este ejemplo, el administrador comenta la directiva bypass configurada en el Paso 4, con lo cual se refuerza la seguridad. Con esta configuración de directiva, cada sistema de la LAN debe activar IPsec para comunicarse con el enrutador.


# LAN traffic must implement IPsec.
# {laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate transport} ipsec {encr_algs aes encr_auth_algs sha1}
Ejemplo 20–16 Uso de sintaxis no admitida para configurar un túnel IPsec en modo transporte

En este ejemplo, el administrador conecta un sistema Solaris 10 7/07 con un sistema con la versión Solaris 10. Por tanto, el administrador utiliza la sintaxis de Solaris 10 en el archivo de configuración e incluye los algoritmos IPsec en el comando ifconfig.

El administrador sigue el procedimiento Cómo proteger una VPN con un túnel IPsec en modo transporte mediante IPv4 con los siguientes cambios en la sintaxis.

ProcedureCómo proteger una VPN con un túnel IPsec en modo transporte mediante IPv6

Para configurar una VPN en una red IPv6, debe seguir los mismos pasos que para configurar una red IPv4. No obstante, la sintaxis de los comandos es ligeramente distinta. Para ver una descripción completa de los motivos para ejecutar comandos específicos, consulte los pasos correspondientes en Cómo proteger una VPN con un túnel IPsec en modo túnel mediante IPv4.

Nota –

Lleve a cabo los pasos de este procedimiento en ambos sistemas.

Este procedimiento utiliza los siguientes parámetros.

Parámetro 

Europa 

California 

Nombre del sistema 

 

enigma
 

partym

Interfaz de la intranet del sistema 

 

hme1
 

hme1

Interfaz de Internet del sistema 

 

hme0
 

hme0

Dirección de intranet del sistema 

 

6000:6666::aaaa:1116
 

6000:3333::eeee:1113

Dirección de Internet del sistema 

 

2001::aaaa:6666:6666
 

2001::eeee:3333:3333

Nombre del enrutador de Internet 

 

router-E
 

router-C

Dirección del enrutador de Internet 

 

2001::aaaa:0:4
 

2001::eeee:0:1

Nombre de túnel 

 

ip6.tun0
 

ip6.tun0

  1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

    Nota –

    El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

  2. Controle el flujo de paquetes antes de configurar IPsec.

    1. Asegúrese de que el reenvío de IP y el enrutamiento dinámico de IP estén desactivados.


      # routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
…
IPv6 forwarding     disabled          disabled
   IPv6 routing     disabled          disabled

      Si el reenvío de IP y el enrutamiento dinámico de IP están habilitados, puede inhabilitarlos escribiendo:


      # routeadm -d ipv6-forwarding -d ipv6-routing
# routeadm -u

    2. Active los hosts múltiples de destino estricto de IP. 


      # ndd -set /dev/ip ip6_strict_dst_multihoming 1
      Precaución – Precaución –

      El valor de ip6_strict_dst_multihoming vuelve al predeterminado cuando se inicia el sistema. Para hacer que el valor cambiado sea persistente, consulte Cómo evitar la falsificación de la IP .

    3. Compruebe que la mayoría de los servicios de red estén inhabilitados.

      Compruebe que los montajes de realimentación y el servicio ssh se estén ejecutando.


      # svcs | grep network
online         Aug_02   svc:/network/loopback:default
…
online         Aug_09   svc:/network/ssh:default

  3. Agregue un par de SA entre los dos sistemas.

    Elija una de las siguientes opciones:

  4. Agregue la directiva IPsec.

    Edite el archivo /etc/inet/ipsecinit.conf para agregar la directiva IPsec para la VPN.

    1. En el sistema enigma, escriba la entrada siguiente en el archivo ipsecinit.conf:


      # IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic can bypass IPsec.
{laddr 6000:6666::aaaa:1116 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip6.tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1}

    2. En el sistema partym, escriba la entrada siguiente en el archivo ipsecinit.conf:


      # IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic can bypass IPsec.
{laddr 6000:3333::eeee:1113 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip6.tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1}

  5. (Opcional) Compruebe la sintaxis del archivo de directiva IPsec.


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. Para configurar el túnel y protegerlo con IPsec, siga los pasos en función de la versión de Solaris:

    • A partir de la versión Solaris 10 4/09, siga los pasos del Paso 7 al Paso 13 y, a continuación, ejecute el protocolo de enrutamiento en Paso 22.

    • Si está ejecutando una versión anterior a Solaris 10 4/09, siga los pasos del Paso 14 al Paso 22.

  7. Configure el túnel, ip6.tun0, en el archivo /etc/hostname.ip6.tun0.

    1. En el sistema enigma, agregue la entrada siguiente al archivo hostname.ip6.tun0:


      6000:6666::aaaa:1116 6000:3333::eeee:1113 tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333 router up

    2. En el sistema partym, agregue la entrada siguiente al archivo hostname.ip6.tun0:


      6000:3333::eeee:1113  6000:6666::aaaa:1116 tsrc 2001::eeee:3333:3333 tdst 2001::aaaa:6666:6666 router up

  8. Proteja el túnel con la directiva IPsec que ha creado.


    # svcadm refresh svc:/network/ipsec/policy:default

  9. Para leer el contenido del archivo hostname.ip6.tun0 en el núcleo, reinicie los servicios de red.


    # svcadm restart svc:/network/initial:default

  10. Active el reenvío de IP para la interfaz hme1.

    1. En el sistema enigma, agregue la entrada del enrutador al archivo /etc/hostname6.hme1.


      2001::aaaa:6666:6666 inet6 router

    2. En el sistema partym, agregue la entrada del enrutador al archivo /etc/hostname6.hme1.


      2001::eeee:3333:3333 inet6 router

  11. Asegúrese de que los protocolos de enrutamiento no publiquen la ruta predeterminada en la intranet.

    1. En el sistema enigma, agregue el indicador private al archivo /etc/hostname6.hme0.


      6000:6666::aaaa:1116 inet6 private

    2. En el sistema partym, agregue el indicador private al archivo /etc/hostname6.hme0.


      6000:3333::eeee:1113 inet6 private

  12. Agregue manualmente una ruta predeterminada a través de hme0.

    1. En el sistema enigma, agregue la ruta siguiente:


      # route add -inet6 default 2001::aaaa:0:4

    2. En el sistema partym, agregue la ruta siguiente:


      # route add -inet6 default 2001::eeee:0:1

  13. Para completar el procedimiento, vaya al Paso 22 para ejecutar un protocolo de enrutamiento.

  14. Configure un túnel seguro, ip6.tun0.

    Nota –

    Los siguientes pasos configuran un túnel en un sistema que esté ejecutando una versión anterior a Solaris 10 4/09.

    1. En el sistema enigma, escriba los comandos siguientes:


      # ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6 6000:6666::aaaa:1116 6000:3333::eeee:1113 \
tsrc 2001::aaaa:6666:6666   tdst 2001::eeee:3333:3333

    2. En el sistema partym, escriba los comandos siguientes:


      # ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6  6000:3333::eeee:1113  6000:6666::aaaa:1116 \
tsrc 2001::eeee:3333:3333   tdst 2001::aaaa:6666:6666

  15. Proteja el túnel con la directiva IPsec que ha creado.


    # ipsecconf

  16. Muestre el enrutador para el túnel.


    # ifconfig ip6.tun0 router up

  17. Active el reenvío de IP para la interfaz hme1. 


    # ifconfig hme1 router

  18. Asegúrese de que los protocolos de enrutamiento no publiquen la ruta predeterminada en la intranet.


    # ifconfig hme0 private

  19. En cada sistema, agregue manualmente una ruta predeterminada mediante hme0.

    La ruta predeterminada debe ser un enrutador con acceso directo a Internet.

    1. En el sistema enigma, agregue la ruta siguiente:


      # route add -inet6 default 2001::aaaa:0:4

    2. En el sistema partym, agregue la ruta siguiente:


      # route add -inet6 default 2001::eeee:0:1

  20. En cada sistema, asegúrese de que la VPN se inicie tras un reinicio agregando una entrada al archivo /etc/hostname6.ip6.tun0 .

    La entrada replica los parámetros que se hayan transferido al comando ifconfig en el Paso 14.

    1. En el sistema enigma, agregue la entrada siguiente al archivo hostname6.ip6.tun0:


      6000:6666::aaaa:1116  6000:3333::eeee:1113 \
tsrc 2001::aaaa:6666:6666   tdst 2001::eeee:3333:3333  router up

    2. En el sistema partym, agregue la entrada siguiente al archivo hostname6.ip6.tun0:


      6000:3333::eeee:1113  6000:6666::aaaa:1116 \
tsrc 2001::eeee:3333:3333   tdst 2001::aaaa:6666:6666  router up

  21. Configure los archivos de interfaz para transferir los parámetros correctos al daemon de enrutamiento.

    1. En el sistema enigma, modifique los archivos /etc/hostname. interfaz.


      # cat /etc/hostname6.hme0
## enigma
6000:6666::aaaa:1116 inet6 private
      		 

      #  cat /etc/hostname6.hme1
## enigma
2001::aaaa:6666:6666 inet6 router

    2. En el sistema partym, modifique los archivos /etc/hostname. interfaz.


      # cat /etc/hostname6.hme0
## partym
6000:3333::eeee:1113 inet6 private
      		 

      # cat /etc/hostname6.hme1
## 
partym2001::eeee:3333:3333 inet6 router

  22. Ejecute un protocolo de enrutamiento.


    # routeadm -e ipv6-routing
# routeadm -u
Ejemplo 20–17 Uso de sintaxis descartada para configurar IPsec en modo de transporte mediante IPv6

En este ejemplo, el administrador conecta un sistema Solaris 10 7/07 con un sistema con la versión Solaris 10. Por tanto, el administrador utiliza la sintaxis de Solaris 10 en el archivo de configuración e incluye los algoritmos IPsec en el comando ifconfig.

El administrador sigue el procedimiento Cómo proteger una VPN con un túnel IPsec en modo transporte mediante IPv6 con los siguientes cambios en la sintaxis.

ProcedureCómo evitar la falsificación de la IP

Para evitar que el sistema reenvíe paquetes a otra interfaz sin intentar descifrarlos, el sistema debe comprobar que no haya falsificación de IP. Un método de prevención es definir el parámetro de inicio múltiple de destino estricto de IP mediante el uso del comando ndd. Cuando este parámetro se define en un manifiesto SMF, el parámetro se establece cuando el sistema se reinicia.

Nota –

Lleve a cabo los pasos de este procedimiento en ambos sistemas.

  1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

  2. Cree el manifiesto SMF específico para el sitio con el fin de comprobar que no haya falsificación de IP.

    Use el siguiente ejemplo de secuencia de comandos, /var/svc/manifest/site/spoof_check.xml . 

    <?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">

<service_bundle type='manifest' name='Custom:ip_spoof_checking'>

<!--    This is a custom smf(5) manifest for this system. Place this
        file in /var/svc/manifest/site, the directory for local
        system customizations. The exec method uses an unstable
        interface to provide a degree of protection against IP
        spoofing attacks when this system is acting as a router.

        IP spoof protection can also be achieved by using ipfilter(5).
        If ipfilter is configured, this service can be disabled.

        Note: Unstable interfaces might be removed in later
        releases.  See attributes(5).
-->

<service
        name='site/ip_spoofcheck'
        type='service'
        version='1'>

        <create_default_instance enabled='false' />
        <single_instance />

        <!--    Don't enable spoof protection until the
                network is up.
        -->
        <dependency
                name='basic_network'
                grouping='require_all'
                restart_on='none'
                type='service'>
        <service_fmri value='svc:/milestone/network' />
        </dependency>

        <exec_method
                type='method'
                name='start'
                exec='/usr/sbin/ndd -set /dev/ip ip_strict_dst_multihoming 1'
<!--    
     For an IPv6 network, use the IPv6 version of this command, as in:
                exec='/usr/sbin/ndd -set /dev/ip ip6_strict_dst_multihoming 1
-->
                timeout_seconds='60'
        />

        <exec_method
                type='method'
                name='stop'
                exec=':true'
                timeout_seconds='3'
        />

        <property_group name='startd' type='framework'>
                <propval
                        name='duration'
                        type='astring'
                        value='transient'
                />
        </property_group>

        <stability value='Unstable' />

</service>
</service_bundle>

  3. Importe este manifiesto al depósito SMF. 


    # svccfg import /var/svc/manifest/site/spoof_check.xml

  4. Habilite el servicio ip_spoofcheck.

    Utilice el nombre que se ha definido en el manifiesto, /site/ip_spoofcheck. 


    # svcadm enable /site/ip_spoofcheck

  5. Compruebe que el servicio ip_spoofcheck esté en línea. 


    # svcs /site/ip_spoofcheck

Capítulo 21 Arquitectura de seguridad IP (referencia)

Este capítulo contiene la siguiente información de referencia:

Para obtener instrucciones sobre cómo implementar IPsec en la red, consulte el Capítulo 20Configuración de IPsec (tareas). Para ver una descripción general de IPsec, consulte el Capítulo 19Arquitectura de seguridad IP (descripción general).

Utilidad de gestión de servicios de IPsec

La utilidad de gestión de servicios (SMF) proporciona los siguientes servicios para IPsec:

Para obtener más información sobre SMF, consulte el Capítulo 18, Managing Services (Overview) de System Administration Guide: Basic Administration. Consulte también las páginas de comando man smf(5),svcadm(1M) y svccfg(1M).

Comando ipsecconf

El comando ipsecconf permite configurar la directiva IPsec para un host. Al ejecutar el comando para configurar la directiva, el sistema crea las entradas de la directiva IPsec en el núcleo. El sistema utiliza estas entradas para comprobar la directiva en todos los datagramas IP entrantes y salientes. Los datagramas reenviados no están sujetos a las comprobaciones de directivas que se agregan utilizando este comando. El comando ipsecconf también configura la base de datos de directivas de seguridad (SPD).

Debe convertirse en superusuario o asumir un rol equivalente para invocar el comando ipsecconf. El comando acepta entradas que protegen el tráfico en ambas direcciones. El comando también acepta entradas que protegen el tráfico sólo en una dirección.

Las entradas de directiva con un formato de dirección local y dirección remota pueden proteger el tráfico en ambas direcciones con una sola entrada de directiva. Por ejemplo, las entradas que contienen los patrones laddr host1 y raddr host2 protegen el tráfico en ambas direcciones, si no se especifica ninguna dirección para el host con nombre. De este modo, sólo necesita una entrada de directiva para cada host.

Las entradas de directiva con un formato de dirección de origen a dirección de destino sólo protegen el tráfico en una dirección. Por ejemplo, una entrada de directiva del patrón saddr host1 daddr host2 protege el tráfico entrante o el saliente, no el tráfico en ambas direcciones. Por tanto, para proteger el tráfico en ambas direcciones, es necesario transferir al comando ipsecconf otra entrada, como en saddr host2 daddr host1.

Para asegurarse de que la directiva IPsec esté activa cuando se inicie el equipo, puede crear un archivo de directiva IPsec, /etc/inet/ipsecinit.conf. Este archivo se lee cuando se inician los servicios de red. Para obtener instrucciones sobre cómo crear un archivo de directiva IPsec, consulte Protección del tráfico con IPsec (mapa de tareas).

A partir de la versión &s10u7, con la opción -c , el comando ipsecconf comprueba la sintaxis del archivo de directiva IPsec que proporciona como argumento.

Las entradas de directivas agregadas por el comando ipsecconf no persisten tras un reinicio del sistema. Para asegurarse de que la directiva IPsec está activa cuando el sistema se inicia, agregue las entradas de directivas al archivo /etc/inet/ipsecinit.conf. En la versión actual, actualice o habilite el servicio directiva. En una versión anterior a Solaris 10 4/09 reinicie o utilice el comando ipsecconf. Si desea conocer ejemplos, consulte Protección del tráfico con IPsec (mapa de tareas).

Archivo ipsecinit.conf

Para invocar las directivas de seguridad IPsec al iniciar Sistema operativo Solaris (sistema operativo Solaris), se crea un archivo de configuración para iniciar IPsec con las entradas de directiva IPsec específicas. El nombre predeterminado para este archivo es /etc/inet/ipsecinit.conf. Consulte la página del comando man ipsecconf(1M) para obtener más información acerca de las entradas de directiva y su formato. Una vez configuradas las directivas, puede utilizar el comando ipsecconf para ver o modificar la configuración existente. A partir de Solaris 10 4/09, debe actualizar el servicio polícy para modificar la configuración existente.

Archivo ipsecinit.conf de ejemplo

El software Solaris incluye un archivo de directiva IPsec de ejemplo, ipsecinit.sample. Puede utilizar dicho archivo como plantilla para crear su propio archivo ipsecinit.conf. El archivo ipsecinit.sample contiene los ejemplos siguientes:


#
# For example,
#
#	 {rport 23} ipsec {encr_algs des encr_auth_algs md5}
#
# will protect the telnet traffic originating from the host with ESP using
# DES and MD5. Also:
#
#	 {raddr 10.5.5.0/24} ipsec {auth_algs any}
#
# will protect traffic to or from the 10.5.5.0 subnet with AH 
# using any available algorithm.
#
#
# To do basic filtering, a drop rule may be used. For example:
#
#	 {lport 23 dir in} drop {}
#	 {lport 23 dir out} drop {}
# will disallow any remote system from telnetting in.
#
# If you are using IPv6, it may be useful to bypass neighbor discovery
# to allow in.iked to work properly with on-link neighbors. To do that,
# add the following lines:
#
#        {ulp ipv6-icmp type 133-137 dir both } pass { }
#
# This will allow neighbor discovery to work normally.

Consideraciones de seguridad para ipsecinit.conf e ipsecconf

Tenga especial precaución al transmitir una copia del archivo ipsecinit.conf por una red. Un adversario puede leer un archivo montado en red mientras se lee el archivo. Si, por ejemplo, se accede al archivo /etc/inet/ipsecinit.conf o se copia desde un sistema de archivos montado en NFS, un adversario puede cambiar la directiva que contiene el archivo.

Asegúrese de configurar las directivas IPsec antes de iniciar cualquier comunicación, ya que las conexiones existentes podrían verse afectadas por la adición de nuevas entradas de directiva. Asimismo, no cambie las directivas durante una comunicación.

Específicamente, la directiva IPsec no puede cambiarse para los sockets SCTP, TCP o UDP en los que se ha emitido una llamada de función connect() o accept. () Un socket cuya directiva no se puede modificar se denomina socket bloqueado. Las nuevas entradas de directiva no protegen los sockets que ya están bloqueados. Para más información, consulte las páginas del comando man connect(3SOCKET) y accept(3SOCKET).

Proteja su sistema de nombres. Si se cumplen las dos condiciones siguientes, los nombres de host dejarán de ser de confianza:

Los fallos de seguridad a menudo se deben a la mala aplicación de las herramientas, no a las herramientas en sí. Utilice el comando ipsecconf con precaución. Utilice una consola u otro TTY conectado físicamente para obtener el funcionamiento mas seguro.

Comando ipsecalgs

La estructura criptográfica de Solaris proporciona autenticación y algoritmos de cifrado para IPsec. El comando ipsecalgs puede enumerar los algoritmos que cada protocolo de IPsec admite. La configuración ipsecalgs se almacena en el archivo /etc/inet/ipsecalgs. Normalmente, este archivo no necesita modificarse. Sin embargo, si el archivo debe modificarse, utilice el comando ipsecalgs. El archivo nunca debe editarse directamente. En la versión actual, los algoritmos admitidos se sincronizan con el núcleo en el inicio del sistema mediante el servicio svc:/network/ipsec/ipsecalgs:default.

ISAKMP dominio de interpretación, que se trata en la norma RFC 1407, describe los algoritmos y protocolos IPsec válidos. De manera general, el dominio de interpretación define los formatos de los datos, los tipos de intercambio de tráfico de red y las convenciones de denominación de información relacionada con la seguridad. Ejemplos de información relacionada con la seguridad son los algoritmos y modos criptográficos, y las directrices de seguridad.

En concreto, el DOI ISAKMP define las convenciones de denominación y numeración para los algoritmos IPsec válidos y sus protocolos. PROTO_IPSEC_AH y PROTO_IPSEC_ESP. Cada algoritmo se asocia exactamente con un protocolo. Estas definiciones DOI ISAKMP se encuentran en el archivo /etc/inet/ipsecalgs. Los números de protocolo y algoritmos los define la Autoridad de números asignados de Internet (IANA). El comando ipsecalgs permite ampliar la lista de algoritmos para IPsec.

Para obtener más información acerca de los algoritmos, consulte la página del comando man ipsecalgs(1M) Para mas información sobre la estructura criptográfica de Solaris, consulte el Capítulo 13, Oracle Solaris Cryptographic Framework (Overview) de System Administration Guide: Security Services.

Base de datos de asociaciones de seguridad para IPsec

La información sobre el material de claves para los servicios de seguridad IPsec se guarda en una base de datos de asociaciones de seguridad (SADB). Las asociaciones de seguridad (SA) protegen los paquetes entrantes y salientes. Las SADB se controlan mediante un proceso de usuario, o posiblemente varios procesos a la vez, que envían mensajes a través de un tipo de socket especial. Este modo de controlar las SADB es análogo al método que se describe en la página del comando man route(7P) Sólo el superusuario o un usuario que haya asumido un rol equivalente pueden acceder a la base de datos.

El daemon in.iked y el comando ipseckey utilizan la interfaz de socket PF_KEY para mantener las SADB. Para más información sobre cómo administrar las solicitudes y mensajes de SADB, consulte la página del comando man pf_key(7P).

Utilidades para la generación de claves en IPsec

El protocolo IKE permite administrar automáticamente las claves para las direcciones IPv4 e IPv6. Consulte el Capítulo 23Configuración de IKE (tareas) para obtener instrucciones sobre cómo configurar IKE. La utilidad de claves manuales es el comando ipseckey, que se describe en la página del comando man ipseckey(1M).

Puede usar el comando ipseckey para rellenar manualmente la base de datos de asociaciones de seguridad (SADB). Normalmente, la generación manual de SA se utiliza cuando IKE no está disponible por algún motivo. Sin embargo, si los valores SPI son exclusivos, la generación manual de SA e IKE se pueden utilizar al mismo tiempo.

El comando ipseckey puede utilizarse para ver todas las SA conocidas por el sistema, independientemente de si las claves se han agregado manualmente o mediante IKE. A partir de la versión Solaris 10 4/09, con la opción -c, el comando ipseckey comprueba la sintaxis del archivo de claves que proporciona como argumento.

Las IPsec SA que añade el comando ipseckey no persisten tras el reinicio del sistema. En la versión actual, para habilitar manualmente las SA agregadas en el inicio del sistema, agregue entradas al archivo /etc/inet/secret/ipseckeys y, a continuación, habilite el servicio svc:/network/ipsec/manual-key:default. Si desea conocer el procedimiento, consulte Cómo crear manualmente asociaciones de seguridad IPsec.

Aunque el comando ipseckey tiene un número limitado de opciones generales, admite un lenguaje de comandos amplio. Puede especificar que las solicitudes se envíen mediante una interfaz de programación específica para las claves manuales. Para obtener información adicional, consulte la página del comando man pf_key(7P).

Consideraciones de seguridad para ipseckey

El comando ipseckey permite al superusuario o a una función con el perfil de seguridad de red o de derechos de administración de redes IPsec especificar información criptográfica confidencial de claves. Si un adversario obtiene acceso a esta información, puede poner en peligro la seguridad del tráfico IPsec.

Cuando administre material de claves y utilice el comando ipseckey, debe tener en cuenta los aspectos siguientes:

Los fallos de seguridad a menudo se deben a la mala aplicación de las herramientas, no a las herramientas en sí. Utilice el comando ipseckey con precaución. Utilice una consola u otro TTY conectado físicamente para obtener el funcionamiento mas seguro.

Extensiones IPsec para otras utilidades

El comando ifconfig tiene opciones para administrar la directiva IPsec en una interfaz de túnel. El comando snoop puede analizar los encabezados AH y ESP.

Comando ifconfig e IPsec

En Solaris 10, Solaris 10 7/05, Solaris 10 1/06 y Solaris 10 11/06: Para admitir IPsec, con el comando ifconfig hay disponibles las siguientes opciones de seguridad. Estas opciones de seguridad se administran mediante el comando ipsecconf de Solaris 10 7/07.

Debe especificar todas las opciones de seguridad de IPsec para un túnel de una invocación. Por ejemplo, si utiliza solamente ESP para proteger el tráfico, debe configurar el túnel (ip.tun0) una vez con ambas opciones de seguridad, como en el ejemplo siguiente:


# ifconfig ip.tun0 encr_algs aes encr_auth_algs md5

De un modo similar, una entrada de ipsecinit.conf configuraría el túnel una vez con ambas opciones de seguridad, como en el caso siguiente:


# WAN traffic uses ESP with AES and MD5.
   {} ipsec {encr_algs aes encr_auth_algs md5}

Opción de seguridad auth_algs

Esta opción habilita AH IPsec para un túnel con un algoritmo de autenticación especificado. La opción auth_algs tiene el formato siguiente:


auth_algs authentication-algorithm

Para el algoritmo, puede especificar un número o un nombre de algoritmo, incluido el parámetro any, para no expresar ninguna preferencia de algoritmo específica. Para desactivar la seguridad del túnel, especifique la opción siguiente:


auth_algs none

Para ver una lista de los algoritmos de autenticación disponibles, ejecute el comando ipsecalgs.

Nota –

La opción auth_algs no puede funcionar con NAT-Traversal. Para más información, consulte Paso a través de IPsec y NAT.

Opción de seguridad encr_auth_algs

Esta opción habilita ESP IPsec para un túnel con un algoritmo de autenticación especificado. La opción encr_auth_algs tiene el formato siguiente:


encr_auth_algs authentication-algorithm

Para el algoritmo, puede especificar un número o un nombre de algoritmo, incluido el parámetro any, para no expresar ninguna preferencia de algoritmo específica. Si especifica un algoritmo de cifrado ESP pero no especifica el algoritmo de autenticación, el valor predeterminado del algoritmo de autenticación ESP es el parámetro any.

Para ver una lista de los algoritmos de autenticación disponibles, ejecute el comando ipsecalgs.

Opción de seguridad encr_algs

Esta opción habilita ESP IPsec para un túnel con un algoritmo de cifrado especificado. La opción encr_algs tiene el formato siguiente:


encr_algs encryption-algorithm

Para el algoritmo, puede especificar un número o un nombre de algoritmo. Para desactivar la seguridad del túnel, especifique la opción siguiente:


encr_algs none

Si especifica un algoritmo de autenticación ESP pero no un algoritmo de cifrado, el valor de cifrado predeterminado de ESP será el parámetro null.

Para ver una lista de los algoritmos de cifrado disponibles, ejecute el comando ipsecalgs.

Comando snoop e IPsec

El comando snoop puede analizar encabezados AH y ESP. Dado que ESP cifra sus datos, el comando snoop no puede ver los encabezados cifrados protegidos por ESP. AH no cifra los datos. En consecuencia, el tráfico que protege AH se puede examinar con el comando snoop. La opción -V para el comando muestra cuándo se está utilizando AH en un paquete. Para obtener más información, consulte la página del comando man snoop(1M).

Para ver un ejemplo de resultado snoop detallado en un paquete protegido, consulte Cómo verificar que los paquetes estén protegidos con IPsec.

Capítulo 22 Intercambio de claves de Internet (descripción general)

El Protocolo de intercambio de claves de Internet (Internet Key Exchange, IKE) automatiza la gestión de claves de IPsec. Este capítulo contiene la información siguiente sobre IKE:

Para obtener instrucciones sobre cómo implementar IKE, consulte el Capítulo 23Configuración de IKE (tareas). Para obtener información de referencia, consulte el Capítulo 24Intercambio de claves de Internet (referencia). Para obtener información sobre IPsec, consulte el Capítulo 19Arquitectura de seguridad IP (descripción general).

Novedades de IKE

Solaris 10 4/09: A partir de esta versión, la utilidad de gestión de servicios (SMF) administra IKE como servicio. Por defecto, el servicio red/svc:/ipsec/ike:predeterminado está deshabilitado. También en esta versión, el perfil de derechos Network IPsec Management se proporciona para administrar IPsec e IKE.

Solaris 10 7/07: A partir de esta versión, IKE puede utilizar el algoritmo AES y configurarse en la zona global para utilizar en zonas no globales.

Administración de claves con IKE

La administración del material de claves de las asociaciones de seguridad de IPsec se denomina administración de claves. La administración de claves automática requiere un canal de comunicación seguro para la creación, autenticación e intercambio de claves. Sistema operativo Solaris utiliza el intercambio de claves de Internet (IKE) para automatizar la administración de claves. IKE se escala fácilmente para proporcionar un canal seguro para un volumen de tráfico importante. Las asociaciones de seguridad de IPsec en paquetes IPv4 e IPv6 pueden aprovechar IKE.

Cuando se utiliza IKE en un sistema con una placa de Sun Crypto Accelerator 1000, Sun Crypto Accelerator 4000 o Sun Crypto Accelerator 6000, las operaciones de claves públicas se pueden descargar en el acelerador. Los recursos del sistema operativo no se utilizan para las operaciones de claves públicas. Cuando se utiliza IKE en un sistema con una placa de Sun Crypto Accelerator 6000 o Sun Crypto Accelerator 4000, los certificados, claves públicas y claves privadas se pueden almacenar en la placa. El almacenamiento de claves fuera del sistema proporciona una capa de protección adicional.

Negociación de claves IKE

El daemon IKE, in.iked, negocia y autentica el material de claves para las asociaciones de seguridad de forma protegida. El daemon utiliza números generadores aleatorios a partir de funciones internas que proporciona Sistema operativo Solaris. IKE proporciona confidencialidad directa perfecta (PFS). En PFS, las claves que protegen la transmisión de datos no se utilizan para derivar claves adicionales. Asimismo, los números generadores que se utilizan para crear claves de transmisión de datos no se vuelven a utilizar. Consulte la página del comando man in.iked(1M).

Cuando el daemon IKE descubre una clave de cifrado pública del sistema remoto, el sistema puede utilizar dicha clave. El sistema cifra los mensajes utilizando la clave pública del sistema remoto. Sólo el sistema remoto puede leer los mensajes. El daemon IKE lleva a cabo su trabajo en dos fases. Las fases se denominan intercambios.

Terminología de claves IKE

La tabla siguiente enumera los términos que se utilizan en el ámbito de la negociación de claves, incluye sus acrónimos habituales y aporta una definición e información del uso de cada término.

Tabla 22–1 Términos de negociación de claves, acrónimos y usos

Término de negociación de claves 

Acrónimo 

Definición y uso 

Intercambio de claves 

 

El proceso de generación de claves para los algoritmos criptográficos asimétricos. Los dos métodos principales son los protocolos RSA y el protocolo Diffie-Hellman. 

Protocolo Diffie-Hellman 

DH 

Protocolo de intercambio de claves que implica la generación y la autenticación de claves. A menudo se denomina intercambio de claves autenticadas.

Protocolo RSA 

RSA 

Protocolo de intercambio de claves que implica la generación y el transporte de claves. El protocolo recibe el nombre de sus tres creadores, Rivest, Shamir y Adleman. 

Confidencialidad directa perfecta

PFS 

Sólo se aplica en el intercambio de claves autenticadas. PFS garantiza que el material secreto a largo plazo para las claves no ponga en peligro la confidencialidad de las claves intercambiadas de comunicaciones anteriores.  

En PFS, la clave que se emplea para proteger la transmisión de datos no se aplica en la derivación de claves adicionales. La fuente de la clave que se usa para proteger la transmisión de datos tampoco se emplea en la derivación de claves adicionales. 

Método Oakley 

 

Método para establecer claves para la fase 2 de un modo seguro. Este protocolo es análogo al método Diffie-Hellman de intercambio de claves. De un modo similar a Diffie-Hellman, el intercambio de claves de grupo Oakley implica la generación de claves y la autenticación de claves. El método Oakley se utiliza para negociar PFS. 

Intercambio de IKE de fase 1

El intercambio de fase 1 se conoce como modo principal. En el intercambio de fase 1, IKE utiliza métodos de cifrado de claves públicas para autenticarse con entidades IKE equivalentes. El resultado es una asociación de seguridad de Internet y una asociación de seguridad del protocolo de administración de claves (ISAKMP). Una asociación de seguridad ISAKMP es un canal seguro para que IKE negocie el material de claves para los datagramas IP. A diferencia de las asociaciones de seguridad de IPsec, las asociaciones de seguridad de ISAKMP son bidireccionales, de modo que sólo se necesita una asociación de seguridad.

El modo en que IKE negocia el material de claves en el intercambio de la fase 1 es configurable. IKE lee la información de configuración del archivo /etc/inet/ike/config. La información de configuración incluye:

Los dos métodos de autenticación son las claves previamente compartidas y los certificados de claves públicas. Los certificados de claves públicas pueden ser autofirmados. Los certificados también los puede emitir una autoridad de certificación desde una organización de infraestructuras de clave pública (PKI). Las organizaciones incluyen beTrusted, Entrust, GeoTrust, RSA Security y Verisign.

Intercambio de IKE de fase 2

El intercambio de fase 2 se conoce como modo rápido (Quick). En el intercambio de fase 2, IKE crea y administra las asociaciones de seguridad de IPsec entre los sistemas que ejecutan el daemon de IKE. IKE utiliza el canal seguro creado en el intercambio de fase 1 para proteger la transmisión del material de claves. El daemon IKE crea las claves a partir de un generador de números aleatorio utilizando el dispositivo /dev/random. La velocidad a la que el daemon actualiza las claves se puede configurar. El material de claves está disponible para los algoritmos especificados en el archivo de configuración para la directiva IPsec, ipsecinit.conf.

Opciones de configuración de IKE

El archivo de configuración /etc/inet/ike/config contiene entradas de directiva IKE. Para que dos daemons IKE se autentiquen entre sí, las entradas deben ser válidas. Además, el material de claves debe estar disponible. Las entradas del archivo de configuración determinan el método para utilizar el material de claves para autenticar el intercambio de fase 1. Las opciones son las claves previamente compartidas o los certificados de claves públicas.

La entrada auth_method preshared indica que se utilizan claves previamente compartidas. Los valores de auth_method que no sean preshared indican que se deben utilizar certificados de claves públicas. Los certificados de claves públicas pueden ser autofirmados o instalarse desde una organización de PKI. Para más información, consulte la página del comando man ike.config(4).

IKE con claves previamente compartidas

Las claves previamente compartidas las crea un administrador de un sistema. A continuación, se comparten las claves fuera de la banda con administradores de sistemas remotos. Debe procurar crear claves aleatorias largas y proteger el archivo y la transmisión fuera de banda. Las claves se colocan en el archivo /etc/inet/secret/ike.preshared de cada sistema. El archivo ike.preshared para IKE hace las funciones del archivo ipseckeys para IPsec. Cualquier peligro para las claves del archivo ike.preshared pondrá en peligro todas las claves que se deriven de las claves del archivo.

La clave precompartida de un sistema debe ser idéntica a la clave de su sistema remoto. Las claves están vinculadas a una dirección IP específica. Las claves son más seguras cuando un administrador controla los sistemas que se comunican. Para obtener más información, consulte la página del comando man ike.preshared(4).

IKE con certificados de claves públicas

Los certificados de claves públicas acaban con la necesidad de que los sistemas que se comunican compartan el material de claves secreto fuera de banda. Las claves publicas utilizan el protocolo de Diffie-Hellman (DH) para autenticar y negociar claves. Existen dos tipos de certificados de claves públicas. Los certificados pueden ser autofirmados o certificados por una autoridad de certificación.

Los certificados de claves públicas autofirmadas los crea el administrador. El comando ikecert certlocal -ks crea la parte privada del par de claves pública-privada para el sistema. A continuación se obtiene el resultado del certificado autofirmado en formato X.509 del sistema remoto. El certificado del sistema remoto se incluye en el comando ikecert certdb para la parte pública del par de claves. Los certificados autofirmados se encuentran en el directorio /etc/inet/ike/publickeys de los sistemas que se comunican. Cuando se utiliza la opción -T, los certificados residen en el hardware conectado.

Los certificados autofirmados son un punto intermedio entre las claves previamente compartidas y las autoridades de certificación. A diferencia de las claves previamente compartidas, un certificado autofirmado se puede utilizar en un equipo portátil o en un sistema cuya numeración podría cambiar. Para autofirmar un certificado para un sistema sin un número fijo, utilice un nombre alternativo DNS (www.example.org ) o email (root@domain.org).

Las claves públicas se pueden entregar mediante PKI o una organización de autoridad de certificación. Las claves públicas y sus autoridades de certificación pertinentes se instalan en el directorio /etc/inet/ike/publickeys. Cuando se utiliza la opción -T, los certificados residen en el hardware conectado. Los proveedores también emiten listas de revocación de certificados (CRL). Junto con la instalación de las claves y las autoridades de certificación, debe instalar la CRL en el directorio /etc/inet/ike/crls.

Las autoridades de certificación tienen la ventaja de estar certificadas por una organización exterior, en lugar del administrador del sitio. En cierto modo, las autoridades de certificación son certificados autorizados. Al igual que ocurre con los certificados autofirmados, las autoridades de certificación se pueden utilizar en un equipo portátil o en un sistema cuya numeración podría cambiar. A diferencia de los certificados autofirmados, las autoridades de certificación se pueden escalar muy fácilmente para proteger una gran cantidad de sistemas que se comunican.

IKE y aceleración de hardware

Los algoritmos IKE requieren cálculos complejos, especialmente en el intercambio de fase 1. Los sistemas que controlan una gran cantidad de intercambios pueden utilizar una placa de Sun Crypto Accelerator 1000 para administrar las operaciones de claves públicas. Las placas de Sun Crypto Accelerator 4000 y Crypto Accelerator 6000 de Sun también se pueden utilizar para manejar cálculos de Fase 1 costosos.

Para obtener información sobre cómo configurar IKE para descargar sus cálculos en la placa del acelerador, consulte Cómo configurar IKE para buscar la placa de Sun Crypto Accelerator 1000 . Para obtener información sobre cómo almacenar claves, consulte Cómo configurar IKE para buscar la placa de Sun Crypto Accelerator 4000 y la página del comando man cryptoadm(1M).

IKE y almacenamiento de hardware

Los certificados de claves públicas, las claves privadas y las claves públicas se pueden almacenar en una placa Sun Crypto Accelerator 4000 o Crypto Accelerator 6000 de Sun. Para el cifrado RSA, la placa Sun Crypto Accelerator 4000 admite claves de hasta 2.048 bits. Para el cifrado DSA, la placa admite claves de hasta 1.024 bits. La placa Crypto Accelerator 6000 de Sun es compatible con los algoritmos SHA-512 y ECC.

Para obtener información sobre cómo configurar IKE para acceder a la placa, consulte Cómo configurar IKE para buscar la placa de Sun Crypto Accelerator 1000 . Para obtener información sobre cómo agregar certificados y claves públicas a la placa, consulte Cómo generar y almacenar certificados de clave pública en el hardware.

Archivos y utilidades IKE

La siguiente tabla resume los archivos de configuración para la directiva IKE, las ubicaciones de almacenamiento para las claves IKE y los distintos comandos y servicios que implementan IKE. Para obtener más información sobre los servicios, consulte el Capítulo 18, Managing Services (Overview) de System Administration Guide: Basic Administration.

Tabla 22–2 Archivos de configuración de IKE, ubicaciones de almacenamiento de claves, comandos y servicios

Archivo, ubicación, comando o servicio  

Descripción 

Para obtener más información 

svc: /network/ipsec/ike

En la versión actual, el servicio SMF que gestiona IKE.

smf(5)

Daemon /usr/lib/inet/in.iked

Daemon de intercambio de claves de Internet (IKE). Activa la administración de claves automática. En la versión actual, el servicio ike habilita este daemon. En las versiones anteriores, se utiliza el comando in.iked.

in.iked(1M)

Comando /usr/sbin/ikeadm

Comando de administración de IKE para ver y modificar la directiva IKE.

ikeadm(1M)

Comando /usr/sbin/ikecert

Comando de administración de bases de datos de certificados para administrar bases de datos locales que contienen certificados de claves públicas. Estas bases de datos también se puede almacenar en una placa de Sun Crypto Accelerator 4000 conectada.

ikecert(1M)

Archivo /etc/inet/ike/config

Archivo de configuración predeterminada para la directiva IKE en el directorio /etc/inet. Contiene las reglas del sitio para hacer coincidir las solicitudes IKE entrantes y preparar las solicitudes IKE salientes.

En la versión actual, si este archivo existe, el daemon en.iked se inicia cuando el servicio ike está habilitado. El comando svccfg puede modificar la ubicación de este archivo.

ike.config(4)

Archivo ike.preshared

Archivo de claves previamente compartidas del directorio /etc/inet/secret. Contiene material de claves secretas para autenticación en el intercambio de fase 1. Se utiliza al configurar IKE con claves previamente compartidas.

ike.preshared(4)

Directorio ike.privatekeys

Directorio de claves privadas del directorio /etc/inet/secret. Contiene las claves privadas que forman parte de un par de claves pública-privada.

ikecert(1M)

Directorio publickeys

Directorio del directorio /etc/inet/ike que contiene archivos de certificados y claves públicas. Contiene la parte de clave pública de un par de claves pública-privada.

ikecert(1M)

Directorio crls

Directorio del directorio /etc/inet/ike que incluye listas de revocación para archivos de certificados y claves públicas.

ikecert(1M)

Placa de Sun Crypto Accelerator 1000 

Hardware que acelera las operaciones de claves públicas al descargar las operaciones del sistema operativo. 

ikecert(1M)

Placa de Sun Crypto Accelerator 4000 

Hardware que acelera las operaciones de claves públicas al descargar las operaciones del sistema operativo. La placa también almacena claves públicas, claves privadas y certificados de claves públicas. 

ikecert(1M)

Cambios de IKE en Solaris 10

A partir de Solaris 9, IKE incluye las funciones siguientes:

Capítulo 23 Configuración de IKE (tareas)

En este capítulo se describe cómo configurar Internet Key Exchange (IKE) para sus sistemas. Una vez configurado IKE, se genera automáticamente material de claves para IPsec en la red. Este capítulo contiene la información siguiente:

Para obtener una descripción general sobre IKE, consulte el Capítulo 22Intercambio de claves de Internet (descripción general). Para obtener información de referencia sobre IKE, consulte el Capítulo 24Intercambio de claves de Internet (referencia). Para ver más procedimientos, consulte las secciones de ejemplos de las páginas del comando man ikeadm(1M), ikecert(1M) y ike.config(4).

Configuración de IKE (mapa de tareas)

Para autenticar IKE puede utilizar claves previamente compartidas, certificados autofirmados y certificados de una autoridad de certificación. Una regla vincula el método de autenticación de IKE específico con los puntos finales que se están protegiendo. Por tanto, puede utilizar uno o todos los métodos de autenticación de IKE de un sistema. Un puntero a una biblioteca PKCS #11 permite a los certificados utilizar un acelerador de hardware conectado.

Una vez configurado IKE, complete la tarea de IPsec que utilice la configuración de IKE. La tabla siguiente hace referencia a los mapas de tareas que se centran en una configuración de IKE específica.

Tarea 

Descripción 

Para obtener instrucciones 

Configurar IKE con claves previamente compartidas 

Protege la comunicación entre dos sistemas al hacer que dos sistemas compartan una clave secreta. 

Configuración de IKE con claves previamente compartidas (mapa de tareas)

Configurar IKE con certificados de clave pública 

Protege las comunicaciones con certificados de clave pública. Los certificados pueden ser autofirmados o comprobados por una organización de PKI. 

Configuración de IKE con certificados de clave pública (mapa de tareas)

Cruzar un límite de NAT 

Configura IPsec e IKE para comunicarse con un sistema portátil 

Configuración de IKE para sistemas portátiles (mapa de tareas)

Configurar IKE para generar y guardar certificados de clave pública en el hardware conectado 

Permite a una placa Sun Crypto Accelerator 1000 o Sun Crypto Accelerator 4000 acelerar las operaciones de IKE. También permite a las placas Sun Crypto Accelerator 4000 guardar certificados de clave pública. 

Configuración de IKE para buscar el hardware conectado (mapa de tareas)

Ajustar parámetros de negociación de clave de fase 1 

Cambia el tiempo de las negociaciones de claves IKE. 

Cambio de los parámetros de transmisión de IKE (mapa de tareas)

Configuración de IKE con claves previamente compartidas (mapa de tareas)

En la tabla siguiente se incluyen los procedimientos para configurar y mantener IKE con claves previamente compartidas.

Tarea 

Descripción 

Para obtener instrucciones 

Configurar IKE con claves previamente compartidas 

Crea un archivo de directiva IKE y una clave para compartir. 

Cómo configurar IKE con claves previamente compartidas

Actualizar claves previamente compartidas en un sistema IKE en ejecución 

Agrega nuevo material de claves para IKE en los sistemas que se comunican. 

Cómo actualizar las claves IKE previamente compartidas

Agregar claves previamente compartidas a un sistema IKE en ejecución 

Agrega una nueva entrada de directiva IKE y nuevo material de claves en un sistema que está aplicando la directiva IKE. 

Cómo agregar una clave IKE previamente compartida para una nueva entrada de directiva en ipsecinit.conf

Comprobar que las claves previamente compartidas sean idénticas 

Muestra las claves previamente compartidas en ambos sistemas para comprobar que las claves sean idénticas. 

Verificación de que las claves IKE previamente compartidas sean idénticas

Configuración de IKE con claves previamente compartidas

Las claves previamente compartidas constituyen el método de autenticación más sencillo para IKE. Si esta configurando dos sistemas para que utilicen IKE y es el administrador de ambos sistemas, se recomienda utilizar claves previamente compartidas. Sin embargo, a diferencia de los certificados de clave pública, las claves previamente compartidas están vinculadas a direcciones IP específicas. Las claves previamente compartidas no se pueden utilizar con sistemas portátiles o sistemas cuya numeración podría variar. Además, al utilizar claves previamente compartidas, no es posible descargar los cálculos de IKE en el hardware conectado.

ProcedureCómo configurar IKE con claves previamente compartidas

La implementación de IKE ofrece algoritmos con claves cuya longitud varía. La longitud de claves que elija dependerá de la seguridad del sitio. En general, las claves largas son más seguras que las cortas.

Estos procedimientos utilizan los nombres de sistema enigma y partym. Sustituya los nombres de los sistemas con los nombres enigma y partym.

  1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

    Nota –

    El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

  2. En cada sistema, copie el archivo /etc/inet/ike/config.sample al archivo /etc/inet/ike/config.

  3. Especifique las reglas y los parámetros generales en el archivo ike/config de cada sistema.

    Las reglas y los parámetros generales de este archivo deberían permitir la correcta aplicación de la directiva IPsec en el archivo ipsecinit.conf del sistema. Los siguientes ejemplos de ike/config funcionan con los ejemplos de ipsecinit.conf de Cómo proteger el tráfico entre dos sistemas con IPsec.

    1. Por ejemplo, modifique el archivo /etc/inet/ike/config del sistema enigma:


      ### ike/config file on enigma, 192.168.116.16

## Global parameters
#
## Phase 1 transform defaults
p1_lifetime_secs 14400
p1_nonce_len 40
#
## Defaults that individual rules can override.
p1_xform
  { auth_method preshared oakley_group 5 auth_alg sha encr_alg des }
p2_pfs 2
#
## The rule to communicate with partym
#  Label must be unique
{ label "enigma-partym"
  local_addr 192.168.116.16
  remote_addr 192.168.13.213
  p1_xform
   { auth_method preshared oakley_group 5 auth_alg sha1 encr_alg aes }
  p2_pfs 5
}
      Nota –

      Todos los argumentos del parámetro auth_method deben encontrarse en la misma línea.

    2. Modifique el archivo /etc/inet/ike/config del sistema partym:


      ### ike/config file on partym, 192.168.13.213
## Global Parameters
#
p1_lifetime_secs 14400
p1_nonce_len 40
#
p1_xform
  { auth_method preshared oakley_group 5 auth_alg sha encr_alg des }
p2_pfs 2

## The rule to communicate with enigma
#  Label must be unique
{ label "partym-enigma"
  local_addr 192.168.13.213
  remote_addr 192.168.116.16
p1_xform
   { auth_method preshared oakley_group 5 auth_alg sha1 encr_alg aes }
p2_pfs 5
}

  4. En cada sistema, compruebe la sintaxis del archivo.


    # /usr/lib/inet/in.iked -c -f /etc/inet/ike/config

  5. Genere números aleatorios para utilizar como material de claves.

    Si su sitio cuenta con un generador de números aleatorios, utilícelo. En un sistema Solaris, puede utilizar el comando od. Por ejemplo, el siguiente comando imprime dos líneas de números hexadecimales:


    % od -X -A n /dev/random | head -2
         f47cb0f4 32e14480 951095f8 2b735ba8
         0a9467d0 8f92c880 68b6a40e 0efe067d

    Para ver una explicación del comando od, consulte Cómo generar números aleatorios en un sistema Solaris y la página del comando man od(1).

    Nota –

    Otros sistemas operativos pueden requerir material de claves ASCII. Para generar una clave idéntica en los formatos hexadecimal y ASCII, consulte el Ejemplo 23–1.

  6. Cree una clave a partir del resultado obtenido en el Paso 5.


    f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e

    El algoritmo de autenticación de este procedimiento es SHA–1, tal como se muestra en el Paso 3. El tamaño del hash, es decir, el tamaño del resultado del algoritmo de autenticación, determina el tamaño mínimo recomendado de una clave previamente compartida. El resultado del algoritmo SHA–1 es 160 bits o 40 caracteres. La clave de ejemplo tiene una longitud de 56 caracteres, que proporciona material de claves adicional para usar en IKE.

  7. Cree el archivo /etc/inet/secret/ike.preshared en cada sistema.

    Coloque la clave previamente compartida en cada archivo.

    1. Por ejemplo, en el sistema enigma, el archivo ike.preshared tendría el siguiente aspecto:


      # ike.preshared on enigma, 192.168.116.16
#…
{ localidtype IP
	localid 192.168.116.16
	remoteidtype IP
	remoteid 192.168.13.213
	# enigma and partym's shared key in hex (192 bits)
	key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e
	}

    2. En el sistema partym, el archivo ike.preshared tendría el siguiente aspecto:


      # ike.preshared on partym, 192.168.13.213
#…
{ localidtype IP
	localid 192.168.13.213
	remoteidtype IP
	remoteid 192.168.116.16
	# partym and enigma's shared key in hex (192 bits)
	key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e
	}
    Nota –

    Las claves previamente compartidas de cada sistema deben ser idénticas.

Ejemplo 23–1 Generación de material de claves idéntico para dos sistemas con diferentes sistemas operativos

Solaris IPsec interopera con otros sistemas operativos. Si su sistema se comunica con un sistema que requiere claves previamente compartidas ASCII, debe generar una clave en dos formatos, hexadecimal y ASCII.

En este ejemplo, el administrador del sistema Solaris desea material de claves de 56 caracteres. El administrador utiliza el comando siguiente para generar una clave hexadecimal a partir de una contraseña ASCII. La opción -tx1 imprime los bytes uno a uno en todos los sistemas Solaris.


# /bin/echo "papiermache with cashews and\c" | od -tx1 | cut -c 8-55 | \
tr -d '\n' | tr -d ' ' | awk '{print}'
7061706965726d616368652077697468206361736865777320616e64

Al eliminar los desfases y concatenar el resultado hexadecimal, la clave hexadecimal del sistema Solaris es 7061706965726d616368652077697468206361736865777320616e64. El administrador coloca este valor en el archivo ike.preshared del sistema Solaris.


# Shared key in hex (192 bits)
key 7061706965726d616368652077697468206361736865777320616e64

En el sistema que requiere claves previamente compartidas ASCII, la contraseña es la clave previamente compartida. El administrador del sistema Solaris comunica por teléfono la contraseña (papiermache with cashews and) al otro administrador.

ProcedureCómo actualizar las claves IKE previamente compartidas

Este procedimiento presupone que desea reemplazar una clave previamente compartida a intervalos regulares.

  1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

    Nota –

    El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

  2. Genere números aleatorios y cree una clave con la longitud adecuada.

    Para obtener más información, consulte Cómo generar números aleatorios en un sistema Solaris. Si va a generar una clave previamente compartida para un sistema Solaris que se comunica con un sistema operativo que requiere ASCII, consulte el Ejemplo 23–1.

  3. Sustituya la clave actual por una nueva.

    Por ejemplo, en los hosts enigma y partym, debe reemplazar el valor de key en el archivo /etc/inet/secret/ike.preshared con un nuevo número que tenga la misma longitud.

  4. Lea la nueva clave en el núcleo.

    • A partir de la versión Solaris 10 4/09, actualice el servicio ike. 


      # svcadm refresh ike

    • Si está ejecutando una versión anterior a la Solaris 10 4/09, finalícela y reinicie el daemon in.iked.

      1. Compruebe el nivel de privilegio del daemon in.iked.


        # /usr/sbin/ikeadm get priv
Current privilege level is 0x0, base privileges enabled

        Puede cambiar el material de claves si el comando devuelve un nivel de privilegio de 0x1 o 0x2. El nivel 0x0 no permite a las operaciones modificar ni ver el material de claves. De modo predeterminado, el daemon in.iked se ejecuta en el nivel de privilegio 0x0.

      2. Si el nivel de privilegio es 0x0, finalice el daemon y reinícielo.

        Al reiniciar el daemon, lee la nueva versión del archivo ike.preshared.


        # pkill in.iked
# /usr/lib/inet/in.iked

      3. Si el nivel de privilegio es 0x1 o 0x2, lea la nueva versión del archivo ike.preshared.


        # ikeadm read preshared

ProcedureCómo ver las claves IKE previamente compartidas

Por defecto, el comando ikeadm impide que vea las teclas reales en un volcado de una fase 1 SA. La visualización de las claves es útil durante la depuración.

Para ver las teclas reales, debe aumentar el nivel de privilegios del daemon. Para obtener una descripción de los niveles de privilegios, consulte Comando de administración de IKE.

Nota –

Para llevar a cabo este procedimiento en una versión anterior a Solaris 10 4/09 consulte Ejemplo 23–2.

Antes de empezar

IKE se configura y el servicio ike se ejecuta.

  1. Consulte las teclas previamente compartidas de IKE. 


    # ikeadm
ikeadm> dump preshared

  2. Si aparece un mensaje de error, aumente el nivel de privilegios del daemon in.iked .

    1. Aumente el nivel de privilegios del daemon in.iked en el repositorio SMF. 


      # svcprop -p config/admin_privilege ike
base
# svccfg -s ike setprop config/admin_privilege=keymat

    2. Aumente el nivel de privilegios del daemon in.iked en ejecución.


      # svcadm refresh ike ; svcadm restart ike

    3. (Opcional) Confirme que el nivel de privilegios es keymat. 


      # svcprop -p config/admin_privilege ike
keymat

    4. Ejecute de nuevo el Paso 1 para ver las teclas.

  3. Devuelva al daemon IKE el nivel de privilegios base.

    1. Después de ver las claves, devuelva al nivel de privilegios el valor predeterminado. 


      # svccfg -s ike setprop config/admin_privilege=base

    2. Actualice y, a continuación, reinicie IKE. 


      # svcadm refresh ike ; svcadm restart ike
Ejemplo 23–2 Verificación de las claves IKE compartidas previamente en una versión anterior a Solaris 10 4/09

En el siguiente ejemplo, el administrador está consultando claves en un sistema Solaris que no ejecuta la versión actual de Solaris. El administrador desea comprobar que las claves de este sistema son idénticas a las del sistema de comunicación. Después de comprobar que las claves de los dos sistemas son idénticos, el administrador restablece el nivel de privilegios a 0.

ProcedureCómo agregar una clave IKE previamente compartida para una nueva entrada de directiva en ipsecinit.conf

Si agrega entradas de la directiva IPsec, mientras se ejecutan IPsec e IKE, deberá leer la nueva directiva y las reglas IKE en el núcleo. A partir de la versión Solaris 10 4/09, reinicie el servicio de directivas y actualice el servicio ike después de agregar las nuevas claves.

Nota –

Para llevar a cabo este procedimiento en una versión anterior a Solaris 10 4/09, consulte el Ejemplo 23–3.

Antes de empezar

Este procedimiento presupone lo siguiente:

  1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

    Nota –

    El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

  2. En este sistema, genere números aleatorios y cree una clave de entre 64 y 448 bits.

    Para obtener más información, consulte Cómo generar números aleatorios en un sistema Solaris. Si va a generar una clave previamente compartida para un sistema Solaris que se comunica con un sistema operativo que requiere ASCII, consulte el Ejemplo 23–1.

  3. Envíe la clave al administrador del sistema remoto.

    Ambos deben agregar la misma clave previamente compartida y de forma simultánea. La seguridad de su clave depende de la seguridad de su mecanismo de transmisión. Se recomienda un mecanismo fuera de banda, como un correo registrado o un fax protegido. También puede utilizar una sesión ssh para administrar ambos sistemas.

  4. Cree una regla para que IKE administre las claves para enigma y ada.

    1. En el sistema enigma, agregue la regla siguiente al archivo /etc/inet/ike/config: 


      ### ike/config file on enigma, 192.168.116.16
 
## The rule to communicate with ada

{label "enigma-to-ada"
 local_addr 192.168.116.16
 remote_addr 192.168.15.7
 p1_xform
 {auth_method preshared oakley_group 5 auth_alg sha1 encr_alg blowfish}
 p2_pfs 5
	}

    2. En el sistema ada, agregue la siguiente regla: 


      ### ike/config file on ada, 192.168.15.7
 
## The rule to communicate with enigma

{label "ada-to-enigma"
 local_addr 192.168.15.7
 remote_addr 192.168.116.16
 p1_xform
 {auth_method preshared oakley_group 5 auth_alg sha1 encr_alg blowfish}
 p2_pfs 5
}

  5. Asegúrese de que haya claves IKE previamente compartidas al iniciar.

    1. En el sistema enigma, agregue la siguiente información al archivo /etc/inet/secret/ike.preshared: 


      # ike.preshared on enigma for the ada interface
# 
{ localidtype IP
  localid 192.168.116.16
  remoteidtype IP
  remoteid 192.168.15.7
  # enigma and ada's shared key in hex (32 - 448 bits required)
  key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d
}

    2. En el sistema ada, agregue la información siguiente al archivo ike.preshared:


      # ike.preshared on ada for the enigma interface
# 
{ localidtype IP
  localid 192.168.15.7
  remoteidtype IP
  remoteid 192.168.116.16
  # ada and enigma's shared key in hex (32 - 448 bits required)
  key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d
}

  6. En cada sistema, reinicie el servicio de directivas de IPsec para asegurar la interfaz agregada. 


    # svcadm restart policy

  7. En cada sistema, actualice el servicio ike. 


    # svcadm refresh ike

  8. Compruebe que los sistemas se puedan comunicar.

    Consulte Verificación de que las claves IKE previamente compartidas sean idénticas.

Ejemplo 23–3 Adición de una clave IKE compartida previamente para una nueva entrada de directiva IPsec

En el siguiente ejemplo, el administrador agrega una clave compartida previamente a un sistema Solaris que no ejecuta la versión actual de Solaris. El administrador sigue el procedimiento anterior para modificar los archivos ike/config e ike., así como generar las claves y establecer contacto con el sistema remoto. El administrador utiliza comandos diferentes para leer la nueva directiva IPsec y las reglas IKE en el núcleo.

ProcedureVerificación de que las claves IKE previamente compartidas sean idénticas

Si las claves previamente compartidas de los sistemas que se comunican no son idénticas, los sistemas no se podrán autenticar.

Antes de empezar

IPsec se ha configurado y se ha habilitado entre los dos sistemas que se están probando. Se está ejecutando la versión Solaris 10 actual.

Nota –

Para llevar a cabo este procedimiento en una versión anterior a Solaris 10 4/09 consulte Ejemplo 23–2.

  1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

    Nota –

    El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

  2. En cada sistema, compruebe el nivel de privilegios del daemon in.iked. 


    # svcprop -p config/admin_privilege ike
base

    • Si el nivel de privilegios es keymat, continúe con el Paso 3.

    • Si el nivel de privilegios es base o modkeys, aumente su nivel.

      A continuación, actualice el servicio ike y reinícielo. 


      # svccfg -s ike setprop config/admin_privilege=keymat
# svcadm refresh ike ; svcadm restart ike
# svcprop -p config/admin_privilege ike
keymat

  3. En cada sistema, visualice la información de claves previamente compartidas.


    # ikeadm dump preshared
PSKEY: Preshared key (24 bytes): f47cb…/192
LOCIP: AF_INET: port 0, 192.168.116.16 (enigma).
REMIP: AF_INET: port 0, 192.168.13.213 (partym).

  4. Compare los dos vaciados.

    Si las claves previamente compartidas no son idénticas, sustituya una de ellas con la otra en el archivo /etc/inet/secret/ike.preshared.

  5. Cuando se haya completado la verificación, devuelva al nivel de privilegios el valor predeterminado de cada sistema.


    # svccfg -s ike setprop config/admin_privilege=base
# svcadm restart ike

Configuración de IKE con certificados de clave pública (mapa de tareas)

La tabla siguiente incluye los procedimientos para crear certificados de clave pública para IKE. Entre estos procedimientos se incluye cómo acelerar y guardar los certificados en el hardware conectado.

Tarea 

Descripción 

Para obtener instrucciones 

Configurar IKE con certificados de clave pública autofirmados 

Crea y coloca dos certificados en cada sistema: 

  • Un certificado autofirmado

  • El certificado de clave pública del sistema remoto

Cómo configurar IKE con certificados de clave pública autofirmados

Configurar IKE con una autoridad de certificación de PKI 

Crea una solicitud de certificado y coloca tres certificados en cada sistema: 

  • El certificado que crea la autoridad de certificación a partir de su solicitud

  • El certificado de clave pública de la autoridad de certificación

  • La lista CRL de la autoridad de certificación

Cómo configurar IKE con certificados firmados por una autoridad de certificación

Configurar certificados de clave pública en el hardware local 

Implica una de estas acciones:  

  • Generar un certificado autofirmado en el hardware local y luego agregar la clave pública de un sistema remoto al hardware.

  • Generar una solicitud de certificado en el hardware local y luego agregar los certificados de clave pública de la autoridad de certificación al hardware.

Cómo generar y almacenar certificados de clave pública en el hardware

Actualizar la lista de revocación de certificados (CRL) desde PKI 

Accede a la CRL desde un punto de distribución central. 

Cómo administrar una lista de revocación de certificados

Configuración de IKE con certificados de clave pública

Los certificados de clave pública acaban con la necesidad de que los sistemas que se comunican compartan material de claves secreto fuera de banda. A diferencia de las claves previamente compartidas, un certificado de clave pública se puede utilizar en un equipo portátil o en un sistema cuya numeración podría cambiar.

Los certificados de clave pública también podrían guardarse en el hardware conectado. Para conocer el procedimiento, consulte Configuración de IKE para buscar el hardware conectado (mapa de tareas).

ProcedureCómo configurar IKE con certificados de clave pública autofirmados

Los certificados autofirmados requieren menos carga que los certificados públicos de una autoridad de certificación, pero no se escalan fácilmente.

  1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

    Nota –

    El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

  2. Agregue un certificado autofirmado a la base de datos ike.privatekeys. 


    # ikecert certlocal -ks|-kc -m keysize -t keytype \
-D dname -A altname \
[-S validity-start-time] [-F validity-end-time] [-T token-ID]
    -ks

    Crea un certificado autofirmado.

    -kc

    Crea una solicitud de certificado. Para conocer el procedimiento, consulte Cómo configurar IKE con certificados firmados por una autoridad de certificación.

    -m tamaño_clave

    Es el tamaño de la clave. Tamaño_clave puede ser 512, 1024, 2048, 3072 o 4096.

    -t tipo_clave

    Especifica el tipo de algoritmo que utilizar. Tipo_algoritmo puede ser rsa-sha1, rsa-md5 o dsa-sha1.

    -D nombre_d

    Es el nombre X.509 distinguido para el tema del certificado. Nombre_d suele tener el formato siguiente: C=country (país), O=organization (organización=, OU=organizational unit (unidad organizativa), CN=common name (nombre común). Las etiquetas válidas son C, O, OU y CN.

    -A nombre_alt

    Nombre alternativo del certificado. Nombre_alt tiene el formato tag=value. Las etiquetas válidas son IP, DNS, email y DN.

    -S tiempo_inicio_validez

    Proporciona un tiempo de inicio de validez absoluto o relativo para el certificado.

    -F tiempo_fin_validez

    Proporciona un tiempo de fin de validez absoluto o relativo para el certificado.

    -T ID_token

    Permite al token de hardware PKCS #11 generar las claves. Los certificados se guardan en el hardware.

    1. Por ejemplo, el comando del sistema partym sería como el siguiente:


      # ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
-A IP=192.168.13.213
Creating software private keys.
  Writing private key to file /etc/inet/secret/ike.privatekeys/0.
Enabling external key providers - done.
Acquiring private keys for signing - done.
Certificate: 
 Proceeding with the signing operation.
 Certificate generated successfully (…/publickeys/0)
Finished successfully.
Certificate added to database.
-----BEGIN X509 CERTIFICATE-----
MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
…
6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
-----END X509 CERTIFICATE-----

    2. El comando del sistema enigma sería como el siguiente:


      # ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
-A IP=192.168.116.16
Creating software private keys.
  …
Certificate added to database.
-----BEGIN X509 CERTIFICATE-----
MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV
…
jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A==
-----END X509 CERTIFICATE-----

  3. Guarde el certificado y envíelo al sistema remoto.

    El certificado se puede pegar en un mensaje de correo electrónico.

    1. Por ejemplo, enviaría el siguiente certificado de partym al administrador de enigma:


      To: admin@ja.enigmaexample.com
From: admin@us.partyexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
…
6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
-----END X509 CERTIFICATE-----

    2. El administrador de enigma enviaría el siguiente certificado de enigma:


      To: admin@us.partyexample.com
From: admin@ja.enigmaexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV
…
jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A==
-----END X509 CERTIFICATE-----

  4. En cada sistema, agregue el certificado que reciba.

    1. Copie la clave pública del correo electrónico del administrador.

    2. Escriba el comando ikecert certdb -a y pulse la tecla Intro.

      Al pulsar Intro no aparecerá ningún mensaje.


      # ikecert certdb -a Press the Return key

    3. Pegue la clave pública. A continuación, pulse la tecla Intro. Para finalizar la entrada, pulse Control+D.


      -----BEGIN X509 CERTIFICATE-----
MIIC…
…
----END X509 CERTIFICATE----- Press the Return key
<Control>-D

  5. Verifique con el otro administrador que el certificado proceda de dicho administrador.

    Por ejemplo, puede llamar por teléfono al otro administrador para comparar los valores de hash de clave pública. El hash de clave pública del certificado compartido debe ser idéntico en los dos sistemas.

    1. Enumere el certificado guardado en su sistema.

      Por ejemplo, en el sistema partym, el certificado público se encuentra en la ranura 1 y el certificado privado se encuentra en la ranura 0.


      partym # ikecert certdb -l
Certificate Slot Name: 0   Type: rsa-md5 Private Key
    Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym>
    Key Size: 1024
    Public key hash: B2BD13FCE95FD27ECE6D2DCD0DE760E2

Certificate Slot Name: 1   Type: rsa-md5 Public Certificate
    (Private key in certlocal slot 0) Points to certificate's private key
    Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

    2. Compare este valor con el hash de clave pública del sistema enigma.

      El hash de clave pública se puede comunicar por teléfono.


      enigma # ikecert certdb -l
Certificate Slot Name: 4   Type: rsa-md5 Private Key
    Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
    Key Size: 1024
    Public key hash: DF3F108F6AC669C88C6BD026B0FCE3A0

Certificate Slot Name: 5   Type: rsa-md5 Public Certificate
    (Private key in certlocal slot 4)
    Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym>
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

  6. En cada sistema, confíe en ambos certificados.

    Edite el archivo /etc/inet/ike/config para reconocer los certificados.

    El administrador del sistema remoto proporciona los valores para los parámetros cert_trust, remote_addr y remote_id.

    1. Por ejemplo, en el sistema partym, el archivo ike/config tendría el siguiente aspecto:


      # Explicitly trust the following self-signed certs
# Use the Subject Alternate Name to identify the cert

# Verified remote address and remote ID
# Verified public key hash per telephone call from administrator
cert_trust "192.168.13.213" Local system's certificate Subject Alt Name
cert_trust "192.168.116.16" Remote system's certificate Subject Alt Name

## Parameters that may also show up in rules.

p1_xform 
  { auth_method preshared oakley_group 5 auth_alg sha encr_alg des }
p2_pfs 5

{
 label "US-partym to JA-enigmax"
 local_id_type dn
 local_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"

 local_addr  192.168.13.213
 remote_addr 192.168.116.16

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}

    2. En el sistema enigma, agregue los valores de enigma para los parámetros locales en el archivo ike/config.

      Para los parámetros remotos, utilice los valores de partym. Asegúrese de que el valor de la palabra clave label sea único. Este valor debe ser diferente del valor label del sistema remoto.


      …
{
 label "JA-enigmax to US-partym"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213
…
Ejemplo 23–4 Verificación de la validez de un certificado procedente de otro administrador

En este ejemplo, los administradores recurren al nombre del asunto para verificar que los certificados sean idénticos.

El primer administrador guarda la salida de la generación y hace constar el certificado en un archivo. Debido a que la salida del comando ikecert imprime un error estándar, el administrador redirige el error estándar al archivo.


sys1# cd /
sys1# ikecert certlocal -ks -m1024 -t rsa-md5 \
-D"C=US, O=TestCo, CN=Co2Sys" 2>/tmp/for_co2sys
Certificate added to database.
sys1# ikecert certdb -l "C=US, O=TestCo, CN=Co2Sys" 2>>/tmp/for_co2sys

El administrador verifica el contenido del archivo.


sys1# cat /tmp/for_co2sys
Creating private key.
-----BEGIN X509 CERTIFICATE-----
MIIB7TCCAVagAwIBAgIEZkHfOTANBgkqhkiG9w0BAQQFADAxMQwwCgYDVQQGEwNV
U0ExEDAOBgNVBAoMB3Rlc3RfY28xDzANBgNVBAMTBkVuaWdtYTAeFw0wODAxMTUx
OTI1MjBaFw0xMjAxMTUxOTI1MjBaMDExDDAKBgNVBAYTA1VTQTEQMA4GA1UECgwH
dGVzdF9jbzEPMA0GA1UEAxMGRW5pZ21hMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQCPxGv0rUzHMnFtkx9uwYuPiWbftmWfa9iDt6ELOEuw3zlboy2qtuRUZohz
FIbCxAJevdCY6a+pktvYy3/2nJL0WATObO5T0FKn3F0bphajinLYbyCrYhEzD9E2
gkiT2D9/ttbSiMvi9usphprEDcLAFaWgCJiHnKPBEkjC0vhA3wIDAQABoxIwEDAO
BgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEEBQADgYEAL/q6xgweylGQylqLCwzN
5PIpjfzsNPf3saTyh3VplwEOW6WTHwRQT17IO/1Oc6Jnz9Mr0ZrbHWDXq+1sx180
F8+DMW1Qv1UR/lGMq3ufDG3qedmSN6txDF8qLlPCUML0YL8m4oGdewqGb+78aPyE
Y/cJRsK1hWbYyseqcIkjj5k=
-----END X509 CERTIFICATE-----
Certificate Slot Name: 2   Key Type: rsa
        (Private key in certlocal slot 2)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

A continuación, el administrador envía el archivo al segundo administrador por correo electrónico.

El segundo administrador coloca el archivo en un directorio seguro e importa el certificado del archivo.


sys2# cd /
sys2# ikecert certdb -a < /sec/co2sys

El comando ikecert importa únicamente el texto que hay entre las líneas -----BEGIN y -----END. El administrador verifica que el certificado local tenga el mismo valor hash de clave pública quel valor hash de clave pública que haya en el archivo co2sys.


sys2# ikecert certdb -l
Certificate Slot Name: 1   Key Type: rsa
        (Private key in certlocal slot 1)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

Para asegurarse de que el primer administrador envíe este correo electrónico, el segundo administrador telefonea al primero para verificar el nombre del asunto del certificado.

Ejemplo 23–5 Especificación de un tiempo de inicio y un tiempo de fin para un certificado

En este ejemplo, el administrador del sistema partym establece las fechas durante las cuales el certificado es válido. El certificado será anterior en dos días y medio, y será válido para 4 años y 6 meses a partir de la fecha de creación.


# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
-A IP=192.168.13.213 \
-S -2d12h -F +4y6m

El administrador del sistema enigma establece las fechas para la validez del certificado. El certificado será anterior en dos días y será válido hasta las 12 de la noche del 31 de diciembre de 2010.


# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
-A IP=192.168.116.16 \
-S -2d -F "12/31/2010 12:00 AM"

ProcedureCómo configurar IKE con certificados firmados por una autoridad de certificación

Los certificados públicos de una autoridad de certificación requieren negociar con una organización externa. Los certificados se pueden escalar con gran facilidad para proteger un mayor número de sistemas que se comunican.

  1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

    Nota –

    El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

  2. Utilice el comando ikecert certlocal -kc para crear una solicitud de certificado.

    Para ver una descripción de los argumentos del comando, consulte el Paso 2 en Cómo configurar IKE con certificados de clave pública autofirmados.


    # ikecert certlocal -kc -m keysize -t keytype \
-D dname -A altname

    1. Por ejemplo, el comando siguiente crea una solicitud de certificado en el sistema partym:


      # ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany\, Inc., OU=US-Partym, CN=Partym" \
> -A "DN=C=US, O=PartyCompany\, Inc., OU=US-Partym"
Creating software private keys.
  Writing private key to file /etc/inet/secret/ike.privatekeys/2.
Enabling external key providers - done.
Certificate Request: 
  Proceeding with the signing operation.
  Certificate request generated successfully (…/publickeys/0)
Finished successfully.
-----BEGIN CERTIFICATE REQUEST-----
MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w
…
lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X
-----END CERTIFICATE REQUEST-----

    2. El comando siguiente crea una solicitud de certificado en el sistema enigma:


      # ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax, CN=Enigmax" \
> -A "DN=C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax"
Creating software private keys.
…
Finished successfully.
-----BEGIN CERTIFICATE REQUEST-----
MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu
…
8qlqdjaStLGfhDOO
-----END CERTIFICATE REQUEST-----

  3. Envíe la solicitud de certificado a una organización de PKI.

    La organización de PKI puede indicar cómo enviar la solicitud de certificado. La mayoría de las organizaciones cuenta con un sitio web con un formulario de envío. El formulario requiere una prueba de que el envío es legítimo. Normalmente, la solicitud de certificado se pega en el formulario. Cuando la organización ha comprobado la solicitud, emite los dos objetos de certificado siguientes y una lista de los certificados revocados:

    • El certificado de clave pública: este certificado se basa en la solicitud que ha enviado a la organización. La solicitud que envía forma parte del certificado de clave pública. El certificado le identifica de forma exclusiva.

    • Una autoridad de certificación: la firma de la organización. La autoridad de certificación verifica que el certificado de clave pública sea legítimo.

    • Una lista de revocación de certificados (CRL): La lista de certificados más reciente que ha revocado la organización. La CRL no se envía por separado como objeto de certificado si el acceso a la CRL está integrado en el certificado de clave pública.

      Cuando un URI para la CRL está integrado en el certificado de clave pública, IKE puede recuperar automáticamente la CRL. De modo similar, cuando una entrada DN (nombre de directorio en servidor LDAP) se integra en el certificado de clave pública, IKE puede recuperar la CRL y almacenarla en caché desde un servidor LDAP que se especifique.

      Consulte Cómo administrar una lista de revocación de certificados para ver un ejemplo de URI integrado y una entrada DN integrada en un certificado de clave pública.

  4. Agregue cada certificado al sistema.

    La opción -a de ikecert certdb -a agrega el objeto pegado a la base de datos de certificados pertinente del sistema. Para más información, consulte IKE con certificados de claves públicas.

    1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

    2. Agregue el certificado de clave pública que ha recibido de la organización de PKI.


      # ikecert certdb -a
Press the Return key
Paste the certificate:
-----BEGIN X509 CERTIFICATE-----
…
-----END X509 CERTIFICATE----
Press the Return key
<Control>-D

    3. Agregue la autoridad de certificación de la organización de PKI.


      # ikecert certdb -a
Press the Return key
Paste the CA:
-----BEGIN X509 CERTIFICATE-----
…
-----END X509 CERTIFICATE----
Press the Return key
<Control>-D

    4. Si la organización de PKI ha enviado una lista de certificados revocados, agregue la CRL a la base de datos certrldb:


      # ikecert certrldb -a
Press the Return key
Paste the CRL:
-----BEGIN CRL-----
…
-----END CRL----
Press the Return key
<Control>-D

  5. Utilice la palabra clave cert_root para identificar la organización de PKI en el archivo /etc/inet/ike/config.

    Utilice el nombre que proporciona la organización de PKI.

    1. Por ejemplo, el archivo ike/config del sistema partym podría ser similar a:


      # Trusted root cert
# This certificate is from Example PKI
# This is the X.509 distinguished name for the CA that it issues.

cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"

## Parameters that may also show up in rules.

p1_xform 
 { auth_method rsa_sig oakley_group 1 auth_alg sha1 encr_alg des }
p2_pfs 2

{
 label "US-partym to JA-enigmax - Example PKI"
 local_id_type dn
 local_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"

 local_addr  192.168.13.213
 remote_addr 192.168.116.16

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}
      Nota –

      Todos los argumentos del parámetro auth_method deben encontrarse en la misma línea.

    2. En el sistema enigma, cree un archivo similar.

      En concreto, el archivo enigma ike/config llevará a cabo las siguientes acciones:

      • Incluirá el mismo valor de cert_root.

      • Utilizará los valores de enigma para los parámetros locales.

      • Utilice los valores de partym para los parámetros remotos.

      • Cree un valor único para la palabra clave label. Este valor debe ser diferente del valor label del sistema remoto.


      …
cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"
…
{
 label "JA-enigmax to US-partym - Example PKI"
 local_id_type dn
 local_id   "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 
 local_addr  192.168.116.16
 remote_addr 192.168.13.213
…

  6. Indique a IKE cómo administrar las CRL.

    Elija la opción adecuada:

    • Ninguna CRL disponible

      Si la organización de PKI no proporciona ninguna CRL, agregue la palabra clave ignore_crls al archivo ike/config.


      # Trusted root cert
…
cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example,…
ignore_crls
…

      La palabra clave ignore_crls indica a IKE que no debe buscar ninguna CRL.

    • CRL disponible

      Si la organización de PKI proporciona un punto de distribución central para las CRL, puede modificar el archivo ike/config para que haga referencia a esa ubicación.

      Consulte Cómo administrar una lista de revocación de certificados para ver algunos ejemplos.

Ejemplo 23–6 Uso de rsa_encrypt durante la configuración de IKE

    Cuando utiliza auth_method rsa_encrypt en el archivo ike/config, debe agregar el certificado equivalente a la base de datos publickeys.

  1. Envíe el certificado al administrador del sistema remoto.

    El certificado se puede pegar en un mensaje de correo electrónico.

    Por ejemplo, el administrador de partym enviaría el siguiente mensaje de correo electrónico:


    To: admin@ja.enigmaexample.com
From: admin@us.partyexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MII…
----END X509 CERTIFICATE-----

    El administrador de enigma enviaría el siguiente mensaje de correo electrónico:


    To: admin@us.partyexample.com
From: admin@ja.enigmaexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MII
…
-----END X509 CERTIFICATE-----

  2. En cada sistema, agregue el certificado enviado por correo electrónico a la base de datos publickeys local. 


    # ikecert certdb -a
Press the Return key
-----BEGIN X509 CERTIFICATE-----
MII…
-----END X509 CERTIFICATE-----
Press the Return key
<Control>-D

El método de autenticación para el cifrado de RSA oculta las identidades de IKE de los intrusos. Dado que el método rsa_encrypt oculta la identidad del equivalente, IKE no puede recuperar su certificado. Como consecuencia de ello, el método rsa_encrypt requiere que los equivalentes de IKE conozcan las claves públicas el uno del otro.

Por tanto, si utiliza un auth_method de rsa_encrypt en el archivo /etc/inet/ike/config, debe agregar el certificado del equivalente a la base de datos publickeys. La base de datos publickeys incluye tres certificados para cada par de sistemas que se comunican:

Resolución de problemas: La carga útil de IKE, que incluye los tres certificados, puede ser demasiado grande para que la cifre rsa_encrypt. Errores como un fallo de autenticación o una carga útil mal formada pueden indicar que el método rsa_encrypt no puede cifrar la carga útil total. Reduzca el tamaño de la carga útil utilizando un método que requiera únicamente dos certificados, por ejemplo rsa_sig.

ProcedureCómo generar y almacenar certificados de clave pública en el hardware

La generación y el almacenamiento de certificados de clave pública en hardware es similar a la generación y el almacenamiento de certificados de clave pública en el sistema. En el hardware, los comandos ikecert certlocal e ikecert certdb deben identificar el hardware. La opción -T con el ID de símbolo identifica el hardware para los comandos.

Antes de empezar

  1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

    Nota –

    El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

  2. Genere un certificado autofirmado o una solicitud de certificado y especifique el ID de símbolo.

    Elija una de las siguientes opciones:

    Nota –

    La placa Sun Crypto Accelerator 4000 admite claves de hasta 2048 bits para RSA. Para DSA, esta placa admite claves de hasta 1024 bits.

    • Para un certificado autofirmado, utilice esta sintaxis.


      # ikecert certlocal -ks -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
> -a -T dca0-accel-stor IP=192.168.116.16
Creating hardware private keys.
Enter PIN for PKCS#11 token: Type user:password

      El argumento para la opción -T es el ID de símbolo de la placa Sun Crypto Accelerator 4000 conectada.

    • Para obtener una solicitud de certificado, utilice esta sintaxis.


      # ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
> -a -T dca0-accel-stor IP=192.168.116.16
Creating hardware private keys.
Enter PIN for PKCS#11 token: Type user:password

    Para ver una descripción de los argumentos para el comando ikecert, consulte la página del comando man ikecert(1M).

  3. Cuando se le solicite un PIN, escriba el usuario de Sun Crypto Accelerator 4000, dos puntos y la contraseña del usuario.

    Si la placa de Sun Crypto Accelerator 4000 tiene un usuario ikemgr cuya contraseña es rgm4tigt, debe escribir:


    Enter PIN for PKCS#11 token: ikemgr:rgm4tigt
    Nota –

    La respuesta de PIN se guarda en el disco como texto sin cifrar.

    Una vez indicada la contraseña, se imprime el certificado:


    Enter PIN for PKCS#11 token: ikemgr:rgm4tigt
-----BEGIN X509 CERTIFICATE-----
MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu
…
oKUDBbZ9O/pLWYGr
-----END X509 CERTIFICATE-----

  4. Envíe su certificado para que lo pueda utilizar la otra parte.

    Elija una de las siguientes opciones:

  5. En el sistema, edite el archivo /etc/inet/ike/config para que reconozca los certificados.

    Elija una de las siguientes opciones.

    • Certificado autofirmado

      Utilice los valores que proporciona el administrador del sistema remoto para los parámetros cert_trust, remote_id y remote_addr. Por ejemplo, en el sistema enigma, el archivo ike/config sería similar a:


      # Explicitly trust the following self-signed certs
# Use the Subject Alternate Name to identify the cert

cert_trust "192.168.116.16"  Local system's certificate Subject Alt Name
cert_trust "192.168.13.213"  Remote system's certificate Subject Alt name


# Solaris 10 1/06 release: default path does not have to be typed in
#pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection

# Solaris 10 release: use this path
#pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so"
…
{
 label "JA-enigmax to US-partym"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}

    • Solicitud de certificado

      Escriba el nombre que proporciona la organización de PKI como valor para la palabra clave cert_root. Por ejemplo, el archivo ike/config del sistema enigma podría ser similar a:


      # Trusted root cert
# This certificate is from Example PKI
# This is the X.509 distinguished name for the CA that it issues.

cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"

# Solaris 10 1/06 release: default path does not have to be typed in
#pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection

# Solaris 10 release: use this path
#pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so"
…
{
 label "JA-enigmax to US-partym - Example PKI"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}

  6. Coloque los certificados de la otra parte en el hardware.

    Responda a la solicitud de PIN del mismo modo que en el Paso 3.

    Nota –

    Debe agregar los certificados de clave pública al mismo hardware conectado que generó la clave privada.

    • Certificado autofirmado.

      Agregue el certificado autofirmado al sistema remoto. En este ejemplo, el certificado se guarda en el archivo, DCA.ACCEL.STOR.CERT.


      # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT
Enter PIN for PKCS#11 token: Type user:password

      Si el certificado autofirmado utilizó rsa_encrypt como valor para el parámetro auth_method, agregue el certificado del equivalente al hardware.

    • Certificados de una organización de PKI.

      Agregue el certificado que ha generado la organización a partir de la solicitud de certificado, y agregue la autoridad de certificación.


      # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT
Enter PIN for PKCS#11 token: Type user:password


      # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CA.CERT
Enter PIN for PKCS#11 token: Type user:password

      Para agregar una lista de revocación de certificados (CRL) de la organización de PKI, consulte Cómo administrar una lista de revocación de certificados.

ProcedureCómo administrar una lista de revocación de certificados

Una lista de revocación de certificados (CRL) contiene certificados caducados o que suponen un peligro de una autoridad de certificación. Existen cuatro modos de administrar las CRL.

El siguiente procedimiento describe cómo indicar a IKE que utilice las CRL de un punto de distribución central.

  1. Visualice el certificado que ha recibido de la autoridad de certificación.


    # ikecert certdb -lv certspec
    -l

    Enumera los certificados de la base de datos IKE.

    -v

    Enumera los certificados en modo detallado. Utilice esta opción con precaución.

    certspec

    Es un patrón que coincide con un certificado de la base de datos de certificados IKE.

    Por ejemplo, el certificado siguiente ha sido emitido por Sun Microsystems. Los detalles se han modificado.


    # ikecert certdb -lv example-protect.sun.com
Certificate Slot Name: 0   Type: dsa-sha1
   (Private key in certlocal slot 0)
 Subject Name: <O=Sun Microsystems Inc, CN=example-protect.sun.com>
 Issuer Name: <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc>
 SerialNumber: 14000D93
   Validity:
      Not Valid Before: 2002 Jul 19th, 21:11:11 GMT
      Not Valid After:  2005 Jul 18th, 21:11:11 GMT
   Public Key Info:
      Public Modulus  (n) (2048 bits): C575A…A5
      Public Exponent (e) (  24 bits): 010001
   Extensions:
      Subject Alternative Names:
              DNS = example-protect.sun.com
      Key Usage: DigitalSignature KeyEncipherment
      [CRITICAL]
   CRL Distribution Points:
      Full Name:
         URI = #Ihttp://www.sun.com/pki/pkismica.crl#i
         DN = <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc>
      CRL Issuer: 
      Authority Key ID:
      Key ID:              4F … 6B
      SubjectKeyID:        A5 … FD
      Certificate Policies
      Authority Information Access

    Observe la entrada CRL Distribution Points. La entrada URI indica que la CRL de esta organización está disponible en Internet. La entrada DN indica que la CRL está disponible en un servidor LDAP. Cuando IKE accede a la CRL, ésta se almacena en caché para futuros usos.

    Para acceder a la CRL, debe alcanzar un punto de distribución.

  2. Elija uno de los métodos siguientes para acceder a la CRL desde un punto de distribución central.

    • Utilice el URI.

      Agregue la palabra clave use_http al archivo /etc/inet/ike/config del host. Por ejemplo, el archivo ike/config tendría el siguiente aspecto:


      # Use CRL from organization's URI
use_http
…

    • Utilice un proxy Web.

      Agregue la palabra clave proxy al archivo ike/config. La palabra clave proxy adopta una dirección URL como argumento, como en el caso siguiente:


      # Use own web proxy
proxy "http://proxy1:8080"

    • Utilice un servidor LDAP.

      Configure el servidor LDAP como argumento para la palabra clave ldap-list del archivo /etc/inet/ike/config del host. Su organización proporciona el nombre del servidor LDAP. La entrada del archivo ike/config tendría el siguiente aspecto:


      # Use CRL from organization's LDAP
ldap-list "ldap1.sun.com:389,ldap2.sun.com"
…

    IKE recupera la CRL y almacena en caché la CRL hasta que caduque el certificado.

Ejemplo 23–7 Cómo pegar una CRL en la base de datos certrldb local

Si la CRL de la organización de PKI no está disponible en un punto de distribución central, puede agregar la CRL manualmente a la base de datos certrldb local. Siga las instrucciones de la organización de PKI para extraer la CRL en un archivo y, a continuación, agregue la CRL a la base de datos con el comando ikecert certrldb -a.


# ikecert certrldb -a < Sun.Cert.CRL

Configuración de IKE para sistemas portátiles (mapa de tareas)

La tabla siguiente incluye los procedimientos para configurar IKE para la administración de sistemas que se registran remotamente en un sitio central.

Tarea 

Descripción 

Para obtener instrucciones 

Comunicar remotamente con un sitio central 

Permite a los sistemas remotos comunicarse con un sitio central. Los sistemas remotos pueden ser portátiles. 

Cómo configurar IKE para sistemas remotos

Utilizar un certificado raíz e IKE en un sistema central que acepta tráfico de sistemas portátiles 

Configura un sistema de portal para que acepte el tráfico de IPsec de un sistema que no tiene una dirección IP fija. 

Ejemplo 23–8

Utilizar un certificado raíz e IKE en un sistema que no tiene una dirección IP fija 

Configura un sistema portátil para proteger su tráfico en un sitio central, como la oficina central de una compañía. 

Ejemplo 23–9

Utilizar certificados autofirmados e IKE en un sistema central que acepta tráfico de sistemas portátiles 

Configura un sistema de portal con certificados autofirmados para aceptar tráfico de IPsec desde un sistema portátil. 

Ejemplo 23–10

Utilizar certificados autofirmados e IKE en un sistema que no tiene una dirección IP fija 

Configura un sistema portátil con certificados autofirmados para proteger su tráfico en un sitio central. 

Ejemplo 23–11

Configuración de IKE para sistemas portátiles

Cuando se configuran correctamente, las oficinas domésticas y los portátiles pueden utilizar IPsec e IKE para comunicarse con los equipos centrales de la compañía. Una directiva IPsec general que se combina con un método de autenticación de claves públicas permite a los sistemas remotos proteger su tráfico en un sistema central.

ProcedureCómo configurar IKE para sistemas remotos

IPsec e IKE requieren un ID único para identificar el origen y el destino. Para los sistemas remotos o portátiles que no tienen una dirección IP única, debe utilizar otro tipo de ID. Los tipos de ID como DNS, DN o email se pueden utilizar para identificar a un sistema de forma exclusiva.

Los sistemas remotos o portátiles que tienen direcciones IP exclusivas se siguen configurando mejor con un tipo de ID diferente. Por ejemplo, si los sistemas intentan conectarse a un sitio central desde un enrutador NAT, no se utilizarán sus direcciones exclusivas. Un enrutador NAT asigna una dirección IP arbitraria, que el sistema central no reconocería.

Las claves previamente compartidas tampoco funcionan bien como mecanismo de autenticación para sistemas portátiles, dado que requieren direcciones IP fijas. Los certificados autofirmados o certificados desde un PKI permiten a los sistemas portátiles comunicarse con el sitio central.

  1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

    Nota –

    El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

  2. Configure el sistema central para que reconozca los sistemas portátiles.

    1. Configure el archivo /etc/hosts.

      El sistema central no tiene que reconocer las direcciones específicas para los sistemas portátiles.


      # /etc/hosts on central
central 192.xxx.xxx.x

    2. Configure el archivo ipsecinit.conf.

      El sistema central necesita una directiva que permite una amplia gama de direcciones IP. Los certificados de la directiva IKE garantizan que los sistemas conectados son legítimos.


      # /etc/inet/ipsecinit.conf on central
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    3. Configure el archivo ike.config.

      DNS identifica el sistema central. Se utilizan certificados para autenticar el sistema.


      ## /etc/inet/ike/ike.config on central
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://somecache.domain:port/"
#
# Use LDAP server
ldap_server   "ldap-server1.domain.org,ldap2.domain.org:port"
#
# List CA-signed certificates
cert_root    "C=US, O=Domain Org, CN=Domain STATE"
#
# List self-signed certificates - trust server and enumerated others
#cert_trust    "DNS=central.domain.org"
#cert_trust    "DNS=mobile.domain.org"
#cert_trust    "DN=CN=Domain Org STATE (CLASS), O=Domain Org
#cert_trust    "email=root@central.domain.org"
#cert_trust    "email=user1@mobile.domain.org"
#

# Rule for mobile systems with certificate
{
  label "Mobile systems with certificate"
  local_id_type DNS

# Any mobile system who knows my DNS or IP can find me.

  local_id "central.domain.org"
  local_addr 192.xxx.xxx.x

# Root certificate ensures trust,
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

  3. Inicie sesión en cada sistema portátil y configure el sistema para buscar el sistema central.

    1. Configure el archivo /etc/hosts.

      El archivo /etc/hosts no necesita una dirección para el sistema portátil, pero puede proporcionar una. El archivo debe contener una dirección IP pública para el sistema central.


      # /etc/hosts on mobile
mobile 10.x.x.xx
central 192.xxx.xxx.x

    2. Configure el archivo ipsecinit.conf.

      El sistema portátil debe encontrar el sistema central por su dirección IP pública. Los sistemas deben configurar la misma directiva IPsec.


      # /etc/inet/ipsecinit.conf on mobile
# Find central
{raddr 192.xxx.xxx.x} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    3. Configure el archivo ike.config.

      El identificador no puede ser una dirección IP. Los siguientes identificadores son válidos para sistemas portátiles:

      • DN=nombre_directorio_ldap

      • DNS=dirección_servidor_nombre_dominio

      • email=dirección_correo_electrónico

      Se utilizan certificados para autenticar el sistema portátil.


      ## /etc/inet/ike/ike.config on mobile
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://somecache.domain:port/"
#
# Use LDAP server
ldap_server   "ldap-server1.domain.org,ldap2.domain.org:port"
#
# List CA-signed certificates
cert_root    "C=US, O=Domain Org, CN=Domain STATE"
#
# Self-signed certificates - trust me and enumerated others
#cert_trust    "DNS=mobile.domain.org"
#cert_trust    "DNS=central.domain.org"
#cert_trust    "DN=CN=Domain Org STATE (CLASS), O=Domain Org
#cert_trust    "email=user1@domain.org"
#cert_trust    "email=root@central.domain.org"
#
# Rule for off-site systems with root certificate
{
	label "Off-site mobile with certificate"
	local_id_type DNS

# NAT-T can translate local_addr into any public IP address
# central knows me by my DNS

	local_id "mobile.domain.org"
	local_addr 0.0.0.0/0

# Find central and trust the root certificate
	remote_id "central.domain.org"
	remote_addr 192.xxx.xxx.x

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

  4. Lea la configuración de IKE en el núcleo.

    • A partir de la versión Solaris 10 4/09, habilite el servicio ike. 


      # svcadm enable svc:/network/ipsec/ike

    • Si está ejecutando una versión anterior a la Solaris 10 4/09, reinicie el sistema. 


      # init 6

      También puede detener e iniciar el daemon in.iked.

Ejemplo 23–8 Configuración de un equipo para que acepte tráfico IPsec de un sistema portátil

IKE puede iniciar negociaciones desde un enrutador NAT. Sin embargo, la configuración de IKE ideal no incluye un enrutador NAT. En el ejemplo siguiente, una autoridad de certificación ha emitido certificados raíz. Los certificados de la autoridad de certificación se colocan en el sistema portátil y el sistema central. Un sistema central acepta las negociaciones de IPsec desde un sistema con un enrutador NAT. main1 es el sistema de la compañía que puede aceptar conexiones desde sistemas remotos. Para configurar los sistemas remotos, consulte el Ejemplo 23–9.


## /etc/hosts on main1
main1 192.168.0.100
 

## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
 

## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.domain.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.domain.org,ldap2.domain.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI"
#
# Rule for off-site systems with root certificate
{
  label "Off-site system with root certificate"
  local_id_type DNS
  local_id "main1.domain.org"
  local_addr 192.168.0.100

# Root certificate ensures trust,
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha1}
}
Ejemplo 23–9 Configuración de un sistema con una NAT con IPsec

En el ejemplo siguiente, una autoridad de certificación ha emitido certificados raíz y los ha colocado en el sistema portátil y el sistema central. mobile1 se conecta a la oficina central de la compañía desde casa. La red del proveedor de servicios de Internet (ISP) utiliza un enrutador NAT para permitir al ISP asignar a mobile1 una dirección privada. A continuación, el enrutador convierte la dirección privada en una dirección IP pública que comparte con otros nodos de red del ISP. La oficina central de la compañía no está detrás de un dispositivo NAT. Para configurar el sistema en las oficinas de la empresa, consulte el Ejemplo 23–8.


## /etc/hosts on mobile1
mobile1 10.1.3.3
main1 192.168.0.100
 

## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
 

## /etc/inet/ike/ike.config on mobile1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.domain.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.domain.org,ldap2.domain.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI"
#
# Rule for off-site systems with root certificate
{
  label "Off-site mobile1 with root certificate"
  local_id_type DNS
  local_id "mobile1.domain.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the root certificate
  remote_id "main1.domain.org"
  remote_addr 192.168.0.100

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}
Ejemplo 23–10 Aceptación de certificados autofirmados de un sistema portátil

En el ejemplo siguiente, se han emitido certificados autofirmados y se encuentran en el sistema portátil y el sistema central. main1 es el sistema de la compañía que puede aceptar conexiones desde sistemas remotos. Para configurar los sistemas que no estén en las oficinas, consulte el Ejemplo 23–11.


## /etc/hosts on main1
main1 192.168.0.100
 

## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
 

## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Self-signed certificates - trust me and enumerated others
cert_trust    "DNS=main1.domain.org"
cert_trust    "jdoe@domain.org"
cert_trust    "user2@domain.org"
cert_trust    "user3@domain.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site systems with trusted certificates"
  local_id_type DNS
  local_id "main1.domain.org"
  local_addr 192.168.0.100

# Trust the self-signed certificates
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}
Ejemplo 23–11 Uso de certificados autofirmados para contactar con un sistema central

En el ejemplo siguiente, mobile1 se conecta a la oficina central de la compañía desde casa. Los certificados se han emitido y se colocan en el sistema portátil y el sistema central. La red ISP utiliza un enrutador NAT para permitir al ISP asignar a mobile1 una dirección privada. A continuación, el enrutador convierte la dirección privada en una dirección IP pública que comparte con otros nodos de red del ISP. La oficina central de la compañía no está detrás de un dispositivo NAT. Para configurar el sistema en las oficinas de la empresa, consulte el Ejemplo 23–10.


## /etc/hosts on mobile1
mobile1 10.1.3.3
main1 192.168.0.100
 

## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
 

## /etc/inet/ike/ike.config on mobile1
# Global parameters

# Self-signed certificates - trust me and the central system
cert_trust    "jdoe@domain.org"
cert_trust    "DNS=main1.domain.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site mobile1 with trusted certificate"
  local_id_type email
  local_id "jdoe@domain.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the certificate
  remote_id "main1.domain.org"
  remote_addr 192.168.0.100

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

Configuración de IKE para buscar el hardware conectado (mapa de tareas)

La tabla siguiente incluye los procedimientos que indican a IKE el hardware conectado. Debe informar a IKE del hardware conectado para que pueda utilizarlo. Para utilizar el hardware, siga los procedimientos de Configuración de IKE con certificados de clave pública .

Nota –

No tiene que informar a IKE sobre el hardware en chip. Por ejemplo, el procesador UltraSPARC® T2 proporciona aceleración criptográfica. No es necesario configurar IKE para encontrar los aceleradores en chip.

Tarea 

Descripción 

Para obtener instrucciones 

Descargar operaciones de claves IKE en la placa de Sun Crypto Accelerator 1000 

Vincula IKE con la biblioteca de PKCS #11. 

Cómo configurar IKE para buscar la placa de Sun Crypto Accelerator 1000

Descargar operaciones de claves IKE y almacenar las claves en la placa de Sun Crypto Accelerator 4000 

Vincula IKE con la biblioteca de PKCS #11 e indica el nombre del hardware conectado. 

Cómo configurar IKE para buscar la placa de Sun Crypto Accelerator 4000

Configuración de IKE para buscar el hardware conectado

Los certificados de claves públicas también se pueden almacenar en el hardware adjunto. La placa Sun Crypto Accelerator 1000 sólo proporciona almacenamiento. Las placas Sun Crypto Accelerator 4000 y Crypto Accelerator 6000 de Sun proporcionan almacenamiento y permiten que se descarguen operaciones de claves públicas desde el sistema a la placa.

ProcedureCómo configurar IKE para buscar la placa de Sun Crypto Accelerator 1000

Antes de empezar

El procedimiento siguiente presupone que hay una placa de Sun Crypto Accelerator 1000 conectada al sistema. Además, el procedimiento presupone que se ha instalado y configurado el software para la placa. Para obtener instrucciones, consulte Sun Crypto Accelerator 1000 Board Version 2.0 Installation and User’s Guide.

  1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

    Nota –

    El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

  2. Compruebe que esté vinculada la biblioteca de PKCS #11.

    Escriba el comando siguiente para determinar si la biblioteca de PKCS #11 está vinculada:


    # ikeadm get stats
Phase 1 SA counts:
Current:   initiator:          0   responder:          0
Total:     initiator:          0   responder:          0
Attempted: initiator:          0   responder:          0
Failed:    initiator:          0   responder:          0
           initiator fails include 0 time-out(s)
PKCS#11 library linked in from /usr/lib/libpkcs11.so
#

  3. Solaris 10 1/06: A partir de esta versión, puede guardar las claves en el almacén de claves softtoken.

    Para obtener información sobre el almacén de claves que proporciona la estructura criptográfica de Solaris, consulte la página del comando man cryptoadm(1M) Si desea ver un ejemplo del uso del almacén de claves, consulte el Example 23–12.

ProcedureCómo configurar IKE para buscar la placa de Sun Crypto Accelerator 4000

Antes de empezar

El siguiente procedimiento presupone que hay una placa de Sun Crypto Accelerator 4000 conectada al sistema. Además, el procedimiento presupone que se ha instalado y configurado el software para la placa. Para obtener instrucciones, consulte la Sun Crypto Accelerator 4000 Board Version 1.1 Installation and User’s Guide.

Si utiliza una placa Crypto Accelerator 6000 de Sun, consulte la Sun Crypto Accelerator 6000 Board Version 1.1 User’s Guide para obtener instrucciones.

  1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

    Nota –

    El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

  2. Compruebe que esté vinculada la biblioteca de PKCS #11.

    IKE utiliza las rutinas de la biblioteca para administrar la generación de claves y el almacenamiento de claves en la placa de Sun Crypto Accelerator 4000. Escriba el comando siguiente para determinar si se ha vinculado una biblioteca de PKCS #11:


    $ ikeadm get stats
…
PKCS#11 library linked in from /usr/lib/libpkcs11.so
$
    Nota –

    La placa Sun Crypto Accelerator 4000 admite claves de hasta 2048 bits para RSA. Para DSA, esta placa admite claves de hasta 1024 bits.

  3. Busque el ID de símbolo para la placa de Sun Crypto Accelerator 4000 conectada.


    $ ikecert tokens
Available tokens with library "/usr/lib/libpkcs11.so":

"Sun Metaslot                     "

    La biblioteca devuelve un ID de símbolo, también denominado nombre de keystore, de 32 caracteres. En este ejemplo, puede utilizar el símbolo Sun Metaslot con los comandos ikecert para almacenar y acelerar claves IKE.

    Para obtener instrucciones sobre cómo utilizar el símbolo, consulte Cómo generar y almacenar certificados de clave pública en el hardware.

    Los espacios finales se rellenan automáticamente con el comando ikecert.

Ejemplo 23–12 Búsqueda y uso de símbolos de metarranura

Los símbolos se pueden almacenar en el disco, en una placa conectada o en el almacén de claves softtoken que proporciona la estructura de cifrado de Solaris. El ID de símbolo del almacén de claves softtoken podría ser similar al siguiente.


$ ikecert tokens
Available tokens with library "/usr/lib/libpkcs11.so":

"Sun Metaslot                   "

Para crear una contraseña para el almacén de claves softtoken, consulte la página del comando man pktool(1).

Un comando como el siguiente agregaría un certificado al almacén de claves softtoken. Sun.Metaslot.cert es un archivo que contiene un certificado de una autoridad de certificación.


# ikecert certdb -a -T "Sun Metaslot" < Sun.Metaslot.cert
Enter PIN for PKCS#11 token: Type user:passphrase

Cambio de los parámetros de transmisión de IKE (mapa de tareas)

En la tabla siguiente se incluyen los procedimientos para configurar los parámetros de transmisión para IKE.

Tarea 

Descripción 

Para obtener instrucciones 

Hacer la negociación de claves más eficiente 

Cambia los parámetros de negociación de claves. 

Cómo cambiar la duración de la negociación de claves IKE de fase 1

Configurar la negociación de claves para permitir retrasos en la transmisión 

Alarga los parámetros de negociación de claves. 

Ejemplo 23–13

Configurar la negociación de claves para proceder con rapidez si es correcta o para mostrar los fallos rápidamente 

Acorta los parámetros de negociación de claves. 

Ejemplo 23–14

Cambio de los parámetros de transmisión de IKE

Cuando IKE negocia claves, la velocidad de transmisión puede afectar al éxito de la negociación. Normalmente, no necesita cambiar los valores predeterminados de los parámetros de transmisión de IKE. Sin embargo, al optimizar la negociación de claves con líneas muy codificadas o al reproducir un problema, puede cambiar los valores de transmisión.

Un tiempo más prolongado permite a IKE negociar claves en líneas de transmisión poco fiables. Puede alargar determinados parámetros para que los intentos iniciales tengan éxito. Si el intento inicial no tiene éxito, puede espaciar los siguientes intentos para que haya más tiempo.

Un tiempo más breve permite aprovechar las líneas de transmisión fiables. Puede reintentar una negociación fallida con mayor rapidez para acelerar la negociación. Al diagnosticar un problema, es posible que también desee acelerar la negociación para un fallo rápido. Un tiempo más breve también permite utilizar las SA de la fase 1.

ProcedureCómo cambiar la duración de la negociación de claves IKE de fase 1

  1. En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.

    La función de administrador principal incluye el perfil de administrador principal. Para crear el rol y asignarlo a un usuario, consulte el Capítulo 2, Working With the Solaris Management Console (Tasks) de System Administration Guide: Basic Administration.

    Nota –

    El inicio de sesión remoto expone el tráfico cuya seguridad es crítica a intrusos. Aunque proteja de algún modo el inicio de sesión remoto, la seguridad del sistema se reducirá a la seguridad de la sesión remota. Utilice el comando ssh para un inicio de sesión remota seguro.

  2. Cambie los valores predeterminados de los parámetros de transmisión globales de cada sistema.

    En cada sistema, modifique los parámetros de duración de la fase 1 del archivo /etc/inet/ike/config.


    ### ike/config file on system

## Global parameters
#
## Phase 1 transform defaults
#
#expire_timer      300
#retry_limit         5
#retry_timer_init    0.5 (integer or float)
#retry_timer_max    30   (integer or float)
    expire_timer

    Número de segundos que persistirá una negociación de IKE de fase 1 sin completar antes de eliminar el intento de negociación. De modo predeterminado, el intento persiste durante 30 segundos.

    retry_limit

    El número de retransmisiones antes de que se cancele cualquier negociación de IKE. De modo predeterminado, hay cinco intentos de IKE.

    retry_timer_init

    Intervalo inicial entre retransmisiones. Este intervalo se dobla hasta alcanzar el valor de retry_timer_max. El intervalo inicial es de 0,5 segundos.

    retry_timer_max

    El intervalo máximo en segundos entre retransmisiones. El intervalo de retransmisión deja de aumentar una vez alcanzado este límite. De modo predeterminado, el limite es de 30 segundos.

  3. Lea la configuración que ha cambiado en el núcleo.

    • A partir de la versión Solaris 10 4/09 actualice el ike. 


      # svcadm refresh svc:/network/ipsec/ike

    • Si está ejecutando una versión anterior a Solaris 10 4/09 reinicie el sistema. 


      # init 6

      También puede detener e iniciar el daemon in.iked.

Ejemplo 23–13 Cómo alargar el tiempo de negociación de IKE de fase 1

En el ejemplo siguiente, un sistema se conecta a sus equivalentes IKE mediante una línea de transmisión de alta densidad de tráfico. Los parámetros originales se encuentran en los comentarios del archivo. Los nuevos parámetros alargan el tiempo de negociación.


### ike/config file on partym
## Global Parameters
#
## Phase 1 transform defaults
#expire_timer   300
#retry_limit      5
#retry_timer_init 0.5 (integer or float)
#retry_timer_max 30   (integer or float)
#
expire_timer  600
retry_limit  10
retry_timer_init  2.5
retry_timer_max  180
Ejemplo 23–14 Cómo acortar el tiempo de negociación de IKE de fase 1

En el ejemplo siguiente, un sistema se conecta a sus equivalentes IKE mediante una línea de alta velocidad con poca densidad de tráfico. Los parámetros originales se encuentran en los comentarios del archivo. Los nuevos parámetros acortan el tiempo de negociación.


### ike/config file on partym
## Global Parameters
#
## Phase 1 transform defaults
#expire_timer   300
#retry_limit      5
#retry_timer_init 0.5 (integer or float)
#retry_timer_max 30   (integer or float)
#
expire_timer  120
retry_timer_init  0.20

Capítulo 24 Intercambio de claves de Internet (referencia)

Este capítulo contiene la siguiente información de referencia sobre IKE:

Para obtener instrucciones sobre la implementación de IKE, consulte el Capítulo 23Configuración de IKE (tareas). Para obtener una descripción general, consulte el Capítulo 22Intercambio de claves de Internet (descripción general).

Utilidad de gestión de servicios de IKE

svc:/network/ipsec/ike:default servicio – la utilidad de administración de servicios (SMF) proporciona el servicio ike para administrar IKE. Por defecto, este servicio está inhabilitado. Antes de habilitar este servicio, debe crear un archivo de configuración IKE, archivo /etc/inet/ike/config.

las siguientes propiedades del servicio ike son configurables:

Para obtener más información sobre SMF, consulte el Capítulo 18, Managing Services (Overview) de System Administration Guide: Basic Administration. Consulte también las páginas de comando man smf(5),svcadm(1M) y svccfg(1M).

Daemon IKE

El daemon in.iked automatiza la administración de claves criptográficas para IPsec en un sistema Solaris. El daemon negocia con un sistema remoto que ejecuta el mismo protocolo para proporcionar materiales de claves autenticados para las asociaciones de seguridad de forma protegida. El daemon debe ejecutarse en todos los sistemas que tienen previsto comunicarse de forma segura.

Por defecto, el servicio svc:/network/ipsec/ike:default servicio no está habilitado. Después de que se haya configurado el archivo /etc/inet/ike/config y se haya habilitado el servicio ike, el daemon in.iked se ejecuta con el inicio del sistema.

Al ejecutar el daemon IKE, el sistema se autentica automáticamente en su entidad IKE equivalente en el intercambio de fase 1. El equivalente se define en el archivo de directiva IKE, al igual que los métodos de autenticación. A continuación, el daemon establece las claves para el intercambio de fase 2. Las claves IKE se actualizan automáticamente a un intervalo especificado en el archivo de directiva. El daemon in.iked escucha las solicitudes IKE entrantes de la red y las solicitudes del tráfico saliente mediante el socket PF_KEY. Para más información, consulte la página del comando man pf_key(7P).

Dos comandos admiten el daemon IKE. El comando ikeadm puede utilizarse para ver y modificar temporalmente la directiva IKE. Para modificar permanentemente la directiva IKE, puede modificar las propiedades del servicio ike. Si desea conocer el procedimiento, consulte Cómo ver las claves IKE previamente compartidas.

El comando ikecert permite ver y administrar las bases de datos de claves públicas. Este comando administra las bases de datos locales, ike.privatekeys y publickeys . Este comando también administra operaciones de claves públicas y el almacenamiento de las claves públicas en el hardware.

Archivo de directiva IKE

El archivo de configuración para la directiva IKE, /etc/inet/ike/config , administra las claves para las interfaces que está protegiendo el archivo de directiva IPsec, /etc/inet/ipsecinit.conf. El archivo de directiva IKE administra claves para IKE y para las asociaciones de seguridad de IPsec. El daemon IKE requiere material de claves en el intercambio de fase 1.

La administración de claves con IKE incluye reglas y parámetros globales. Una regla IKE identifica los sistemas o redes que protege el material de claves. La regla también especifica el método de autenticación. Los parámetros globales incluyen elementos como la ruta a un acelerador de hardware conectado. Para ver ejemplos de los archivos de directiva IKE, consulte Configuración de IKE con claves previamente compartidas (mapa de tareas). Para ver ejemplos y descripciones de las entradas de directiva IKE, consulte la página del comando man ike.config(4).

Las asociaciones de seguridad de IPsec que admite IKE protegen los datagramas IP de acuerdo con las directivas que se establecen en el archivo de configuración para la directiva IPsec, /etc/inet/ipsecinit.conf. El archivo de directiva IKE determina si se utiliza la seguridad directa perfecta (PFS) al crear las asociaciones de seguridad de IPsec.

El archivo ike/config puede incluir la ruta a una biblioteca que se implementa de acuerdo con el estándar siguiente: Interfaz de señal criptográfica RSA Security Inc. PKCS #11 (Cryptoki). IKE utiliza esta biblioteca de PKCS #11 con tal de acceder al hardware para la aceleración de claves y el almacenamiento de claves.

Las consideraciones de seguridad del archivo ike/config son similares a las consideraciones del archivo ipsecinit.conf. Para obtener más información, consulte Consideraciones de seguridad para ipsecinit.conf e ipsecconf.

Comando de administración de IKE

Puede utilizar el comando ikeadm para:

Para ver ejemplos y una descripción completa de las opciones de este comando, consulte la página del comando man ikeadm(1M)

El nivel de privilegio del daemon IKE en ejecución determina qué aspectos del daemon IKE pueden verse y modificarse. Hay tres niveles de privilegio posibles.

Nivel Base

No puede ver ni modificar el material de claves. El nivel base es el nivel de privilegio predeterminado.

Nivel modkeys

Puede eliminar, cambiar y agregar claves previamente compartidas.

Nivel keymat

Puede ver el material de claves real con el comando ikeadm.

Si desea un cambio en un privilegio temporal, puede utilizar el comando ikeadm. Para un cambio permanente, cambie la propiedad admin_privilege del servicio ike. Si desea conocer el procedimiento, consulte Cómo administrar servicios de IPsec e IKE .

Las consideraciones de seguridad del comando ikeadm son similares a las consideraciones del comando ipseckey. Para más detalles, consulte Consideraciones de seguridad para ipseckey.

Archivos de claves IKE previamente compartidas

Al crear manualmente claves previamente compartidas, las claves se almacenan en archivos del directorio /etc/inet/secret. El archivo ike.preshared contiene las claves previamente compartidas para las asociaciones de seguridad del protocolo de administración de claves y asociaciones de seguridad de Internet (ISAKMP). El archivo ipseckeys contiene las claves previamente compartidas para las asociaciones de seguridad de IPsec. Los archivos se protegen en 0600. El directorio secret se protege en 0700.

Nota –

Las claves previamente compartidas no pueden utilizar el almacenamiento de hardware. Las claves previamente compartidas se generan y almacenan en el sistema.

Comandos y bases de datos de claves públicas IKE

El comando ikecert administra las bases de datos de claves públicas del sistema local. Este comando se utiliza cuando el archivo ike/config requiere certificados de claves públicas. Dado que IKE utiliza estas bases de datos para autenticar el intercambio de fase 1, las bases de datos deben rellenarse antes de activar el daemon in.iked. Existen tres subcomandos que administran las tres bases de datos: certlocal, certdb y certrldb.

El comando ikecert también administra el almacenamiento de claves. Las claves se pueden almacenar en disco, en una placa Sun Crypto Accelerator 4000 o Crypto Accelerator 6000 de Sun, o bien en un almacén de claves softtoken. El almacén de claves softtoken está disponible cuando la metarranura de la estructura criptográfica de Solaris se utilice para comunicarse con el dispositivo de hardware. El comando ikecert utiliza la biblioteca PKCS #11 para localizar el almacenamiento de claves.

Para obtener más información, consulte la página del comando man ikecert(1M) Para obtener información sobre la metarranura y el almacén de claves softtoken, consulte la página del comando man cryptoadm(1M).

Comando ikecert tokens

El argumento tokens enumera los ID de testigo que están disponibles. Los ID de símbolo permiten a los comandos ikecert certlocal e ikecert certdb generar certificados de claves públicas y solicitudes de certificados. Las certificados y las solicitudes de certificados también se pueden almacenar mediante la estructura criptográfica del almacén de claves softtoken, o bien en una placa Sun Crypto Accelerator 4000 o Crypto Accelerator 6000 de Sun. El comando ikecert utiliza la biblioteca PKCS #11 para localizar el almacenamiento de certificados.

Comando ikecert certlocal

El subcomando certlocal administra la base de datos de claves privadas. Las opciones de este subcomando permiten agregar, ver y eliminar claves privadas. Este subcomando también crea un certificado autofirmado o una solicitud de certificado. La opción -ks crea un certificado autofirmado. La opción -kc crea una solicitud de certificado. Las claves se almacenan en el directorio /etc/inet/secret/ike.privatekeys del sistema o en el hardware conectado con la opción -T.

Al crear una clave privada, las opciones del comando ikecert certlocal deben tener entradas relacionadas en el archivo ike/config. La tabla siguiente muestra las correspondencias entre las opciones ikecert y las entradas ike/config.

Tabla 24–1 Correspondencias entre las opciones ikecert y las entradas ike/config

Opción ikecert

Entrada ike/config

Descripción 

-A nombre_alternativo_tema

cert_trust nombre_alternativo_tema

Apodo que identifica el certificado de modo exclusivo. Los posibles valores son una dirección IP, una dirección de correo electrónico o un nombre de dominio. 

-D nombre_distinguido_X.509

nombre_distinguido_X.509

El nombre completo de la autoridad de certificación que incluye el país (C), el nombre de organización (ON), la unidad organizativa (OU) y el nombre común (CN). 

-t dsa-sha1

auth_method dss_sig

Método de autenticación que es ligeramente más lento que RSA.

-t rsa-md5 y

-t rsa-sha1

auth_method rsa_sig

Método de autenticación que es ligeramente más lento que DSA.

La clave pública RSA debe ser lo suficientemente grande para cifrar la carga útil mayor. Normalmente, una carga útil de identidad, como el nombre distinguido X.509, es la mayor carga útil.

-t rsa-md5 y

-t rsa-sha1

auth_method rsa_encrypt

El cifrado RSA oculta las identidades de IKE de los intrusos, pero requiere que los equivalentes de IKE conozcan las claves públicas el uno del otro. 

-T

pkcs11_path

La biblioteca PKCS #11 gestiona aceleración de claves en las placas de Sun Crypto Accelerator 1000, Crypto Accelerator 6000 de Sun y Sun Crypto Accelerator 4000. La biblioteca también proporciona los símbolos que gestionan el almacenamiento de claves en las placas de Sun Crypto Accelerator 4000 y Crypto Accelerator 6000 de Sun.

Si emite una solicitud de certificado con el comando ikecert certlocal -kc, envía el resultado del comando a una organización de PKI o a una autoridad de certificación. Si su compañía ejecuta su propio PKI, el resultado se envía al administrador de PKI. A continuación, la organización de PKI, la autoridad de certificación o el administrador de PKI crea los certificados. Los certificados que devuelve el PKI o la autoridad de certificación se incluyen en el subcomando certdb. La lista de revocación de certificados (CRL) que devuelve el PKI se incluye en el subcomando certrldb.

Comando ikecert certdb

El subcomando certdb administra la base de datos de claves públicas. Las opciones de este subcomando permiten agregar, ver y eliminar certificados y claves públicas. El comando acepta como entrada los certificados generados con el comando ikecert certlocal -ks en un sistema remoto. Para conocer el procedimiento, consulte Cómo configurar IKE con certificados de clave pública autofirmados. Este comando también acepta el certificado que recibe de un PKI o una autoridad de certificación. Para conocer el procedimiento, consulte Cómo configurar IKE con certificados firmados por una autoridad de certificación.

Los certificados y las claves públicas se almacenan en el directorio /etc/inet/ike/publickeys del sistema. La opción -T almacena los certificados, las claves privadas y las claves públicas del hardware conectado.

Comando ikecert certrldb

El subcomando certrldb administra la base de datos de listas de revocación de certificados (CRL), /etc/inet/ike/crls. La base de datos de CRL mantiene las listas de revocación para las claves públicas. En esta lista se incluyen los certificados que dejan de ser válidos. Cuando los PKI proporcionan una CRL, puede instalar la CRL en la base de datos de CRL con el comando ikecert certrldb. Para conocer el procedimiento, consulte Cómo administrar una lista de revocación de certificados.

Directorio /etc/inet/ike/publickeys

El directorio /etc/inet/ike/publickeys contiene la parte pública de un par de claves pública-privada y su certificado en los archivos, o ranuras. El directorio se protege en 0755 . El comando ikecert certdb rellena el directorio. La opción -T almacena las claves en la placa Sun Crypto Accelerator 4000 o Crypto Accelerator 6000 de Sun en lugar del directorio publickeys.

Las ranuras contienen, de modo codificado, el nombre distinguido X.509 de un certificado generado en otro sistema. Si está utilizando certificados autofirmados, se utiliza el certificado que se recibe del administrador del sistema remoto como entrada del comando. Si está utilizando certificados de una entidad certificadora (CA), puede instalar dos certificados firmados de ésta en la base de datos. Se instala un certificado que está basado en la solicitud de firma de certificado que envió a la entidad certificadora (CA). También se instala un certificado de la entidad certificadora (CA).

Directorio /etc/inet/secret/ike.privatekeys

El directorio /etc/inet/secret/ike.privatekeys contiene archivos de claves privadas que forman parte del par de claves pública-privada, que constituye material de claves para las asociaciones de seguridad de ISAKMP. El directorio se protege en 0700. El comando ikecert certlocal rellena el directorio ike.privatekeys. Las claves privadas no son efectivas hasta que se instalan sus equivalentes de claves públicas, certificados autofirmados o autoridades de certificación. Los equivalentes de claves públicas se almacenan en el directorio /etc/inet/ike/publickeys o en una placa &sca 4; o Crypto Accelerator 6000 de Sun.

Directorio /etc/inet/ike/crls

El directorio /etc/inet/ike/crls contiene archivos de lista de revocación de certificados (CRL). Cada archivo corresponde a un archivo de certificado público del directorio /etc/inet/ike/publickeys. Las organizaciones de PKI proporcionan las CRL para sus certificados. Puede utilizar el comando ikecert certrldb para rellenar la base de datos.

Capítulo 25 Filtro IP de Oracle Solaris (descripción general)

Este capítulo proporciona una descripción general del filtro IP de Oracle Solaris. Para informarse sobre las tareas del filtro IP de Oracle Solaris, consulte el Capítulo 26Filtro IP de Oracle Solaris (tareas).

Este capítulo contiene la información siguiente:

Novedades del filtro IP de Oracle Solaris

En esta sección se describen las nuevas funciones del filtro IP de Oracle Solaris.

Para ver una lista completa de las nuevas funciones de y una descripción de las versiones de Oracle Solaris, consulte Novedades de Oracle Solaris 10 9/10

Enlaces de filtros de paquetes

A partir de la versión Solaris 10 7/07: se usan enlaces de filtros de paquetes para filtrado de paquetes en Oracle Solaris. Esta función ofrece las siguientes ventajas en lo que se refiere a la administración del sistema:

Para obtener más información sobre estos enlaces, consulte Enlaces de filtros de paquetes. Para conocer las tareas asociadas con los enlaces de filtros de paquetes, consulte el Capítulo 26Filtro IP de Oracle Solaris (tareas).

Filtros de paquetes IPv6 para el filtro IP de Oracle Solaris

Solaris 10 6/06: Para los administradores de sistemas que han configurado parte o toda la infraestructura de red con IPv6, se ha mejorado el filtro IP de Oracle Solaris para que incluya filtros de paquetes IPv6. Los filtros de paquetes IPv6 pueden filtrar basándose en la dirección IPv6 de origen o destino, agrupaciones con direcciones IPv6 y encabezados de extensiones IPv6.

Se ha agregado la opción -6 a los comandos ipf e ipfstat para utilizar con IPv6. Aunque no se ha modificado la interfaz de la línea de comandos para los comandos ipmon e ippool, estos comandos también admiten IPv6. Se ha mejorado el comando ipmon para admitir el registro de paquetes IPv6, y el comando ippool admite la inclusión de direcciones IPv6 en las agrupaciones.

Para obtener más información, consulte IPv6 para el filtro IP de Oracle Solaris. Si desea conocer las tareas asociadas con los filtros de paquetes IPv6, consulte el Capítulo 26Filtro IP de Oracle Solaris (tareas).

Introducción al filtro IP de Oracle Solaris

El filtro IP de Oracle Solaris sustituye a SunScreen como software de cortafuegos para Oracle Solaris. Al igual que el cortafuegos de SunScreen, el filtro IP de Oracle Solaris proporciona filtros de paquetes con estado y traducción de direcciones de red (NAT). El filtro IP de Oracle Solaris también incluye filtrado de paquetes sin estado y la posibilidad de crear y administrar agrupaciones de direcciones.

Los filtros de paquetes ofrecen protección básica contra ataques de la red. El filtro IP de Oracle Solaris puede filtrar por dirección IP, puerto, protocolo, interfaz de red y dirección de tráfico. El filtro IP de Oracle Solaris también puede filtrar por dirección IP de origen individual, dirección IP de destino, por intervalo de direcciones IP o por agrupaciones de direcciones.

El filtro IP de Oracle Solaris se deriva de software de filtro IP de código abierto. Para ver las condiciones de la licencia, las atribuciones y los copyrights para el filtro IP de código abierto, la ruta predeterminada es /usr/lib/ipf/IPFILTER.LICENCE. Si se ha instalado Oracle Solaris en una ubicación que no sea la predeterminada, modifique la ruta para acceder al archivo en la ubicación correcta.

Fuentes de información para el filtro IP de código abierto

Encontrará la página de inicio del software de filtro IP de código abierto de Darren Reed en http://coombs.anu.edu.au/~avalon/ip-filter.html. Este sitio incluye información para el filtro IP de código abierto, incluido un vínculo a un tutorial llamado "IP Filter Based Firewalls HOWTO" (Brendan Conoboy y Erik Fichtner, 2002). Este tutorial incluye instrucciones paso a paso para configurar cortafuegos en un entorno BSD UNIX. Aunque el tutorial se ha escrito para un entorno BSD UNIX, también es necesario para la configuración del filtro IP de información de Oracle Solaris.

Procesamiento de paquetes del filtro IP de Oracle Solaris

El filtro IP de Oracle Solaris ejecuta una secuencia de pasos cuando se procesa un paquete. El diagrama siguiente ilustra los pasos del procesamiento de paquetes y el modo en que los filtros se integran con la pila de protocolo TCP/IP.

Figura 25–1 Secuencia de procesamiento de paquetes

Muestra la secuencia de pasos asociados con el procesamiento de paquetes del filtro IP de Oracle Solaris.

La secuencia de procesamiento de paquetes incluye:

Directrices para utilizar el filtro IP de OpenSolaris

Uso de los archivos de configuración del filtro IP de OpenSolaris

El filtro IP de Oracle Solaris puede utilizarse para proporcionar servicios de cortafuegos o traducción de direcciones de red (NAT). El filtro IP de Oracle Solaris se puede implementar utilizando archivos de configuración que se puedan cargar. El filtro IP de Oracle Solaris incluye un directorio denominado /etc/ipf. Puede crear y guardar archivos de configuración denominados ipf.conf, ipnat.conf e ippool.conf en el directorio /etc/ipf. Estos archivos se cargan automáticamente durante el proceso de inicio cuando residen en el directorio /etc/ipf. También puede guardar los archivos de configuración en otra ubicación y cargarlos manualmente. Para ver ejemplos de archivos de configuración, consulte Creación y edición de archivos de configuración del filtro IP de Oracle Solaris.

Conjuntos de reglas del filtro IP de Oracle Solaris

Para administrar el cortafuegos, utilice el filtro IP de Oracle Solaris para especificar los conjuntos de reglas que se utilizarán para filtrar el tráfico de red. Puede crear los siguientes tipos de conjuntos de reglas:

Asimismo, puede crear agrupaciones de direcciones para hacer referencia a grupos de direcciones IP. Estas agrupaciones podrán utilizarse más adelante en un conjunto de reglas. Las agrupaciones de direcciones aceleran el procesamiento de reglas. Asimismo, facilitan la administración de agrupaciones de direcciones de gran tamaño.

Uso de la función de filtros de paquetes del filtro IP de Oracle Solaris

Los filtros de paquetes se configuran con los conjuntos de reglas de filtros de paquetes. Utilice el comando ipf para trabajar con conjuntos de reglas de filtros de paquetes. Para obtener más información sobre el comando ipf, consulte el comando ipf(1M).

Puede crear reglas de filtros de paquetes en la línea de comandos, utilizando el comando ipf, o en un archivo de configuración de filtros de paquetes. Si desea que las reglas de filtros de paquetes se carguen durante el inicio, cree un archivo de configuración denominado /etc/ipf/ipf.conf en el que colocar las reglas de filtros de paquetes. Si no desea que las reglas de filtros de paquetes se carguen durante el inicio, coloque el archivo ipf.conf en la ubicación que prefiera y active manualmente los filtros de paquetes utilizando el comando ipf.

Puede mantener dos conjuntos de reglas de filtros de paquetes con el filtro IP de Oracle Solaris: el conjunto de reglas activo y el conjunto de reglas inactivo. En la mayoría de los casos, se trabaja con el conjunto de reglas activo. Sin embargo, el comando ipf -I permite aplicar la acción del comando a la lista de reglas inactivas. El filtro IP de Oracle Solaris no utiliza la lista de reglas inactivas a menos que lo seleccione. La lista de reglas inactivas es un lugar donde guardar las reglas para que no afecten a los filtros de paquetes activos.

El filtro IP de Oracle Solaris procesa las reglas desde el principio de la lista de reglas configuradas hasta el final, antes de transferir o bloquear un paquete. El filtro IP de Oracle Solaris incluye un indicador que determina si se transferirá un paquete. Se aplica a todo el conjunto de reglas y determina si se pasará o bloqueará el paquete basándose en la última regla coincidente.

Existen dos excepciones para este proceso. La primera tiene lugar si el paquete coincide con una regla que contenga la palabra clave quick. Si una regla incluye la palabra clave quick, se lleva a cabo la acción de dicha regla y no se comprueban las reglas subsiguientes. La segunda excepción se produce si el paquete coincide con una regla que contenga la palabra clave group. Si un paquete coincide con un grupo, sólo se comprueban las reglas etiquetadas con el grupo.

Configuración de reglas de filtros de paquetes

Utilice la sintaxis siguiente para crear reglas de filtros de paquetes:

acción [in|out] opción palabra clave, palabra clave...

  1. Cada regla empieza por una acción. El filtro IP de Oracle Solaris aplica la acción al paquete si éste coincide con la regla. La lista siguiente incluye las acciones utilizadas comúnmente que se aplican a un paquete.

    block

    Impide que el paquete se transfiera a través del filtro.

    pass

    Permite que el paquete se transfiera a través del filtro.

    log

    Registra el paquete pero no determina si se bloquea o se transfiere. Utilice el comando ipmon para ver el registro.

    count

    Incluye el paquete en las estadísticas de filtro. Utilice el comando ipfstat para ver las estadísticas.

    skip número

    Hace que el filtro omita número reglas de filtros.

    auth

    Solicita la autenticación de paquetes por parte de un programa de usuario que valida la información de paquetes. El programa determina si el paquete se transferirá o se bloqueará.

    preauth

    Solicita que el filtro consulte una lista autenticada previamente para determinar la acción que se llevará a cabo con el paquete.

  2. Según la acción que se lleve a cabo, la siguiente palabra debe ser in o out. Su elección determina si la regla de filtro de paquetes se aplica a un paquete entrante o saliente.

  3. A continuación, puede elegir en una lista de opciones. Si utiliza más de una opción, debe hacerlo en el orden siguiente.

    log

    Registra el paquete si la regla es la última regla coincidente. Utilice el comando ipmon para ver el registro.

    quick

    Ejecuta la regla que contiene la opción quick si hay coincidencia de paquetes. Se detiene cualquier comprobación de reglas adicional.

    on nombre_interfaz

    Aplica la regla sólo si el paquete se transfiere a la interfaz especificada o desde ella.

    dup-to nombre_interfaz

    Copia el paquete y envía el duplicado de nombre_interfaz a una dirección IP especificada opcionalmente.

    to nombre_interfaz

    Transfiere el paquete a una cola de salida en nombre_interfaz.

  4. Una vez especificadas las opciones, puede elegir entre varias palabras clave que determinan si el paquete coincide con la regla. Las siguientes palabras clave deben utilizarse en el orden que se indica.

    Nota –

    De modo predeterminado, cualquier paquete que no coincida con ninguna regla en el archivo de configuración se transfiere a través del filtro.

    tos

    Filtra el paquete basándose en el valor de tipo de servicio expresado como entero decimal o hexadecimal.

    ttl

    Hace coincidir el paquete basándose en su valor de tiempo de vida. El valor de tiempo de vida que se guarda en un paquete indica el tiempo que puede permanecer un paquete en la red antes de que se descarte.

    proto

    Coincide con un protocolo específico. Puede utilizar cualquier nombre de protocolo especificado en el archivo /etc/protocols, o utilizar un número decimal para representar el protocolo. La palabra clave tcp/udp se puede utilizar para hacer coincidir un paquete TCP o UDP.

    from/to/all/ any

    Hace coincidir cualquiera o todos los elementos siguientes: la dirección IP de origen, la dirección IP de destino y el número de puerto. La palabra clave all se utiliza para aceptar paquetes de todos los orígenes y con todos los destinos.

    with

    Hace coincidir los atributos especificados asociados con el paquete. Inserte las palabras not o no delante de la palabra clave para que el paquete coincida sólo si no está presente la opción.

    flags

    Se utiliza para que TCP filtra basándose en los indicadores TCP configurados. Para obtener más información sobre los indicadores TCP, consulte la página del comando man ipf(4).

    icmp-type

    Filtra de acuerdo con el tipo de ICMP. Esta palabra clave sólo se utiliza cuando la opción proto se configura como icmp y no se utiliza si se usa la opción flags.

    keep opciones_guardado

    Determina la información que se guarda para un paquete. Las opciones_guardado disponibles incluyen las opciones state y frags. La opción state guarda información sobre la sesión y se puede guardar en paquetes TCP, UDP e ICMP. La opción frags guarda información sobre los fragmentos de paquetes y la aplica a fragmentos posteriores. opciones_guardado permite la transferencia de los paquetes coincidentes sin pasar por la lista de control de acceso.

    head número

    Crea un grupo para las reglas de filtros, que se indica mediante el número número.

    group número

    Agrega la regla al número de grupo número en lugar de agregarla al grupo predeterminado. Todas las reglas de filtros se colocan en el grupo 0 si no se especifica otro.

El ejemplo siguiente ilustra cómo agrupar la sintaxis de reglas de filtros de paquetes para crear una regla. Para bloquear el tráfico entrante de la dirección IP 192.168.0.0/16, debe incluir la siguiente regla en la lista:


block in quick from 192.168.0.0/16 to any

Para ver la gramática y sintaxis completa que se utiliza para escribir reglas de filtros de paquetes, consulte la página del comando man ipf(4) Para conocer las tareas asociadas con los filtros de paquetes, consulte Administración de conjuntos de reglas de filtros de paquetes para el filtro IP de Oracle Solaris. Para ver una explicación del esquema de direcciones IP (192.168.0.0/16) de este ejemplo, consulte el Capítulo 2Planificación de la red TCP/IP (tareas).

Uso de la función NAT del filtro IP de Oracle Solaris

NAT establece las reglas de asignación que traducen las direcciones IP de origen y destino en otras direcciones de Internet o intranet. Estas reglas modifican las direcciones de origen y destino de los paquetes IP entrantes o salientes y envían los paquetes. También puede utilizar NAT para redirigir el tráfico de un puerto a otro. NAT mantiene la integridad del paquete durante cualquier modificación o redirección que se lleve a cabo en el paquete.

Utilice el comando ipnat para trabajar con listas de reglas NAT. Para obtener más información sobre el comando ipnat, consulte el comando ipnat(1M).

Puede crear reglas NAT en la línea de comandos, utilizando el comando ipnat, o en un archivo de configuración de NAT. Las reglas de configuración de NAT residen en el archivo ipnat.conf. Si desea que las reglas NAT se carguen durante el inicio, cree un archivo denominado /etc/ipf/ipnat.conf en el que colocar las reglas NAT. Si no desea que las reglas NAT se carguen durante el inicio, coloque el archivo ipnat.conf en la ubicación que prefiera y active manualmente los filtros de paquetes utilizando el comando ipnat.

Configuración de reglas NAT

La sintaxis siguiente permite crear reglas NAT:

comando nombre_interfaz parámetros

  1. Cada regla empieza con uno de los comandos siguientes:

    map

    Asigna una red o dirección IP a otra red o dirección IP en un proceso por turnos.

    rdr

    Redirige los paquetes de una dirección IP y un par de puertos a otra dirección IP y otro par de puertos.

    bimap

    Establece una NAT bidireccional entre una dirección IP externa y una dirección IP interna.

    map-block

    Establece una traducción basada en una dirección IP estática. Este comando se basa en un algoritmo que fuerza la traducción de las direcciones en un intervalo de destino.

  2. Después del comando, la siguiente palabra es el nombre de la interfaz, por ejemplo hme0.

  3. A continuación, puede elegir entre una serie de parámetros, que determinan la configuración de NAT. Algunos de los parámetros son:

    ipmask

    Designa la máscara de red.

    dstipmask

    Designa la dirección a la que se traduce ipmask.

    mapport

    Designa los protocolos tcp, udp o tcp/udp, junto con una serie de números de puerto.

El ejemplo siguiente muestra cómo agrupar la sintaxis de reglas NAT para crear una regla NAT. Para volver a escribir un paquete saliente en el dispositivo de0 con una dirección de origen de 192.168.1.0/24 y mostrar externamente su dirección de origen como 10.1.0.0/16, debe incluir la siguiente regla en el conjunto de reglas NAT:


map de0 192.168.1.0/24 -> 10.1.0.0/16

Para ver la gramática y sintaxis completa que se utilizan para escribir las reglas NAT, consulta la página del comando man ipnat(4).

Uso de la función de agrupaciones de direcciones del filtro IP de Oracle Solaris

Las agrupaciones de direcciones establecen una única referencia que se utiliza para asignar un nombre a un grupo de pares de direcciones/máscaras de red. Las agrupaciones de direcciones proporcionan los procesos para reducir el tiempo necesario para hacer coincidir las direcciones IP con las reglas. Asimismo, facilitan la administración de grupos de direcciones de gran tamaño.

Las reglas de configuración de agrupaciones de direcciones residen en el archivo ippool.conf. Si desea que las reglas de agrupaciones de direcciones se carguen durante el inicio, cree un archivo denominado /etc/ipf/ippool.conf en el que colocar las reglas de agrupaciones de direcciones. Si no desea que las reglas de agrupaciones de direcciones se carguen durante el inicio, coloque el archivo ippool.conf en la ubicación que prefiera y active manualmente los filtros de paquetes con el comando ippool.

Configuración de agrupaciones de direcciones

Utilice la sintaxis siguiente para crear una agrupación de direcciones:


table role = role-name type = storage-format number = reference-number
table

Define la referencia para las diferentes direcciones.

role

Especifica el rol de la agrupación en el filtro IP de Oracle Solaris. En este punto, el único rol al que se puede hacer referencia es ipf.

type

Especifica el formato de almacenamiento de la agrupación.

number

Especifica el número de referencia que utiliza la regla de filtros.

Por ejemplo, para hacer referencia al grupo de direcciones 10.1.1.1 y 10.1.1.2 y la red 192.16.1.0 como número de agrupación 13, debe incluir la siguiente regla en el archivo de configuración de agrupaciones de direcciones:

table role = ipf type = tree number = 13 
{ 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24 };

A continuación, para hacer referencia al número de agrupación 13 en una regla de filtros, debe estructurar la regla de un modo similar al siguiente:


pass in from pool/13 to any

Observe que debe cargar el archivo de agrupaciones antes de cargar el archivo de reglas que contiene una referencia a la agrupación. Si no lo hace, la agrupación no estará definida, como en el ejemplo siguiente:


# ipfstat -io
empty list for ipfilter(out)
block in from pool/13(!) to any

Aunque agregue la agrupación más adelante, no se actualizará el conjunto de reglas del núcleo. También necesita volver a cargar el archivo de reglas que hace referencia a la agrupación.

Para ver la gramática y sintaxis completas que se utilizan para escribir las reglas de filtros de paquetes, consulte la página del comando man ippool(4).

Enlaces de filtros de paquetes

A partir de la versión Solaris 10 7/07, los enlaces de filtros de paquetes reemplazan al módulo pfil para habilitar el filtro IP de Oracle Solaris. En versiones anteriores de Oracle Solaris, se requería la configuración del módulo pfil como paso adicional para configurar el filtro IP de Oracle Solaris. Este requisito de configuración adicional aumentaba el riesgo de errores que ocasionarían un funcionamiento incorrecto del filtro IP de Oracle Solaris. La inserción del módulo pfil STREAMS entre la dirección IP y el controlador de dispositivos también afectaba al rendimiento. Por último, el módulo pfil no podría interceptar paquetes entre zonas.

El uso de los enlaces de filtros de paquetes mejora el procedimiento para habilitar el filtro IP de Oracle Solaris. A través de estos enlaces, el filtro IP de Oracle Solaris utiliza bifurcaciones de filtros previas al enrutamiento (entrada) y posteriores al enrutamiento (salida) para controlar el flujo de paquetes que entran y salen del sistema Oracle Solaris.

Los enlaces de filtros de paquetes acaban con la necesidad del módulo pfil. Por tanto, también se eliminan los siguientes componentes asociados con el módulo.

Para conocer las tareas asociadas con la activación del filtro IP de Oracle Solaris, consulte el Capítulo 26Filtro IP de Oracle Solaris (tareas).

El filtro IP de Oracle Solaris y el módulo pfil STREAMS

Nota –

El módulo pfil se utiliza con el filtro IP de Oracle Solaris en las siguientes versiones de Oracle Solaris 10

A partir de Solaris 10 7/07, el módulo pfil se ha sustituido por los enlaces de filtros de paquetes y ya no se utiliza con el filtro IP de Oracle Solaris.

El módulo pfil STREAMS es necesario para habilitar el filtro IP de Oracle Solaris. Sin embargo, el filtro IP de Oracle Solaris no proporciona un mecanismo automático para utilizar el módulo en cada interfaz. En lugar de ello, el módulo pfil STREAMS lo administra el servicio SMF svc:/network/pfil. Para activar los filtros en una interfaz de red, primero debe configurar el archivo pfil.ap. A continuación, active el servicio svc:/network/pfil para proporcionar el módulo pfil STREAMS a la interfaz de red. Para que el módulo STREAMS surta efecto, es necesario reiniciar el sistema o desconectar y volver a sondear cada interfaz de red en la que desee aplicar los filtros. Para activar las funciones de los filtros de paquetes IPv6, debe sondear la versión inet6 de la interfaz.

Si no se encuentra ningún módulo pfil para las interfaces de red, los servicios SMF se colocan en el estado de mantenimiento. La causa más común de esta situación es un archivo /etc/ipf/pfil.ap editado de forma incorrecta. Si el servicio se coloca en el modo de mantenimiento, su aparición se registra en los archivos de registro de filtros.

Para ver las tareas asociadas con la activación del filtro IP de Oracle Solaris, consulte Configuración del filtro IP de Oracle Solaris.

IPv6 para filtro IP de Oracle Solaris

A partir de Solaris 10 6/06, el filtro IP de Oracle Solaris es compatible con IPv6. Los filtros de paquetes IPv6 pueden filtrar basándose en la dirección IPv6 de origen o destino, agrupaciones con direcciones IPv6 y encabezados de extensiones IPv6.

IPv6 es similar a IPv4 en muchos aspectos. Sin embargo, el tamaño del paquete y el encabezado son diferentes en las dos versiones de IP, lo cual es una consideración importante para el filtro IP. Los paquetes IPv6 conocidos como jumbogramas contienen un datagrama de más de 65.535 bytes. El filtro IP de Oracle Solaris no admite jumbogramas de IPv6. Para obtener más información sobre otras características de IPv6, consulte Características principales de IPv6.

Nota –

Si desea más información sobre los jumbogramas, consulte el documento IPv6 Jumbograms, RFC 2675 de Internet Engineering Task Force (IETF). [http://www.ietf.org/rfc/rfc2675.txt]

Las tareas del filtro IP asociadas con IPv6 no son muy diferentes de IPv4. La diferencia más notable es el uso de la opción -6 con determinados comandos. Tanto los comandos ipf como ipfstat incluyen la opción -6 para utilizar los filtros de paquetes IPv6. Utilice la opción -6 con el comando ipf para cargar y vaciar las reglas de filtros de paquetes IPv6. Para ver las estadísticas de IPv6, utilice la opción -6 con el comando ipfstat. Los comandos ipmon e ippool también admiten IPv6, aunque no hay ninguna opción asociada para la compatibilidad con IPv6. El comando ipmon se ha mejorado para permitir el registro de paquetes IPv6. El comando ippool admite las agrupaciones con las direcciones IPv6. Puede crear agrupaciones sólo de direcciones IPv4 o IPv6, o una agrupación que contenga tanto direcciones IPv4 como IPv6.

Puede utilizar el archivo ipf6.conf para crear conjuntos de reglas de filtros de paquetes para IPv6. De modo predeterminado, el archivo de configuración ipf6.conf se incluye en el directorio /etc/ipf. Al igual que con los demás archivos de configuración de filtros, el archivo ipf6.conf se carga automáticamente durante el proceso de inicio cuando se almacena en el directorio /etc/ipf. También puede crear y guardar un archivo de configuración IPv6 en otra ubicación y cargar el archivo manualmente.

Nota –

La traducción de direcciones de red (NAT) no admite IPv6.

Una vez configuradas las reglas de filtros de paquetes para IPv6, active las funciones de filtros de paquetes IPv6 sondeando la versión inet6 de la interfaz.

Para obtener más información sobre IPv6, consulte el Capítulo 3Introducción a IPv6 (descripción general). Para conocer las tareas asociadas con el filtro IP de Oracle Solaris, consulte el Capítulo 26Filtro IP de Oracle Solaris (tareas).

Páginas del comando man del filtro IP de Oracle Solaris

La tabla siguiente incluye la documentación de la página del comando man relativa al filtro IP de Oracle Solaris.

Página de comando man 

Descripción 

ipf(1M)

Utilice el comando ipf para:

  • Trabajar con conjuntos de reglas de filtros de paquetes.

  • Desactivar y activar los filtros.

  • Restablecer las estadísticas y volver a sincronizar la lista de interfaces del núcleo con la lista de estado de la interfaz actual.

ipf(4)

Contiene la gramática y sintaxis para crear reglas de filtros de paquetes del filtro IP de Oracle Solaris. 

ipfilter(5)

Proporciona información de licencia del filtro IP de código abierto. 

ipfs(1M)

Utilice el comando ipfs para guardar y restablecer la información NAT y la de la tabla de estado tras los reinicios.

ipfstat(1M)

Utilice el comando ipfstat para recuperar y mostrar las estadísticas de procesamiento de paquetes.

ipmon(1M)

Utilice el comando ipmon para abrir el dispositivo de registro y ver los paquetes registrados para NAT y los filtros de paquetes.

ipnat(1M)

Utilice el comando ipnat para:

  • Trabajar con reglas NAT.

  • Recuperar y ver las estadísticas de NAT.

ipnat(4)

Contiene la gramática y sintaxis para crear reglas NAT. 

ippool(1M)

Utilice el comando ippool para crear y administrar agrupaciones de direcciones.

ippool(4)

Contiene la gramática y sintaxis para crear agrupaciones de direcciones del filtro IP de Oracle Solaris. 

ndd(1M)

Muestra los parámetros de filtros actuales del módulo pfil STREAMS y los valores actuales de los parámetros ajustables.

Capítulo 26 Filtro IP de Oracle Solaris (tareas)

Este capítulo proporciona instrucciones detalladas para las tareas del Filtro IP de Solaris. Para obtener información general sobre el filtro IP de Oracle Solaris, consulte el Capítulo 25Filtro IP de Oracle Solaris (descripción general).

Este capítulo contiene la información siguiente:

Configuración del filtro IP de Oracle Solaris

El siguiente mapa de tareas identifica los procedimientos asociados con la configuración del filtro IP de Oracle Solaris.

Tabla 26–1 Configuración del filtro IP de Oracle Solaris (mapa de tareas)

Tarea 

Descripción 

Para obtener instrucciones 

Activar inicialmente el filtro IP de Oracle Solaris. 

El filtro IP de Oracle Solaris no está activado de modo predeterminado. Debe activarlo manualmente o utilizar los archivos de configuración del directorio /etc/ipf/ y reiniciar el sistema. A partir de la versión Solaris 10 7/07, los enlaces de filtros de paquetes reemplazan al módulo pfil para activar el filtro IP de Oracle Solaris.

Cómo activar el filtro IP de Oracle Solaris

Volver a habilitar el filtro IP de Oracle Solaris.  

Puede activar o desactivar el filtro IP de Oracle Solaris reiniciando el sistema o utilizando el comando ipf.

Cómo reactivar el filtro IP de Oracle Solaris

Activar filtrado en bucle 

De modo opcional, puede activar el filtrado en bucle, por ejemplo, para filtrar el tráfico entre zonas. 

Cómo activar los filtros en bucle

ProcedureCómo activar el filtro IP de Oracle Solaris

Utilice este procedimiento para activar el filtro IP de Oracle Solaris en un sistema en que se ejecute como mínimo el sistema operativo Solaris 10 7/07. Para habilitar los filtros IP de Oracle Solaris si el sistema tiene una versión de Oracle Solaris 10 anterior a la Solaris 10 7/07, consulte Módulo pfil.

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Cree un conjunto de reglas de filtros de paquetes.

    El conjunto de reglas de filtros de paquetes contiene reglas de filtros de paquetes que utiliza el filtro IP de Oracle Solaris. Si desea cargar las reglas de filtros de paquetes en el momento de iniciar, edite el archivo /etc/ipf/ipf.conf para implementar los filtros de paquetes IPv4. Utilice el archivo /etc/ipf/ipf6.conf para las reglas de filtros de paquetes IPv6. Si no desea cargar las reglas de filtros de paquetes al iniciar, colóquelas en un archivo y active manualmente los filtros de paquetes. Para obtener información sobre los filtros de paquetes, consulte Uso de la función de filtros de paquetes del filtro IP de Oracle Solaris. Para obtener información sobre cómo trabajar con los archivos de configuración, consulte Creación y edición de archivos de configuración del filtro IP de Oracle Solaris.

  3. (Opcional) Cree un archivo de configuración de traducción de direcciones de red (NAT).

    Nota –

    La traducción de direcciones de red (NAT) no admite IPv6.

    Cree un archivo ipnat.conf si desea utilizar la traducción de direcciones de red. Si desea que las reglas NAT se carguen durante el inicio, cree un archivo denominado /etc/ipf/ipnat.conf en el que colocar las reglas NAT. Si no desea cargar las reglas NAT al iniciar, coloque el archivo ipnat.conf en la ubicación que desee y active manualmente las reglas NAT.

    Para obtener más información sobre NAT, consulte Uso de la función NAT del filtro IP de Oracle Solaris.

  4. (Opcional) Cree un archivo de configuración de agrupaciones de direcciones.

    Cree un archivo ipool.conf si desea hacer referencia a una agrupación de direcciones como una única agrupación. Si desea que el archivo de configuración de agrupaciones de direcciones se cargue al inicio, cree un archivo denominado /etc/ipf/ippool.conf en el que colocar la agrupación de direcciones. Si no desea cargar el archivo de configuración de la agrupación de direcciones al iniciar, coloque el archivo ippool.conf en la ubicación que desee y active las reglas manualmente.

    Una agrupación de direcciones sólo puede contener direcciones IPv4 o IPv6. También puede contener tanto direcciones IPv4 como direcciones IPv6.

    Para obtener más información sobre las agrupaciones de direcciones, consulte Uso de la función de agrupaciones de direcciones del filtro IP de Oracle Solaris.

  5. (Opcional) Active el filtro de tráfico en bucle.

    Si desea filtrar el tráfico entre zonas que están configuradas en el sistema, debe activar los filtros en bucle. Consulte Cómo activar los filtros en bucle. Asegúrese de definir también los conjuntos de reglas adecuados que se aplican a las zonas.

  6. Active el filtro IP de Oracle Solaris. 


    # svcadm enable network/ipfilter

ProcedureCómo reactivar el filtro IP de Oracle Solaris

Puede volver a activar los filtros de paquetes que estén desactivados temporalmente.

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Habilite el filtro IP de Oracle Solaris y los filtros utilizando uno de los métodos siguientes:

    • Reinicie el equipo.


      # reboot
      Nota –

      Al activar el filtro IP, tras reiniciar se cargan los siguientes archivos si están presentes: el archivo /etc/ipf/ipf.conf, el archivo /etc/ipf/ipf6.conf cuando se utiliza IPv6 o el archivo /etc/ipf/ipnat.conf.

    • Ejecute la siguiente serie de comandos para habilitar el filtro IP de Oracle Solaris y los filtros:

      1. Habilite el filtro IP de Oracle Solaris. 


        # ipf -E

      2. Active los filtros de paquetes.


        # ipf -f filename

      3. (Opcional) Active NAT.


        # ipnat -f filename
        Nota –

        La traducción de direcciones de red (NAT) no admite IPv6.

ProcedureCómo activar los filtros en bucle

Nota –

Sólo se puede filtrar tráfico de bucle si el sistema ejecuta como mínimo Solaris 10 7/07. En las versiones anteriores de Oracle Solaris 10 no se admite el filtro en bucle.

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Detenga el filtro IP de Oracle Solaris si se está ejecutando.


    # svcadm disable network/ipfilter

  3. Edite los archivos /etc/ipf.conf o /etc/ipf6.conf agregando la línea siguiente al principio del archivo:


    set intercept_loopback true;

    Esta línea debe preceder a todas las reglas de filtros IP que se definan en el archivo. Sin embargo, puede insertar comentarios delante de la linea, como en el ejemplo siguiente:


    # 
# Enable loopback filtering to filter between zones 
# 
set intercept_loopback true; 
# 
# Define policy 
# 
block in all 
block out all 
<other rules>
...

  4. Inicie el filtro IP de Oracle Solaris.


    # svcadm enable network/ipfilter

  5. Para comprobar el estado de los filtros en bucle, utilice el comando siguiente:


    # ipf —T ipf_loopback
ipf_loopback    min 0   max 0x1 current 1
#

    Si el filtro en bucle está desactivado, el comando producirá el resultado siguiente:


    ipf_loopback    min 0   max 0x1 current 0

Desactivación e inhabilitación de filtro IP de Oracle Solaris

La desactivación del filtro de paquetes y NAT resulta útil en las siguientes circunstancias:

El siguiente mapa de tareas identifica los procedimientos asociados con la desactivación de las funciones de filtro IP de Oracle Solaris.

Tabla 26–2 Desactivación del filtro IP de Oracle Solaris (mapa de tareas)

Tarea 

Descripción 

Para obtener instrucciones 

Desactive los filtros de paquetes. 

Desactive los filtros de paquetes utilizando el comando ipf.

Cómo desactivar los filtros de paquetes

Desactive NAT. 

Desactive NAT utilizando el comando ipnat.

Cómo desactivar NAT

Desactive los filtros de paquetes y NAT. 

Desactive los filtros de paquetes y NAT utilizando el comando ipf.

Cómo desactivar los filtros de paquetes

ProcedureCómo desactivar los filtros de paquetes

El siguiente procedimiento desactiva los filtros de paquetes del filtro IP de Oracle Solaris vaciando las reglas de filtros de paquetes desde el conjunto de reglas de filtros activo. Este procedimiento no inhabilita el filtro IP de Oracle Solaris. Puede volver a activar el filtro IP de Oracle Solaris agregando reglas al conjunto.

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Use uno de los métodos siguientes para desactivar las reglas de filtro IP de Oracle Solaris:

    • Elimine el conjunto de reglas activo desde el núcleo.


      # ipf -Fa

      Este comando desactiva todas las reglas de filtros de paquetes.

    • Elimine las reglas de filtros de paquetes entrantes.


      # ipf -Fi

      Este comando desactiva las reglas de filtros de paquetes para los paquetes entrantes.

    • Elimine las reglas de filtros de paquetes salientes.


      # ipf -Fo

      Este comando desactiva las reglas de filtros de paquetes para los paquetes salientes.

ProcedureCómo desactivar NAT

Con el procedimiento siguiente se desactivan las reglas NAT del filtro IP de Oracle Solaris vaciándolas desde el conjunto de reglas NAT activo. Este procedimiento no inhabilita el filtro IP de Oracle Solaris. Puede volver a activar el filtro IP de Oracle Solaris agregando reglas al conjunto.

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Elimine NAT del núcleo.


    # ipnat -FC

    La opción -C elimina todas las entradas de la lista de reglas NAT actual. La opción -F elimina todas las entradas activas de la tabla de traducciones NAT activa, que muestra las asignaciones NAT activas.

ProcedureCómo desactivar los filtros de paquetes

Al ejecutar este procedimiento, se eliminan del núcleo tanto los filtros de paquetes como NAT. Si utiliza este procedimiento, debe volver a activar el Filtro IP de Solaris para reactivar el filtro de paquetes y NAT. Para más información, consulte Cómo reactivar el filtro IP de Oracle Solaris.

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Desactive los filtros de paquetes y permita a todos los paquetes pasar a la red.


    # ipf –D
    Nota –

    El comando ipf -D vacía las reglas del conjunto de reglas. Al volver a activar los filtros, debe agregar reglas al conjunto de reglas.

Módulo pfil

En esta sección se describe cómo utilizar el módulo pfil STREAMS para activar o desactivar el filtro IP de Oracle Solaris y cómo ver las estadísticas de pfil. Los procedimientos sólo se aplican a los sistemas que ejecutan una de las siguientes versiones de Oracle Solaris 10.

El siguiente mapa de tareas identifica los procedimientos asociados con la configuración del módulo pfil.

Tabla 26–3 Módulo pfil (mapa de tareas)

Tarea 

Descripción 

Para obtener instrucciones 

Habilitar filtro IP de Oracle Solaris 

El filtro IP de Oracle Solaris no está activado de modo predeterminado. Debe activarlo manualmente o utilizar los archivos de configuración del directorio /etc/ipf/ y reiniciar el sistema.

Cómo activar el filtro IP de Oracle Solaris en versiones anteriores de Oracle Solaris 10

Activar una NIC para los filtros de paquetes 

Configure el módulo pfil para activar los filtros de paquetes e una tarjeta NIC

Cómo activar una NIC para los filtros de paquetes

Desactivar el filtro IP de Oracle Solaris en una tarjeta NIC 

Elimine una tarjeta NIC y permita que todos los paquetes pasen a través de ella. 

Cómo desactivar el filtro IP de Oracle Solaris en una NIC

Visualice las estadísticas de pfil.

Visualice las estadísticas del módulo pfil para poder resolver los problemas relativos al filtro IP de Oracle Solaris utilizando el comando ndd.

Cómo visualizar las estadísticas de pfil para el filtro IP de Oracle Solaris

ProcedureCómo activar el filtro IP de Oracle Solaris en versiones anteriores de Oracle Solaris 10

El filtro IP de Oracle Solaris se instala con Oracle Solaris. Sin embargo, los filtros de paquetes no están activos de modo predeterminado. Siga este procedimiento para activar el filtro IP de Oracle Solaris.

Nota –

Si el sistema ejecuta como mínimo la versión Solaris 10 7/07, siga el procedimiento Cómo activar el filtro IP de Oracle Solaris que utiliza los enlaces de filtros de paquetes.

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Inicie el editor de archivos que prefiera y edite el archivo /etc/ipf/pfil.ap .

    Este archivo contiene los nombres de las tarjetas de interfaz de red (NIC) del host. De modo predeterminado, los nombres están comentados. Elimine el comentario de los nombres de dispositivo que llevan el tráfico de red que desea filtrar. Si el nombre de la NIC del sistema no aparece en la lista, agregue una línea para especificar la tarjeta NIC.


    # vi /etc/ipf/pfil.ap
# IP Filter pfil autopush setup
#
# See autopush(1M) manpage for more information.
#
# Format of the entries in this file is:
#
#major  minor lastminor modules

#le     -1      0       pfil
#qe     -1      0       pfil
hme     -1      0       pfil (Device has been uncommented for filtering)
#qfe    -1      0       pfil
#eri    -1      0       pfil
#ce     -1      0       pfil
#bge    -1      0       pfil
#be     -1      0       pfil
#vge    -1      0       pfil
#ge     -1      0       pfil
#nf     -1      0       pfil
#fa     -1      0       pfil
#ci     -1      0       pfil
#el     -1      0       pfil
#ipdptp -1      0       pfil
#lane   -1      0       pfil
#dmfe   -1      0       pfil

  3. Active los cambios en el archivo /etc/ipf/pfil.ap reiniciando la instancia del servicio network/pfil.


    # svcadm restart network/pfil

  4. Cree un conjunto de reglas de filtros de paquetes.

    El conjunto de reglas de filtros de paquetes contiene reglas de filtros de paquetes que utiliza el filtro IP de Oracle Solaris. Si desea cargar las reglas de filtros de paquetes en el momento de iniciar, edite el archivo /etc/ipf/ipf.conf para implementar los filtros de paquetes IPv4. Utilice el archivo /etc/ipf/ipf6.conf para las reglas de filtros de paquetes IPv6. Si no desea cargar las reglas de filtros de paquetes al iniciar, colóquelas en un archivo y active manualmente los filtros de paquetes. Para obtener información sobre los filtros de paquetes, consulte Uso de la función de filtros de paquetes del filtro IP de Oracle Solaris. Para obtener información sobre cómo trabajar con los archivos de configuración, consulte Creación y edición de archivos de configuración del filtro IP de Oracle Solaris.

  5. (Opcional) Cree un archivo de configuración de traducción de direcciones de red (NAT).

    Nota –

    La traducción de direcciones de red (NAT) no admite IPv6.

    Cree un archivo ipnat.conf si desea utilizar la traducción de direcciones de red. Si desea que las reglas NAT se carguen durante el inicio, cree un archivo denominado /etc/ipf/ipnat.conf en el que colocar las reglas NAT. Si no desea cargar las reglas NAT al iniciar, coloque el archivo ipnat.conf en la ubicación que desee y active manualmente las reglas NAT.

    Para obtener más información sobre NAT, consulte Uso de la función NAT del filtro IP de Oracle Solaris.

  6. (Opcional) Cree un archivo de configuración de agrupaciones de direcciones.

    Cree un archivo ipool.conf si desea hacer referencia a una agrupación de direcciones como una única agrupación. Si desea que el archivo de configuración de agrupaciones de direcciones se cargue al inicio, cree un archivo denominado /etc/ipf/ippool.conf en el que colocar la agrupación de direcciones. Si no desea cargar el archivo de configuración de la agrupación de direcciones al iniciar, coloque el archivo ippool.conf en la ubicación que desee y active las reglas manualmente.

    Una agrupación de direcciones sólo puede contener direcciones IPv4 o IPv6. También puede contener tanto direcciones IPv4 como direcciones IPv6.

    Para obtener más información sobre las agrupaciones de direcciones, consulte Uso de la función de agrupaciones de direcciones del filtro IP de Oracle Solaris.

  7. Active el filtro IP de Oracle Solaris siguiendo uno de estos métodos:

    • Active el filtro IP y reinicie el equipo.


      # svcadm enable network/ipfilter
# reboot
      Nota –

      Es necesario reiniciar si no puede utilizar los comandos ifconfig unplumb y ifconfig plumb con seguridad en las tarjetas NIC.

    • Active las tarjetas NIC utilizando los comandos ifconfig unplumb e ifconfig plumb. A continuación, active el filtro IP. La versión inet6 de la interfaz debe estar sondeada para poder implementar los filtros de paquetes IPv6.


      # ifconfig hme0 unplumb
# ifconfig hme0 plumb 192.168.1.20 netmask 255.255.255.0 up
# ifconfig hme0 inte6 unplumb
# ifconfig hme0 inet6 plumb fec3:f849::1/96 up
# svcadm enable network/ipfilter

      Para obtener más información sobre el comando ifconfig, consulte la página del comando man ifconfig(1M).

ProcedureCómo activar una NIC para los filtros de paquetes

El filtro IP de Oracle Solaris está activo durante el inicio cuando existe el archivo /etc/ipf/ipf.conf (o /etc/ipf/ipf6.conf si se utiliza IPv6). Si tiene que activar los filtros en una NIC después de activar el filtro IP de Oracle Solaris, utilice el procedimiento siguiente.

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Inicie el editor de archivos que prefiera y edite el archivo /etc/ipf/pfil.ap .

    Este archivo contiene los nombres de las NIC del host. De modo predeterminado, los nombres están comentados. Elimine el comentario de los nombres de dispositivo que llevan el tráfico de red que desea filtrar. Si el nombre de la NIC del sistema no aparece en la lista, agregue una línea para especificar la tarjeta NIC.


    # vi /etc/ipf/pfil.ap
# IP Filter pfil autopush setup
#
# See autopush(1M) manpage for more information.
#
# Format of the entries in this file is:
#
#major  minor lastminor modules

#le     -1      0       pfil
#qe     -1      0       pfil
hme     -1      0       pfil (Device has been uncommented for filtering)
#qfe    -1      0       pfil
#eri    -1      0       pfil
#ce     -1      0       pfil
#bge    -1      0       pfil
#be     -1      0       pfil
#vge    -1      0       pfil
#ge     -1      0       pfil
#nf     -1      0       pfil
#fa     -1      0       pfil
#ci     -1      0       pfil
#el     -1      0       pfil
#ipdptp -1      0       pfil
#lane   -1      0       pfil
#dmfe   -1      0       pfil

  3. Active los cambios en el archivo /etc/ipf/pfil.ap reiniciando la instancia del servicio network/pfil.


    # svcadm restart network/pfil

  4. Active la NIC siguiendo uno de estos métodos:

    • Reinicie el equipo.


      # reboot
      Nota –

      Es necesario reiniciar si no puede utilizar los comandos ifconfig unplumb y ifconfig plumb con seguridad en las tarjetas NIC.

    • Active las NIC que desee filtrar utilizando el comando ifconfig con las opciones unplumb y plumb. La versión inet6 de cada interfaz debe estar sondeada para poder implementar los filtros de paquetes IPv6.


      # ifconfig hme0 unplumb
# ifconfig hme0 plumb 192.168.1.20  netmask 255.255.255.0  up
# ifconfig hme0 inet6 unplumb
# ifconfig hme0 inet6 plumb fec3:f840::1/96 up

      Para obtener más información sobre el comando ifconfig, consulte la página del comando man ifconfig(1M).

ProcedureCómo desactivar el filtro IP de Oracle Solaris en una NIC

Siga el procedimiento de más abajo para detener los paquetes de filtros en una tarjeta NIC.

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Inicie el editor de archivos que prefiera y edite el archivo /etc/ipf/pfil.ap .

    Este archivo contiene los nombres de las NIC del host. Se eliminan los comentarios de las NIC que se han utilizando para filtrar el tráfico de red. Elimine los comentarios de los nombres de dispositivos que ya no desee utilizar para filtrar el tráfico de red.


    # vi /etc/ipf/pfil.ap
# IP Filter pfil autopush setup
#
# See autopush(1M) manpage for more information.
#
# Format of the entries in this file is:
#
#major  minor lastminor modules

#le     -1      0       pfil
#qe     -1      0       pfil
#hme    -1      0       pfil (Commented-out device no longer filters network traffic)
#qfe    -1      0       pfil
#eri    -1      0       pfil
#ce     -1      0       pfil
#bge    -1      0       pfil
#be     -1      0       pfil
#vge    -1      0       pfil
#ge     -1      0       pfil
#nf     -1      0       pfil
#fa     -1      0       pfil
#ci     -1      0       pfil
#el     -1      0       pfil
#ipdptp -1      0       pfil
#lane   -1      0       pfil
#dmfe   -1      0       pfil

  3. Desactive la NIC utilizando uno de estos métodos:

    • Reinicie el equipo.


      # reboot
      Nota –

      Es necesario reiniciar si no puede utilizar los comandos ifconfig unplumb y ifconfig plumb con seguridad en las tarjetas NIC.

    • Desactive las tarjetas NIC utilizando el comando ifconfig con las opciones unplumb y plumb. La versión inet6 de cada interfaz no debe estar sondeada para poder desactivar los filtros de paquetes IPv6. realice los siguientes pasos. El dispositivo de ejemplo del sistema es hme:

      1. Identifique el "major number" del dispositivo que está desactivando.


        # grep hme /etc/name_to_major
hme 7

      2. Visualice la configuración actual de autopush para hme0. 


        # autopush -g -M 7 -m 0
   Major     Minor     Lastminor       Modules
       7      ALL          -           pfil

      3. Elimine la configuración de autopush.


        # autopush -r -M 7 -m 0

      4. Abra el dispositivo y asígnele las direcciones IP.


        # ifconfig hme0 unplumb
# ifconfig hme0 plumb 192.168.1.20  netmask 255.255.255.0  up
# ifconfig hme0 inet6 unplumb
# ifconfig hme0 inet6 plumb fec3:f840::1/96 up

        Para obtener más información sobre el comando ifconfig, consulte la página del comando man ifconfig(1M).

ProcedureCómo visualizar las estadísticas de pfil para el filtro IP de Oracle Solaris

Cuando esté resolviendo problemas del filtro IP de Oracle Solaris, puede ver las estadísticas de pfil.

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Visualice las estadísticas de pfil.


    # ndd -get /dev/pfil qif_status
Ejemplo 26–1 Visualización de las estadísticas de pfil para el filtro IP de Oracle Solaris

El ejemplo siguiente muestra cómo visualizar las estadísticas de pfil.


# ndd -get /dev/pfil qif_status
ifname ill q OTHERQ num sap hl nr nw bad copy copyfail drop notip nodata
   notdata
QIF6 0 300011247b8 300011248b0 6 806 0 4 9 0 0 0 0 0 0 0
dmfe1 3000200a018 30002162a50 30002162b48 5 800 14 171 13681 0 0 0 0 0 0 0

Conjuntos de reglas del filtro IP de Oracle Solaris

El siguiente mapa de tareas identifica los procedimientos asociados con los conjuntos de reglas del filtro IP de Oracle Solaris.

Tabla 26–4 Conjuntos de reglas del filtro IP de Oracle Solaris (mapa de tareas)

Tarea 

Descripción 

Para obtener instrucciones 

Administrar, ver y modificar los conjuntos de reglas de filtros de paquetes del filtro IP de Oracle Solaris. 

 

Administración de conjuntos de reglas de filtros de paquetes para el filtro IP de Oracle Solaris

 

Visualiza un conjunto de reglas de filtros de paquetes activo. 

Cómo visualizar el conjunto de reglas de filtros de paquetes activo

 

Visualiza un conjunto de reglas de filtros de paquetes inactivo. 

Cómo visualizar el conjunto de reglas de filtros de paquetes inactivo

 

Activa un conjunto de reglas activo distinto. 

Cómo activar un conjunto de reglas de filtros de paquetes diferente o actualizado

 

Elimina un conjunto de reglas. 

Cómo eliminar un conjunto de reglas de filtros de paquetes

 

Agrega reglas a los conjuntos de reglas. 

Cómo anexar reglas al conjunto de reglas de filtros de paquetes activo

Cómo anexar reglas al conjunto de reglas de filtros de paquetes inactivo

 

Pasa de los conjuntos de reglas activos a los inactivos y viceversa. 

Cómo alternar entre los conjuntos de reglas de filtros de paquetes activo e inactivo

 

Elimina un conjunto de reglas inactivo del núcleo. 

Cómo eliminar un conjunto de reglas de filtros de paquetes inactivo del núcleo

Administrar, ver y modificar las reglas NAT del filtro IP de Oracle Solaris. 

 

Administración de reglas NAT para el filtro IP de Oracle Solaris

 

Visualiza las reglas NAT activas. 

Cómo ver las reglas NAT activas

 

Elimina las reglas NAT. 

Cómo eliminar reglas NAT

 

Agrega las reglas adicionales a las reglas NAT. 

Como anexar reglas a las reglas NAT

Administrar, ver y modificar las agrupaciones de direcciones del filtro IP de Oracle Solaris. 

 

Administración de agrupaciones de direcciones para el filtro IP de Oracle Solaris

 

Visualiza las agrupaciones de direcciones activas. 

Cómo ver las agrupaciones de direcciones activas

 

Elimina una agrupación de direcciones. 

Cómo eliminar una agrupación de direcciones

 

Agrega reglas adicionales a una agrupación de direcciones. 

Cómo anexar reglas a una agrupación de direcciones

Administración de conjuntos de reglas de filtros de paquetes para el filtro IP de Oracle Solaris

Cuando el Filtro IP de Solaris está activo, tanto los conjuntos de reglas de filtros de paquetes activos como los inactivos pueden residir en el núcleo. El conjunto de reglas activo determina el filtro que se está aplicando en los paquetes entrantes y salientes. El conjunto de reglas inactivo también guarda las reglas. Estas reglas no se utilizan a menos que convierta el conjunto de reglas inactivo en el conjunto activo. Puede administrar, ver y modificar los conjuntos de reglas de filtros de paquetes activos e inactivos.

ProcedureCómo visualizar el conjunto de reglas de filtros de paquetes activo

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Visualice el conjunto de reglas de filtros de paquetes activo que se ha cargado en el núcleo.


    # ipfstat -io
Ejemplo 26–2 Visualización del conjunto de reglas de filtros de paquetes activo

En el ejemplo siguiente se muestra el resultado del conjunto de reglas de filtros de paquetes activo que está cargado en el núcleo.


# ipfstat -io
empty list for ipfilter(out)
pass in quick on dmfe1 from 192.168.1.0/24 to any
pass in all
block in on dmfe1 from 192.168.1.10/32 to any

ProcedureCómo visualizar el conjunto de reglas de filtros de paquetes inactivo

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Visualice el conjunto de reglas de filtros de paquetes inactivo.


    # ipfstat -I -io
Ejemplo 26–3 Visualización del conjunto de reglas de filtros de paquetes inactivo

El ejemplo siguiente muestra el resultado del conjunto de reglas de filtros de paquetes inactivo.


# ipfstat -I -io
pass out quick on dmfe1 all
pass in quick on dmfe1 all

ProcedureCómo activar un conjunto de reglas de filtros de paquetes diferente o actualizado

Siga este procedimiento para llevar a cabo una de las tareas siguientes:

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Elija uno de estos pasos:

    • Cree un conjunto de reglas en un archivo diferente si desea activar un conjunto de reglas completamente distinto.

    • Actualice el conjunto de reglas actual editando el archivo de configuración que lo contiene.

  3. Elimine el conjunto de reglas actual y cargue el nuevo.


    # ipf -Fa -f filename

    El nombre_archivo puede ser el nuevo archivo con el nuevo conjunto de reglas o el archivo actualizado que contenga el conjunto de reglas activo.

    El conjunto de reglas activo se elimina del núcleo. Las reglas del archivo nombre_archivo pasan a ser el conjunto de reglas activo.

    Nota –

    Es preciso ejecutar el comando aunque esté volviendo a cargar el archivo de configuración actual. De lo contrario, el antiguo conjunto de reglas seguirá funcionando, y no se aplicará el conjunto de reglas modificado en el archivo de configuración actualizado.

    No utilice comandos como ipf -D o svcadm restart para cargar el conjunto de reglas actualizado. Dichos comandos ponen en peligro la red al desactivar el cortafuegos antes de cargar el nuevo conjunto de reglas.

Ejemplo 26–4 Activación de un conjunto de reglas de filtros de paquetes diferente

El ejemplo siguiente muestra cómo reemplazar un conjunto de reglas de filtros de paquetes por otro en un archivo de configuración distinto, /etc/ipf/ipf.conf.


# ipfstat -io
empty list for ipfilter(out)
pass in quick on dmfe all
# ipf -Fa -f /etc/ipf/ipf.conf
# ipfstat -io
empty list for ipfilter(out)
block in log quick from 10.0.0.0/8 to any
Ejemplo 26–5 Cómo volver a cargar un conjunto de reglas de filtros de paquetes actualizado

El ejemplo siguiente muestra cómo volver a cargar un conjunto de reglas de filtros de paquetes activo y luego actualizarlo. En este ejemplo, el archivo en uso es /etc/ipf/ipf.conf.


# ipfstat -io (Optional)
empty list for ipfilter (out)
block in log quick from 10.0.0.0/8 to any

(Edit the /etc/ipf/ipf.conf configuration file.)

# ip -Fa -f /etc/ipf/ipf.conf
# ipfstat -io (Optional)
empty list for ipfilter (out)
block in log quick from 10.0.0.0/8 to any
block in quick on elx10 from 192.168.0.0/12 to any

ProcedureCómo eliminar un conjunto de reglas de filtros de paquetes

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Elimine el conjunto de reglas.


    # ipf -F [a|i|o]
    -a

    Elimina todas las reglas de filtros del conjunto de reglas.

    -i

    Elimina las reglas de filtros de los paquetes entrantes.

    -o

    Elimina las reglas de filtros de los paquetes salientes.

Ejemplo 26–6 Eliminación de un conjunto de reglas de filtros de paquetes

El ejemplo siguiente muestra cómo eliminar todas las reglas de filtros del conjunto de reglas de filtros activo.


# ipfstat -io
block out log on dmf0 all
block in log quick from 10.0.0.0/8 to any
# ipf -Fa
# ipfstat -io
empty list for ipfilter(out)
empty list for ipfilter(in)

ProcedureCómo anexar reglas al conjunto de reglas de filtros de paquetes activo

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Utilice uno de os métodos siguientes para anexar reglas al conjunto de reglas activo:

    • Anexe reglas al conjunto de reglas en la línea de comandos con el comando ipf -f -.


      # echo "block in on dmfe1 proto tcp from 10.1.1.1/32 to any" | ipf -f -

    • Ejecute los comandos siguientes:

      1. Cree un conjunto de reglas en el archivo que desee.

      2. Agregue las reglas que ha creado al conjunto de reglas activo.


        # ipf -f filename

        Las reglas de nombre_archivo se agregan al final del conjunto de reglas activo. Dado que el Filtro IP de Solaris utiliza un algoritmo de "última regla coincidente", las reglas que agregue determinan las prioridades de los filtros, a menos que utilice la palabra clave quick. Si el paquete coincide con una regla que contiene la palabra clave quick, se lleva a cabo la acción de dicha regla y no se comprueban las reglas subsiguientes.

Ejemplo 26–7 Cómo anexar reglas al conjunto de reglas de filtros de paquetes activo

El ejemplo siguiente muestra cómo agregar una regla al conjunto de reglas de filtros de paquetes activo desde la línea de comandos.


# ipfstat -io
empty list for ipfilter(out)
block in log quick from 10.0.0.0/8 to any
# echo "block in on dmfe1 proto tcp from 10.1.1.1/32 to any" | ipf -f -
# ipfstat -io
empty list for ipfilter(out)
block in log quick from 10.0.0.0/8 to any
block in on dmfe1 proto tcp from 10.1.1.1/32 to any

ProcedureCómo anexar reglas al conjunto de reglas de filtros de paquetes inactivo

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Cree un conjunto de reglas en el archivo que desee.

  3. Agregue las reglas que ha creado al conjunto de reglas inactivo.


    # ipf -I -f filename

    Las reglas de nombre_archivo se agregan al final del conjunto de reglas inactivo. Dado que el Filtro IP de Solaris utiliza un algoritmo de "última regla coincidente", las reglas que agregue determinan las prioridades de los filtros, a menos que utilice la palabra clave quick. Si el paquete coincide con una regla que contiene la palabra clave quick, se lleva a cabo la acción de dicha regla y no se comprueban las reglas subsiguientes.

Ejemplo 26–8 Cómo anexar reglas al conjunto de reglas inactivo

El ejemplo siguiente muestra cómo agregar una regla al conjunto de reglas inactivo desde un archivo.


# ipfstat -I -io
pass out quick on dmfe1 all
pass in quick on dmfe1 all
# ipf -I -f /etc/ipf/ipf.conf
# ipfstat -I -io
pass out quick on dmfe1 all
pass in quick on dmfe1 all
block in log quick from 10.0.0.0/8 to any

ProcedureCómo alternar entre los conjuntos de reglas de filtros de paquetes activo e inactivo

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Alterne los conjuntos de reglas activo e inactivo.


    # ipf -s

    Este comando permite alternar entre los conjuntos de reglas activo e inactivo del núcleo. Si el conjunto de reglas inactivo está vacío, no se aplicará ningún filtro de paquetes.

Ejemplo 26–9 Cómo alternar entre los conjuntos de reglas de filtros de paquetes activo e inactivo

El ejemplo siguiente muestra cómo el uso del comando ipf -s convierte el conjunto de reglas inactivo en el conjunto activo y viceversa.

ProcedureCómo eliminar un conjunto de reglas de filtros de paquetes inactivo del núcleo

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Especifique el conjunto de reglas inactivo en el comando "flush all".


    # ipf -I -Fa

    Este comando vacía el conjunto de reglas inactivo del núcleo.

    Nota –

    Si ejecuta posteriormente ipf -s, el conjunto de reglas inactivo vacío se convertirá en el conjunto de reglas activo. Un conjunto de reglas activo vacío implica que no se aplicará ningún filtro.

Ejemplo 26–10 Cómo eliminar un conjunto de reglas de filtros de paquetes inactivo del núcleo

El ejemplo siguiente muestra cómo vaciar el conjunto de reglas de filtros de paquetes inactivo para eliminar todas las reglas.


# ipfstat -I -io
empty list for inactive ipfilter(out)
block in log quick from 10.0.0.0/8 to any
block in on dmfe1 proto tcp from 10.1.1.1/32 to any
# ipf -I -Fa
# ipfstat -I -io
empty list for inactive ipfilter(out)
empty list for inactive ipfilter(in)

Administración de reglas NAT para el filtro IP de Oracle Solaris

Utilice el procedimiento siguiente para administrar, ver y modificar las reglas NAT.

ProcedureCómo ver las reglas NAT activas

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Visualice las reglas NAT activas.


    # ipnat -l
Ejemplo 26–11 Visualización de las reglas NAT activas

El ejemplo siguiente muestra el resultado del conjunto de reglas NAT activo.


# ipnat -l
List of active MAP/Redirect filters:
map dmfe0 192.168.1.0/24 -> 20.20.20.1/32

List of active sessions:

ProcedureCómo eliminar reglas NAT

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Elimine las reglas NAT actuales.


    # ipnat -C
Ejemplo 26–12 Eliminación de reglas NAT

Con el ejemplo siguiente aprenderá a eliminar las entradas de las reglas NAT actuales.


# ipnat -l
List of active MAP/Redirect filters:
map dmfe0 192.168.1.0/24 -> 20.20.20.1/32

List of active sessions:
# ipnat -C
1 entries flushed from NAT list
# ipnat -l
List of active MAP/Redirect filters:

List of active sessions:

ProcedureComo anexar reglas a las reglas NAT

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Utilice uno de os métodos siguientes para anexar reglas al conjunto de reglas activo:

    • Anexe reglas al conjunto de reglas NAT en la línea de comandos con el comando ipnat -f -.


      # echo "map dmfe0 192.168.1.0/24 -> 20.20.20.1/32" | ipnat -f -

    • Ejecute los comandos siguientes:

      1. Cree reglas NAT adicionales en el archivo que desee.

      2. Agregue las reglas que ha creado al conjunto de reglas NAT activo.


        # ipnat -f filename

        Las reglas de nombre_archivo se agregan al final de las reglas NAT.

Ejemplo 26–13 Cómo anexar reglas al conjunto de reglas NAT

El ejemplo siguiente muestra cómo agregar una regla al conjunto de reglas NAT desde la línea de comandos.


# ipnat -l
List of active MAP/Redirect filters:

List of active sessions:
# echo "map dmfe0 192.168.1.0/24 -> 20.20.20.1/32" | ipnat -f -
# ipnat -l
List of active MAP/Redirect filters:
map dmfe0 192.168.1.0/24 -> 20.20.20.1/32

List of active sessions:

Administración de agrupaciones de direcciones para el filtro IP de Oracle Solaris

Utilice los procedimientos siguientes para administrar, ver y modificar las agrupaciones de direcciones.

ProcedureCómo ver las agrupaciones de direcciones activas

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Visualice la agrupación de direcciones activa.


    # ippool -l
Ejemplo 26–14 Visualización de la agrupación de direcciones activa

El ejemplo siguiente muestra cómo visualizar el contenido de la agrupación de direcciones activa.


# ippool -l
table role = ipf type = tree number = 13
        { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24; };

ProcedureCómo eliminar una agrupación de direcciones

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Elimine las entradas de la agrupación de direcciones actual.


    # ippool -F
Ejemplo 26–15 Cómo eliminar una agrupación de direcciones

El ejemplo siguiente muestra cómo eliminar una agrupación de direcciones.


# ippool -l
table role = ipf type = tree number = 13
        { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24; };
# ippool -F
1 object flushed
# ippool -l

ProcedureCómo anexar reglas a una agrupación de direcciones

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Utilice uno de os métodos siguientes para anexar reglas al conjunto de reglas activo:

    • Anexe reglas al conjunto de reglas en la línea de comandos utilizando el comando ippool -f -.


      # echo "table role = ipf type = tree number = 13 
{10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24};" | ippool -f -

    • Ejecute los comandos siguientes:

      1. Cree agrupaciones de direcciones adicionales en el archivo que desee.

      2. Agregue las reglas que ha creado al conjunto de direcciones activo.


        # ippool -f filename

        Las reglas de nombre_archivo se agregan al final de la agrupación de direcciones activa.

Ejemplo 26–16 Cómo anexar reglas a una agrupación de direcciones

El ejemplo siguiente muestra cómo agregar una agrupación de direcciones al conjunto de reglas de la agrupación de direcciones desde la línea de comandos.


# ippool -l
table role = ipf type = tree number = 13
        { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24; };
# echo "table role = ipf type = tree number = 100
 {10.0.0.0/32, 172.16.1.2/32, 192.168.1.0/24};" | ippool -f -
# ippool -l
table role = ipf type = tree number = 100
        { 10.0.0.0/32, 172.16.1.2/32, 192.168.1.0/24; };
table role = ipf type = tree number = 13
        { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24; };

Cómo visualizar las estadísticas e información sobre el filtro IP de Oracle Solaris

Tabla 26–5 Cómo visualizar las estadísticas e información sobre el filtro IP de Oracle Solaris (mapa de tareas)

Tarea 

Descripción 

Para obtener instrucciones 

Ver las tablas de estado. 

Visualiza las tablas de estado para obtener información sobre los filtros de paquetes con el comando ipfstat.

Cómo ver las tablas de estado para el filtro IP de Oracle Solaris

Ver las estadísticas de estado. 

Visualiza las estadísticas sobre el estado de los paquetes utilizando el comando ipfstat - s.

Cómo ver las tablas de estado para el filtro IP de Oracle Solaris

Ver las estadísticas de NAT. 

Visualiza las estadísticas de NAT utilizando el comando ipnat -s.

Cómo visualizar las estadísticas de NAT para el filtro IP de Oracle Solaris

Ver las estadísticas de la agrupación de direcciones. 

Visualiza las estadísticas de la agrupación de direcciones utilizando el comando ippool -s.

Cómo visualizar las estadísticas de la agrupación de direcciones para el filtro IP de Oracle Solaris

ProcedureCómo ver las tablas de estado para el filtro IP de Oracle Solaris

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Visualice la tabla de estado.


    # ipfstat
    Nota –

    Puede utilizar la opción -t para ver la tabla de estado en el formato de la utilidad.

Ejemplo 26–17 Visualización de tablas de estado para el filtro IP Oracle Solaris

El ejemplo siguiente muestra cómo visualizar una tabla de estado.


# ipfstat
bad packets:            in 0    out 0
 input packets:         blocked 160 passed 11 nomatch 1 counted 0 short 0
output packets:         blocked 0 passed 13681 nomatch 6844 counted 0 short 0
 input packets logged:  blocked 0 passed 0
output packets logged:  blocked 0 passed 0
 packets logged:        input 0 output 0
 log failures:          input 0 output 0
fragment state(in):     kept 0  lost 0
fragment state(out):    kept 0  lost 0
packet state(in):       kept 0  lost 0
packet state(out):      kept 0  lost 0
ICMP replies:   0       TCP RSTs sent:  0
Invalid source(in):     0
Result cache hits(in):  152     (out):  6837
IN Pullups succeeded:   0       failed: 0
OUT Pullups succeeded:  0       failed: 0
Fastroute successes:    0       failures:       0
TCP cksum fails(in):    0       (out):  0
IPF Ticks:      14341469
Packet log flags set: (0)
        none

ProcedureCómo ver las tablas de estado para el filtro IP de Oracle Solaris

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Visualice las estadísticas de estado.


    # ipfstat -s
Ejemplo 26–18 Visualización de tablas de estadísticas para el filtro IP de Oracle Solaris

El ejemplo siguiente muestra cómo visualizar las estadísticas de estado.


# ipfstat -s
IP states added:
        0 TCP
        0 UDP
        0 ICMP
        0 hits
        0 misses
        0 maximum
        0 no memory
        0 max bucket
        0 active
        0 expired
        0 closed
State logging enabled

State table bucket statistics:
        0 in use        
        0.00% bucket usage
        0 minimal length
        0 maximal length
        0.000 average length

ProcedureCómo visualizar las estadísticas de NAT para el filtro IP de Oracle Solaris

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Ver las estadísticas de NAT.


    # ipnat -s
Ejemplo 26–19 Visualización de estadísticas NAT para el filtro IP de Oracle Solaris

El ejemplo siguiente muestra cómo visualizar las estadísticas de NAT.


# ipnat -s
mapped  in      0       out     0
added   0       expired 0
no memory       0       bad nat 0
inuse   0
rules   1
wilds   0

ProcedureCómo visualizar las estadísticas de la agrupación de direcciones para el filtro IP de Oracle Solaris

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Ver las estadísticas de la agrupación de direcciones.


    # ippool -s
Ejemplo 26–20 Visualización de las estadísticas de la agrupación de direcciones para el filtro IP de Oracle Solaris

El ejemplo siguiente muestra cómo visualizar las estadísticas de la agrupación de direcciones.


# ippool -s
Pools:  3
Hash Tables:    0
Nodes:  0

Archivos de registro para el filtro IP de Oracle Solaris

Tabla 26–6 Archivos de registro para el filtro IP de Oracle Solaris (mapa de tareas)

Tarea 

Descripción 

Para obtener instrucciones 

Crear un archivo de registro. 

Crea un archivo de registro del filtro IP de Oracle Solaris independiente. 

Cómo configurar un archivo de registro para el filtro IP de Oracle Solaris

Visualizar archivos de registro. 

Visualiza el estado, la NAT y los archivos de registro normales utilizando el comando ipmon.

Cómo visualizar los archivos de registro del filtro IP de Oracle Solaris

Vacíe el búfer de registro de paquetes. 

Elimine el contenido del búfer de registro de paquetes utilizando el comando ipmon - F.

Cómo vaciar el archivo de registro de paquetes

Guardar los paquetes registrados en un archivo. 

Guarda los paquetes registrados en un archivo para poder consultarlos posteriormente. 

Cómo guardar paquetes registrados en un archivo

ProcedureCómo configurar un archivo de registro para el filtro IP de Oracle Solaris

De modo predeterminado, toda la información de registro del filtro IP de Oracle Solaris se guarda en el archivo syslogd. Debe configurar un archivo de registro para que guarde la información de tráfico del filtro IP de Oracle Solaris de forma independiente de los demás datos que se puedan registrar en el archivo predeterminado. Realice los siguientes pasos.

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Edite el archivo /etc/syslog.conf agregando las dos líneas siguientes:


    # Save IPFilter log output to its own file 
local0.debug             /var/log/log-name
    Nota –

    En la segunda línea, asegúrese de utilizar la tecla de tabulación y no la barra espaciadora para separar local0.debug de /var/log/nombre_registro.

  3. Cree el nuevo archivo de registro.


    # touch /var/log/log-name

  4. Reinicie el servicio de registro del sistema.


    # svcadm restart system-log
Ejemplo 26–21 Creación de un registro del filtro IP de Oracle Solaris

En el ejemplo siguiente se muestra cómo crear ipmon.log para archivar información de filtro de IP.

En /etc/syslog.conf:


# Save IPFilter log output to its own file 
local0.debug             /var/log/ipmon.log

En la línea de comandos:


# touch /var/log/ipmon.log
# svcadm restart system-log

ProcedureCómo visualizar los archivos de registro del filtro IP de Oracle Solaris

Antes de empezar

Debe crear un archivo de registro independiente para guardar los datos del filtro IP de Oracle Solaris. Consulte Cómo configurar un archivo de registro para el filtro IP de Oracle Solaris.

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Visualice el estado, la NAT o los archivos de registro normales. Para ver un archivo de registro, escriba el comando siguiente con la opción adecuada:


    # ipmon -o [S|N|I] filename
    S

    Muestra el archivo de registro de estado.

    N

    Muestra al archivo de registro de NAT.

    I

    Muestra el archivo de registro de IP normal.

    Para ver todos los archivos de estado, NAT y registro normal, utilice todas las opciones:


    # ipmon -o SNI filename

    • Si ha detenido manualmente el daemon ipmon en primer lugar, también puede utilizar el siguiente comando para ver los archivos de registro de estado, NAT y filtro IP de Oracle Solaris:


      # ipmon -a filename
      Nota –

      No utilice la sintaxis ipmon -a si el daemon ipmon sigue ejecutándose. Normalmente, el daemon se inicia automáticamente durante el inicio del sistema. Al ejecutar el comando ipmon -a también se abre otra copia de ipmon. En tal caso, ambas copias leen el mismo registro, y sólo una obtiene un mensaje de registro específico.

    Si desea más información sobre cómo visualizar archivos de registro, consulte la página del comando man ipmon(1M).

Ejemplo 26–22 Visualización de archivos de registro del filtro IP de Oracle Solaris

El ejemplo siguiente muestra el resultado de /var/ipmon.log.


# ipmon -o SNI /var/ipmon.log
02/09/2004 15:27:20.606626 hme0 @0:1 p 129.146.157.149 -> 
129.146.157.145 PR icmp len 20 84 icmp echo/0 IN

o


# pkill ipmon
# ipmon -aD /var/ipmon.log
02/09/2004 15:27:20.606626 hme0 @0:1 p 129.146.157.149 -> 
129.146.157.145 PR icmp len 20 84 icmp echo/0 IN

ProcedureCómo vaciar el archivo de registro de paquetes

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Vacíe el búfer de registro de paquetes.


    # ipmon -F
Ejemplo 26–23 Vaciado del archivo de registro de paquetes

El siguiente ejemplo muestra el resultado cuando se elimina un archivo de registro. El sistema crea un informe incluso cuando no hay nada en el archivo de registro, como es el caso de este ejemplo.


# ipmon -F
0 bytes flushed from log buffer
0 bytes flushed from log buffer
0 bytes flushed from log buffer

ProcedureCómo guardar paquetes registrados en un archivo

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Guarde los paquetes registrados en un archivo.


    # cat /dev/ipl > filename

    Siga registrando paquetes en el archivo nombre_archivo hasta interrumpir el procedimiento escribiendo Control-C para que vuelva a aparecer la línea de comandos.

Ejemplo 26–24 Cómo guardar los paquetes registrados en un archivo

El ejemplo siguiente muestra el resultado que se obtiene al guardar paquetes registrados en un archivo.


# cat /dev/ipl > /tmp/logfile
^C#

# ipmon -f /tmp/logfile
02/09/2004 15:30:28.708294 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 52 -S IN
02/09/2004 15:30:28.708708 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 40 -A IN
02/09/2004 15:30:28.792611 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 70 -AP IN
02/09/2004 15:30:28.872000 hme0 @0:1 p 129.146.157.149,33923 -> 
 129.146.157.145,23 PR tcp len 20 40 -A IN
02/09/2004 15:30:28.872142 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 43 -AP IN
02/09/2004 15:30:28.872808 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 40 -A IN
02/09/2004 15:30:28.872951 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 47 -AP IN
02/09/2004 15:30:28.926792 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 40 -A IN 
.
.
(output truncated)

Creación y edición de archivos de configuración del filtro IP de Oracle Solaris

Debe editar directamente los archivos de configuración para crear y modificar conjuntos de reglas y agrupaciones de direcciones. Los archivos de configuración siguen reglas de sintaxis de UNIX estándar:

ProcedureCómo crear un archivo de configuración para el filtro IP de Oracle Solaris

El procedimiento siguiente describe cómo configurar:

  1. Asuma un rol que incluya el perfil con derechos de administración del filtro IP, o conviértase en superusuario.

    Puede asignar el perfil con derechos de administración del filtro IP a un rol que cree. Para crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security Services.

  2. Inicie el editor de archivos que prefiera. Cree o edite el archivo de configuración para la función que desee configurar.

    • Para crear un archivo de configuración para las reglas de filtros de paquetes, edite el archivo ipf.conf.

      El filtro IP de Oracle Solaris utiliza las reglas de filtros de paquetes que se colocan en el archivo ipf.conf. Si coloca las reglas para los filtros de paquetes en el archivo /etc/ipf/ipf.conf, dicho archivo se carga al iniciar el sistema. Si no desea que las reglas de filtros se carguen durante el inicio, colóquelas en el archivo que prefiera. A continuación, puede activar las reglas con el comando ipf, tal como se describe en Cómo activar un conjunto de reglas de filtros de paquetes diferente o actualizado.

      Consulte Uso de la función de filtros de paquetes del filtro IP de Oracle Solaris para obtener información sobre cómo crear reglas de filtros de paquetes.

      Nota –

      Si el archivo ipf.conf está vacío, no se aplica ningún filtro. Un archivo ipf.conf vacío equivale a tener un conjunto de reglas como el siguiente:


      pass in all
pass out all

    • Para crear un archivo de configuración para las reglas NAT, edite el archivo ipnat.conf.

      El filtro IP de Oracle Solaris utiliza las reglas NAT que se colocan en el archivo ipnat.conf. Si coloca las reglas para NAT en el archivo /etc/ipf/ipnat.conf, dicho archivo se carga al iniciar el sistema. Si no desea que las reglas NAT se carguen durante el inicio, coloque el archivo ipnat.conf en la ubicación que prefiera. A continuación, puede activar las reglas NAT con el comando ipnat.

      Consulte Uso de la función NAT del filtro IP de Oracle Solaris para obtener información sobre cómo crear reglas para la NAT.

    • Para crear un archivo de configuración para las agrupaciones de direcciones, edite el archivo ippool.conf.

      El filtro IP de Oracle Solaris utiliza la agrupación de direcciones que se coloca en el archivo ippool.conf. Si coloca las reglas para la agrupación de direcciones en el archivo /etc/ipf/ippool.conf, dicho archivo se carga al iniciar el sistema. Si no desea que la agrupación de direcciones se cargue durante el inicio, coloque el archivo ippool.conf en la ubicación que prefiera. A continuación, puede activar la agrupación de direcciones con el comando ippool.

      Consulte Uso de la función de agrupaciones de direcciones del filtro IP de Oracle Solaris para obtener información sobre la creación de agrupaciones de direcciones.

Ejemplos de archivos de configuración del filtro IP de Oracle Solaris

Los ejemplos siguientes ilustran las reglas de filtros de paquetes que se utilizan en las configuraciones de filtros.

Ejemplo 26–25 Configuración de host del filtro IP de Oracle Solaris

Este ejemplo muestra una configuración en un equipo host con una interfaz de red elxl.


# pass and log everything by default
pass in log on elxl0 all
pass out log on elxl0 all

# block, but don't log, incoming packets from other reserved addresses
block in quick on elxl0 from 10.0.0.0/8 to any
block in quick on elxl0 from 172.16.0.0/12 to any

# block and log untrusted internal IPs. 0/32 is notation that replaces 
# address of the machine running Solaris IP Filter.
block in log quick from 192.168.1.15 to <thishost>
block in log quick from 192.168.1.43 to <thishost>

# block and log X11 (port 6000) and remote procedure call 
# and portmapper (port 111) attempts
block in log quick on elxl0 proto tcp from any to elxl0/32 port = 6000 keep state
block in log quick on elxl0 proto tcp/udp from any to elxl0/32 port = 111 keep state

Este conjunto de reglas comienza con dos reglas sin restricciones que permiten la transferencia de todos los datos con la interfaz elxl. El segundo conjunto de reglas bloquea todos los paquetes entrantes de los espacios de direcciones privadas 10.0.0.0 y 172.16.0.0 mediante el cortafuegos. El siguiente conjunto de reglas bloquea direcciones internas específicas del equipo host. Finalmente, el último conjunto de reglas bloquea los paquetes que provienen de los puertos 6000 y 111.

Ejemplo 26–26 Configuración de servidor del filtro IP de Oracle Solaris

Este ejemplo muestra una configuración para un equipo host que actúa como servidor Web. Este equipo cuenta con una interfaz de red eri.


# web server with an eri interface
# block and log everything by default; then allow specific services
# group 100 - inbound rules
# group 200 - outbound rules
# (0/32) resolves to our IP address)
*** FTP proxy ***


# block short packets which are packets fragmented too short to be real.
block in log quick all with short


# block and log inbound and outbound by default, group by destination
block in log on eri0 from any to any head 100
block out log on eri0 from any to any head 200


# web rules that get hit most often
pass in quick on eri0 proto tcp from any \
to eri0/32 port = http flags S keep state group 100
pass in quick on eri0 proto tcp from any \
to eri0/32 port = https flags S keep state group 100


# inbound traffic - ssh, auth
pass in quick on eri0 proto tcp from any \
to eri0/32 port = 22 flags S keep state group 100
pass in log quick on eri0 proto tcp from any \
to eri0/32 port = 113 flags S keep state group 100
pass in log quick on eri0 proto tcp from any port = 113 \
to eri0/32 flags S keep state group 100


# outbound traffic - DNS, auth, NTP, ssh, WWW, smtp
pass out quick on eri0 proto tcp/udp from eri0/32 \
to any port = domain flags S keep state group 200
pass in quick on eri0 proto udp from any port = domain to eri0/32 group 100

pass out quick on eri0 proto tcp from eri0/32 \
to any port = 113 flags S keep state group 200
pass out quick on eri0 proto tcp from eri0/32 port = 113 \
to any flags S keep state group 200

pass out quick on eri0 proto udp from eri0/32 to any port = ntp group 200
pass in quick on eri0 proto udp from any port = ntp to eri0/32 port = ntp group 100

pass out quick on eri0 proto tcp from eri0/32 \
to any port = ssh flags S keep state group 200

pass out quick on eri0 proto tcp from eri0/32 \
to any port = http flags S keep state group 200
pass out quick on eri0 proto tcp from eri0/32 \
to any port = https flags S keep state group 200

pass out quick on eri0 proto tcp from eri0/32 \
to any port = smtp flags S keep state group 200


# pass icmp packets in and out
pass in quick on eri0 proto icmp from any to eri0/32  keep state group 100
pass out quick on eri0 proto icmp from eri0/32 to any keep state group 200


# block and ignore NETBIOS packets
block in quick on eri0 proto tcp from any \
to any port = 135 flags S keep state group 100

block in quick on eri0 proto tcp from any port = 137 \
to any flags S keep state group 100
block in quick on eri0 proto udp from any to any port = 137 group 100
block in quick on eri0 proto udp from any port = 137 to any group 100

block in quick on eri0 proto tcp from any port = 138 \
to any flags S keep state group 100
block in quick on eri0 proto udp from any port = 138 to any group 100

block in quick on eri0 proto tcp from any port = 139 to any flags S keep state
group 100
block in quick on eri0 proto udp from any port = 139 to any group 100
Ejemplo 26–27 Configuración de enrutador del filtro IP de Oracle Solaris

El ejemplo siguiente muestra una configuración para un enrutador con una interfaz interna (ce0) y otra externa (ce1).


# internal interface is ce0 at 192.168.1.1
# external interface is ce1 IP obtained via DHCP
# block all packets and allow specific services
*** NAT ***
*** POOLS ***


# Short packets which are fragmented too short to be real.
block in log quick all with short


# By default, block and log everything.
block in log on ce0 all
block in log on ce1 all
block out log on ce0 all
block out log on ce1 all


# Packets going in/out of network interfaces that aren't on the loopback
# interface should not exist.
block in log quick on ce0 from 127.0.0.0/8 to any
block in log quick on ce0 from any to 127.0.0.0/8
block in log quick on ce1 from 127.0.0.0/8 to any
block in log quick on ce1 from any to 127.0.0.0/8


# Deny reserved addresses.
block in quick on ce1 from 10.0.0.0/8 to any
block in quick on ce1 from 172.16.0.0/12 to any
block in log quick on ce1 from 192.168.1.0/24 to any
block in quick on ce1 from 192.168.0.0/16 to any


# Allow internal traffic
pass in quick on ce0 from 192.168.1.0/24 to 192.168.1.0/24
pass out quick on ce0 from 192.168.1.0/24 to 192.168.1.0/24


# Allow outgoing DNS requests from our servers on .1, .2, and .3
pass out quick on ce1 proto tcp/udp from ce1/32 to any port = domain keep state
pass in quick on ce0 proto tcp/udp from 192.168.1.2 to any port = domain keep state
pass in quick on ce0 proto tcp/udp from 192.168.1.3 to any port = domain keep state


# Allow NTP from any internal hosts to any external NTP server.
pass in quick on ce0 proto udp from 192.168.1.0/24 to any port = 123 keep state
pass out quick on ce1 proto udp from any to any port = 123 keep state


# Allow incoming mail
pass in quick on ce1 proto tcp from any to ce1/32 port = smtp keep state
pass in quick on ce1 proto tcp from any to ce1/32 port = smtp keep state
pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = smtp keep state


# Allow outgoing connections: SSH, WWW, NNTP, mail, whois
pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = 22 keep state
pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = 22 keep state

pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = 80 keep state
pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = 80 keep state
pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = 443 keep state
pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = 443 keep state

pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = nntp keep state
block in quick on ce1 proto tcp from any to any port = nntp keep state
pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = nntp keep state

pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = smtp keep state

pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = whois keep state
pass out quick on ce1 proto tcp from any to any port = whois keep state


# Allow ssh from offsite
pass in quick on ce1 proto tcp from any to ce1/32 port = 22 keep state


# Allow ping out
pass in quick on ce0 proto icmp all keep state
pass out quick on ce1 proto icmp all keep state


# allow auth out
pass out quick on ce1 proto tcp from ce1/32 to any port = 113 keep state
pass out quick on ce1 proto tcp from ce1/32 port = 113 to any keep state


# return rst for incoming auth
block return-rst in quick on ce1 proto tcp from any to any port = 113 flags S/SA


# log and return reset for any TCP packets with S/SA
block return-rst in log on ce1 proto tcp from any to any flags S/SA


# return ICMP error packets for invalid UDP packets
block return-icmp(net-unr) in proto udp all