Configuration des Routes et Vérification des Informations Réseau dans les Extensions de confiance (Carte des tâches)

La carte des tâches suivante décrit les tâches de configuration du réseau et de vérification de la configuration.

Comment configurer des Routes Avec des Attributs de sécurité

Avant de Commencer

, vous devez avoir le rôle d’administrateur de sécurité dans la zone globale.

1. Ajoutez chaque hôte et passerelle de destination que vous utilisez aux routepackets sur le réseau de confiance.

   Les adresses sont ajoutées au fichier local /etc/hosts, ou à son équivalent sur le serveur LDAP. Utilisez l’outil Ordinateurs et réseaux de la console de gestion Solaris. La portée des fichiers modifie le fichier /etc/hosts. Le LDAPscope modifie les entrées sur le serveur LDAP. Pour plus de détails, voir Comment ajouter des hôtes au réseau connu du Système.

2. Attribuez chaque hôte, réseau et passerelle de destination à un modèle de sécurité.

   Les adresses sont ajoutées au fichier local /etc/security/tsol/tnrhdb, ou à son équivalent sur le serveur LDAP. Utilisez l’outil Modèles de sécurité dans la console SolarisManagement. Pour plus de détails, reportez-vous à la section Comment Attribuer un modèle de sécurité à un hôte ou à un groupe d’hôtes.

3. Configurez les itinéraires.

   Dans une fenêtre de terminal, utilisez la commande ajouter une route pour spécifier des routes.

   La première entrée définit une route par défaut. L’entrée spécifie l’adresse d’agateway, 192.168.113.1, à utiliser lorsqu’aucune route spécifique n’est définie pour l’hôte ou la destination du paquet.

   # route add default 192.168.113.1 -static

   Pour plus de détails, consultez la page de manuel route(1M).

4. Configurez une ou plusieurs entrées réseau.

   Utilisez l’indicateur -secattr pour spécifier les attributs de sécurité.

   Dans la liste de commandes suivante, la deuxième ligne affiche une tentative de réseau. La troisième ligne montre une entrée réseau avec une plage d’étiquettes de PUBLIC à CONFIDENTIEL: USAGE INTERNE UNIQUEMENT.

   # route add default 192.168.113.36# route add -net 192.168.102.0 gateway-101# route add -net 192.168.101.0 gateway-102 \-secattr min_sl="PUBLIC",max_sl="CONFIDENTIAL : INTERNAL USE ONLY",doi=1

5. Configurez une ou plusieurs entrées d’hôte.

   La nouvelle quatrième ligne affiche une entrée d’hôte pour l’hôte à étiquette unique, gateway-pub. gateway-pub a une gamme d’étiquettes de PUBLIC à PUBLIC.

   # route add default 192.168.113.36# route add -net 192.168.102.0 gateway-101# route add -net 192.168.101.0 gateway-102 \-secattr min_sl="PUBLIC",max_sl="CONFIDENTIAL : INTERNAL USE ONLY",doi=1# route add -host 192.168.101.3 gateway-pub \-secattr min_sl="PUBLIC",max_sl="PUBLIC",doi=1

Exemple 13-14 Ajout d’un Itinéraire Avec une Plage d’Étiquettes de CONFIDENTIEL : USAGE INTERNE UNIQUEMENT à CONFIDENTIEL : RESTREINT

La commande de route suivante ajoute à la table de routage les hôtes at192.168.115.0 avec 192.168.118.39 comme passerelle. La gamme d’étiquettes va de CONFIDENTIEL: USAGE INTERNE uniquement à CONFIDENTIEL: RESTREINT, et le DOI est 1.

$ route add -net 192.168.115.0 192.168.118.39 \-secattr min_sl="CONFIDENTIAL : INTERNAL USE ONLY",max_sl="CONFIDENTIAL : RESTRICTED",doi=1

Le résultat des hôtes ajoutés est affiché avec le netstat-rR command.In l’extrait suivant, les autres routes sont remplacées par des ellipses (…).

$ netstat -rRn...192.168.115.0 192.168.118.39 UG 0 0 min_sl=CNF : INTERNAL USE ONLY,max_sl=CNF : RESTRICTED,DOI=1,CIPSO...

Comment vérifier la syntaxe des bases de données réseau de confiance

La commande tnchkdb vérifie que la syntaxe de chaque base de données réseau est exacte.La console de gestion Solaris exécute cette commande automatiquement lorsque vous utilisez l’outil Modèles de sécurité ou l’outil Zones de réseau de confiance. En règle générale, vous exécutez cette commande pour vérifier la syntaxe des fichiers de base de données que vous configurez pour une utilisation future.

Avant de Commencer

, Vous devez être dans la zone globale dans un rôle qui peutvérifier les paramètres réseau. Le rôle d’Administrateur de sécurité et le rôle d’Administrateur systèmepeut vérifier ces paramètres.

• Dans une fenêtre de terminal, exécutez la commande tnchkdb.

  $ tnchkdb checking /etc/security/tsol/tnrhtp ...checking /etc/security/tsol/tnrhdb ...checking /etc/security/tsol/tnzonecfg ...

Exemple 13-15 Test de la syntaxe d’une base de données réseau d’essai

Dans cet exemple, l’administrateur de sécurité teste un fichier de base de données réseau pour une utilisation possible. Initialement, l’administrateur utilise la mauvaise option. Les résultats de la vérification sont imprimés sur la ligne du fichier tnrhdb:

$ tnchkdb -h /opt/secfiles/trial.tnrhtpchecking /etc/security/tsol/tnrhtp ...checking /opt/secfiles/trial.tnrhtp ...line 12: Illegal name: min_sl=ADMIN_LOW;max_sl=ADMIN_HIGHline 14: Illegal name: min_sl=ADMIN_LOW;max_sl=ADMIN_HIGHchecking /etc/security/tsol/tnzonecfg ...

Lorsque l’administrateur de sécurité vérifie le fichier à l’aide de l’option -t, la commande confirme que la syntaxe de la base de données tnrhtp d’essai est exacte:

$ tnchkdb -t /opt/secfiles/trial.tnrhtpchecking /opt/secfiles/trial.tnrhtp ...checking /etc/security/tsol/tnrhdb ...checking /etc/security/tsol/tnzonecfg ...

Comment comparer les informations de base de données Réseau de confiance Avec le cache du Noyau

Les bases de données réseau peuvent contenir des informations qui ne sont pas mises en cache dans le noyau. Cette procédure vérifie que les informations sont identiques. Lorsque vous utilisez la console de gestion Solaris pour mettre à jour le réseau, le cache du noyau est mis à jour avec les informations de la base de données réseau. La commande tninfo est utile lors des tests etpour le débogage.

Avant de Commencer

, Vous devez être dans la zone globale dans un rôle qui peutvérifier les paramètres réseau. Le rôle d’Administrateur de sécurité et le rôle d’Administrateur systèmepeut vérifier ces paramètres.

• Dans une fenêtre de terminal, exécutez la commande tninfo.

  • tninfo-h hostname affiche l’adresse IP et le modèle de l’hôte spécifié.

  • tninfo-t templatename affiche les informations suivantes:

    template: template-namehost_type: either CIPSO or UNLABELEDdoi: 1min_sl: minimum-labelhex: minimum-hex-labelmax_sl: maximum-labelhex:maximum-hex-label

  • tninfo-m zone-name affiche la configuration de port multiniveau (MLP) d’une zone.

Exemple 13-16 Affichage de ports multiniveaux sur un hôte

Dans cet exemple, un système est configuré avec plusieurs zones étiquetées. Toutes les zones partagent la même adresse IP. Certaines zones sont également configurées avec des adresses spécifiques à la zone. Dans cette configuration, le port TCP pour la navigation Web, port8080, est un MLP sur une interface partagée dans la zone publique. L’administrateur a également configuré telnet, port TCP 23, pour être anMLP dans la zone publique. Parce que ces deux MLP sont sur une interface partagée, aucune autre zone, y compris la zone globale, ne peut recevoir de paquets sur l’interface partagée sur les ports 8080 et 23.

De plus, le port TCP pour ssh, le port 22, est un par zoneMLP dans la zone publique. Le service ssh de la zone publique peut recevoir tous les paquets sur son adresse spécifique à la zone dans la plage d’étiquettes de l’adresse.

La commande suivante affiche les MLP pour la zone publique:

$ tninfo -m publicprivate: 22/tcpshared: 23/tcp;8080/tcp

La commande suivante affiche les MLP pour la zone globale. Notez que les ports 23 et 8080 ne peuvent pas être des MLP dans la zone globale car la zone globale partage la même adresse avec la zone publique:

$ tninfo -m globalprivate: 111/tcp;111/udp;514/tcp;515/tcp;631/tcp;2049/tcp; 6000-6003/tcp;38672/tcp;60770/tcp;shared: 6000-6003/tcp

Comment synchroniser le Cache du Noyau Avec des bases de données Réseau de confiance

Lorsque le noyau n’a pas été mis à jour avec des informations de base de données réseau de confiance, vous avez plusieurs façons de mettre à jour le cache du noyau. La console de gestion Solaris exécute cette commande automatiquement lorsque vous utilisez l’outil Modèles de sécurité ou l’outil Zones de réseau de confiance.

Avant de commencer

, vous devez occuper le rôle d’administrateur de sécurité dans la zone globale.

• Pour synchroniser le cache du noyau avec les bases de données réseau, exécutez l’une des commandes suivantes :
  • Redémarrez le service tnctl.

    Attention – N’utilisez pas cette méthode sur les systèmes qui obtiennent leurs informations de base de données réseau de confiance à partir d’un serveur LDAP. Les informations de la base de données locale écrasentles informations obtenues à partir du serveur LDAP.

    $ svcadm restart svc:/network/tnctl

    Cette commande lit toutes les informations des bases de données du réseau de confiance local dans le noyau.

  • Mettez à jour le cache du noyau pour vos entrées récemment ajoutées.

    $ tnctl -h hostname

    Cette commande lit uniquement les informations de l’option choisie dans le noyau. Pour plus de détails sur les options, reportez-vous à l’exemple 13-17 et à la page de manuel tnctl(1M).

  • Modifiez le service tnd.

    Remarque – Le service tnd s’exécute uniquement si le service ldap est en cours d’exécution.

    • Modifiez l’intervalle d’interrogation tnd.

      Cela ne met pas à jour le cache du noyau. Cependant, vous pouvez raccourcir l’intervalle d’interrogation pour mettre à jour le cache du noyau plus fréquemment. Pour plus de détails, consultez l’exemple dans la page de manuel de tnd(1M).

    • Actualisez le tnd.

      Cette commande SMF (Service Management Facility) déclenche une mise à jour immédiate de thekernel avec les modifications récentes apportées aux bases de données du réseau de confiance.

      $ svcadm refresh svc:/network/tnd

    • Redémarrez le tnd en utilisant SMF.

      $ svcadm restart svc:/network/tnd

      Attention – Évitez d’exécuter la commande tnd pour redémarrer le tnd. Cette commande peutinterrupter les communications qui réussissent actuellement.

Exemple 13-17 Mise à jour du Noyau Avec Vos dernières entrées tnrhdb

Dans cet exemple, l’administrateur a ajouté trois adresses à la base de données localtnrhdb. Tout d’abord, l’administrateur a supprimé l’entrée générique 0.0.0.0.

$ tnctl -d -h 0.0.0.0:admin_low

Ensuite, l’administrateur visualise le format des trois dernières entrées dans la base de données /etc/security/tsol/tnrhdb:

$ tail /etc/security/tsol/tnrhdb#\:\:0:admin_low127.0.0.1:cipso#\:\:1:cipso192.168.103.5:admin_low192.168.103.0:cipso0.0.0.0/32:admin_low

Ensuite, l’administrateur met à jour le cache du noyau:

$ tnctl -h 192.168.103.5tnctl -h 192.168.103.0tnctl -h 0.0.0.0/32

Enfin, l’administrateur vérifie que le cache du noyau est mis à jour. La sortie pour la première entrée est similaire à ce qui suit:

$ tninfo -h 192.168.103.5IP Address: 192.168.103.5Template: admin_low

Exemple 13-18 Mise à jour des informations réseau dans le Noyau

Dans cet exemple, l’administrateur met à jour le réseau de confiance avec un serveur publicprint, puis vérifie que les paramètres du noyau sont corrects.

$ tnctl -h public-print-server$ tninfo -h public-print-serverIP Address: 192.168.103.55Template: PublicOnly$ tninfo -t PublicOnly==================================Remote Host Template Table Entries----------------------------------template: PublicOnlyhost_type: CIPSOdoi: 1min_sl: PUBLIChex: 0x0002-08-08max_sl: PUBLIChex: 0x0002-08-08