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.
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).
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:
svc:/network/ipsec/policy:default
svc:/network/ipsec/ipsecalgs:default
Por defecto, los servicios de gestión de claves se deshabilitan en el inicio del sistema:
svc:/network/ipsec/manual-key:default
svc:/network/ipsec/ike:default
Para activar directivas IPsec en SMF, siga estos pasos:
Agregue entradas de directivas IPsec al archivo ipsecinit.conf.
Configure la Internet Key Exchange (IKE) o configure manualmente las claves.
Actualice el servicio de directivas IPsec.
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.
IPsec implementa los túneles en modo túnel para las redes privadas virtuales (VPN). En modo túnel, IPsec admite múltiples clientes detrás de una sola NAT. En modo túnel, IPsec es interoperable con las implementaciones de túneles de IP en IP de otros proveedores. IPsec sigue admitiendo túneles en modo transporte, de modo que es compatible con las versiones anteriores de Solaris.
La sintaxis para crear un túnel se simplifica. Para administrar la directiva IPsec, se ha ampliado el comando ipsecconf. El comando ifconfig no se admite para la administración de la directiva IPsec.
A partir de esta versión, se elimina el archivo /etc/ipnodes. Utilice el archivo /etc/hosts para configurar las direcciones IPv6 de red.
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.
Para utilizar el almacén de claves softtoken, consulte la página del comando man cryptoadm(1M).
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.
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:
Protocolos de seguridad: Mecanismo de protección de datagramas IP. El encabezado de autenticación (AH) firma los paquetes IP y garantiza la integridad. El contenido del datagrama no está cifrado, pero el receptor tiene la seguridad de que el contenido del paquete no se ha modificado. El receptor también tiene la garantía de que los paquetes los ha enviado el remitente. La Encapsulating Security Payload (ESP) cifra los datos IP, con lo cual codifica el contenido durante la transmisión de paquetes. ESP también puede garantizar la integridad de los datos mediante una opción de algoritmo de autenticación.
Base de datos de asociaciones de seguridad (SADB): La base de datos que asocia un protocolo de seguridad con una dirección de destino IP y un número de índice. El número de índice se denomina índice de parámetros de seguridad. Estos tres elementos (el protocolo de seguridad, la dirección de destino y el SPI) identifican de forma exclusiva a un paquete IPsec legítimo. La base de datos garantiza que el receptor reconozca un paquete protegido que llega a su destino. El receptor también utiliza información de la base de datos para descifrar la comunicación, verificar que los paquetes no se hayan modificado, volver a ensamblar los paquetes y entregarlos en su destino final.
Administración de claves: La generación y distribución de claves para los algoritmos criptográficos y SPI.
Mecanismos de seguridad: Los algoritmos de autenticación y cifrado que protegen los datos de los datagramas IP.
Base de datos de directivas de seguridad (SPD): La base de datos que especifica el nivel de protección que se aplica a un paquete. SPD filtra el tráfico IP para determinar el modo en que se deben procesar los paquetes. Un paquete puede descartarse, transferirse sin codificar o protegerse con IPsec. Para los paquetes salientes, SPD y SADB determinan el nivel de protección que se aplicará. Para los paquetes entrantes, SPD permite determinar si el nivel de protección del paquete es aceptable. Si el paquete se protege con IPsec, SPD se consulta una vez descifrado y verificado el paquete.
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:
Los SA por socket modifican su entrada de puerto correspondiente en SPD.
Además, si el socket de un puerto está conectado y posteriormente se aplica la directiva IPsec a ese puerto, el tráfico que utiliza ese socket no está protegido mediante IPsec.
Naturalmente, un socket abierto en un puerto después de la aplicación de la directiva IPsec en el puerto está protegido con 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:
RFC 2411, "IP Security Document Roadmap", noviembre de 1998.
RFC 2401, "Security Architecture for the Internet Protocol", noviembre de 1998.
RFC 2402, "IP Authentication Header", noviembre de 1998.
RFC 2406, "IP Encapsulating Security Payload (ESP)", noviembre de 1998.
RFC 2408, "Internet Security Association and Key Management Protocol (ISAKMP)", noviembre de 1998.
RFC 2407, "The Internet IP Security Domain of Interpretation for ISAKMP", noviembre de 1998
RFC 2409, "The Internet Key Exchange (IKE)", noviembre de 1998.
RFC 3554, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", julio de 2003 [sin implementar en la versión Solaris 10]
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. |
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. |
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.
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 protocolo de seguridad (AH o ESP)
La dirección IP de destino
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.
Para obtener una descripción completa de SADB IPsec, consulte Base de datos de asociaciones de seguridad para IPsec.
Para obtener más información sobre cómo administrar SADB, consulte la página del comando man pf_key(7P).
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:
svc:/network/ipsec/ike:default service – es el servicio SMF para la administración automática de claves. El servicio ike ejecuta el daemon in.iked para proporcionar administración automática de claves. Para ver una descripción de IKE, consulte el Capítulo 22Intercambio de claves de Internet (descripción general). Para obtener más información sobre el daemon in.iked, consulte la página de comando man in.iked(1M) Para obtener información sobre el servicio ike, consulte Utilidad de gestión de servicios de IKE.
svc:/network/ipsec/manual-key:default service – es el servicio SMF para la administración manual de claves. El servicio de manual-key ejecuta el comando ipseckey con varias opciones para administrar claves manualmente. Para ver una descripción del comando ipseckey, consulte Utilidades para la generación de claves en IPsec. Para obtener más información sobre las opciones del comando ipseckey, consulte la página de comando man ipseckey(1M).
En las versiones anteriores a Solaris 10 4/09 los comandos en.iked e ipseckey administran material de claves.
El daemon in.iked proporciona administración de claves automática. Para ver una descripción de IKE, consulte el Capítulo 22Intercambio de claves de Internet (descripción general). Para obtener más información sobre el daemon in.iked, consulte la página de comando man in.iked(1M).
El comando ipseckey proporciona administración de claves manual. Para ver una descripción del comando, consulte Utilidades para la generación de claves en IPsec. Para obtener más información sobre las opciones del comando ipseckey, consulte la página de comando man ipseckey(1M).
IPsec proporciona dos protocolos de seguridad para proteger los datos:
Encabezado de autenticación (AH)
Carga de seguridad encapsuladora (ESP)
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.
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 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.
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.
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.
La tabla siguiente compara las protecciones que proporcionan AH y ESP.
Tabla 19–2 Protecciones que proporcionan AH y ESP 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:
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.
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.
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.
A partir de la versión Solaris 10 7/07, el contenido de Solaris Encryption Kit se instala mediante el disco de instalación de Solaris. En esta versión se añaden los algoritmos de autenticación SHA2: sha256, sha384 y sha512. Las implementaciones SHA2 cumplen la especificación RFC 4868. Esta versión también agrega grupos Diffie-Hellman más grandes: 2048 bits (grupo 14), 3072 bits (grupo 15) y 4096 bits (grupo 16). Tenga en cuenta que los sistemas de Sun con tecnología CoolThreads sólo aceleran los grupos de 2048 bits.
Antes de la versión Solaris 10 7/07, el disco de instalación de Solaris proporciona algoritmos básicos, además puede añadir algoritmos más complejos desde Solaris Encryption Kit.
De modo predeterminado, están instalados los algoritmos DES-CBC, 3DES-CBC, AES-CBC, y Blowfish-CBC. Los tamaños de claves que admiten los algoritmos AES-CBC y Blowfish-CBC están limitados a 128 bits.
Los algoritmos AES-CBC y Blowfish-CBC que admiten tamaños de claves de más de 128 bits están disponibles para IPsec cuando se instala el Solaris Encryption Kit. Sin embargo, no todos los algoritmos de cifrado están disponibles fuera de Estados Unidos. El kit está disponible en un CD independiente que no forma parte del paquete de instalación de Solaris 10. En la Solaris 10 Encryption Kit Installation Guide se describe cómo instalar el kit. Para obtener más información, visite el sitio web de descargas de Sun. Para descargar el kit, haga clic en la ficha Downloads A-Z y, a continuación, haga clic en la letra S. Encontrará Solaris 10 Encryption Kit entre las 20 primeras entradas.
Las directivas de protección IPsec pueden utilizar cualquiera de los mecanismos de seguridad. Las directivas IPsec se pueden aplicar en los niveles siguientes:
En el sistema
Por socket
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).
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, el encabezado exterior determina la directiva IPsec que protege el paquete IP interior.
En modo túnel, el paquete IP interior determina la directiva IPsec que protege su contenido.
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.
En modo transporte, ESP protege los datos tal como se muestra en la figura siguiente. El área sombreada muestra la parte cifrada del paquete.
En modo transporte, AH protege los datos como se muestra en la figura siguiente.
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.
El comando ipsecconf incluye palabras clave para configurar túneles en modo túnel o en modo transporte.
Para obtener detalles sobre la directiva por socket, consulte la página del comando man ipsec(7P).
Si desea ver un ejemplo de la directiva por socket, consulte Cómo utilizar IPsec para proteger un servidor web del tráfico que no procede de Internet.
Para más información acerca de los túneles, consulte la página del comando man ipsecconf(1M).
Para ver un ejemplo de configuración de túnel, consulte Cómo proteger una VPN con un túnel IPsec en modo túnel mediante IPv4.
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.
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.
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:
NAT-T funciona sólo en redes IPv4.
NAT-T no puede aprovechar la aceleración ESP IPsec que proporciona la placa de Sun Crypto Accelerator 4000. Sin embargo, la aceleración IKE con la placa Sun Crypto Accelerator 4000 funciona.
El protocolo AH depende de un encabezado de IP inalterable; por lo tanto, AH no funciona con NAT-T. El protocolo ESP se utiliza con NAT-T.
El cuadro NAT no utiliza reglas de procesamiento especiales. Un cuadro NAT con reglas de procesamiento IPsec especiales podría interferir con la implementación de NAT-T.
NAT-T sólo funciona cuando el iniciador IKE es el sistema que hay detrás del cuadro NAT. Un contestador IKE no puede estar detrás de un cuadro NAT a menos que el cuadro se haya programado para reenviar paquetes IKE al sistema individual adecuado detrás del cuadro.
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.
RFC 3022, "Traditional IP Network Address Translator (Traditional NAT)", enero de 2001.
RFC 3715, "IPsec-Network Address Translation (NAT) Compatibility Requirements", marzo de 2004.
RFC 3947, "Negotiation of NAT-Traversal in the IKE", enero de 2005.
RFC 3948, "UDP Encapsulation of IPsec Packets", enero de 2005.
Para utilizar IPsec en una NAT, consulte Configuración de IKE para sistemas portátiles (mapa de tareas).
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 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 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.
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.
Si desea obtener instrucciones sobre la implementación de IPsec en la red, consulte Protección del tráfico con IPsec (mapa de tareas).
Para mas información sobre los archivos y las utilidades IPsec, consulte el Capítulo 21Arquitectura de seguridad IP (referencia).
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. | |
svc:/network/ipsec/manual-key |
En la versión actual, el servicio SMF que gestiona asociaciones de seguridad manuales (SA). | |
svc:/network/ipsec/policy |
En la versión actual, el servicio SMF que gestiona la directiva IPsec. | |
svc: /network/ipsec/ike |
En la versión actual, el servicio SMF para la gestión automática de IPsec SA. | |
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. | |
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. | |
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. | |
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. | |
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. | |
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. |
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:
Cuando se conecta una placa Sun Crypto Accelerator 4000, ésta coloca en caché automáticamente las SA IPsec para los paquetes que utilizan la interfaz Ethernet de la placa. La placa también acelera el procesamiento de las SA IPsec.
IPsec puede aprovechar la administración de claves automática con IKE a través de redes IPv6. Para más información, consulte el Capítulo 22Intercambio de claves de Internet (descripción general).
Para conocer las novedades IKE, consulte Cambios de IKE en Solaris 10.
Encontrará más ayuda en el analizador del comando ipseckey. El comando ipseckey monitor incluye indicaciones de fecha y hora en cada evento. Para obtener más información, consulte la página del comando man ipseckey(1M).
Los algoritmos IPsec ahora provienen de una ubicación de almacenamiento central, la estructura criptográfica de Solaris. La página del comando man ipsecalgs(1M) describe las características de los algoritmos que hay disponibles. Los algoritmos están optimizados para la arquitectura en la que se ejecutan. Para obtener una descripción de la estructura, consulte el Capítulo 13, Oracle Solaris Cryptographic Framework (Overview) de System Administration Guide: Security Services.
IPsec funciona en la zona global. La directiva IPsec se administra en la zona global para una zona no global. El material de claves se crea y administra manualmente en la zona global para una zona no global. IKE no se puede utilizar para generar claves para una zona no global. Para obtener más 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.
La directiva IPsec puede funcionar con el protocolo SCTP (Streams Control Transmission Protocol) y el número de puerto SCTP. Sin embargo, la implementación no está completa. Las extensiones IPsec para SCTP que se especifican en la RFC 3554 todavía no están implementadas. Estas limitaciones pueden ocasionar complicaciones a la hora de crear la directiva IPsec para SCTP. Para obtener más información, consulte las RFC. Asimismo, lea IPsec y SCTP y Protocolo SCTP.
IPsec e IKE pueden proteger el tráfico que se origina detrás de un cuadro NAT. Para obtener más detalles e información sobre las limitaciones, consulte Paso a través de IPsec y NAT. Para ver los procedimientos, consulte Configuración de IKE para sistemas portátiles (mapa de 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).
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. | |
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. | |
Generar números aleatorios. |
Genera números aleatorios para el material de claves para las asociaciones de seguridad creadas manualmente. | |
Crear o reemplazar asociaciones de seguridad manualmente. |
Proporciona los datos básicos para las asociaciones de seguridad:
| |
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. | |
(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. | |
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. | |
Configurar una red privada virtual protegida (VPN). |
Configura IPsec entre dos sistemas separados por Internet. |
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:
IPsec y zonas: Para administrar la directiva IPsec y las claves para una zona no global IP compartida, cree el archivo de directiva IPsec en la zona global y ejecute los comandos de configuración de IPsec desde la zona global. Utilice la dirección de origen que corresponda a la zona no global que se esté configurando. También puede configurar la directiva IPsec y las claves en la zona global para la zona global. Para una zona de IP exclusiva, debe configurar directiva IPsec en la zona no global. A partir de la versión Solaris 10 7/07, puede utilizar IKE para administrar claves en una zona no global.
IPsec y RBAC – Para utilizar los roles para administrar IPsec, consulte el Capítulo 9, Using Role-Based Access Control (Tasks) de System Administration Guide: Security Services. Si desea ver un ejemplo, consulte Cómo configurar una función para la seguridad de la red.
IPsec y SCTP – IPsec se puede utilizar para proteger las asociaciones SCTP (Streams Control Transmission Protocol), pero debe hacerse con precaución. Para obtener más información, consulte IPsec y SCTP.
Este procedimiento presupone la siguiente configuración:
Los dos sistemas se denominan enigma y partym.
Cada sistema tiene dos direcciones, una dirección IPv4 y otra IPv6.
Cada sistema requiere ESP cifrado con el algoritmo AES, que, a su vez, requiere una clave de 128 bits y autenticación ESP con el resumen de mensajes de SHA1, que, a su vez, requiere una clave de 160 bits.
Cada sistema utiliza asociaciones de seguridad compartidas.
Con las asociaciones de seguridad (SA) compartidas, sólo se necesita un par de SA para proteger los dos sistemas.
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.
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.
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.
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.
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 |
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.
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.
Agregue una entrada de directiva IPsec al archivo ipsecinit.conf.
En el sistema enigma, agregue la directiva siguiente:
{laddr enigma raddr partym} ipsec {encr_algs aes encr_auth_algs sha1 sa shared} |
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).
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.
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.
Configure IKE siguiendo uno de los métodos de configuración de Configuración de IKE (mapa de tareas). Para ver la sintaxis del archivo de configuración de IKE, consulte la página del comando man ike.config(4).
Para agregar las SA manualmente, consulte Cómo crear manualmente asociaciones de seguridad IPsec.
Habilite la directiva IPsec.
Si está ejecutando una versión anterior a Solaris 10 4/09, reinicie el sistema.
# init 6 |
A continuación, vaya a Cómo verificar que los paquetes estén protegidos con IPsec.
A partir de la versión Solaris 10 4/09, actualice el servicio IPsec y habilite el servicio de administración de claves.
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.
# 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 |
Active las claves para IPsec.
Compruebe que los paquetes se estén protegiendo.
Para ver el procedimiento, consulte Cómo verificar que los paquetes estén protegidos con IPsec.
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).
En primer lugar, el administrador realiza del Paso 2 al Paso 5 del procedimiento anterior para configurar el primer sistema.
A continuación, en una ventana de terminal distinta, el administrador utiliza el comando ssh para iniciar la sesión en el segundo sistema.
local-system # ssh other-system other-system # |
En la ventana de terminal de la sesión ssh, el administrador configura la directiva IPsec y las claves del segundo sistema; para ello, realiza del Paso 2 al Paso 6.
A continuación, el administrador termina la sesión ssh.
other-system # exit local-system # |
Por último, el administrador realiza el Paso 6 para habilitar la directiva IPsec en el primer sistema.
La próxima ocasión que los dos sistemas se comunican, incluida la conexión ssh, la comunicación queda protegida por IPsec.
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:
Si ha utilizado IKE para crear material de claves, detenga y reinicie el daemon in.iked.
# pkill in.iked # /usr/lib/inet/in.iked |
Si ha agregado claves manualmente, utilice el comando ipseckey para agregar las SA a la base de datos.
# ipseckey -c -f /etc/inet/secret/ipseckeys |
A continuación, active la directiva IPsec con el comando ipsecconf.
# ipsecconf -a /etc/inet/ipsecinit.conf |
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.
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.
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:
Que la comunicación entre los dos sistemas esté protegida por IPsec.
Que se esté generando material de claves, ya sea de forma manual o mediante IKE.
Que haya comprobado que los paquetes se estén protegiendo.
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.
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.
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.
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.
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.
Compruebe la sintaxis del archivo de directiva IPsec.
# ipsecconf -c -f /etc/inet/ipsecinit.conf |
Actualice la directiva IPsec.
# svcadm refresh svc:/network/ipsec/policy:default |
Actualice las claves para IPsec.
Si ha configurado IKE en el Paso 5 de Cómo proteger el tráfico entre dos sistemas con IPsec, reinicie el servicio ike.
# svcadm restart svc:/network/ipsec/ike |
Si ha configurado manualmente las claves en el Paso 5 de Cómo proteger el tráfico entre dos sistemas con IPsec, actualice el servicio manual-key.
# svcadm refresh svc:/network/ipsec/manual-key:default |
La configuración se ha completado. Si lo desea, puede llevar a cabo el Paso 12.
Cree un archivo en el directorio /etc/inet para la directiva del servidor web.
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.
Copie el contenido del archivo que haya creado en el Paso 8 en el archivo /etc/inet/ipsecinit.conf.
Proteja el archivo IPsecWebInitFile con permisos de sólo lectura.
# chmod 400 IPsecWebInitFile |
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 |
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.
(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.
Puede ver las directivas configuradas en el sistema ejecutando el comando ipsecconf sin argumentos.
Debe ejecutar el comando ipsecconf en la zona global. Para una zona de IP exclusiva, ejecute el comando ipsecconf en la zona no global.
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.
Visualizar las directivas de IPsec.
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.
Visualice las entradas de la directiva IPsec en el orden en que se produzca una coincidencia.
$ ipsecconf -l |
Visualice las entradas de la directiva IPsec, incluidas las entradas por túnel, en el orden en que se produzca una coincidencia.
$ ipsecconf -L |
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.
Genere números aleatorios en formato hexadecimal.
% od -x|-X -A n file | head -n |
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.
Muestra el vaciado octal en formato hexadecimal. Dicho formato se imprime en bloques de 8 caracteres.
Elimina la base de desfase de entrada de la pantalla.
Actúa como origen para los números aleatorios.
Limita el resultado de la pantalla a las primeras n líneas.
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.
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.
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.
Debe estar en la zona global para administrar material de claves para una zona IP compartida.
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.
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.
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.
Cree las SA.
Active el modo de comando ipseckey.
# ipseckey > |
El símbolo del sistema > indica que se encuentra en modo de comando ipseckey.
Si está sustituyendo las SA existentes, vacíelas.
> flush > |
Para evitar que un intruso interrumpa las SA, debe sustituir el material de claves.
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.
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.
Especifica esp o ah.
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.
Especifica la dirección IP de un sistema.
Especifica la dirección IP del sistema equivalente a dir.
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.
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.
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.
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 > |
El sistema equivalente debe utilizar el mismo material de claves y el mismo SPI.
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 > |
Las claves y el SPI pueden ser diferentes para cada SA. Debe asignar claves y SPI distintos para cada SA.
Para salir del modo de comando ipseckey, pulse Control-D o escriba quit.
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.
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 |
Proteja el archivo con permisos de sólo lectura.
# chmod 400 /etc/inet/secret/ipseckeys |
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 |
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.
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.
En primer lugar, el administrador completa Cómo generar números aleatorios en un sistema Solaris para generar las claves.
A continuación, el administrador utiliza las claves generadas en el archivo /etc/inet/secreto/.
El administrador ha utilizado los mismos algoritmos. Por tanto, el administrador cambia los valores de SPI, encrkey y authkey sólo:
add esp spi 0x8xzy1492 \ src 192.168.116.16 dst 192.168.13.213 \ encr_alg aes \ auth_alg sha1 \ encrkey 0a1f3886b06ebd7d39f6f89e4c29c93f2741c6fa598a38af969907a29ab1b42a \ authkey a7230aabf513f35785da73e33b064608be41f69a # # add esp spi 0x177xce34\ src 192.168.13.213 dst 192.168.116.16 \ encr_alg aes \ auth_alg sha1 \ encrkey 4ef5be40bf93498017b2151d788bb37e372f091add9b11149fba42435fefe328 \ authkey 0e1875d9ff8e42ab652766a5cad49f38c9152821 |
Por último, el administrador reinicia el servicio manual-key. El comando de reinicio borra las claves anteriores antes de agregar las nuevas.
# svcadm restart manual-key |
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:
AH: Prefijo que indica que AH esta protegiendo los encabezados. El prefijo AH: aparece si se utiliza auth_alg para proteger el tráfico.
ESP: Prefijo que indica que se están enviando los datos cifrados. ESP: aparece si se utiliza encr_auth_alg o encr_alg para proteger el tráfico.
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.
Conviértase en superusuario en un sistema, por ejemplo partym.
% su - Password: Type root password # |
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) |
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 |
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 ----- ... |
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.
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.
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).
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.
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.
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:
El administrador asigna el nombre de LinkWifi a la primera función.
El administrador asigna los perfiles de derechos wifi de red, seguridad de vínculos de red y gestión de red a la función.
A continuación, el administrador asigna la función LinkWifi a los usuarios pertinentes.
El administrador asigna el nombre de IPsec Administrator a la segunda función.
El administrador asigna los perfiles de derechos de gestión de red IPsec y de gestión de red a la función.
A continuación, el administrador asigna la función de administrador de IPsec a los usuarios pertinentes.
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.
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 |
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 |
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 |
Si modifica la tabla de algoritmos y los protocolos IPsec, actualice el servicio ipsecalgs.
# svcadm refresh svc:/network/ipsec/ipsecalgs |
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.
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.
Para ver ejemplos de las directivas de IPsec para los túneles en modo túnel, consulte Ejemplos de protección de una VPN con IPsec mediante el uso de túneles en modo túnel.
Para ver los procedimientos que protegen las VPN, consulte Protección de una VPN con IPsec (mapa de tareas) .
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 |
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} |
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} |
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} |
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} |
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. | ||
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. |
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.
Cada sistema utiliza un espacio de dirección 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.
Cada sistema cuenta con dos interfaces. La interfaz hme0 se conecta a Internet. En este ejemplo, las direcciones IP de Internet empiezan por 192.168. La interfaz hme1 se conecta a la LAN de la compañía, es decir, a su intranet. En este ejemplo, las direcciones IP de la intranet empiezan por el número 10.
Cada sistema requiere autenticación ESP con el algoritmo SHA-1. El algoritmo SHA–1 requiere una clave de 160 bits.
Cada sistema requiere cifrado ESP con el algoritmo AES. El algoritmo AES utiliza una clave de 128 o 256 bits.
Cada sistema puede conectarse a un enrutador que tenga acceso directo a Internet.
Cada sistema utiliza asociaciones de seguridad compartidas.
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 |
|
|
||
Interfaz de la intranet del sistema |
|
|
||
La dirección de intranet del sistema, también dirección -punto en el Paso 7 |
|
|
||
Interfaz de Internet del sistema |
|
|
||
Dirección de Internet del sistema, también dirección tsrc en el Paso 7 |
|
|
||
Nombre del enrutador de Internet |
|
|
||
Dirección del enrutador de Internet |
|
|
||
Nombre de túnel |
|
|
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 |
|
|
||
Dirección de Internet del sistema |
|
|
||
Dirección del enrutador de Internet |
|
|
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.
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.
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.
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.
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.
Controle el flujo de paquetes antes de configurar IPsec.
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).
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.
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 .
Desactive la mayoría de los servicios de red, y posiblemente todos.
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 |
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 |
Agregue un par de SA entre los dos sistemas.
Elija una de las siguientes opciones:
Configure IKE para administrar las claves para las SA. Utilice uno de los procedimientos de Configuración de IKE (mapa de tareas) para configurar IKE para la VPN.
Si tiene motivos para administrar las claves manualmente, consulte Cómo crear manualmente asociaciones de seguridad IPsec.
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.
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} |
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} |
(Opcional) Compruebe la sintaxis del archivo de directiva IPsec.
# ipsecconf -c -f /etc/inet/ipsecinit.conf |
Para configurar el túnel y protegerlo con IPsec, siga los pasos descritos en función de la versión de Solaris:
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 |
Proteja el túnel con la directiva IPsec que ha creado.
# svcadm refresh svc:/network/ipsec/policy:default |
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 |
Active el reenvío de IP para la interfaz hme1.
En el sistema enigma, agregue la entrada del enrutador al archivo /etc/hostname.hme1.
192.168.116.16 router |
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.
Asegúrese de que los protocolos de enrutamiento no publiquen la ruta predeterminada en la intranet.
En el sistema enigma, agregue el indicador private al archivo /etc/hostname.hme0.
10.16.16.6 private |
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.
Agregue manualmente una ruta predeterminada a través de la interfaz hme0.
La ruta predeterminada debe ser un enrutador con acceso directo a Internet.
En el sistema enigma, agregue la ruta siguiente:
# route add default 192.168.116.4 |
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).
Para completar el procedimiento, vaya al Paso 22 para ejecutar un protocolo de enrutamiento.
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 |
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 |
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 |
Proteja el túnel con la directiva IPsec que ha creado.
# ipsecconf |
Muestre el enrutador para el túnel.
# ifconfig ip.tun0 router up |
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.
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.
Agregue manualmente una ruta predeterminada a través de hme0.
La ruta predeterminada debe ser un enrutador con acceso directo a Internet.
En el sistema enigma, agregue la ruta siguiente:
# route add default 192.168.116.4 |
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).
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 |
Configure los archivos de interfaz para transferir los parámetros correctos al daemon de enrutamiento.
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 |
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 |
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.
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:
En ambos sistemas, el administrador completa los cinco primeros pasos de Cómo proteger una VPN con un túnel IPsec en modo túnel mediante IPv4.
El administrador utiliza el comando ifconfig para conectar y configurar un túnel temporal.
system1 # ifconfig ip.tun0 plumb system1 # ifconfig ip.tun0 10.16.16.6 10.1.3.3 \ tsrc 192.168.116.16 tdst 192.168.13.213 # ssh system2 Password: admin-password-on-system2 system2 # ifconfig ip.tun0 plumb system2 # ifconfig ip.tun0 10.1.3.3 10.16.16.6 \ tsrc 192.168.13.213 tdst 192.168.116.16 |
El administrador habilita la directiva IPsec en el túnel. La directiva se creó en el Paso 4 de Cómo proteger una VPN con un túnel IPsec en modo túnel mediante IPv4.
system1 # svcadm refresh svc:/network/ipsec/policy:default system2 # svcadm refresh svc:/network/ipsec/policy:default |
El administrador realiza la interfaz de Internet y evita que los protocolos de enrutamiento pasen a través de la interfaz de la intranet.
system1 # ifconfig hme1 router ; ifconfig hme0 private system2 # ifconfig hme1 router ; ifconfig hme0 private |
El administrador agrega manualmente enrutamiento y ejecuta el protocolo de enrutamiento mediante el Paso 12 y el Paso 22 de Cómo proteger una VPN con un túnel IPsec en modo túnel mediante IPv4 en ambos sistemas.
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:
En ambos sistemas, el administrador completa los cinco primeros pasos de Cómo proteger una VPN con un túnel IPsec en modo túnel mediante IPv4.
El administrador conecta y configura el túnel.
system1 # ifconfig ip.tun0 plumb system1 # ifconfig ip.tun0 10.16.16.6 10.1.3.3 \ tsrc 192.168.116.16 tdst 192.168.13.213 \ encr_algs aes encr_auth_algs sha1 system1 # ifconfig ip.tun0 router up |
# ssh system2 Password: admin-password-on-system2 system2 # ifconfig ip.tun0 plumb system2 # ifconfig ip.tun0 10.1.3.3 10.16.16.6 \ tsrc 192.168.13.213 tdst 192.168.116.16 \ encr_algs aes encr_auth_algs sha1 system2 # ifconfig ip.tun0 router up |
El administrador habilita la directiva IPsec en el túnel. La directiva se creó en el Paso 4 de Cómo proteger una VPN con un túnel IPsec en modo túnel mediante IPv4.
system1 # svcadm refresh svc:/network/ipsec/policy:default system2 # svcadm refresh svc:/network/ipsec/policy:default |
El administrador convierte la interfaz de Internet en un enrutador y evita que los protocolos de enrutamiento pasen a través de la interfaz de la intranet.
system1 # ifconfig hme1 router ; ifconfig hme0 private system2 # ifconfig hme1 router ; ifconfig hme0 private |
El administrador agrega enrutamiento mediante la realización del Paso 12 y el Paso 22 de Cómo proteger una VPN con un túnel IPsec en modo túnel mediante IPv4 en ambos sistemas.
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} |
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} |
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} |
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.
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 |
|
|
||
Interfaz de la intranet del sistema |
|
|
||
Interfaz de Internet del sistema |
|
|
||
Dirección de intranet del sistema |
|
|
||
Dirección de Internet del sistema |
|
|
||
Nombre del enrutador de Internet |
|
|
||
Dirección del enrutador de Internet |
|
|
||
Nombre de túnel |
|
|
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.
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.
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.
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 |
Active los hosts múltiples de destino estricto de IP.
# ndd -set /dev/ip ip6_strict_dst_multihoming 1 |
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 .
Desactive la mayoría de los servicios de red, y posiblemente todos.
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 |
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 |
Agregue un par de SA entre los dos sistemas.
Elija una de las siguientes opciones:
Configure IKE para administrar las claves para las SA. Utilice uno de los procedimientos de Configuración de IKE (mapa de tareas) para configurar IKE para la VPN.
Si tiene motivos para administrar las claves manualmente, consulte Cómo crear manualmente asociaciones de seguridad IPsec.
Agregue una directiva IPsec para la VPN.
Edite el archivo /etc/inet/ipsecinit.conf para agregar la directiva IPsec para la VPN.
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} |
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} |
(Opcional) Compruebe la sintaxis del archivo de directiva IPsec.
# ipsecconf -c -f /etc/inet/ipsecinit.conf |
Para configurar el túnel y protegerlo con IPsec, siga los pasos en función de la versión de Solaris:
Configure el túnel, ip6.tun0, en el archivo /etc/hostname.ip6.tun0.
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 |
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 |
Proteja el túnel con la directiva IPsec que ha creado.
# svcadm refresh svc:/network/ipsec/policy:default |
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 |
Asegúrese de que los protocolos de enrutamiento no publiquen la ruta predeterminada en la intranet.
Agregue manualmente una ruta predeterminada a través de hme0.
Para completar el procedimiento, vaya al Paso 22 para ejecutar un protocolo de enrutamiento.
Configure un túnel seguro, ip6.tun0.
Los siguientes pasos configuran un túnel en un sistema que esté ejecutando una versión anterior a Solaris 10 4/09.
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 |
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 |
Proteja el túnel con la directiva IPsec que ha creado.
# ipsecconf |
Muestre el enrutador para el túnel.
# ifconfig ip6.tun0 router up |
En cada sistema, active el reenvío de IP para la interfaz hme1.
# ifconfig hme1 router |
Asegúrese de que los protocolos de enrutamiento no publiquen la ruta predeterminada en la intranet.
# ifconfig hme0 private |
Agregue manualmente una ruta predeterminada a través de hme0.
La ruta predeterminada debe ser un enrutador con acceso directo a Internet.
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.
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 |
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 |
En cada sistema, configure los archivos de interfaz para transferir los parámetros correctos al daemon de enrutamiento.
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 |
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 |
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.
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.
Lleve a cabo los pasos de este procedimiento en ambos sistemas.
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.
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.
Controle el flujo de paquetes antes de configurar IPsec.
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 |
Active los hosts múltiples de destino estricto de IP.
# ndd -set /dev/ip ip_strict_dst_multihoming 1 |
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 .
Desactive la mayoría de los servicios de red, y posiblemente todos.
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 |
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 |
Agregue un par de SA entre los dos sistemas.
Elija una de las siguientes opciones:
Configure IKE para administrar las claves para las SA. Utilice uno de los procedimientos de Configuración de IKE (mapa de tareas) para configurar IKE para la VPN.
Si tiene motivos para administrar las claves manualmente, consulte Cómo crear manualmente asociaciones de seguridad IPsec.
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.
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} |
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} |
(Opcional) Compruebe la sintaxis del archivo de directiva IPsec.
# ipsecconf -c -f /etc/inet/ipsecinit.conf |
Para configurar el túnel y protegerlo con IPsec, siga los pasos en función de la versión de Solaris:
Configure el túnel, ip.tun0, en el archivo /etc/hostname.ip.tun0.
Proteja el túnel con la directiva IPsec que ha creado.
# svcadm refresh svc:/network/ipsec/policy:default |
Para leer el contenido del archivo hostname.ip.tun0 en el núcleo, reinicie los servicios de red.
# svcadm restart svc:/network/initial:default |
Asegúrese de que los protocolos de enrutamiento no publiquen la ruta predeterminada en la intranet.
Agregue manualmente una ruta predeterminada a través de hme0.
Para completar el procedimiento, vaya al Paso 22 para ejecutar un protocolo de enrutamiento.
Configure el túnel, ip.tun0.
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 |
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 |
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 |
Proteja el túnel con la directiva IPsec que ha creado.
# ipsecconf |
Muestre el enrutador para el túnel.
# ifconfig ip.tun0 router up |
Active el reenvío de IP para la interfaz hme1.
# ifconfig hme1 router |
Asegúrese de que los protocolos de enrutamiento no publiquen la ruta predeterminada en la intranet.
# ifconfig hme0 private |
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 |
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 |
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 |
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 |
Configure los archivos de interfaz para transferir los parámetros correctos al daemon de enrutamiento.
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 |
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 |
Ejecute un protocolo de enrutamiento.
# routeadm -e ipv4-routing # routeadm -u |
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} |
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.
Para el Paso 4, la sintaxis del archivo ipsecinit.conf es la siguiente:
# LAN traffic to and from this address can bypass IPsec. {laddr 10.1.3.3 dir both} bypass {} # WAN traffic uses ESP with AES and SHA-1. {} ipsec {encr_algs aes encr_auth_algs sha1} |
Para el proceso del Paso 14 al Paso 16, la sintaxis para configurar un túnel seguro es la siguiente:
# 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 \ encr_algs aes encr_auth_algs sha1 # ifconfig ip.tun0 router up |
# 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 \ encr_algs aes encr_auth_algs sha1 |
La directiva IPsec que se transfiere a los comandos ifconfig debe ser la misma que la directiva IPsec del archivo ipsecinit.conf. Al reiniciar, cada sistema lee el archivo ipsecinit.conf para su directiva.
Para el Paso 20, la sintaxis del archivo hostname.ip.tun0 es la siguiente:
10.16.16.6 10.1.3.3 tsrc 192.168.116.16 \ tdst 192.168.13.213 encr_algs aes encr_auth_algs sha1 router up |
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.
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 |
|
|
||
Interfaz de la intranet del sistema |
|
|
||
Interfaz de Internet del sistema |
|
|
||
Dirección de intranet del sistema |
|
|
||
Dirección de Internet del sistema |
|
|
||
Nombre del enrutador de Internet |
|
|
||
Dirección del enrutador de Internet |
|
|
||
Nombre de túnel |
|
|
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.
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.
Controle el flujo de paquetes antes de configurar IPsec.
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 |
Active los hosts múltiples de destino estricto de IP.
# ndd -set /dev/ip ip6_strict_dst_multihoming 1 |
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 .
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 |
Agregue un par de SA entre los dos sistemas.
Elija una de las siguientes opciones:
Configure IKE para administrar las claves para las SA. Utilice uno de los procedimientos de Configuración de IKE (mapa de tareas) para configurar IKE para la VPN.
Si tiene motivos para administrar las claves manualmente, consulte Cómo crear manualmente asociaciones de seguridad IPsec.
Edite el archivo /etc/inet/ipsecinit.conf para agregar la directiva IPsec para la VPN.
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} |
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} |
(Opcional) Compruebe la sintaxis del archivo de directiva IPsec.
# ipsecconf -c -f /etc/inet/ipsecinit.conf |
Para configurar el túnel y protegerlo con IPsec, siga los pasos en función de la versión de Solaris:
Configure el túnel, ip6.tun0, en el archivo /etc/hostname.ip6.tun0.
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 |
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 |
Proteja el túnel con la directiva IPsec que ha creado.
# svcadm refresh svc:/network/ipsec/policy:default |
Para leer el contenido del archivo hostname.ip6.tun0 en el núcleo, reinicie los servicios de red.
# svcadm restart svc:/network/initial:default |
Asegúrese de que los protocolos de enrutamiento no publiquen la ruta predeterminada en la intranet.
Agregue manualmente una ruta predeterminada a través de hme0.
Para completar el procedimiento, vaya al Paso 22 para ejecutar un protocolo de enrutamiento.
Configure un túnel seguro, ip6.tun0.
Los siguientes pasos configuran un túnel en un sistema que esté ejecutando una versión anterior a Solaris 10 4/09.
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 |
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 |
Proteja el túnel con la directiva IPsec que ha creado.
# ipsecconf |
Muestre el enrutador para el túnel.
# ifconfig ip6.tun0 router up |
Active el reenvío de IP para la interfaz hme1.
# ifconfig hme1 router |
Asegúrese de que los protocolos de enrutamiento no publiquen la ruta predeterminada en la intranet.
# ifconfig hme0 private |
En cada sistema, agregue manualmente una ruta predeterminada mediante hme0.
La ruta predeterminada debe ser un enrutador con acceso directo a Internet.
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.
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 |
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 |
Configure los archivos de interfaz para transferir los parámetros correctos al daemon de enrutamiento.
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 |
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 |
Ejecute un protocolo de enrutamiento.
# routeadm -e ipv6-routing # routeadm -u |
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.
Para el Paso 4, la sintaxis del archivo ipsecinit.conf es la siguiente:
# 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. {} ipsec {encr_algs aes encr_auth_algs sha1} |
Para el proceso del Paso 14 al Paso 17, la sintaxis para configurar un túnel seguro es la siguiente:
# 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 \ encr_algs aes encr_auth_algs sha1 # ifconfig ip6.tun0 inet6 router up |
La directiva IPsec que se transfiere a los comandos ifconfig debe ser la misma que la directiva IPsec del archivo ipsecinit.conf. Al reiniciar, cada sistema lee el archivo ipsecinit.conf para su directiva.
Para el Paso 20, la sintaxis del archivo hostname6.ip6.tun0 es la siguiente:
6000:6666::aaaa:1116 6000:3333::eeee:1113 \ tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333 \ encr_algs aes encr_auth_algs sha1 router up |
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.
Lleve a cabo los pasos de este procedimiento en ambos sistemas.
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.
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>
Importe este manifiesto al depósito SMF.
# svccfg import /var/svc/manifest/site/spoof_check.xml |
Habilite el servicio ip_spoofcheck.
Utilice el nombre que se ha definido en el manifiesto, /site/ip_spoofcheck.
# svcadm enable /site/ip_spoofcheck |
Compruebe que el servicio ip_spoofcheck esté en línea.
# svcs /site/ip_spoofcheck |
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).
La utilidad de gestión de servicios (SMF) proporciona los siguientes servicios para IPsec:
svc:/network/ipsec/policy servicio – administra la directiva IPsec. Por defecto, este servicio está habilitado. El valor de la propiedad config_file determina la ubicación del archivo ipsecinit.conf. El valor inicial es /etc/inet/ipsecinit.conf.
svc:/network/ipsec/ipsecalgs servicio – Administra los algoritmos que están disponibles para IPsec. Por defecto, este servicio está habilitado.
svc:/network/ipsec/manual-key servicio - Activa la gestión manual de claves. Por defecto, este servicio está inhabilitado. El valor de la propiedad config_file determina la ubicación del archivo de configuración ipseckeys. El valor inicial es /etc/inet/secret/ipseckeys.
svc:/network/ipsec/ike servicio – Administra IKE. Por defecto, este servicio está inhabilitado. Si desea conocer las propiedades configurables, consulte Utilidad de gestión de servicios de IKE.
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).
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).
Para obtener información sobre cómo proteger los paquetes reenviados, consulte ifconfig(1M) y tun(7M).
Para conocer las opciones de directiva IPsec, consulte la página del comando man ipsecconf(1M).
Para obtener instrucciones sobre cómo utilizar el comando ipsecconf para proteger el tráfico entre los sistemas, consulte Configuración de IKE (mapa de tareas).
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).
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.
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. |
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:
La dirección de origen es un host que se puede buscar en la red.
El sistema de nombres está en peligro.
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.
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.
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).
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).
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:
¿Ha actualizado el material de claves? La actualización periódica de las claves es fundamental para garantizar la seguridad. La actualización de las claves protege contra posibles ataques de los algoritmos y las claves, y limita los daños a los que se expone una clave.
¿El TTY se transfiere por una red? ¿El comando ipseckey está en modo interactivo?
En modo interactivo, la seguridad del material de claves es la seguridad de la ruta de red para el tráfico de este TTY. Debe evitar el uso del comando ipseckey en una sesión rlogin o telnet de texto simple.
Incluso las ventanas locales podrían ser vulnerables a ataques de un programa oculto que lee los eventos de ventanas.
¿Ha utilizado la opción -f? ¿Se está accediendo al archivo a través de la red? ¿Todo el mundo puede leer el archivo?
Un adversario puede leer un archivo montado en red mientras se lee el archivo. Debe evitar el uso de un archivo con material de claves que pueda leer todo el mundo.
Proteja su sistema de nombres. Si se cumplen las dos condiciones siguientes, los nombres de host dejarán de ser de confianza:
La dirección de origen es un host que se puede buscar en la red.
El sistema de nombres está en peligro.
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.
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.
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} |
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.
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.
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.
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.
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.
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).
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.
La opción de socket SO_ALLZONES permite a IKE controlar el tráfico de las zonas no globales.
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.
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.
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.
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. |
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. |
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:
Parámetros globales, como los nombres de los certificados de claves públicas
Si se utiliza confidencialidad directa perfecta (PFS)
Las interfaces implicadas
Los protocolos de seguridad y sus algoritmos
El método de autenticación
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.
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.
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).
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).
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.
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).
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.
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
A partir de Solaris 9, IKE incluye las funciones siguientes:
IKE se puede utilizar para automatizar el intercambio de claves para IPsec en redes IPv6. Para más información, consulte Administración de claves con IKE.
IKE no se puede utilizar para administrar claves para IPsec en una zona no global.
Las operaciones de claves públicas de IKE se pueden acelerar mediante una placa de Sun Crypto Accelerator 1000 o una placa de Sun Crypto Accelerator 4000. Las operaciones se descargan en la placa. La descarga acelera el cifrado y reduce las exigencias con respecto al sistema operativo. Para mas información, consulte IKE y aceleración de hardware. Para conocer los procedimientos, consulte Configuración de IKE para buscar el hardware conectado (mapa de tareas).
Los certificados de claves públicas, las claves privadas y las claves públicas se pueden guardar en una placa de Sun Crypto Accelerator 4000. Para obtener más información sobre el almacenamiento de claves, consulte IKE y almacenamiento de hardware.
IKE se puede utilizar para automatizar el intercambio de claves para IPsec desde un enrutador NAT. El tráfico debe utilizar una red IPv4. Asimismo, las claves ESP IPsec a través de NAT no pueden acelerarse con hardware. Para más información, consulte Paso a través de IPsec y NAT. Para ver los procedimientos, consulte Configuración de IKE para sistemas portátiles (mapa de tareas).
Al archivo /etc/inet/ike/config se le han agregado parámetros de retransmisión y parámetros de tiempo de espera agotado de paquetes. Estos parámetros ajustan la negociación de IKE de fase 1 (modo principal) para administrar la interferencia de redes, el tráfico de red elevado y la interoperación con plataformas que tienen diferentes implementaciones del protocolo IKE. Para obtener más información sobre los parámetros, consulte la página del comando man ike.config(4) Para ver los procedimientos, consulte Cambio de los parámetros de transmisión de IKE (mapa de 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:
Configuración de IKE con claves previamente compartidas (mapa de tareas)
Configuración de IKE con certificados de clave pública (mapa de tareas)
Configuración de IKE para sistemas portátiles (mapa de tareas)
Configuración de IKE para buscar el hardware conectado (mapa de tareas)
Cambio de los parámetros de transmisión de IKE (mapa de tareas)
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).
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) |
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. | |
Actualizar claves previamente compartidas en un sistema IKE en ejecución |
Agrega nuevo material de claves para IKE en los sistemas que se comunican. | |
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. | |
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 |
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.
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.
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.
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.
En cada sistema, copie el archivo /etc/inet/ike/config.sample al archivo /etc/inet/ike/config.
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.
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 } |
Todos los argumentos del parámetro auth_method deben encontrarse en la misma línea.
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 } |
En cada sistema, compruebe la sintaxis del archivo.
# /usr/lib/inet/in.iked -c -f /etc/inet/ike/config |
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).
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.
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.
Cree el archivo /etc/inet/secret/ike.preshared en cada sistema.
Coloque la clave previamente compartida en cada archivo.
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 } |
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 } |
Las claves previamente compartidas de cada sistema deben ser idénticas.
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.
Este procedimiento presupone que desea reemplazar una clave previamente compartida a intervalos regulares.
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.
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.
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.
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.
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.
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.
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 |
Si el nivel de privilegio es 0x1 o 0x2, lea la nueva versión del archivo ike.preshared.
# ikeadm read preshared |
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.
Para llevar a cabo este procedimiento en una versión anterior a Solaris 10 4/09 consulte Ejemplo 23–2.
IKE se configura y el servicio ike se ejecuta.
Consulte las teclas previamente compartidas de IKE.
# ikeadm ikeadm> dump preshared |
Si aparece un mensaje de error, aumente el nivel de privilegios del daemon in.iked .
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 |
Aumente el nivel de privilegios del daemon in.iked en ejecución.
# svcadm refresh ike ; svcadm restart ike |
(Opcional) Confirme que el nivel de privilegios es keymat.
# svcprop -p config/admin_privilege ike keymat |
Ejecute de nuevo el Paso 1 para ver las teclas.
Devuelva al daemon IKE el nivel de privilegios base.
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.
En primer lugar, el administrador determina el nivel de privilegios del daemon in.iked.
adm1 # /usr/sbin/ikeadm get priv Current privilege level is 0x0, base privileges enabled |
Debido a que el nivel de privilegios no es 0x1 o 0x2, el administrador detiene el daemon in.iked y, a continuación, aumenta el nivel de privilegios a 2.
adm1 # pkill in.iked adm1 # /usr/lib/inet/in.iked -p 2 Setting privilege level to 2 |
El administrador muestra las claves.
adm1 # ikeadm dump preshared PSKEY: Preshared key (24 bytes): f47cb…/192 LOCIP: AF_INET: port 0, 192.168.116.16 (adm1). REMIP: AF_INET: port 0, 192.168.13.213 (com1). |
El administrador inicia sesión remota en el sistema de comunicación y determina que las claves sean idénticas.
A continuación, el administrador restablece el nivel básico de privilegios.
# ikeadm set priv base |
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.
Para llevar a cabo este procedimiento en una versión anterior a Solaris 10 4/09, consulte el Ejemplo 23–3.
Este procedimiento presupone lo siguiente:
El sistema enigma está configurado de acuerdo con lo descrito en Cómo configurar IKE con claves previamente compartidas.
El sistema enigma va a proteger su tráfico con un nuevo sistema, ada.
El daemon in.iked se ejecuta en ambos sistemas.
Las interfaces de los sistemas se incluyen como entradas en el archivo /etc/hosts de ambos sistemas. La entrada siguiente es un ejemplo.
192.168.15.7 ada 192.168.116.16 enigma |
Este procedimiento también funciona con una dirección IPv6 en el archivo /etc/inet/ipnodes. A partir de la versión Solaris 10 6/07 las entradas IPv6 se colocan en el archivo /etc/hosts.
Ha agregado una nueva entrada de directiva en el archivo /etc/inet/ipsecinit.conf en ambos sistemas. Las entradas tienen el siguiente aspecto:
# ipsecinit.conf file for enigma {laddr enigma raddr ada} ipsec {auth_algs any encr_algs any sa shared} |
# ipsecinit.conf file for ada {laddr ada raddr enigma} ipsec {auth_algs any encr_algs any sa shared} |
En la versión actual, ha comprobado la sintaxis del archivo /etc/inet/ipsecinit.conf en ambos sistemas mediante lo siguiente:
# ipsecconf -c -f /etc/inet/ipsecinit.conf |
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.
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.
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.
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.
Cree una regla para que IKE administre las claves para enigma y ada.
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 } |
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 } |
Asegúrese de que haya claves IKE previamente compartidas al iniciar.
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 } |
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 } |
En cada sistema, reinicie el servicio de directivas de IPsec para asegurar la interfaz agregada.
# svcadm restart policy |
En cada sistema, actualice el servicio ike.
# svcadm refresh ike |
Compruebe que los sistemas se puedan comunicar.
Consulte Verificación de que las claves IKE previamente compartidas sean idénticas.
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.
Antes de generar la nueva tecla, el administrador define el nivel de privilegios del daemon in.iked en 2.
# pkill in.iked # /usr/lib/inet/in.iked -p 2 Setting privilege level to 2 |
Después de enviar la tecla para el otro sistema y agregar la nueva tecla al sistema, el administrador reduce el nivel de privilegios.
# ikeadm set priv base |
A continuación, el administrador lee la nueva directiva IPsec en el núcleo.
# ipsecconf -a /etc/inet/ipsecinit.conf |
Por último, el administrador lee las nuevas reglas IKE en el núcleo.
# ikeadm read rules |
Si las claves previamente compartidas de los sistemas que se comunican no son idénticas, los sistemas no se podrán autenticar.
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.
Para llevar a cabo este procedimiento en una versión anterior a Solaris 10 4/09 consulte Ejemplo 23–2.
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.
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.
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 |
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). |
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.
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 |
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:
|
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:
|
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:
|
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. |
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).
Los certificados autofirmados requieren menos carga que los certificados públicos de una autoridad de certificación, pero no se escalan fácilmente.
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.
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.
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] |
Crea un certificado autofirmado.
Crea una solicitud de certificado. Para conocer el procedimiento, consulte Cómo configurar IKE con certificados firmados por una autoridad de certificación.
Es el tamaño de la clave. Tamaño_clave puede ser 512, 1024, 2048, 3072 o 4096.
Especifica el tipo de algoritmo que utilizar. Tipo_algoritmo puede ser rsa-sha1, rsa-md5 o dsa-sha1.
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.
Nombre alternativo del certificado. Nombre_alt tiene el formato tag=value. Las etiquetas válidas son IP, DNS, email y DN.
Proporciona un tiempo de inicio de validez absoluto o relativo para el certificado.
Proporciona un tiempo de fin de validez absoluto o relativo para el certificado.
Permite al token de hardware PKCS #11 generar las claves. Los certificados se guardan en el hardware.
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----- |
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----- |
Guarde el certificado y envíelo al sistema remoto.
El certificado se puede pegar en un mensaje de correo electrónico.
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----- |
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----- |
En cada sistema, agregue el certificado que reciba.
Copie la clave pública del correo electrónico del administrador.
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 |
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 |
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.
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 |
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 |
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.
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} } |
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 … |
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.
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" |
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.
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.
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.
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 |
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----- |
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----- |
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.
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.
En la consola del sistema, asuma el rol de administrador principal o conviértase en superusuario.
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 |
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 |
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 |
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.
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} } |
Todos los argumentos del parámetro auth_method deben encontrarse en la misma línea.
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 … |
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.
Cuando utiliza auth_method rsa_encrypt en el archivo ike/config, debe agregar el certificado equivalente a la base de datos publickeys.
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----- |
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:
Su certificado de clave pública
El certificado de la administración de certificación
El certificado de clave pública del equivalente
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.
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.
El hardware debe estar configurado.
El hardware utiliza la biblioteca /usr/lib/libpkcs11.so, a menos que la palabra clave pkcs11_path del archivo /etc/inet/ike/config haga referencia a una biblioteca distinta. La biblioteca debe implementarse de acuerdo con el estándar siguiente: RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki), es decir, una biblioteca PKCS #11.
Consulte Cómo configurar IKE para buscar la placa de Sun Crypto Accelerator 4000 para obtener instrucciones sobre la instalación.
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.
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.
Genere un certificado autofirmado o una solicitud de certificado y especifique el ID de símbolo.
Elija una de las siguientes opciones:
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).
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 |
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----- |
Envíe su certificado para que lo pueda utilizar la otra parte.
Elija una de las siguientes opciones:
Envíe el certificado autofirmado al sistema remoto.
El certificado se puede pegar en un mensaje de correo electrónico.
Envíe la solicitud de certificado a una organización que administre PKI.
Siga las instrucciones de la administración de PKI para enviar la solicitud de certificado. Para obtener información más detallada, consulte el Paso 3 de Cómo configurar IKE con certificados firmados por una autoridad de certificación.
En el sistema, edite el archivo /etc/inet/ike/config para que reconozca los certificados.
Elija una de las siguientes opciones.
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} } |
Coloque los certificados de la otra parte en el hardware.
Responda a la solicitud de PIN del mismo modo que en el Paso 3.
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.
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.
Debe indicar a IKE que omita las CRL si la organización de la autoridad de certificación no emite ninguna CRL. Esta opción se muestra en el Paso 6 en Cómo configurar IKE con certificados firmados por una autoridad de certificación.
Puede indicar a IKE que acceda a las CRL desde un indicador de recursos uniforme (URI) cuya dirección esté integrada en el certificado de clave pública de la autoridad de certificación.
Puede indicar a IKE que acceda a las CRL desde un servidor LDAP cuya entrada de nombre de directorio (DN) esté integrada en el certificado de clave pública de la autoridad de certificación.
Puede proporcionar la CRL como argumento para el comando ikecert certrldb. Si desea ver un ejemplo, consulte el Ejemplo 23–7.
El siguiente procedimiento describe cómo indicar a IKE que utilice las CRL de un punto de distribución central.
Visualice el certificado que ha recibido de la autoridad de certificación.
# ikecert certdb -lv certspec |
Enumera los certificados de la base de datos IKE.
Enumera los certificados en modo detallado. Utilice esta opción con precaución.
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.
Elija uno de los métodos siguientes para acceder a la CRL desde un punto de distribución central.
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 … |
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" |
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.
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 |
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. | |
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. | |
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. | |
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. | |
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. |
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.
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.
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.
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.
Configure el sistema central para que reconozca los sistemas portátiles.
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 |
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} |
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 } } |
Inicie sesión en cada sistema portátil y configure el sistema para buscar el sistema central.
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 |
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} |
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 } } |
Lea la configuración de IKE en el núcleo.
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} } |
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 } } |
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 } } |
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 } } |
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 .
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 |
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.
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.
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.
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.
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 # |
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.
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.
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.
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.
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 $ |
La placa Sun Crypto Accelerator 4000 admite claves de hasta 2048 bits para RSA. Para DSA, esta placa admite claves de hasta 1024 bits.
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.
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 |
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. | |
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. |
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.
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.
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.
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) |
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.
El número de retransmisiones antes de que se cancele cualquier negociación de IKE. De modo predeterminado, hay cinco intentos de IKE.
Intervalo inicial entre retransmisiones. Este intervalo se dobla hasta alcanzar el valor de retry_timer_max. El intervalo inicial es de 0,5 segundos.
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.
Lea la configuración que ha cambiado en el núcleo.
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 |
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 |
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).
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:
Propiedad config_file – es la ubicación del archivo de configuración IKE. El valor inicial es /etc/inet/ike/config.
Propiedad debug level – es el nivel de depuración del daemon in.iked. El valor inicial es op u operativos. Para ver los posibles valores, consulte la tabla de niveles de depuración en Object Types en la página de comando man ikeadm(1M).
Propiedad admin_privilege – es el nivel de privilegio del daemon in.iked. El valor inicial es base. Otros valores son modkeys y keymat. Para obtener más detalles, consulte Comando de administración de IKE.
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).
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.
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.
Puede utilizar el comando ikeadm para:
Ver aspectos del proceso del daemon IKE.
Cambiar los parámetros que se transfieren al daemon IKE.
Ver estadísticas sobre la creación de asociaciones de seguridad durante el intercambio de fase 1.
Depurar procesos de IKE.
Ver aspectos del estado de IKE.
Cambiar las propiedades del daemon IKE.
Ver estadísticas sobre la creación de asociaciones de seguridad durante el intercambio de fase 1.
Depurar los intercambios del protocolo IKE.
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.
No puede ver ni modificar el material de claves. El nivel base es el nivel de privilegio predeterminado.
Puede eliminar, cambiar y agregar claves previamente compartidas.
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.
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.
El archivo ike.preshared se crea al configurar el archivo ike/config para que requiera claves previamente compartidas. El material de claves se especifica para las asociaciones de seguridad de ISAKMP, es decir, para la autenticación IKE en el archivo ike.preshared. Dado que se utilizan claves previamente compartidas para autenticar el intercambio de fase 1, el archivo debe ser válido antes de iniciar el daemon in.iked.
El archivo ipseckeys contiene el material de claves para las asociaciones de seguridad de IPsec. Para ver ejemplos de la administración manual del archivo, consulte Cómo crear manualmente asociaciones de seguridad IPsec. El daemon IKE no utiliza este archivo. El material de claves que genera IKE para las asociaciones de seguridad de IPsec se almacena en el núcleo.
Las claves previamente compartidas no pueden utilizar el almacenamiento de hardware. Las claves previamente compartidas se generan y almacenan en el sistema.
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.
Solaris 10 1/06: A partir de esta versión, no es preciso especificar la biblioteca. De modo predeterminado, la biblioteca PKCS #11 es /usr/lib/libpkcs11.so.
Solaris 10: en esta versión, debe especificarse la entrada PKCS #11. De lo contrario, la opción -T del comando ikecert no funcionará. La entrada tiene el siguiente aspecto:
pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so" |
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).
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.
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 |
---|---|---|
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. |
||
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). |
|
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 |
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. |
|
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.
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.
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.
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).
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.
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.
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:
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
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:
Los enlaces de filtros de paquetes simplifican la configuración del filtro IP de Oracle Solaris.
Ahora se admite el uso de filtros de paquetes en las zonas.
El uso de enlaces de filtros mejora el rendimiento del filtro IP de Oracle Solaris.
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).
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).
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.
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.
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.
La secuencia de procesamiento de paquetes incluye:
Traducción de direcciones de red (NAT)
La traducción de una dirección IP privada a una dirección pública distinta, o la asignación de alias de múltiples direcciones privadas a una sola dirección pública. NAT permite a una organización resolver el problema del agotamiento de direcciones IP cuando cuenta con redes y necesita acceder a Internet.
Cuentas IP
Es posible configurar las reglas de entrada y salida por separado, y registrar el número de bytes que se transfieren. Cada vez que se produce una coincidencia de regla, el número de bytes del paquete se agrega a la regla y permite obtener las estadísticas de cascadas.
Comprobación de caché de fragmentación
Si el siguiente paquete del tráfico actual es un paquete y se ha permitido el paquete anterior, también se permitirá el fragmento de paquete y se omitirá la tabla de estado y la comprobación de reglas.
Comprobación de estado de paquete
Si en una regla se incluye keep state, todos los paquetes de una sesión específica se transfieren o bloquean automáticamente, según si la regla incluye pass o block.
Comprobación de cortafuegos
Las reglas de entrada y salida se pueden configurar por separado, y determinar si un paquete podrá transferirse a través del Filtro IP de Solaris a las rutinas TCP/IP del núcleo, o hacia la red.
Grupos
Los grupos permiten escribir un conjunto de reglas a modo de árbol.
Función
Una función es la acción que se va a emprender. Las posibles funciones son block, pass, literal y send ICMP response.
Ruta rápida
La ruta rápida señala al Filtro IP de Solaris que no debe transferir el paquete a la pila IP de UNIX para el enrutamiento, lo cual significa una reducción de TTL.
Autenticación IP
Los paquetes que se autentican sólo se transfieren una vez a través de bucles de cortafuegos para evitar el procesamiento doble.
Los servicios SMF svc: /network/pfil y svc: /network/ipfilter administran el filtro IP de OpenSolaris. Para ver una descripción completa de SMF, consulte el Capítulo 18, Managing Services (Overview) de System Administration Guide: Basic Administration. Si desea información detallada sobre los procedimientos asociados con SMF, consulte el Capítulo 19, Managing Services (Tasks) de System Administration Guide: Basic Administration.
El filtro IP de OpenSolaris requiere la edición directa de los archivos de configuración.
El filtro IP de OpenSolaris se instala con OpenSolaris. De modo predeterminado, el filtro IP de OpenSolaris no está activo en una instalación desde cero. Para configurar los filtros, debe editar los archivos de configuración y activar manualmente el filtro IP de OpenSolaris. Puede activar los filtros reiniciando el sistema o sondeando las interfaces con el comando ifconfig. Si desea más información, consulte la página de comando man ifconfig(1M) Para conocer las tareas asociadas con la activación del filtro IP de OpenSolaris, consulte Configuración del filtro IP de Oracle Solaris.
Para administrar el filtro IP de OpenSolaris, debe asumir un rol que incluya el perfil de derechos de administración del filtro IP o convertirse 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.
Las rutas de redes IP (IPMP) sólo admiten filtros sin estado.
Las configuraciones de Sun Cluster non admiten filtros con el filtro IP de OpenSolaris.
Los filtros entre zonas no se admiten con el 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.
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:
Conjuntos de reglas de filtros de paquetes
Conjuntos de reglas de traducción de direcciones de red (NAT)
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.
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.
Utilice la sintaxis siguiente para crear reglas de filtros de paquetes:
acción [in|out] opción palabra clave, palabra clave...
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.
Impide que el paquete se transfiera a través del filtro.
Permite que el paquete se transfiera a través del filtro.
Registra el paquete pero no determina si se bloquea o se transfiere. Utilice el comando ipmon para ver el registro.
Incluye el paquete en las estadísticas de filtro. Utilice el comando ipfstat para ver las estadísticas.
Hace que el filtro omita número reglas de filtros.
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á.
Solicita que el filtro consulte una lista autenticada previamente para determinar la acción que se llevará a cabo con el paquete.
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.
A continuación, puede elegir en una lista de opciones. Si utiliza más de una opción, debe hacerlo en el orden siguiente.
Registra el paquete si la regla es la última regla coincidente. Utilice el comando ipmon para ver el registro.
Ejecuta la regla que contiene la opción quick si hay coincidencia de paquetes. Se detiene cualquier comprobación de reglas adicional.
Aplica la regla sólo si el paquete se transfiere a la interfaz especificada o desde ella.
Copia el paquete y envía el duplicado de nombre_interfaz a una dirección IP especificada opcionalmente.
Transfiere el paquete a una cola de salida en nombre_interfaz.
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.
De modo predeterminado, cualquier paquete que no coincida con ninguna regla en el archivo de configuración se transfiere a través del filtro.
Filtra el paquete basándose en el valor de tipo de servicio expresado como entero decimal o hexadecimal.
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.
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.
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.
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.
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).
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.
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.
Crea un grupo para las reglas de filtros, que se indica mediante el número 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).
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.
La sintaxis siguiente permite crear reglas NAT:
comando nombre_interfaz parámetros
Cada regla empieza con uno de los comandos siguientes:
Asigna una red o dirección IP a otra red o dirección IP en un proceso por turnos.
Redirige los paquetes de una dirección IP y un par de puertos a otra dirección IP y otro par de puertos.
Establece una NAT bidireccional entre una dirección IP externa y una dirección IP interna.
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.
Después del comando, la siguiente palabra es el nombre de la interfaz, por ejemplo hme0.
A continuación, puede elegir entre una serie de parámetros, que determinan la configuración de NAT. Algunos de los parámetros son:
Designa la máscara de red.
Designa la dirección a la que se traduce ipmask.
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).
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.
Utilice la sintaxis siguiente para crear una agrupación de direcciones:
table role = role-name type = storage-format number = reference-number |
Define la referencia para las diferentes direcciones.
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.
Especifica el formato de almacenamiento de la agrupación.
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).
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.
Controlador pfil
Daemon pfil
Servicio SMF svc:/network/pfil
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 módulo pfil se utiliza con el filtro IP de Oracle Solaris en las siguientes versiones de Oracle Solaris 10
Solaris 10 3/05
Solaris 10 1/06
Solaris 10 6/06
Solaris 10 11/06
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.
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.
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.
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).
La tabla siguiente incluye la documentación de la página del comando man relativa al filtro IP de Oracle Solaris.
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:
Desactivación e inhabilitación de filtro IP de Oracle Solaris
Cómo visualizar las estadísticas e información sobre el filtro IP de Oracle Solaris
Creación y edición de archivos de 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. | |
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. | |
Activar filtrado en bucle |
De modo opcional, puede activar el filtrado en bucle, por ejemplo, para filtrar el tráfico entre zonas. |
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.
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.
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.
(Opcional) Cree un archivo de configuración de traducción de direcciones de red (NAT).
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.
(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.
(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.
Active el filtro IP de Oracle Solaris.
# svcadm enable network/ipfilter |
Puede volver a activar los filtros de paquetes que estén desactivados temporalmente.
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.
Habilite el filtro IP de Oracle Solaris y los filtros utilizando uno de los métodos siguientes:
Reinicie el equipo.
# reboot |
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:
Habilite el filtro IP de Oracle Solaris.
# ipf -E |
Active los filtros de paquetes.
# ipf -f filename |
(Opcional) Active NAT.
# ipnat -f filename |
La traducción de direcciones de red (NAT) no admite IPv6.
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.
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.
Detenga el filtro IP de Oracle Solaris si se está ejecutando.
# svcadm disable network/ipfilter |
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> ... |
Inicie el filtro IP de Oracle Solaris.
# svcadm enable network/ipfilter |
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 |
La desactivación del filtro de paquetes y NAT resulta útil en las siguientes circunstancias:
Para realizar pruebas
Para resolver problemas del sistema cuando se cree que los causa el filtro IP de Oracle Solaris
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. | |
Desactive NAT. |
Desactive NAT utilizando el comando ipnat. | |
Desactive los filtros de paquetes y NAT. |
Desactive los filtros de paquetes y NAT utilizando el comando ipf. |
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.
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.
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.
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.
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.
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.
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.
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.
Desactive los filtros de paquetes y permita a todos los paquetes pasar a la red.
# ipf –D |
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.
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.
Solaris 10 3/05
Solaris 10 1/06
Solaris 10 6/06
Solaris 10 11/06
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 | |
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. | |
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 |
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.
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.
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.
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 |
Active los cambios en el archivo /etc/ipf/pfil.ap reiniciando la instancia del servicio network/pfil.
# svcadm restart network/pfil |
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.
(Opcional) Cree un archivo de configuración de traducción de direcciones de red (NAT).
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.
(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.
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 |
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).
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.
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.
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 |
Active los cambios en el archivo /etc/ipf/pfil.ap reiniciando la instancia del servicio network/pfil.
# svcadm restart network/pfil |
Active la NIC siguiendo uno de estos métodos:
Reinicie el equipo.
# reboot |
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).
Siga el procedimiento de más abajo para detener los paquetes de filtros en una tarjeta NIC.
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.
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 |
Desactive la NIC utilizando uno de estos métodos:
Reinicie el equipo.
# reboot |
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:
Identifique el "major number" del dispositivo que está desactivando.
# grep hme /etc/name_to_major hme 7 |
Visualice la configuración actual de autopush para hme0.
# autopush -g -M 7 -m 0 Major Minor Lastminor Modules 7 ALL - pfil |
Elimine la configuración de autopush.
# autopush -r -M 7 -m 0 |
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).
Cuando esté resolviendo problemas del filtro IP de Oracle Solaris, puede ver las estadísticas de pfil.
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.
Visualice las estadísticas de pfil.
# ndd -get /dev/pfil qif_status |
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 |
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. | ||
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. | ||
Elimina las reglas NAT. | ||
Agrega las reglas adicionales 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. | ||
Elimina una agrupación de direcciones. | ||
Agrega reglas adicionales a una agrupación de direcciones. |
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.
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.
Visualice el conjunto de reglas de filtros de paquetes activo que se ha cargado en el núcleo.
# ipfstat -io |
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 |
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.
Visualice el conjunto de reglas de filtros de paquetes inactivo.
# ipfstat -I -io |
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 |
Siga este procedimiento para llevar a cabo una de las tareas siguientes:
Activar un conjunto de reglas de filtros de paquetes que no sea el que está utilizando el filtro IP de Oracle Solaris.
Volver a cargar el mismo conjunto de reglas de filtros que se ha actualizado.
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.
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.
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.
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.
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 |
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 |
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.
Elimine el conjunto de reglas.
# ipf -F [a|i|o] |
Elimina todas las reglas de filtros del conjunto de reglas.
Elimina las reglas de filtros de los paquetes entrantes.
Elimina las reglas de filtros de los paquetes salientes.
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) |
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.
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:
Cree un conjunto de reglas en el archivo que desee.
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.
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 |
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.
Cree un conjunto de reglas en el archivo que desee.
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.
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 |
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.
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.
El ejemplo siguiente muestra cómo el uso del comando ipf -s convierte el conjunto de reglas inactivo en el conjunto activo y viceversa.
Antes de ejecutar el comando ipf -s, el resultado del comando ipfstat -I -io muestra las reglas en el conjunto de reglas inactivo. El resultado del comando ipfstat - io muestra las reglas en el conjunto de reglas activo.
# 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 # 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 |
Después de ejecutar el comando ipf -s, el resultado de los comandos ipfstat -I -io y ipfstat -io muestra que el contenido de los dos conjuntos de reglas ha cambiado.
# ipf -s Set 1 now inactive # ipfstat -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 # 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 |
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.
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.
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.
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) |
Utilice el procedimiento siguiente para administrar, ver y modificar las reglas NAT.
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.
Visualice las reglas NAT activas.
# ipnat -l |
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: |
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.
Elimine las reglas NAT actuales.
# ipnat -C |
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: |
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.
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:
Cree reglas NAT adicionales en el archivo que desee.
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.
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: |
Utilice los procedimientos siguientes para administrar, ver y modificar las agrupaciones de direcciones.
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.
Visualice la agrupación de direcciones activa.
# ippool -l |
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; }; |
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.
Elimine las entradas de la agrupación de direcciones actual.
# ippool -F |
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 |
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.
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:
Cree agrupaciones de direcciones adicionales en el archivo que desee.
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.
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; }; |
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 |
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.
Visualice la tabla de estado.
# ipfstat |
Puede utilizar la opción -t para ver la tabla de estado en el formato de la utilidad.
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 |
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.
Visualice las estadísticas de estado.
# ipfstat -s |
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 |
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.
Ver las estadísticas de NAT.
# ipnat -s |
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 |
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.
Ver las estadísticas de la agrupación de direcciones.
# ippool -s |
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 |
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. | |
Guardar los paquetes registrados en un archivo. |
Guarda los paquetes registrados en un archivo para poder consultarlos posteriormente. |
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.
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.
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 |
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.
Cree el nuevo archivo de registro.
# touch /var/log/log-name |
Reinicie el servicio de registro del sistema.
# svcadm restart system-log |
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 |
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.
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.
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 |
Muestra el archivo de registro de estado.
Muestra al archivo de registro de NAT.
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 |
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).
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 |
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.
Vacíe el búfer de registro de paquetes.
# ipmon -F |
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 |
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.
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.
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) |
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:
El signo # indica que una línea contiene comentarios.
Los comentarios y las reglas pueden coexistir en la misma línea.
También se permite agregar espacios en blanco para facilitar la lectura de las reglas.
Las reglas pueden ocupar más de una línea. Utilice la barra inclinada inversa (\) al final de una línea para indicar que la regla continúa en la línea siguiente.
El procedimiento siguiente describe cómo configurar:
Los archivos de configuración de filtros de paquetes
Los archivos de configuración de reglas NAT
Los archivos de configuración de agrupaciones de direcciones
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.
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.
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.
Los ejemplos siguientes ilustran las reglas de filtros de paquetes que se utilizan en las configuraciones de filtros.
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.
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 |
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 |