Le plan de gestion est utilisé pour accéder à un périphérique, le configurer et le gérer, ainsi que pour surveiller ses opérations et le réseau sur lequel il est déployé. Le plan de gestion reçoit et envoie le trafic pour les opérations de ces fonctions. Le plan de gestion et le plan de commande d’un périphérique doivent être sécurisés, car les opérations du plan de commande ont une incidence directe sur les opérations du plan de gestion. La liste suivante comprend les protocoles utilisés par le plan de gestion :

• SNMP

• Telnet

• SSH

• SFTP

• FTP

• TFTP

• HTTP / HTTPS

• Protocole Secure Copy Protocol ( SCP)

• TACACS+

• RADIUS

• LDAP

• Protocole de temps réseau (NTP)

• Syslog

Les administrateurs doivent prendre des mesures pour assurer l’intégrité des plans de gestion et de commande lors des incidents de sécurité. Si l’un de ces plans est exploité avec succès, tous les plans peuvent être compromis.

Étant donné que des renseignements peuvent être divulgués au cours d’une séance de gestion interactive, le trafic doit être chiffré afin qu’un utilisateur malveillant ne puisse pas lire les données transmises. Le chiffrement du trafic permet une connexion sécurisée d’accès à distance au périphérique. Si le trafic d’une session de gestion est envoyé sur le réseau en texte brut, un pirate pourrait obtenir des informations sensibles sur le périphérique et le réseau. Les protocoles suivants sont pris en charge sur FXOS :

• SSH

• TLS

• HTTPS

• SNMP

• LDAP

• Telnet

  Remarque

  Telnet n’est pas un protocole sécurisé, et nous recommandons aux administrateurs de FXOS de ne pas l’utiliser.

Les sections suivantes détaillent les options de configuration de renforcement pour les protocoles de session de gestion.

Après la configuration initiale, un certificat SSL autosigné est généré pour une utilisation avec l’application Web du châssis FXOS. Comme ce certificat est autosigné, les navigateurs clients ne le font pas automatiquement confiance. La première fois qu’un nouveau navigateur client accède à l’interface Web du châssis FXOS, le navigateur lance un avertissement SSL et demande à l’utilisateur d’accepter le certificat avant d’accéder au châssis FXOS. Vous devez générer une requête de signature de certificat (CSR) à l’aide de l’interface de ligne de commande de FXOS et installer le certificat d’identité qui en découle pour l’utiliser avec le châssis FXOS. Ce certificat d’identité permet à un navigateur client de faire confiance à la connexion et d’afficher l’interface Web sans avertissement.

Pour la procédure complète d’installation d’un certificat d’identité de confiance, consultez la rubrique « Installation d’un certificat d’identité de confiance » dans le Guide de configuration de l’interface de ligne de commande Cisco Firepower 4100/9300 FXOS.

Le protocole HTTPS utilise des composants de l’infrastructure de clé publique (PKI) pour établir des communications sécurisées entre deux appareils, comme le navigateur d’un client et le Châssis 9300 .

Points de confiance

Pour fournir une authentification renforcée pour FXOS, vous pouvez obtenir et installer un certificat tiers à partir d’une source ou d’un point de confiance qui confirme l’identité de votre périphérique. Le certificat tiers est signé par le point de confiance d’émetteur, qui peut être une autorité de certification racine (CA) ou une CA intermédiaire ou une ancre d’approbation faisant partie d’une chaîne d’approbation qui mène à une CA racine. Pour obtenir un nouveau certificat, vous devez générer une demande de certificat par l’intermédiaire de FXOS et soumettre la demande à un point de confiance.

Important

Le certificat doit être au format X.509 codé en Base64 (CER).

Utilisez le flux de travail suivant pour configurer et renforcer le protocole HTTPS sur votre châssis FXOS :

1. Créez un trousseau de clés (consultez la rubrique « Création d’un trousseau de clés » du Guide de configuration de l’interface de ligne de commande Cisco Firepower 4100/9300 FXOS).

2. Créez une demande de certificat pour un trousseau de clés (consultez la rubrique « Création d’une demande de certificat pour un trousseau de clés avec des options avancées » du Guide de configuration de l’interface de ligne de commande Cisco Firepower 4100/9300 FXOS).

3. Créez un point de confiance (consultez la rubrique « Création d’un point de confiance » du Guide de configuration de l’interface de ligne de commande Cisco Firepower 4100/9300 FXOS).

4. Importez le certificat dans le trousseau de clés (consultez la rubrique « Importation d’un certificat dans un trousseau de clés » du Guide de configuration de l’interface de ligne de commande Cisco Firepower 4100/9300 FXOS).

Utilisez les options supplémentaires suivantes pour renforcer le HTTPS :

• Précisez le niveau de sécurité de la suite de chiffrement utilisé par le domaine (set https cipher-suite-mode ). Nous recommandons une valeur fort ou personnalisé. Si vous choisissez personnalisé, vous devez préciser un niveau personnalisé de sécurité de la suite de chiffrement pour le domaine ( set https cipher-suite cipher-suite-spec-chaîne ).

• Activez la vérification de la liste de révocation de certificat.

Nous vous recommandons d’utiliser SSHv2, qui est activé par défaut en utilisant le port TCP 22. Notez les options de configuration de renforcement SSH suivantes qui peuvent être activées sur le serveur et le client :

Force de clé RSA (set ssh-server host-key rsa/set ssh-client host-key rsa)

La valeur du module (en bits) est un multiple de 8 de 1024 à 2048. Plus la taille du module de clé que vous spécifiez est grande, plus il faut de temps pour générer une paire de clés RSA. Nous recommandons une valeur de 2048.

Algorithmes de chiffrement (set ssh-server encrypt-algorithm/set ssh-client encrypt-algorithm)

Les algorithmes de chiffrement suivants sont pris en charge sur FXOS :

  3des-cbc    3DES  CBC
  aes128-cbc  AES128 CBC
  aes128-ctr  AES128 CTR
  aes192-cbc  AES192 CBC
  aes192-ctr  AES192 CTR
  aes256-cbc  AES256 CBC
  aes256-ctr  AES256 CTR

Remarque

3des-cbc n’est pas conforme aux critères communs.

Algorithme d’échange de clé Diffie-Hellman (set ssh-server kex-algorithm/set ssh-client kex-algorithm)

L’échange de clés DH fournit un secret partagé qui ne peut être déterminé par aucune des parties à elles seules. L’échange de clé est combiné à une signature et à la clé de l’hôte pour authentifier l’hôte. Cette méthode d’échange de clés fournit une authentification explicite du serveur. Pour en savoir plus sur l’utilisation des méthodes d’échange de clés DH, consultez la RFC 4253.

Les algorithmes DH suivants sont pris en charge sur FXOS :

diffie-hellman-group14-sha1  Diffie-Hellman Group14 SHA1

Algorithmes MAC des serveurs et des clients (set ssh-server mac-algorithm/set ssh-client mac-algorithm)

Les algorithmes MAC suivants sont pris en charge sur FXOS :

  hmac-sha1      Hmac SHA1
  hmac-sha2-256  HMAC SHA2 256
  hmac-sha2-512  HMAC SHA2 512

Limite de renouvellement du volume (set ssh-server rekey-limit volume/set ssh-client rekey-limit volume)

Détermine la quantité de trafic en Ko autorisée sur la connexion avant que FXOS ne se déconnecte de la session.

Time ReKey Limit (définir l’heure de reconnexion du serveur ssh-server/définir l’heure de rekey-limit ssh-client)

Détermine le nombre de minutes pendant lesquelles une session SSH peut être inactive avant que FXOS ne déconnecte la session.

Définir la vérification de clé d’hôte stricte (définir ssh-client stricthostkeycheck)

Contrôle la clé d’hôte SSH en vérifiant :

• enable (activer) - La connexion est rejetée si la clé de l’hôte n’est pas déjà dans le fichier des hôtes connus de FXOS. Vous devez ajouter manuellement des hôtes à l’aide de la commande CLI FXOS enter ssh-host dans l’étendue système/services.

• prompt (invite) - Vous êtes invité à accepter ou à rejeter la clé d’hôte si elle n’est pas déjà stockée sur le châssis.

• disable (désactiver) : (valeur par défaut) le châssis accepte automatiquement la clé d’hôte si elle n’a pas été stockée auparavant.

Pour connaître les procédures complètes de configuration de SSH sur votre châssis FXOS, consultez le chapitre des paramètres de la plateforme dans le Guide de configuration de Cisco Firepower 4100/9300 FXOS Chassis Manager et dans le Guide de configuration de Cisco Firepower 4100/9300 FXOS CLI.

Il est essentiel que votre protocole de gestion de réseau simple (SNMP) soit correctement sécurisé afin de protéger la confidentialité, l’intégrité et la disponibilité des données du réseau et des appareils réseau par lesquels ces données transitent. Le protocole SNMP fournit une kyrielle d’informations sur l’état des périphériques réseau. Ces renseignements doivent être protégés contre les utilisateurs malintentionnés qui souhaitent utiliser ces données afin d’effectuer des attaques contre le réseau.

SNMPv3 prend en charge les modèles et les niveaux de sécurité. Un modèle de sécurité est une méthode d’authentification configurée pour un utilisateur et le rôle dans lequel l’utilisateur réside. Un niveau de sécurité est le niveau de sécurité autorisé dans un modèle de sécurité. Une combinaison d’un modèle de sécurité et d’un niveau de sécurité détermine quel mécanisme de sécurité est utilisé lors du traitement d’un paquet SNMP.

Les identifiants de communauté SNMP sont des mots de passe appliqués au châssis FXOS pour restreindre l’accès en lecture seule et en lecture-écriture aux données SNMP de l’appareil. Ces identifiants de communauté, comme tous les mots de passe, doivent être sélectionnés avec soin pour éviter qu’ils ne soient pas triviaux. Les identifiants de communauté doivent être modifiés à des intervalles réguliers et conformément aux politiques de sécurité du réseau. Par exemple, les identifiants doivent être modifiés lorsqu’un administrateur réseau change de rôles ou quitte l’entreprise.

Pour en savoir plus sur les niveaux et les modèles de sécurité SNMP pris en charge, consultez la section « Configuration SNMP » du chapitre Paramètres de la plateforme du Guide de configuration de l’interface de ligne de commande Cisco Firepower 4100/9300 FXOS.

La journalisation du système est une méthode de collecte de messages des périphériques vers un serveur exécutant un daemon syslog. La journalisation sur un serveur syslog central facilite l’agrégation des journaux et des alertes. Un service syslog accepte les messages et les stocke dans des fichiers ou les imprimés conformément à un fichier de configuration simple. Cette forme de journalisation offre un stockage protégé à long terme pour les journaux. Les journaux sont utiles pour les dépannages de routine et pour le traitement des incidents.

L’envoi d’informations de journalisation à un serveur syslog distant permet de corréler et d’auditer plus efficacement les événements de réseau et de sécurité sur les périphériques réseau. Notez que les messages du journal système sont transmis en texte clair. Pour cette raison, toutes les protections qu’un réseau offre au trafic de gestion (par exemple, le chiffrement ou l’accès hors bande) doivent être étendues pour inclure le trafic syslog. Pour vous assurer que le trafic journal système n’est jamais envoyé en texte clair sur des réseaux non fiables, vous pouvez configurer le canal sécurisé IPSec. IPSec fournit un service de chiffrement et d’authentification de bout en bout sur les paquets de données qui empruntent le réseau public.

Pour en savoir plus sur la configuration de syslog sur votre châssis FXOS, consultez la section Configuration de Syslog du chapitre des paramètres de la plateforme du Guide de configuration de l’interface de ligne de commande Cisco Firepower 4100/9300 FXOS. Pour en savoir plus sur la configuration d’IPSec, consultez la rubrique Configurer le canal sécurisé IPSec du Guide de configuration de l’interface de ligne de commande Cisco Firepower 4100/9300 FXOS.

Par défaut, le châssis FXOS refuse tout accès au serveur Web local. Vous devez configurer votre liste d’accès IP avec les adresses IP des hôtes ou des sous-réseaux autorisés pour chaque protocole.

La liste d’accès IP prend en charge les protocoles suivants :

• HTTPS

• SSH

• SNMP

Pour chaque liste d’adresses IP (v4 ou v6), jusqu’à 100 sous-réseaux différents peuvent être configurés pour chaque service. Un sous-réseau de 0 et un préfixe de 0 permettent un accès sans restriction à un service.

Pour plus d’informations et des procédures complètes sur la configuration des listes d’accès IP sur votre châssis FXOS, consultez la rubrique « Configuration de la liste d’accès IP » dans le chapitre Paramètres de la plateforme du Guide de configuration de Cisco Firepower 4100/9300 FXOS Chassis Manager et de Cisco Firepower 4100/ 9300 Guide de configuration de l’interface de ligne de commande FXOS.

Configurez IPSec sur votre châssis Firepower 4100/9300 pour fournir un service de chiffrement et d’authentification de bout en bout sur les paquets de données passant par le réseau public.

Remarque

Si vous utilisez un canal sécurisé IPSec en mode FIPS, l’homologue IPSec doit prendre en charge la RFC 7427.

Pour des instructions complètes sur la configuration d’un canal sécurisé IPSec pour votre châssis FXOS, consultez la rubrique « Configuration du canal sécurisé IPSec » dans le chapitre Conformité des certifications de sécurité du Guide de configuration de l’interface de ligne de commande Cisco Firepower 4100/9300 FXOS.

Vous pouvez configurer votre mode de vérification de liste de révocation de certificat (CRL) pour qu’il soit strict ou décompressé dans les connexions IPSec, HTTPS et LDAP sécurisées.

FXOS récupère les informations de CRL dynamiques (non statiques) à partir des informations CDP d’un certificat X.509, ce qui indique les informations de CRL dynamiques. L’administration du système télécharge manuellement les informations sur les CRL statiques, ce qui indique les informations sur les CRL locales dans le système FXOS. FXOS traite les informations de CRL dynamiques en fonction du certificat de traitement actuel dans la chaîne de certificats. La liste de révocation de certificats statique est appliquée à l’ensemble de la chaîne de certificats homologues.

Pour les étapes à suivre pour activer ou désactiver les contrôles de révocation de certificat pour vos connexions sécurisées IPSec, LDAP et HTTPS, consultez Configuration du canal sécurisé IPSec, Création d’un fournisseur LDAP et configuration du protocole HTTPS.

Remarque

Si le mode de vérification de révocation de certificat est défini sur Strict, la CRL statique ne s’applique que lorsque la chaîne de certificats homologues a un niveau de 1 ou plus. (Par exemple, lorsque la chaîne de certificats homologues ne contient que le certificat de l’autorité de certification racine et le certificat homologue signé par l’autorité de certification racine.) Lors de la configuration de la CRL statique pour IPSec, le champ Authority Key Identifier (authkey) doit être présent dans le fichier CRL importé. Dans le cas contraire, IPSec la considère comme non valide. La CRL statique a priorité sur la CRL dynamique du même émetteur. Lorsque FXOS valide le certificat homologue, si une CRL statique valide (déterminée) du même émetteur existe, FXOS ignore le CDP dans le certificat homologue. La vérification stricte des CRL est activée par défaut dans les scénarios suivants : Connexions fournisseur LDAP sécurisées, connexions IPSec ou entrées de certificat client nouvellement créées Gestionnaires de châssis FXOS nouvellement déployés (déployés avec une version initiale de démarrage de FXOS 2.3.1.x ou une version ultérieure)

Les tableaux suivants décrivent les résultats de la connexion, en fonction de vos paramètres de vérification de liste de révocation de certificat et de la validation de certificat.

Les certifications révoquées sont conservées dans la liste des révocations de certification (Certificate Revocation List ou CRL). Les applications clients utilisent la liste de révocation de certificats pour vérifier l’authentification d’un serveur. Les applications serveur utilisent la liste de révocation de certificats pour accorder ou refuser les demandes d’accès des applications clientes qui ne sont plus de confiance.

Vous pouvez configurer votre châssis Firepower 4100/9300 pour valider les certificats de pair à l’aide des informations de la liste de révocation de certification (CRL).

Une fois que vous avez configuré la validation des certificats homologues à l’aide des informations de la liste de révocation de certification, vous pouvez également configurer votre système pour télécharger périodiquement une CRL afin qu’une nouvelle CRL soit utilisée toutes les 1 à 24 heures pour valider les certificats.

Pour des instructions détaillées sur la configuration d’une liste de révocation de certification pour un point de confiance, consultez la rubrique « Configurer la CRL statique pour un point de confiance » dans le chapitre Conformité des certifications de sécurité du Guide de configuration de l’interface de ligne de commande Cisco Firepower 4100/9300 FXOS.