Étiquetage d'hôtes et de réseaux (liste des tâches)

Le système Trusted Extensions peut contacter d'autres hôtes uniquement après avoir défini les attributs de sécurité de ces hôtes. Étant donné que les hôtes distants peuvent avoir des attributs de sécurité similaires, Trusted Extensions fournit des modèles de sécurité auxquels il est possible d'ajouter des hôtes.

La liste ci-dessous décrit les tâches que vous pouvez utiliser pour compléter les modèles de sécurité et les appliquer à des hôtes distants.

Procédure d'affichage des modèles de sécurité

Vous pouvez visualiser la liste des modèles de sécurité et le contenu de chaque modèle. Les exemples de cette procédure sont les modèles de sécurité par défaut.

1. Répertoriez les modèles de sécurité disponibles.

   # tncfg list
      cipso
      admin_low

2. Affichez le contenu des modèles répertoriés.

   # 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

   L'entrée 127.0.0.1/32 du modèle de sécurité cipso précédent identifie ce système comme étiqueté. Lorsqu'un pair attribue ce système au modèle d'hôte distant du pair à l'aide du host_type de admin_low, les deux systèmes peuvent échanger des paquets étiquetés.

   # tncfg -t admin_low info
      name=admin_low
      host_type=unlabeled
      doi=1
      def_label=ADMIN_LOW
      min_label=ADMIN_LOW
      max_label=ADMIN_HIGH
      host=0.0.0.0/0

   L'entrée 0.0.0.0/0 du modèle de sécurité admin_low précédent permet à l'ensemble des hôtes qui ne sont pas explicitement assignés à un modèle de sécurité de contacter ce système. Ces hôtes sont reconnus en tant qu'hôtes sans étiquette.

   • L'avantage de cette entrée est que tous les hôtes requis par le système au moment de l'initialisation, tels que les serveurs et les passerelles, peuvent être trouvés.

   • L'inconvénient de cette entrée est que n'importe quel hôte se trouvant sur le réseau du système peut contacter ce système. Pour restreindre le nombre d'hôtes autorisés à contacter ce système, reportez-vous à la section Procédure de limitation des hôtes pouvant être contactés sur le réseau de confiance.

Procédure d'évaluation de la nécessité d'utiliser des modèles de sécurité personnalisés sur votre site

Avant de commencer

Vous devez être dans le rôle d'administrateur de sécurité dans la zone globale.

1. Familiarisez-vous avec les modèles de sécurité Trusted Extensions.

   Suivez les instructions de la section Procédure d'affichage des modèles de sécurité pour afficher les modèles de sécurité disponibles.

2. Créez de nouveaux modèles de sécurité si vous souhaitez effectuer l'une des opérations suivantes pour les hôtes avec lesquels vous communiquez :

   • Limiter la plage d'étiquettes d'un hôte ou d'un groupe d'hôtes.

   • Créer un hôte à étiquette unique sous une autre étiquette que ADMIN_LOW.

   • Utiliser une étiquette par défaut autre que ADMIN_LOW pour les hôtes non étiquetés.

   • Créer un hôte capable de reconnaître certaines étiquettes discrètes.

   • Utilisez un DOI autre que 1.

Étapes suivantes

Pour ajouter des hôtes aux modèles de sécurité par défaut, reportez-vous à la section Procédure d'ajout d'un hôte au modèle de sécurité.

Sinon, poursuivez à la section Procédure de création de modèles de sécurité.

Procédure de création de modèles de sécurité

Avant de commencer

Vous devez accéder à la zone globale à l'aide d'un rôle capable de modifier la sécurité du réseau. Par exemple, les rôles auxquels des profils de droits Information Security ou Network Security ont été affectés peuvent modifier les valeurs de sécurité. Le rôle d'administrateur de sécurité inclut ces profils de droits.

1. (Facultatif) Déterminez la version hexadécimale de chaque étiquette autre que ADMIN_HIGH et ADMIN_LOW.

   Pour les étiquettes comme PUBLIC , vous pouvez utiliser la chaîne d'étiquettes ou la valeur hexadécimale, 0x0002-08-08 comme valeurs d'étiquette. La commande tncfg accepte les deux formats.

   # atohexlabel "confidential : internal use only"
   0x0004-08-48

   Pour plus d'informations, reportez-vous à la section Obtention de l'équivalent hexadécimal d'une étiquette.

2. Ne modifiez pas les modèles de sécurité par défaut.

   Pour permettre une assistance en cas de besoin, vous ne devez pas supprimer les modèles de sécurité par défaut. Vous pouvez copier et modifier ces modèles. Vous pouvez également ajouter et supprimer des hôtes assignés à ces modèles. Pour consulter un exemple, reportez-vous à la section Procédure de limitation des hôtes pouvant être contactés sur le réseau de confiance.

3. Créez un modèle de sécurité.

   La commande tncfg -t fournit trois façons de créer de nouveaux modèles.

   • Créer un modèle de sécurité à partir de zéro.

     Utilisez la commande tncfg en mode interactif. La sous-commande info affiche les valeurs fournies par défaut. Utilisez la touche de tabulation pour compléter les propriétés et les valeurs partielles.

     # tncfg -t newunlabeled
     tncfg:newtemplate> info
        name=newunlabeled
        host_type=unlabeled
        doi=1
        def_label=ADMIN_LOW
        min_label=ADMIN_LOW
        max_label=ADMIN_HIGH
     tncfg:newunlabeled> set m<Tab>
     set max_label=" set min_label="
     tncfg:newunlabeled> set ma<Tab>
     tncfg:newunlabeled> set max_label=ADMIN_LOW
     ...

     Vous pouvez également fournir la liste complète des attributs d'un modèle de sécurité sur la ligne de commande. Les sous-commandes set sont séparées par des points-virgules. Lorsqu'une propriété est omise, la valeur par défaut lui est attribuée.

     # tncfg -t newunlabeled set host_type=unlabeled;set doi=1; \
     set min_label=ADMIN_LOW;set max_label=ADMIN_LOW

   • Copier et modifier un modèle de sécurité existant.

     # tncfg -t cipso
     tncfg:cipso> set name=newcipso
     tncfg:newcipso> info
     name=newcipso
     host_type=cipso
     doi=1
     min_label=ADMIN_LOW
     max_label=ADMIN_HIGH

     Les hôtes qui sont affectés au modèle de sécurité existant ne sont pas copiés dans le nouveau modèle.

   • Utiliser un fichier modèle créé par la sous-commande export.

     # tncfg -f unlab_1 -f template-file
     tncfg: unlab1> set host_type=unlabeled
     ...
     # tncfg -f template-file

     Pour obtenir un exemple de modèle source pour l'importation, reportez-vous à la page de manuel tncfg(1M).

Exemple 16-1 Création d'un modèle de sécurité pour une passerelle gérant des paquets sous une étiquette unique

Dans cet exemple, l'administrateur de sécurité définit une passerelle qui permet uniquement la transmission de paquets au niveau de l'étiquette PUBLIC.

# tncfg -t cipso_public
tncfg:cipso_public> set host_type=cipso
tncfg:cipso_public> set doi=1
tncfg:cipso_public> set min_label="public"
tncfg:cipso_public> set max_label="public"
tncfg:cipso_public> commit
tncfg:cipso_public> exit

L'administrateur de sécurité ajoute ensuite l'hôte de passerelle au modèle de sécurité. Pour des instructions sur l'ajout, reportez-vous à l'Exemple 16-7.

Exemple 16-2 Création d'un modèle de sécurité pour un routeur sans étiquette acheminant les paquets étiquetés

Tous les routeurs IP sont capables de transférer des messages pourvus d'étiquettes 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.

L'administrateur de sécurité crée le modèle à partir de zéro.

# tncfg -t unl_public
tncfg:unl_public> set host_type=unlabeled
tncfg:unl_public> set doi=1
tncfg:unl_public> set def_label="PUBLIC"
tncfg:unl_public> set min_label=ADMIN_LOW
tncfg:unl_public> set max_label=ADMIN_HIGH
tncfg:unl_public> exit

L'administrateur de sécurité ajoute ensuite le routeur au modèle de sécurité. Pour des instructions sur l'ajout, reportez-vous à l'Exemple 16-8.

Exemple 16-3 Création d'un modèle de sécurité pour une passerelle avec une plage d'étiquettes limitée

Dans cet exemple, l'administrateur de sécurité crée une passerelle limitant les paquets à une plage d'étiquettes restreinte. L'administrateur crée un modèle de sécurité auquel il affecte ultérieurement l'hôte de passerelle.

# 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

L'administrateur de sécurité ajoute ensuite l'hôte de passerelle au modèle de sécurité. Pour des instructions sur l'ajout, reportez-vous à l'Exemple 16-9.

Exemple 16-4 Création d'un modèle de sécurité avec étiquettes discrètes

Dans 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é.

L'administrateur doit tout d'abord 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 confidential :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

Exemple 16-5 Création d'un modèle de sécurité non étiqueté sous l'étiquette PUBLIC

Dans cet exemple, l'administrateur de sécurité crée un modèle à étiquette unique pour les hôtes autorisés à recevoir et envoyer des paquets sous l'étiquette PUBLIC uniquement. Ce modèle peut être affecté aux hôtes dont les systèmes de fichiers doivent être montés sur l'étiquette PUBLIC par les systèmes Trusted Extensions.

# tncfg -t public
tncfg:public> set host_type=unlabeled
tncfg:public> set doi=1
tncfg:public> set def_label="public"
tncfg:public> set min_sl="public"
tncfg:public> set max_sl="public"
tncfg:public> exit

L'administrateur de sécurité ajoute ensuite des hôtes au modèle de sécurité. Pour des instructions sur l'ajout, reportez-vous à l'Exemple 16-13.

Exemple 16-6 Création d'un modèle de sécurité étiqueté pour les développeurs

Dans cet exemple, l'administrateur de sécurité crée un modèle cipso_sandbox . Ce modèle de sécurité 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> exit

Procédure d'ajout d'hôtes au réseau connu du système

Une fois que vous avez ajouté des hôtes et des groupes d'hôtes dans le fichier /etc/hosts du système, les hôtes sont connus du système. Seuls les hôtes connus peuvent être ajoutés à un modèle de sécurité.

Avant de commencer

Vous êtes dans le rôle root dans la zone globale.

1. Ajoutez des hôtes individuels dans le fichier /etc/hosts.

   # vi /etc/hosts
   
   ...
   192.168.111.121   ahost

2. Ajoutez un groupe d'hôtes dans le fichier /etc/hosts.

   # vi /etc/hosts
   
   ...
   192.168.111.0   111-network

Étapes suivantes

Poursuivez à la section Procédure d'ajout d'un hôte au modèle de sécurité.

Procédure d'ajout d'un hôte au modèle de sécurité

Avant de commencer

Les éléments suivants doivent être en place :

• Le modèle de sécurité doit exister. Pour plus d'informations sur cette procédure, reportez-vous à la section Procédure de création de modèles de sécurité.

• 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 Procédure d'ajout d'hôtes au réseau connu du système .

  Pour DNS, reportez-vous à Chapitre 3, Managing DNS (Tasks) du manuel Oracle Solaris Administration: Naming and Directory Services.

• Les extrémités de l'étiquette doivent correspondre. Pour connaître les règles, reportez-vous à la section Présentation du routage dans Trusted Extensions.

• Vous devez être dans le rôle d'administrateur de sécurité dans la zone globale.

1. Ajoutez un nom d'hôte ou une adresse IP à un modèle de sécurité.

   Par exemple, 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é. Par exemple :

   # tncfg -t cipso
   tncfg:cipso> add host=192.168.1.22
   192.168.1.2 previously matched the admin_low template
   tncfg:cipso> info
   ...
   host=192.168.1.2/32
   tncfg:cipso> exit

2. Consultez le modèle de sécurité modifié.

   Par exemple, la ligne ci-après montre l'adresse 192.168.1.2 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.

3. Validez la modification et quittez le modèle de sécurité.

   tncfg:cipso> commit
   tncfg:cipso> exit

   Pour supprimer une entrée d'hôte, reportez-vous à l'Exemple 16-11.

Exemple 16-7 Création d'une passerelle gérant des paquets sur une étiquette unique

Dans l'Exemple 16-1, l'administrateur 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-8 Création d'un routeur sans étiquette pour acheminer des paquets étiquetés

Dans l'Exemple 16-2, l'administrateur crée le modèle de sécurité du routeur. Dans cet exemple, l'administrateur s'assure que l'adresse IP du routeur peut être résolue.

# arp 192.168.131.82
router-1.example.com (192.168.131.82) at 0:0:0:2:ab:cd

La commande arp indique 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 le routeur au modèle de sécurité.

# tncfg -t unl_public
tncfg:unl_public> add host=192.168.131.82
tncfg:unl_public> exit

Le système peut immédiatement envoyer et recevoir des paquets sur toutes les étiquettes via routeur-1.

Exemple 16-9 Création d'une passerelle avec une plage d'étiquettes limitée

Dans l'Exemple 16-3, l'administrateur créé un modèle de sécurité contenant une plage d'étiquettes limitée. 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.78
gateway-ir.example.com (192.168.131.78) at 0:0:0:3:ab:cd

La commande arp indique 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 la passerelle au modèle de sécurité.

# tncfg -t cipso_iuo_rstrct
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-10 Création d'un hôte étiqueté pour les développeurs

Dans l'Exemple 16-6, l'administrateur crée le modèle de sécurité cipso_sandbox. Dans cet exemple, l'administrateur de sécurité ajoute deux hôtes au modèle.

# tncfg -t cipso_sandbox
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-11 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
#

Procédure d'ajout d'une plage d'hôtes au modèle de sécurité

Avant de commencer

Pour la configuration requise, reportez-vous à la section Procédure d'ajout d'un hôte au modèle de sécurité

1. Pour affecter un modèle de sécurité à un sous-réseau, ajoutez l'adresse de sous-réseau au modèle.

   Par exemple, ajoutez deux sous-réseaux au modèle admin_low, puis affichez le modèle de sécurité.

   # 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.

   ---

   Remarque - Si vous ajoutez une plage d'hôtes précédemment ajoutés à 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é.

   ---

   # tncfg -t cipso
   tncfg:cipso> add host=192.168.113.100/25
   192.168.113.100/25 previously matched the admin_low template

2. Pour affecter un modèle de sécurité à un groupe d'adresses IP contiguës, spécifiez l'adresse IP et la longueur du préfixe.

   Dans l'exemple suivant, la longueur du préfixe couvre la plage d'adresses 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 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 ne saisissez pas correctement une entrée, vous recevez un message semblable à ce qui suit :

   # tncfg -t cipso
   tncfg:cipso> add host=2001:a08:3903::0/56
   Invalid host: 2001:a08:3903::0/56

   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é. Par exemple :

   # 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 affectation explicite remplace l'affectation précédente, comme indiqué à la section Mécanisme de secours du réseau de confiance.

Exemple 16-12 Création d'hôtes sous des étiquettes discrètes

Dans l'Exemple 16-4, l'administrateur crée le modèle de sécurité qui reconnaît deux étiquettes. Dans cet exemple, 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

La commande arp indique que les hôtes sont définis dans le fichier /etc/hosts du système ou qu'ils peuvent être résolus par DNS.

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/24

Exemple 16-13 Création d'un sous-réseau non étiqueté sous l'étiquette PUBLIC

Dans l'Exemple 16-5, l'administrateur crée un modèle de sécurité qui définit un hôte PUBLIC à étiquette unique. Dans cet exemple, l'administrateur de sécurité affecte un sous-réseau à l'étiquette PUBLIC. Les utilisateurs du système sécurisé peuvent monter des systèmes de fichiers à partir de ce sous-réseau sous l'étiquette 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.

Procédure de limitation des hôtes pouvant être contactés sur le réseau de confiance

Cette procédure empêche que les hôtes étiquetés ne soient contactés par des hôtes non étiquetés arbitraires. Lorsque Trusted Extensions est installé, le modèle de sécurité admin_low par défaut définit tous les hôtes du réseau. Utilisez cette procédure pour énumérer des hôtes non étiquetés spécifiques.

Les valeurs du réseau de confiance local de chaque système permettent d'établir le contact avec le réseau lors de l'initialisation. Par défaut, tous les hôtes qui ne sont pas pourvus d'un modèle cipso sont définis par le modèle admin_low. Ce modèle définit tous les hôtes distants non définis par ailleurs (0.0.0.0/0) comme étant des systèmes sans étiquette et leur assigne l'étiquette par défaut admin_low.

---

Attention - Le modèle admin_low par défaut peut présenter un risque de sécurité sur le réseau Trusted Extensions. Si la sécurité du site nécessite une protection renforcée, l'administrateur de sécurité peut supprimer l'entrée générique 0.0.0.0/0 une fois le système installé. L'entrée doit être remplacée par des entrées correspondant à chacun des hôtes que le système contacte lors de l'initialisation. Par exemple, les serveurs DNS, les serveurs d'annuaire personnel, les serveurs d'audit, les adresses de diffusion et de multidiffusion et les routeurs doivent être ajoutés de façon explicite à un modèle après la suppression de l'entrée générique 0.0.0.0/0. Si une application reconnaît initialement les clients sur l'adresse d'hôte 0.0.0.0/32, vous devez ajouter l'entrée d'hôte 0.0.0.0/32 au modèle admin_low. Une fois que le serveur a reconnu les clients, une adresse IP est attribuée aux clients et ces derniers sont connectés en tant que clients CIPSO.

---

Avant de commencer

Vous devez être dans le rôle d'administrateur de sécurité dans la zone globale.

Tous les hôtes qui doivent être contactés lors de l'initialisation doivent exister dans le fichier /etc/hosts.

1. Assignez le modèle admin_low à chaque hôte sans étiquette qui doit être contacté au moment de l'initialisation.

   • Ajoutez tous les hôtes sans étiquette qui doivent être contactés lors de l'initialisation.

   • Incluez tous les routeurs infra-réseau n'exécutant pas Trusted Extensions via lesquels ce système doit communiquer.

   • Retirez l'assignation 0.0.0.0/0.

2. Ajoutez des hôtes au modèle admin_low.

   Ajoutez chaque hôte étiqueté qui doit être contacté lors de l'initialisation.

   • Incluez tous les routeurs infra-réseau exécutant Trusted Extensions via lesquels ce système doit communiquer.

   • Assurez-vous que toutes les interfaces réseau sont assignées au modèle.

   • Incluez les adresses de diffusion.

   • Ajoutez les plages d'hôtes étiquetés à contacter lors de l'initialisation.

   Pour un exemple de base de données, consultez l'Exemple 16-15.

3. Assurez-vous que les assignations d'hôtes n'empêchent pas le système de s'initialiser.

Exemple 16-14 Modification de l'étiquette de l'adresse IP 0.0.0.0/0

Dans cet exemple, l'administrateur crée un système de passerelle publique. L'administrateur supprime l'entrée d'hôte 0.0.0.0/0 à partir du modèle admin_low et ajoute l'entrée d'hôte 0.0.0.0/0 au modèle public sans étiquette. Le système reconnaît ensuite tout hôte non spécifiquement assigné à un autre modèle de sécurité comme un système sans étiquette possédant les attributs de sécurité du modèle de sécurité public.

# tncfg -t admin_low info
tncfg:admin_low> remove host=0.0.0.0Wildcard address
tncfg:admin_low> exit

# tncfg -t public
tncfg:public> set host_type=unlabeled
tncfg:public> set doi=1
tncfg:public> set def_label="public"
tncfg:public> set min_sl="public"
tncfg:public> set max_sl="public"
tncfg:public> add host=0.0.0.0Wildcard address
tncfg:public> exit

Exemple 16-15 Énumération des ordinateurs à contacter au moment de l'initialisation

Dans l'exemple suivant, l'administrateur configure le réseau de confiance du système Trusted Extensions avec deux interfaces réseau. Le système communique avec un autre réseau et des routeurs. Les hôtes distants sont assignés à l'un des trois modèles, cipso, admin_low ou public. Les commandes suivantes sont annotées.

# tncfg -t cipso
tncfg:admin_low> add host=127.0.0.1Loopback address
tncfg:admin_low> add host=192.168.112.111Interface 1 of this host
tncfg:admin_low> add host=192.168.113.111Interface 2 of this host
tncfg:admin_low> add host=192.168.113.6File server
tncfg:admin_low> add host=192.168.112.255Subnet broadcast address
tncfg:admin_low> add host=192.168.113.255Subnet broadcast address
tncfg:admin_low> add host=192.168.113.1Router
tncfg:admin_low> add host=192.168.117.0/24Another Trusted Extensions network
tncfg:admin_low> exit

# tncfg -t public
tncfg:public> add host=192.168.112.12Specific network router
tncfg:public> add host=192.168.113.12Specific network router
tncfg:public> add host=224.0.0.2Multicast address
tncfg:admin_low> exit

# tncfg -t admin_low
tncfg:admin_low> add host=255.255.255.255Broadcast address
tncfg:admin_low> exit

Après avoir spécifié les hôtes à contacter au moment de l'initialisation, l'administrateur supprime l'entrée 0.0.0.0/0 à partir du modèle admin_low.

# tncfg -t admin_low
tncfg:admin_low> remove host=0.0.0.0
tncfg:admin_low> exit

Exemple 16-16 Faire de l'adresse hôte 0.0.0.0/32 une adresse initiale valide

Dans cet exemple, l'administrateur de sécurité configure un serveur d'application de manière à ce qu'il accepte les requêtes de connexion initiales provenant de clients potentiels.

L'administrateur configure le réseau de confiance du serveur. Les entrées du serveur et du client sont annotées.

# 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.128.1/32 Application server address
   host=192.168.128.0/24 Application's client network
Other addresses to be contacted at boot time

# tncfg -t admin_low info
   name=cipso
   host_type=cipso
   doi=1
   def_label=ADMIN_LOW
   min_label=ADMIN_LOW
   max_label=ADMIN_HIGH
   host=192.168.128.0/24 Application's client network
   host=0.0.0.0/0 Wildcard address
Other addresses to be contacted at boot time

Une fois cette phase de test réussie, l'administrateur verrouille la configuration en supprimant l'adresse générique par défaut, 0.0.0.0/0, en validant la modification, puis en ajoutant l'adresse spécifique.

# tncfg -t admin_low info
tncfg:admin_low> remove host=0.0.0.0
tncfg:admin_low> commit
tncfg:admin_low> add host=0.0.0.0/32For initial client contact
tncfg:admin_low> exit

La configuration admin_low finale s'affiche comme suit :

# tncfg -t admin_low
   name=cipso
   host_type=cipso
   doi=1
   def_label=ADMIN_LOW
   min_label=ADMIN_LOW
   max_label=ADMIN_HIGH
   192.168.128.0/24 Application's client network
   host=0.0.0.0/32 For initial client contact
Other addresses to be contacted at boot time

L'entrée 0.0.0.0/32 autorise uniquement les clients de l'application à atteindre le serveur d'application.