Omitir Vínculos de navegación | |
Salir de la Vista de impresión | |
Protección de la red en Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library (Español) |
1. Uso de protección de enlaces en entornos virtualizados
3. Servidores web y el protocolo de capa de sockets seguros
4. Filtro IP en Oracle Solaris (descripción general)
6. Arquitectura de seguridad IP (descripción general)
7. Configuración de IPsec (tareas)
8. Arquitectura de seguridad IP (referencia)
9. Intercambio de claves de Internet (descripción general)
10. Configuración de IKE (tareas)
Visualización de información IKE
Cómo visualizar grupos y algoritmos disponibles para intercambios IKE de fase 1
Configuración de IKE (mapa de tareas)
Configuración de IKE con claves previamente compartidas (mapa de tareas)
Configuración de IKE con claves previamente compartidas
Cómo configurar IKE con claves previamente compartidas
Cómo actualizar IKE para un sistema equivalente nuevo
Configuración de IKE con certificados de clave pública (mapa de tareas)
Configuración de IKE con certificados de clave pública
Cómo configurar IKE con certificados de clave pública autofirmados
Cómo configurar IKE con certificados firmados por una autoridad de certificación
Cómo generar y almacenar certificados de clave pública en el hardware
Cómo administrar una lista de revocación de certificados
Configuración de IKE para sistemas portátiles (mapa de tareas)
Configuración de IKE para buscar el hardware conectado
Cómo configurar IKE para buscar la placa Sun Crypto Accelerator 6000
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 política 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.
Antes de empezar
Debe asumir el rol root. Para obtener más información, consulte Cómo usar los derechos administrativos que tiene asignados de Administración de Oracle Solaris 11.1: servicios de seguridad. Si inicia sesión de manera remota, utilice el comando ssh para un inicio de sesión remoto seguro. Si desea ver un ejemplo, consulte el Ejemplo 7-1.
El sistema central necesita una política que permite una amplia gama de direcciones IP. Los certificados de la política 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 sha256 sa shared}
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 # CA's public 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 aes auth_alg sha256 } }
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 central 192.xxx.xxx.x
El sistema portátil debe encontrar el sistema central por su dirección IP pública. Los sistemas deben configurar la misma política IPsec.
# /etc/inet/ipsecinit.conf on mobile # Find central {raddr 192.xxx.xxx.x} ipsec {encr_algs aes encr_auth_algs sha256 sa shared}
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 aes auth_alg sha256 } }
# svcadm enable svc:/network/ipsec/ike
Ejemplo 10-4 Configuración de un equipo para que acepte tráfico IPsec de un sistema portátil
IKE puede iniciar negociaciones desde un enrutador NAT. Sin embargo, la configuración de IKE ideal no incluye un enrutador NAT. En el ejemplo siguiente, el certificado público de una autoridad de certificación se colocó en el sistema portátil y en 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 10-5.
## /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 sha256 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 # CA's public 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 aes auth_alg sha256} p1_xform {auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha256} p1_xform {auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha256} p1_xform {auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha256} }
Ejemplo 10-5 Configuración de un sistema con una NAT con IPsec
En el ejemplo siguiente, el certificado público de una autoridad de certificación se coloca en el sistema portátil y en el sistema central. mobile1 se conecta a la oficina central de la compañía desde su 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 equipo en las oficinas de la compañía, consulte el Ejemplo 10-4.
## /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 sha256 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 aes auth_alg sha256 } }
Ejemplo 10-6 Aceptación de certificados autofirmados de un sistema portátil
En el ejemplo siguiente, se han emitido certificados autofirmados y se encuentran en el sistema portátil y el sistema central. main1 es el sistema de la compañía que puede aceptar conexiones desde sistemas remotos. Para configurar los sistemas remotos, consulte el Ejemplo 10-7.
## /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 sha256 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 aes auth_alg sha256 } }
Ejemplo 10-7 Uso de certificados autofirmados para contactar con un sistema central
En el ejemplo siguiente, mobile1 se conecta a la oficina central de la compañía desde casa. Los certificados se han emitido y se colocan en el sistema portátil y el sistema central. La red ISP utiliza un enrutador NAT para permitir al ISP asignar a mobile1 una dirección privada. A continuación, el enrutador convierte la dirección privada en una dirección IP pública que comparte con otros nodos de red del ISP. La oficina central de la compañía no está detrás de un dispositivo NAT. Para configurar el sistema en las oficinas de la empresa, consulte el Ejemplo 10-6.
## /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 sha256 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 aes auth_alg sha256 } }
Pasos siguientes
Si no terminó de establecer la política IPsec, regrese al procedimiento IPsec para activar o refrescar la política IPsec.