Etiquetage d'hôtes et de réseaux (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. Etant 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.

Affichage des modèles de sécurité existants (tâches)

Avant d'étiqueter les réseaux et les hôtes distants, consultez les modèles de sécurité fournis et assurez-vous que vous pouvez atteindre les réseaux et les hôtes distants. Pour obtenir des instructions, reportez-vous aux sections suivantes :

Afficher les modèles de sécurité : Affichage des modèles de sécurité
Déterminer si votre site nécessite des modèles de sécurité personnalisés : Evaluation de la nécessité d'utiliser des modèles de sécurité personnalisés sur votre site
Ajouter des systèmes et des réseaux au réseau de confiance : Ajout d'hôtes au réseau connu du système

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.

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

# tncfg list
   cipso
   admin_low
   adapt
   netif

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 l'entrée 0.0.0.0/0 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 l'entrée 0.0.0.0/0 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 Limitation des hôtes pouvant être contactés sur le réseau de confiance.
```
# tncfg -t adapt info
   name=adapt
   host_type=adapt
   doi=1
   min_label=ADMIN_LOW
   max_label=ADMIN_HIGH
   host=0.0.0.0/0
```
Un modèle adapt identifie un hôte adaptatif, c'est-à-dire un système non sécurisé qui ne peut pas disposer d'une étiquette par défaut. En revanche, son étiquette est assignée par son système de confiance de réception. L'étiquette est dérivée de l'étiquette par défaut de l'interface IP qui reçoit le paquet, comme défini par le modèle netif du système étiqueté.
```
# tncfg -t netif info
   name=netif
   host_type=netif
   doi=1
   def_label=ADMIN_LOW
   min_label=ADMIN_LOW
   max_label=ADMIN_HIGH
   host=127.0.0.1/32
```
Un modèle netif indique une interface du réseau local de confiance, et non un hôte distant. L'étiquette par défaut d'un modèle netif doit être égale à l'étiquette de chaque zone avec une interface réseau dédiée dont l'adresse IP correspond à l'adresse de l'hôte dans ce modèle. En outre, la liaison inférieure qui correspond à l'interface de zone correspondante peut uniquement être assignée à d'autres zones qui partagent la même étiquette.

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

Créez des modèles de sécurité spécifiques au site 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 un ensemble limité d'étiquettes.
- Utiliser un DOI autre que 1.
- Envoyer des informations à partir d'hôtes spécifiés sans étiquette à une interface réseau qui est autorisée à assigner l'étiquette appropriée aux paquets des hôtes sans étiquette.

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.

Ajoutez des hôtes individuels dans le fichier /etc/hosts.
```
# pfedit /etc/hosts

...
192.168.111.121   ahost
```

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

# pfedit /etc/hosts

...
192.168.111.0   111-network

Création de modèles de sécurité (tâches)

Cette section contient des pointeurs ou des exemples de création de modèles de sécurité pour les configurations réseau suivantes :

Le DOI est une valeur différente de 1 : Configuration d'un autre domaine d'interprétation
Une étiquette spécifique est assignée aux hôtes distants de confiance : Exemple 16-1
Une étiquette spécifique est assignée aux hôtes distants non sécurisés : Exemple 16-2

Pour obtenir plus d'exemples de modèles de sécurité qui répondent à des obligations spécifiques, reportez-vous à la section Ajout d'hôtes aux modèles de sécurité (tâches).

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.

(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.
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 Limitation des hôtes pouvant être contactés sur le réseau de confiance.
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. Saisissez exit pour terminer le modèle.
```
# tncfg -t newunlabeled
tncfg:newunlabeled> 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
...
tncfg:newunlabeled> commit
tncfg:newunlabeled> exit
```
  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: unlab_1> set host_type=unlabeled
...
# tncfg -f template-file
```
  Pour obtenir un exemple de création 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-3.

Exemple 16-2 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 non étiqueté pour les hôtes non sécurisés qui peuvent recevoir et envoyer des paquets uniquement sous l'étiquette PUBLIC. 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-12.

Ajout d'hôtes aux modèles de sécurité (tâches)

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 :

La passerelle distante de confiance gère le trafic PUBLIC : Exemple 16-3
Les hôtes distants non sécurisés jouent le rôle de routeurs à étiquette unique : Exemple 16-4
Les hôtes distants de confiance limitent le trafic à une plage d'étiquettes réduite : Exemple 16-5
Un ensemble limité d'étiquettes est assigné aux hôtes distants de confiance : Exemple 16-6
Des étiquettes disjointes du reste du réseau sont assignées aux hôtes distants de confiance : Exemple 16-7
Paquets d'étiquettes d'hôte netif de confiance des systèmes adapt : Exemple 16-8
L'hôte adapt non sécurisé envoie des paquets à un hôte netif : Exemple 16-9
Le réseau homogène de confiance ajoute une adresse de multidiffusion sous une étiquette spécifique : Exemple 16-10
Un hôte est supprimé d'un modèle de sécurité : Exemple 16-11
Des étiquettes sont assignées aux hôtes et aux réseaux non sécurisés distants : Exemple 16-12

Ajout d'un hôte au modèle de sécurité

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 DNS, reportez-vous au Chapitre 3, Gestion de DNS (tâches) du manuel Utilisation des services de noms et d’annuaire dans Oracle Solaris 11.1.
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.

(Facultatif) Assurez-vous que vous pouvez atteindre le nom d'hôte ou l'adresse IP que vous allez ajouter.
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.
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.2
192.168.1.2 previously matched the admin_low template
tncfg:cipso> info
...
host=192.168.1.2/32
tncfg:cipso> exit
```
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.
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-3 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-4 Création d'un routeur sans étiquette pour acheminer des paquets étiquetés

Tous 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 sous 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_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 routeur-1.

Exemple 16-5 Création d'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 et ajoute la passerelle.

# 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-6 Création d'hôtes sous des é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é.

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

Exemple 16-7 Création d'un hôte é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> 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-8 Création d'un modèle de sécurité pour un hôte netif

Dans 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> exit

Exemple 16-9 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 adapt. 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> exit

Exemple 16-10 Envoi de messages de multidiffusion étiquetés

Sur un réseau LAN homogène et étiqueté, l'administrateur 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> exit

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
#

Ajout d'une plage d'hôtes au modèle de sécurité

Avant de commencer

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

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 IPv4 au modèle cipso, 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
```
Pour affecter un modèle de sécurité à une plage d'adresses, spécifiez l'adresse IP et la longueur du préfixe.
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 ne saisissez pas correctement une entrée, comme omettre :200 dans l'adresse, vous recevez un message semblable au suivant :
```
# 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'un sous-réseau non étiqueté sous l'étiquette PUBLIC

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

Limitation des hôtes pouvant atteindre le réseau de confiance (tâches)

Dans cette section, vous protégez le réseau en limitant le nombre d'hôtes qui peuvent atteindre le réseau.

Limitation des hôtes pouvant être contactés sur le réseau de confiance
Augmenter la sécurité en spécifiant les systèmes à contacter au moment de l'initialisation : Exemple 16-13
Configurer un serveur d'applications de manière à ce qu'il accepte le contact initial provenant d'un client distant : Exemple 16-15
Configurer un serveur Sun Ray étiqueté de manière à ce qu'il accepte le contact initial provenant d'un client distant : Exemple 16-16

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 des clients à l'adresse hôte 0.0.0.0/32, vous devez alors ajouter l'entrée d'hôte 0.0.0.0/32 au modèle admin_low. Par exemple, pour recevoir les demandes de connexion initiale de clients Sun Ray potentiels, les serveurs Sun Ray doivent inclure cette entrée. Une fois que le serveur a reconnu les clients, une adresse IP est assignée aux clients et ces derniers sont connectés en tant que clients étiquetés.

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.

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.
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-14.
Assurez-vous que les assignations d'hôtes n'empêchent pas le système de s'initialiser.

Exemple 16-13 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-14 Enumération de systèmes pour qu'un système Trusted Extensions effectue un contact à 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-15 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.

Exemple 16-16 Configuration d'une adresse initiale valide pour un serveur Sun Ray étiqueté

Dans cet exemple, l'administrateur de sécurité configure un serveur Sun Ray pour accepter les demandes de connexion initiale des clients potentiels. Le serveur utilise une topologie privée et les valeurs par défaut du serveur Sun Ray.

# utadm -a net0

L'administrateur configure ensuite 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 Sun Ray server address
   host=192.168.128.0/24 Sun Ray 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 Sun Ray client network
   host=0.0.0.0/0 Wildcard address
Other addresses to be contacted at boot time

# 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 Sun Ray 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 Sun Ray à accéder au serveur.

Ignorer les liens de navigation
Quitter l'aperu
	Configuration et administration de Trusted Extensions Oracle Solaris 11.1 Information Library (Français)