Cette section contient des pointeurs ou des exemples d'ajout d'hôtes à des modèles de sécurité. Pour les adresses IP discontinues, reportez-vous à la section Ajout d'un hôte au modèle de sécurité. Pour une plage d'hôtes, reportez-vous à la section Ajout d'une plage d'hôtes au modèle de sécurité.
Les exemples de cette section illustrent les affectations suivantes d'étiquette d'hôte distant :
Une passerelle distante de confiance gère le trafic PUBLIC. Voir l'Example 16–4.
Les hôtes distants non sécurisés jouent le rôle de routeurs à étiquette unique : Example 16–5
Les hôtes distants de confiance limitent le trafic à une plage d'étiquettes réduite. Voir l'Example 16–6.
Une plages d'étiquettes réduite est assignée aux hôtes distants de confiance. Voir l'Example 16–7.
Des étiquettes disjointes du reste du réseau sont assignées aux hôtes distants de confiance. Voir l'Example 16–8.
Un hôte netif de confiance étiquette les paquets des systèmes adaptive. Voir l'Example 16–9.
Un hôte adaptive non fiable envoie des paquets à un hôte netif. Voir l'Example 16–10.
Un réseau homogène de confiance ajoute une adresse de multidiffusion sous une étiquette spécifique. Voir l'Example 16–11.
Un hôte est supprimé d'un modèle de sécurité. Voir l'Example 16–12.
Des étiquettes sont assignées aux réseaux et hôtes distants non fiables. Voir l'Example 16–15.
Avant de commencer
Les éléments suivants doivent être en place :
Les adresses IP doivent exister dans le fichier /etc/hosts ou pouvoir être résolues par DNS.
Pour plus d'informations sur le fichier hosts, reportez-vous à la section Ajout d'hôtes au réseau connu du système.
Pour plus d'informations sur le système DNS, reportez-vous au Chapitre 3, Gestion du système de noms de domaine (DNS) du manuel Utilisation des services de noms et d’annuaire Oracle Solaris 11.2 : DNS et NIS .
Les extrémités de l'étiquette doivent correspondre. Pour connaître les règles, reportez-vous à la section A propos du routage dans Trusted Extensions.
Vous devez être dans le rôle d'administrateur de sécurité dans la zone globale.
Dans cet exemple, vous allez vérifier que vous pouvez atteindre 192.168.1.2.
# arp 192.168.1.2 gateway-2.example.com (192.168.1.2) at 0:0:0:1:ad:cd
La commande arp vérifie que l'hôte est défini dans le fichier /etc/hosts du système ou qu'il peut être résolu par DNS.
Dans cet exemple, vous ajoutez l'adresse IP 192.168.1.2.
# tncfg -t cipso tncfg:cipso> add host=192.168.1.2
Si vous ajoutez un hôte précédemment ajouté à un autre modèle, vous êtes averti du fait que vous êtes en train de remplacer le modèle de sécurité qui lui est affecté. Pour le message d'information, reportez-vous à l'Example 16–3.
Dans l'exemple suivant, l'adresse 192.168.1.2 est ajoutée au modèle cipso :
tncfg:cipso> info ... host=192.168.1.2/32
La longueur du préfixe de /32 indique que l'adresse est exacte.
tncfg:cipso> commit tncfg:cipso> exit
Pour supprimer une entrée d'hôte, reportez-vous à l'Example 16–12.
Cet exemple montre le message d'information qui s'affiche lorsque vous assignez un modèle de sécurité à un hôte qui comporte déjà une assignation de modèle.
# tncfg -t cipso tncfg:cipso> add host=192.168.1.2 192.168.1.2 previously matched the admin_low template tncfg:cipso> info ... host=192.168.1.2/32 tncfg:cipso> exitExemple 16-4 Création d'une passerelle gérant des paquets sur une étiquette unique
Dans l'Example 16–1, l'administrateur de sécurité crée un modèle de sécurité qui définit une passerelle permettant uniquement de transmettre des paquets à l'étiquette PUBLIC. Dans cet exemple, l'administrateur de sécurité s'assure que l'adresse IP de l'hôte de passerelle peut être résolue.
# arp 192.168.131.75 gateway-1.example.com (192.168.131.75) at 0:0:0:1:ab:cd
La commande arp vérifie que l'hôte est défini dans le fichier /etc/hosts du système ou qu'il peut être résolu par DNS.
L'administrateur ajoute ensuite l'hôte gateway-1 au modèle de sécurité.
# tncfg -t cipso_public tncfg:cipso_public> add host=192.168.131.75 tncfg:cipso_public> exit
Le système peut immédiatement envoyer et recevoir des paquets public via gateway-1.
Exemple 16-5 Création d'un routeur sans étiquette pour acheminer des paquets étiquetésTous les routeurs IP sont capables de transférer des messages pourvus d'étiquettes CALIPSO ou CIPSO, et ce même si les étiquettes ne sont pas explicitement prises en charge par le routeur. Ce routeur non étiqueté nécessite une étiquette par défaut définissant le niveau de traitement des connexions au routeur (pour la gestion du routeur par exemple). Dans cet exemple, l'administrateur de sécurité crée un routeur capable de transférer le trafic de n'importe quelle étiquette, mais toutes les communications directes avec le routeur sont gérées sous l'étiquette par défaut PUBLIC.
Tout d'abord, l'administrateur de sécurité crée le modèle à partir de zéro.
# tncfg -t unl_public_router tncfg:unl_public_router> set host_type=unlabeled tncfg:unl_public_router> set doi=1 tncfg:unl_public_router> set def_label="PUBLIC" tncfg:unl_public_router> set min_label=ADMIN_LOW tncfg:unl_public_router> set max_label=ADMIN_HIGH tncfg:unl_public_router> exit
L'administrateur ajoute ensuite le routeur au modèle de sécurité.
# tncfg -t unl_public_router tncfg:unl_public_router> add host=192.168.131.82 tncfg:unl_public_router> exit
Le système peut immédiatement envoyer et recevoir des paquets sur toutes les étiquettes via router-1, le nom d'hôte correspondant à l'adresse 192.168.131.82.
Exemple 16-6 Création d'une passerelle avec une plage d'étiquettes limitéeDans cet exemple, l'administrateur de sécurité crée un modèle limitant les paquets à une plage d'étiquettes restreinte et ajoute la passerelle à ce modèle.
# arp 192.168.131.78 gateway-ir.example.com (192.168.131.78) at 0:0:0:3:ab:cd
# tncfg -t cipso_iuo_rstrct tncfg:cipso_iuo_rstrct> set host_type=cipso tncfg:cipso_iuo_rstrct> set doi=1 tncfg:cipso_iuo_rstrct> set min_label=0x0004-08-48 tncfg:cipso_iuo_rstrct> set max_label=0x0004-08-78 tncfg:cipso_iuo_rstrct> add host=192.168.131.78 tncfg:cipso_iuo_rstrct> exit
Le système peut immédiatement envoyer et recevoir des paquets associés aux étiquettes internal et restricted via gateway-ir.
Exemple 16-7 Création d'hôtes sous des étiquettes discrètesDans cet exemple, l'administrateur de sécurité crée un modèle de sécurité qui reconnaît uniquement deux étiquettes, confidential : internal use only et confidential : restricted. Tout autre trafic est rejeté.
Tout d'abord, l'administrateur de sécurité s'assure que chaque adresse IP de l'hôte peut être résolue.
# arp 192.168.132.21 host-auxset1.example.com (192.168.132.21) at 0:0:0:4:ab:cd # arp 192.168.132.22 host-auxset2.example.com (192.168.132.22) at 0:0:0:5:ab:cd # arp 192.168.132.23 host-auxset3.example.com (192.168.132.23) at 0:0:0:6:ab:cd # arp 192.168.132.24 host-auxset4.example.com (192.168.132.24) at 0:0:0:7:ab:cd
L'administrateur doit ensuite veiller à saisir les étiquettes de façon précise. Le logiciel reconnaît les étiquettes en majuscules et en minuscules, en abrégé, mais ne peut pas reconnaître les étiquettes lorsque l'espacement n'est pas exact. Par exemple, l'étiquette cnf :restricted n'est pas valide.
# tncfg -t cipso_int_and_rst tncfg:cipso_int_and_rst> set host_type=cipso tncfg:cipso_int_and_rst> set doi=1 tncfg:cipso_int_and_rst> set min_label="cnf : internal use only" tncfg:cipso_int_and_rst> set max_label="cnf : internal use only" tncfg:cipso_int_and_rst> set aux_label="cnf : restricted" tncfg:cipso_int_and_rst> exit
L'administrateur attribue ensuite la plage d'adresses IP au modèle de sécurité à l'aide d'une longueur de préfixe.
# tncfg -t cipso_int_rstrct tncfg:cipso_int_rstrct> set host=192.168.132.0/24Exemple 16-8 Création d'un hôte étiqueté pour les développeurs
Dans cet exemple, l'administrateur de sécurité crée un modèle de sécurité cipso_sandbox. Ce modèle est assigné aux systèmes utilisés par les développeurs de logiciels de confiance. Cependant, leurs tests n'affectent pas les autres hôtes étiquetés, car l'étiquette SANDBOX est disjointe des autres étiquettes du réseau.
# tncfg -t cipso_sandbox tncfg:cipso_sandbox> set host_type=cipso tncfg:cipso_sandbox> set doi=1 tncfg:cipso_sandbox> set min_sl="SBX" tncfg:cipso_sandbox> set max_sl="SBX" tncfg:cipso_sandbox> add host=196.168.129.102 tncfg:cipso_sandbox> add host=196.168.129.129 tncfg:cipso_sandbox> exit
Les développeurs utilisant les systèmes 196.168.129.102 et 196.168.129.129 peuvent communiquer les uns avec les autres à l'aide de l'étiquette SANDBOX.
Exemple 16-9 Création d'un modèle de sécurité pour un hôte netifDans cet exemple, l'administrateur de sécurité crée un modèle de sécurité netif. Ce modèle est assigné à l'interface réseau étiquetée qui héberge l'adresse IP 10.121.10.3. Avec cette affectation, le module IP Trusted Extensions ajoute l'étiquette par défaut PUBLIC à tous les paquets entrants qui arrivent à partir d'un hôte adaptive.
# tncfg -t netif_public tncfg:netif_public> set host_type=netif tncfg:netif_public> set doi=1 tncfg:netif_public> set def_label="PUBLIC" tncfg:netif_public> add host=10.121.10.3 tncfg:netif_public> commit tncfg:netif_public> exitExemple 16-10 Création de modèles de sécurité pour les hôtes adaptatifs
Dans cet exemple, l'administrateur de sécurité prévoit à l'avance. L'administrateur crée des sous-réseaux différents pour un réseau contenant des informations publiques et pour un réseau contenant des informations internes. L'administrateur définit ensuite deux hôtes adaptive. L'étiquette PUBLIC est assignée aux systèmes du sous-réseau public. L'étiquette IUO est assignée aux systèmes du réseau interne. Ce réseau étant planifié à l'avance, chaque réseau contient et transmet des informations sous une étiquette spécifique. Un autre avantage est que le réseau est facilement débogué lorsque les paquets ne sont pas livrés à l'interface attendue.
# tncfg -t adpub_192_168_10 tncfg:adapt_public> set host_type=adapt tncfg:adapt_public> set doi=1 tncfg:adapt_public> set min_label="public" tncfg:adapt_public> set max_label="public" tncfg:adapt_public> add host=192.168.10.0 tncfg:adapt_public> commit tncfg:adapt_public> exit
# tncfg -t adiuo_192_168_20 tncfg:adapt_public> set host_type=adapt tncfg:adapt_public> set doi=1 tncfg:adapt_public> set min_label="iuo" tncfg:adapt_public> set max_label="iuo" tncfg:adapt_public> add host=192.168.20.0 tncfg:adapt_public> commit tncfg:adapt_public> exitExemple 16-11 Envoi de messages de multidiffusion étiquetés
Dans cet exemple sur un réseau LAN homogène et étiqueté, l'administrateur de sécurité choisit une adresse de multidiffusion disponible sur laquelle envoyer des paquets sous l'étiquette PUBLIC.
# tncfg -t cipso_public tncfg:cipso_public> add host=224.4.4.4 tncfg:cipso_public> exitExemple 16-12 Suppression de plusieurs hôtes à partir d'un modèle de sécurité
Dans cet exemple, l'administrateur de sécurité supprime plusieurs hôtes à partir du modèle de sécurité cipso. L'administrateur utilise la sous-commande info pour afficher les hôtes, il saisit ensuite remove, puis copie-colle quatre entrées host=.
# tncfg -t cipso info name=cipso host_type=cipso doi=1 min_label=ADMIN_LOW max_label=ADMIN_HIGH host=127.0.0.1/32 host=192.168.1.2/32 host=192.168.113.0/24 host=192.168.113.100/25 host=2001:a08:3903:200::0/56
# tncfg -t cipso tncfg:cipso> remove host=192.168.1.2/32 tncfg:cipso> remove host=192.168.113.0/24 tncfg:cipso> remove host=192.168.113.100/25 tncfg:cipso> remove host=2001:a08:3903:200::0/56 tncfg:cipso> info ... max_label=ADMIN_HIGH host=127.0.0.1/32 host=192.168.75.0/24
Après la suppression des hôtes, l'administrateur valide les modifications et quitte le modèle de sécurité.
tncfg:cipso> commit tncfg:cipso> exit #
Avant de commencer
Pour la configuration requise, reportez-vous à la section Ajout d'un hôte au modèle de sécurité.
Dans cet exemple, deux sous-réseaux IPv4 sont ajoutés au modèle cipso, puis le modèle de sécurité est affiché.
# tncfg -t cipso tncfg:cipso> add host=192.168.75.0 tncfg:cipso> add host=192.168.113.0 tncfg:cipso> info ... host=192.168.75.0/24 host=192.168.113.0/24 tncfg:cipso> exit
La longueur du préfixe de /24 indique que l'adresse, qui se termine par .0, représente un sous-réseau.
# tncfg -t cipso tncfg:cipso> add host=192.168.113.100/25 192.168.113.100/25 previously matched the admin_low template
Dans l'exemple suivant, la longueur du préfixe /25 couvre les adresses IPv4 contiguës de 192.168.113.0 à 192.168.113.127. L'adresse inclut 192.168.113.100.
# tncfg -t cipso tncfg:cipso> add host=192.168.113.100/25 tncfg:cipso> exit
Dans l'exemple suivant, la longueur du préfixe /56 couvre les adresses IPv6 contiguës de 2001:a08:3903:200::0 à 2001:a08:3903:2ff:ffff:ffff:ffff:ffff. L'adresse inclut 2001:a08:3903:201:20e:cff:fe08:58c.
# tncfg -t cipso tncfg:cipso> add host=2001:a08:3903:200::0/56 tncfg:cipso> info ... host=2001:a08:3903:200::0/56 tncfg:cipso> exit
Si vous ajoutez un hôte précédemment ajouté à un autre modèle, vous êtes averti du fait que vous êtes en train de remplacer le modèle de sécurité qui lui est affecté. Pour le message d'information, reportez-vous à l'Example 16–13.
En cas d'entrée mal saisie, un message d'information s'affiche également, comme illustré dans l'Example 16–14.
Cet exemple montre le message d'information qui s'affiche lorsque vous assignez un modèle de sécurité à une plage d'hôtes qui possède déjà une assignation de modèle.
# tncfg -t cipso tncfg:cipso> add host=192.168.113.100/32 192.168.113.100/32 previously matched the admin_low template tncfg:cipso> info ... host=192.168.113.100/32 tncfg:cipso> exit
Le mécanisme de secours de Trusted Extensions garantit que cette assignation explicite remplace l'assignation précédente, comme indiqué dans la section Mécanisme de secours du réseau de confiance.
Exemple 16-14 Gestion d'une adresse IP mal saisie dans un modèle de sécuritéSi une entrée est mal saisie, un message d'information s'affiche. Dans l'exemple d'ajout d'hôte suivant, la partie :200 est omise dans l'adresse :
# tncfg -t cipso tncfg:cipso> add host=2001:a08:3903::0/56 Invalid host: 2001:a08:3903::0/56Exemple 16-15 Création d'un sous-réseau non étiqueté sous l'étiquette PUBLIC
Dans l'Example 16–2, l'administrateur de sécurité crée un modèle de sécurité qui assigne l'étiquette PUBLIC à un hôte non fiable. Dans cet exemple, l'administrateur de sécurité assigne un sous-réseau à l'étiquette PUBLIC. Sur le système d'assignation, les utilisateurs peuvent monter des systèmes de fichiers d'hôtes de ce sous-réseau dans une zone PUBLIC.
# tncfg -t public tncfg:public> add host=10.10.0.0/16 tncfg:public> exit
Le sous-réseau peut être atteint immédiatement sous l'étiquette PUBLIC.