Konfiguration von IKE für mobile Systeme

Wenn Heimbüros und mobile Laptops ordnungsgemäß konfiguriert wurden, können IPsec und IKE die Kommunikation mit den Computern am Unternehmenssitz schützen. Eine umfassende IPsec-Richtlinie, kombiniert mit einer PublicKey-Authentifizierungsmethode, bietet Offsite-Systemen die Möglichkeit, ihren Datenverkehr mit einem zentralen System zu schützen.

So konfigurieren Sie IKE für Offsite-Systeme

IPsec und IKE erfordern eine einmalige ID, um Quelle und Ziel eindeutig identifizieren zu können. Bei offsite oder mobilen Systemen, die nicht über eine einmalige IP-Adresse verfügen, müssen Sie einen anderen ID-Typ verwenden. Beispielsweise kann ein System eindeutig mit ID-Typen wie DNS, DN oder E-Mail identifiziert werden.

Offsite oder mobile Systeme, die über einmalige IP-Adressen verfügen, werden dennoch besser mit einem anderen ID-Typ konfiguriert. Wenn die Systeme z. B. versuchen, über eine NAT-Box eine Verbindung mit einem zentralen Standort herzustellen, werden deren einmalige Adressen nicht verwendet. Eine NAT-Box weist eine zufällige IP-Adresse zu, die das zentrale System nicht erkennen würde.

PresharedKeys können ebenfalls nicht als Authentifizierungsmechanismus für mobile Systeme eingesetzt werden, da sie feststehende IP-Adressen benötigen. Selbst-signierte Zertifikate oder Zertifikate von einer PKI ermöglichen mobilen Systemen jedoch die Kommunikation mit einem zentralen Standort.

1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

   Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

   ---

   Hinweis - Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

   ---

2. Konfigurieren Sie das zentrale System, sodass es mobile Systeme erkennt.
   1. Richten Sie die /etc/hosts-Datei ein.

      Das zentrale System muss bestimmte Adressen für mobile Systeme nicht erkennen.

      # /etc/hosts on central
      central 192.xxx.xxx.x

   2. Richten Sie die ipsecinit.conf-Datei ein.

      Das zentrale System benötigt eine Richtlinie, die einen breiten Bereich an IP-Adressen zulässt. Später stellen Zertifikate in der IKE-Richtlinie sicher, dass Systeme, die eine Verbindung herzustellen versuchen, hierzu berechtigt sind.

      # /etc/inet/ipsecinit.conf on central
      # Keep everyone out unless they use this IPsec policy:
      {} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

   3. Richten Sie die ike.config-Datei ein.

      DNS identifiziert das zentrale System. Zur Authentifizierung des Systems werden Zertifikate verwendet.

      ## /etc/inet/ike/ike.config on central
      # Global parameters
      #
      # Find CRLs by URI, URL, or LDAP
      # Use CRL from organization's URI
      use_http
      #
      # Use web proxy
      proxy "http://somecache.domain:port/"
      #
      # Use LDAP server
      ldap_server   "ldap-server1.domain.org,ldap2.domain.org:port"
      #
      # List CA-signed certificates
      cert_root    "C=US, O=Domain Org, CN=Domain STATE"
      #
      # List self-signed certificates - trust server and enumerated others
      #cert_trust    "DNS=central.domain.org"
      #cert_trust    "DNS=mobile.domain.org"
      #cert_trust    "DN=CN=Domain Org STATE (CLASS), O=Domain Org
      #cert_trust    "email=root@central.domain.org"
      #cert_trust    "email=user1@mobile.domain.org"
      #
      
      # Rule for mobile systems with certificate
      {
        label "Mobile systems with certificate"
        local_id_type DNS
      
      # Any mobile system who knows my DNS or IP can find me.
      
        local_id "central.domain.org"
        local_addr 192.xxx.xxx.x
      
      # Root certificate ensures trust,
      # so allow any remote_id and any remote IP address.
        remote_id ""
        remote_addr 0.0.0.0/0
      
      p2_pfs 5
      
      p1_xform
      {auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
      }

3. Melden Sie sich bei jedem mobilen System an und konfigurieren Sie das System so, dass es das zentrale System findet.
   1. Richten Sie die /etc/hosts-Datei ein.

      Die /etc/hosts-Datei benötigt keine Adresse für das mobile System, kann aber eine bereitstellen. Die Datei muss eine öffentliche IP-Adresse für das zentrale System enthalten.

      # /etc/hosts on mobile
      mobile 10.x.x.xx
      central 192.xxx.xxx.x

   2. Richten Sie die ipsecinit.conf-Datei ein.

      Das mobile System muss das zentrale System über die öffentliche IP-Adresse finden können. Die Systeme müssen mit der gleichen IPsec-Richtlinie konfiguriert sein.

      # /etc/inet/ipsecinit.conf on mobile
      # Find central
      {raddr 192.xxx.xxx.x} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

   3. Richten Sie die ike.config-Datei ein.

      Als Bezeichner darf keine IP-Adresse verwendet werden. Für mobile Systeme sind die folgenden Bezeichner gültig:

      • DN=ldap-Verzeichnisname

      • DNS=Adresse-des-Domänennamenservers

      • email=E-Mail-Adresse

      Zur Authentifizierung des mobilen Systems werden Zertifikate verwendet.

      ## /etc/inet/ike/ike.config on mobile
      # Global parameters
      #
      # Find CRLs by URI, URL, or LDAP
      # Use CRL from organization's URI
      use_http
      #
      # Use web proxy
      proxy "http://somecache.domain:port/"
      #
      # Use LDAP server
      ldap_server   "ldap-server1.domain.org,ldap2.domain.org:port"
      #
      # List CA-signed certificates
      cert_root    "C=US, O=Domain Org, CN=Domain STATE"
      #
      # Self-signed certificates - trust me and enumerated others
      #cert_trust    "DNS=mobile.domain.org"
      #cert_trust    "DNS=central.domain.org"
      #cert_trust    "DN=CN=Domain Org STATE (CLASS), O=Domain Org
      #cert_trust    "email=user1@domain.org"
      #cert_trust    "email=root@central.domain.org"
      #
      # Rule for off-site systems with root certificate
      {
          label "Off-site mobile with certificate"
          local_id_type DNS
      
      # NAT-T can translate local_addr into any public IP address
      # central knows me by my DNS
      
          local_id "mobile.domain.org"
          local_addr 0.0.0.0/0
      
      # Find central and trust the root certificate
          remote_id "central.domain.org"
          remote_addr 192.xxx.xxx.x
      
      p2_pfs 5
      
      p1_xform
      {auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
      }

4. Lesen Sie die IKE-Konfiguration in den Systemkern ein.
   • Wenn Sie mit mindestens Solaris 10 4/09 arbeiten, aktivieren Sie den ike-Service.

     # svcadm enable svc:/network/ipsec/ike

   • Wenn Sie eine ältere Version als Solaris 10 4/09 verwenden, muss das System neu gestartet werden.

     # init 6

     Alternativ stoppen und starten Sie den in.iked-Daemon.

Beispiel 23-8 Konfiguration eines zentralen Computers zum Akzeptieren von IPsec-Verkehr von einem mobilen System

IKE kann Aushandlungen hinter einer NAT-Box initiieren. Das ideale Setup für IKE sieht jedoch keine zwischengeschaltete NAT-Box vor. Im folgenden Beispiel wurden die Root-Zertifikate von einer CA ausgegeben und auf dem mobilen und dem zentralen System eingepflegt. Ein zentrales System akzeptiert IPsec-Aushandlungen von einem System hinter einer NAT-Box. main1 ist ein Unternehmenssystem, das Verbindungen von Offsite-Systemen akzeptiert. Anweisungen zum Einrichten von Offsite-Systemen finden Sie unter Beispiel 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}
}

Beispiel 23-9 Konfiguration eines Systems hinter einer NAT-Box mit IPsec

Im folgenden Beispiel wurden die Root-Zertifikate von einer CA ausgegeben und auf dem mobilen sowie auf dem zentralen System eingepflegt. mobile1 stellt von zu Hause aus eine Verbindung mit dem Unternehmenshauptsitz her. Das Internet Service-Providers (ISP)-Netzwerk verwendet eine NAT-Box, damit der ISP mobile1 eine private Adresse zuordnen kann. Die NAT-Box übersetzt die private Adresse dann in eine öffentliche IP-Adresse, die gemeinsam mit anderen ISP-Netzwerkknoten genutzt wird. Das Hauptbüro des Unternehmens befindet sich nicht hinter einer NAT-Box. Informationen zum Einrichten des Computers am Unternehmenshauptsitz finden Sie in Beispiel 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 }
}

Beispiel 23-10 Akzeptieren selbst-signierter Zertifikate von einem mobilen System

Im folgenden Beispiel wurden selbst-signierte Zertifikate ausgegeben, die sich auf dem mobilen und auf dem zentralen System befinden. main1 ist ein Unternehmenssystem, das Verbindungen von Offsite-Systemen akzeptiert. Anweisungen zum Einrichten von Offsite-Systemen finden Sie unter Beispiel 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 }
}

Beispiel 23-11 Verwenden von selbst-signierten Zertifikaten zum Aufnehmen einer Verbindung mit einem zentralen System

Im folgenden Beispiel versucht mobile1, eine Verbindung von zu Hause aus mit dem Hauptbüro des Unternehmens herzustellen. Die Zertifikate wurden ausgegeben und befinden sich auf dem mobilen und auf dem zentralen System. Das ISP-Netzwerk verwendet eine NAT-Box, damit der ISP mobile1 eine private Adresse zuordnen kann. Die NAT-Box übersetzt die private Adresse dann in eine öffentliche IP-Adresse, die gemeinsam mit anderen ISP-Netzwerkknoten genutzt wird. Das Hauptbüro des Unternehmens befindet sich nicht hinter einer NAT-Box. Informationen zum Einrichten der Computer am Unternehmenshauptsitz finden Sie in Beispiel 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 }
}