Ignorer les liens de navigation | |
Quitter l'aperu | |
Sécurisation du réseau dans Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library (Français) |
1. Utilisation de la protection des liens dans des environnements virtualisés
3. Serveurs Web et protocole SSL (Secure Sockets Layer)
4. IP Filter dans Oracle Solaris (présentation)
6. Architecture IPsec (présentation)
7. Configuration d'IPsec (tâches)
Protection du trafic à l'aide d'IPsec
Sécurisation du trafic entre deux systèmes à l'aide d'IPsec
Utilisation d'IPsec pour protéger un serveur Web du trafic non-web.
Affichage des stratégies IPsec
Protection d'un VPN à l'aide d'IPsec
Protection d'un VPN à l'aide d'IPsec en mode Tunnel (exemples)
Description de la topologie réseau requise par les tâches IPsec afin de protéger un VPN
Création manuelle de clés IPsec
Configuration d'un rôle pour la sécurité réseau
Gestion des services IKE et IPsec
Vérification de la protection des paquets par IPsec
8. Architecture IPsec (référence)
9. Protocole IKE (présentation)
Oracle Solaris peut configurer un réseau privé virtuel (VPN) protégé par IPsec. Vous pouvez créer des tunnels en mode Tunnel ou en mode Transport. Pour plus d'informations, reportez-vous à la section Modes Transport et Tunnel dans IPsec. Les exemples et procédures de cette section utilisent des adresses IPv4, mais les exemples et procédures s'appliquent également aux réseaux privés virtuels IPv6. Pour une courte explication, reportez-vous à la section Protection du trafic à l'aide d'IPsec.
Des exemples de stratégies IPsec pour les tunnels en mode Tunnel sont présentés à la section Protection d'un VPN à l'aide d'IPsec en mode Tunnel (exemples).
Figure 7-1 Tunnel protégé par IPsec
Les exemples ci-dessous considèrent que le tunnel est configuré pour tous les sous-réseaux des LAN :
## Tunnel configuration ## # Tunnel name is 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
# Tunnel name address object is tun0/to-central # Tunnel name address object is tun0/to-overseas
Exemple 7-2 Création d'un tunnel utilisable par tous les sous-réseaux
Dans cet exemple, l'ensemble du trafic des LAN locaux du LAN Central de la Figure 7-1 peut être mis en tunnel du routeur 1 au routeur 2, puis distribué à tous les LAN locaux du LAN Overseas. Le trafic est chiffré à l'aide d'AES.
## IPsec policy ## {tunnel tun0 negotiate tunnel} ipsec {encr_algs aes encr_auth_algs sha512 sa shared}
Exemple 7-3 Création d'un tunnel connectant deux sous-réseaux
Dans cet exemple, seul le trafic entre le sous-réseau 10.1.2.0/24 du LAN Central et le sous-réseau 10.2.3.0/24 du LAN Overseas est mis en tunnel et chiffré. En l'absence d'autres stratégies IPsec pour Central, si le LAN Central tente de transmettre des données pour d'autres LAN via ce tunnel, le trafic est abandonné au niveau du routeur 1.
## IPsec policy ## {tunnel tun0 negotiate tunnel laddr 10.1.2.0/24 raddr 10.2.3.0/24} ipsec {encr_algs aes encr_auth_algs sha512 shared}
Les procédures suivant cette section sont définies pour la configuration ci-dessous. Le réseau est illustré à la Figure 7-2.
Chaque système utilise un espace d'adressage IPv4.
Chaque système possède deux interfaces. L'interface net0 se connecte à Internet. Dans cet exemple, les adresses IP Internet commencent par 192.168. L'interface net1 se connecte au LAN de la société, son intranet. Dans cet exemple, les adresses IP intranet commencent par le numéro 10.
Chaque système nécessite l'authentification ESP avec l'algorithme SHA-2. Dans cet exemple, l'algorithme SHA-2 requiert une clé de 512 bits.
Chaque système nécessite le chiffrement ESP avec l'algorithme AES. L'algorithme AES utilise une clé de 128 ou 256 bits.
Chaque système peut se connecter à un routeur bénéficiant d'un accès direct à Internet.
Chaque système utilise des associations de sécurité partagées (SA, Security Associations).
Figure 7-2 Exemple de VPN entre plusieurs sites connectés à Internet
Dans l'illustration précédente, les procédures utilisent les paramètres de configuration suivants.
|
Pour plus d'informations sur les noms de tunnels, reportez-vous à la section Configuration et administration du tunnel avec la commande dladm du manuel Configuration et administration de réseaux Oracle Solaris 11.1. Pour plus d'informations sur les objets d'adresse, reportez-vous à la section Configuration d’une interface IP du manuel Connexion de systèmes à l’aide d’une configuration réseau fixe dans Oracle Solaris 11.1 et à la page de manuel ipadm(1M).
En mode Tunnel, le paquet IP interne détermine la stratégie IPsec qui protège son contenu.
Cette procédure prolonge la procédure Sécurisation du trafic entre deux systèmes à l'aide d'IPsec. La configuration est décrite à la section Description de la topologie réseau requise par les tâches IPsec afin de protéger un VPN.
Pour une description plus détaillée des raisons pour lesquelles certaines commandes doivent être exécutées, reportez-vous aux étapes correspondantes à la section Sécurisation du trafic entre deux systèmes à l'aide d'IPsec.
Remarque - Effectuez cette procédure sur les deux systèmes.
Outre la connexion de deux systèmes, vous connectez deux intranets qui leur sont connectés. Les systèmes de cette procédure fonctionnent comme des passerelles.
Remarque - Pour utiliser IPsec en mode Tunnel avec des étiquettes sur un système Trusted Extensions, reportez-vous aux étapes supplémentaires indiquées à la section Configuration d’un tunnel au sein d’un réseau non autorisé du manuel Configuration et administration de Trusted Extensions.
Avant de commencer
Vous devez vous trouver dans la zone globale pour configurer la stratégie IPsec pour le système ou pour une zone IP partagée. Dans une zone IP exclusive, vous devez configurer la stratégie IPsec dans la zone non globale.
Pour exécuter des commandes de configuration, vous devez vous connecter en tant qu'administrateur disposant des profils de droits Network Management (gestion du réseau) et Network IPsec Management (gestion IPsec du réseau). Pour modifier des fichiers système, vous devez prendre le rôle root. Pour plus d'informations, reportez-vous à la section Utilisation de vos droits d’administration du manuel Administration d’Oracle Solaris 11.1 : Services de sécurité.
Si vous vous connectez à distance, exécutez la commande ssh pour que votre connexion soit sécurisée. Reportez-vous à l'Exemple 7-1.
# routeadm -d ipv4-routing # ipadm set-prop -p forwarding=off ipv4 # routeadm -u
La désactivation de la transmission IP empêche le transfert de paquets d'un réseau vers un autre par l'intermédiaire de ce système. La commande routeadm est décrite à la page de manuel routeadm(1M).
# ipadm set-prop -p hostmodel=strong ipv4
L'activation du multihébergement IP strict requiert que les paquets de l'une des adresses de destination du système arrivent à l'adresse de destination adéquate.
Lorsque le paramètre hostmodel est défini sur strong, les paquets arrivant sur une interface particulière doivent être adressés à l'une des adresses IP locales de cette interface. Tous les autres paquets sont abandonnés, même les paquets envoyés vers d'autres adresses locales du système.
Vérifiez que les montages en loopback et le service ssh sont en cours d'exécution.
# svcs | grep network online Aug_02 svc:/network/loopback:default … online Aug_09 svc:/network/ssh:default
Modifiez le fichier /etc/inet/ipsecinit.conf afin d'ajouter la stratégie IPsec pour le VPN. Pour obtenir des exemples supplémentaires, reportez-vous à la section Protection d'un VPN à l'aide d'IPsec en mode Tunnel (exemples).
Dans cette stratégie, la protection IPsec n'est pas requise entre les systèmes du réseau local et l'adresse IP interne de la passerelle, d'où l'ajout d'une déclaration bypass.
# 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-2. {tunnel tun0 negotiate tunnel} ipsec {encr_algs aes encr_auth_algs sha512 sa shared}
# 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-2. {tunnel tun0 negotiate tunnel} ipsec {encr_algs aes encr_auth_algs sha512 sa shared}
Configurez IKE en suivant l'une des procédures de configuration décrites à la section Configuration du protocole IKE (liste des tâches). La syntaxe du fichier de configuration IKE est décrite à la page de manuel ike.config(4).
Remarque - Si vous devez générer et maintenir vos clés manuellement, reportez-vous à la section Création manuelle de clés IPsec.
# ipsecconf -f -c /etc/inet/ipsecinit.conf
Corrigez les éventuelles erreurs, vérifiez la syntaxe du fichier, puis continuez.
# svcadm refresh svc:/network/ipsec/policy:default
La stratégie IPsec est activée par défaut. Actualisez-la. Si vous avez désactivé la stratégie IPsec, activez-la.
# svcadm enable svc:/network/ipsec/policy:default
Les commandes suivantes configurent les interfaces internes et externes, créent le tunnel tun0 et attribuent des adresses IP au tunnel.
Si l'interface net1 n'existe pas, la première commande la crée.
# ipadm create-addr -T static -a local=10.1.3.3 net1/inside # dladm create-iptun -T ipv4 -a local=10.1.3.3,remote=10.16.16.6 tun0 # ipadm create-addr -T static \ -a local=192.168.13.213,remote=192.168.116.16 tun0/v4tunaddr
# ipadm create-addr -T static -a local=10.16.16.6 net1/inside # dladm create-iptun -T ipv4 -a local=10.16.16.6,remote=10.1.3.3 tun0 # ipadm create-addr -T static \ -a local=192.168.116.16,remote=192.168.13.213 tun0/v4tunaddr
Remarque - L'option -T de la commande ipadm spécifie le type d'adresse à créer. L'option -T de la commande dladm spécifie le tunnel.
Pour plus d'informations sur ces commandes, reportez-vous aux pages de manuel dladm(1M) et ipadm(1M), ainsi qu'à la section Configuration d’une interface IP du manuel Connexion de systèmes à l’aide d’une configuration réseau fixe dans Oracle Solaris 11.1. Pour obtenir des informations sur les noms personnalisés, reportez-vous à la section Noms des périphériques réseau et des liaisons de données du manuel Administration d’Oracle Solaris : interfaces réseau et virtualisation réseau.
# ipadm set-ifprop -m ipv4 -p forwarding=on net1 # ipadm set-ifprop -m ipv4 -p forwarding=off net0
Le transfert IP signifie que les paquets arrivant peuvent être transférés. Le transfert IP signifie également que les paquets quittant l'interface peuvent provenir d'un autre emplacement. Pour que le transfert de paquet s'effectue sans erreur, vous devez activer le transfert IP à la fois sur l'interface réceptrice et sur l'interface émettrice.
Etant donné que l'interface net1 se trouve dans l'intranet, le transfert IP doit être activé pour net1. Comme tun0 connecte les deux systèmes via Internet, la transmission IP doit être activée pour tun0. Le transfert IP de l'interface net0 est désactivé afin d'éviter toute injection de paquets par un concurrent externe dans l'intranet protégé. Le terme externe fait référence à Internet.
# ipadm set-addrprop -p private=on net0
Même si le transfert de l'IP de net0 est désactivé, l'implémentation d'un protocole de routage peut permettre d'annoncer l'interface. Par exemple, le protocole in.routed peut encore annoncer que net0 est disponible pour transférer des paquets à ses homologues dans l'intranet. Pour éviter ces annonces, définissez l'indicateur private de l'interface.
# svcadm restart svc:/network/initial:default
La route par défaut doit correspondre à un routeur bénéficiant d'un accès direct à Internet.
# route -p add net default 192.168.13.5
# route -p add net default 192.168.116.4
Même si l'interface net0 ne fait pas partie de l'intranet, net0 n'a pas besoin de passer par Internet pour atteindre le système homologue. Pour trouver son homologue, net0 requiert des informations sur le routage Internet. Pour le reste d'Internet, le système VPN apparaît comme étant un hôte, non un routeur. Par conséquent, vous pouvez utiliser un routeur par défaut ou exécuter le protocole de recherche de routeur pour rechercher le système. Pour plus d'informations, reportez-vous aux pages de manuel route(1M) et in.routed(1M).