Présentation des meilleures pratiques en matière de sécurité Citrix ADC MPX, VPX et SDX

Une appliance Citrix ADC MPX est un contrôleur de distribution d’applications qui accélère les sites Web, assure la gestion du trafic L4-L7, offre un Citrix Web App Firewall intégré et décharge les serveurs. Une instance Citrix ADC VPX est une appliance virtuelle qui possède toutes les fonctionnalités d’une appliance Citrix ADC MPX, s’exécute sur des serveurs standard et offre une plus grande disponibilité pour les applications Web, notamment Citrix XenDesktop et XenApp. Une appliance Citrix ADC SDX offre une virtualisation avancée pour toute la flexibilité de VPX avec les performances de MPX. À l’aide de MPX, VPX et SDX, une organisation peut déployer la solution flexible ou multi-locataire qui optimise votre infrastructure de mise à disposition d’applications Web en séparant les services réseau partagés à volume élevé des services spécifiques aux applications exigeants en processeurs. Une appliance Citrix ADC offre également une intégration transparente avec Citrix OpenCloud Access qui peut étendre le datacenter avec la puissance du Cloud.

Pour maintenir la sécurité tout au long du cycle de vie du déploiement, Citrix recommande d’examiner les considérations suivantes pour :

  • Sécurité physique
  • Sécurité de l’appliance
  • Sécurité du réseau
  • Administration et gestion

Différents déploiements peuvent nécessiter des considérations de sécurité différentes. Ce document fournit des conseils de sécurité généraux pour vous aider à décider d’un déploiement sécurisé approprié en fonction de vos exigences de sécurité spécifiques.

Important :

à partir de la version 12.1 du logiciel, NetScaler est rebaptisé Citrix ADC. Pour plus d’informations, consultez https://www.citrix.com/about/citrix-product-guide/.

Directives de déploiement

Lors du déploiement d’un Citrix ADC, tenez compte des meilleures pratiques de sécurité physique et d’appliance suivantes :

Meilleures pratiques de sécurité physique

Déployer l’appliance Citrix ADC dans un emplacement sécurisé

Les appliances Citrix ADC doivent être déployées dans un emplacement sécurisé avec des contrôles d’accès physiques suffisants pour protéger les appliances contre les accès non autorisés. Au minimum, l’accès à la salle des serveurs doit être contrôlé à l’aide d’une serrure, d’un lecteur de carte électronique ou d’autres méthodes physiques similaires.

D’autres mesures peuvent inclure l’utilisation d’un système de surveillance électronique, par exemple la vidéosurveillance, pour surveiller en permanence l’activité de la pièce. En cas d’intrusion non autorisée, la sortie de ce système doit en informer le personnel de sécurité. S’il y a une vidéosurveillance, les images enregistrées sont disponibles à des fins d’audit.

Accès sécurisé au panneau avant de l’appliance et au port de la console

L’appliance Citrix ADC ou le serveur d’hébergement VPX doit être déployé dans un rack ou une cage pouvant être verrouillé à l’aide d’une clé appropriée ou d’autres méthodes physiques. Le verrouillage empêche l’accès aux ports physiques de l’appliance Citrix ADC ou, dans un déploiement VPX, à la console hôte de virtualisation.

Protection de l’alimentation

L’appliance Citrix ADC (ou le serveur d’hébergement) doit être protégée par une alimentation sans interruption appropriée. En cas de panne de courant, l’alimentation sans interruption garantit le fonctionnement continu de l’appliance ou permet un arrêt contrôlé des Citrix ADC physiques ou virtuels. L’utilisation d’une alimentation sans coupure contribue également à la protection contre les pics de puissance.

Protection des clés cryptographiques

Si une protection supplémentaire est requise pour les clés cryptographiques de votre déploiement, envisagez d’utiliser une appliance conforme à la norme FIPS 140-2 Niveau 2. La plate-forme FIPS utilise un module de sécurité matérielle pour protéger les clés cryptographiques critiques de l’appliance contre un accès non autorisé.

Meilleure pratique de sécurité de l’appliance Citrix ADC

Mise à jour logicielle de l’appliance

Citrix recommande fortement que, avant le déploiement, les clients s’assurent que leurs appliances ont été mises à jour avec les dernières versions du microprogramme. Lorsqu’elle est effectuée à distance, Citrix recommande aux clients d’utiliser un protocole sécurisé, tel que SFTP ou HTTPS, pour mettre à niveau l’appliance.

Il est également conseillé aux clients de consulter les bulletins de sécurité relatifs à leurs produits Citrix. Pour plus d’informations sur les bulletins de sécurité nouveaux et mis à jour, consultez la page Web Citrix Security Bulletins (https://support.citrix.com/securitybulletins) et envisagez de vous inscrire aux alertes concernant les bulletins nouveaux et mis à jour.

Sécuriser le système d’exploitation des serveurs hébergeant une appliance Citrix ADC VPX

Une appliance Citrix ADC VPX peut exécuter une appliance virtuelle sur un serveur de virtualisation standard ou en tant qu’appliance virtuelle sur un SDX Citrix ADC.

En plus d’appliquer des procédures de sécurité physique normales, vous devez protéger l’accès à l’hôte de virtualisation avec un contrôle d’accès basé sur les rôles et une gestion solide des mots de passe. En outre, le serveur doit être mis à jour avec les derniers correctifs de sécurité pour le système d’exploitation lorsqu’ils sont disponibles, et déployer un logiciel antivirus à jour sur le serveur, le cas échéant au type de virtualisation. Les clients qui utilisent la plate-forme Citrix ADC SDX pour héberger Citrix ADC VPX doivent s’assurer qu’ils utilisent la dernière version du microprogramme pour leur SDX Citrix ADC.

Réinitialiser la gestion de la mise sous/hors tension (LOM) de Citrix ADC

Citrix recommande que, avant de configurer le LOM pour une utilisation dans un déploiement de production, vous effectuez une réinitialisation d’usine du LOM pour restaurer les paramètres par défaut.

  1. À l’invite Citrix ADC shell, exécutez la commande suivante :

    >ipmitool raw 0x30 0x41 0x1
    <!--NeedCopy-->
    

    Remarque : L’exécution de la commande précédente réinitialise le LOM aux paramètres par défaut d’usine et supprime tous les certificats SSL. Pour obtenir des instructions sur la façon de reconfigurer le port LOM, voir Port de gestion de la mise sous/hors tension de l’appliance Citrix ADC MPX.

  2. Dans l’interface graphique LOM, accédez à Configuration > Certification SSLet ajoutez un certificat et une clé privée.

    En outre, Citrix recommande fortement d’effectuer la configuration utilisateur suivante. Utilisation de l’interface graphique LOM :

    • Accédez à Configuration > Utilisateurs > Modifier l’utilisateur et modifiez le mot de passe du compte de nsroot superutilisateur.
    • Accédez à Configuration > Utilisateurs > Modifier l’utilisateur et créez des stratégies pour les utilisateurs ou liez des stratégies existantes aux utilisateurs.
    • Accédez à Configuration > Contrôle d’accès IP > Ajouter et configurer le contrôle d’accès IP pour autoriser l’accès à la plage connue d’adresses IP.
    • Accédez à Configuration > Utilisateurs > Modifier l’utilisateur, créez un autre compte superutilisateur et liez des stratégies à ce compte.

    Pour plus d’informations sur la configuration LOM, voir Configuration LOM.

Maintenance et suppression des données persistantes

Si un Citrix ADC est redéployé dans un autre environnement, mis hors service ou renvoyé à Citrix sous RMA, assurez-vous que les données persistantes sont correctement supprimées de l’appliance.

Pour plus d’informations sur ce processus, consultez la FAQ suivante : https://www.citrix.com/support/programs/faqs.html.

Consignes de configuration

Sécurité du réseau

Lors du déploiement d’une appliance Citrix ADC dans un environnement de production, Citrix recommande vivement que les modifications de configuration clés suivantes soient apportées :

  • N’exposez pas l’interface administrateur Citrix ADC (NSIP) à Internet.
  • Le certificat SSL par défaut Citrix ADC doit être remplacé.
  • HTTPS (HTTP sur TLS) doit être utilisé lors de l’accès à l’interface graphique et l’interface HTTP par défaut désactivée.

La section suivante fournit de plus amples renseignements sur ces facteurs clés, en plus des autres changements recommandés.

Considérations clés en matière de sécurité réseau

N’exposez pas le NSIP sur Internet :

Citrix recommande vivement que Citrix ADC Management IP (NSIP) ne soit pas exposée à l’Internet public et qu’elle soit déployée derrière un pare-feu SPI (Packet Inspection) approprié.

Remplacez le certificat TLS par défaut Citrix ADC :

Lors de la configuration initiale d’une appliance Citrix ADC, les certificats TLS par défaut sont créés. Ces certificats ne sont pas destinés à être utilisés dans les déploiements de production et doivent être remplacés.

Citrix recommande aux clients de configurer l’appliance Citrix ADC pour utiliser des certificats provenant d’une autorité de certification (CA) fiable ou des certificats appropriés de votre autorité de certification d’entreprise.

Lorsqu’il est lié à un serveur virtuel public, un certificat TLS valide provenant d’une autorité de certification fiable simplifie l’expérience utilisateur pour les applications Web accessibles à Internet ; les navigateurs Web utilisateur ne nécessitent aucune interaction de l’utilisateur lors de l’initialisation d’une communication sécurisée avec le serveur Web. Pour remplacer le certificat Citrix ADC par défaut par un certificat d’autorité de certification approuvé, consultez l’article CTX122521 du centre de connaissances : Comment remplacer le certificat par défaut d’une appliance Citrix ADC par un certificat d’autorité de certification de confiance correspondant au nom d’hôte de l’appliance.

Alternativement, il est possible de créer et d’utiliser des certificats TLS personnalisés et des clés privées. Bien que cela puisse fournir un niveau équivalent de sécurité de la couche de transport, il faut que les certificats TLS soient distribués aux utilisateurs et nécessite une interaction utilisateur lors du lancement de connexions au serveur Web. Pour plus d’informations sur la création de certificats personnalisés, consultez l’article CTX121617 du Centre de connaissances : Comment créer et installer des certificats auto-signés sur Citrix ADC Appliance.

Vous trouverez plus d’informations sur la gestion et la configuration des certificats TLS dans la section « Recommandations Citrix ADC TLS » de ce guide.

Désactivez l’accès HTTP à l’interface administrateur :

Pour protéger le trafic vers l’interface d’administration Citrix ADC et l’interface graphique, l’appliance Citrix ADC doit être configurée pour utiliser HTTPS. Procédez comme suit :

  • Créez une paire de clés privées et publiques RSA 2048 bits ou plus et utilisez les clés pour HTTPS et SSH pour accéder à l’adresse IP Citrix ADC, en remplaçant la paire de clés privées et publiques RSA 512 bits provisionnée en usine.

  • Configurez l’appliance pour qu’elle n’utilise que des suites de chiffrement puissantes et modifiez l’ensemble de suites de chiffrement « DEFAULT » par des suites de chiffrement fortes sur l’appliance. Il est recommandé d’utiliser la liste des suites de chiffrement TLS approuvées à la section 3.3 de la publication spéciale 800-52 du NIST (Révision 1). Ce document peut être consulté sur le site Web du NIST à l’adresse suivante : https://www.nist.gov/publications/guidelines-selection-configuration-and-use-transport-layer-security-tls-implementations?pub_id=915295

  • Configurez l’appliance pour qu’elle utilise l’authentification par clé publique SSH pour accéder à l’interface administrateur. N’utilisez pas les clés par défaut Citrix ADC. Créez et utilisez votre propre paire de clés privées et publiques RSA 2048 bits. Pour plus d’informations, consultez l’article CTX109011 du centre de connaissances : How to Secure SSH Access to the Citrix ADC Appliance with Public Key Authentication.

  • Une fois que Citrix ADC a été configuré pour utiliser ces nouveaux certificats, l’accès HTTP à l’interface de gestion de l’interface graphique peut être désactivé à l’aide de la commande suivante :

set ns ip <NSIP> -gui SECUREONLY
<!--NeedCopy-->

Pour plus d’informations sur la configuration de l’accès sécurisé à l’interface graphique d’administration, consultez l’article CTX111531 du Centre de connaissances : Comment activer Secure Access to Citrix ADC GUI Using the SNIP/MIP Address of the Appliance.

Autres considérations relatives à la sécurité du réseau

Limitez l’accès à l’interpréteur de commandes VPX aux administrateurs VPX qui ne sont pas fiables pour gérer le SDX :

Dans les situations où il est souhaitable qu’une autre personne administre un VPX à celui de la SVM, l’administrateur de la SVM doit créer un utilisateur administrateur VPX qui dispose d’un accès shell limité sur le VPX et ne fournir le compte d’utilisateur administrateur restreint qu’à l’administrateur VPX.

Notez que certaines opérations peuvent nécessiter un accès shell (par exemple l’administration de certificats SSL). Toutefois, seules les personnes qui ont confiance pour administrer la SVM doivent avoir accès à l’interpréteur de commandes d’instance VPX. Les commandes de niveau RBAC, répertoriées plus loin dans cette section, peuvent être affectées à ces comptes. Ces recommandations s’appliquent à tous les flux de travail de gestion SVM-IP/VPX-NSIP (L2/L3) et doivent être suivies à des fins d’audit d’accès sécurisé.

Les étapes suivantes peuvent être utilisées pour supprimer l’accès au shell d’un administrateur VPX.

Sécurisation d’instances VPX existantes :

  1. Connectez-vous à l’interface de ligne de commande VPX en tant que nsroot ou superutilisateur.

    Citrix recommande de ne pas utiliser le compte nsroot et de créer un compte de superutilisateur. Lorsque vous utilisez un compte nsroot, assurez-vous que les mots de passe sont forts avec des caractères spéciaux. Pour plus d’informations sur les mots de passe forts, voir Administration et gestion.

    • Créez un utilisateur et une stratégie RBAC dans une instance VPX sur le système SDX.
    • Liez cet utilisateur à la stratégie.
        > add system user userabc
        Enter password:
        Confirm password:
        Done
        > bind system user userabc superuser 2
        Done
        > add system cmdpolicy shell deny (shell)
        Done
        > bind system user userabc shell 1
        Done
    <!--NeedCopy-->
    

    Remarque : Dans cet exemple, la cmdpolicy système (ex : cmdpolicy name : shell) est créée pour refuser l’accès à l’interpréteur de commandes. Cette stratégie est liée à l’utilisateur créé (userabc) avec une priorité élevée. La cmdpolicy du superutilisateur par défaut est également liée en tant que priorité inférieure à l’utilisateur système. Avec cette configuration, l’utilisateur système créé dispose de stratégies RBAC de superutilisateur, mais l’accès à l’interpréteur de commandes est refusé.

  2. Connectez-vous en tant qu’utilisateur créé et effectuez les opérations suivantes.
    • Vérifiez que l’utilisateur actuel a appliqué les stratégies RBAC.
    • Exécutez toutes les commandes que l’utilisateur est autorisé. (par exemple, show system cmdpolicy)
    • Exécutez la cmd shell pour vérifier que l’accès à l’interpréteur de commandes est restreint.

    login as: userabc

    Message de bannière de pré-authentification du serveur :

    | #############################################################################
    > ##
    | #
    >  #
    | #        WARNING: Access to this system is for authorized users only
    >  #
    | #         Disconnect IMMEDIATELY if you are not an authorized user!
    >  #
    | #
    >  #
    | #############################################################################
    > ##
    |
    End of banner message from server
    Keyboard-interactive authentication prompts from server:
    | Password:
    End of keyboard-interactive prompts from server
    Last login: Thu May 13 04:11:15 2021 from 10.10.1.1
    Done
    <!--NeedCopy-->
    
    > whoami
        UserName:  userabc        LoggedIn:  "Thu May 13 04:18:50 2021"
    Done
    <!--NeedCopy-->
    
  3. Dans la console de ce VPX, connectez-vous en tant qu’utilisateur et assurez-vous que l’accès au shell n’est pas autorisé pour cet utilisateur :

    > shell
    ERROR: Not authorized to execute this command [shell]
    <!--NeedCopy-->
    
  4. Connectez-vous en tant qu’utilisateur administrateur normal (nsroot) et assurez-vous que l’accès au shell est autorisé :

    > shell
    Copyright (c) 1992-2013 The FreeBSD Project.
    Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
    
    root@Zela-40G-10#
    <!--NeedCopy-->
    

Sécurisation d’une nouvelle instance VPX :

  1. Lorsqu’une nouvelle instance VPX est créée à partir de l’interface graphique SVM, créez un utilisateur INSTANCE ADMIN et désactivez la case à cocher Shell/SFTP/SCP Access . Lors de la désactivation de l’accès au shell, svm_access_policy (action DENY) est explicitement lié à l’utilisateur administrateur de l’instance spécifié.

  2. Fournissez ces informations utilisateur à l’ADMIN VPX. SDX ADMIN doit conserver ce mot de passe administrateur nsroot et ne doit pas le partager avec l’administrateur VPX.

Remarque :

Désactiver le transfert de port SSH :

Le transfert de port SSH n’est pas requis par l’appliance Citrix ADC. Si vous ne souhaitez pas utiliser cette fonctionnalité, Citrix vous recommande de la désactiver en suivant les étapes suivantes :

  1. Modifiez le fichier /etc/sshd_config en ajoutant la ligne suivante.

    AllowTcpForwarding non

  2. Enregistrez le fichier et copiez-le dans /nsconfig pour que les modifications soient persistantes au cas où vous redémarrez pendant les tests.

Arrêtez le processus à l’aide de la commande kill -SIGHUP <sshdpid> ou redémarrez le système.

Configurez l’appliance Citrix ADC avec une haute disponibilité :

Dans les déploiements nécessitant un fonctionnement continu, les appliances Citrix ADC peuvent être déployées dans une configuration haute disponibilité. Une telle configuration permet de continuer à fonctionner si l’une des appliances cesse de fonctionner ou nécessite une mise à niveau hors ligne.

Pour plus d’informations sur la configuration de la configuration de la haute disponibilité, consultez la rubrique Haute disponibilité > Configuration de la haute disponibilité sur Citrix Docs et Comment configurer une paire haute disponibilité sur Citrix ADC.

Dans les déploiements où la haute disponibilité n’est pas requise, cette fonctionnalité doit être désactivée.

Configurez une communication sécurisée entre les appliances homologues :

Si vous avez configuré vos appliances Citrix ADC dans une configuration haute disponibilité, cluster ou GSLB, sécurisez la communication entre les appliances.

Pour sécuriser la communication entre les appliances, Citrix vous recommande de modifier le compte d’utilisateur interne ou le mot de passe du nœud RPC et d’activer l’option Secure. Les nœuds RPC sont des entités système internes utilisées pour la communication système à système des informations de configuration et de session.

Les fonctionnalités de l’appliance Citrix ADC peuvent également utiliser une authentification basée sur une clé SSH pour la communication interne lorsque le compte d’utilisateur interne est désactivé. Dans de tels cas, le nom de la clé doit être défini comme “ns_comm_key”. Pour plus d’informations, voir Accès à une appliance Citrix ADC à l’aide de clés SSH et sans mot de passe.

Modifiez les mots de passe par défaut :

Pour améliorer la sécurité, Citrix recommande de modifier les mots de passe de l’administrateur et du compte utilisateur interne ou du nœud RPC pour les déploiements sur site et dans le cloud. Il est conseillé de modifier fréquemment les mots de passe.

Configurer les domaines de sécurité réseau et les VLAN :

Citrix recommande fortement que le trafic réseau vers l’interface de gestion de l’appliance Citrix ADC soit séparé, physiquement ou logiquement, du trafic réseau normal. La meilleure pratique recommandée consiste à disposer de trois réseaux virtuels :

  • VLAN Internet en dehors
  • VLAN de gestion
  • VLAN à l’intérieur du serveur

Citrix recommande de configurer le réseau pour que le port LOM fasse partie du VLAN de gestion.

Lors du déploiement d’une appliance Citrix ADC en mode deux bras, dédiez un port spécifique à un réseau spécifique. Si le balisage VLAN et la liaison de deux réseaux à un port sont requis, vous devez vous assurer que les deux réseaux ont des niveaux de sécurité identiques ou similaires.

Si les deux réseaux ont des niveaux de sécurité différents, le balisage VLAN ne doit pas être utilisé. Au lieu de cela, envisagez de consacrer un port à chaque réseau spécifique et d’utiliser des VLAN indépendants distribués sur les ports de l’appliance.

Envisager d’utiliser Citrix Web App Firewall : une appliance sous licence Citrix ADC Premium Edition fournit un pare-feu Citrix Web App Firewall intégré qui utilise un modèle de sécurité positif et apprend automatiquement le comportement approprié de l’application pour la protection contre les menaces telles que l’injection de commandes, l’injection SQL et les scripts inter-sites.

Lorsque vous utilisez Citrix Web App Firewall, les utilisateurs peuvent ajouter une sécurité supplémentaire à l’application Web sans modifier le code et avec peu de modifications de configuration. Pour plus d’informations, consultez la page Web Citrix ADC Citrix Web App Firewall.

Restreindre l’accès aux applications autres que de gestion : exécutez la commande suivante pour restreindre la capacité des applications non administratives à accéder à une appliance Citrix ADC.

set ns ip <NSIP> -restrictAccess enabled
<!--NeedCopy-->

Déploiement sécurisé de cluster : si les nœuds de cluster Citrix ADC sont distribués en dehors du centre de données, Citrix recommande fortement l’utilisation de RPC sécurisé pour NNM (Node to Node Messaging), AppNNM et la configuration de la haute disponibilité.

Pour activer la fonctionnalité Secure RPC pour toutes les adresses IP Citrix ADC dans un cluster Citrix ADC et une configuration haute disponibilité, exécutez la commande suivante :

set rpcnode <ip> -secure on
<!--NeedCopy-->

Remarque : Une autre configuration peut être requise. Pour plus d’informations, consultez les rubriques Clustering sur le site Citrix Docs.

Lors du déploiement dans un déploiement de cluster L3, les paquets entre les nœuds Citrix ADC sont échangés sur un tunnel GRE non chiffré qui utilise les adresses NSIP des nœuds source et de destination pour le routage. Lorsque l’échange se produit sur Internet, en l’absence d’un tunnel IPSec, les NSIP sont exposés sur Internet. Ceci n’est pas recommandé car il ne respecte pas les meilleures pratiques de sécurité pour Citrix ADC.

Citrix recommande fortement aux clients d’établir leur propre solution IPSec pour utiliser le cluster sur la fonctionnalité L3.

Si la fonction de transfert IP n’est pas utilisée, utilisez la commande suivante pour désactiver le mode L3 :

disable ns mode L3
<!--NeedCopy-->

Utilisez le protocole MEP sécurisé pour l’équilibrage de charge du serveur global (GSLB) : Pour chiffrer le MEP entre les appliances Citrix ADC pour GSLB, exécutez la commande suivante à partir du NSCLI :

set rpcNode <GSLB Site IP> -secure yes
<!--NeedCopy-->

Sécurisez le cookie de persistance d’équilibrage de charge :

Citrix recommande de chiffrer le cookie de persistance d’équilibrage de charge en plus du canal SSL/TLS. Pour plus d’informations sur la procédure à suivre, voir Persistance des cookie HTTP.

Paramètre Helloverifyrequest pour atténuer l’attaque d’amplification DDoS DTLS :

À partir de Citrix ADC version 12.1 build 62.x et 13.0 build 79.x, le paramètre helloverifyrequest est activé par défaut. L’activation du paramètre helloverifyrequest sur le profil DTLS permet d’atténuer le risque qu’un attaquant ou des bots submerge le débit réseau, entraînant potentiellement un épuisement de la bande passante sortante. C’est-à-dire qu’il aide à atténuer l’attaque d’amplification DDoS DTLS.

Pour afficher l’état du paramètre helloverifyrequest, à l’invite de l’interface de ligne de commande ADC, tapez ;

show dtlsProfile
<!--NeedCopy-->

Exemple :

Hello verify request status

Sécurisation du trafic pass-through sur l’appliance Citrix ADC à l’aide des paramètres du mode infrastructure

Les paramètres du mode d’infrastructure Citrix Web App Firewall peuvent être utilisés pour le trafic pass-through sécurisé sur l’appliance Citrix ADC. Ces paramètres du mode infrastructure offrent un niveau de sécurité de base sans interrompre les applications. La liste suivante récapitule les paramètres du mode d’infrastructure disponibles.

  • Protection de l’état de session
  • Protection de la fixation de session (activer HTTP uniquement)
  • HSTS (activer HTTP Strict Transport Security (HSTS))
  • Authentification forte
  • SSL de bout en bout préféré (TLS 1.2 et TLS 1.1)
  • Proxy HTTPS/Refuser tout autre trafic

Protection de l’état de session :

Recommandation : Activé Citrix ADC : Activé par défaut pour la plupart des entités

Le paramètre de protection de l’état de session est activé par défaut et ne nécessite aucune configuration spécifique. Lorsque l’appliance Citrix ADC est configurée pour assurer le proxy d’une connexion. Par exemple, lorsque flux sélectionne un serveur virtuel configuré ou un service de type TCP ou supérieur, l’appliance Citrix ADC crée une session avec état. L’appliance Citrix ADC continue de maintenir l’état de ces connexions et seuls les paquets qui tombent dans cette machine d’état sont traités. Les autres paquets sont supprimés ou réinitialisés.

Les entités de type de service suivantes atteignent ce comportement avec état sur une appliance Citrix ADC.

  • ADNS_TCP
  • DIAMETER, DNS_TCP
  • FTP-c
  • GRE-c
  • HTTP
  • MYSQL, MSSQL
  • NNTP
  • ORACLE
  • PUSH, PPTP
  • RTSP, RDP
  • SIP_SSL, SIP_TCP
  • SMPP
  • SSL, SSL_BRIDGE, SSL_DIAMETER, SSL_PUSH
  • SSL_TCP, SYSLOG_TCP
  • TCP
  • ADNS_TCP
  • RNAT (rnat_tcpproxy est ENABLED)

Protection de la fixation de session (en activant l’indicateur HttpOnly ou en ajoutant une stratégie de réécriture) :

Recommandation : Pour activer HttpOnly pour les cookies définis par l’appliance Citrix ADC ou le serveur principal
Citrix ADC : Activé par défaut pour les cookies insérés Citrix ADC, possible via Réécriture pour les cookies définis par le serveur principal.

HttpOnly : Lorsque vous balisez un cookie avec l’indicateur HttpOnly, il indique au navigateur que ce cookie doit être accessible uniquement par le serveur. Toute tentative d’accès au cookie à partir du script client est strictement interdite. Les cookies HttpOnly, s’ils sont correctement implémentés, rendent d’énormes classes d’attaques de script intersite courantes beaucoup plus difficiles à tirer.

Voici un exemple de cookie avec le drapeau HttpOnly défini :

Set-Cookie: ASP.NET_SessionId=ig2fac55; path=/; HttpOnly
<!--NeedCopy-->

Les cookies insérés par Citrix ADC pour la persistance d’Insertion de Cookie, par défaut, définissez l’indicateur HttpOnly pour indiquer que le cookie n’est pas scriptable et ne doit pas être révélé à l’application cliente. Par conséquent, le script côté client ne peut pas accéder au cookie et le client n’est pas sensible aux scripts intersites.

Pour activer le paramètre d’indicateur HttpOnly à l’aide de l’interface de ligne de commande :

À l’invite de commandes, tapez :

set lb parameter -HttpOnlyCookieFlag (ENABLED)  
<!--NeedCopy-->

Utilisation de la politique de réécriture pour insérer Secure et HttpOnly pour les cookies :

La stratégie de réécriture insère Secure et HTTP uniquement pour les cookies envoyés par le serveur principal.

Remarque : Les cookies sécurisés et HTTpOnly peuvent être faits ensemble pour les VIP SSL. Pour les VIP non SSL, on peut insérer l’indicateur HttpOnly.

Avec Citrix ADC, vous pouvez inclure uniquement les indicateurs HTTP et Secure pour les cookies définis par le serveur.

  • HttpOnly - Cette option sur un cookie entraîne les navigateurs Web à renvoyer le cookie en utilisant le protocole HTTP (ou HTTPS) uniquement ; les méthodes non-HTTP telles que JavaScript document.cookie références ne peuvent pas accéder au cookie. Cette option aide à prévenir le vol de cookies en raison des scripts intersites.
  • Sécurisé - Cette option sur un cookie entraîne les navigateurs Web à renvoyer uniquement la valeur du cookie lorsque la transmission est chiffrée par SSL. Cette option peut être utilisée pour empêcher le vol de cookies par écoute de connexion.

Pour créer une stratégie de réécriture à l’aide de l’interface de ligne de commande :

  1. Activez la fonction Réécriture, si elle n’est pas déjà activée.

    enable feature REWRITE
    <!--NeedCopy-->
    
  2. Créez une action de réécriture (cet exemple est configuré pour définir les indicateurs Secure et HttpOnly. Si l’un ou l’autre est manquant, modifiez-le si nécessaire pour d’autres combinaisons).

    add rewrite action <action name> replace_all http.RES.full_Header ""path=/; Secure; HttpOnly"" -search "regex(re!(path=/\\; Secure; HttpOnly)|(path=/\\; Secure)|(path=/\\; HttpOnly)|(path=/)!)" -bypassSafetyCheck YES
    <!--NeedCopy-->
    

    Exemple :

    add rewrite action act_cookie_Secure replace_all http.RES.full_Header ""path=/; Secure; HttpOnly"" -search "regex(re!(path=/\\; Secure; HttpOnly)|(path=/\\; Secure)|(path=/\\; HttpOnly)|(path=/)!)" -bypassSafetyCheck YES
    <!--NeedCopy-->
    
  3. Créez une stratégie de réécriture pour déclencher l’action.

    add rewrite policy <policy name> "http.RES.HEADER("Set-Cookie").EXISTS" <action name>
    <!--NeedCopy-->
    

    Exemple :

    add rewrite policy rw_force_secure_cookie "http.RES.HEADER("Set-Cookie").EXISTS" act_cookie_Secure
    <!--NeedCopy-->
    
  4. Liez la stratégie de réécriture au serveur virtuel à sécuriser (si l’option Secure est utilisée, un serveur virtuel SSL doit être utilisé).

    bind lb vserver <vserver name> - <policy name> -priority <priority number> -gotoPriorityExpression NEXT -type RESPONSE
    <!--NeedCopy-->
    

    Exemple :

    bind lb vserver mySSLVServer -policyName rw_force_secure_cookie -priority 100 -gotoPriorityExpression NEXT -type RESPONSE
    <!--NeedCopy-->
    

    Pour plus d’informations, consultez https://support.citrix.com/article/CTX138055.

HSTS (activer HTTP Strict Transport Security (HSTS)) :

Recommandation : Activé Citrix ADC : Dans le logiciel Citrix ADC version 12.0, ce paramètre peut être activé à l’aide de l’interface de ligne de commande. Dans les versions 11.1 et antérieures du logiciel Citrix ADC, ce paramètre peut être activé à l’aide de la stratégie de réécriture.

  • Dans la version 12.0 du logiciel Citrix ADC, les appliances Citrix ADC prennent en charge la sécurité de transport stricte HTTP (HSTS) en tant qu’option intégrée dans les profils SSL et les serveurs virtuels SSL.

Pour activer HSTS à l’aide de la ligne de commande Citrix ADC :

À l’invite de commandes, tapez :

add ssl vserver <vServerName> -HSTS ( ENABLED ) maxage <positive_integer> -IncludeSubdomains ( YES | NO)
<!--NeedCopy-->

OU

add ssl profile <name> -HSTS ( ENABLED ) -maxage <positive_integer> -IncludeSubdomains ( YES | NO )
<!--NeedCopy-->

Pour plus d’informations, voir Configurer la prise en charge de la sécurité stricte du transport HTTP (HSTS).

  • Dans les versions 11.1 et antérieures du logiciel Citrix ADC, la sécurité de transport stricte HTTP (HSTS) peut être activée en créant une stratégie de réécriture et en la liant globalement ou au serveur virtuel en question.

À l’invite de commandes, tapez les commandes suivantes :

add rewrite action <action name> insert_http_header Strict-Transport-Security ""max-age=157680000\”"

add rewrite policy <policy name> “true” <action name>

bind lb vserver <vserver name> - <policy name> -priority <priority number> END -type RESPONSE
<!--NeedCopy-->

Exemple :

add rewrite action insert_STS_header insert_http_header Strict-Transport-Security ""max-age=157680000\”"

add rewrite policy enforce_STS "true” insert_STS_header

bind lb vserver vs1 -policyName enforce_STS -priority 100 -gotoPriorityExpression END -type RESPONSE
<!--NeedCopy-->

Pour plus d’informations, consultez les rubriques suivantes :

https://support.citrix.com/article/CTX205221

https://www.citrix.com/blogs/2010/09/10/strict-transport-security-sts-or-hsts-with-citrix-netscaler-and-access-gateway-enterprise/

Authentification forte :

L’authentification forte (ou authentification multifacteur — MFA) doit être activée pour tous les accès aux données sensibles, aux applications et à l’administration.

Pour plus d’informations sur la façon dont les applications sensibles peuvent être configurées pour l’authentification multifactorielle, voir Authentification multi-facteurs (nFactor).

SSL de bout en bout préféré (TLS 1.2 et TLS 1.1) :

Il est recommandé d’avoir SSL à la fois sur le front end et le backend. SSLv3 et TLS v1.0 peuvent être désactivés sur les entités SSL car des vulnérabilités de sécurité ont été signalées. TLS 1.1 et TLS 1.2 ne peuvent être activés que. Si possible, n’avez que la version TLS 1.2 sur le client faisant face à des VIP. Cela peut être fait au niveau de l’entité SSL ou au niveau du profil et toutes les entités SSL héritent des paramètres SSL du profil.

Pour désactiver les entités SSL à l’aide de l’interface de ligne de commande :

À l’invite de commandes, tapez :

set ssl vserver <vServerName> -ssl2 DISABLED   -ssl3  DISABLED   -tls1   DISABLED

set ssl service <vServiceName> -ssl2 DISABLED   -ssl3  DISABLED   -tls1   DISABLED
<!--NeedCopy-->

Suites de chiffrement recommandées Citrix ADC :

Les chiffrements suivants pris en charge par Citrix ADC n’incluent aucun composant dans la liste « élimination obligatoire ». Ces chiffrements sont organisés par échange de clés (RSA, DHE et ECDHE) puis en plaçant les plus performants en haut et les plus sécuritaires en bas :

Recommander les suites de chiffrement RSA Key Exchange :

  • TLS1-AES-128-CBC-SHA
  • TLS1-AES-256-CBC-SHA
  • TLS1.2-AES-128-SHA256
  • TLS1.2-AES-256-SHA256
  • TLS1.2-AES128-GCM-SHA256
  • TLS1.2-AES256-GCM-SHA384

Recommander les suites de chiffrement d’échange de clés DHE :

  • TLS1-DHE-RSA-AES-128-CBC-SHA
  • TLS1-DHE-RSA-AES-256-CBC-SHA
  • TLS1.2-DHE-RSA-AES-128-SHA256
  • TLS1.2-DHE-RSA-AES-256-SHA256
  • TLS1.2-DHE-RSA-AES128-GCM-SHA256
  • TLS1.2-DHE-RSA-AES256-GCM-SHA384

Recommander ECDHE Clé Exchange Cipher suites :

  • TLS1-ECDHE-RSA-AES128-SHA
  • TLS1-ECDHE-RSA-AES256-SHA
  • TLS1.2-ECDHE-RSA-AES-128-SHA256
  • TLS1.2-ECDHE-RSA-AES-256-SHA384
  • TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
  • TLS1.2-ECDHE-RSA-AES256-GCM-SHA384

Recommander les suites Cipher dans l’ordre de préférence :

La liste suivante de chiffrements inclut les échanges de clés RSA, DHE et ECDHE. Elle offre le meilleur compromis entre la sécurité, les performances et la compatibilité.

  1. TLS1.2-AES128-GCM-SHA256
  2. TLS1.2-AES-128-SHA256
  3. TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
  4. TLS1.2-ECDHE-RSA-AES-128-SHA256
  5. TLS1-ECDHE-RSA-AES128-SHA
  6. TLS1.2-DHE-RSA-AES128-GCM-SHA256
  7. TLS1.2-DHE-RSA-AES-128-SHA256
  8. TLS1-DHE-RSA-AES-128-CBC-SHA
  9. TLS1-AES-128-CBC-SHA

Proxy HTTPS/refuser tout autre trafic :

Dans la mesure du possible, disposez de VIP SSL pour un meilleur chiffrement des données, en utilisant des versions SSL sécurisées (TLSv1.1 et TLSv1.2) et des chiffrements sécurisés. Le débit SSL TPS et SSL doivent être pris en compte tout en activant SSL pour les VIP et les services SSL back-end.

Administration et gestion

Cette section fournit des exemples de modifications de configuration spécifiques qui peuvent être appliquées pour augmenter la sécurité des appliances Citrix ADC et Citrix ADC SDX. Vous trouverez plus d’informations sur les meilleures pratiques de configuration de Citrix ADC dans l’article Paramètres recommandés et meilleures pratiques pour une implémentation générique d’une appliance Citrix ADC.

Comptes système et utilisateurs

Modifier le mot de passe du compte de super-utilisateur : vous ne pouvez pas supprimer le superutilisateur administrateur intégré (nsroot). Par conséquent, modifiez le mot de passe par défaut pour ce compte en un mot de passe sécurisé. Pour modifier le mot de passe par défaut de l’utilisateur admin, effectuez les opérations suivantes :

  1. Ouvrez une session en tant que superutilisateur et ouvrez l’utilitaire de configuration.
  2. Dans le volet de navigation, développez le nœud Systèmes.
  3. Sélectionnez le nœud Utilisateurs.
  4. Dans la page Utilisateurs système, sélectionnez l’utilisateur nsroot.
  5. Sélectionnez Modifier le mot de passe.
  6. Entrez le mot de passe requis dans les champs Mot de passe et Confirmer le mot de passe
  7. Cliquez sur OK.

Créer un compte de superutilisateur alternatif : Pour créer un compte de superutilisateur, exécutez les commandes suivantes :

add system user <newuser> <password>

bind system user <newuser> superuser 0
<!--NeedCopy-->

Utilisez ce compte de superutilisateur au lieu du compte de superutilisateur nsroot par défaut.

Pour les déploiements Citrix ADC SDX, un administrateur doit modifier les informations d’identification par défaut de l’appliance Citrix ADC SDX et de sa console de gestion GUI après la configuration initiale. Pour modifier le mot de passe de l’utilisateur par défaut, effectuez les opérations suivantes :

  1. Ouvrez une session en tant que superutilisateur et ouvrez l’utilitaire de configuration.
  2. Dans le volet de navigation, développez le nœud Systèmes.
  3. Sélectionnez le nœud Utilisateurs.
  4. Dans la page Utilisateurs système, sélectionnez l’utilisateur par défaut.
  5. Sélectionnez Modifier.
  6. Entrez le mot de passe requis dans les champs Mot de passe et Confirmer le mot de passe
  7. Cliquez sur OK.

Remarque : à partir de Citrix ADC version 11.0 et ultérieure, les utilisateurs et administrateurs locaux doivent choisir des mots de passe forts. Voici des exemples d’exigences relatives à la complexité des mots de passe :

  • Le mot de passe doit avoir une longueur minimale de huit caractères.
  • Le mot de passe ne doit pas contenir de mots de dictionnaire ou une combinaison de mots de dictionnaire.
  • Le mot de passe doit comprendre au moins une lettre majuscule, une lettre minuscule, un chiffre et un caractère spécial.

Les mots de passe forts peuvent être appliqués en définissant deux paramètres, l’un pour la longueur minimale des mots de passe et l’autre pour imposer la complexité des mots de passe :

set system parameter -localAuth ( ENABLED | DISABLED ) -minpasswordlen <positive_integer> -natPcbForceFlushLimit <positive_integer> -natPcbRstOnTimeout ( ENABLED | DISABLED )
-strongpassword ( ENABLED | DISABLED ) -promptString <string> -rbaOnResponse ( ENABLED | DISABLED ) -timeout <secs>
<!--NeedCopy-->

Dans les déploiements où plusieurs administrateurs sont requis, envisagez d’utiliser une méthode d’authentification externe pour authentifier les utilisateurs, par exemple RADIUS, TACACS+ ou LDAP (S).

Verrouiller le compte d’utilisateur système pour l’accès à la gestion : l’appliance Citrix ADC vous permet de verrouiller un utilisateur système pendant 24 heures et de refuser l’accès à l’utilisateur. L’appliance Citrix ADC prend en charge la configuration pour les utilisateurs système et externes. À l’invite de commandes, tapez :

set aaa parameter –persistentLoginAttempts DISABLED

Maintenant, pour verrouiller un compte d’utilisateur, à l’invite de commandes, tapez :

lock aaa user test

Pour plus d’informations sur la configuration de cette fonctionnalité à l’aide de l’interface graphique, voir Gestion des comptes utilisateur et des mots de passe.

Déverrouiller un compte d’utilisateur système verrouillé pour l’accès à la gestion : les utilisateurs système et les utilisateurs externes peuvent être verrouillés pendant 24 heures à l’aide de la commande Verrouillage authentification, autorisation et audit utilisateur. L’appliance Citrix ADC vous permet de déverrouiller l’utilisateur système verrouillé. À l’invite de commandes, tapez :

unlock aaa user test Pour plus d’informations sur la configuration de cette fonctionnalité à l’aide de l’interface graphique, voir Gestion des comptes utilisateur et des mots de passe.

Désactiver l’accès de gestion pour le compte d’utilisateur système : Lorsque l’authentification externe est configurée sur l’appliance et qu’en tant qu’administrateur, vous préférez refuser l’accès aux utilisateurs système pour ouvrir une session à l’accès de gestion, vous devez désactiver l’option LocalAuth dans le paramètre système.

Remarque : Le serveur externe doit être configuré.

À l’invite de commandes, tapez ce qui suit :

set system parameter localAuth <ENABLED|DISABLED>

Exemple :

set system parameter localAuth DISABLED Pour plus d’informations sur la configuration de cette fonctionnalité à l’aide de l’interface graphique, voir Gestion des comptes utilisateur et des mots de passe.

Forcer la modification du mot de passe pour les utilisateurs administratifs : pour une authentification nsroot sécurisée, l’appliance Citrix ADC invite l’utilisateur à changer le mot de passe par défaut en un nouveau si l’ forcePasswordChange option est activée dans le paramètre système. Vous pouvez modifier votre nsroot mot de passe à partir de la CLI ou de l’interface graphique, lors de votre première connexion avec les informations d’identification par défaut. À l’invite de commandes, tapez :

set system parameter -forcePasswordChange ( ENABLED | DISABLED )

Pour savoir comment configurer cette fonctionnalité, voir Gestion des comptes utilisateur et des mots de passe.

Accédez au Citrix ADC à l’aide de clés SSH et sans mot de passe : dans les déploiements où il est nécessaire d’administrer de nombreuses appliances Citrix ADC, envisagez d’utiliser les clés SSH et Aucun mot de passe. Pour plus d’informations sur la configuration de cette fonctionnalité, consultez Accès à une appliance Citrix ADC à l’aide de clés SSH et sans mot de passe.

Création de la clé principale système pour la protection des données : à partir de la version Citrix ADC 11.0, il est nécessaire de créer une clé principale du système pour protéger certains paramètres de sécurité, tels que les mots de passe des comptes de service requis pour l’authentification LDAP et l’authentification, l’autorisation et l’audit stockés localement Comptes d’utilisateurs. Pour créer la clé principale du système :

  1. À l’aide de l’interface de ligne de commande, connectez-vous en tant qu’administrateur système.
  2. Entrez la commande suivante :
create kek <passphrase>
<!--NeedCopy-->

Remarque :

  • Une fois la commande create system kek exécutée, KEK est utilisé pour la plupart des chiffrements de mot de passe (les mots de passe des utilisateurs locaux ne sont pas chiffrés avec KEK).
  • Vous ne devez pas supprimer le fichier KEK. Si vous disposez d’un accès shell et que vous supprimez les fichiers de fragment de clé par erreur, cela peut entraîner une perte de configuration, un échec de synchronisation, un échec de connexion. Voici quelques-uns des points à noter :

    • Utilisez toujours un ancien fichier de configuration correspondant à la version en cours d’installation lors de la rétrogradation ; sinon l’ouverture de session, la configuration source, la synchronisation et le basculement peuvent échouer.
    • Si l’un des fichiers de fragment de clé est perdu ou endommagé, le chiffrement ou le déchiffrement des données sensibles entraîne une défaillance qui peut à son tour entraîner une perte de configuration, un échec de synchronisation, un échec de connexion.
  • La phrase de passe doit comporter au moins 8 caractères.

Utiliser les listes de contrôle d’accès :

Par défaut, tous les protocoles et ports, y compris l’interface graphique et SSH, sont accessibles sur une appliance Citrix ADC. Les listes de contrôle d’accès (ACL) peuvent vous aider à gérer l’appliance en toute sécurité en autorisant uniquement les utilisateurs explicitement spécifiés à accéder aux ports et aux protocoles.

Recommandations pour contrôler l’accès à l’appliance :

  • Envisagez d’utiliser Citrix Gateway pour limiter l’accès à l’appliance à l’interface graphique uniquement. Pour les administrateurs qui ont besoin de méthodes d’accès en plus de l’interface graphique, Citrix Gateway doit être configuré avec une liste ACL « REFUSER » par défaut pour les ports 80, 443 et 3010, mais avec un « AUTORISER » explicite pour que les adresses IP de confiance puissent accéder à ces ports.

Cette stratégie peut être étendue pour être utilisée avec une plage d’adresses IP approuvées avec la commande NSCLI suivante :

add acl local_access allow -srcip 192.168.0.1-192.168.0.3 -destip 192.168.0.1-192.168.0.3

apply acls
<!--NeedCopy-->
  • Si vous utilisez SNMP, autorisez explicitement le trafic SNMP avec ACL. Exemples de commandes :
add acl snmp1-ssh ALLOW -srcip 10.0.0.1-10.0.0.20 -destip 192.168.0.2-192.168.0.3 -destport 161 -protocol udp

add acl snmp2-ssh ALLOW -srcip 172.16.0.1-172.16.0.20 -destip 192.168.0.2-192.168.0.3 –destport 161 -protocol udp

apply acls
<!--NeedCopy-->

Dans l’exemple précédent, la commande permet d’accéder à toutes les requêtes SNMP aux deux sous-réseaux définis, même si les requêtes concernent la communauté correctement définie.

Vous pouvez activer les fonctions de gestion sur les adresses NSIP, SNIP et MIP. Si cette option est activée, fournissez l’accès aux adresses NSIP, SNIP, avec ACL pour protéger l’accès aux fonctions de gestion. L’administrateur peut également configurer l’appliance de telle sorte qu’elle ne soit pas accessible à l’aide de la commande ping.

  • Open Shortest Path First (OSPF) et IPSEC ne sont pas un protocole basé sur TCP ou UDP. Par conséquent, si vous avez besoin de l’appliance pour prendre en charge ces protocoles, autorisez explicitement le trafic utilisant ces protocoles à l’aide d’une liste ACL. Exécutez la commande suivante pour définir une ACL pour spécifier OSPF et IPSEC par numéros de protocole :
add acl allow_ospf allow -protocolnumber 89

add acl allow_ipsec allow –protocolnumber 50
<!--NeedCopy-->
  • Si un service Web XML-API est utilisé, effectuez les tâches suivantes pour sécuriser l’interface API :
  • Fournissez l’autorisation à l’hôte d’accéder à l’interface à l’aide d’une liste ACL. Par exemple, exécutez les commandes suivantes pour permettre aux hôtes des plages d’adresses IP 10.0.0.1-20 et 172.16.0.1-20 d’accéder à l’interface XML-API :
add acl xml-api1 ALLOW -srcip 10.0.0.1-10.0.0.20 -destip 192.168.0.2-192.168.0.3 -destport 80 -protocol tcp

add acl xml-api2 ALLOW -srcip 172.16.0.1-172.16.0.20 -destip 192.168.0.2-192.168.0.3 -destport 80 -protocol tcp

apply acls
<!--NeedCopy-->
  • Pour appliquer les listes d’accès aux ports internes, utilisez la commande suivante :
set l3param -implicitACLAllow DISABLED
<!--NeedCopy-->

Remarque : La valeur par défaut de la commande Implicitaclallow est ENABLED.

  • Pour supprimer les ACL des ports internes, utilisez la commande suivante :
set l3param -implicitACLAllow ENABLED
<!--NeedCopy-->
  • Spécifiez le transport sécurisé pour le service Web XML-API en configurant un serveur frontal HTTPS sur l’appliance avec une stratégie de répondeur appropriée. Cela s’applique à l’appliance exécutant le logiciel Citrix ADC version 8.0 ou ultérieure. Exemples de commandes :
enable ns feature responder

add responder policy allow_soap 'HTTP.REQ.URL.STARTSWITH("/soap").NOT' RESET

add lb vserver xml-https ssl 192.168.0.4 443

add server localhost 127.0.0.1

add service xml-service localhost HTTP 80

bind lb vserver xml-https xml-service

bind lb vserver xml-https -policyName allow_soap -type REQUEST -priority 1

add ssl certkey xml-certificate -cert testcert.cert -key testcert.key

bind ssl certkey xml-https xml-certificate
<!--NeedCopy-->

Utiliser le contrôle d’accès basé sur les rôles pour les utilisateurs administratifs :

L’appliance Citrix ADC comprend quatre stratégies de commande ou rôles tels que opérateur, lecture seule, réseau et superutilisateur. Vous pouvez également définir des stratégies de commande, créer des comptes d’administration différents pour différents rôles et affecter les stratégies de commande nécessaires au rôle aux comptes. Voici un ensemble d’exemples de commandes visant à restreindre l’accès en lecture seule à l’utilisateur en lecture seule :

add system user readonlyuser

bind system user readonlyuser read-only 0
<!--NeedCopy-->

Pour plus d’informations sur la configuration des utilisateurs, des groupes d’utilisateurs ou des stratégies de commande, consultez les documents Citrix :

Configurer le délai d’expiration de la session système :

Un intervalle de temporisation de session est fourni pour limiter la durée pendant laquelle une session (GUI, CLI ou API) reste active lorsqu’elle n’est pas utilisée. Pour l’appliance Citrix ADC, le délai d’expiration de la session système peut être configuré aux niveaux suivants :

  • Délai d’expiration au niveau utilisateur. Applicable à l’utilisateur spécifique.

GUI : accédez à Système > Administration des utilisateurs > Utilisateurs, sélectionnez un utilisateur et modifiez le paramètre de délai d’expiration de l’utilisateur. CLI : À l’invite de commandes, entrez la commande suivante :

set system user <name> -timeout <secs>
<!--NeedCopy-->
  • Délai d’expiration de niveau groupe d’utilisateurs. Applicable à tous les utilisateurs du groupe.

GUI : accédez à Système > Administration des utilisateurs > Groupes, sélectionnez un groupe et modifiez le paramètre de délai d’expiration du groupe. CLI : À l’invite de commandes, entrez la commande suivante :

set system group <groupName> -timeout <secs>
<!--NeedCopy-->
  • Délai d’expiration du système global. Applicable à tous les utilisateurs et utilisateurs de groupes qui n’ont pas de délai d’expiration configuré.

GUI : accédez à Système > Paramètres, cliquez sur Définir les paramètres système globaux, puis définissez le paramètre ANY Client Idle Time-out (secs). CLI : À l’invite de commandes, entrez la commande suivante :

set system parameter -timeout <secs>
<!--NeedCopy-->

La valeur de délai d’attente spécifiée pour un utilisateur a la priorité la plus élevée. Si le délai d’expiration n’est pas configuré pour l’utilisateur, le délai d’expiration configuré pour un groupe de membres est pris en compte. Si le délai d’expiration n’est pas spécifié pour un groupe (ou si l’utilisateur n’appartient pas à un groupe), la valeur de délai d’expiration configurée globalement est prise en compte. Si le délai d’expiration n’est configuré à aucun niveau, la valeur par défaut de 900 secondes est définie comme délai d’expiration de la session système.

Vous pouvez également restreindre la valeur du délai d’expiration afin que la valeur de délai d’expiration de session ne puisse pas être configurée au-delà de la valeur de délai d’expiration configurée par l’administrateur. Vous pouvez limiter la valeur du délai d’attente entre 5 minutes et 1 jour. Pour restreindre la valeur du délai d’attente :

  • GUI : accédez à Système > Paramètres, cliquez sur Définir les paramètres système globaux, puis sélectionnez le champ Délai d’attente restreint.
  • CLI : À l’invite de commandes, entrez la commande suivante :
set system parameter -restrictedtimeout <ENABLED/DISABLED>
<!--NeedCopy-->

Une fois que l’utilisateur a activé le paramètre RestrictedTimeout et si la valeur du délai d’expiration est déjà configurée sur une valeur supérieure à 1 jour ou inférieure à 5 minutes, l’utilisateur sera averti de modifier la valeur du délai d’expiration. Si l’utilisateur ne modifie pas la valeur du délai d’attente, par défaut, la valeur du délai d’attente sera reconfigurée à 900 secondes (15 minutes) lors du prochain redémarrage.

Vous pouvez également spécifier des durées d’expiration pour chacune des interfaces à laquelle vous accédez. Toutefois, la valeur de délai d’expiration spécifiée pour une interface spécifique est limitée à la valeur de délai d’expiration configurée pour l’utilisateur qui accède à l’interface. Par exemple, considérez qu’un utilisateur publicadmin a une valeur de délai d’attente de 20 minutes. Désormais, lors de l’accès à une interface, l’utilisateur doit spécifier une valeur de délai d’attente de 20 minutes.

Pour configurer la durée du délai d’expiration à chaque interface :

  • CLI : spécifiez la valeur de délai d’expiration sur l’invite de commande à l’aide de la commande suivante :
set cli mode -timeout <secs>
<!--NeedCopy-->
  • API : spécifiez la valeur de délai d’attente dans la charge utile de connexion.

Journalisation et surveillance

Configurer le protocole de temps réseau

Citrix recommande que le protocole NTP (Network Time Protocol) soit activé sur l’appliance et configuré pour utiliser un serveur de temps réseau approuvé. L’activation de NTP garantit que les heures enregistrées pour les entrées de journal et les événements système sont exacts et synchronisés avec d’autres ressources réseau.

Lors de la configuration de NTP, le fichier ntp.conf doit être modifié pour empêcher le serveur NTP de divulguer les informations dans des paquets sensibles.

Vous pouvez exécuter les commandes suivantes pour configurer NTP sur l’appliance :

add ntp server <IP_address> 10

enable ntp sync
<!--NeedCopy-->

Modifiez le fichier ntp.conf pour chaque serveur NTP approuvé que vous ajoutez. Il doit y avoir une entrée de restriction correspondante pour chaque entrée de serveur. Vous pouvez localiser le fichier ntp.conf en exécutant la commande find . –name ntp.conf à partir de l’invite de commandes de l’appliance.

Configurer SNMP

L’appliance Citrix ADC prend en charge la version 3 du protocole SNMP. SNMPv3 intègre des fonctions d’administration et de sécurité telles que l’authentification, le contrôle d’accès et les contrôles d’intégrité des données. Pour plus d’informations, reportez-vous à System > Rubriques SNMP sur Citrix Docs.

Si vous ne configurez pas au moins un gestionnaire SNMP, l’appliance accepte et répond aux requêtes SNMP provenant de toutes les adresses IP du réseau. Exécutez la commande suivante pour ajouter un gestionnaire SNMP et restreindre ce comportement :

add snmp manager <IP_address>
<!--NeedCopy-->

Dans les déploiements où SNMP n’est pas requis, la fonctionnalité doit être désactivée à l’aide de la commande suivante :

set ns ip <IP_Address> -snmp disabled
<!--NeedCopy-->

Configurer la journalisation sur l’hôte de journal Citrix ADC externe

Citrix ADC Audit Server enregistre tous les états et informations d’état collectées par différents modules dans le noyau et dans les démons de niveau utilisateur. Le serveur d’audit permet à un administrateur de voir l’historique des événements dans un ordre chronologique. Le serveur d’audit est similaire au serveur SYSLOG qui collecte les journaux de l’appliance. Audit Server utilise les informations d’identification de l’administrateur pour récupérer les journaux d’une ou de plusieurs appliances.

  • Configuration du serveur d’audit local

Exécutez la commande suivante pour configurer la journalisation sur le serveur d’audit local dans l’appliance Citrix ADC : > set audit nslogparams –serverip <hostname> -serverport <port>

  • Configuration du serveur d’audit à distance

Pour configurer la journalisation sur le serveur d’audit sur un ordinateur distant, installez Audit Server sur cet ordinateur. Voici des exemples d’options du serveur d’audit :

./audserver -help
usage : audserver -[cmds] [cmd arguments]
cmds cmd arguments: -f <filename> -d debug
-help - detail help
-start - cmd arguements,[starts audit server]
-stop - stop audit server
-verify - cmd arguments [verifies config file]
-addns - cmd arguments [add a netscaler to conf file]
-version - prints the version info
<!--NeedCopy-->

Cela permet de consigner uniquement les messages d’audit générés par le fichier ns.log de la solution matérielle-logicielle. Pour consigner tous les messages syslog, effectuez les opérations suivantes :

  1. Supprimez les spécifications du fichier journal du fichier /nsconfig/syslog.conf pour les installations locales.
  2. Remplacez les spécifications du fichier journal par le nom d’hôte du journal ou l’adresse IP de l’hôte syslog distant, similaire aux entrées suivantes :

    local0.* @10.100.3.53

    local1.* @10.100.3.53

  3. Configurez le serveur syslog pour qu’il accepte les entrées de journal des installations de journalisation précédentes. Pour plus d’informations, consultez la documentation du serveur syslog.
  4. Pour la plupart des serveurs UNIX utilisant le logiciel syslog standard, vous devez ajouter une entrée de configuration locale pour les messages et les fichiers nsvpn.log au fichier de configuration syslog.conf. Les valeurs de ressource doivent correspondre aux valeurs configurées sur l’appliance.
  5. Par défaut, le serveur syslog distant dans n’importe quel ordinateur UNIX n’écoute pas les journaux distants. Par conséquent, exécutez la commande suivante pour démarrer le serveur syslog distant :
syslogd -m 0 –r
<!--NeedCopy-->

Remarque : Consultez les options équivalentes de la variante Syslog déployée sur le serveur d’audit.

Configuration LOM

Citrix recommande vivement que les mesures suivantes soient prises pour sécuriser l’interface LOM :

  • N’exposez pas le port LOM à Internet.
  • Déployez le LOM derrière un pare-feu SPI.
  • Déployez le LOM sur un segment de réseau séparé logiquement (VLAN séparé) ou physiquement (LAN séparé) d’un trafic réseau non fiable.
  • Définissez différents noms d’utilisateur, mot de passe, certificat SSL et valeurs de clé SSL pour les ports de gestion LOM et Citrix ADC.
  • Assurez-vous que les périphériques utilisés pour accéder à l’interface de gestion LOM sont exclusivement dédiés à une fonction de gestion réseau et placés sur un segment de réseau de gestion qui se trouve dans le même réseau local physique ou VLAN que les autres ports de périphérique de gestion.
  • Pour identifier et isoler facilement les adresses IP LOM, réservez des adresses IP spéciales (sous-réseaux privés) pour les interfaces de gestion LOM et les serveurs de gestion. N’utilisez pas de sous-réseaux IP réservés avec les interfaces LAN des appliances gérées. Les adresses IP dynamiques attribuées par DHCP ne sont pas recommandées, car elles rendent difficile la mise en œuvre des listes de contrôle d’accès du pare-feu basées sur une adresse MAC en dehors du segment LAN.
  • Définissez le mot de passe pour un minimum de 8 caractères, avec une combinaison de caractères alphanumériques et spéciaux. Changez fréquemment le mot de passe.

Applications et services

Configurer Citrix ADC pour supprimer les requêtes HTTP non valides

Citrix recommande fortement que l’appliance Citrix ADC soit configurée avec une vérification et une application strictes des requêtes HTTP afin d’empêcher les demandes HTTP non valides de passer par des serveurs virtuels. Cela peut être fait en liant un profil HTTP intégré, nshttp_default_strict_validation, à un ou plusieurs serveurs virtuels à l’aide de la commande suivante sur l’interface de ligne de commande :

show ns httpProfile (Shows the available http profile (default+user configured profiles))

set lb vserver <vserver name> -httpProfileName nshttp_default_strict_validation
<!--NeedCopy-->

Citrix recommande aux clients utilisant cette option de tester les modifications dans un environnement intermédiaire avant de le lancer en production.

La protection contre les attaques de désynchronisation HTTP est activée par défaut sur le profil de validation HTTP strict (nshttp_default_strict_validation). Utilisez le profil strict pour toutes les entités face au client.

Pour plus d’informations sur les attaques de contrebande de requêtes HTTP et leur atténuation, consultez l’article de support Citrix ADC - HTTP Request Smuggling Reference Guide.

Configurer la protection contre les attaques par déni de service HTTP

Le microprogramme de l’appliance Citrix ADC prend en charge des contre-mesures limitées contre les attaques par déni de service HTTP, y compris les attaques de type « lecture lente ». Vous pouvez configurer ces fonctionnalités à l’aide de l’utilitaire nsapimgr à partir de l’invite shell de l’appliance :

  • small_window_threshold (par défaut = 1)
  • small_window_idle_timeout (par défaut = 7 s)
  • small_window_cleanthresh (par défaut = 100)
  • small_window_protection (default=Enabled)

Les paramètres par défaut sont adéquats pour empêcher les attaques par déni de service HTTP, y compris les attaques à lecture lente. Toutefois, un certain réglage des paramètres peut être nécessaire pour d’autres attaques.

Pour vous protéger contre de telles attaques, ajustez la propriété small_window_threshold vers le haut à l’aide de la commande nsapimgr suivante à partir de l’invite de commandes de l’appliance :

$ nsapimgr –ys small_window_threshold=<desired value>

Remarque : La valeur souhaitée small_window_threshold peut être définie en fonction du modèle de trafic entrant dans le déploiement. La plage acceptable est de 0 à 2^32.

Vous pouvez vérifier la protection contre les attaques par déni de service HTTP en surveillant les compteurs suivants à l’aide de la commande nsconmsg –d stats à partir de l’invite du shell de l’appliance :

  • nstcp_cur_zero_win_pcbs : Ce compteur suit le nombre de PCB dont la valeur Window est faible.
  • nstcp_err_conndrop_at_pass : Ce compteur est incrémenté lorsque l’appliance détecte que, lors du passage de paquets d’un côté à l’autre, il a dépassé la valeur nscfg_small_window_idletimeout.
  • nstcp_err_conndrop_at_retx : Ce compteur est incrémenté lorsque le temps qui s’écoule pendant la retransmission dépasse la valeur nscfg_small_window_idletimeout.
  • nstcp_cur_pcbs_probed_withKA: ce compteur suit le nombre de circuits imprimés dans la file d’attente de surtension qui sont sondés avec une sonde KA.

Citrix recommande aux clients utilisant cette option de tester les modifications dans un environnement intermédiaire avant de le lancer en production.

Configurer Citrix ADC pour se défendre contre les attaques d’usurpation TCP

Les commandes suivantes peuvent être utilisées pour protéger les serveurs back-end contre les attaques d’usurpation TCP :

set ns tcpProfile profile1 -rstWindowAttenuate ENABLED -spoofSynDrop ENABLED

Done

set lb vserver lbvserver1 -tcpProfileName profile1

Done
<!--NeedCopy-->

Citrix recommande aux clients utilisant cette option de tester les modifications dans un environnement intermédiaire avant de le lancer en production.

Configurer Citrix ADC pour accepter des en-têtes HTTP spécifiques

Il est possible de configurer l’appliance Citrix ADC pour qu’elle n’accepte que des en-têtes HTTP spécifiques. Cela peut être réalisé en ajoutant une action de réécriture pour empêcher le trafic réseau avec des en-têtes HTTP spécifiques et définis d’être transmis au serveur principal.

L’action globale de réécriture suivante envoie uniquement le trafic réseau avec des en-têtes tels que Host, Accepter et test au serveur :

add rewrite action act1 replace_all q/HTTP.REQ.FULL_HEADER.after_str("\r\n")/     q{TARGET.REGEX_SELECT(re/(iu)^(Host|Accept|test):.*\r\n/) ALT ""} -pattern q{re/(U).+:.+r\n/}

add rewrite policy pol1 HTTP.REQ.IS_VALID act1

bind rewrite global pol1 100
<!--NeedCopy-->

Remarque : Ces commandes ne sont prises en charge que dans Citrix ADC version 10.5 et versions ultérieures.

Configuration de close-notification

Une notification de fermeture est un message sécurisé qui indique la fin de la transmission de données SSL. Conformément à la RFC 5246 : Le client et le serveur doivent partager la connaissance de la fin de la connexion pour éviter une attaque de troncature. Chaque partie peut initier l’échange de messages de clôture. Chaque partie peut lancer une fermeture en envoyant une alerte close_notify. Toutes les données reçues après une alerte de fermeture sont ignorées, sauf si une autre alerte fatale a été transmise, chaque partie doit envoyer une alerte close_notify avant de fermer le côté écriture de la connexion. Pour vous assurer que les événements d’audit sont capturés pour les événements de terminaison TLS, connectez-vous à l’interface de ligne de commande en tant que superutilisateur ou sysadmin et exécutez les commandes suivantes :

set ssl parameter -sendCloseNotify y

save ns config
<!--NeedCopy-->

Recommandations de sécurité DNSSEC

Citrix recommande que les recommandations suivantes soient appliquées aux clients utilisant DNSSEC :

Utilisez RSA 1024 bits ou plus pour les clés privées KSK/ZSK

Le NIST recommande aux administrateurs DNS de conserver les ZSKs RSA/SHA-1 ou RSA/SHA-256 à 1024 bits jusqu’au 1er octobre 2015.

Activer l’alarme SNMP pour l’expiration de clé DNSSEC

Par défaut, l’alarme SNMP pour l’expiration de clé DNSSEC est activée sur une appliance Citrix ADC. La notification d’expiration de la clé est envoyée via une interruption SNMP appelée DNSKeyExpiration. Trois variables MIB dnskeyName, et dnskeyUnitsOfExpiry, sont envoyées avec l’interruption SNMP dnskeyExpiry. Pour plus d’informations, consultez Citrix ADC SNMP OID Reference.

Rouler les clés privées KSK/ZSK avant l’expiration des certificats x.509

Sur une appliance Citrix ADC, vous pouvez utiliser les méthodes de pré-publication et de double signature pour effectuer un survol de la clé de signature de zone et de la clé de signature de clé. Pour plus d’informations, consultez la rubrique Système de noms de domaine > Configuration de DNSSEC sur Citrix Docs.

Serveur ADNS DNSSEC sécurisé

Si l’appliance est configurée en mode proxy DNSSEC, elle met en cache les réponses du serveur ADNS principal et transmet les réponses mises en cache aux clients DNS.

Lorsque l’appliance Citrix ADC fait autorité pour une zone donnée, tous les enregistrements de ressource de la zone sont configurés sur Citrix ADC. Pour signer la zone faisant autorité, vous devez créer les clés (la clé de signature de zone et la clé de signature de clé) pour la zone, ajouter les clés à ADC, puis signer la zone

Pour configurer Citrix ADC en tant que serveur faisant autorité, effectuez les opérations suivantes :

  1. Ajoutez un service ADNS.

    Par exemple :

    add service s1 <ip address> adns 53`
    <!--NeedCopy-->
    
  2. Créez des clés DNS.

    Par exemple, pour agir en tant que serveur faisant autorité pour le domaine com :

    create dns key -zoneName com -keytype ksK -algorithm rsASHA1 -keysize 3000 -fileNamePrefix com.ksk.rsasha1.3000
    
    create dns key -zoneName com -keytype zsk -algorithm rsASHA1 -keysize 3000 -fileNamePrefix com.zsk.rsasha1.3000
    <!--NeedCopy-->
    

    Remarque : Vous devez créer les clés DNS une fois et elles sont enregistrées dans /nsconfig/dns.

  3. Ajoutez des clés DNS.

    Par exemple,

    add dns key com.zsk.3000 /nsconfig/dns/com.zsk.rsasha1.3000.key /nsconfig/dns/com.zsk.rsasha1.3000.private
            add dns key com.ksk.3000 /nsconfig/dns/com.ksk.rsasha1.3000.key /nsconfig/dns/com.ksk.rsasha1.3000.private
    <!--NeedCopy-->
    
  4. Ajoutez des enregistrements NS et SOA pour la zone com, puis signez la zone.

    add dns soaRec com -originServer n1.com -contact citrix
    add dns nsrec com n1.com
    add dns zone com -proxyMode no
    add dns addRec n1.com 1.1.1.1

    sign dns zone com
<!--NeedCopy-->

Remarque : En outre, vous devez également activer le paramètre Extension DNSEC dans les paramètres globaux DNS.

Pour plus d’informations sur la configuration de Citrix ADC en tant que serveur de noms de domaine faisant autorité, consultez la rubrique Système de noms de domaine > Configuration du Citrix ADC en tant que serveur ADNS sur Citrix Docs.

Configuration héritée

Configurer Citrix ADC pour désactiver la redirection SSLv2

Si vous activez la fonctionnalité de redirection SSL v2 sur une appliance Citrix ADC, l’appliance effectue la liaison SSL et redirige le client vers l’URL configurée. Si cette fonctionnalité est désactivée, l’appliance refuse d’exécuter le processus de prise de contact SSL avec les clients SSL v2.

Exécutez la commande suivante pour désactiver la redirection SSLv2 :

set ssl vserver <vserver_name> -sslv2redirect DISABLED -cipherredirect DISABLED
<!--NeedCopy-->

Remarque : à partir de la version 9.2 du logiciel Citrix ADC, les fonctions de redirection SSLv2 et de redirection de chiffrement sont désactivées par défaut.

Configurer Citrix ADC version 10.0 et antérieure pour utiliser la renégociation SSL sécurisée

Pour configurer Citrix ADC afin d’empêcher la renégociation SSL non sécurisée pour le logiciel Citrix ADC version 9.3e ou 10.0, exécutez la commande suivante :

set ssl parameter -denySSLReneg NONSECURE
<!--NeedCopy-->

Pour les versions antérieures du logiciel Citrix ADC, exécutez la commande suivante pour désactiver la renégociation SSL :

set ssl parameter -denySSLReneg ALL
<!--NeedCopy-->

La commande suivante permet de renégocier uniquement les clients et les serveurs sécurisés :

set ssl parameter -denySSLReneg NONSECURE
<!--NeedCopy-->

Pour plus d’informations, consultez How to Configure and Use the -DenySSlReneg Parameter.”

Recommandations cryptographiques Citrix ADC

Cette section détaille certaines étapes clés à suivre pour garantir que le matériel cryptographique est correctement sécurisé sur l’appliance Citrix ADC. Il fournit également des informations sur la configuration des appliances pour qu’elles utilisent ce matériel pour protéger l’appliance elle-même, les serveurs back-end et les utilisateurs finaux.

Gestion des certificats et des clés TLS

Configuration de suites de chiffrement TLS pour les déploiements NDPP

Pour obtenir la liste des suites de chiffrement TLS prises en charge pour les déploiements NDPP, consultez https://www.citrix.com/content/dam/citrix/en_us/documents/downloads/netscaler-adc/Common-criteria-documents-for-NetScaler-10.5.zip

Pour vous assurer que seules les suites de chiffrement approuvées sont configurées sur l’appliance, effectuez les étapes de configuration suivantes à partir de l’interface de ligne de commande :

  1. Délier tous les chiffrements du serveur virtuel

    unbind ssl vs v1 –cipherName FIPS
    <!--NeedCopy-->
    
  2. Liez seulement TLS1-AES-256-CBC-SHA puis TLS1-AES-128-CBC-SHA avec la commande :

    bind ssl vs v1 –cipherName <cipher>
    
    bind ssl vs v1 -cipherName TLS1-AES-256-CBC-SHA
    <!--NeedCopy-->
    

Importation d’un certificat d’autorité de certification racine approuvé :

  1. À l’aide d’un utilitaire de transfert de fichiers sécurisé, tel que scp ou WinSCP, transférez le certificat émetteur du serveur (racine) dans le répertoire /nsconfig/ssl de l’appliance Citrix ADC.

    Remarque : vous devez vous authentifier en tant que super-utilisateur via SCP ou WinSCP pour terminer cette étape.

  2. Connectez-vous à l’appliance Citrix ADC en tant qu’administrateur système ou super-utilisateur et tapez la commande suivante :

add ssl certkey <Certificate_Name> –cert <Cert_File_Name>
<!--NeedCopy-->

Remarque : Installez uniquement les certificats d’autorité de certification racine provenant d’autorités de certification connues pour être fiables. Supprimez tous les autres certificats.

Importation d’un certificat PKCS #12 (.PFX) et d’un fichier clé :

Vous trouverez des informations détaillées sur la façon dont les fichiers de certificats et de clés peuvent être importés dans l’appliance Citrix ADC dans les rubriques Déchargement et accélération SSL > Importer des certificats et clés existants de la documentation produit Citrix.

  1. Transférez le fichier .pfx dans le répertoire /nsconfig/ssl, comme mentionné à l’étape 1 de la section précédente.

  2. S’authentifier auprès de l’appliance Citrix ADC via l’interface de ligne de commande en tant que sysadmin ou superutilisateur et exécutez la commande suivante :

    convert ssl pkcs12 Cert-Client-1.pfx -export -certFile Cert-Client-1 -keyFile Key-Client-1
    <!--NeedCopy-->
    
  3. Ajoutez le certificat à l’appliance Citrix ADC comme suit :

    add ssl certkey Clent-Cert-1 –cert Cert-Client-1
    <!--NeedCopy-->
    
  4. Enregistrez la configuration actuelle.

    save ns config
    <!--NeedCopy-->
    

Remarque : à partir de la version Citrix ADC 11.0, le fichier PKCS #12 (.PFX) est automatiquement converti en PEM et tous les certificats sont ajoutés et liés automatiquement à l’autorité de certification.

Installation de certificats et de paires de clés à l’aide d’une autorité de certification approuvée :

Pour obtenir un certificat auprès d’une autorité de certification publique ou d’entreprise, vous devez d’abord générer une demande de signature de clé privée et de certificat (CSR). Procédez comme suit :

  1. S’authentifier auprès de l’interface de ligne de commande Citrix ADC en tant que sysadmin ou superutilisateur.

  2. Créez une clé privée RSA.

    create fipsKey m1 -modulus 2048
    <!--NeedCopy-->
    
  3. Créez la demande de signature de certificat (CSR) :

    create certreq csr_1 -fipsKeyName m1 -countryName IN -stateName BA -organizationName citrix
    <!--NeedCopy-->
    
  4. Soumettre la CSR à l’autorité de certification.

Pour la plupart des autorités de certification commerciales et d’entreprise, la CSR est envoyée par courrier électronique. Toutefois, la méthode de soumission peut varier selon les environnements d’autorité de certification d’entreprise. L’autorité de certification renvoie un certificat valide par e-mail, mais cela peut également varier d’une autorité de certification d’entreprise à l’autre. Après avoir reçu le certificat de l’autorité de certification, copiez-le en toute sécurité dans le répertoire /nsconfig/ssl.

Connectez-vous en tant que superutilisateur ou sysadmin et exécutez la commande suivante à partir de l’interface de ligne de commande : > add ssl certKey ck_1 -cert cert1_1 -fipsKey m1

Recommandations Citrix ADC-FIPS

Configuration de Citrix ADC SDX dans un déploiement basé sur FIPS

Si vous êtes un client FIPS existant et que vous utilisez une appliance Citrix ADC SDX pour une réelle multilocation, utilisez l’appliance Citrix ADC MPX certifiée FIPS pour mettre fin à TLS et transférer le trafic vers l’appliance Citrix ADC SDX. Alternativement, il est possible d’utiliser un HSM externe Thales. Modifiez les mots de passe de la carte crypto FIPS lors de l’utilisation d’une version certifiée FIPS de Citrix ADC avec un module de sécurité matérielle (HSM), modifiez le responsable de la sécurité (SO) par défaut et définissez un nouveau mot de passe utilisateur comme suit. Si vous ne connaissez pas le mot de passe SO par défaut d’une appliance Citrix ADC compatible FIPS, contactez le support technique Citrix. Remarque : Seul un super utilisateur ou un sysadmin peut effectuer cette tâche.

set ssl fips -initHSM Level-2 <soPassword> <oldSoPassword> <user-Password> [-hsmLabel <string>]

save configuration

initHSM
<!--NeedCopy-->

Niveau d’initialisation FIPS. L’appliance prend actuellement en charge le niveau 2 (FIPS 140-2). Il s’agit d’un argument obligatoire. Valeurs possibles : Level-2

hsmLabel

Étiquette pour identifier le module de sécurité matérielle (HSM).

Longueur maximale : 31

Remarque : Toutes les données de la carte FIPS sont effacées avec la commande précédente.

Stockez le mot de passe HSM dans un emplacement sécurisé

Le mot de passe du HSM doit être stocké dans un emplacement sécurisé conformément aux procédures opérationnelles de votre entreprise.

Remarque : Le HSM est verrouillé après trois tentatives de connexion infructueuses. Lorsqu’il est verrouillé, il devient non opérationnel et vous ne pouvez pas modifier sa configuration.

Autres caractéristiques

Cette section fournit des exemples de modifications de configuration qui peuvent être appliquées à la fois au Citrix Web App Firewall et à Citrix Gateway pour améliorer la sécurité des appliances déployées et des informations sur la création de plusieurs niveaux ou de sécurité. Cette section contient également des informations sur les détails de configuration lors de l’utilisation de Citrix ADC ou de Citrix Gateway en tant que SP SAML ou SAML IdP ou les deux.

Recommandations de sécurité Citrix Web App Firewall

Déploiement de l’appliance en mode à deux bras

Avec une installation en mode à deux bras, l’appliance se trouve physiquement entre les utilisateurs et les serveurs Web que l’appliance protège. Les connexions doivent passer par l’appliance. Cet arrangement réduit les chances de trouver un itinéraire autour de l’appareil.

Utiliser une stratégie « Refuser par défaut »

Citrix recommande aux administrateurs de configurer Citrix Web App Firewall avec une stratégie de refus de tous au niveau global pour bloquer toutes les demandes qui ne correspondent pas à une stratégie Citrix Web App Firewall. Voici un exemple de commandes permettant de configurer une stratégie de « refus de tout » au niveau mondial :

add appfw profile default_deny_profile –defaults advanced

add appfw policy default_deny_policy NS_TRUE default_deny_profile

bind appfw global default_deny_policy <PRIORITY>
<!--NeedCopy-->

Remarque : le paramètre PRIORITY doit s’assurer que la stratégie par défaut est évaluée en dernier (uniquement si la demande ne correspond à aucune autre stratégie configurée).

La version 9.2 du logiciel Citrix ADC inclut des profils par défaut, tels que appfw_block, qui, lorsqu’ils sont configurés, bloquent les demandes qui ne correspondent pas aux stratégies Citrix Web App Firewall. Exécutez la commande suivante pour définir le profil par défaut :

set appfw settings -defaultProfile appfw_block
<!--NeedCopy-->

Citrix Web App Firewall — Création de plusieurs niveaux de sécurité

Les instructions suivantes vous aident à créer plusieurs niveaux de sécurité en fonction de votre environnement et des applications prises en charge.

Premier niveau de sécurité

Pour créer le premier niveau de sécurité, effectuez les opérations suivantes :

  • Activez le dépassement de tampon, l’injection SQL et le script inter-site.
  • L’URL de démarrage est nécessaire lorsque l’application est particulière sur les URL qui doivent être accédées et doivent se protéger contre la navigation forcée.
  • Activer le format de champ Vérifie si votre application attend des entrées dans un champ de formulaire.

La vérification des scripts inter-sites peut générer des faux positifs car de nombreuses entreprises disposent d’une grande base installée de contenu Web amélioré JavaScript qui viole la même règle d’origine. Si vous activez la vérification HTML Cross-Site Scripting sur un tel site, vous devez générer les exceptions appropriées afin que la vérification ne bloque pas l’activité légitime.

Déployez le premier niveau, recherchez les faux positifs, déployez les exceptions, puis passez au niveau suivant. Une implémentation progressive aide à gérer le déploiement AppFW.

Deuxième niveau de sécurité

Pour créer le deuxième niveau de sécurité, effectuez les opérations suivantes :

Activez les signatures sur le profil en plus du dépassement de tampon, de l’injection SQL et du script inter-site. Il y a plus de 1300 signatures. Essayez d’activer uniquement les signatures applicables à la protection de votre application, plutôt que d’activer toutes les règles de signature.

Déployez le deuxième niveau, recherchez les faux positifs, déployez les exceptions, puis passez au niveau suivant. Une implémentation progressive aide à gérer le déploiement Citrix Web App Firewall.

Troisième niveau de sécurité

Pour créer le troisième niveau de sécurité, effectuez les opérations suivantes :

  • En fonction des besoins de l’application, activez les contrôles Advanced Profile Security comme le marquage CSRF, la cohérence des cookies. Cohérence du champ de formulaire sur les parties des applications qui en ont besoin.
  • Les contrôles de sécurité avancés nécessitent un traitement plus important et peuvent affecter les performances. À moins que votre application n’ait besoin d’une sécurité avancée, vous pouvez commencer par un profil de base et resserrer la sécurité selon les besoins de votre application.

Les vérifications de sécurité désactivées dans le profil Citrix Web App Firewall de base fonctionnent tous sur les objets de la réponse HTTP. Par conséquent, ces contrôles de sécurité nécessitent plus de ressources. Lorsque Citrix Web App Firewall effectue des protections côté réponse, il doit mémoriser les informations envoyées à chaque client individuel. Par exemple, si un formulaire est protégé par Citrix Web App Firewall, les informations de champ de formulaire envoyées dans la réponse sont conservées en mémoire. Lorsque le client soumet le formulaire dans la demande suivante, les incohérences sont vérifiées avant que les informations ne soient envoyées au serveur Web. Ce concept est appelé “Sessionization”. Les contrôles de sécurité tels que l’enveloppe URL dans l’URL de démarrage, la cohérence des cookies, la cohérence des champs de formulaire et le marquage des formulaires CSRF impliquent tous la sessionization. La quantité de ressources CPU et mémoire utilisées par ces contrôles de sécurité augmente de façon linéaire avec le nombre de requêtes envoyées via Citrix Web App Firewall. Par exemple :

  • Activer le contrôle de cohérence des champs de formulaire : Cette vérification est requise pour vérifier si les formulaires Web n’ont pas été modifiés de manière inappropriée par le client. Une application qui sert et héberge des informations critiques dans les formulaires aurait besoin de la vérification.

  • Vérification du marquage du formulaire CSRF : Cette vérification concerne les formulaires. La vérification de balisage de formulaire CSRF (Falsification de requête inter-site) balise chaque formulaire Web envoyé par un site Web protégé aux utilisateurs avec un FormID unique et imprévisible, puis examine les formulaires Web renvoyés par les utilisateurs pour s’assurer que le formulaire fourni est correct. Cette vérification protège contre les attaques de falsification de requêtes intersites. Cette vérification doit être activée si l’application dispose de formulaires Web. Ce contrôle nécessite relativement peu de capacité de traitement de l’UC par rapport à certains autres contrôles de sécurité qui analysent les formulaires Web en profondeur. Il est donc capable de gérer des attaques de volume élevé sans dégrader sérieusement les performances du site Web protégé ou du Citrix Web App Firewall lui-même.

Étapes du workflow Citrix Web App Firewall

Le diagramme suivant illustre les étapes du workflow Citrix Web App Firewall :

Étapes du workflow Citrix Web App Firewall

Voici les étapes de haut niveau impliquées dans le flux de travail Citrix Web App Firewall :

  1. Configurez le profil de sécurité.
  2. Appliquer des signatures pour toutes les menaces connues - le modèle négatif.
  3. Configurez des stratégies de trafic qui peuvent détecter le flux de trafic correct où ce profil de sécurité doit être activé.

Vous êtes prêt pour que le trafic de production passe par le système. Le premier niveau de débit est terminé. En outre, configurez l’infrastructure d’apprentissage. De nombreuses fois, les clients veulent apprendre dans le trafic de production, ce qui permet d’avoir les signatures appliquées évite tout risque. Procédez comme suit :

  1. Configurez l’infrastructure d’apprentissage.
  2. Déployez les règles apprises pour la protection.
  3. Validez les données d’apprentissage ainsi que les signatures appliquées avant d’être mises en ligne.

Recommandations de sécurité Citrix Gateway

Utiliser une stratégie « Refuser par défaut »

Citrix recommande aux administrateurs de configurer Citrix Gateway avec une stratégie de « refus de tout » au niveau mondial, en plus de l’utilisation de stratégies d’autorisation pour activer sélectivement l’accès aux ressources sur une base de groupe.

Par défaut, le paramètre DefaultAuthorizationAction est défini sur DENY. Vérifiez ce paramètre et accordez un accès explicite à chaque utilisateur. Vous pouvez utiliser la commande show DefaultAuthorizationAction sur l’interface de ligne de commande pour vérifier le paramètre. Pour définir le paramètre de manière à refuser toutes les ressources au niveau global, exécutez la commande suivante à partir de l’interface de ligne de commande :

set vpn parameter -defaultAuthorizationAction DENY
<!--NeedCopy-->

Utiliser la communication TLS1.1/1.2 entre les serveurs

Citrix recommande vivement que TLS1.1/1.2 soit utilisé pour les liens entre l’appliance Citrix Gateway et d’autres services, tels que les serveurs LDAP et Web Interface. L’utilisation d’anciennes versions de ce protocole, 1.0, et SSLv3 et versions antérieures n’est pas recommandée.

Utilisez la fonctionnalité « Applications intranet » Utiliser les applications intranet pour définir quels réseaux sont interceptés par le plug-in Citrix Gateway et envoyés à la passerelle. Voici un exemple d’ensemble de commandes pour définir l’interception :

add vpn intranetApplication intra1 ANY 10.217.0.0 -netmask 255.255.0.0 -destPort 1-65535 -interception TRANSPARENT

bind vpn vserver v1 –intranetapp intra1
<!--NeedCopy-->

Recommandations de sécurité AAA Citrix ADC

Si une appliance Citrix ADC ou Citrix Gateway est configurée en tant que SP SAML ou SAML IdP ou les deux, consultez l’article https://support.citrix.com/article/CTX316577 pour obtenir les détails de configuration recommandés.

Pour plus d’informations sur l’authentification SAML, voir Authentification SAML.

Ressources d’information supplémentaires

Consultez les ressources suivantes pour obtenir d’autres informations de sécurité sur les appliances Citrix ADC et Citrix Gateway :

Pour obtenir de l’aide supplémentaire sur la configuration de votre Citrix ADC, vous pouvez soumettre une demande de support à l’adresse suivante : https://www.citrix.com/support.html

Présentation des meilleures pratiques en matière de sécurité Citrix ADC MPX, VPX et SDX